📚 课程目录第4章模型部署基础

4. 模型部署基础

在 Orin 自动驾驶项目中，模型训练与车端推理往往运行在两套完全不同的环境里：训练侧使用 PyTorch、TensorFlow 等框架，依赖 Python 运行时和完整算子库；车端则要求低延迟、低功耗、确定性执行，通常由 TensorRT 在 GPU/DLA 上完成推理。模型部署基础要解决的核心问题，就是如何把训练框架产出的权重，经过中间表示与图优化，转换成推理引擎可高效执行的引擎文件，并在 Orin 上稳定运行。

一、核心原理：三层转换与两类角色

从训练到推理，模型通常经历三个层次：训练框架层（PyTorch/TensorFlow，保存 .pt/.pth/.pb）、中间表示层（ONNX，统一算子与计算图）、推理引擎层（TensorRT engine，面向具体 GPU/DLA 与精度做优化）。ONNX 的角色是“通用交换格式”，它把不同框架的模型统一成标准计算图，屏蔽框架差异；TensorRT 的角色是“硬件相关优化器与运行时”，它读取 ONNX，做层融合、精度校准、内核自动调优，生成针对 Orin 的序列化引擎。

需要特别理解：ONNX 不是推理引擎，它只描述计算图，不负责执行；TensorRT 也不是训练工具，它只做前向推理优化。二者是“描述”与“执行”的分工关系。

二、方法流程：一次完整的转换链路

以 PyTorch 模型部署到 Orin 为例，典型流程如下：

导出 ONNX：使用 torch.onnx.export，指定输入张量、动态轴、opset 版本，并调用 model.eval() 关闭 Dropout/BatchNorm 训练行为。
检查与简化 ONNX：用 onnx.checker 校验图合法性，用 onnxsim 做常量折叠与冗余节点消除，减少后续解析失败概率。
构建 TensorRT 引擎：用 trtexec 或 Python API 解析 ONNX，设置精度、工作空间、DLA 回退策略，生成 .engine。
车端加载与推理：在 Orin 上用 TensorRT Runtime 反序列化引擎，绑定输入输出显存，执行 executeV2 或 enqueueV3。
精度与性能验证：对比 ONNX Runtime 与 TensorRT 输出误差，测量端到端延迟与显存占用。

# 1. 导出 ONNX
torch.onnx.export(model, dummy_input, "model.onnx",
                  input_names=["input"], output_names=["output"],
                  dynamic_axes={"input": {0: "batch"}}, opset_version=12)

# 2. 简化 ONNX
python -m onnxsim model.onnx model_sim.onnx

# 3. 构建 TensorRT 引擎（FP16）
trtexec --onnx=model_sim.onnx --saveEngine=model_fp16.engine \
        --fp16 --workspace=2048 --minShapes=input:1x3x640x640 \
        --optShapes=input:1x3x640x640 --maxShapes=input:4x3x640x640

三、案例场景：Orin 上的感知模型部署

假设一个 BEV 感知模型在训练侧为 PyTorch，输入 1×3×640×640，包含可变形卷积与自定义算子。直接导出 ONNX 时，可变形卷积可能被拆成多个基础算子，导致 TensorRT 解析后性能下降。工程上的做法是：先在导出时用 ONNX 自定义域保留该算子，再在 TensorRT 中通过插件（Plugin）实现；若时间紧张，也可用 onnxsim 与算子替换将其退化为普通卷积近似，但需重新评估精度。最终在 Orin 上以 FP16 构建引擎，端到端延迟从 85 ms 降到 32 ms，显存占用从 2.1 GB 降到 1.3 GB。

四、常见挑战与误区复盘

挑战/误区	典型表现	应对策略
ONNX 算子不支持	导出报错或 TensorRT 解析失败	升级 opset、替换算子、编写 Plugin
动态 shape 处理不当	引擎只支持固定 batch，换 batch 崩溃	设置 min/opt/max shape，使用 Optimization Profile
精度下降	FP16/INT8 后 mAP 掉点明显	校准集覆盖真实场景，逐层敏感度分析
忽略 DLA 限制	部分层回退 GPU，延迟不降反升	用 trtexec --useDLACore 验证，拆分模型
训练/推理预处理不一致	车端结果与训练验证差异大	统一归一化、通道顺序、letterbox 逻辑

建议把 ONNX 作为“可检查的中间产物”保留在 CI 中：每次模型更新都自动导出、简化、构建引擎并跑一遍精度对齐，避免问题拖到车端才暴露。

不要直接在 Orin 上从 ONNX 现场构建引擎用于量产。构建过程耗时且依赖环境，量产应使用离线构建好的 .engine，并做好版本与硬件绑定管理。

理解训练框架、ONNX、TensorRT 三者的分工与转换链路，是 Orin 模型部署的第一步。后续的量化、插件开发与多流并发，都建立在这条链路稳定可靠的基础之上。