简介onnxruntime-win-x64-1.23.2.zip 是 ONNX Runtime 官方预编译的 Windows 64 位 CPU 版本安装包面向需要在本地部署或调试 ONNX 模型推理的开发者、算法工程师及学生。由于官方渠道下载速度不稳定此备份包可帮助读者快速获取完整运行库省去反复重试的麻烦。压缩包共 26 个文件约 74.51MB以 C/C 头文件为主包含 onnxruntime_c_api.h、onnxruntime_cxx_api.h、onnxruntime_float16.h 等核心接口声明以及 onnxruntime.dll、onnxruntime.lib、onnxruntime_providers_shared.dll 等动态库与导入库另附 pdb 调试符号、LICENSE、README.md、VERSION_NUMBER 与 GIT_COMMIT_ID 等元数据便于核对版本与二次开发。目前已有 78 人学习下载。读者可直接将 include 与 lib 目录接入 Visual Studio 工程完成模型加载、会话配置与 CPU 推理调用适合作为 Windows 平台 ONNX 部署的稳定依赖备份。1. onnxruntime-win-x64-1.23.2 到底解决什么问题从模型训练完到 Windows 上跑起来的那段路训练好的模型在 Linux 服务器上跑得好好的一搬到 Windows 客户端就报找不到 onnxruntime.dll或者 Python 里import onnxruntime直接抛DLL load failed——这类问题我见过太多次。onnxruntime-win-x64-1.23.2.zip 就是干这件事的它是 ONNX Runtime 官方为 Windows 64 位平台编译好的运行时压缩包解压后直接拿到onnxruntime.dll、onnxruntime_providers_*.dll以及配套的头文件和导入库。你不需要装 Visual Studio 编译整套源码也不需要折腾 CMake 工具链把包解开、路径配好C、C#、Python 都能直接调用。适合谁做模型部署的算法工程师、需要在 Windows 上集成推理能力的桌面端开发者以及被 DLL 依赖问题卡住的运维同学。这一版对应 1.23.2属于 1.23 分支的补丁版本接口稳定适合生产环境落地。2. 包内结构与依赖关系先搞清楚你拿到的是什么2.1 解压后目录长什么样把 zip 解开根目录通常叫onnxruntime-win-x64-1.23.2里面按用途分成几个区域。我一般先tree一下看清楚# Windows 下用 dir /s /b 递归列出Linux/macOS 用 tree dir /s /b onnxruntime-win-x64-1.23.2典型结构如下不同小版本可能略有差异以实际解压为准路径内容用途lib/onnxruntime.dll核心运行时所有语言最终都加载它lib/onnxruntime_providers_shared.dllProvider 公共层CPU 之外的执行提供者依赖lib/onnxruntime_providers_cuda.dllCUDA EP有 NVIDIA 显卡时启用 GPU 推理lib/onnxruntime.lib导入库C 链接用include/onnxruntime_c_api.hC 接口头文件C/C 集成入口include/onnxruntime_cxx_api.hC 封装头写 C 推理代码用这个更省事这里有个容易忽略的点onnxruntime.dll和onnxruntime_providers_shared.dll必须放在同一个目录否则加载 CUDA 或 TensorRT 时会报provider shared library not found。我一般把lib整个目录加到PATH而不是只复制单个 dll。2.2 为什么选官方预编译包而不是自己编自己从源码编 onnxruntime 在 Windows 上是一场硬仗需要匹配的 CMake、Python、Visual Studio 版本还要拉 protobuf、eigen 等一堆子模块编译一次动辄一两个小时中间任何一步版本对不上就失败。官方预编译包把这些都替你做了而且针对不同 CUDA 版本有对应构建。常见做法是开发阶段用官方包快速验证确认接口和精度没问题后如果对体积或特定算子有要求再考虑裁剪编译。对于绝大多数部署场景直接用这个 zip 就够了。2.3 版本对齐别让 dll 和 Python 包打架如果你同时用 Python 的onnxruntimepip 包和这个 C 包要注意版本号尽量一致。pip 包内部也带了自己的 dll如果PATH里的 dll 版本和 pip 包不匹配会出现onnxruntime能 import 但一推理就崩的情况。我的习惯是C 集成用这个 zipPython 环境单独用 pip 装两者不混用同一个PATH。如果非要混先python -c import onnxruntime; print(onnxruntime.__version__)确认版本再决定 dll 用哪个。3. 三种集成方式实操C、C#、Python 各走一遍3.1 C 集成从链接到跑通第一个模型C 是最直接的用法也是这个包设计的核心场景。假设你已经有一个model.onnx下面是最小可运行示例// main.cpp #include onnxruntime_cxx_api.h #include iostream #include vector int main() { // 1. 创建环境日志级别设为 WARNING 避免刷屏 Ort::Env env(ORT_LOGGING_LEVEL_WARNING, test); // 2. 配置会话选项线程数按 CPU 核心数设 Ort::SessionOptions session_options; session_options.SetIntraOpNumThreads(4); session_options.SetGraphOptimizationLevel(GraphOptimizationLevel::ORT_ENABLE_ALL); // 3. 加载模型路径用宽字符 Ort::Session session(env, Lmodel.onnx, session_options); // 4. 查询输入输出信息 Ort::AllocatorWithDefaultOptions allocator; auto input_name session.GetInputNameAllocated(0, allocator); auto output_name session.GetOutputNameAllocated(0, allocator); std::cout Input: input_name.get() std::endl; std::cout Output: output_name.get() std::endl; return 0; }编译命令MSVCcl /EHsc /I onnxruntime-win-x64-1.23.2\include main.cpp ^ /link onnxruntime-win-x64-1.23.2\lib\onnxruntime.lib逻辑说明Ort::Env是全局单例一个进程创建一个就够SessionOptions里SetIntraOpNumThreads控制算子内并行度设成 CPU 物理核心数通常最优GetInputNameAllocated返回的是智能指针别手动 free。参数方面GraphOptimizationLevel::ORT_ENABLE_ALL会做常量折叠、算子融合等优化首次加载稍慢但推理更快生产环境建议开。3.2 C# 集成NuGet 包和本地 dll 怎么配合C# 项目一般用Microsoft.ML.OnnxRuntimeNuGet 包但如果你要指定用这个 zip 里的 dll需要手动处理。做法是NuGet 包提供托管层把 zip 里的onnxruntime.dll复制到输出目录覆盖默认的。using Microsoft.ML.OnnxRuntime; using Microsoft.ML.OnnxRuntime.Tensors; var session new InferenceSession(model.onnx); var inputTensor new DenseTensorfloat(new[] { 1, 3, 224, 224 }); var inputs new ListNamedOnnxValue { NamedOnnxValue.CreateFromTensor(input, inputTensor) }; using var results session.Run(inputs); foreach (var r in results) { Console.WriteLine(r.Name); }关键点C# 的InferenceSession默认从程序目录找onnxruntime.dll所以把 zip 里的 dll 放到bin\Debug\net6.0\下即可。如果报Unable to load DLL onnxruntime九成是 dll 没复制过去或者位数不对x64 项目必须用 x64 dll。3.3 Python 集成绕过 pip 直接用本地 dllPython 用户通常直接pip install onnxruntime但如果你想用这个特定版本的 dll可以手动指定import onnxruntime as ort import numpy as np # 查看可用 provider print(ort.get_available_providers()) # 创建会话指定 CPU 执行 sess ort.InferenceSession(model.onnx, providers[CPUExecutionProvider]) # 查看输入输出 for inp in sess.get_inputs(): print(inp.name, inp.shape, inp.type) # 推理 input_data np.random.randn(1, 3, 224, 224).astype(np.float32) outputs sess.run(None, {input: input_data}) print(outputs[0].shape)如果要用本地 dll 而不是 pip 自带的把 zip 里的 dll 所在目录加到PATH最前面再import onnxruntime。注意 Python 版本和 dll 位数必须匹配64 位 Python 配 x64 dll。4. 避坑与排查那些让我加班到凌晨的报错4.1 现象DLL load failed: 找不到指定的模块原因onnxruntime.dll依赖 Visual C 运行时系统缺vcruntime140.dll或msvcp140.dll。解决装Microsoft Visual C 2015-2022 Redistributable (x64)这是最常见的补救措施。装完重启终端再试。4.2 现象CUDA provider 加载失败回退到 CPU原因onnxruntime_providers_cuda.dll和onnxruntime_providers_shared.dll不在同一目录或者 CUDA/cuDNN 版本不匹配。解决确认两个 dll 同目录然后nvidia-smi看驱动支持的 CUDA 版本对照 onnxruntime 官方文档确认该版本要求的 CUDA 和 cuDNN 版本。版本不对就换对应的 onnxruntime 构建。4.3 现象推理结果和训练框架对不上原因输入预处理不一致比如归一化参数、通道顺序NCHW vs NHWC、数据类型float32 vs float16。解决用sess.get_inputs()打印期望的 shape 和 type逐项核对预处理代码。我一般会拿一张固定图片在训练框架和 onnxruntime 里各跑一次对比输出余弦相似度低于 0.999 就说明有问题。4.4 现象多线程下推理崩溃或结果错乱原因Ort::Session不是线程安全的多个线程共用一个 session 同时Run会出问题。解决要么每个线程创建自己的 session内存开销大要么加锁串行化Run调用。常见做法是用线程池加 session 池每个 session 绑定一个线程。4.5 现象模型加载慢首次推理卡顿原因图优化和内存分配在首次Run时才完成。解决加载后先用一个 dummy 输入跑一次 warmup把初始化开销提前。另外SetGraphOptimizationLevel设为ORT_ENABLE_ALL会增加加载时间但降低推理延迟按场景权衡。5. 进阶技巧用 ONNX Runtime 做动态批处理和性能验证5.1 动态 batch 的正确打开方式很多模型导出时 batch 维度是固定的但实际请求量是波动的。如果模型支持动态 batch导出时dynamic_axes设了 batch 维onnxruntime 可以自动处理不同 batch size# 假设模型支持动态 batch for bs in [1, 4, 8, 16]: dummy np.random.randn(bs, 3, 224, 224).astype(np.float32) out sess.run(None, {input: dummy}) print(fbatch{bs}, output shape{out[0].shape})如果模型不支持动态 batch就得导出时重新指定或者用固定 batch 加 padding。我一般会在导出阶段就把 batch 维设为动态省得后面改。5.2 性能验证别只看单次推理时间测性能不能只跑一次time要区分加载时间、首次推理时间、稳态推理时间。我习惯用下面这段脚本import time import numpy as np import onnxruntime as ort sess ort.InferenceSession(model.onnx, providers[CPUExecutionProvider]) input_data np.random.randn(1, 3, 224, 224).astype(np.float32) # warmup for _ in range(10): sess.run(None, {input: input_data}) # 稳态测试 times [] for _ in range(100): start time.perf_counter() sess.run(None, {input: input_data}) times.append(time.perf_counter() - start) times np.array(times) * 1000 # 转毫秒 print(f平均: {times.mean():.2f}ms, P50: {np.percentile(times, 50):.2f}ms, fP99: {np.percentile(times, 99):.2f}ms)关注 P99 而不是平均值因为线上超时往往发生在长尾。如果 P99 远高于 P50说明有线程竞争或内存分配抖动可以尝试调SetIntraOpNumThreads和SetInterOpNumThreads。5.3 一个我踩过的坑有次部署一个图像分类模型CPU 上 P50 只有 8ms但 P99 飙到 200ms。排查半天发现是SetIntraOpNumThreads设成了 16而机器只有 8 核线程切换开销反而拖慢了长尾。改成 8 之后 P99 降到 15ms。从那以后我每次设线程数都强制走一遍std::thread::hardware_concurrency()确认物理核心数再留一两个核给系统。希望这些经验帮到你少走点弯路。本文还有配套的精品资源点击获取 
长河君 · 2026/10/30 0:46:19 · 阅读 1.2k onnxruntime-win-x64-1.23.2 部署指南：C++/C#/Python 集成与避坑
简介onnxruntime-win-x64-1.23.2.zip 是 ONNX Runtime 官方预编译的 Windows 64 位 CPU 版本安装包面向需要在本地部署或调试 ONNX 模型推理的开发者、算法工程师及学生。由于官方渠道下载速度不稳定此备份包可帮助读者快速获取完整运行库省去反复重试的麻烦。压缩包共 26 个文件约 74.51MB以 C/C 头文件为主包含 onnxruntime_c_api.h、onnxruntime_cxx_api.h、onnxruntime_float16.h 等核心接口声明以及 onnxruntime.dll、onnxruntime.lib、onnxruntime_providers_shared.dll 等动态库与导入库另附 pdb 调试符号、LICENSE、README.md、VERSION_NUMBER 与 GIT_COMMIT_ID 等元数据便于核对版本与二次开发。目前已有 78 人学习下载。读者可直接将 include 与 lib 目录接入 Visual Studio 工程完成模型加载、会话配置与 CPU 推理调用适合作为 Windows 平台 ONNX 部署的稳定依赖备份。1. onnxruntime-win-x64-1.23.2 到底解决什么问题从模型训练完到 Windows 上跑起来的那段路训练好的模型在 Linux 服务器上跑得好好的一搬到 Windows 客户端就报找不到 onnxruntime.dll或者 Python 里import onnxruntime直接抛DLL load failed——这类问题我见过太多次。onnxruntime-win-x64-1.23.2.zip 就是干这件事的它是 ONNX Runtime 官方为 Windows 64 位平台编译好的运行时压缩包解压后直接拿到onnxruntime.dll、onnxruntime_providers_*.dll以及配套的头文件和导入库。你不需要装 Visual Studio 编译整套源码也不需要折腾 CMake 工具链把包解开、路径配好C、C#、Python 都能直接调用。适合谁做模型部署的算法工程师、需要在 Windows 上集成推理能力的桌面端开发者以及被 DLL 依赖问题卡住的运维同学。这一版对应 1.23.2属于 1.23 分支的补丁版本接口稳定适合生产环境落地。2. 包内结构与依赖关系先搞清楚你拿到的是什么2.1 解压后目录长什么样把 zip 解开根目录通常叫onnxruntime-win-x64-1.23.2里面按用途分成几个区域。我一般先tree一下看清楚# Windows 下用 dir /s /b 递归列出Linux/macOS 用 tree dir /s /b onnxruntime-win-x64-1.23.2典型结构如下不同小版本可能略有差异以实际解压为准路径内容用途lib/onnxruntime.dll核心运行时所有语言最终都加载它lib/onnxruntime_providers_shared.dllProvider 公共层CPU 之外的执行提供者依赖lib/onnxruntime_providers_cuda.dllCUDA EP有 NVIDIA 显卡时启用 GPU 推理lib/onnxruntime.lib导入库C 链接用include/onnxruntime_c_api.hC 接口头文件C/C 集成入口include/onnxruntime_cxx_api.hC 封装头写 C 推理代码用这个更省事这里有个容易忽略的点onnxruntime.dll和onnxruntime_providers_shared.dll必须放在同一个目录否则加载 CUDA 或 TensorRT 时会报provider shared library not found。我一般把lib整个目录加到PATH而不是只复制单个 dll。2.2 为什么选官方预编译包而不是自己编自己从源码编 onnxruntime 在 Windows 上是一场硬仗需要匹配的 CMake、Python、Visual Studio 版本还要拉 protobuf、eigen 等一堆子模块编译一次动辄一两个小时中间任何一步版本对不上就失败。官方预编译包把这些都替你做了而且针对不同 CUDA 版本有对应构建。常见做法是开发阶段用官方包快速验证确认接口和精度没问题后如果对体积或特定算子有要求再考虑裁剪编译。对于绝大多数部署场景直接用这个 zip 就够了。2.3 版本对齐别让 dll 和 Python 包打架如果你同时用 Python 的onnxruntimepip 包和这个 C 包要注意版本号尽量一致。pip 包内部也带了自己的 dll如果PATH里的 dll 版本和 pip 包不匹配会出现onnxruntime能 import 但一推理就崩的情况。我的习惯是C 集成用这个 zipPython 环境单独用 pip 装两者不混用同一个PATH。如果非要混先python -c import onnxruntime; print(onnxruntime.__version__)确认版本再决定 dll 用哪个。3. 三种集成方式实操C、C#、Python 各走一遍3.1 C 集成从链接到跑通第一个模型C 是最直接的用法也是这个包设计的核心场景。假设你已经有一个model.onnx下面是最小可运行示例// main.cpp #include onnxruntime_cxx_api.h #include iostream #include vector int main() { // 1. 创建环境日志级别设为 WARNING 避免刷屏 Ort::Env env(ORT_LOGGING_LEVEL_WARNING, test); // 2. 配置会话选项线程数按 CPU 核心数设 Ort::SessionOptions session_options; session_options.SetIntraOpNumThreads(4); session_options.SetGraphOptimizationLevel(GraphOptimizationLevel::ORT_ENABLE_ALL); // 3. 加载模型路径用宽字符 Ort::Session session(env, Lmodel.onnx, session_options); // 4. 查询输入输出信息 Ort::AllocatorWithDefaultOptions allocator; auto input_name session.GetInputNameAllocated(0, allocator); auto output_name session.GetOutputNameAllocated(0, allocator); std::cout Input: input_name.get() std::endl; std::cout Output: output_name.get() std::endl; return 0; }编译命令MSVCcl /EHsc /I onnxruntime-win-x64-1.23.2\include main.cpp ^ /link onnxruntime-win-x64-1.23.2\lib\onnxruntime.lib逻辑说明Ort::Env是全局单例一个进程创建一个就够SessionOptions里SetIntraOpNumThreads控制算子内并行度设成 CPU 物理核心数通常最优GetInputNameAllocated返回的是智能指针别手动 free。参数方面GraphOptimizationLevel::ORT_ENABLE_ALL会做常量折叠、算子融合等优化首次加载稍慢但推理更快生产环境建议开。3.2 C# 集成NuGet 包和本地 dll 怎么配合C# 项目一般用Microsoft.ML.OnnxRuntimeNuGet 包但如果你要指定用这个 zip 里的 dll需要手动处理。做法是NuGet 包提供托管层把 zip 里的onnxruntime.dll复制到输出目录覆盖默认的。using Microsoft.ML.OnnxRuntime; using Microsoft.ML.OnnxRuntime.Tensors; var session new InferenceSession(model.onnx); var inputTensor new DenseTensorfloat(new[] { 1, 3, 224, 224 }); var inputs new ListNamedOnnxValue { NamedOnnxValue.CreateFromTensor(input, inputTensor) }; using var results session.Run(inputs); foreach (var r in results) { Console.WriteLine(r.Name); }关键点C# 的InferenceSession默认从程序目录找onnxruntime.dll所以把 zip 里的 dll 放到bin\Debug\net6.0\下即可。如果报Unable to load DLL onnxruntime九成是 dll 没复制过去或者位数不对x64 项目必须用 x64 dll。3.3 Python 集成绕过 pip 直接用本地 dllPython 用户通常直接pip install onnxruntime但如果你想用这个特定版本的 dll可以手动指定import onnxruntime as ort import numpy as np # 查看可用 provider print(ort.get_available_providers()) # 创建会话指定 CPU 执行 sess ort.InferenceSession(model.onnx, providers[CPUExecutionProvider]) # 查看输入输出 for inp in sess.get_inputs(): print(inp.name, inp.shape, inp.type) # 推理 input_data np.random.randn(1, 3, 224, 224).astype(np.float32) outputs sess.run(None, {input: input_data}) print(outputs[0].shape)如果要用本地 dll 而不是 pip 自带的把 zip 里的 dll 所在目录加到PATH最前面再import onnxruntime。注意 Python 版本和 dll 位数必须匹配64 位 Python 配 x64 dll。4. 避坑与排查那些让我加班到凌晨的报错4.1 现象DLL load failed: 找不到指定的模块原因onnxruntime.dll依赖 Visual C 运行时系统缺vcruntime140.dll或msvcp140.dll。解决装Microsoft Visual C 2015-2022 Redistributable (x64)这是最常见的补救措施。装完重启终端再试。4.2 现象CUDA provider 加载失败回退到 CPU原因onnxruntime_providers_cuda.dll和onnxruntime_providers_shared.dll不在同一目录或者 CUDA/cuDNN 版本不匹配。解决确认两个 dll 同目录然后nvidia-smi看驱动支持的 CUDA 版本对照 onnxruntime 官方文档确认该版本要求的 CUDA 和 cuDNN 版本。版本不对就换对应的 onnxruntime 构建。4.3 现象推理结果和训练框架对不上原因输入预处理不一致比如归一化参数、通道顺序NCHW vs NHWC、数据类型float32 vs float16。解决用sess.get_inputs()打印期望的 shape 和 type逐项核对预处理代码。我一般会拿一张固定图片在训练框架和 onnxruntime 里各跑一次对比输出余弦相似度低于 0.999 就说明有问题。4.4 现象多线程下推理崩溃或结果错乱原因Ort::Session不是线程安全的多个线程共用一个 session 同时Run会出问题。解决要么每个线程创建自己的 session内存开销大要么加锁串行化Run调用。常见做法是用线程池加 session 池每个 session 绑定一个线程。4.5 现象模型加载慢首次推理卡顿原因图优化和内存分配在首次Run时才完成。解决加载后先用一个 dummy 输入跑一次 warmup把初始化开销提前。另外SetGraphOptimizationLevel设为ORT_ENABLE_ALL会增加加载时间但降低推理延迟按场景权衡。5. 进阶技巧用 ONNX Runtime 做动态批处理和性能验证5.1 动态 batch 的正确打开方式很多模型导出时 batch 维度是固定的但实际请求量是波动的。如果模型支持动态 batch导出时dynamic_axes设了 batch 维onnxruntime 可以自动处理不同 batch size# 假设模型支持动态 batch for bs in [1, 4, 8, 16]: dummy np.random.randn(bs, 3, 224, 224).astype(np.float32) out sess.run(None, {input: dummy}) print(fbatch{bs}, output shape{out[0].shape})如果模型不支持动态 batch就得导出时重新指定或者用固定 batch 加 padding。我一般会在导出阶段就把 batch 维设为动态省得后面改。5.2 性能验证别只看单次推理时间测性能不能只跑一次time要区分加载时间、首次推理时间、稳态推理时间。我习惯用下面这段脚本import time import numpy as np import onnxruntime as ort sess ort.InferenceSession(model.onnx, providers[CPUExecutionProvider]) input_data np.random.randn(1, 3, 224, 224).astype(np.float32) # warmup for _ in range(10): sess.run(None, {input: input_data}) # 稳态测试 times [] for _ in range(100): start time.perf_counter() sess.run(None, {input: input_data}) times.append(time.perf_counter() - start) times np.array(times) * 1000 # 转毫秒 print(f平均: {times.mean():.2f}ms, P50: {np.percentile(times, 50):.2f}ms, fP99: {np.percentile(times, 99):.2f}ms)关注 P99 而不是平均值因为线上超时往往发生在长尾。如果 P99 远高于 P50说明有线程竞争或内存分配抖动可以尝试调SetIntraOpNumThreads和SetInterOpNumThreads。5.3 一个我踩过的坑有次部署一个图像分类模型CPU 上 P50 只有 8ms但 P99 飙到 200ms。排查半天发现是SetIntraOpNumThreads设成了 16而机器只有 8 核线程切换开销反而拖慢了长尾。改成 8 之后 P99 降到 15ms。从那以后我每次设线程数都强制走一遍std::thread::hardware_concurrency()确认物理核心数再留一两个核给系统。希望这些经验帮到你少走点弯路。本文还有配套的精品资源点击获取