第一次看到 Fast and Furious 这个标题时我以为是聊电影。后来才发现这是一项自动驾驶感知方案的名字单个卷积网络实时完成 3D 检测、跟踪和运动预测。简单说输入连续几帧 LiDAR 点云网络一次前向直接输出当前时刻所有目标的 3D 框、与上一帧的关联关系以及未来几秒的轨迹。我想把这个方案拆开讲清楚为什么三个任务要绑在一个网络里BEV 鸟瞰图为什么是合适的中介检测头、跟踪头、预测头分别怎么设计以及我在复刻和落地时踩过的那些坑。这套思路放在今天的自动驾驶感知里仍然很有借鉴价值。很多团队做感知还是老式流水线检测、跟踪、预测各跑各的节点单独看每个模块都挺不错一联调就卡壳。而“单网络端到端”这个方向至少在计算效率和信息共享上给出了一个让我很服气的答案。如果你正在做车载感知、点云检测或者多目标跟踪这篇文章应该能给你不少可执行的经验。1. 为什么检测、跟踪、运动预测必须塞进一个网络1.1 传统多模块链路到底慢在哪在很长一段时间里业内做车辆感知是这样一个流程。LiDAR 先跑 3D 检测输出一堆带着置信度的 3D 框跟踪节点拿这些框做数据关联维护目标 ID预测节点再基于历史轨迹外推未来位置。听起来很科学实际一上线就难受。三个节点分别调参检测刷高一点点跟踪就崩跟踪临时多了个缓存预测就延迟排错的时候还得三个模块负责人凑到一起开会。更本质的问题在于每个模块只看到自己需要的中间表达。检测不知道跟踪需要什么样的特征跟踪也不知道预测对轨迹光滑性的要求。信息在这里是被截断的。比如跟踪模块如果只拿 3D 框中心距离做关联那它天然忽略外观、点云分布这些关键线索而这些线索其实在检测的中间特征层都存在。传统流水线根本没有传递这些信息的通道。还有个容易被忽视的问题延迟。假设检测跑 30ms跟踪跑 20ms预测跑 20ms串起来就是 70ms这还没算节点间的序列化和缓存同步。在高速场景下70ms 意味着前车已经往前挪了将近 1 米任何一个环节抖动一下留给下游规划的反应时间就更少。Fast and Furious 这类方案最打动我的地方就是把链路上能看到的所有多余开销全砍掉。1.2 端到端共享特征能省多少事把这些任务塞进一个卷积网络核心不是“把三个 loss 加在一起”这么简单而是让三个任务共用一套 BEV 特征。检测分支可以从共享特征里拿几何上下文跟踪分支可以拿检测分支输出的对齐特征预测分支又能拿到“当前目标在哪、从哪来”的完整信息。这种共享带来的收益比单独训练三个模型然后拼起来高得多。我在复刻类似方案时有个明显感受当跟踪分支和检测分支共享主干后跟踪的鲁棒性比单独训练一个跟踪网络好不少。原因很简单检测分支的反向梯度会逼着主干特征保留更多跟目标形状、朝向、边界相关的信息而这些信息恰好也是区分不同目标身份的关键。主干特征不再是某单一任务的自私特征而是对多个任务都有利的中立表示。计算上的收益更直观。传统做法是三个网络分别前向等于对同一份点云要做三遍特征提取端到端单网络只需要做一遍主干前向三个轻量 head 在共享特征上各自输出结果。模型总参数量没省太多但推理算力和工程部署复杂度省了一大截。1.3 “Fast and Furious”标题里的速度与激情Fast 当然指速度网络前向一次搞定所有感知任务实时性非常好。Furious 则有点双关意味一方面是网络里多个任务并行输出、交互激烈另一方面也呼应了电影《速度与激情》里那种不断逼近极限的感觉。刚开始我以为只是蹭个电影名后来发现这个名字确实贴切全卷积、单次前向、多任务并发追求的就是在车规算力下榨出极限感知延迟。但这并不意味着简单的工程堆叠。多任务并发可能带来任务间梯度冲突、loss 量纲差异、收敛不稳定等问题。真正想做到又快又稳需要在网络结构和训练策略上做很多细致设计。这也是后面几节要重点展开的内容。2. 为什么偏偏选 BEV 鸟瞰图而不是直接吃原始点云2.1 三维点云表示方式的取舍LiDAR 产生的原始点云是一堆无序的三维坐标密度不均匀近处密集、远处稀疏。直接用 PointNet 一类的网络也不是不行但对计算资源和数据组织的要求都比较高。更麻烦的是自动驾驶场景中目标尺寸差异巨大远处一辆车可能只有几个点直接做点级处理很容易漏检。比较成熟的折中方案是先把点云体素化再在体素空间上做稀疏卷积。这当然是一种选择但体素卷积对三维稀疏结构的管理比较重部署到车端时性能优化难度大。Fast and Furious 的做法是再退一步把三维场景压到二维 BEV 鸟瞰图。这个选择牺牲了一部分垂直方向的信息但在结构规则性、卷积效率、部署便利性上获得了巨大回报。我做过一个简单的对比记忆大致是这样一个取舍关系表示方式结构规则性垂直信息保留计算效率部署难度原始点级无序需特殊卷积最完整中高3D 体素规则但稀疏完整中低高BEV 栅格规则稠密部分可通过多通道补偿高低BEV 并不是不用垂直信息而是把垂直信息编码成多个栅格通道后面我会讲到具体做法。这种“降维但不丢关键信息”的设计让整个感知链路可以用标准的 2D 卷积结构去跑工业落地价值非常高。2.2 BEV 栅格化从点云到“俯视图图像”BEV 栅格化其实就是把三维点云投影到地面平面上按网格统计特征。以自车为中心建立一个俯视坐标系X 轴向前Y 轴向左Z 轴向上。假设覆盖范围是左右各 80 米、前后各 80 米分辨率取 0.25 米那就得到一个 640x640 的栅格图。每个栅格单元不像普通图像那样只有 RGB它可以编码很多点云统计量常见的有这么几类点云密度这个单元内有多少个点能反映目标的置信度。最大高度单元内点数最高处的 Z 值能区分车辆、行人、低矮障碍物。高度方差点云高度分布的离散程度对区分地面点和目标点很有帮助。反射强度LiDAR 回波强度对路面车道线、车辆尾灯等有区分度。为了把垂直信息多保留一些还可以把 Z 轴切成多个高度区间比如 0.3 米到 1 米、1 米到 2 米、2 米到 3 米每个区间单独做一层栅格图最后拼成多通道输入。这样车辆的整体轮廓、车顶高度、侧面反射都能在不同通道里体现出来。栅格化看似简单但分辨率、高度切片数量、地面滤波方式都会直接影响后面的感知精度。2.3 全卷积网络在 BEV 上如何组织输入输出有了 BEV 栅格整个问题就变成一个纯 2D 卷积问题。网络主干用类似编码器-解码器的全卷积结构把 640x640 的输入下采样到某个低分辨率再上采样回接近原分辨率保证每个栅格都有对应的稠密输出。这里的关键是“稠密预测”的设计思路每个栅格位置都是一个预测单元网络在每个位置上同时输出多个任务的结果。例如检测头预测该位置是否有目标中心、目标尺寸是多少、朝向角是多少跟踪头预测当前目标与上一帧哪个目标的关联预测头预测未来轨迹偏移。这种设计不需要额外的候选框生成阶段和单阶段目标检测器的逻辑很像速度自然快。看到这里你应该明白BEV 选择的最大价值不是“看起来像图像”而是让 3D 感知变成了成熟的 2D 稠密预测问题。整个计算机视觉界积累的超多卷积网络设计经验都可以直接搬过来用。3. 一个前向里三个任务是怎么同时输出的3.1 检测头从 BEV 特征到 3D 框的“反演”检测头要做的事很直观在 BEV 特征图上判断每个栅格的中心是否对应一个真实目标如果对应就回归出目标的位置、尺寸和朝向。具体输出可以这样拆。中心位置一般用相对于当前栅格中心的偏移量来表示比如 0.5 米分辨率下预测一个 x 偏移和 y 偏移范围控制在栅格内或稍微外溢一点。尺寸输出的是目标底面的长和宽以及高度也就是 BEV 二维框加一个高度值。朝向角是比较容易翻车的部分如果直接回归一个角度值会遇到 0 度和 360 度在数值上接近但在回归空间上距离很大的问题。常见做法是回归 sin 和 cos 两个值再在解码时用反正切恢复出角度。检测头的分类输出不能像二分类那样简单用 sigmoid 就完事。自动驾驶场景中绝大部分栅格都是背景正负样本极不平衡。我的经验是分类分支用 Focal Loss让网络重点关注那些少数有目标的栅格。框回归分支用 Smooth L1放宽异常点的影响。检测头是整个方案最基础的部分跟踪和预测都依赖它提供的目标位置和特征。如果检测头在远处漏掉一个目标后面两个头再强也没用。所以调试时一定要先用可视化确认检测框是否稳定再往下看跟踪和预测。3.2 跟踪头跨帧匹配不是硬关联而是预测关联线索跟踪头的核心是要回答一个问题当前帧这个目标和上一帧哪个目标属于同一个物体传统解决方案是卡尔曼滤波加匈牙利匹配而端到端方案更想直接把关联线索从网络里预测出来。具体有两种常见设计。一种是外观嵌入法对每个检测目标从共享特征里提取一个低维向量让同一目标在不同帧里的向量尽量接近不同目标的向量尽量远离。推理时计算当前帧所有目标与上一帧 tracklet 的相似度矩阵然后做贪心匹配或匈牙利匹配。另一种是中心位移法直接预测上一帧每个 tracklet 在当前帧可能出现的位置再和当前帧检测结果做最近邻匹配。我在实际项目里倾向于两者结合。外观嵌入负责处理外观相似、但位置可能变化较大的目标中心位移负责处理位置连续、但点云外观不太稳定的目标。两者加权成一个匹配得分综合结果比单用任一方法稳定很多。跟踪头在 BEV 特征图上如何实现呢通常会在每个目标中心处抽取一个特征向量等价于一个 RoI 特征或者更简单点直接把整个 BEV 特征图与上一帧特征图对齐后做卷积输出。前者需要小规模矩阵运算后者更贴合纯卷积框架。选择上没有绝对优劣核心是让跟踪任务能够反向传播梯度从而逼着主干特征保留时序判别信息。3.3 运动预测头不仅输出未来位置还要会“刹车”运动预测头输出的是目标未来若干时刻的轨迹。在 BEV 框架下每个目标中心点处再接一个小分支预测未来 K 个时刻相对于当前位置的偏移。比如以 0.5 秒为步长输出未来 3 秒的 6 个轨迹点每个点包含 x 偏移和 y 偏移。但真实场景中运动预测远比“回归未来坐标”复杂。前方车辆有概率直行有概率减速有概率变道某个时刻的状态其实是一个多模态分布单一轨迹无法表达这种不确定性。成熟的方案会引入多分支设计预测 M 条候选轨迹每条轨迹带一个置信度分数训练时用最小损失的那条轨迹来监督让网络自己学会表达不同驾驶意图。还有一个容易忽略的问题场景里大量目标是静止的。停车场里停着一整排车如果运动预测分支一视同仁地回归未来位置网络很容易学成“所有目标未来都不动”的保守策略。我的做法是在预测头里额外加一个二分类判断目标是否处于运动状态。只有被判定为运动的物体才计算轨迹回归损失静止目标只参与分类损失。这个小改动对动态目标的预测精度提升非常明显。3.4 多任务 loss 的加减乘除多任务网络的训练难点往往不在网络结构而在 loss 的组合。检测、跟踪、预测三者的 loss 量纲不一致数值范围也差很多。分类 loss 通常是零点几框回归 loss 可能是几轨迹回归 loss 可能是十几如果不做处理量级大的 loss 直接主导梯度。我常用的做法有三种人工调权重先固定检测 loss 权重为 1然后分别扫描跟踪和预测的权重每跑几个 epoch 看一下指标曲线。不确定性加权让每个任务自己学一个噪声参数loss 除以噪声平方再取对数项。这个方法的优点是省去大量人工调参。渐进式训练先只训练检测头等检测框稳定后再加入跟踪头最后加入运动预测头。多任务同时训练容易互相干扰渐进式训练会稳很多。关于多任务之间的梯度冲突还可以在共享主干到每个 head 的连接处做梯度隔离。比如某些层只让检测任务的梯度通过不让预测任务的梯度污染这样检测特征能保持几何纯净度。这类细节在论文里可能只是一句话但在实际训练中能省掉大量麻烦。4. 训练一个会“预知未来”的网络数据要先想清楚4.1 把一段连续点云变成一个训练样本训练这种端到端网络最基础的一步是构造时间连续的样本。输入是连续 N 帧 LiDAR 点云对应的 BEV 栅格比如过去 5 帧每帧一个输入通道组按时间顺序叠起来。输出既要包括当前帧检测结果也要包括与上一帧的跟踪匹配关系还要包括未来若干帧该目标的真实轨迹。这些 ground truth 从哪来公开的自动驾驶数据集不一定都能满足要求因为很多数据集只有逐帧检测框没有连续目标 ID。想训练跟踪头至少得有目标的跨帧关联真值。如果只有检测真值一种可行的办法是用离线的高精度跟踪算法先跑一遍生成伪标签再用这些伪标签训练网络。但要注意清洗掉漂移和 ID Switch 的样本否则网络会学到错误关联。我习惯在生成训练集时额外存一份“轨迹片段文件”每条轨迹包含目标 ID、每一帧的三元组坐标、尺寸、朝向以及未来轨迹点。这样在训练时按目标 ID 去取数比在线读取多帧标注高效得多。4.2 数据增强旋转和平移必须“全家一起动”BEV 点云增强常见的手段是随机旋转、随机平移、随机缩放、随机丢弃一些点来模拟遮挡。但对于多任务时序网络增强有个非常容易踩的坑若只对当前帧点云做旋转而跟踪真值和未来轨迹没有跟着旋转网络就会学到完全错误的关系。正确的做法是先对整段序列做同一个空间变换。比如绕自车坐标系旋转 15 度那么从第 1 帧到未来最后 1 帧的每个目标位置都要按同一个旋转矩阵做变换目标 ID 不变跟踪关联关系不变未来轨迹点也做同样变换。平移同理所有框和轨迹点要加同一个偏移量。另外可以针对时序做 dropout 增强。训练时随机丢掉某几帧输入让网络学会在帧率不稳定、传感器丢帧的情况下依然保持匹配和预测能力。这个增强在实车上特别重要因为部署环境中的硬件触发抖动远比训练数据集里更常见。4.3 端到端训练的收敛节奏端到端训练一开始会给人一种“三个和尚没水喝”的感觉检测还没学好跟踪头就在瞎猜跟踪头在瞎猜运动预测头又拿不到稳定的目标中心梯度乱撞。所以收敛节奏一定要控制好。我的建议是先固定检测任务主导训练。可以把跟踪和预测的 loss 权重设小一些让网络先学会“知道目标在哪”。等到检测 mAP 基本稳定再逐步增大跟踪 loss让跟踪分支开始要求主干保留更多时序特征。最后再把运动预测权重拉上来。这个过程有点像给队伍加人先把核心成员带起来再让新人逐步参与。如果训练资源充足也可以尝试多头并行但用不同的优化器学习率。比如检测头基础学习率 1e-4跟踪头预测头用 3e-4帮助弱势任务快速追赶。但要注意不能追太猛否则共享主干会被后加的任务带偏。每次调整权重后都要重新验证一下检测指标有没有明显掉点掉点就缩小权重差距。5. 实时性不是靠运气从架构到推理的每一毫秒5.1 用 FLOPs 算一笔账“实时”这个词经常被滥用但落实到工程上要看具体指标。假设 LiDAR 是 10Hz每帧间隔 100ms那么整个感知链路最好在 80ms 内完成留点余量给其他模块。如果老流水线三个模块串行耗了 70ms那么端到端单网络把目标定在 50ms 是合理的。算一笔账以 BEV 输入 640x640主干用 ResNet 风格的编码器加 U-Net 风格的上采样总计算量大约在 40~80 GMAC 之间。在主流车规级边缘计算设备上经过优化后可以做到单帧 30~50ms在更高性能的图形处理器上甚至可以压到 15ms 以内。具体数值取决于分辨率、通道数和模型深度不能一概而论。我自己在复刻时有过一个对比相同检测精度的两个 head一个挂在 BEV 主干之后做共享上采样一个从原始点云分支单独计算共享上采样的延迟能比单分支低 30% 以上。这进一步说明多任务共享不是妥协而是实打实的性能红利。5.2 分辨率与感受野的取舍BEV 分辨率直接决定小目标能占多少个像素。0.5 米分辨率下一辆 4.8 米长的轿车大约占 9~10 个格子算够用但行人只有 0.5 米宽可能只占 1 个格子非常容易漏检。想提升小目标性能可以增加输入分辨率但计算量会像平方一样涨实时性立刻吃紧。另一种思路是保持输入分辨率不变在特征层做高分辨率特征融合。编码器-解码器结构天然会在上采样阶段融合高分辨率低层特征这样行人这类小目标也能在高分辨率特征图上获得一定响应同时整体计算量并没有显著增加。我在项目里就是靠加了一层跨层融合让远距离行人漏检率下降了不少而帧率只掉了 5%。5.3 推理阶段的工程加速手段模型训练完只完成了第一步车载部署还要过工程这一关。我总结几条亲测有效的思路把 BEV 栅格化的预处理搬到 GPU 上完成避免 CPU 到 GPU 之间反复拷贝点云数据。对多任务 head 做算子融合例如把卷积加归一化加激活合并成一个算子减少中小算子的 launch 开销。采用低精度推理FP16 是起步INT8 之后模型体积和延迟能进一步降低但要关注量化后的检测框回退问题。上采样部分用反卷积代替双线性插值加卷积的组合不仅在结构上更统一算子上也更容易被优化工具识别成单一融合算子。实时性优化没有银弹需要从数据预处理、网络结构、推理引擎三个层面一起抠才有效。这个方案之所以叫 Fast也正是因为这些细节都被认真对待过。6. 落到实车上我碰到的几个真坑6.1 角度回归的头快分裂了第一次训练多任务网络时检测头里的朝向角怎么都调不好。车辆朝向接近 180 度的时候真值角度从一个正数跳到另一个负数回归 loss 突然暴涨网络在相邻帧上就发疯似的频繁改判头朝后还是头朝前。后来把单一角度回归换成回归 sin 和 cos 两条通道取反正切得到最终角度这个问题才算彻底稳定。如果你在做类似方案我强烈建议从第一天起就为航向角设计好连续编码不要等到训练完再修。所有角度类回归任务都有这个问题包括目标朝向、轨迹切线的方向都要做循环编码处理。6.2 静止目标太多运动预测直接“躺平”开在快速路上场景里 90% 的可见目标要么是路边停车要么是护栏等静态物体。运动预测头如果按普通回归去训练网络很快学会“所有目标未来位置等于当前位置”因为这样它能在绝大多数样本上拿到很小的 loss。我最后是用“运动分类 动态目标加权”的组合解决的运动预测头先输出一个是否运动的状态只有判定为运动的样本才计入轨迹回归训练时把动态目标的样本权重调高三倍以上把因为静止目标太多导致的类别不平衡压下去。改完以后动态车辆的未来轨迹误差明显降低而静态目标的误判率也没变差。6.3 跟踪 ID 在遮挡后接不回来城市道路上最常见的场景是前方一辆车驶入大车侧后方的盲区短暂消失两秒后再次出现。传统匹配方法只要没有在两秒内找到匹配就把 tracklet 从状态列表里删掉等目标再出现时只能创建一个新 ID。端到端跟踪头在这一点上有它的优势因为外观嵌入是从共享特征里学出来的目标重新出现时哪怕点云稀疏嵌入向量可能依然和之前接近。但前提是 tracklet 生命周期管理要留出足够的“保留期”。具体实现上可以在匹配前先根据目标速度外推一下候选位置扩大搜索范围匹配失败后暂时保留 tracklet 状态而不是立刻删除。遮挡期间网络看不到目标所以特征更新会停滞此时靠几何预测来“续命”非常关键。6.4 可视化是调试多任务最值钱的投资多任务网络的调试难度在于一个指标的下降你很难定位到底是哪个 head 的问题。我踩过很多坑之后得出的结论是一定要在项目早期就做一套完整的可视化工具把 BEV 点云、检测框、跟踪 ID、未来轨迹、ground truth 全部叠加同一张图上按帧播放。我习惯把同一目标的跟踪 ID 固定映射到同一颜色这样逐帧回放时只要颜色发生跳变基本就能判断这一帧出现了 ID Switch。运动预测是否有延迟看轨迹曲线是否贴合真实点云前进方向比看数值指标直观得多。这套可视化工具的成本不高但对排查多任务交互问题至关重要。如果你也在做类似的端到端感知方案建议先拿一段小规模数据跑通整个链路再上大规模训练。先把检测、跟踪、预测各自的验证指标独立跑出来确认单任务没有明显毛病再考虑多任务联合调优。端到端不是魔法它只是把原本割裂的三个问题放回同一个坐标空间让它们互相提供线索真正决定落地效果的还是你对每个任务细节的打磨程度。