第 14 章 · 部署与推理优化——从训练到落地

开场：模型训练好了，然后呢？

训练好一个检测模型只是故事的一半。另一半——把模型部署到实际环境中，让它在真实硬件上快速、稳定地运行——往往比训练本身更复杂。

这就像做菜和开餐厅的区别：你在家做出了一道好菜（训练好了模型），但要让顾客吃到（在用户设备上运行），你还需要考虑标准化（导出格式）、供应链（推理框架）、厨房设备（目标硬件）、出餐速度（延迟优化）等一系列问题。

部署流水线全景

训练完成的模型 (.pt / .pth)
    │
    ▼
┌──────────────────┐
│  1. 模型导出     │   PyTorch → 中间格式（ONNX / TorchScript）
└──────┬───────────┘
       │
       ▼
┌──────────────────┐
│  2. 模型优化     │   图优化、算子融合、量化
└──────┬───────────┘
       │
       ▼
┌──────────────────┐
│  3. 推理引擎     │   TensorRT / CoreML / ncnn / OpenVINO / TFLite
└──────┬───────────┘
       │
       ▼
┌──────────────────┐
│  4. 部署环境     │   云服务器 / 边缘设备 / 手机 / 浏览器
└──────────────────┘

阶段一：模型导出

ONNX：通用中间格式

ONNX（Open Neural Network Exchange）是模型导出最重要的中间格式——它定义了一套标准的算子集合，不同的推理框架（TensorRT、CoreML、ncnn 等）都能读取 ONNX 格式。

# Ultralytics 导出 ONNX
from ultralytics import YOLO
model = YOLO("yolov8n.pt")
model.export(format="onnx", opset=12, simplify=True)

# 等价的 CLI 命令
# yolo export model=yolov8n.pt format=onnx opset=12 simplify=True

导出 ONNX 时需要注意的关键参数：

opset:     ONNX 算子集版本（推荐 11-13）
           版本越高支持的算子越多，但推理框架可能不支持最新版本

simplify:  是否简化计算图
           合并冗余节点、消除无用计算
           推荐开启

dynamic:   是否支持动态输入尺寸
           True → 可以输入任意分辨率的图像
           False → 固定为导出时的分辨率（通常更快）

half:      是否导出为 FP16
           在支持 FP16 的 GPU 上可以加速推理

TorchScript

TorchScript 是 PyTorch 自带的序列化格式——不依赖外部工具，但推理性能不如 TensorRT 等专用引擎。

YOLO-Master 的导出注意事项

YOLO-Master 的 MoE 模块在导出 ONNX 时可能遇到的问题：

潜在问题 1: Top-K 选择
  torch.topk() 可以导出为 ONNX，但某些推理框架可能不支持
  解决方案: 确保使用的 ONNX opset 支持 TopK 算子（opset ≥ 11）

潜在问题 2: 动态专家选择
  如果代码中使用了 if/else 根据路由结果选择专家
  ONNX 的静态图无法表达动态控制流
  解决方案: 用矩阵运算替代条件分支
    # 不好导出的写法:
    if topk_idx == 0:
        out = expert_0(x)
    elif topk_idx == 1:
        out = expert_1(x)

    # 可以导出的写法:
    # 计算所有专家的输出，用 gate 权重（大部分为 0）加权
    all_outputs = [expert(x) for expert in experts]  # 计算所有专家
    out = sum(gate[i] * all_outputs[i] for i in range(num_experts))

潜在问题 3: 全局平均池化
  通常没问题，但注意动态形状时的行为

阶段二：模型优化

图优化

推理引擎在加载模型后，会对计算图做一系列优化：

常见的图优化:

1. 算子融合 (Operator Fusion):
   Conv → BN → ReLU    ===  融合为一个算子  ===    ConvBnRelu
   减少内存读写次数，提速 20-30%

2. 常量折叠 (Constant Folding):
   已知值的计算在编译时完成，不在推理时执行
   比如 BN 的 mean 和 var 在推理时是固定的

3. 死代码消除:
   去掉不影响输出的计算分支
   比如训练时用的辅助损失分支

4. 布局优化:
   NCHW → NHWC（或其他硬件偏好的布局）
   TensorRT 会自动选择最优布局

量化

量化是减少模型计算量和内存占用的最有效手段——把浮点数（FP32 / FP16）转换为低精度整数（INT8 / INT4）。

