资料整理

ONNX 能导入但用不上显卡：分开查包、执行提供程序和会话

区分 onnx、onnxruntime、GPU 构建与会话实际使用的执行提供程序，避免把所有错误当成缺包。

更新于 2026-09-25发布修订: 7资料基线: 7

按三层看，不只看安装按钮

onnx 与 onnxruntime 不是同一个分发包。get_available_providers() 列出已安装运行时可用的 provider；InferenceSession.get_providers() 列出该会话注册的 provider。这两种列表都不能证明当前模型把计算交给 CUDA。provider 有优先顺序：能由 CUDA 处理的节点可以走 CUDA，其余节点仍可能走 CPU。安装说明 CUDA 要求 Python API provider 优先级

我们建议保留的检查结果

先用原解释器查看安装记录，判断是否混入了不同运行时构建。然后才对已经信任的运行时执行下面的查询；它会导入包，不能代替安全审核。

python -m pip show onnx onnxruntime onnxruntime-gpu
python -c "import onnxruntime as r; print(r.__version__); print(r.get_available_providers())"

只在受影响节点使用的解释器和可信安装中执行；导入命令会加载原生代码。若包能导入但没有 CUDAExecutionProvider，先核对运行时构建，再考虑驱动。若 CUDA provider 可见，仍需记录节点实际创建的会话及初始化日志；可用列表不能证明 GPU 执行。

不同现象的下一步

模块找不到，先查解释器与已安装分发包；provider 动态库加载失败，按当前 ONNX Runtime 版本核对官方 CUDA/cuDNN 主版本要求及原生库报错，GPU 包的默认构建会随发行版变化。会话退回 CPU，查节点的 provider 顺序与初始化日志。CUDA 和 CPU 都在会话列表里，也可能有不支持 CUDA 的节点落到 CPU；运行时及包装层提供图分配或 profiling 信息时，才据此核验。模型格式或算子失败，应保留原错误，不先重装驱动。

验收与止损

保留可恢复的环境副本，按节点项目约束只改变必要的一层。用原节点和小输入执行一次，记录会话 provider 列表以及可取得的图分配或 profiling 证据。包装层无法提供足够证据时，应标为“GPU 执行未验证”。若仅 CPU 路径成功，只能标记“CPU 路径通过”；没有实测不填写 GPU 加速倍数。