1. ONNX 到底解决什么问题先抛一个比较直白的类比ONNX 在大模型和 AI 推理生态里的角色有点像音频领域的 MP3或者文档领域的 PDF。你不需要关心它背后是哪个软件做的、在什么系统上跑的只要格式统一换个环境依然能打开。ONNX 本质上做的就是这件事——把各种深度学习框架训练出来的模型转换成一个统一的、标准化的计算图描述格式。这句话听起来很简单但往深了说它解决的是 AI 工程化里最头疼的格式孤岛难题。在 ONNX 出现之前PyTorch 训练出来的模型只能靠 PyTorch 自己推理TensorFlow 训练的模型也只能在自己生态里跑Caffe 的模型更是出了名的难迁移。如果业务方用的是 Java 后端想直接调用一个 PyTorch 模型要么用 PyTorch Serve 单独起一个 Python 服务要么花大力气把模型重写一遍。这两种方案在工程上的成本都不低前者引入了额外的进程通信和运维负担后者简直是一场灾难——深度学习模型动辄几十上百层逐层复现网络结构任何一个参数对不上输出结果就完全不对。ONNX 把这个问题拆成了两个阶段训练阶段继续用 PyTorch 或 TensorFlow得到模型后导出为 ONNX 格式的中间文件推理阶段再用 ONNX Runtime 或者转成 TensorRT、OpenVINO 等格式执行。训练和推理解耦之后整个架构的灵活性一下就上来了——模型训练团队不用关心线上部署环境是 Java 还是 C部署团队也不用关心模型是用什么框架训出来的。大模型时代到来之后ONNX 的存在感不但没有减弱反而变得更重要了。现在做 LLM 推理大家满脑子都是 vLLM、TensorRT-LLM、Ollama 这些名字但它们内部其实都很重视 ONNX 这条链路。原因在于大模型的部署形态已经变得极其复杂既要跑在云端 A100/H100 上也要跑在国产加速卡上还要兼顾 PC 端的 CPU 环境甚至移动端。一个统一的中间表示能帮你省下大量重复适配的功夫。这篇内容我会从 ONNX 的核心设计讲起然后带你完整走一遍模型转换到推理的实操流程最后聊一聊在大模型和各类推理引擎并存的局面下ONNX 到底应该放在什么位置。无论你是刚接触模型部署的新手还是正在折腾模型迁移的老手应该都能从中找到点有用的东西。2. ONNX 的核心设计计算图、算子与格式细节2.1 ONNX 模型文件里到底装了什么拿一个 .onnx 文件在编辑器里打开或者用 Netron 可视化你会看到它本质是一个 protobuf 序列化的数据文件。里面的结构分几大块计算图Graph、算子集合Opset、模型元信息以及可选的权重参数。计算图是 ONNX 的核心。它描述的是数据从输入到输出的流动过程图中的每个节点Node代表一个算子操作比如 Conv、MatMul、Add 这些边Edge代表张量Tensor在算子之间如何传递。每个节点都定义了输入张量的名称、输出张量的名称以及算子自身的属性参数。整个图结构可以看成一张有向无环图DAG数据从输入节点流入经过一层层算子变换最终从输出节点流出。这里要特别强调一下ONNX 存的不是训练好的神经网络对象而是一个逐个算子展开的静态计算流程。PyTorch 里的 nn.Module 是面向训练设计的里面包含了很多训练特有的逻辑比如 dropout 的随机掩码、BN 层的滑动均值更新而 ONNX 只关心推理路径上的算子序列。这也是为什么导出时经常要指定 opset_version——不同版本的算子集合支持的能力不同新版本通常会增加新算子或修改旧算子的行为描述。权重参数也直接打包在 .onnx 文件里。PyTorch 模型的 state_dict 是分散的参数集合但 ONNX 会按照计算图的拓扑顺序把权重组织起来作为图的初始化器Initializer内嵌在文件里。这也是 .onnx 文件通常比原模型更大的原因之一但好处是不用额外管理权重文件一个文件拿过去就能直接跑推理。2.2 算子集合Opset和 IR 版本为什么重要理解 Opset 是 ONNX 绕不开的一关。ONNX 的算子集合是版本化的每个版本的算子集合新增或修改了一些算子定义。比如 opset 11 引入了一些动态 shape 相关的修改opset 13 优化了 Reduce 系列算子的行为opset 17 之后对字符串和复数类型的支持更完善。导出模型时指定的 opset_version 决定了模型使用的是哪个版本的语义。这个问题在实践中非常关键因为它直接影响模型的可移植性。如果你在 opset 11 下导出模型遇到一个 opset 13 才支持的新算子就得想办法绕过或者升级 opset 版本。反过来如果你用了很新的 opset但推理端的 ONNX Runtime 版本较老可能也会因为不支持新的算子集合而报错。IR 版本Intermediate Representation version是另一个容易忽略的配置。它定义了模型文件本身的格式规范比如数据类型的表示方式、图结构的序列化方式等。IR 版本和 opset 版本需要匹配导出工具通常会帮你处理好但如果你手工修改过模型文件或者跨版本转换过就要多留意一下这两者的兼容性。实践中我的建议是除非有特殊算子需求否则不要追求过新的 opset。尽量选择一个主流推理框架都已经兼容的版本比如 11、13、17 这几年用的都比较多。太激进地使用新版本 op set往往会在国产加速卡或者边缘设备的推理引擎上踩到兼容性坑。2.3 Netron看 ONNX 模型的必备工具接触 ONNX 之后Netron 应该是使用频率最高的可视化工具了没有之一。它是一个开源的神经网络模型可视化工具支持 ONNX、TensorFlow Lite、Keras、CoreML 等多种格式。把 .onnx 文件拖进去就能看到完整的计算图结构、每个节点的输入输出 shape、权重参数的维度甚至能直接查看某个节点的属性值。调试模型导出问题时Netron 的价值特别大。比如你发现导出的模型推理结果不对先用 Netron 打开看一遍构图是否符合预期能快速定位是不是某个算子的连接关系搞错了或者权重有没有对调。还有一些情况下PyTorch 里看起来正常的操作导出后可能会被拆成多个细粒度的算子组合因为 ONNX 的算子粒度往往比 PyTorch 的层粒度更细Netron 里一眼就能看出来这些组合是否合理。Netron 还有网页版和桌面版网页版直接上传本地文件就能用桌面版支持更大的模型文件。大模型场景下动辄几个 GB 的 .onnx 文件在网页版里加载会比较吃力建议直接用桌面版会更顺手一些。3. 实操一把把 PyTorch 模型转换成 ONNX3.1 准备环境和依赖开始之前先把环境准备好。最基础的三件套是 PyTorch、ONNX 和 ONNX Runtime。如果后面要可视化检查可以再装一个 netron 的 Python 包这样可以直接在代码里启动可视化界面。我建议用 Python 3.8 以上的环境3.10、3.11 都没问题PyTorch 装 2.x 版本ONNX 装 1.14 以上ONNX Runtime 装最新稳定版。如果涉及到量化后面还需要 onnxruntime 的扩展包这个先按下不表后面讲量化的时候具体说。import torch import torch.nn as nn # 定义一个简单的 CNN 模型用于演示 class SimpleCNN(nn.Module): def __init__(self): super().__init__() self.conv1 nn.Conv2d(3, 16, kernel_size3, padding1) self.conv2 nn.Conv2d(16, 32, kernel_size3, padding1) self.fc nn.Linear(32 * 8 * 8, 10) def forward(self, x): x torch.relu(self.conv1(x)) x torch.max_pool2d(x, 2) x torch.relu(self.conv2(x)) x torch.max_pool2d(x, 2) x x.view(x.size(0), -1) x self.fc(x) return x这里要注意PyTorch 从 2.0 开始默认是动态图模式导出 ONNX 时需要把模型切换到推理模式并且用 torch.no_grad() 包裹推理过程。另外模型的 forward 方法里如果有 if 分支或者 Python 层的动态逻辑导出时也要格外小心ONNX 只能捕捉到实际执行过的路径。3.2 导出 ONNX 的关键参数设置PyTorch 导出 ONNX 的核心接口是 torch.onnx.export。这个方法看起来很简单但参数细节决定了导出成败。model SimpleCNN() model.eval() # 切换到推理模式 dummy_input torch.randn(1, 3, 32, 32) torch.onnx.export( model, dummy_input, simple_cnn.onnx, export_paramsTrue, opset_version13, do_constant_foldingTrue, input_names[input], output_names[output], dynamic_axes{input: {0: batch_size}, output: {0: batch_size}} )重点说几个参数背后的逻辑export_paramsTrue 表示把权重参数一并导出到 ONNX 文件里。如果你设置成 False导出的模型就不带权重只有图结构这在某些特殊场景比如只在特定框架里加载结构后手动灌权重下有用但常规推理场景请务必保持 True不然后期用起来会非常痛苦。do_constant_foldingTrue 会在导出时对常量子图进行折叠优化。比如某个算子只做了纯常量的数学计算导出的过程中直接就把结果算好写进文件推理时就不用再重复计算了。默认是开启的我建议保持开启可以让模型更精简推理速度也有一定提升。dynamic_axes 是动态维度设置。上面代码里把 batch_size 维度设成了动态意味着导出的模型在推理时可以接受任意 batch 大小的输入而不只是固定为 1。这个配置在很多场景下都很有必要但要注意动态维度会限制某些推理引擎的优化效果比如 TensorRT 对动态 batch 的优化通常比静态 shape 差一些。如果你的业务场景里 batch size 是固定的就不要全部设成动态。检查一下导出的模型是否正常可以用 ONNX 自带的校验工具import onnx model onnx.load(simple_cnn.onnx) onnx.checker.check_model(model) print(onnx.helper.printable_graph(model.graph))onnx.checker.check_model 会检查模型结构是否合法包括图结构是否完整、节点连接是否正确、数据类型的定义是否符合规范等。如果这一步能通过说明模型本身在格式层面没有问题。3.3 ONNX Runtime 推理验证导出完成后用 ONNX Runtime 跑一遍推理对比 PyTorch 的输出结果这是检验转换是否正确最直接的方法。import onnxruntime as ort import numpy as np # 创建 ONNX Runtime 推理会话 sess_options ort.SessionOptions() sess_options.graph_optimization_level ort.GraphOptimizationLevel.ORT_ENABLE_ALL session ort.InferenceSession(simple_cnn.onnx, sess_optionssess_options) # 准备输入数据 input_data np.random.randn(1, 3, 32, 32).astype(np.float32) # 获取输入输出名称 input_name session.get_inputs()[0].name output_name session.get_outputs()[0].name # 推理 output session.run([output_name], {input_name: input_data})[0] print(ONNX Runtime 输出 shape:, output.shape) # 同样的输入用 PyTorch 推理对比 with torch.no_grad(): torch_output model(torch.from_numpy(input_data)).numpy() print(最大误差:, np.max(np.abs(output - torch_output)))这里设置的 graph_optimization_level 就是 ONNX Runtime 的优化等级。ORT_ENABLE_ALL 表示启用全部图优化包括算子融合、布局优化、常量折叠等。推理引擎在加载模型时会按照这个优化级别对模型进行优化然后再执行。最大误差控制在 1e-5 级别以内就说明转换没有问题。如果误差很大通常有几个可能的原因一是模型里包含训练特有的层比如 BN 层在训练和推理模式下行为不同导出时忘记切到 eval 模式二是有一些自定义算子没有被 ONNX 支持导出工具用多个基础算子拼凑代替时引入了精度损失三是对动态 shape 的处理有偏差。这种误差对比在模型迁移场景下是必做的一步不要偷懒跳过。3.4 一个容易踩的坑控制流的导出如果你处理的是 LLM 这类大模型或者任何在 forward 方法里包含 if 条件判断、循环等控制流的模型导出 ONNX 时就要特别注意了。PyTorch 的 torch.onnx.export 默认走的是 tracing 路线——它只记录实际执行过的算子路径不会把 if 分支的另一个分支也导出到 ONNX 图里。举个例子如果你的模型中有def forward(self, x): if x.shape[1] 10: x self.layer_a(x) else: x self.layer_b(x) return x用 dummy_input 导出时dummy_input 的 shape 决定了哪一个分支会被追踪。如果你设置一个 shape 为 (1, 12, ...) 的 dummy_input导出的模型里就只有 layer_a 这个分支。线上推理时如果输入变成 (1, 5, ...)模型根本不知道还有 layer_b 这个分支的存在结果就会出问题。这种情况下有两种解决思路。一种是通过 torch.onnx.is_onnx_export() 这类条件判断接口在导出时手动控制走哪个分支另一种是把静态的 if 判断改成动态的可导算子让 ONNX 图天然支持不同 shape 的输入。对于大模型来说很多部署工具比如 HuggingFace Optimum已经帮你把这些转换细节处理好了但如果你是自己手写导出逻辑这块一定要留意。4. 不只是转换ONNX 模型的优化手段4.1 模型精简去掉冗余节点和算子融合拿到一个 ONNX 模型之后第一件事不是直接上推理引擎而是先看看模型有没有优化的空间。ONNX 模型本身就有一些优化手段常见的有这么几类第一类是节点精简。深度学习模型在训练框架里定义的时候为了方便开发者阅读和调试结构往往比较冗余。比如某个算子做了 AB然后又有一个算子做了结果乘 C导出成 ONNX 后可能是一个 Add 节点加一个 Mul 节点。但如果推理时这个计算只被用一次合并成一个 Fused 算子比如 Scale就能省掉一次内存读写的开销。这类优化 ONNX Runtime 在加载模型时会自动做一部分不需要你手动干预。第二类是算子融合。这是推理优化的大头。常见的融合模式包括 ConvBN 融合、ConvReLU 融合、MatMulAdd 融合等。这些融合能大幅减少访存次数因为中间结果不用再写回内存再从内存读出来了。ONNX Runtime 和 TensorRT 都在做这件事只是策略和粒度不一样。第三类是精度裁剪。把模型里的数据类型从 FP32 改成 FP16 或 INT8。这个改动可以在 ONNX 模型层面做也可以在推理引擎层面做。ONNX 本身支持不同数据精度的描述但实际转换时需要特别注意量化工具的选择和数值范围的控制。4.2 量化INT8 量化如何加快推理速度提到 ONNX 模型的优化量化一定是最受关注的话题之一。量化Quantization的本质是用更低精度的数据类型去近似表示原模型的权重和激活值从而换取更低的计算开销和更小的内存占用。最常见的量化是 INT8 量化把模型的权重从 FP32 压缩到 INT8模型大小直接缩小到原来的四分之一推理延迟通常能降低一半以上内存带宽的压力也大幅缓解。ONNX Runtime 的量化方案分两种基础路线静态量化和动态量化。动态量化Dynamic Quantization是在推理时动态计算激活值的量化范围。它不需要预先准备校准数据集使用起来最省事但推理速度提升的幅度相对有限更适合 CPU 环境下的部署场景。具体做法是用 onnxruntime.quantization 模块里的 quantize_dynamic 接口from onnxruntime.quantization import quantize_dynamic, QuantType model_path simple_cnn.onnx quantized_model_path simple_cnn_int8.onnx quantize_dynamic( model_path, quantized_model_path, weight_typeQuantType.QInt8 )静态量化Static Quantization需要先用一批有代表性的输入数据校准数据集去观察激活值的分布范围然后基于这个范围把激活值也量化成 INT8。这个过程类似一门综合课的期末考试——考试范围量化参数是提前划定的考试时按这个范围去答题推理。静态量化的加速效果比动态量化更明显尤其在 GPU 上但操作流程更复杂而且校准数据集的选择直接影响量化后的精度损失。如果校准数据分布和线上真实数据差异太大量化后的模型精度可能崩得一塌糊涂。从实战经验来看INT8 量化有两种情况特别值得做一种是在 CPU 上部署目标机器没有强 GPU量化是提升吞吐最直接的手段另一种是大模型场景模型文件动辄好几 GB量化后能极大缓解显存和内存压力配合 KV Cache 优化还能进一步扩大并发能力。量化不是没有代价的。最明显的问题就是精度损失。对分类、检测这类任务INT8 量化通常能控制在可接受的范围top-1 准确率下降 1% 以内但对生成式模型或者对数值敏感的任务比如车牌识别、OCR 识别量化后的结果可能出现字符识别错误率升高的问题。我做过的项目里出现过车牌识别模型量化后字符5频繁被识别成6的情况。所以量化后的模型一定要做充分的精度回测而不是只看推理速度。4.3 ONNX 转 TensorRTGPU 部署的进阶路线如果目标部署环境是 NVIDIA GPU那 ONNX 模型的下一步通常不是直接用 ONNX Runtime而是转成 TensorRT 引擎。TensorRT 是 NVIDIA 针对自家 GPU 做深度优化的推理引擎里面有很多黑魔法级的优化比如 kernel 自动调优、显存复用、低精度推理等。ONNX 转 TensorRT 有两种常见方式一种是用 TensorRT 自带的 trtexec 命令行工具另一种是在代码里用 TensorRT 的 ONNX Parser 直接解析。比较简单的做法是用 trtexectrtexec --onnxsimple_cnn.onnx \ --saveEnginesimple_cnn.engine \ --fp16--fp16 表示开启 FP16 精度推理这种配置在 Ampere 及以上架构的 GPU 上效果尤其明显。TensorRT 转换时会有一个构建Build阶段这个阶段会分析 ONNX 图结构、自动选择最优的 kernel 实现还可能做一些层融合的优化。构建过程可能比较慢几次甚至十几分钟都有可能但构建好的 engine 文件后续加载推理很快。有一个值得注意的点是TensorRT 的 engine 文件和硬件绑定。用 A100 构建的 engine 不能直接拿到 T4 上跑反之亦然。所以你在训练机上构建的 TensorRT 引擎不能直接部署到生产环境的 GPU 上必须在目标 GPU 型号相同的环境下重新构建。这也是 ONNX 这类中间格式存在的意义之一——ONNX 可以跨硬件迁移TensorRT 引擎不行。YOLO12 ONNX 转 TensorRT 的案例现在社区里讨论度很高核心流程和我上面写的完全一致YOLO 模型导出 ONNX然后 trtexec 转 TensorRT再用 C/Python 在 5070 这类显卡上做推理测试。需要注意的点主要是 YOLO 的输出层在导出 ONNX 后可能会包含一些非标准算子需要提前处理或者使用专用的部署仓库。5. 推理引擎选型ONNX Runtime、vLLM、Ollama 怎么选5.1 一张表看懂主流推理引擎的定位现在模型推理引擎非常多光是把名字列出来就能吓到新手。但从使用场景上分其实可以比较清晰地分成几类。下面用表格来做一个整理推理引擎适用场景优势注意事项ONNX Runtime通用模型部署、跨平台生态成熟支持多端CPU/GPU/移动端API 简洁极致性能不如专用引擎TensorRTNVIDIA GPU 高性能推理推理速度极快GPU 利用率高engine 和硬件绑定构建时间长OpenVINOIntel CPU/GPU/VPU 推理Intel 硬件优化好边缘部署常用非 Intel 硬件优势不明显vLLM大模型LLM在线推理PagedAttention 省显存吞吐高主要服务 LLM对其他模型支持有限Ollama本地一键部署大模型使用门槛极低拿来就能跑定制化程度低适合快速体验TensorFlow Lite移动端/嵌入式设备模型小端侧优化成熟主要服务 TFLite 模型ONNX Runtime 是目前覆盖面最广的因为它在 ONNX 模型上做了大量优化而且支持直接加载 ONNX 模型不需要二次编译和转换。你在开发阶段用 PyTorch 训练导出 ONNX 后直接用 ONNX Runtime 跑推理链路是最短的。TensorRT 适合对性能有极致要求的场景。如果在生产环境上跑的是固定 GPU 型号并且模型结构比较稳定不会频繁改动值得花时间转成 TensorRT。反过来说如果模型迭代频繁每次都要重新构建 TensorRT 引擎那维护成本会比较高性价比就低了。vLLM 和 Ollama 是大模型时代的产物。vLLM 做了大量的显存优化PagedAttention 机制能显著提升 LLM 的并发处理能力适合做在线 API 服务。Ollama 胜在零门槛本地机器装好之后直接拉模型就能跑很多人在自己电脑上体验大模型就是这个方案。Ollama 底层其实也集成了多个运行时引擎模型格式也不止 ONNX 一种但对用户来说是透明封装好的。5.2 ONNX 在其中的真实位置明白了这些引擎的定位之后ONNX 的位置就很清晰了它不是一个和 TensorRT、vLLM 直接竞争的推理引擎而是一个中间表示层。你可以把它理解为通用语言TensorRT 是专用高速工具vLLM 是大模型专用服务器。在理想的技术架构里训练框架负责把模型转成 ONNX 或者其他中间格式比如 Safetensors、GGUF推理引擎再从这个中间格式转换成自己最擅长的执行方式。但有一点必须说明白ONNX 并不是大模型场景中唯一的中间格式甚至在很多主流 LLM 部署方案里ONNX 并不是首选路径。HuggingFace 生态更常用的是 Safetensors PyTorch 原生推理本地 CPU 推理方案更常用的是 GGUF配合 llama.cppNVIDIA 的方案则倾向于直接把 PyTorch 模型转成 TensorRT-LLM 适配的格式通常是按层存权重而不是一个完整计算图。那 ONNX 的优势在哪里就在于它同时具备通用性和可针对性。通用性体现在 ONNX 是一个开放标准不受单一厂商控制而且支持范围极广。你写一个模型导出 ONNX 后可以在 Windows 上用 ONNX Runtime 跑在 Linux 上用 TensorRT 跑在浏览器里用 WebAssembly 跑在 iPhone 上用 CoreML 导入跑。一套模型四处部署这个收益在跨端场景里是无法忽略的。针对性体现在 ONNX 已经在上层工具链上衍生出了一整套生态。比如 HuggingFace 的 Optimum 可以直接导出 ONNX 格式的模型并且配合 ONNX Runtime 做加速推理很多 transformer 类模型都有现成的 ONNX 导出教程。这意味着你已经训练好的 BERT、GPT、ViT 这类模型可能不需要写一行额外的代码就能获得 ONNX 带来的部署便利性。所以我的选择建议是如果项目是多端部署PC Web 移动端或者后端开发团队主要使用 Java/C# 这类非 Python 语言那 ONNX 是必需的中间桥梁。如果项目纯粹是 LLM 的云端在线服务且显卡型号固定、追求极致吞吐那直接走 vLLM 或者 TensorRT-LLM 路线可能更合适ONNX 作为兜底方案存在即可。5.3 多语言部署的典型场景Java 调用 ONNX 模型在众多实际需求中Java 调用 ONNX 模型是非常高频的一个场景。原因在于很多公司的后端服务体系是 Java 写的模型推理如果依赖 Python 服务就需要单独部署和管理一个 Python 进程增加了运维的复杂度。而 ONNX Runtime 官方提供了 Java 绑定可以直接在 JVM 里面加载 ONNX 模型并执行推理这样整个推理链路就能完全糅合进 Java 后端服务里。以车牌识别为例这个场景的完整链路一般是先用 PP-OCRv6PaddleOCR 的第六版训练或者下载一个文字检测识别模型转成 ONNX 格式然后用 ONNX Runtime Java API 去加载。之所以 PP-OCRv6 能转成 ONNX是因为 PaddleOCR 的 PaddlePaddle 框架本身支持导出 ONNX导出的 ONNX 模型可以直接用 ONNX Runtime 的 Java API 跑。ONNX Runtime 的 Java API 用法也很直接import ai.onnxruntime.*; public class OnnxInference { public static void main(String[] args) throws Exception { OrtEnvironment env OrtEnvironment.getEnvironment(); OrtSession session env.createSession(simple_cnn.onnx, new OrtSession.SessionOptions()); try (OrtSession.Result result session.run(env.createTensor(inputData)) ) { // 处理结果 OnnxTensor output (OnnxTensor) result.get(0); float[][] outputData (float[][]) output.getValue(); } } }这样做的好处是显而易见的不需要跨进程通信不需要额外部署 Python 服务Java 后端直接和模型推理在同一个 JVM 进程里完成延迟更低、运维更简单。这也是 ONNX 在工业界落地时最核心的价值之一。很多传统互联网公司的 CV 类业务OCR、目标检测、图像分类都通过这种方式把模型推理融入 Java 微服务体系。6. 大模型时代的 ONNX从图像分类时代到LLM 时代6.1 大模型时代的部署形态变化大模型尤其是 LLM和传统 CNN 模型最大的区别在于推理模式的改变。传统模型是一次前向传播出结果输入一张图片、一段短文本通过几十层网络计算输出分类结果。而 LLM 是自回归解码——每次只预测一个 token然后把预测结果拼接到输入里继续预测下一个循环往复直到生成结束。这种模式带来的结果是推理时不仅要做矩阵乘法还要维护大量的历史状态KV Cache访存密集程度远高于计算密集程度。这种形态的变化对部署提出了非常不一样的要求。传统 ONNX 推理里模型推理一般只需要把输入张量推给引擎即可而 LLM 推理涉及输入序列长度动态变化、历史 token 的 KV Cache 管理、beam search 或 sampling 策略选择等一系列问题。这也是为什么大模型时代出现了 vLLM、TensorRT-LLM 这些专门做 LLM 推理的引擎——它们不只是执行计算图更是在做显存管理、调度优化、批量推理等系统层面的工作。ONNX 在这个阶段的位置从推理执行环境变成了模型交换格式。你可以把 ONNX 当成模型在 PyTorch 训练生态与其他推理引擎之间的接口。比如你想把一个 HuggingFace 上的模型部署到 TensorRT 上中间大概率会用到 ONNX 作为中介格式。有了这个中间层模型转换的逻辑就能模块化、标准化而不是每个引擎都重新实现一套模型解析。6.2 大模型场景下 ONNX 的落地路径大模型场景下 ONNX 的实际落地路径通常是这样的——先从 HuggingFace 等模型仓库获取预训练权重用 Optimum 等工具导出为 ONNX 格式然后分两条路走一条是直接交给 ONNX Runtime 做 CPU 或 GPU 推理另一条是再转换成 TensorRT-LLM 等专用格式做高性能 GPU 推理。HuggingFace 的很多 CLIP、ViT、Whisper、BERT 类模型都有现成的 ONNX 权重可以直接下载。另外ONNX Runtime 也推出了专门针对 LLM 的优化方案比如 onnxruntime-genai 扩展支持 llama、mistral、phi 等常见架构的 ONNX 模型量化推理。这类方案在 CPU 设备上跑 LLM 时表现还不错但在顶级 GPU 上的性能距离 vLLM 还是有差距。我在实际使用中的感受是如果只是本地调试、或者 CPU 上跑一个小规模的 LLM比如 7B 以下的量化模型ONNX Runtime 是一个还算靠谱的选择但如果要大规模服务用户、追求高并发和低延迟vLLM 和 TensorRT-LLM 还是主要选择。6.3 对大模型学习者的建议这几年动手学大模型类的教程特别火上海交大出过一套相关课程社区里也有各种学习路线。但说实话很多所谓的大模型学习路线内容安排得太功利一上来就让人去跑 vLLM、Ollama却忽略了最基础的知识储备。其中 ONNX 这条链路往往是被轻视的一环但它恰恰是很多工程师从会用大模型跨到能上手部署大模型的分水岭。我给大模型学习者的建议是不要一上来就陷入哪个框架最强的比拼里。先把模型推理的基本链路走通——训练一个模型哪怕是 MNIST 分类导出 ONNX用 ONNX Runtime 跑推理再用 TensorRT 试一次 GPU 加速。这个过程能帮你建立对模型从训练到部署全链路的直觉比单纯看教程有用得多。记住一个学习原则模型格式只是载体计算图和算子的本质才是根本。你把 ONNX 的图结构搞明白了后面学 vLLM 的 PagedAttention、TensorRT-LLM 的层融合、Ollama 的量化格式都会觉得不过是把同一件事做成了不同的性能版本底层逻辑是通的。7. 常见 ONNX 问题和排查思路实录做 ONNX 相关的部署做久了遇到的坑基本能总结成一张清单。我这里挑几个出现频率最高的问题以及对应的排查思路分享出来供大家参考。7.1 导出时报Unsupported operator错误这是最常见的问题之一。PyTorch 里的某些算子尤其是比较新的、不常见的算子在 ONNX 的算子集合里还没有对应的映射导出时就会报错。排查思路先看错误信息里提示的是哪个算子在搞事。如果是比较新的算子可以试着升级 PyTorch 和 ONNX 的版本新版通常会增加更多算子映射比如 FlashAttention 相关的融合算子。如果升级后还是不行就需要考虑修改模型结构来绕过这个算子比如把自定义算子拆解成多个 ONNX 支持的基础算子。还有一种办法是写自定义算子注册ONNX 的自定义 op 机制但这个方案复杂度较高做之前要评估清楚收益。7.2 导出成功但推理结果不对这种情况通常不是 ONNX 本身的问题而是模型在导出时丢掉了一些信息。最常见的原因是 batch norm 层在训练模式和推理模式下的行为不一样导出时如果没有调用 model.eval()batch norm 还是在用训练时的统计方式用当前 batch 的均值方差导出后的模型和实际推理行为对不上。另外一个常见原因是动态 shape 处理不当。如果你的模型在 forward 里有依赖输入 shape 的条件逻辑导出时用的 dummy input 一旦和线上输入尺寸不一致导出的计算图就可能走错分支。排查这类问题时强烈建议用 Netron 打开导出的 ONNX 模型人眼检查一遍网络结构。很多时候问题在 Netron 里一眼就能发现比盯着代码猜要高效得多。7.3 量化后精度暴跌INT8 量化后精度下降是正常现象但暴跌就说明哪里出了问题。检查顺序如下第一确认校准数据集的规模和质量一般建议至少几百到几千张有代表性的图片或文本样本覆盖尽可能多的分布情况第二检查有没有不适合量化的层比如最后的全连接层、带有特殊数学运算的层必要时可以在量化时对特定的层做精度保护不量化该层第三确认模型的动态范围是否稳定如果模型输入数据的数值尺度变化非常大比如 0 到 1 的图片和 0 到 255 的图片混在一起量化效果肯定会受影响建议先做输入归一化再量化。7.4 遇到 Unknown model 或 Unsupported DataType这类错误通常说明推理引擎的版本和模型使用的 opset 版本不匹配。比如你拿 opset 17 导出的模型喂给一个只支持 opset 15 的 ONNX Runtime 旧版本就会报类似错误。解决方式是降低导出的 opset 版本或者升级推理引擎的版本。如果是 DataType 不支持很可能是在模型里引入了自定义的、非标准的数据类型比如某些特殊场景下的复数运算这种情况下需要考虑调整模型实现避免使用推理引擎不支持的中间数据类型。7.5 我在实操中的几条经验最后分享几条吃过亏才记住的经验。第一导出 ONNX 之前先在 PyTorch 侧把模型推理的结果保存一份导出的 ONNX 推理结果和它做精确对比。不要省这一步它能帮你提前发现百分之八十的模型迁移问题。第二保护好自己的 CPU 环境。ONNX Runtime 在 CPU 上的性能优化已经做得比较好了很多场景尤其是中小模型CPU 推理速度和 GPU 差距并没有想象中那么大。急着上 GPU 之前先试试 CPU 推理的 benchmark可能会帮你省下一笔显卡预算。第三多留意大模型和边缘设备领域的格式演进速度。ONNX 仍然是目前覆盖面最广的中间表示但 GGUF、Safetensors 等格式在 LLM 领域已经有很强的生态了。做技术选型时不要有一个格式走天下的执念根据场景选择最合适的链路才是务实的工作方式。第四ONNX 模型并不是越大越准也不是越小越快。过量化会导致精度受损过度融合也可能引入风险合理评估精度和性能的平衡点才是工程上最应该花时间的部分。