4、模型格式与转换：常见模型格式（ONNX、TensorRT、TorchScript、SavedModel）、格式转换工具与注意事项
模型训练完成后，并不能直接部署到生产环境。训练框架（如 PyTorch、TensorFlow）中的模型权重与计算图，往往与推理引擎、目标硬件（GPU、CPU、NPU、移动端）之间存在“语言不通”的问题。模型格式与转换，正是解决这一问题的桥梁。本章将深入剖析四种主流模型格式——ONNX、TensorRT、TorchScript、SavedModel 的定位与内部结构，讲解格式转换的标准流程与工具链，并重点剖析转换过程中常见的精度损失、算子不支持、动态维度失效等“坑”，帮助学员建立一套稳健的模型交付方法论。
上图展示了从训练框架到目标硬件的完整转换链路。核心思想是：训练框架负责“表达”模型，中间格式负责“通用传输”，推理引擎负责“高效执行”。理解这条链路，是掌握模型部署的第一步。
4.1 四大主流模型格式的定位与内部结构
4.1.1 核心原理：格式的本质是“协议”
模型格式本质上是一种序列化协议，它规定了如何将神经网络的结构（层、连接、参数）和属性（版本、元数据）持久化到文件中。不同的格式，其设计目标截然不同：
- ONNX（Open Neural Network Exchange）：由微软和Facebook联合推出，旨在成为AI框架之间的“通用语”。它定义了一套标准化的算子集（Opset）和图结构（GraphProto），使得模型可以在不同框架间自由流动。ONNX 本身不负责高性能计算，它只是一个“中间表示”。
- TensorRT（TRT）：NVIDIA 推出的高性能推理引擎，其模型格式（.engine / .plan）是经过深度优化的、针对特定GPU架构的二进制文件。它融合了层、内核自动调优、精度校准（FP16/INT8）等特性，是NVIDIA GPU上推理性能的“天花板”。
- TorchScript：PyTorch 的原生部署格式。它通过
torch.jit.trace或torch.jit.script将Python动态图“固化”为静态图，从而脱离Python解释器运行。TorchScript 的优势在于与PyTorch生态无缝集成，但跨框架能力较弱。 - SavedModel：TensorFlow 的官方部署格式。它是一个包含模型结构（GraphDef）、权重（Variables）和资产（Assets）的目录。SavedModel 是TensorFlow Serving、TFLite转换的基石，支持签名（Signature）定义，便于服务化部署。
| 格式 | 设计目标 | 运行依赖 | 典型应用场景 |
|---|---|---|---|
| ONNX | 跨框架互转 | ONNX Runtime / 各框架解析器 | 模型迁移、多引擎适配 |
| TensorRT | GPU极致性能 | NVIDIA GPU + TensorRT库 | 在线推理服务、自动驾驶 |
| TorchScript | PyTorch服务化 | LibTorch / C++ | PyTorch模型C++部署 |
| SavedModel | TF服务化 | TensorFlow Serving / TFLite | TF模型生产部署 |
4.1.2 判断方法：如何选择格式？
选择格式的核心依据是目标硬件与性能要求。如果目标是NVIDIA GPU且追求极致吞吐，TensorRT 是首选；如果需要跨框架或跨硬件（如从PyTorch转到TensorRT），则必须先转换为ONNX；如果团队技术栈完全基于PyTorch且无性能极致要求，TorchScript 是最省事的路径。
4.1.3 案例拆解：一个典型的转换决策
假设我们有一个训练好的PyTorch目标检测模型（YOLOv5），需要部署到NVIDIA A100 GPU上提供API服务。初始方案是直接用TorchScript部署，但压测发现GPU利用率仅30%，延迟不达标。分析后决定：PyTorch → ONNX → TensorRT。转换后，通过FP16精度校准和层融合，GPU利用率提升至85%，延迟降低60%。这个案例说明，格式转换不仅是“翻译”，更是“优化”。
4.1.4 常见误区与复盘
- 误区一：认为ONNX文件可以直接用于生产推理。实际上，ONNX Runtime 的性能远低于专用引擎。
- 误区二：忽略版本兼容性。PyTorch 2.x 导出的ONNX算子集（Opset 17+）在旧版ONNX Runtime上可能无法解析。
- 复盘：转换前务必确认目标引擎支持的ONNX Opset版本范围。
4.2 格式转换工具链与操作流程
4.2.1 核心原理：转换的本质是“图重写”
格式转换工具（如 torch.onnx.export、tf2onnx）的工作机制是：遍历源框架的计算图，将每个算子映射为目标格式的算子，并处理权重布局、常量折叠等细节。这个过程涉及三个关键步骤：图遍历、算子映射、属性转换。
4.2.2 操作流程：以PyTorch转ONNX为例
- 准备模型：确保模型处于
eval()模式，并固定输入尺寸（或指定动态轴）。 - 执行导出：使用
torch.onnx.export传入模型、示例输入、输出路径。 - 验证模型：使用
onnxruntime加载ONNX文件，对比输出与PyTorch原始输出的误差。 - 可视化检查：使用 Netron 打开ONNX文件，检查图结构是否与预期一致。
import torch
import torchvision.models as models
model = models.resnet18(pretrained=True).eval()
dummy_input = torch.randn(1, 3, 224, 224)
torch.onnx.export(
model, dummy_input, "resnet18.onnx",
input_names=["input"], output_names=["output"],
dynamic_axes={"input": {0: "batch"}, "output": {0: "batch"}},
opset_version=17
)
print("ONNX export done.")4.2.3 案例拆解：TensorRT 转换的完整闭环
在将ONNX转换为TensorRT引擎时，我们遇到了一个典型的精度问题。初始使用FP16模式转换，模型输出与FP32相比误差较大（mAP下降2.1%）。分析发现，模型中的 BatchNormalization 层在FP16下存在数值不稳定。解决方法是：在转换时使用 --fp16 --strictTypeConstraints 并指定 BatchNormalization 层保持FP32计算。调整后，mAP损失降至0.3%以内，且推理速度几乎不变。这个案例表明，精度校准是TensorRT转换中最需要反复试验的环节。
4.2.4 常见误区与总结
- 误区：转换后不验证。转换工具不会报错，但输出可能已经“悄悄”变了。
- 误区：忽略动态维度。如果服务需要支持可变batch size，必须在导出时声明动态轴。
- 总结：转换流程必须包含“验证”环节，且验证数据应覆盖真实业务分布。
4.3 转换中的关键注意事项与排障
4.3.1 核心原理：三大“拦路虎”
格式转换中最常见的三类问题是：算子不支持、精度损失、动态维度失效。算子不支持源于目标格式的算子集覆盖不全；精度损失多与低精度（FP16/INT8）转换有关；动态维度失效则是因为某些算子（如Reshape）对输入形状有硬编码假设。
4.3.2 判断与排障方法
- 算子不支持：使用
onnxruntime的get_available_providers()检查执行环境，或使用polygraphy工具进行逐层对比定位失败层。 - 精度损失：对比FP32与FP16/INT8的输出差异，使用
--verbose日志查看每层精度统计。 - 动态维度：在导出时明确指定
dynamic_axes，并在TensorRT转换时使用--minShapes --optShapes --maxShapes定义范围。
4.3.3 案例拆解：一个动态维度引发的线上事故
某推荐系统模型在转换时未声明动态batch轴，导致线上服务只能以固定batch=1运行，GPU利用率极低。排查过程：查看TensorRT引擎的profile信息，发现输入形状被固定为[1, 128]。修复方案：重新导出ONNX并声明动态轴，使用 trtexec --minShapes=input:1x128 --optShapes=input:16x128 --maxShapes=input:32x128 重新生成引擎。修复后，服务支持batch=16的动态调整，吞吐量提升4倍。
4.3.4 总结复盘
格式转换不是“一键完成”的魔法，而是一个需要验证、调优、再验证的工程过程。建议建立标准化的转换验证流程：导出 → 静态检查（Netron）→ 数值对比（误差<1e-4）→ 性能压测 → 灰度上线。同时，保留原始模型和转换脚本，以便快速迭代。