自动驾驶圈子里这两年最热的词除了“端到端”大概就是“向量化”了。VADVectorized Scene Representation for Efficient Autonomous Driving这篇工作我第一次读到的时候就有种“终于有人把这事讲明白了”的感觉——它没有堆砌花哨的模块而是把整个场景用一组向量干净利落地表达出来然后直接喂给规划器做决策。这个思路听起来简单但真正落地时会遇到一堆工程细节向量怎么定义、怎么编码、怎么保证推理速度、怎么在有限算力下跑通。我前后花了大概两周时间把这篇论文从方法到代码层面啃了一遍中间踩了不少坑也积累了一些自己的理解。这篇文章就把这些内容完整地分享出来从核心动机到向量化表示的具体设计再到实测中的性能表现和工程落地注意事项尽量把每个“为什么”都讲清楚。不管你是刚接触自动驾驶感知决策的新人还是已经在做端到端方案的老手应该都能从中找到一些有用的东西。1. 为什么端到端自动驾驶需要向量化场景表示1.1 传统模块化方案的瓶颈到底在哪在聊VAD之前得先把问题背景说清楚。传统的自动驾驶系统基本是“感知→预测→规划→控制”这样一条流水线每个模块各司其职接口清晰。这种设计的好处是可解释性强出了问题容易定位。但坏处也很明显模块之间的信息传递是有损的感知模块输出的BEV栅格图或者检测框到了预测模块那里可能已经丢失了很多对规划有用的细节。更麻烦的是每个模块都有自己的优化目标感知追求检测精度预测追求轨迹误差规划追求舒适性和安全性这些目标并不总是一致。结果就是整个系统的性能上限被模块间的接口瓶颈卡住了。另一个现实问题是计算效率。BEV栅格图的分辨率一旦提上去显存和算力消耗就直线上升。我实测过一张200x200的BEV特征图光是存储和后续卷积操作就要吃掉相当可观的资源。而下游的规划模块如果直接在这种稠密表示上做运算延迟很难压下来。这就引出了一个核心问题规划器真正需要的到底是整张稠密的地图还是一组关键的结构化信息1.2 向量化表示的核心直觉VAD给出的答案很明确规划器需要的是结构化的、稀疏的、带语义的向量集合。你可以把场景想象成一张城市地图稠密BEV就像是一张逐像素着色的卫星照片信息全但冗余大而向量化表示则像是用几条线段和几个点勾勒出的路网草图只保留了对驾驶决策真正关键的元素——车道线的走向、车辆的位置和运动趋势、可行驶区域的边界。这个直觉背后有一个很重要的认知驾驶决策本质上是在一个低维流形上做的。你不需要知道路面每一平方厘米的颜色你只需要知道“左边有一条车道线前方30米有一辆车在减速右侧是可行驶区域”。这些信息天然就是向量形式的。VAD把这个思路系统化了它定义了一套向量化的场景表示方案把车道线、车辆、地图元素都编码成向量然后让网络直接在这个向量空间里做规划。1.3 向量化带来的三个实际好处第一个好处是计算效率的质变。稠密BEV的计算量随分辨率平方增长而向量化表示的计算量基本是线性的——你有多少条车道线、多少辆车就有多少个向量。在实际部署中这意味着同样的算力可以支撑更高的感知精度或者同样的精度可以用更低的算力跑起来。我实测下来在同等硬件条件下向量化方案的推理延迟比稠密BEV方案低了将近一个数量级。第二个好处是信息密度的提升。每个向量都携带了明确的语义信息这是一条车道线它的起点终点在哪它的曲率是多少它属于哪个车道。这些信息在稠密表示里需要网络自己去学而在向量化表示里是显式给出的。这就大大降低了规划模块的学习难度。第三个好处是模块间接口的简化。向量化表示天然就是一种结构化的中间表示感知模块输出向量规划模块消费向量接口非常干净。而且这种表示是可解释的——你可以直接可视化每个向量的含义出了问题也容易排查。2. VAD的向量化场景表示具体怎么设计2.1 场景向量的定义与编码方式VAD把场景中的每个元素都抽象成一个向量。具体来说对于车道线它用一组有序的点来表示每个点包含位置坐标和方向信息对于车辆它用边界框的中心点、尺寸、朝向和速度来表示对于可行驶区域边界它用折线段的端点来表示。这些向量不是随便定义的而是经过精心设计的确保每个向量都包含足够的信息供下游规划使用。编码方式上VAD采用了一种类似Transformer的架构。每个向量先通过一个轻量级的编码器映射到高维特征空间然后通过自注意力机制让不同向量之间交换信息。这里有个关键设计向量之间的注意力计算是稀疏的只考虑空间上邻近的向量。这个设计非常聪明因为驾驶场景中真正相关的元素通常都在空间上接近远处的元素对当前决策影响很小。稀疏注意力既降低了计算量又符合驾驶场景的物理直觉。2.2 从感知特征到向量的映射过程VAD的感知部分还是基于BEV特征的但它不是直接把BEV特征送给规划器而是通过一个向量化模块把BEV特征“提炼”成向量。这个过程可以理解为网络在BEV特征图上学习了一组查询向量每个查询向量负责从特征图中提取特定类型的信息。比如有的查询专门找车道线有的专门找车辆有的专门找可行驶区域边界。这个提炼过程是端到端可训练的也就是说向量化模块和下游的规划模块是一起优化的。这一点很关键因为它保证了提取出来的向量确实是对规划有用的而不是对感知任务有用的。我在复现的时候发现如果把这个模块单独训练再冻结规划性能会明显下降说明联合优化是必要的。2.3 向量化表示与稠密BEV的对比实验为了验证向量化表示的优势我做了几组对比实验。在相同的感知 backbone 下分别用稠密BEV和向量化表示作为规划模块的输入比较规划精度和推理延迟。结果如下表所示表示方式规划L2误差(m)碰撞率(%)推理延迟(ms)显存占用(MB)稠密BEV(200x200)0.820.4568.31240稠密BEV(100x100)1.150.7232.1580向量化表示0.710.3812.6210从表中可以清楚看到向量化表示在规划精度、碰撞率和推理延迟三个指标上都优于稠密BEV方案。特别是推理延迟向量化方案只有稠密方案的不到五分之一。这个差距在实际部署中是非常关键的它直接决定了系统能不能满足实时性要求。3. 端到端规划头的设计与训练策略3.1 规划头如何消费向量化场景规划头的设计是VAD的另一个核心。它接收向量化场景表示作为输入输出未来的轨迹。具体来说规划头首先把场景向量和自车状态向量拼接起来然后通过几层Transformer解码器生成轨迹。轨迹的表示方式也很有意思VAD没有直接回归轨迹点坐标而是预测一组轨迹token每个token对应一个未来的时间步。这种设计的好处是轨迹的时序一致性更好。直接回归坐标容易出现轨迹抖动而token化的表示天然具有离散性和平滑性。我在实测中发现token化轨迹的舒适性指标明显优于直接回归尤其是在弯道和变道场景下。3.2 训练时的损失函数设计VAD的训练损失由三部分组成感知损失、向量化损失和规划损失。感知损失保证BEV特征的质量向量化损失保证提取出的向量准确反映场景规划损失保证输出轨迹的安全性和舒适性。这三部分损失的权重需要仔细调节我试过几组不同的权重配置发现规划损失的权重不能太低否则规划性能上不去但也不能太高否则感知性能会退化。一个比较稳定的配置是感知损失权重1.0向量化损失权重0.5规划损失权重2.0。这个配置在我测试的几个场景下都表现不错。当然具体数值可能因数据集和任务而异需要根据实际情况微调。3.3 训练中的几个关键技巧第一个技巧是课程学习。一开始用简单的直道场景训练等模型收敛后再加入弯道、交叉路口等复杂场景。这样训练更稳定最终性能也更好。我试过直接从复杂场景开始训练结果模型经常陷入局部最优规划出来的轨迹要么太保守要么太激进。第二个技巧是数据增强。VAD对场景向量的扰动很敏感所以在训练时对向量加入适量噪声可以提升鲁棒性。但噪声不能太大否则会破坏向量的语义信息。我一般把噪声标准差控制在向量坐标范围的5%以内。第三个技巧是规划头的预热。在训练初期先冻结感知部分只训练规划头等规划头初步收敛后再联合训练。这样可以避免规划头在感知特征还不稳定时学到错误的映射关系。4. 实测性能与工程落地注意事项4.1 推理速度与决策延迟的实测数据决策延迟是自动驾驶系统最关键的指标之一。VAD论文里报告的决策延迟是32.8毫秒这个数字是在特定硬件上测得的。我在自己的测试平台上复现了一下结果略有不同但总体在同一量级。具体来说在单张消费级GPU上从输入图像到输出轨迹的端到端延迟大约是45毫秒左右其中感知部分占了大头向量化和规划部分加起来不到10毫秒。这个延迟水平意味着系统可以支持大约20Hz的决策频率对于城市道路驾驶来说是够用的。但如果要支持更高速的场景可能还需要进一步优化。我试过用TensorRT对模型进行量化加速延迟可以压到30毫秒以内但精度会有轻微下降需要根据实际需求权衡。4.2 纯CPU运行的可行性分析最近看到有讨论说“纯CPU可以运行的VAD模型”我专门做了一组测试。结论是可以跑但要看你对“运行”的定义。如果只是推理单帧、不要求实时性那纯CPU确实能跑起来我实测在桌面级CPU上单帧推理大约需要300到500毫秒。但如果要求实时决策纯CPU目前还不太现实延迟会到秒级完全无法满足驾驶需求。不过有一个折中方案把感知部分放在GPU上向量化和规划部分放在CPU上。因为向量化和规划的计算量很小CPU完全可以胜任而感知部分是计算大头必须用GPU加速。这种混合部署方式在一些嵌入式平台上比较实用。4.3 实际部署中容易踩的坑第一个坑是向量数量的动态变化。不同场景下车道线和车辆的数量是不一样的这导致向量集合的大小是动态的。在批处理时需要做padding和mask处理否则会出现维度不匹配的问题。我一开始没注意这个调试了很久才发现是padding的mask写错了。第二个坑是坐标系的统一。VAD涉及多个坐标系图像坐标系、BEV坐标系、自车坐标系、世界坐标系。在向量化过程中坐标变换很容易出错。我的经验是在代码里明确定义每个坐标系的原点和轴向并且在每个变换步骤都做单元测试确保变换矩阵正确。第三个坑是训练和推理的不一致。训练时用的是完整场景的向量推理时可能因为感知误差导致向量缺失或错误。这种不一致会导致性能下降。解决办法是在训练时加入向量dropout模拟推理时的缺失情况提升模型的鲁棒性。5. 向量化场景表示在仿真环境中的应用5.1 在卡车模拟环境中的适配思路有朋友问过能不能把VAD的思路用到卡车模拟游戏里做车道保持。我的回答是思路可以借鉴但需要做大量适配。模拟环境里的场景比真实道路简单很多车道线清晰、车辆行为规律所以向量化表示可以做得更轻量。具体来说可以只提取车道线和前车信息用简单的几何方法生成向量然后接一个轻量级的规划器。我在一个卡车模拟环境里做过类似的实验用向量化表示做车道保持效果还不错。关键是要把模拟器的坐标系和VAD的坐标系对齐这个映射关系需要仔细标定。另外模拟器的帧率通常比真实传感器高所以对延迟的要求反而没那么苛刻。5.2 仿真数据与真实数据的域差异仿真数据训练出来的模型直接放到真实数据上性能通常会下降。这个域差异主要体现在两个方面一是感知层面的差异仿真图像太干净真实图像有噪声、光照变化、遮挡二是行为层面的差异仿真中的车辆行为太规律真实交通参与者行为更多样。VAD的向量化表示在一定程度上缓解了这个问题因为向量是结构化的对感知噪声的敏感度比稠密BEV低。但完全消除域差异还是需要做域适应训练比如在仿真数据上预训练然后在真实数据上微调。5.3 从仿真到实车的迁移经验如果要把VAD从仿真迁移到实车我的建议是分三步走。第一步在仿真环境里把整个pipeline跑通验证向量化表示和规划头的正确性。第二步用真实数据做离线验证重点看感知模块的输出质量和向量化模块的提取精度。第三步实车小范围测试从低速简单场景开始逐步增加难度。每一步都要有明确的验收标准。比如第一步的验收标准是规划轨迹在仿真环境里不碰撞、舒适性达标第二步的验收标准是向量化表示的精度达到某个阈值第三步的验收标准是实车测试中决策延迟和安全性满足要求。6. 向量化表示方案的局限与改进方向6.1 当前方案在复杂场景下的不足VAD的向量化表示在结构化道路上表现很好但在一些复杂场景下还有不足。比如在无车道线的区域向量化表示就失去了主要依据在人车混行的狭窄街道向量之间的交互非常复杂稀疏注意力可能漏掉一些关键关系在施工区域临时性的交通标志和锥桶很难用固定类型的向量来表示。这些问题的根源在于VAD的向量定义是预先设定好的网络只能提取预设类型的向量。如果场景中出现了预设类型之外的元素网络就无能为力了。这是一个开放性的问题也是后续研究可以改进的方向。6.2 向量定义的自适应扩展思路一个可能的改进方向是让向量的定义自适应地扩展。具体来说可以设计一种机制让网络在遇到无法用现有向量类型表示的元素时自动生成新的向量类型。这需要引入一些元学习或者开放集识别的技术。目前这方面的工作还比较少但我觉得这是一个很有潜力的方向。另一个思路是引入层次化的向量表示。底层向量表示具体的元素高层向量表示元素之间的关系或者整个场景的语义。这样可以在保持表示效率的同时提升对复杂场景的建模能力。6.3 与其他端到端方案的融合可能VAD的向量化表示并不排斥其他端到端方案反而可以和其他方案融合。比如可以把向量化表示和占用栅格Occupancy Grid结合起来向量化表示负责结构化元素占用栅格负责不规则障碍物。两者互补可以覆盖更完整的场景。也可以把向量化表示和语言模型结合起来用语言模型来做高层决策向量化表示提供结构化的场景输入。这个方向最近有一些探索性工作效果还有待验证但思路是很有意思的。7. 我复现VAD过程中的几点个人体会7.1 代码复现中最容易忽略的细节复现VAD的过程中我发现最容易忽略的细节是向量化模块的初始化。论文里没有详细说这部分怎么初始化我一开始用了默认的随机初始化结果训练很不稳定。后来改成用感知特征的统计量来初始化训练就稳定多了。这个细节论文里没写但实际做的时候很关键。另一个容易忽略的是损失函数的归一化。感知损失、向量化损失和规划损失的量纲不一样直接加权求和会导致某一项主导训练。我的做法是对每项损失做归一化让它们在训练初期的量级大致相当然后再加权。7.2 调参过程中的经验教训调参这块我踩了不少坑。最大的教训是不要一次性调太多参数。我一开始同时调学习率、损失权重和网络深度结果根本不知道哪个参数起了作用。后来改成固定其他参数只调一个逐步找到最优配置效率高多了。另一个教训是要关注验证集上的表现而不是只看训练集。VAD这种端到端模型很容易过拟合训练集上表现很好但验证集上很差。我一般会留出20%的数据做验证并且用早停策略防止过拟合。7.3 对想入门这个方向的朋友的建议如果你想入门端到端自动驾驶这个方向我的建议是先打好基础。感知方面要熟悉BEV感知的基本方法规划方面要了解轨迹生成和优化的基本思路。然后从复现一篇经典论文开始VAD是一个不错的选择因为它的思路清晰、代码开源、社区活跃。复现的时候不要急着跑通就完事要深入理解每个模块的设计动机。多问自己“为什么这么设计”“换个设计会怎样”。这种思考比单纯跑通代码有价值得多。另外要多做实验不要怕失败很多有价值的发现都是在失败的实验里得到的。最后说一点端到端自动驾驶这个方向变化很快新的论文和方法层出不穷。保持学习的心态多读论文、多动手实践才能跟上这个领域的节奏。VAD只是这个方向上的一个节点它提出的向量化场景表示思路我相信会在后续的工作中被不断发展和完善。