2. 自动驾驶系统概述
自动驾驶系统并不是一个单一模型，而是一条由多模块串联、闭环运行的实时决策链路。理解模型部署的位置与作用，必须先看清整条链路的职责边界：感知负责“看见世界”，预测负责“推测他者”，规划负责“决定怎么走”，控制负责“把决定变成动作”。模型部署工程则贯穿其中，把训练好的算法变成车上可执行、可监控、可降级的软件实体。
一、四大模块的职责与数据流
感知模块接收摄像头、激光雷达、毫米波雷达、IMU、GNSS 等传感器数据，输出目标检测框、车道线、可行驶区域、障碍物距离与速度等结构化信息。预测模块基于感知结果与地图，推断其他交通参与者未来数秒的轨迹分布。规划模块结合预测、地图、交规与自车状态，生成一条安全、舒适、可执行的轨迹。控制模块把轨迹转化为油门、刹车、转向指令，通过 CAN 总线作用于底盘执行器。
这四个模块构成一个持续运行的闭环：感知误差会放大为预测偏差，预测偏差会传导为规划风险，规划抖动会加剧控制负担。因此，模型部署不是“把模型放上车”这么简单，而是要在每个环节保证时延、精度与稳定性。
二、模型部署在系统中的位置与作用
从部署视角看，每个模块内部都包含“算法模型 + 运行时 + 接口”三层。算法模型是训练产物，运行时负责加载、推理、内存管理与调度，接口负责与上下游交换结构化数据。部署工程师的核心任务，是让模型在车规级计算平台上满足时延、吞吐、内存与功耗约束。
以感知为例，一个 BEV 检测模型在服务器上可能以 FP32 运行，但在车端需要经过 TensorRT 量化、层融合与 kernel 自动调优，才能把单帧推理压到 30ms 以内。预测模块常用序列模型，部署时要处理变长输入、缓存历史状态与批处理调度。规划模块中的优化求解器虽然不一定是神经网络，但同样需要部署封装、超时回退与安全校验。控制模块则更强调确定性时延与执行器接口的稳定性。
部署位置的本质：模型部署位于“算法输出”与“系统行为”之间，是可靠性工程的第一道工程化关口。它决定了模型能否在真实车上稳定、可观测、可降级地运行。
三、可靠性需求从哪里来
可靠性需求并非凭空设定，而是从安全、实时、算力、环境与法规五个方向共同挤压出来的。安全要求模型不能漏检关键障碍物，也不能因误检导致急刹；实时要求端到端链路在百毫秒级完成；算力约束要求模型在有限 TOPS 与带宽下运行；环境变化要求模型对雨雾、逆光、夜间具有泛化能力；法规与功能安全标准则要求系统具备故障检测、降级与可追溯能力。
| 需求来源 | 典型指标 | 对模型部署的影响 |
|---|---|---|
| 功能安全 | 漏检率、误检率、ASIL 等级 | 需要冗余推理、置信度校验与安全回退 |
| 实时性 | 端到端时延 ≤ 100ms | 量化、剪枝、算子融合与流水线调度 |
| 算力与功耗 | TOPS、内存带宽、散热上限 | 模型压缩、动态批处理、精度取舍 |
| 环境泛化 | 雨雾、逆光、夜间场景通过率 | 数据增强、在线监控与 OTA 更新 |
| 法规合规 | ISO 26262、SOTIF、数据记录 | 版本管理、日志留存与可追溯部署 |
四、案例：一次感知模型上车部署的复盘
某项目将服务器上 mAP 达 0.82 的检测模型直接转为 ONNX 后部署到车端，实车测试却发现两个问题：一是逆光场景下漏检率明显上升，二是推理时延波动大，偶发超过 80ms。复盘发现，量化校准集只用了晴天数据，导致模型对高动态范围场景的激活分布估计失真；同时推理线程与图像采集线程共享内存带宽，造成时延抖动。
部署检查清单：
1. 量化校准集是否覆盖雨、雾、逆光、夜间？
2. 推理线程优先级是否高于非关键任务？
3. 是否设置超时阈值与降级策略？
4. 是否记录每帧推理时延与置信度分布？
5. 模型版本与标定参数是否可追溯？常见误区：把部署当成“格式转换”。实际上，部署是模型精度、时延、内存、功耗与安全策略的联合调优过程。忽略校准数据分布、线程调度与降级逻辑，往往会在实车阶段暴露严重问题。
五、从系统视角理解部署可靠性
感知、预测、规划、控制四个模块的模型部署，共同构成自动驾驶系统的可靠性底座。部署工程师需要同时理解算法意图与系统约束：知道模型输出会被谁消费，知道时延预算如何分配，知道故障时如何降级。只有把模型部署放在整条闭环链路中审视，才能真正回答“模型部署在系统中的位置与作用”以及“可靠性需求从哪里来”这两个核心问题。