深入解析 Polygraphy 的 ONNX-Runtime Runner：从参数组到推理执行链-北京尧图网络

深入解析 Polygraphy 的 ONNX-Runtime Runner从参数组到推理执行链【免费下载链接】TensorRTNVIDIA® TensorRT™ is an SDK for high-performance deep learning inference on NVIDIA GPUs. This repository contains the open source components of TensorRT.项目地址: https://gitcode.com/GitHub_Trending/tens/TensorRT本篇技术指南以 Polygraphy 文档体系中的 Runners 参数组文档为核心系统讲解 Polygraphy 如何通过命令行参数驱动 ONNX-Runtime 后端完成推理以及底层OnnxrtRunner的完整实现链路。读完本文你将掌握--runner onnxrt一类参数背后的参数组设计模式、--providers执行后端的选择方式以及 runner 与加载器Loader、比较器Comparator如何协同完成基准测试与精度比对。一、Runners 参数组在 Polygraphy 中的定位在 Polygraphy 的文档树中tools/Polygraphy/docs/tool/args/backend/onnxrt/toc.rst将 ONNX-Runtime 后端的命令行参数组织为两个主题loader创建 Inference Session与runner运行推理。本文聚焦的 runner.rst 文档对应的模块是polygraphy.tools.args其核心类是位于 tools/Polygraphy/polygraphy/tools/args/backend/onnxrt/runner.py 中的OnnxrtRunnerArgs。从源码结构看Polygraphy 的 args 体系采用「参数组Args Group→ 脚本生成add_to_script→ 执行器Runner/Loader」的分层设计每个后端都有对应的参数组类如OnnxrtRunnerArgs、OnnxrtSessionArgs这些类负责声明 CLI 参数、解析参数并把参数编译成可复现的 Python 脚本片段最终由真正的后端实现类如OnnxrtRunner执行推理。这种设计让同一套 CLI 参数既能直接运行又能导出为可复现的 Python 脚本。二、OnnxrtRunnerArgs参数组的骨架与职责OnnxrtRunnerArgs继承自BaseRunnerArgs定义于 tools/Polygraphy/polygraphy/tools/args/base.py。BaseRunnerArgs专门用于与 runner 相关的参数组它在add_to_script时会调用子类的add_to_script_impl并向脚本注册 runner 列表同时要求子类实现get_name_opt_impl来声明 runner 的人类可读名称与 CLI 选项名。OnnxrtRunnerArgs的类文档明确写道ONNX-Runtime Inference: running inference with ONNX-Runtime. Depends on: OnnxrtSessionArgs也就是说该参数组负责使用 ONNX-Runtime 运行推理并且依赖OnnxrtSessionArgs——Session 的创建完全由加载器参数组负责runner 参数组本身不直接声明任何新增 CLI 参数而是把 Session 参数组生成的加载器接入自己的执行管线。这正是 Polygraphy 参数组依赖注入的典型体现get_name_opt_impl()返回元组(ONNX-Runtime, onnxrt)声明了该 runner 在 CLI 上对应的选项名据此可以推断在支持--runner选项的命令中可通过onnxrt关键字选择此 runneradd_to_script_impl()向脚本导入OnnxrtRunner来自polygraphy.backend.onnxrt并调用OnnxrtSessionArgs.add_to_script(script)先生成构建 Session 的代码再把该结果作为OnnxrtRunner的构造参数注入最终通过script.add_runner(...)注册到 runner 列表中。这一小段代码体现了 Polygraphy 的核心理念runner 不关心模型如何加载只关心拿到一个可用的 Session 后如何执行推理从而让同一份推理逻辑可以无缝换用 TensorRT、ONNX-Runtime、PyTorch 等不同后端。三、依赖参数组 OnnxrtSessionArgs 与 --providers 参数由于OnnxrtRunnerArgs依赖OnnxrtSessionArgs理解 runner 就必须理解 Session 是如何被参数化的。OnnxrtSessionArgs位于 tools/Polygraphy/polygraphy/tools/args/backend/onnxrt/loader.py其职责文档为 ONNX-Runtime Session Creation: creating an ONNX-Runtime Inference Session依赖OnnxLoadArgs与ModelArgs。它声明了 ONNX-Runtime 后端最关键的 CLI 参数--providers, --execution-providers providers...参数说明原文为A list of execution providers to use in order of priority. Each provider may be either an exact match or a case-insensitive partial match for the execution providers available in ONNX-Runtime. For example, a value of cpu would match the CPUExecutionProvider.要点如下按优先级排序--providers接受一个列表ONNX-Runtime 会按给出的先后顺序尝试启用执行提供程序Execution Provider支持大小写不敏感的模糊匹配每个值既可以精确匹配如CPUExecutionProvider也可以部分匹配如cpu会命中CPUExecutionProvider这对习惯缩写如CUDA、Tensorrt、cpu的使用者非常友好默认值为 None未指定时使用 ONNX-Runtime 自身的默认 EP 选择逻辑。在add_to_script_impl中该参数组会依据OnnxLoadArgs.must_use_onnx_loader()决定模型来源若需要走 ONNX 加载器则调用OnnxLoadArgs.add_to_script(script, serialize_modelTrue)生成可能被序列化的模型字节流否则直接使用ModelArgs.path指定的模型路径随后导入SessionFromOnnx并把onnx_name与providers组合为一次SessionFromOnnx(...)调用注册到脚本的 loader 列表。也就是说--providers的最终归宿是polygraphy.backend.onnxrt.SessionFromOnnx的providers参数。此外OnnxrtSessionArgs还提供编程式入口load_onnxrt_session(modelNone)它通过args_util.run_script动态执行自身生成的脚本并返回一个onnxruntime.InferenceSession实例方便在 Python API 场景下直接复用相同的 CLI 参数逻辑。四、底层执行器 OnnxrtRunner推理的实现原理参数组最终构造的是 tools/Polygraphy/polygraphy/backend/onnxrt/runner.py 中的OnnxrtRunner。它继承自polygraphy.backend.base.BaseRunner类文档一句话概括其定位Runs inference using an ONNX-Runtime inference session.其构造签名与生命周期如下4.1 构造与激活def __init__(self, sess, nameNone): super().__init__(namename, prefixonnxrt-runner) self._sess sesssess可以是onnxruntime.InferenceSession实例也可以是返回 Session 的可调用对象例如SessionFromOnnx(...)这个 loader 工厂。这与OnnxrtRunnerArgs.add_to_script_impl中把 loader 生成结果传给 runner的流程完全对应。Session 的实际创建发生在activate_impl()中util.check_called_by(activate) def activate_impl(self): self.sess, _ util.invoke_if_callable(self._sess)util.invoke_if_callable负责如果是可调用对象就调用它否则原样返回从而统一处理直接传 Session与传 loader 工厂两种用法。这也解释了测试中OnnxrtRunner(SessionFromOnnx(model.loader))之所以成立——传入的 loader 会在 runner 被activate()时惰性求值。4.2 输入元数据获取util.check_called_by(get_input_metadata) def get_input_metadata_impl(self): meta TensorMetadata() for node in self.sess.get_inputs(): meta.add(node.name, dtypeDataType.from_dtype(node.type, onnxruntime), shapenode.shape) return meta该实现遍历sess.get_inputs()把每个输入张量的名称、数据类型经DataType.from_dtype从 ONNX-Runtime 的类型字符串转换为 Polygraphy 的统一类型与形状组装成TensorMetadata。Polygraphy 的比较器与参数化流程正是依赖这份元数据来生成或校验输入数据确保 runner 之间可比对。4.3 推理执行 infer_implutil.check_called_by(infer) def infer_impl(self, feed_dict): use_torch any(util.array.is_torch(t) for t in feed_dict.values()) feed_dict {name: util.array.to_numpy(t) for name, t in feed_dict.items()} start time.time() inference_outputs self.sess.run(None, feed_dict) end time.time() out_dict OrderedDict() for node, out in zip(self.sess.get_outputs(), inference_outputs): out_dict[node.name] out if not use_torch else util.array.to_torch(out) self.inference_time end - start return out_dict这一实现有几个值得注意的细节PyTorch 张量透明支持若feed_dict中存在任意torch.Tensor则输出也会被转回 PyTorch 张量util.array.to_torch否则统一转 NumPy。注释明确说明to_numpy()与to_torch()在可能的情况下是零拷贝的单次 run 取全部输出self.sess.run(None, feed_dict)的None表示请求 ONNX-Runtime 返回所有输出随后按sess.get_outputs()的顺序与输出结果一一对应组装成OrderedDict自动计时推理耗时被记录到self.inference_time属性这是 Polygraphy 报告Reporting与延迟统计的数据来源也是基准测试能力的基础方法约定infer_impl不应被直接调用而应通过基类infer()调用基类会把未识别参数转发给实现方法。4.4 反激活util.check_called_by(deactivate) def deactivate_impl(self): del self.sessdeactivate_impl释放 Session 引用配合上下文管理器协议with OnnxrtRunner(...) as runner:完成资源生命周期管理。五、测试验证runner 行为的事实依据仓库测试对上述实现给出了直接验证主要测试位于 tools/Polygraphy/tests/backend/onnxrt/test_runner.pyOnnxrtRunner(None, nameNAME)验证了自定义 name 与prefixonnxrt-runner的命名机制大量用例采用with OnnxrtRunner(SessionFromOnnx(model.loader)) as runner:的上下文管理器形态验证loader 惰性求值 activate/deactivate 生命周期通过runner.get_input_metadata()、runner.infer(feed_dict)等调用验证元数据提取与推理输出的正确性。此外tools/Polygraphy/tests/backend/base/test_runner.py 与 tools/Polygraphy/tests/comparator/test_comparator.py 将OnnxrtRunner与SessionFromOnnx、Comparator.run(...)组合使用例如Comparator.run([OnnxrtRunner(SessionFromOnnx(onnx_loader))])验证了它在多后端精度比对场景中的核心角色。而参数组层面的测试位于 tools/Polygraphy/tests/tools/args/backend/onnxrt/test_loader.py覆盖OnnxrtSessionArgs与ModelArgs、OnnxLoadArgs的依赖组合。六、实战场景如何组合使用结合上述机制在 Polygraphy 中让 ONNX-Runtime 参与推理与比对的典型路径有两条命令行方式在支持 runner 选择的命令如run中通过--runner onnxrt一类选项对应get_name_opt_impl返回的onnxrt关键字选中 ONNX-Runtime 后端再配合--providers CUDA cpu指定 EP 优先级即可让 ONNX-Runtime 在指定设备上执行推理并参与比较。Python API 方式直接构造from polygraphy.backend.onnxrt import OnnxrtRunner, SessionFromOnnx from polygraphy.comparator import Comparator runner OnnxrtRunner(SessionFromOnnx(model.onnx, providers[CUDA, cpu])) results Comparator.run([runner])这正是测试用例中反复出现的组合模式也是 Polygraphy 同一份 runner 接口、不同后端实现设计的直接体现OnnxrtRunner与 TensorRT、PyTorch 等 runner 遵循同一套activate / get_input_metadata / infer / deactivate契约从而可以被 Comparator 统一调度实现跨后端的精度与性能对比。七、总结围绕 Runners 参数组文档本文完整梳理了 Polygraphy 中 ONNX-Runtime 推理能力的全链路OnnxrtRunnerArgs作为参数组外壳负责把 CLI 选择转化为脚本与 runner 注册OnnxrtSessionArgs通过--providers控制执行提供程序的优先级与匹配规则OnnxrtRunner则承担 Session 激活、输入元数据提取、带计时的推理执行与资源释放。理解这条链路你就掌握了 Polygraphy 参数组架构的通用范式——任何后端的 runner 参数组都遵循同样的参数声明 → 脚本生成 → 执行器注入模式这也是 Polygraphy 能够统一调度多后端做基准测试与精度比对的根基所在。【免费下载链接】TensorRTNVIDIA® TensorRT™ is an SDK for high-performance deep learning inference on NVIDIA GPUs. This repository contains the open source components of TensorRT.项目地址: https://gitcode.com/GitHub_Trending/tens/TensorRT创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考

