ONNX Runtime 部署排错指南从装到跑通、跑快的实战清单【免费下载链接】onnxruntimeONNX Runtime: cross-platform, high performance ML inferencing and training accelerator项目地址: https://gitcode.com/GitHub_Trending/on/onnxruntimeONNX Runtime 从安装到上线最容易卡在四步装错 CPU/GPU 包、模型加载时算子或形状报错、GPU 起不来、以及默认配置下的推理速度不达标。本文按部署顺序讲排查路径适用 onnxruntime 1.17CUDA 12 需 1.17 及以上覆盖 Python 为主、C 为辅的场景。安装与自检验证 ONNX Runtime 环境与 CUDA 版本装完别急着跑模型先做三件事确认装的是哪种包。纯 CPU 场景装onnxruntime要用 GPU 必须装onnxruntime-gpu。装错了包后面所有 CUDA 报错都是徒劳。pip show onnxruntime核对版本和安装位置确认你跑的进程和 pip 环境是同一个解释器——这是明明装好了却 ImportError最常见的原因。跑nvidia-smi对照下面这张表确认驱动支持的 CUDA 版本与 ONNX Runtime GPU 包的配套版本一致。Pythononnxruntime配套 CUDA / cuDNN3.9 ~ 3.121.17 ~ 1.20CUDA 11.8 / cuDNN 8.73.8 ~ 3.121.19 ~ 1.22CUDA 12.2 ~ 12.4 / cuDNN 8.9 ~ 9.13.91.21CUDA 12.x对不上时的动作很简单升级驱动、换onnxruntime-gpu小版本二选一直到 pip 包版本和nvidia-smi右上角的 CUDA Version 匹配。让模型跑起来处理算子不支持与输入形状不匹配加载阶段卡住的大多是两类问题。第一类是算子不支持报错形如Node (XXX) Op (XXX) is not supported。先怀疑两件事模型 opset 太低或运行时版本比导出模型时还旧。动作按顺序来先升级 onnxruntime多数老算子问题直接消失还不行就用最新 onnx 重新导出模型把 opset 拉到 14 以上。如果报错的是自研算子那是另一条路——把算子编译成动态库在 SessionOptions 上register_custom_ops_library(./custom_ops.so)注册进去实现方式见贡献算子文档。第二类是输入形状不匹配报错形如Shape mismatch: Input tensor has shape (X) but expected (Y)。怀疑点通常就两个batch 维写死没改、或者 dtype 不对。自查用session.get_inputs()它会把每个输入的名字、shape 和类型都列出来照着喂数据就行。看不清模型结构时用 Netron 可视化一遍输入节点的标注值就是硬要求。推理提速ONNX Runtime 性能调优的递进排查顺序ONNX Runtime 把图分区后分派给不同 Execution ProviderCPU 与 GPU EP 可以混跑没被 GPU 接管的算子自动回落 CPU。提速也按这个逻辑递进先排除低级原因再上重型手段先跑默认配置。多数模型不慢默认就是最优解先别动任何参数。调线程数。CPU 推理不够快先调intra_op_num_threads单算子内部并行和inter_op_num_threads算子间并行一般立刻见效opts ort.SessionOptions() opts.intra_op_num_threads 4 # 单算子内部并行线程数 opts.inter_op_num_threads 2 # 算子之间并行线程数 opts.enable_profiling True # 同时开 profiling后面第 4 步用 session ort.InferenceSession(model.onnx, opts, providers[CUDAExecutionProvider, CPUExecutionProvider])注意 providers 要带 CPU 回退顺序就是优先顺序指定一次即可后文不再重复。再考虑执行提供器。上表里 providers 指定了 GPU 优先、CPU 兜底确认日志里没有大面积回落说明 GPU EP 真正接住了图。开 profiling 定位瓶颈。end_profiling()生成的文件用 Chrome tracing 打开看哪些节点耗时、哪些节点还在 CPU 上跑。节点散落回 CPU 时优先查算子覆盖而不是继续拧线程参数。最后才是量化。先确认 ORT 的图优化默认全开没达到目标再考虑 INT8。GPU 上限制不少CUDA 构建只支持 QuantizeLinear、DequantizeLinear、MatMulInteger 三个量化算子其余会回落 CPUTensorRT EP 对 INT8 也只是有限支持。所以别为量化而量化profiling 显示计算瓶颈不在算子数量上就别动它。报错速查ONNX Runtime 报错关键词对照表报错关键词常见原因第一个该做的动作ImportError: No module named onnxruntime装错包、解释器/环境不一致pip show onnxruntime核对安装位置CUDA not available/CUDA out of memoryCUDA、cuDNN 版本与包不配套显存被批大小撑爆nvidia-smi对照驱动核对上表版本Shape mismatchbatch 维写死、dtype 不符session.get_inputs()对照实际数据Op (XXX) is not supportedopset 过旧、运行时过旧或自研算子先升级 onnxruntime再查 opsetCPU 与 GPU 结果不一致opset 差异、未对齐的浮点累加固定 opset 重导再比对输入 dtype打开 ONNX Runtime 详细日志报错信息看不出门道时把日志级别调到 VERBOSEPython 里在导入前执行ort.set_default_logger_severity(0)0 最详细3 只显示错误默认是 WARNINGC 则在Ort::Env构造时传ORT_LOGGING_LEVEL_VERBOSE。加载阶段的 provider 分配、算子回落都会打出来先开日志再调参别盲猜。限制 ONNX Runtime 线程数反过来线程用太多导致调度抖动、或者要和别的进程抢核时要把线程压下来构建带 OpenMP 时设环境变量OMP_NUM_THREADS否则把intra_op_num_threads设为 1并配合execution_mode ort.ExecutionMode.ORT_SEQUENTIAL走顺序执行。单线程复现问题还能帮你判断慢到底是并行问题还是模型本身的问题。上线前自查环境、模型与性能三行 checklist环境onnxruntime 版本、CUDA/cuDNN 版本、驱动版本三者互相匹配且和你跑模型的解释器一致。模型get_inputs()的 shape 与 dtype 和线上数据逐一对齐opset 不低于 13导出后跑过onnx.checker.check_model。性能默认配置跑过基线profiling 里没有意外回落 CPU 的关键节点线程参数在目标机器上调过而不是抄的。三行都对上剩下的问题基本只剩慢多少的量级之争了。排查细节多去翻仓库里的官方 FAQ它把量化支持、日志级别、单线程强制等高频问题都写了碰到仓库没覆盖的坑直接去项目 Issues 搜报错原文八成有人踩过同一条。【免费下载链接】onnxruntimeONNX Runtime: cross-platform, high performance ML inferencing and training accelerator项目地址: https://gitcode.com/GitHub_Trending/on/onnxruntime创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
ONNX Runtime 部署排错指南从装到跑通、跑快的实战清单【免费下载链接】onnxruntimeONNX Runtime: cross-platform, high performance ML inferencing and training accelerator项目地址: https://gitcode.com/GitHub_Trending/on/onnxruntimeONNX Runtime 从安装到上线最容易卡在四步装错 CPU/GPU 包、模型加载时算子或形状报错、GPU 起不来、以及默认配置下的推理速度不达标。本文按部署顺序讲排查路径适用 onnxruntime 1.17CUDA 12 需 1.17 及以上覆盖 Python 为主、C 为辅的场景。安装与自检验证 ONNX Runtime 环境与 CUDA 版本装完别急着跑模型先做三件事确认装的是哪种包。纯 CPU 场景装onnxruntime要用 GPU 必须装onnxruntime-gpu。装错了包后面所有 CUDA 报错都是徒劳。pip show onnxruntime核对版本和安装位置确认你跑的进程和 pip 环境是同一个解释器——这是明明装好了却 ImportError最常见的原因。跑nvidia-smi对照下面这张表确认驱动支持的 CUDA 版本与 ONNX Runtime GPU 包的配套版本一致。Pythononnxruntime配套 CUDA / cuDNN3.9 ~ 3.121.17 ~ 1.20CUDA 11.8 / cuDNN 8.73.8 ~ 3.121.19 ~ 1.22CUDA 12.2 ~ 12.4 / cuDNN 8.9 ~ 9.13.91.21CUDA 12.x对不上时的动作很简单升级驱动、换onnxruntime-gpu小版本二选一直到 pip 包版本和nvidia-smi右上角的 CUDA Version 匹配。让模型跑起来处理算子不支持与输入形状不匹配加载阶段卡住的大多是两类问题。第一类是算子不支持报错形如Node (XXX) Op (XXX) is not supported。先怀疑两件事模型 opset 太低或运行时版本比导出模型时还旧。动作按顺序来先升级 onnxruntime多数老算子问题直接消失还不行就用最新 onnx 重新导出模型把 opset 拉到 14 以上。如果报错的是自研算子那是另一条路——把算子编译成动态库在 SessionOptions 上register_custom_ops_library(./custom_ops.so)注册进去实现方式见贡献算子文档。第二类是输入形状不匹配报错形如Shape mismatch: Input tensor has shape (X) but expected (Y)。怀疑点通常就两个batch 维写死没改、或者 dtype 不对。自查用session.get_inputs()它会把每个输入的名字、shape 和类型都列出来照着喂数据就行。看不清模型结构时用 Netron 可视化一遍输入节点的标注值就是硬要求。推理提速ONNX Runtime 性能调优的递进排查顺序ONNX Runtime 把图分区后分派给不同 Execution ProviderCPU 与 GPU EP 可以混跑没被 GPU 接管的算子自动回落 CPU。提速也按这个逻辑递进先排除低级原因再上重型手段先跑默认配置。多数模型不慢默认就是最优解先别动任何参数。调线程数。CPU 推理不够快先调intra_op_num_threads单算子内部并行和inter_op_num_threads算子间并行一般立刻见效opts ort.SessionOptions() opts.intra_op_num_threads 4 # 单算子内部并行线程数 opts.inter_op_num_threads 2 # 算子之间并行线程数 opts.enable_profiling True # 同时开 profiling后面第 4 步用 session ort.InferenceSession(model.onnx, opts, providers[CUDAExecutionProvider, CPUExecutionProvider])注意 providers 要带 CPU 回退顺序就是优先顺序指定一次即可后文不再重复。再考虑执行提供器。上表里 providers 指定了 GPU 优先、CPU 兜底确认日志里没有大面积回落说明 GPU EP 真正接住了图。开 profiling 定位瓶颈。end_profiling()生成的文件用 Chrome tracing 打开看哪些节点耗时、哪些节点还在 CPU 上跑。节点散落回 CPU 时优先查算子覆盖而不是继续拧线程参数。最后才是量化。先确认 ORT 的图优化默认全开没达到目标再考虑 INT8。GPU 上限制不少CUDA 构建只支持 QuantizeLinear、DequantizeLinear、MatMulInteger 三个量化算子其余会回落 CPUTensorRT EP 对 INT8 也只是有限支持。所以别为量化而量化profiling 显示计算瓶颈不在算子数量上就别动它。报错速查ONNX Runtime 报错关键词对照表报错关键词常见原因第一个该做的动作ImportError: No module named onnxruntime装错包、解释器/环境不一致pip show onnxruntime核对安装位置CUDA not available/CUDA out of memoryCUDA、cuDNN 版本与包不配套显存被批大小撑爆nvidia-smi对照驱动核对上表版本Shape mismatchbatch 维写死、dtype 不符session.get_inputs()对照实际数据Op (XXX) is not supportedopset 过旧、运行时过旧或自研算子先升级 onnxruntime再查 opsetCPU 与 GPU 结果不一致opset 差异、未对齐的浮点累加固定 opset 重导再比对输入 dtype打开 ONNX Runtime 详细日志报错信息看不出门道时把日志级别调到 VERBOSEPython 里在导入前执行ort.set_default_logger_severity(0)0 最详细3 只显示错误默认是 WARNINGC 则在Ort::Env构造时传ORT_LOGGING_LEVEL_VERBOSE。加载阶段的 provider 分配、算子回落都会打出来先开日志再调参别盲猜。限制 ONNX Runtime 线程数反过来线程用太多导致调度抖动、或者要和别的进程抢核时要把线程压下来构建带 OpenMP 时设环境变量OMP_NUM_THREADS否则把intra_op_num_threads设为 1并配合execution_mode ort.ExecutionMode.ORT_SEQUENTIAL走顺序执行。单线程复现问题还能帮你判断慢到底是并行问题还是模型本身的问题。上线前自查环境、模型与性能三行 checklist环境onnxruntime 版本、CUDA/cuDNN 版本、驱动版本三者互相匹配且和你跑模型的解释器一致。模型get_inputs()的 shape 与 dtype 和线上数据逐一对齐opset 不低于 13导出后跑过onnx.checker.check_model。性能默认配置跑过基线profiling 里没有意外回落 CPU 的关键节点线程参数在目标机器上调过而不是抄的。三行都对上剩下的问题基本只剩慢多少的量级之争了。排查细节多去翻仓库里的官方 FAQ它把量化支持、日志级别、单线程强制等高频问题都写了碰到仓库没覆盖的坑直接去项目 Issues 搜报错原文八成有人踩过同一条。【免费下载链接】onnxruntimeONNX Runtime: cross-platform, high performance ML inferencing and training accelerator项目地址: https://gitcode.com/GitHub_Trending/on/onnxruntime创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