精度层级:
  FP32:  32 位浮点  ← 训练默认
  FP16:  16 位浮点  ← 几乎无损，推理速度翻倍
  INT8:  8 位整数   ← 损失 0.5-2.0 mAP，速度翻倍
  INT4:  4 位整数   ← 损失较大，极端场景使用

量化方式:
  PTQ (Post-Training Quantization):
    训练后直接量化，不需要重新训练
    简单快速，但精度损失可能较大

  QAT (Quantization-Aware Training):
    在训练时模拟量化误差
    精度损失更小，但需要额外训练

# TensorRT INT8 量化示例（通过 Ultralytics）
from ultralytics import YOLO
model = YOLO("yolov8n.pt")
model.export(
    format="engine",          # TensorRT
    int8=True,                # INT8 量化
    data="coco128.yaml",      # 校准数据集
)

MoE 的量化挑战

MoE 模型的量化有一些独特的挑战：

挑战 1: 路由器的量化
  路由器输出的 logits → softmax → topk
  softmax 对输入的数值范围非常敏感
  INT8 量化可能导致路由决策变化
  → 路由器建议保持 FP16

挑战 2: 专家间的量化一致性
  不同专家的权重分布可能不同
  如果用同一套量化参数，某些专家可能量化误差更大
  → 建议对每个专家独立做量化校准

挑战 3: 稀疏计算的效率
  量化后，专家的计算可以更快
  但路由选择的开销（topk, softmax）没有变
  → 路由开销占总推理时间的比例可能变大

阶段三：推理引擎

TensorRT（NVIDIA GPU）

TensorRT 是 NVIDIA GPU 上性能最强的推理引擎：

TensorRT 的优化:
  - 自动图优化（融合、消除、布局）
  - 针对具体 GPU 型号的内核自动调优
  - FP16 / INT8 / Sparsity 支持
  - 动态 batch / 动态形状支持

典型加速:
  YOLOv8n PyTorch FP32:   6.16ms
  YOLOv8n TensorRT FP16:  1.47ms    ← 4.2× 加速
  YOLOv8n TensorRT INT8:  0.98ms    ← 6.3× 加速

CoreML（Apple 设备）

CoreML 是 Apple 设备（iPhone、iPad、Mac）上的推理框架：

CoreML 的特点:
  - 自动利用 Apple Neural Engine（ANE）加速
  - ANE 上 INT8 推理速度极快
  - 和 iOS/macOS 原生集成
  - 支持的算子集比 TensorRT 小

ncnn（移动端 / 嵌入式）

ncnn 是腾讯开源的轻量推理框架，专为移动端优化：

ncnn 的特点:
  - 极小的库体积（< 1MB）
  - 无依赖（不需要 CUDA、cuDNN 等）
  - ARM NEON / Vulkan GPU 加速
  - 适合 Android 手机和嵌入式设备（如 Raspberry Pi）

OpenVINO（Intel 硬件）

OpenVINO 的特点:
  - Intel CPU / GPU / VPU 优化
  - 特别擅长 CPU 推理
  - 支持 INT8 自动量化
  - 适合 Intel 平台的边缘设备

TFLite（Android / 嵌入式）

TFLite 的特点:
  - Google 的移动端推理框架
  - Android 设备上的主流选择
  - 支持 NNAPI 硬件加速
  - GPU / DSP / NPU 委托

阶段四：部署环境

云端部署

场景: 视频监控中心、在线图像分析服务
硬件: NVIDIA A100/T4/L4 GPU
框架: TensorRT + Triton Inference Server
特点: 高吞吐（batch 推理）、延迟要求相对宽松

典型配置:
  YOLOv8m + TensorRT FP16 + A100
  → 吞吐: ~800 FPS (batch=32)
  → 延迟: ~5ms (batch=1)

边缘设备部署

场景: 自动驾驶、工业质检、智能摄像头
硬件: NVIDIA Jetson (Orin/Xavier/Nano), Intel NUC
框架: TensorRT / OpenVINO
特点: 受限的算力和内存，但需要低延迟

典型配置:
  YOLOv8n + TensorRT INT8 + Jetson Orin
  → 延迟: ~3ms
  → 功耗: ~15W

移动端部署

场景: 手机 APP（拍照识别、AR 应用）
硬件: iPhone (ANE), Android (Snapdragon NPU)
框架: CoreML / TFLite / ncnn
特点: 极受限的算力，需要考虑电池消耗

典型配置:
  YOLOv8n + CoreML + iPhone 15
  → 延迟: ~8ms (ANE)
  → 功耗: 很低

