ONNX

ONNX（Open Neural Network Exchange）是由 Facebook 与 Microsoft 于 2017 年联合发起的开放神经网络交换格式，前身为 Facebook PyTorch 团队内部项目 Toffee，后更名并对外公告。它以有向无环计算图（DAG）加标准化算子集描述模型结构，采用 Protocol Buffers 序列化，使同一模型能在 PyTorch、TensorFlow、TensorRT、Core ML 等主流框架和推理引擎之间流通复用，已成为 MLOps 工程中模型部署与迁移的事实标准之一。

深度学习框架林立，模型在框架间迁移成本极高，ONNX 的诞生正是为了消除「框架锁定」问题。

• 框架锁定痛点：PyTorch 擅长研究与实验，TensorFlow 擅长生产部署，两者模型格式互不兼容，实验到落地需大量重写工作。
• 前身 Toffee：ONNX 前身为 Facebook PyTorch 团队内部项目 Toffee；2017 年 9 月与 Microsoft 合作后正式更名并对外发布，目标之一是打通 Caffe2 与 PyTorch 的互转。
• 开放生态联盟：IBM、华为、Intel、AMD、Arm、Qualcomm 等厂商相继宣布支持，形成广泛的工业联盟。
• 中立治理：项目后纳入 LF AI & Data Foundation（Linux 基金会旗下）托管，强化了中立性与长期治理。

ONNX 格式以 Protocol Buffers 序列化，核心数据结构围绕计算图展开。

• 模型（ModelProto）：顶层结构，包含图定义、opset 版本声明、生产者元数据等信息。
• 计算图（Graph）：由节点（Node）、输入输出描述（ValueInfo）和初始化权重（Initializer）组成的有向无环图。
• 算子集（Opset）：ONNX 将算子按版本分组为 Opset，每个版本对应一套不可变的算子语义；当前已定义超过 180 个算子，跨 19 个域（domain）。
• 数据类型：支持 float16、bfloat16、float32、float64、int8、int4 等主流张量类型，覆盖量化推理与 LLM 边缘部署场景。
• 函数算子：部分高阶算子以「函数」形式表达，其语义由基础算子展开定义，在保持可移植性的同时支持扩展。

模型从训练框架导出为 ONNX 格式，再由目标推理引擎读取并优化执行。

• 导出阶段：PyTorch 通过 torch.onnx.export() 追踪模型并生成 ONNX 计算图；TensorFlow 可通过 tf2onnx，scikit-learn 通过 sklearn-onnx 完成导出。
• 图优化：ONNX Runtime 在加载时对图做算子融合（如 Conv+BN+ReLU 合并）、常量折叠、死代码消除等优化，显著降低推理延迟。
• 执行提供程序（Execution Provider）：ONNX Runtime 通过插件化 EP 机制对接不同硬件，包括 CUDA EP、TensorRT EP、DirectML EP、CoreML EP 等。
• 动态 shape：ONNX 支持将部分维度声明为符号变量（如 batch_size），但并非所有算子和运行时都完整支持，需在导出时显式声明并实测验证。

围绕 ONNX 格式，社区构建了从模型转换到推理部署的完整工具链。

• ONNX Runtime：Microsoft 主导的跨平台推理引擎，1.0 版于 2019 年正式开源，支持 CPU、CUDA、TensorRT、DirectML、CoreML 等多种后端，是目前最主流的 ONNX 推理实现。
• 图优化工具：onnxoptimizer 与 onnxsim（ONNX Simplifier）可进行图融合、常量折叠，减小模型体积并提升推理速度。
• ONNX Script：Microsoft 推出的 Python DSL，用于直接在 Python 中编写和调试 ONNX 算子，比手写 Protobuf 更友好。
• 可视化工具：Netron 支持 ONNX 计算图的交互式浏览，便于调试算子结构与张量形状。
• Hugging Face 集成：平台上大量模型提供 .onnx 权重，用户无需安装训练框架即可直接推理。

ONNX 从双边协议演化为行业通用标准，经历了数年迭代。

• 2017：Facebook 与 Microsoft 联合公告 ONNX；12 月发布 1.0 正式版，AWS 等合作伙伴加入。
• 2018：Amazon、IBM、Intel 等加入；LF AI Foundation 接手治理；Caffe、MXNet 等框架陆续支持导出。
• 2019：ONNX Runtime 1.0 正式开源，成为独立推理引擎并迅速普及；ONNX-ML 扩展支持传统机器学习算子。
• 2020–2022：Opset 11–17 大幅扩展算子集，新增 Transformer 关键算子（LayerNorm、Attention），QDQ 量化算子逐步完善。
• 2023–2025：Opset 18–21 引入 INT4 量化算子、RoPE 等 LLM 推理相关算子；ONNX Script 发布；与 PyTorch 2.0 torch.export 深度集成；LLM 边缘部署场景持续延伸。

ONNX 并非万能，实际部署中需关注若干常见陷阱。

• 算子覆盖不完整：自定义算子（Custom Op）需额外注册；部分框架专有算子无法直接导出，会报错或静默截断。
• 动态控制流限制：含 Python if/for 的动态模型导出时需改写为静态或受限的动态形式，否则行为不一致。
• 数值精度漂移：框架间浮点舍入顺序不同，导出后 ONNX 模型输出与原框架结果可能有微小但可测量的差异，需做端到端精度对齐验证。
• 「一次导出即可用」是误区：不同 Execution Provider 支持的 Opset 版本和算子集不同，需针对目标硬件实测，不可假设默认兼容。
• LLM 导出挑战：大型语言模型因含 KV cache 动态状态和自回归循环，ONNX 导出与高性能 serving 的配合仍是工程难点；超过 2 GB 的模型需启用外部数据格式（external data）。

ONNX 在模型从研发到生产的全链路中扮演「通用接口」的角色。

• 训练-推理框架解耦：用 PyTorch 训练，用 ONNX Runtime 或 TensorRT 部署，同时享受两个框架各自的优势。
• 边缘与端侧部署：将 PyTorch 模型导出为 ONNX，再转换为 CoreML 或 TFLite 等端侧格式，是移动端 AI 部署的标准路径之一。
• 跨云模型托管：Azure Machine Learning、AWS SageMaker 等平台原生支持 ONNX 格式，实现框架无关的模型托管与推理服务。
• 量化推理加速：配合 QAT/PTQ 流程导出 INT8/INT4 ONNX 模型，在 CPU 和 NPU 上显著提升吞吐量，降低能耗。
• MLOps 流水线标准化：以 ONNX 作为模型制品（artifact）格式，统一训练与服务两侧的接口，降低平台迁移成本。