ONNX Runtime 作为跨平台机器学习推理的核心运行时,持续推动模型部署的灵活性和性能优化。v1.23.0 版本带来了多项重要改进,尤其在执行提供程序(Execution Provider,简称 EP)插件化、WinML 平台的动态下载机制、设备自动发现及若干关键 EP 的更新方面体现出明显的进步。对于希望在生产环境中获得更高性能、更佳可扩展性和更简单部署方案的工程师与研究人员而言,理解这些变化并据此调整部署策略尤为重要。 ONNX Runtime v1.23.0 引入了 Execution Provider Plugin API,这是一套面向第三方和内部团队的全新插件化基础设施。插件化 EP 的核心理念是将执行后端模块化,使其可以以插件形式独立开发、测试和发布。这一设计带来的好处包括更低的集成复杂度、更快的迭代速度以及更灵活的部署模型。
对于硬件厂商和第三方软件提供商而言,EP 插件 API 降低了将自家加速器整合到 ONNX Runtime 的门槛,开发者可以专注于优化算子与内核实现,而无需修改运行时的核心代码。 在 Windows 平台,尤其是 WinML 构建上,v1.23.0 新增了执行提供程序的动态下载与安装能力。该功能依赖于 Windows 11 25H2 或更高版本,并且目前仅在通过 Windows App SDK 分发的 C/C++/C# 构建以及很快发布的 onnxruntime-winml Python 包中可用。动态下载机制允许运行时在首次检测到合适硬件或配置时,自动从受信任源下载并注册相应的 EP,从而实现按需扩展。对于需要在多样化设备上部署推理服务的团队,这意味着可以统一分发带有核心功能的基础运行时,而将诸如 TensorRT、Vitis AI 等硬件专属 EP 作为后续可选组件下发,简化安装包体积并减少初始部署复杂度。 设备自动发现与 AutoEP 策略在本次更新中得到增强,ONNX Runtime 现在能够更智能地识别系统可用的计算资源并选择最合适的 EP。
在多设备、多加速器环境中,自动化策略可以显著降低人为配置错误,提高模型在异构平台上的性能利用率。结合动态 EP 下载,系统可以在运行时补全缺失的提供程序,从而实现从 CPU 切换到更高效加速器的无缝体验。 v1.23.0 还对执行与核心逻辑进行了优化,简化了 Windows 平台上的进程注销(shutdown)逻辑。在检测到进程正在终止的情形下,某些全局对象将不再被显式销毁。虽然这看似是一种资源未被正常释放的行为,但操作系统在进程结束时会回收全部内存,因而不会造成持久内存泄露。此变化的主要目的是减少在进程退出阶段出现的崩溃概率,对于需要频繁重启服务或短周期进程的应用场景尤为有利。
在执行提供程序生态上,v1.23.0 做出若干重要调整。ROCm EP 被移除出源码树,官方建议 AMD 硬件用户转向 Migraphx 或 Vitis AI 等替代 EP。NVIDIA 家族则新增了 TensorRT RTX EP,进一步提升了对 RTX 系列 GPU 的推理能力与延迟优化。Web 方向的改进包含将 EMDSK 从 4.0.4 升级到 4.0.8,WebGPU EP 中新增对 WGSL 模板的支持,使得在浏览器或 Web 平台上部署更加灵活和高效。 QNN EP 的 SDK 也在本次发布中升级,支持 QNN SDK 2.37,带来硬件兼容性与性能改进。对于依赖 Qualcomm 等移动 SoC 的实时推理场景,更新后的 QNN EP 能够更好地利用底层加速单元,从而在移动端实现更低的延迟与更好的能效表现。
KleidiAI 平台的贡献则主要体现在对 SGEMM、IGEMM 以及动态量化矩阵乘(Dynamic Quantized MatMul)等关键内核的性能增强,特别是在支持 SME2(Scalable Matrix Extension v2)的硬件上,Conv2D 等算子的吞吐量有显著提升。 随着生态与平台策略的演进,v1.23.0 同时宣布了一些即将生效的兼容性调整。下一个版本将停止提供 macOS 与 iOS 的 x86_64 二进制发行包,并将 macOS 的最低支持版本由 13.4 提升至 14.0。此外,Python 3.10 的 wheel 支持也将在后续发布中停止。对于仍运行老旧 macOS 系统或依赖 Python 3.10 的团队,建议提前规划升级路径,确保在受支持的平台与 Python 版本上持续获得性能优化与安全更新。 需要注意的是,本次发布也列出若干已知问题。
例如与 KleidiAI 相关的 build.py 更改可能导致交叉编译时构建失败。在将 v1.23.0 集成到复杂的 CI/CD 管道或交叉编译环境前,应先在测试环境中验证完整构建流程,必要时在社区或仓库中查找补丁与临时解决方案。 从迁移与实践角度来看,开发者在采用 v1.23.0 时应重点关注几个方面。首先,评估所部署平台是否满足 WinML 动态 EP 下载的条件,尤其是 Windows 11 25H2 的版本要求与应用分发方式。对于无法升级到 Windows 11 的环境,动态下载功能不可用,但仍可通过静态打包所需 EP 的方式实现相同功能。其次,若项目依赖 ROCm EP,需要提前规划迁移至 Migraphx 或 Vitis AI,并评估模型在替代 EP 上的兼容性与性能差异。
NVIDIA 用户可重点测试新加入的 TensorRT RTX EP,特别是在使用 RTX 系列 GPU 时比较其延迟与吞吐量收益。 针对 Python 用户,虽然 onnxruntime 的标准包仍然覆盖广泛场景,但计划发布的 onnxruntime-winml 包将为 WinML 平台带来额外功能,包含动态 EP 下载能力。Python 开发者在升级前应关注官方发布的 wheel 支持平台列表,确保所用 Python 版本在未来仍受支持。对于依赖较旧 Python 版本的项目,推荐提前制定升级计划或者锁定运行时与依赖库的版本以维持兼容性。 在性能调优方面,v1.23.0 的改进为工程师提供了更多优化空间。自动设备发现与 AutoEP 策略有助于在混合加速器环境中实现更合理的工作负载分配,而 KleidiAI 的内核优化则在特定硬件上显著提升计算密集型算子的性能。
建议在真实工作负载下对不同 EP 进行基准测试,比较 CPU、TensorRT、Vitis AI、Migraphx 等后端在延迟与吞吐量上的表现,从而选定最优的部署方案。对于延迟敏感型应用,优先考虑低延迟 EP,并在可能的情况下使用动态量化或混合精度技术降低推理时延。 安全与可维护性也应纳入部署考量。动态下载 EP 的机制虽然带来部署灵活性,但同时引入了供应链安全关注点。务必确认 EP 的下载来源为受信任渠道,并在企业环境中结合代码签名与完整性校验策略,避免潜在的恶意组件注入。CI/CD 管道中应加入自动化测试,覆盖模型功能正确性、性能回归与资源使用,以便在 EP 更新或运行时升级后快速发现问题。
社区与贡献方面,v1.23.0 展现了 ONNX Runtime 社区的广泛参与和协作精神。来自 Microsoft 内部团队与外部社区的开发者共同推动了多个关键特性与 EP 的更新。对于希望贡献代码或扩展 EP 的厂商与个人开发者,建议参考最新的插件 API 文档与示例,利用模块化插件机制开发自定义 EP,从而更容易地将专有硬件或优化库接入 ONNX Runtime 生态。 综合来看,ONNX Runtime v1.23.0 是一次兼顾扩展性与性能的迭代。插件化 EP API 与 WinML 的动态 EP 下载为未来生态带来了更大的灵活性,使得不同硬件厂商能够更快速地将加速能力投放到用户端。设备自动发现与核心执行优化则提升了在实际部署中的稳定性和性能表现。
然而,随着一些旧平台与 Python 版本的支持逐步退场,开发者需要为兼容性变更做好迁移准备。同时应关注已知的构建问题,特别是在交叉编译场景下的潜在风险。 对于正在评估或计划升级到 v1.23.0 的团队,建议先在测试环境中验证关键工作负载、对比不同 EP 的性能,并根据目标部署平台制定清晰的升级与回滚策略。对硬件厂商与加速器开发者而言,EP 插件 API 是一个极佳的入口,可以更低成本地将优化成果推向更大范围的用户。未来版本中,随着更多 EP 插件化生态的成熟与 Windows 动态分发机制的完善,ONNX Runtime 在边缘计算、云端推理与混合部署场景中的竞争力将持续增强。 无论是关注性能极致、追求部署便捷,还是希望在异构硬件环境中实现平滑扩展,ONNX Runtime v1.23.0 都提供了值得关注的工具与方向。
通过合理规划迁移路径、利用自动设备发现与自动化测试手段,并结合社区资源与文档,开发者可以更稳健地将最新特性纳入生产系统,从而在快速发展的推理生态中赢得更好的性能与更高的可维护性。 。
