一个基本问题：当我们谈论移植的时候，我们聊的是 ONNX 还是自定义算子？
这篇笔记不讨论哪条路线“更先进”，只记录一个实际选型问题：模型离开训练框架以后，究竟应该交给通用推理引擎，还是把它改写成项目自己的 C++ 实现。 面试时我常问这个问题。我关心的是，对方能不能把“能跑”和“适合长期维护”分开看。很多项目一开始只是照着现成方案接进去，等到包体积、启动时间或某个算子性能出了问题，才发现当初其实已经做了取舍。 所以这里的“移植”，不只是换一个文件格式。它更像是在两套成本之间做选择：一套成本由运行时和通用性承担，另一套成本由自己的代码、测试和维护承担。 一、ONNX 到底做了一件什么事 先从模型离开训练框架后的处境说起。 我们在 PyTorch 里训练模型，享受的是动态图、Python 生态、随时 print 随时调试。但部署环境——一个可能没有 Python、没有 torch、甚至没有文件系统的进程——什么都没有。训练与部署之间需要一次"交接"。交接最朴素的方式是序列化：把权重存下来，把结构描述出来。问题在于，每家框架的序列化格式都是私有方言：PyTorch 有 TorchScript 和 .pt，TensorFlow 有 SavedModel 和 .pb，互不相认。而部署端的推理引擎又层出不穷：ONNX Runtime、TensorRT、OpenVINO、CoreML、DirectML、各家 NPU 的私有 SDK……如果每个框架都要为每种引擎各写一条导出通道，对接复杂度是 N × M 的；在中间垫一层公共格式，它就变成 N + M。 ONNX（Open Neural Network Exchange）就是这层公共格式。具体来说，它负责三件事： 定义了一套标准算子集（operator set，简称 opset）：Conv、Gemm、BatchNormalization、Relu……每个算子的语义、输入输出、数值行为都有书面规范，并按版本演进（opset 13、17、18……）。 定义了一张计算图格式：用 protobuf 描述节点（NodeProto）、张量（ValueInfoProto）、权重（Initializer），以及它们之间的连接关系。一个 .onnx 文件本质上就是一段序列化后的 protobuf。 定义了类型与张量规范：数据类型、布局约定、广播规则。 可以把它看成模型领域的交换文件：训练框架负责把图和权重写出来，推理引擎负责把它读进去。双方不必直接适配彼此，只要共同遵守这份格式即可。它能普及，主要也是因为这个生态位置，而不是因为它在每一种设备上都能做到最好。 这里有一个几乎所有初学者都会混淆、但一问就露馅的点：ONNX 只是一个格式，它自己不会执行任何东西。真正让模型跑起来的是推理引擎，最常见的就是 ONNX Runtime（下文简称 ORT）。前者是协议，后者是实现，就像 JSON 和某个 JSON 解析器的关系。我们日常说"用 onnx 跑"，省略掉的主语几乎都是 ONNX Runtime。 那么这条路线的优势和代价分别是什么？ 先看它为什么常常是默认选项。实际项目里，通常看重的是三点：格式标准，工具链成熟，以及性能能够满足要求。 标准：一次导出，处处可跑（至少在纸面上）。跨框架、跨引擎、跨操作系统。 成熟：ORT 背后是大量工程师十几年打磨的图优化器、算子融合 Pass，以及接驳成熟的 kernel 库（CPU 上有 MLAS 一系，移动端常用 XNNPACK）。你几乎不可能在同等工时内手写出比它更稳、覆盖面更广的实现。 快得足够：对绝大多数 PC 端、服务端场景，ORT 的默认性能已经在业务容忍范围之内；而且它提供 Execution Provider（EP）机制——CUDA、TensorRT、DirectML、CoreML、QNN——同一个 .onnx 几乎零改动就能下发到 GPU 甚至 NPU。 再说代价。代价不在"能不能跑"，而在你为这份通用性交出的东西： ...