深入解析 Polygraphy 的 ONNX-Runtime Runner：从参数组到推理执行链

相关推荐

draw.io 桌面版：6 种格式一条命令批量导出，三平台免费的画图指南

LangChain4j ChatMemory 实战指南：会话记忆抽象、淘汰策略与持久化

Dart Skills CLI：面向交付流水线的AI协作者

更多资讯

Friend 项目内存权限管控：app/key 级内存授权（Memory App/Key Grants）架构与实践

Nightingale 集成中心实战：基于 Categraf 的 BIND DNS 服务器监控与告警方案

douyin-downloader完整教程：快速掌握无水印视频下载与主页批量归档

仿抖音用户作品数据解密：douyin 项目中 user_video_list/*.md 的数据结构、加载链路与生成脚本

BG/NBD模型实战：用Python模拟验证客户终身价值(CLV)预测

电磁-热耦合仿真：Maxwell与Steady-State Thermal联合求解完整指南

今日更新

基于高阶循环谱的MPSK载波频率估计与MATLAB实现

MiniPdf方：.NET开源Office转PDF的高效解决方案

Solon AI v3.10：Java全栈智能体开发框架解析

本周精选

AI驱动的自动化专利分析平台技术解析

LeetCode-Go 题解：1252. Cells with Odd Values in a Matrix（奇数值单元格计数）双解法剖析

在线答疑系统Java毕设实战：Spring Boot前后端分离与状态流转

本月热门

基于YOLO的焊缝缺陷检测：从数据标注到工业部署全流程实践

分布式服务的决策记录

创业产品的首版范围

读完文章，想聊聊您的网站？