1. 课程导入

自动驾驶系统并不是“一个模型包打天下”。在真实车端与云端链路中，感知、预测、规划、控制、驾驶员监控、语义建图、Occupancy 栅格、BEV 融合、多模态大模型问答等任务往往由多个模型协同完成。它们共享摄像头、激光雷达、毫米波雷达、IMU、GNSS 与底盘信号，却对时延、精度、功耗、内存带宽和功能安全等级提出不同要求。因此，多模型并发推理系统工程要解决的核心问题不是“如何把某个模型跑得更快”，而是“如何让一组异构模型在有限算力与严格时限内稳定、可预测、可验证地共同工作”。

1.1 学习目标：从单模型优化走向系统级并发

本课程面向已经具备一定深度学习推理基础、希望进入自动驾驶量产或高阶智驾研发的工程师。完成学习后，你应当能够：

• 理解多模型并发推理的系统边界：模型、运行时、调度器、内存、通信、传感器与整车约束。
• 掌握并发推理的关键指标：端到端时延、P50/P99 尾延迟、吞吐、帧率稳定性、算力利用率、内存峰值与功耗。
• 能够为感知、预测、规划等不同任务设计合理的并发策略，包括流水线并行、数据并行、模型并行与优先级抢占。
• 能够识别并定位典型问题：GPU 利用率低、CPU 瓶颈、内存拷贝过多、算子竞争、优先级反转、尾延迟抖动。
• 能够从功能安全与预期功能安全角度，为并发系统设计降级、监控与回滚机制。

1.2 核心概念：并发、并行与流水线

很多初学者会把“并发”和“并行”混为一谈。并发强调多个任务在逻辑上同时推进，可能分时复用同一硬件；并行强调多个任务在物理上同时执行。自动驾驶中，二者常常混合出现：多个摄像头模型可以并行跑在不同 GPU 流上，而单个大模型内部又可能通过张量并行拆分到多卡。

另一个关键概念是流水线。以 BEV 感知链路为例，图像预处理、骨干网络、BEV 变换、时序融合、检测头、后处理可以拆成多个阶段。若每个阶段都等待上一阶段完全结束，端到端时延会很高；若采用流水线，不同帧可以在不同阶段重叠执行，从而提升吞吐并降低平均时延。但流水线会引入更复杂的同步与内存管理问题，尤其是当各阶段耗时不一致时，必须通过缓冲、背压和动态调度来平衡。

此外，自动驾驶推理系统还必须区分硬实时与软实时。控制与安全监控通常属于硬实时，错过截止时间可能带来安全风险；而部分离线建图、日志上传、模型热更新则属于软实时，可以容忍一定延迟。并发调度器必须能够表达这种优先级差异。

1.3 整体框架：从传感器到执行器的并发推理链路

下图给出自动驾驶多模型并发推理系统的整体框架。它从传感器输入开始，经过预处理、多模型并发推理、融合与后处理，最终输出到规划控制与安全监控。图中同时标出了资源管理层与观测层，它们贯穿整个链路。

从图中可以看到，多模型并发推理并不是孤立的一层，而是被资源管理层与观测运维层包裹。资源管理层决定“谁能用多少算力”，观测层决定“系统是否真的按预期运行”。缺少任何一层，系统都可能在实验室跑通、在量产车上失效。

1.4 产业背景：为什么现在必须学并发推理系统工程

过去几年，自动驾驶算法从单任务小模型快速演进到 BEV、Transformer、Occupancy 与端到端大模型。模型参数量与计算量持续上升，而车端芯片的算力、功耗与散热预算却受到严格限制。与此同时，消费者对智驾体验的期待不断提高：更远的感知距离、更密的帧率、更低的接管率、更自然的规划行为。这些需求叠加在一起，使得“单模型极致优化”越来越难以满足系统目标。

产业界正在形成几个明显趋势：

• 多模型协同：感知、预测、规划不再串行独立，而是通过共享 BEV 特征、统一世界模型与联合训练实现协同。
• 异构计算：CPU、GPU、NPU、DSP 甚至专用加速器共同承担不同算子，调度复杂度显著上升。
• 端云协同：车端负责低时延安全闭环，云端负责大模型训练、难例挖掘与影子模式验证。
• 安全合规：功能安全、预期功能安全、数据合规与 OTA 升级要求系统具备可观测、可降级、可回滚能力。

维度	单模型推理	多模型并发推理
优化目标	单模型时延与精度	系统端到端时延、吞吐与稳定性
资源视角	独占或简单复用	GPU/CPU/内存/带宽/功耗全局分配
主要风险	算子性能不足	资源竞争、优先级反转、尾延迟抖动
验证方式	单模型精度与速度测试	系统级回放、压力测试、故障注入
安全要求	相对较低	硬实时、降级、监控与回滚

1.5 案例场景：一次典型的并发推理帧

假设车辆在城市道路以 60 km/h 行驶，感知系统需要同时运行 6 路摄像头 BEV 模型、1 个激光雷达检测模型、1 个 Occupancy 模型和 1 个驾驶员监控模型。控制周期为 50 ms，感知到规划的端到端预算为 80 ms。某一帧中，BEV 模型耗时 35 ms，激光雷达模型耗时 28 ms，Occupancy 模型耗时 42 ms，驾驶员监控模型耗时 8 ms。如果全部串行执行，总耗时约 113 ms，已经超出预算；如果采用并发调度，将 BEV 与激光雷达模型放在不同 CUDA Stream 上并行，Occupancy 模型与驾驶员监控模型错峰执行，则有可能将关键路径压缩到 70 ms 以内。

但并发并不总是更快。若两个模型竞争同一显存带宽，实际耗时可能反而上升；若低优先级模型长时间占用 GPU，高优先级的安全监控模型可能被延迟。因此，工程上必须通过优先级、配额、时间片与背压机制来约束并发行为。

1.6 方法流程：从需求到可运行系统

一个可落地的多模型并发推理系统工程，通常遵循以下流程：

1. 任务分解：明确每个模型的输入输出、时延预算、精度要求与安全等级。
2. 资源建模：统计各模型的计算量、显存占用、内存带宽与功耗画像。
3. 并发策略设计：选择流水线、数据并行、模型并行或混合方案，确定优先级与配额。
4. 运行时配置：设置 CUDA Stream、TensorRT Profile、批大小、内存池与线程池。
5. 观测与调优：采集 P50/P99 时延、GPU 利用率、显存峰值与丢帧率，迭代优化。
6. 安全验证：进行故障注入、压力测试、降级演练与回滚验证。

# 示例：查看车端推理进程的 GPU 与显存占用
nvidia-smi --query-gpu=timestamp,utilization.gpu,memory.used,memory.total,power.draw \
           --format=csv -l 1

# 示例：采集推理服务端到端时延分布
python latency_probe.py --model bev_det --frames 5000 --report p50,p95,p99

这些命令看似简单，却是并发推理系统工程的基础。没有持续观测，就无法判断并发策略是否真正有效，也无法在问题出现时快速定位。

1.7 复盘：本课程将带你建立的三层能力

第一层是指标意识：不再只看单模型速度，而是关注系统端到端时延、尾延迟、吞吐与稳定性。第二层是调度能力：能够根据任务优先级与资源画像设计并发策略，并处理资源竞争与优先级反转。第三层是安全与运维能力：能够为并发系统设计监控、降级、回滚与灰度发布机制。