部署指标体系

部署时需要关注的指标远不止延迟一个：

延迟 (Latency):
  端到端处理一张图像的时间
  包括预处理、推理、后处理
  单位: ms

吞吐 (Throughput):
  每秒处理的图像数
  batch 推理时吞吐 >> 1/延迟
  单位: FPS (Frames Per Second)

内存占用:
  模型权重 + 中间激活值 + 输入/输出 buffer
  边缘设备通常 < 1GB 内存预算

模型大小:
  权重文件的体积
  移动端 APP 通常 < 50MB 模型预算

功耗:
  推理消耗的电力
  移动端和电池供电的边缘设备尤其敏感

精度保持:
  量化/优化后精度下降多少
  FP16 通常 < 0.1 mAP 损失
  INT8 通常 < 1.0 mAP 损失

端到端部署示例

从训练到 TensorRT 部署的完整流程

# 1. 训练模型
yolo detect train data=coco.yaml model=yolov8n.pt epochs=100

# 2. 验证精度
yolo detect val model=runs/detect/train/weights/best.pt data=coco.yaml
# → mAP@0.5 = 52.3

# 3. 导出 TensorRT（FP16）
yolo export model=best.pt format=engine half=True device=0

# 4. 验证导出后精度
yolo detect val model=best.engine data=coco.yaml
# → mAP@0.5 = 52.2 (损失 0.1)

# 5. 推理延迟测试
yolo detect predict model=best.engine source=bus.jpg
# → Inference: 1.5ms

完整的 Python 部署代码

import cv2
from ultralytics import YOLO

# 加载 TensorRT 模型
model = YOLO("best.engine")

# 打开摄像头
cap = cv2.VideoCapture(0)

while True:
    ret, frame = cap.read()
    if not ret:
        break

    # 推理
    results = model(frame, conf=0.25, iou=0.45)

    # 绘制结果
    annotated = results[0].plot()

    # 显示
    cv2.imshow("Detection", annotated)
    if cv2.waitKey(1) & 0xFF == ord('q'):
        break

cap.release()
cv2.destroyAllWindows()

YOLO-Master 的部署路线建议

对犀牛鸟参赛者来说，部署虽然不是核心评分维度，但能证明你的改进是可落地的——这会显著加分。建议的部署验证路线：

最低限度（必须做）:
导出 ONNX 成功
ONNX Runtime 推理精度和 PyTorch 一致

加分项:
导出 TensorRT 成功
TensorRT 推理延迟数据
INT8 量化后精度数据

如果能做到:
在边缘设备（如 Jetson）上跑通
和 YOLOv8 baseline 做部署后的延迟对比

初学者常见误区

误区一：”PyTorch 推理速度就是部署速度”

→ 正确理解：PyTorch 是一个灵活的训练框架，它的推理速度远不及专用推理引擎。TensorRT 在 NVIDIA GPU 上通常能比 PyTorch 快 2-5 倍。论文中报告的”延迟”通常是 TensorRT 优化后的数据，不是 PyTorch 的推理时间。在比较不同模型的速度时，确保使用同一推理引擎和同一硬件。

误区二：”ONNX 导出成功就等于可以部署”

→ 正确理解：ONNX 只是一个中间格式——从 ONNX 到具体的推理引擎还可能有问题。比如 TensorRT 可能不支持某些 ONNX 算子（需要自定义插件），CoreML 可能对动态形状支持有限。真正的”可部署”需要在目标推理引擎上实际跑通并验证精度。

误区三：”量化会严重损害精度”

→ 正确理解：FP16 量化在绝大多数情况下精度损失可以忽略（< 0.1 mAP）。INT8 量化在使用合适的校准数据后，损失通常在 0.5-1.0 mAP 以内。这个损失换来的是 2-4 倍的速度提升——对于大多数应用来说是非常值得的 trade-off。关键是使用有代表性的校准数据集（通常 500-1000 张训练集的子集）。

读完本章你能做什么

读完这一章，你应该能够：

描述从训练到部署的完整流水线（4 个阶段）
理解 ONNX 作为中间格式的作用
知道主要推理引擎（TensorRT、CoreML、ncnn）各自的适用场景
理解量化（FP16/INT8）的原理和 trade-off
为 YOLO-Master 制定部署验证计划

导读目录：README.md 上一章：第 13 章 · 技术挑战与前沿下一章：第 15 章 · 犀牛鸟参赛完全指南