最直接验证方式是捕获Ort::Session构造时抛出的Ort::Exception，错误信息含“CUDA provider registration failed”等字样；若成功加载，日志会明确输出CUDAExecutionProvider相关标识，且ONNX Runtime不会静默降级到CPU。
怎么确认 CUDA Execution Provider 已被正确加载
最直接的验证方式是捕获 Ort::Session 构造时抛出的异常，或检查日志输出中是否出现 CUDAExecutionProvider 相关字样。ONNX Runtime 不会在静默失败时自动降级到 CPU，如果 CUDA EP 加载失败，AppendExecutionProvider_CUDA() 会抛出 Ort::Exception，错误信息通常包含 "CUDA provider registration failed" 或 "Failed to load CUDA library"。
常见失败原因包括：
- CUDA 驱动版本低于要求（例如 CUDA 12.x 要求驱动 ≥ 525.60.13）
-
cudnn64_8.dll（或对应版本）未在PATH中，或与 CUDA 版本不匹配 - 显卡计算能力（Compute Capability）不被当前 ONNX Runtime 版本支持（如 v1.18.0 支持 5.0+，但不支持 3.5）
- 调用
AppendExecutionProvider_CUDA()前未启用 CUDA 构建选项（预编译库必须带-gpu后缀）
AppendExecutionProvider_CUDA() 的关键参数怎么设
AppendExecutionProvider_CUDA() 接收三个参数，顺序和含义必须严格匹配：
-
device_id：GPU 设备索引，从0开始；多卡环境需确保该 ID 对应的 GPU 处于可用状态（可通过nvidia-smi确认） -
arena_extend_strategy：GPU 内存池扩展策略，推荐使用1024*1024*1024（即 1GB），避免频繁分配释放；设为0表示禁用 arena，可能引发额外同步开销 -
cudnn_conv_algo_search：卷积算法搜索模式，OrtCudnnConvAlgoSearch::EXHAUSTIVE最准但首次推理慢，HEURISTIC更快但可能略损性能；生产环境建议先用EXHAUSTIVE测一次，再换回HEURISTIC
示例调用：
session_options.AppendExecutionProvider_CUDA(0, 1024*1024*1024, OrtCudnnConvAlgoSearch::EXHAUSTIVE);
为什么设置了 CUDA EP 还是跑在 CPU 上
即使成功调用 AppendExecutionProvider_CUDA()，模型仍可能 fallback 到 CPU 执行，根本原因是部分算子不被 CUDA EP 支持。ONNX Runtime 默认采用“fallback”策略：对不支持的节点，自动交由 CPU EP 处理。
排查方法：
- 启用图优化日志：
session_options.SetLogSeverityLevel(0)，观察日志中是否有"Node placed on CPU"提示 - 用
onnxruntime-tools的model_analyzer检查模型算子兼容性，重点关注Resize、NonMaxSuppression、动态 shape 相关算子 - 某些 ONNX 导出设置（如 PyTorch 的
dynamic_axes过度开放）会导致子图无法被 CUDA EP 完整承接
临时绕过方式：强制关闭 fallback，让不支持节点报错而非降级——设置 session_options.AddConfigEntry("session.load_model_format", "ORT") 并配合 session_options.SetGraphOptimizationLevel(GraphOptimizationLevel::ORT_ENABLE_EXTENDED)，可暴露真实不兼容点。
线程配置和内存池对 CUDA 推理的实际影响
SetIntraOpNumThreads() 和 SetInterOpNumThreads() 对 CUDA EP 几乎无影响——GPU 计算本身不依赖这些 CPU 线程数设置。真正关键的是显存分配与数据传输路径：
- 输入/输出张量尽量使用
Ort::MemoryInfo::CreateCpu(..., OrtMemType::OrtMemTypeDefault)创建，避免跨设备拷贝；若需 GPU 内存直传，必须用Ort::MemoryInfo::CreateCuda(...)并确保所有Ort::Value生命周期内绑定同一 GPU 上下文 - 批处理大小（batch size）必须在模型导出时就固定或明确声明支持的 range，CUDA EP 对动态 batch 支持有限，尤其在
NonMaxSuppression等后处理节点上容易触发 CPU fallback - 首次推理延迟高是正常现象，主要耗在 cuDNN 卷积算法预热和显存池初始化；后续推理才会体现真实加速比
最容易被忽略的一点：Windows 下若使用预编译库，必须确保 onnxruntime_providers_cuda.dll 和 onnxruntime.dll 来自同一发布包（例如都来自 onnxruntime-win-x64-gpu-cuda12-1.18.0.zip），混用不同版本的 DLL 会导致 EP 注册静默失败，且无明确报错提示。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
