4. 模型部署与运行时基础
在自动驾驶多模型并发推理系统中，模型训练完成只是起点。真正决定系统能否在车端稳定运行、能否满足实时性与安全性的，是模型部署与运行时基础设施。本章围绕四个核心概念展开：模型格式、推理引擎、硬件加速器，以及运行时调度与资源管理。理解它们之间的协作关系，是后续设计并发推理架构的前提。
一、核心原理：从训练产物到车端可执行单元
训练框架产出的权重文件（如 PyTorch 的 .pt、TensorFlow 的 .pb）并不能直接在车端高效运行。部署过程本质上是格式转换、图优化、算子映射与内存规划的连续变换。模型格式决定了计算图的表达方式，推理引擎负责解释并优化该计算图，硬件加速器提供算力，而运行时调度则决定多个模型如何共享这些资源。
四者构成一条清晰的链路：模型格式 → 推理引擎 → 硬件加速器 → 运行时调度。任何一环选择不当，都会在延迟、吞吐或内存上产生瓶颈。例如，一个为 GPU 优化的 TensorRT 引擎无法直接运行在 NPU 上；一个未做内存复用的运行时，在并发加载多个模型时会迅速耗尽显存。
二、模型格式：表达方式决定优化空间
模型格式是部署的起点。常见格式可分为三类：训练框架原生格式（如 PyTorch .pt）、中间表示格式（如 ONNX）、以及引擎专用序列化格式（如 TensorRT .plan、TFLite .tflite）。原生格式便于训练但推理效率低；ONNX 提供跨框架的通用图表达，是转换枢纽；引擎专用格式则已包含针对特定硬件的算子融合、精度校准和内存布局优化，加载即可执行。
选择格式时需权衡：ONNX 灵活但需运行时解释，TensorRT Plan 高效但绑定 GPU 型号与版本。在自动驾驶项目中，通常采用ONNX 作为中间层，再针对目标硬件生成专用引擎的流水线。
# 典型转换流程示例
# 1. PyTorch → ONNX
torch.onnx.export(model, dummy_input, "perception.onnx",
opset_version=13, input_names=["image"],
output_names=["boxes", "scores"])
# 2. ONNX → TensorRT Plan
trtexec --onnx=perception.onnx --saveEngine=perception.plan \
--fp16 --workspace=2048 --minShapes=image:1x3x640x640 \
--optShapes=image:1x3x640x640 --maxShapes=image:4x3x640x640三、推理引擎与硬件加速器：算力落地的关键
推理引擎负责加载模型、管理内存、调度算子执行。主流引擎包括 TensorRT（NVIDIA GPU）、ONNX Runtime（跨平台）、TVM（可编译到多种后端）、OpenVINO（Intel）以及各芯片厂商的专用 SDK。引擎的核心价值在于图优化：算子融合、常量折叠、精度量化（FP16/INT8）、动态形状支持等。
硬件加速器则提供实际算力。GPU 适合高并行浮点计算，NPU 在 INT8 推理上能效比突出，DSP 擅长信号处理类算子。自动驾驶域控制器常采用异构架构：GPU 跑感知大模型，NPU 跑轻量分类网络，CPU 处理逻辑与后处理。引擎必须与加速器匹配，否则会回退到 CPU 执行，导致延迟飙升。
.hbm 模型，而非直接部署 ONNX。
四、运行时调度与资源管理：并发执行的指挥官
当多个模型同时运行时，运行时调度决定谁先执行、占用多少资源、何时释放。核心机制包括：任务队列（按优先级排队）、计算流（CUDA Stream 实现异步并行）、内存池（复用显存避免频繁分配）、以及算力配额（限制单模型占用比例）。
在自动驾驶场景中，感知模型通常优先级最高，预测与规划次之。调度器需要保证高优先级任务在截止时间内完成，同时避免低优先级任务饿死。常见策略是基于优先级的抢占式调度配合时间片轮转。
| 资源类型 | 管理对象 | 典型策略 | 风险 |
|---|---|---|---|
| 显存 | 模型权重、中间激活、输入输出缓冲 | 内存池 + 静态分配 | 碎片化导致 OOM |
| 算力 | SM 占用、Tensor Core 使用 | 流优先级 + 并发内核 | 高优先级任务被阻塞 |
| 带宽 | HBM / LPDDR 读写 | 数据布局优化 + 缓存 | 带宽饱和拖慢所有模型 |
| 功耗 | 芯片 TDP、散热 | 动态频率调节 | 降频导致延迟抖动 |
五、案例与误区复盘
案例：某 L2+ 项目在 Orin 平台上部署 5 个模型（检测、分割、车道线、预测、规划）。初期直接加载 5 个独立 TensorRT 引擎，显存占用 12GB，推理延迟波动大。优化后：将检测与分割合并为多任务模型，共享 backbone；使用 CUDA Graph 减少内核启动开销；为预测与规划分配独立 Stream 并设置低优先级。最终显存降至 7GB，端到端延迟稳定在 80ms 以内。
- 认为 ONNX 可以直接高效运行——实际需引擎二次优化。
- 忽略动态形状支持——车端输入尺寸变化会导致引擎重建。
- 所有模型共用一个 Stream——无法并行，且相互阻塞。
- 不做内存池——频繁分配释放造成显存碎片与延迟抖动。
总结来看，模型格式、推理引擎、硬件加速器与运行时调度构成一个紧密耦合的系统。部署不是简单的格式转换，而是面向目标硬件的全链路优化。只有四者协同设计，才能在车端有限资源下实现多模型并发推理的实时性与稳定性。