本文旨在解决在同一Python程序中同时使用ONNX Runtime（CUDA Execution Provider）和TensorRT时，因CUDA上下文管理不当导致的“invalid resource handle”错误。核心问题在于pycuda.autoinit与多框架CUDA操作的冲突。通过采用PyCUDA手动初始化和管理CUDA上下文（cuda.init(), ctx.push(), ctx.pop()），可以有效避免资源冲突，确保两种推理引擎稳定协同工作，并提供详细代码示例及最佳实践。
1. 问题背景与现象
在深度学习推理部署中，我们常常需要集成多种优化工具或框架。例如，onnx runtime提供跨平台推理能力，而nvidia tensorrt则专注于nvidia gpu上的高性能推理。当尝试在同一个python脚本中同时加载并运行onnx runtime（配置为使用cuda execution provider）和tensorrt模型时，开发者可能会遇到以下cuda运行时错误：
[TRT] [E] 1: [convolutionRunner.cpp::execute::391] Error Code 1: Cask (Cask convolution execution)[TRT] [E] 1: [checkMacros.cpp::catchCudaError::272] Error Code 1: Cuda Runtime (invalid resource handle)
这些错误通常伴随着ONNX Runtime的警告，提示某些节点未分配到首选执行器，但核心问题在于Cuda Runtime (invalid resource handle)。值得注意的是，如果单独运行每个模型，或者将ONNX Runtime的Provider设置为CPUExecutionProvider，则这些错误不会出现。这表明问题根源在于CUDA资源的共享与管理。
2. 根本原因：CUDA上下文冲突
此问题的核心在于CUDA上下文（CUDA Context）的管理。CUDA上下文是GPU上所有CUDA操作的执行环境，包括内存分配、流管理、内核启动等。每个进程或线程通常需要一个或多个CUDA上下文来执行GPU操作。
pycuda.autoinit的机制： pycuda.autoinit模块在导入时会自动初始化CUDA并为当前线程创建一个默认的CUDA上下文，并将其推送到CUDA上下文堆栈的顶部。这对于简单的PyCUDA程序非常方便。多框架的挑战： 当程序中引入TensorRT和ONNX Runtime（CUDA Execution Provider）时，情况变得复杂。TensorRT： TensorRT在反序列化引擎并创建执行上下文时，会与CUDA运行时交互，可能期望一个特定的CUDA上下文环境。ONNX Runtime (CUDA EP)： ONNX Runtime的CUDA Execution Provider也会在内部初始化CUDA并管理其自己的CUDA上下文。冲突的产生： 如果pycuda.autoinit创建的默认上下文与TensorRT或ONNX Runtime内部所需的上下文管理方式发生冲突，或者上下文堆栈没有被正确地管理（例如，一个上下文被推入但未弹出，导致后续操作在错误的上下文上执行），就会出现invalid resource handle错误。TensorRT尤其对CUDA上下文的活跃状态和有效性敏感。当多个库试图独立管理或依赖全局CUDA上下文时，就容易发生资源句柄失效的问题。
3. 解决方案：手动管理CUDA上下文
解决此问题的关键在于放弃pycuda.autoinit的自动管理，转而采用PyCUDA手动初始化和管理CUDA上下文。通过显式地创建、推送和弹出CUDA上下文，我们可以确保在TensorRT和ONNX Runtime执行GPU操作时，始终有一个有效且受控的CUDA上下文处于激活状态。
3.1 手动CUDA上下文管理步骤
禁用pycuda.autoinit： 从代码中移除import pycuda.autoinit。初始化CUDA驱动： 调用cuda.init()。创建设备和上下文： 选择一个CUDA设备（例如cuda.Device(0)），然后调用device.make_context()创建上下文。推送和弹出上下文： 在所有需要CUDA上下文的操作（包括TensorRT引擎的创建、执行以及ONNX Runtime会话的创建、推理）之前，使用ctx.push()将上下文推入堆栈；在这些操作完成后，使用ctx.pop()将其弹出。通常，这可以通过try…finally块来确保上下文始终被正确弹出和清理。分离上下文： 在程序结束或不再需要CUDA上下文时，调用ctx.detach()来分离上下文并释放相关资源。
3.2 示例代码：ONNX Runtime与TensorRT的协同推理
以下是修改后的代码示例，演示了如何通过手动管理CUDA上下文来解决上述问题：
import cv2import numpy as npimport pycuda.driver as cuda# import pycuda.autoinit # 移除此行，手动管理CUDA上下文import tensorrt as trtnp.bool = np.bool_ # 兼容旧版Numpyimport onnximport onnxruntime# 假设 profiling 模块已定义，如果不需要可删除或替换# from profiling import GlobalProfTime, ProfTimer, mode_to_str# 1. 手动初始化CUDA驱动并创建上下文cuda.init()# 选择第一个GPU设备device = cuda.Device(0)# 为该设备创建CUDA上下文ctx = device.make_context()# 2. 将创建的上下文推入当前线程的CUDA上下文堆栈ctx.push()# 使用try...finally块确保上下文在程序结束时被正确弹出和清理try: # with GlobalProfTime('profile_tensorrt_10_000images') as t: # 性能分析，如果不需要可注释 # with ProfTimer('TensorRT basic image profiler') as t: # 性能分析，如果不需要可注释 # --- TensorRT 模型初始化部分 --- TRT_ENGINE_PATH = '/app/models/buffalo_l/det_10g640x640.engine' # 创建TensorRT运行时日志器 runtime = trt.Runtime(trt.Logger(trt.Logger.WARNING)) # 反序列化TensorRT引擎 with open(TRT_ENGINE_PATH, 'rb') as f: engine_data = f.read() engine = runtime.deserialize_cuda_engine(engine_data) assert engine is not None, "Failed to deserialize TensorRT engine." # 创建TensorRT执行上下文 context = engine.create_execution_context() # 分配输入输出内存 inputs, outputs, bindings, stream = [], [], [], cuda.Stream() for binding in engine: size = trt.volume(engine.get_binding_shape(binding)) * engine.max_batch_size dtype = trt.nptype(engine.get_binding_dtype(binding)) host_mem = cuda.pagelocked_empty(size, dtype) # 页锁定内存 device_mem = cuda.mem_alloc(host_mem.nbytes) # 设备内存 bindings.append(int(device_mem)) if engine.binding_is_input(binding): inputs.append({'host': host_mem, 'device': device_mem, 'name': binding, 'shape': engine.get_binding_shape(binding), 'type': engine.get_binding_dtype(binding)}) else: outputs.append({'host': host_mem, 'device': device_mem, 'name': binding, 'shape': engine.get_binding_shape(binding), 'type': engine.get_binding_dtype(binding)}) # 加载并预处理TensorRT模型输入图像 image_path = "/app/models/buffalo_l/image.png" image = cv2.imread(image_path) assert image is not None, f"Failed to load image from {image_path}" image = cv2.cvtColor(image, cv2.COLOR_BGR2RGB) image = cv2.resize(image, (640, 640)) image = image.astype(np.float32) / 255.0 input_data_trt = np.expand_dims(image.transpose(2, 0, 1), axis=0) # --- ONNX Runtime 模型初始化部分 --- onnx_model_path = "/app/models/buffalo_l/det_10g.onnx" # 加载ONNX模型（可选，onnxruntime.InferenceSession会自动加载） # onnx_model = onnx.load(onnx_model_path) # 创建ONNX Runtime会话，并指定CUDAExecutionProvider # 注意：ort_session的创建必须在CUDA上下文被推入后进行 ort_session = onnxruntime.InferenceSession(onnx_model_path, providers=['CUDAExecutionProvider']) # --- TensorRT 模型推理部分 --- print("n--- Running TensorRT Inference ---") for _ in range(1): # with ProfTimer('TensorRT per call') as t: # 性能分析，如果不需要可注释 # 将输入数据从主机内存拷贝到GPU设备内存 cuda.memcpy_htod_async(inputs[0]['device'], input_data_trt.ravel(), stream) # 执行推理 if context.execute_async(batch_size=1, bindings=bindings, stream_handle=stream.handle) == 0: print("Error: Unable to launch TensorRT inference.") # 将结果从GPU设备内存拷贝回主机内存 if cuda.memcpy_dtoh_async(outputs[0]['host'], outputs[0]['device'], stream) == 0: print("Error: Unable to copy results from GPU to host.") # 获取推理结果 result_trt = outputs[0]['host'] # 同步CUDA流 stream.synchronize() print("Inference TensorRT Results (first 20 elements):") print(result_trt[:20]) stream.synchronize() # 确保所有TensorRT操作完成 # --- ONNX Runtime 模型推理部分 --- print("n--- Running ONNX (CUDA) Inference ---") for _ in range(1): # with ProfTimer('ONNX(CUDA) per call') as t: # 性能分析，如果不需要可注释 # 重新加载并预处理ONNX模型输入图像（如果需要，否则可复用input_data_trt） image_path_onnx = "/app/models/buffalo_l/image.png" image_onnx = cv2.imread(image_path_onnx) assert image_onnx is not None, f"Failed to load image from {image_path_onnx}" image_onnx = cv2.cvtColor(image_onnx, cv2.COLOR_BGR2RGB) image_onnx = cv2.resize(image_onnx, (640, 640)) image_onnx = image_onnx.astype(np.float32) / 255.0 input_data_onnx = np.expand_dims(image_onnx.transpose(2, 0, 1), axis=0) # 获取ONNX模型的输入名称 input_name_onnx = ort_session.get_inputs()[0].name # 运行ONNX推理 outputs_onnx = ort_session.run(None, {input_name_onnx: input_data_onnx}) print("Inference ONNX Results (first 20 elements):") # 注意：ONNX输出的形状可能与TensorRT不同，这里仅打印前20个元素 print(f"{np.transpose(outputs_onnx[0][:20])}")finally: # 3. 确保上下文被弹出，无论是否发生异常 ctx.pop() # 4. 分离并销毁上下文以释放资源 ctx.detach() # 清理TensorRT相关资源 if 'context' in locals() and context: context.destroy() if 'engine' in locals() and engine: engine.destroy() if 'runtime' in locals() and runtime: del runtime # runtime对象没有destroy方法，直接删除引用 # ONNX Runtime session通常在对象销毁时自动释放资源，无需显式操作 # 如果需要，也可以 del ort_session print("nCUDA Context and resources cleaned up.")
4. 注意事项与最佳实践
上下文生命周期管理： 确保ctx.push()和ctx.pop()成对出现，并且所有依赖CUDA的操作都在这两个调用之间。使用try…finally块是保证pop()被执行的健壮方法。资源清理： 除了CUDA上下文，TensorRT的engine和context对象也需要显式地destroy()以释放GPU内存。np.bool兼容性： np.bool = np.bool_这行代码是为了兼容旧版NumPy，在新版中np.bool已被弃用，通常直接使用bool即可。如果遇到相关警告或错误，可以保留此行。多线程/多进程： 如果在多线程或多进程环境中使用CUDA，每个线程/进程可能需要独立管理其CUDA上下文，或者使用PyCUDA提供的线程安全机制。这会使问题变得更复杂，需要更高级的CUDA编程知识。驱动与库版本： 确保NVIDIA驱动、CUDA Toolkit、cuDNN、TensorRT以及ONNX Runtime的版本兼容。不匹配的版本可能导致各种运行时错误。调试： 如果问题依然存在，可以尝试设置CUDA_LAUNCH_BLOCKING=1环境变量，这会让CUDA操作同步执行，有助于定位错误发生的具体位置，但会影响性能。同时，检查TensorRT和ONNX Runtime的日志输出，通常能提供更多线索。
5. 总结
在同一Python程序中整合ONNX Runtime（CUDA Execution Provider）和TensorRT时，正确管理CUDA上下文是避免“invalid resource handle”等资源冲突的关键。通过移除pycuda.autoinit并采用手动pycuda.driver初始化和上下文堆栈管理（ctx.push()和ctx.pop()），我们可以为所有CUDA依赖的库提供一个稳定且受控的执行环境，从而确保两种高性能推理引擎的顺利协同工作。理解并实施这些CUDA上下文管理原则，对于构建健壮且高效的深度学习部署系统至关重要。
以上就是解决ONNX Runtime与TensorRT共存时的CUDA资源冲突的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/1366305.html
微信扫一扫 
支付宝扫一扫 
