3. 多模型并发推理概述

在自动驾驶系统中，单一模型往往无法覆盖感知、预测、规划、控制等全部任务。实际车载计算平台通常同时运行多个深度神经网络：BEV 感知模型、激光雷达检测模型、车道线分割模型、目标跟踪模型、轨迹预测模型，甚至还有驾驶员监控模型。多模型并发推理，就是指在同一个推理运行时或同一套异构计算资源上，让多个模型的任务在时间上重叠执行，从而在有限算力下满足整车实时性要求。

并发推理的定义与本质

并发推理并不等同于“同时算完”。它的本质是资源复用与任务重叠：把多个模型的推理请求拆解为数据搬运、预处理、算子计算、后处理等阶段，通过流水线、批处理、多流并行等方式，让 GPU、NPU、CPU 的不同单元尽量保持忙碌。一个模型在等待内存拷贝时，另一个模型可以占用计算单元；一个模型在跑卷积时，另一个模型可以执行后处理。

从系统视角看，并发推理包含三个层次：模型级并发（多个模型同时驻留显存并交替执行）、请求级并发（同一模型处理多帧或多路输入）、算子级并发（不同算子映射到不同计算单元或流）。自动驾驶中最常见的是模型级并发与请求级并发的组合。

为什么必须并发：必要性与典型场景

自动驾驶对时延极其敏感。以 30 FPS 的感知链路为例，每帧只有约 33 ms 预算，其中可能包含 5 个以上模型。如果串行执行，每个模型平均只有 6 ms，且总延迟等于各模型延迟之和，极易超时。并发推理带来的价值主要体现在：

• 满足帧率约束：通过重叠执行，把总延迟从“求和”压缩到接近“最大值”。
• 提升硬件利用率：避免 GPU 在数据拷贝、后处理阶段空转。
• 支持多传感器融合：摄像头、激光雷达、毫米波雷达的模型需要同步或准同步运行。
• 实现优先级调度：紧急制动相关的模型可以获得更高优先级。
• 降低单位推理成本：批处理和多流并行摊薄调度开销。

典型场景包括：城市 NOA 中同时运行 BEV 检测、Occupancy 网络和轨迹预测；高速场景中同时运行远距检测、车道保持和驾驶员疲劳监测；泊车场景中同时运行环视鱼眼检测、超声波融合和路径规划模型。

并发推理面临的核心挑战

并发不是免费午餐，它会引入新的系统复杂度。主要挑战可以归纳为以下几类：

其中，延迟抖动是最隐蔽的问题。串行推理的延迟相对稳定，而并发推理中，一个低优先级模型的长尾请求可能挤占带宽，导致高优先级模型偶尔超时。因此，并发推理系统必须配套延迟监控和降级策略。

与单模型推理的对比

单模型推理的优化目标通常是单次推理延迟和吞吐，系统结构简单，资源独占，调试容易。多模型并发推理则需要在全局视角下做权衡。二者的关键差异如下：

• 优化目标：单模型追求最低延迟；多模型追求满足截止时间下的系统吞吐与公平性。
• 资源模型：单模型独占或简单共享；多模型需要显存池、流优先级、带宽配额。
• 调度粒度：单模型以请求为单位；多模型需要模型级、流级、算子级多层调度。
• 故障影响：单模型故障影响单一功能；多模型故障可能级联传播。
• 可观测性：单模型指标清晰；多模型需要按模型、按流、按阶段拆分指标。

典型系统架构

一个可落地的多模型并发推理系统通常包含以下层次：接入层负责接收多路传感器数据和推理请求；调度层根据优先级、截止时间和资源状态决定执行顺序；运行时层基于 TensorRT、ONNX Runtime 或自研推理引擎管理多个执行流；资源层负责显存池、CUDA Stream、NPU 队列和带宽分配；监控层采集各模型延迟、吞吐和资源占用，并触发降级。

下面用一张架构图展示多模型并发推理的典型数据流与控制流关系：

在该架构中，调度层是核心。它需要回答三个问题：谁先执行、占用多少资源、何时降级。一个实用的调度策略是：为安全关键模型设置硬截止时间，为舒适性相关模型设置软截止时间；当监控层发现某模型连续超时，自动降低其输入分辨率或跳帧，把资源让给关键模型。

案例与复盘：从串行到并发的改造

某 L2+ 项目最初采用串行推理：BEV 检测 12 ms、激光雷达检测 10 ms、轨迹预测 6 ms、驾驶员监控 4 ms，总延迟 32 ms，加上预处理和后处理，端到端超过 45 ms，无法满足 30 FPS。改造为多流并发后，将四个模型分配到不同 CUDA Stream，并设置优先级：BEV 检测最高，激光雷达次之，轨迹预测和驾驶员监控最低。同时把显存预分配为固定池，避免运行时碎片。改造后，端到端延迟降至 28 ms，GPU 利用率从 55% 提升到 78%。

总结来看，多模型并发推理是自动驾驶推理系统工程的核心能力。它要求工程师同时理解模型特性、硬件资源和调度策略，在延迟、吞吐、公平性和安全性之间找到平衡。掌握并发推理的定义、必要性、挑战、对比和典型架构，是后续深入推理引擎、显存管理和性能调优的基础。