做端到端自动驾驶的人大概都经历过同一个尴尬时刻模型在高速跟车、标准路口直行这类场景里跑得挺稳一进了被大车挡住视线的无保护左转或者小区门口那种两侧停满车的窄路规划出来的轨迹就开始犹豫、顿挫甚至直接原地不动。你回头去看感知输出发现不是检测器不行是那个决定性的目标压根就不在自车视野里——它被挡住了被停在路边的厢式货车挡住了或者干脆还在几百米外的路口另一侧。这篇以《End-to-End Autonomous Driving through V2X Cooperation》为题的工作干的正是把车路协同、车车协同这条“额外视野”链路直接接到端到端自动驾驶模型的骨架上让规划模块在决策时能看到自车传感器看不到的那部分世界。它不是简单的“感知加个路侧相机”而是把协同信息当成网络内部的一种可融合、可退化、可蒸馏的特征来源来处理。下面我按自己做端到端项目时的思路把这篇工作的架构选择、训练策略和工程落地里的坑一层一层拆开讲。1. 单车端到端的天花板和协同链路真正补上的那半块拼图先把概念对齐不然后面全是空谈。很多人第一次听到“端到端自动驾驶”脑子里浮现的是一个大网络输入摄像头图像输出油门刹车方向盘。这个理解不算错但它只是最激进的那一档也是实际工程里最不好调的一档。目前主流可落地的端到端形态是“感知到规划的联合优化”——中间仍然保留 BEV 特征、Agent 查询、地图向量这类结构化表示只是这些表示不再靠人工规则拼接而是由统一损失驱动、端到端反向传播。理解这一点很关键因为协同信息到底该从哪个口子进网络完全取决于你把“端”画在哪里。1.1 端到端不等于“一个网络吃图像出方向盘”我见过不少团队在项目初期把端到端当成一个纯模型问题觉得只要网络够大、数据够多、损失设计够巧规划自然就学会处理遮挡和博弈。实际跑下来会发现端到端模型对“信息缺失”这件事极其敏感而且它的失败方式很难诊断它不会告诉你“我看不见那个横穿的行人”它只会输出一条看起来莫名其妙的减速轨迹你在损失曲线上完全找不到对应的异常点。这就引出一个很现实的问题端到端把中间环节的可解释性换成了整体性能代价是错误归因变难。所以在我的经验里凡是做端到端的团队最后都会老老实实把中间表示打开看——BEV 上那个位置有没有特征、Agent 查询有没有激活、地图向量有没有断。这篇工作把协同特征注入到 BEV 表示这一层本质上就是承认了“中间表示必须可检查、可对齐、可融合”而不是硬憋一个黑箱。你在复现时如果一上来就想去改规划头的结构方向大概率是错的先把融合层的对齐做对收益远比换规划头大。另一个常被忽略的点是端到端模型的训练分布和部署分布差异比传统分模块方案大得多。分模块方案里感知模块的输入永远是当前帧图像分布相对稳定端到端方案里历史帧、自车状态、导航指令、协同信息全都进了网络任何一个通道的统计特性在部署时发生偏移都会直接污染规划输出。协同通道尤其脆弱因为它的可用性是有概率的——通信会断、会延迟、会丢包。这就决定了它必须被设计成一个“可退化”的通道而不是一个“必须有”的输入。1.2 V2X 补的是“看不见”而不是“看不清”我在多个项目里反复确认过一个结论车路协同的增益绝大部分不来自“提高精度”而来自“扩大视野”和“提前时间”。路侧单元架在路口高处能看到自车被遮挡的那一侧前车能提前几百米感知到拥堵尾部这些信息的价值不在分辨率而在“自车传感器物理上够不到”。把这件事量化一下会更清楚。假设自车以 60 km/h约 16.7 m/s行驶前方有一辆厢式货车遮挡自车摄像头能看到的“有效自由空间”被压缩到 30 米左右。这个距离对应的反应时间是 1.8 秒看起来够用。但如果被遮挡区域内有人以 1.5 m/s 横穿从出现在自车可见区域到进入自车行驶走廊可能只有 0.5 到 0.8 秒。这就是典型的“鬼探头”场景单车智能在这个时间尺度上几乎没有安全余量。而路侧单元在这个场景里能提前 1.5 到 3 秒看到那个行人。这个时间差才是协同真正值钱的地方。所以你在设计实验时一定要把评估重点放在“遮挡类场景”和“视野受限路口”而不是在开阔直道上比较协同和非协同的 L2 误差——开阔直道上两者差异很小你很容易得出“协同没用”的错误结论然后把这个方向砍掉。提示评估协同增益时按场景类型分组统计至少要单独看“遮挡路口”“无保护左转”“大车跟车”“视线受阻的汇入”这四类。整体平均指标会把这些场景的增益稀释掉。1.3 两件事合流之后新的问题从哪冒出来端到端加上 V2X不是把两个模块拼起来那么简单它会引入三类新问题而且这三类问题在纯单车方案里都不存在。第一类是坐标系问题。协同方发过来的信息是在它自己的坐标系下表达的。路侧单元有自己固定的安装位姿其他车有实时变化的位姿。你要把这些信息搬到自车的 BEV 网格上中间要串起“协同方坐标系 → 世界坐标系 → 自车当前帧坐标系”这条链任何一环的标定误差或时间戳错位都会让融合特征“糊掉”。糊掉的特征比没有特征更糟糕因为它会给网络提供错误的正激励。第二类是时间不一致问题。不同协同方的数据采集时刻不同传输延迟不同到达自车时的“年龄”不同。你在融合时如果把 300ms 前的他车 BEV 特征和当前帧的自车特征直接拼接网络学到的是错位的信息关联训练时 loss 可能还降得挺好看因为训练集里延迟分布固定一到实车就崩。第三类是可用性问题。协同通道不是永远在的。论文里这类系统通常会设计成“有协同就用、没协同就退化到单车”这个退化过程必须被显式训练不能指望网络自己学会。这就是后面要讲的教师-学生和通道丢弃策略存在的根本原因。2. 协同特征进入网络的通道设计融合发生在第几层决定了系统的上限如果只让我从这篇工作里带走一个工程判断那就是“融合位置的选择比融合模块的结构更重要”。你在感知输出层融合把对方的检测框搬过来实现最简单但信息损失最大而且检测框的类别体系和不确定性完全丢失你在原始传感器层融合把对方的图像拼过来信息最全但带宽和算力都承受不了标定难度也爆表。这篇工作选的是中间那条路——在 BEV 特征层融合用通信传特征、用位姿做对齐、用网络学融合权重。2.1 三种融合位置的真实取舍别只看论文里的漂亮数字我把三种常见融合位置的实际表现整理成一张表这张表里的判断来自我自己做过的对比实验和同行交流的经验不是论文里的数字但方向应该是一致的融合位置传输内容单帧带宽量级对齐难度信息保留度适合的落地阶段感知结果级检测框、跟踪 ID、语义地图几 KB 到几十 KB低只对齐位姿低丢失不确定性与细粒度几何早期验证、低带宽链路BEV 特征级压缩后的 BEV 特征图几百 KB 到几 MB中高位姿时间特征域对齐中高当前主流研究方向原始数据级图像、点云几 MB 到几十 MB极高需精确外参与时同步最高封闭园区、固定路侧为什么特征级是当下的甜点区把带宽算一遍就明白了。假设 BEV 网格是 200×200特征通道 256用 float16 存储单帧大小是 200×200×256×2 字节约 20.5 MB。如果按 10 Hz 传输就是 205 MB/s这个量级在真实车路协同链路上是不现实的。所以论文里这类方案必然要做特征压缩通道降维256 降到 32 或 64、空间下采样200×200 降到 50×50、感兴趣区域裁剪只传自车周围一定范围内的格子、量化float16 到 int8。这几招组合下来通常能把单帧压到几百 KB10 Hz 下就是几 MB/s才算进入可讨论的区间。我自己做过一组压缩对比结论是通道降维比空间下采样更伤性能ROI 裁剪最划算。原因是空间分辨率直接影响小目标的定位精度而通道维度里有很多冗余。所以如果带宽紧张优先砍通道其次砍远处区域最后才动近处的空间分辨率。这个顺序在论文里未必写但工程上非常好用。2.2 BEV 特征对齐位姿链路里每一环误差是怎么被放大的特征级融合最要命的一步是对齐。我给你一个可以直接抄的实现思路。假设协同方发来的是一张 BEV 特征图 $F_c$附带它生成该特征时的自车位姿 $T^{c}{t_c}$协同方在时刻 $t_c$ 的位姿包含位置和朝向以及特征图的网格参数原点偏移、分辨率。自车当前位姿是 $T^{e}{t_e}$。对齐分三步把协同方 BEV 网格上的每个格子中心按网格参数还原到协同方车体坐标系下的坐标用 $T^{c}_{t_c}$ 把这些点变换到世界坐标系用 $(T^{e}_{t_e})^{-1}$ 把世界坐标系的点变换到自车当前车体坐标系再按自车的网格参数落格。如果 $t_c \neq t_e$还要在中间插一步运动补偿用协同方在 $t_c$ 和 $t_e$ 之间的位姿变化把特征“推”到 $t_e$ 时刻。这一步在很多实现里被省略了然后你会看到融合特征在自车转弯时明显错位。误差放大的机制值得单独说。假设协同方定位的横向误差是 0.3 米自车定位误差也是 0.3 米两者独立时融合后的相对误差大概在 0.42 米量级。如果 BEV 分辨率是 0.5 米/格这个误差已经接近一个格子了。而 BEV 特征图上的物体边界通常只有一到两个格子的宽度误差超过半格边界就糊了后续的检测头和规划头拿到的就是一团加宽、模糊的响应。更麻烦的是这个误差是系统性的不是随机的——它会随着两车距离拉大而线性增长因为角度误差乘以距离所以远处区域的融合特征基本是废的。注意如果你的定位链路里用的是纯 IMU 递推加低频全局校正那么两次校正之间的位姿漂移会直接进入融合环节。这种情况下宁可减小融合半径只融合自车周围 30 米内的协同特征也不要强行融合远处。下面这段伪代码是我自己在实验里用的对齐 运动补偿骨架你可以对着改import numpy as np def align_coop_bev(coop_feat, coop_pose_tc, coop_pose_te, ego_pose_te, grid_cfg, out_hw, max_range): coop_feat: [C, Hc, Wc] 协同方发来的 BEV 特征 coop_pose_tc: 4x4 协同方在采集时刻 tc 的位姿世界系 coop_pose_te: 4x4 协同方在自车当前时刻 te 的位姿世界系需插值得到 ego_pose_te: 4x4 自车当前时刻位姿世界系 grid_cfg: 协同方网格参数 {res, x0, y0} out_hw: 输出网格 (H, W) max_range: 只融合自车周围的半径单位米 H, W out_hw res_out grid_cfg[res_out] # 1. 自车输出网格的每个格子中心转到世界系 ys, xs np.meshgrid(np.arange(H), np.arange(W), indexingij) pts_ego np.stack([ (xs - W / 2) * res_out, (ys - H / 2) * res_out, np.zeros_like(xs, dtypenp.float32), np.ones_like(xs, dtypenp.float32), ], axis-1).reshape(-1, 4) pts_world (ego_pose_te pts_ego.T).T # 2. 世界系 - 协同方在 te 时刻的车体系运动补偿后 pts_coop_te (np.linalg.inv(coop_pose_te) pts_world.T).T # 3. 协同方 te 时刻车体系 - 协同方 tc 时刻车体系历史特征所在坐标系 T_te_to_tc np.linalg.inv(coop_pose_tc) coop_pose_te pts_coop_tc (T_te_to_tc pts_coop_te.T).T # 4. 落到协同方特征图网格上做双线性采样 u pts_coop_tc[:, 0] / grid_cfg[res] - grid_cfg[x0] v pts_coop_tc[:, 1] / grid_cfg[res] - grid_cfg[y0] valid (u 0) (u coop_feat.shape[2] - 1) \ (v 0) (v coop_feat.shape[1] - 1) # 超出 max_range 的格子不融合避免远处误差污染 dist np.linalg.norm(pts_world[:, :2] - ego_pose_te[:2, 3], axis-1) valid dist max_range sampled bilinear_sample(coop_feat, u, v) # [N, C] out np.zeros((H * W, sampled.shape[-1]), dtypenp.float32) out[valid] sampled[valid] mask valid.reshape(H, W).astype(np.float32) return out.reshape(H, W, -1), mask这段代码里最关键的不是采样本身而是max_range和mask这两个东西。mask一定要作为额外通道送进融合网络让网络知道哪些格子的协同特征是有效的。我吃过一次教训早期版本没传 mask网络把“零填充”当成了“那里确实没有东西”结果在通信中断的帧上模型对遮挡区域的判断直接反转规划输出一条朝着遮挡区加速的轨迹。加上 mask 之后同样的中断场景模型会退化成保守策略。2.3 通信拓扑和带宽预算决定了你的架构能有多“重”论文里讨论协同通常会涉及通信拓扑是车车直连还是车到路侧再到云还是混合。这个选择不是学术问题是工程约束问题直接决定你的融合频率和融合范围。车车直连的延迟最低几十毫秒量级但覆盖范围随车流密度变化车少的时候没用路侧单元覆盖稳定但部署稀疏出了路口就断两者混合能补上覆盖盲区但你要处理两套时间基准和两套坐标系融合模块得能吃两种来源的特征。我在实际项目里的判断是如果你的目标场景是城市路口优先路侧因为路口恰恰是遮挡最严重、最需要协同的地方如果目标场景是高速或快速路优先车车因为那里没有路侧设施但车流密度高、跟车关系稳定。带宽预算反过来会约束你的模型设计。举个具体的账假设链路可用带宽是 5 MB/s融合频率 10 Hz那么每帧可用 500 KB。500 KB 除以 float16 的 2 字节是 25 万个数值。如果 BEV 空间分辨率定在 100×100覆盖前后 50 米、左右 50 米分辨率 1 米那通道数最多 25。这个通道数够不够我的经验是用于规划决策的协同特征16 到 32 通道基本能保住主要信息再往上收益递减明显。所以如果你的架构设计里融合通道写的是 256那要么你的带宽假设不现实要么你只在仿真里跑过。3. 训练期“看得全”推理期“看得少”教师-学生和退化训练是必需品这是我读这篇工作时最认同的一个设计取向协同信息在训练时通常是完整可得的数据集里各路侧、各车的数据都存着但部署时永远是残缺的。如果你直接拿完整协同数据训一个模型它在推理时遇到协同缺失性能会断崖式下跌而且跌得毫无预兆。解决办法在业界已经比较统一了——用教师-学生框架让“信息完整”的教师去指导“信息残缺”的学生。3.1 为什么不能在训练时就把协同通道随机关掉有人会问那我训练时直接随机丢弃部分协同输入不就让模型适应缺失了吗这个想法方向对但单独用效果一般。原因在于随机丢弃之后学生模型只能靠自己从残缺信息里“猜”出正确答案而规划任务的监督信号非常稀疏往往只有一条专家轨迹模型很难从中学到“缺失的那部分应该怎么补”。教师-学生的价值就在这里。教师模型在训练时能看到完整的协同特征它输出的中间表示BEV 特征、Agent 查询、规划查询或者轨迹分布包含了“如果信息完整世界应该是什么样”的知识。学生模型只看残缺输入但它的中间表示被拉向教师的中间表示。这样一来学生学到的不只是“残缺输入 → 正确轨迹”这个映射还学到了“残缺输入 → 完整世界的表征”这个更有泛化性的映射。具体到损失设计我见过三种做法各有取舍蒸馏对象实现复杂度增益表现适用情况最终轨迹 / 轨迹分布低中等快速验证阶段只想看方向对不对BEV 特征图中较高特征是融合层直接产物监督最直接中间查询 轨迹联合高最高有充足算力、追求极限性能我自己的经验是如果只做一层蒸馏选 BEV 特征如果算力允许加一层规划查询的蒸馏对闭环指标的帮助比开环 L2 更明显。因为开环 L2 主要考核“像不像专家轨迹”而闭环更看重“遇到没见过的状态能不能稳住”后者更依赖中间表征的质量。3.2 通道丢弃策略的细节比“随机丢”三个字复杂得多退化训练的核心是“怎么丢”。我总结了几条实操中验证过的原则按协同源丢不按通道丢。也就是说模拟“某个路侧单元掉线”或“某辆车退出协同”而不是随机把特征图的某些通道置零。按源丢更贴近真实故障模式网络学到的退化策略也更合理。按通道丢会让网络学到“某些通道不重要”这跟实际部署时的失效模式完全不匹配。丢弃概率要分层。我的配置是全协同可用 50%部分协同可用 30%完全无协同 20%。为什么保留 50% 的全协同因为教师蒸馏需要完整的正向样本如果全都是残缺样本学生会失去方向。为什么必须有 20% 的完全无协同因为这是最坏情况必须被显式训练否则一旦真的断链模型的表现会比纯单车模型还差——它已经习惯了有协同突然没了会更慌。丢弃要跟时间相关。真实的通信中断往往持续若干帧而不是单帧随机丢。所以我在实现里用的是“马尔可夫式”的丢弃当前帧是否可用取决于上一帧的状态用一个简单的状态转移矩阵控制。这样训练出来的模型在连续多帧断链的情况下表现明显更稳。class CoopDropoutScheduler: 按协同源做马尔可夫式丢弃模拟真实断链 def __init__(self, sources, p_keep0.95, p_recover0.3): self.state {s: True for s in sources} self.p_keep p_keep # 上一帧可用 - 本帧仍可用 self.p_recover p_recover # 上一帧不可用 - 本帧恢复 def step(self): for s in self.state: if self.state[s]: self.state[s] np.random.rand() self.p_keep else: self.state[s] np.random.rand() self.p_recover # 兜底保证至少 20% 的 batch 处于完全无协同状态在 dataloader 层控制 return dict(self.state)这段逻辑不复杂但它对最终指标的贡献远超我的预期。我在一个路口左转场景上做过消融不做退化训练断链时碰撞率飙升加上按源的马尔可夫丢弃后断链时的表现基本回到纯单车水平而全协同时的增益几乎没有损失。3.3 数据切分和时序标签是最容易被低估的坑协同数据集的切分不能按帧随机切。同一段连续场景里前后帧高度相关随机切分会让训练集和验证集“泄漏”你在验证集上看到的漂亮数字是假的。必须按场景片段切分而且如果数据集包含多个路口、多个时段还要保证验证集里的路口和训练集不重叠否则模型学到的是“这个路口的几何特征”而不是“如何利用协同信息”。时序标签这块坑更深。协同特征是有时间戳的如果你的标签比如未来的规划轨迹是按自车时间轴打的时间戳而输入特征里混着不同时刻的协同信息那么监督信号和输入之间就存在系统性的时间偏移。训练时模型会“学会”利用这个偏移因为偏移在训练集里是固定的部署时延迟分布一变就全乱了。我的处理办法是在数据加载阶段就把所有输入对齐到统一的时间基准自车当前帧并在配置文件里显式记录每个来源的原始时间戳方便后续排查。4. 复现时最耗时间的四类故障一份按现象索引的排查链路论文里的架构图看起来干净实际复现的时候你会有大量时间花在“为什么指标不涨”“为什么训练集收敛验证集不收敛”这类问题上。我把踩过的坑按现象整理成一份排查索引你可以直接拿去对照。4.1 指标不涨反跌先查时间对齐别急着改模型协同方案刚跑通、指标反而比纯单车基线差这是最常见的第一个坎。我的排查顺序是固定的第一步关掉协同通道只跑纯单车基线确认基线本身没问题。听起来很傻但我遇到过两次最后发现是基线复现的配置文件被改坏了跟协同模块一点关系没有。第二步检查时间戳对齐。具体做法是把协同特征和自车特征分别可视化到同一张 BEV 图上找一个静止的显著目标比如路口的杆子、建筑角点看两边是否重合。如果不重合量一下偏移方向和幅度通常是几十毫秒的时间错位造成的。60 km/h 下50 ms 就是 0.83 米的位移在 BEV 上超过一个格子。第三步检查坐标系符号。这个错误极其常见不同来源的坐标系有的是右手系、有的是左手系y 轴朝向、角度正方向都可能不同。我在一个项目里排查了整整两天最后发现是某个来源的朝向角用了顺时针为正而我们默认逆时针。加一个yaw_sign配置项就解决了但那两天真的很难受。第四步检查 mask 有没有传。前面说过零填充必须和“无效”区分开。这四步走完八成的问题能定位。如果还是不行再去看融合模块的结构和初始化。4.2 协同增益只在直道出现弯道和路口全无这个现象特别有诊断价值它几乎总是指向位姿漂移或者运动补偿缺失。直道上两车相对位姿变化小历史特征直接搬过来误差不大一进弯道几十毫秒前采集的特征在自车坐标系里已经转了好几度你不做补偿融合特征就是旋着糊上去的。我的验证方法是在弯道场景里把运动补偿开关做成可配置项分别跑一遍。如果开了补偿指标明显回升问题就确认了。补偿本身不难难的是你拿不到精确的中间位姿——如果协同方只发特征和“当前位姿”你就没法插值出采集时刻到当前时刻之间的运动。解决办法是在数据协议里要求协同方附带位姿序列或者速度、横摆角速度让接收端自己积分。这个协议设计在项目早期定后期改起来很痛苦。另一个隐蔽原因是外参标定误差在弯道被放大。路侧单元的安装外参如果朝向角差 1 度在 100 米外就是 1.7 米的横向误差直道上这个误差表现为整体偏移网络能部分适应弯道上表现为局部形变网络学不会。所以路侧外参一定要定期复核别指望一次标定用一年。4.3 延迟从 80 ms 抖到 400 ms融合策略要怎么改真实链路里的延迟不是常数。我在测试环境里记录到的分布是中位数 80 ms 左右95 分位能到 300 ms极端情况下 400 ms 以上。如果你的融合模块假设延迟恒定那它在长尾情况下的表现会非常差。我的处理分三层第一层时间戳门控。超过一定年龄比如 500 ms的协同特征直接丢弃不要试图融合。老特征提供的信息价值可能还不如带来的错位伤害。第二层年龄编码。把每个协同来源的“特征年龄”作为一个标量编码后拼接到融合特征上让网络自己学会根据年龄调整信任度。这一招效果出乎意料地好实现成本也低。第三层缓存与预测。对高频更新的来源缓存最近几帧用简单的匀速模型外推到当前时刻。这里不要上复杂的预测模型匀速加横摆角速度补偿就够了复杂模型引入的误差反而更大。4.4 训练集漂亮、闭环抖动问题多半在规划层的耦合开环指标比如轨迹 L2 误差、碰撞率和闭环表现之间的相关性比很多人想象的低。我见过开环 L2 降了 15%、闭环舒适度和完成率反而变差的案例。原因通常有两个一是协同特征让模型变得“激进”。模型能从协同信息里提前看到远处空旷于是倾向于加速但它的规划头没有学会处理“协同信息突然中断”的情况一旦中断它已经建立的速度优势收不回来就会出现急刹或者犹豫。二是融合模块和规划模块的梯度冲突。如果融合模块的监督信号比如特征重建损失和规划损失的量级不匹配训练时规划损失会被压制模型学到的融合特征是“好看但不好用”的。我的做法是给融合损失加一个较小的权重并且用梯度裁剪控制它进入主干的反传强度让规划损失主导优化方向。提示判断是不是梯度冲突最快的办法是分别记录融合损失和规划损失的梯度范数。如果融合损失的梯度范数长期高于规划损失基本可以确认存在冲突需要调权重。5. 从论文到能跑的东西一份务实的落地清单读完一篇论文到真正能让代码跑起来中间的差距通常比论文本身厚得多。我把复现这篇工作时认为必须提前定下来的事情列一遍按优先级排。5.1 坐标系和数据协议一定要在写模型之前定死这是我最想强调的一条。协同项目里模型代码可以改数据协议改了要全链路重来。我在协议里固定下来的字段包括每帧的唯一时间戳统一到毫秒级且明确是采集时刻还是发送时刻位姿包含位置、朝向角、以及朝向角的定义方式正方向、零点速度与横摆角速度用于插值和外推BEV 特征图的网格参数分辨率、原点偏移、行列方向特征的编码格式通道数、数据类型、量化方式有效性 mask明确哪些区域是真实观测、哪些是零填充来源标识与帧序号用于做丢包检测和乱序重排。这些字段看起来琐碎但只要缺一个你后面就要花几天去猜。我见过最惨的情况是对方没发帧序号结果乱序到达时整个融合结果都是错的排查了三天才发现。5.2 评估口径开环指标会骗人闭环又跑不动开环评估便宜、快但它只考核“像不像专家轨迹”。协同方案在开环上的增益往往被低估因为开环的专家轨迹本身就是在单车信息下产生的协同提供的额外信息没有对应的“更优轨迹”作为监督。所以只看开环你会觉得协同没什么用。闭环评估能反映真实价值但跑起来慢。我的折中方案是开环做日常回归闭环做阶段性验收。开环阶段重点关注分组指标遮挡场景单列闭环阶段重点关注三类指标——完成率、碰撞率、舒适度加加速度的分布。这三类指标里舒适度最容易被忽略但它是协同方案最容易退化的地方因为融合特征的抖动会直接传导到规划输出。5.3 一份可以照着填的参数速查表下面这些取值是我在复现和调参过程中沉淀下来的“起点值”不是最优值但能让你少走弯路。不同数据集和场景需要微调具体以你的实验结果为准参数建议起点调整方向与说明BEV 网格范围前后 50 m左右 50 m城区路口够用高速需拉长前后向BEV 分辨率0.5 m/格再细带宽吃不消再粗小目标丢失融合通道数32压缩后带宽允许可到 64收益递减融合半径上限40 到 50 m超出后位姿误差主导融合无益协同更新频率10 Hz低于 5 Hz 时决策滞后明显特征年龄门限500 ms超过直接丢弃教师蒸馏权重0.3 到 0.5太高会压制规划损失全协同样本比例约 50%低于 30% 蒸馏失去方向完全无协同比例约 20%必须保留训练退化能力历史帧数3 到 5 帧再多收益小且算力吃紧这张表里我觉得最值得强调的是“完全无协同比例”这一行。很多人在做退化训练时会不自觉地把这个比例设得很低比如 5%觉得“反正是极端情况”。但实测下来20% 左右是性价比最高的区间再低模型就学不会真正的退化策略。5.4 想继续往上做可以从这三个方向切第一个方向是融合的稀疏化。现在主流的做法是稠密 BEV 特征融合但协同信息的价值其实高度集中在少数关键区域被遮挡的那块、路口的那一角。如果能用一个轻量的注意力机制先预测“哪里需要协同信息”再做稀疏传输和稀疏融合带宽能降一个数量级这对落地价值极大。第二个方向是规划层直接消费协同意图。目前的方案基本是把协同信息融合进感知表征再由规划头隐式使用。但如果协同方能直接广播它的意图比如“我准备左转”“我要并线”规划层可以直接把这个意图作为条件输入做交互式决策。这在密集车流里的价值比感知融合更直接也更接近真正的协同驾驶。第三个方向是失效可解释性。协同系统最怕的不是性能不够而是“不知道什么时候不可信”。如果能给融合特征附带一个置信度估计并在置信度低时明确退化到保守策略整个系统的可用性会上一个台阶。这块目前论文里讨论得不多但我认为它是从 demo 走向产品的必经之路。最后分享一个我自己的小习惯每次改完融合模块我都会先把“无协同”和“全协同”两种极端配置各跑一遍看两者的差距。如果差距很小说明融合模块根本没起作用先去查 mask 和梯度如果差距很大但中间态部分协同表现很差说明退化训练不够。这两个极端值就像体温计比看整体指标更快定位问题。踩过几次坑之后我现在打开任何一份协同端到端的实验日志第一眼看的就是这两行数字。 V2X车路协同端到端自动驾驶：BEV融合与退化训练
做端到端自动驾驶的人大概都经历过同一个尴尬时刻模型在高速跟车、标准路口直行这类场景里跑得挺稳一进了被大车挡住视线的无保护左转或者小区门口那种两侧停满车的窄路规划出来的轨迹就开始犹豫、顿挫甚至直接原地不动。你回头去看感知输出发现不是检测器不行是那个决定性的目标压根就不在自车视野里——它被挡住了被停在路边的厢式货车挡住了或者干脆还在几百米外的路口另一侧。这篇以《End-to-End Autonomous Driving through V2X Cooperation》为题的工作干的正是把车路协同、车车协同这条“额外视野”链路直接接到端到端自动驾驶模型的骨架上让规划模块在决策时能看到自车传感器看不到的那部分世界。它不是简单的“感知加个路侧相机”而是把协同信息当成网络内部的一种可融合、可退化、可蒸馏的特征来源来处理。下面我按自己做端到端项目时的思路把这篇工作的架构选择、训练策略和工程落地里的坑一层一层拆开讲。1. 单车端到端的天花板和协同链路真正补上的那半块拼图先把概念对齐不然后面全是空谈。很多人第一次听到“端到端自动驾驶”脑子里浮现的是一个大网络输入摄像头图像输出油门刹车方向盘。这个理解不算错但它只是最激进的那一档也是实际工程里最不好调的一档。目前主流可落地的端到端形态是“感知到规划的联合优化”——中间仍然保留 BEV 特征、Agent 查询、地图向量这类结构化表示只是这些表示不再靠人工规则拼接而是由统一损失驱动、端到端反向传播。理解这一点很关键因为协同信息到底该从哪个口子进网络完全取决于你把“端”画在哪里。1.1 端到端不等于“一个网络吃图像出方向盘”我见过不少团队在项目初期把端到端当成一个纯模型问题觉得只要网络够大、数据够多、损失设计够巧规划自然就学会处理遮挡和博弈。实际跑下来会发现端到端模型对“信息缺失”这件事极其敏感而且它的失败方式很难诊断它不会告诉你“我看不见那个横穿的行人”它只会输出一条看起来莫名其妙的减速轨迹你在损失曲线上完全找不到对应的异常点。这就引出一个很现实的问题端到端把中间环节的可解释性换成了整体性能代价是错误归因变难。所以在我的经验里凡是做端到端的团队最后都会老老实实把中间表示打开看——BEV 上那个位置有没有特征、Agent 查询有没有激活、地图向量有没有断。这篇工作把协同特征注入到 BEV 表示这一层本质上就是承认了“中间表示必须可检查、可对齐、可融合”而不是硬憋一个黑箱。你在复现时如果一上来就想去改规划头的结构方向大概率是错的先把融合层的对齐做对收益远比换规划头大。另一个常被忽略的点是端到端模型的训练分布和部署分布差异比传统分模块方案大得多。分模块方案里感知模块的输入永远是当前帧图像分布相对稳定端到端方案里历史帧、自车状态、导航指令、协同信息全都进了网络任何一个通道的统计特性在部署时发生偏移都会直接污染规划输出。协同通道尤其脆弱因为它的可用性是有概率的——通信会断、会延迟、会丢包。这就决定了它必须被设计成一个“可退化”的通道而不是一个“必须有”的输入。1.2 V2X 补的是“看不见”而不是“看不清”我在多个项目里反复确认过一个结论车路协同的增益绝大部分不来自“提高精度”而来自“扩大视野”和“提前时间”。路侧单元架在路口高处能看到自车被遮挡的那一侧前车能提前几百米感知到拥堵尾部这些信息的价值不在分辨率而在“自车传感器物理上够不到”。把这件事量化一下会更清楚。假设自车以 60 km/h约 16.7 m/s行驶前方有一辆厢式货车遮挡自车摄像头能看到的“有效自由空间”被压缩到 30 米左右。这个距离对应的反应时间是 1.8 秒看起来够用。但如果被遮挡区域内有人以 1.5 m/s 横穿从出现在自车可见区域到进入自车行驶走廊可能只有 0.5 到 0.8 秒。这就是典型的“鬼探头”场景单车智能在这个时间尺度上几乎没有安全余量。而路侧单元在这个场景里能提前 1.5 到 3 秒看到那个行人。这个时间差才是协同真正值钱的地方。所以你在设计实验时一定要把评估重点放在“遮挡类场景”和“视野受限路口”而不是在开阔直道上比较协同和非协同的 L2 误差——开阔直道上两者差异很小你很容易得出“协同没用”的错误结论然后把这个方向砍掉。提示评估协同增益时按场景类型分组统计至少要单独看“遮挡路口”“无保护左转”“大车跟车”“视线受阻的汇入”这四类。整体平均指标会把这些场景的增益稀释掉。1.3 两件事合流之后新的问题从哪冒出来端到端加上 V2X不是把两个模块拼起来那么简单它会引入三类新问题而且这三类问题在纯单车方案里都不存在。第一类是坐标系问题。协同方发过来的信息是在它自己的坐标系下表达的。路侧单元有自己固定的安装位姿其他车有实时变化的位姿。你要把这些信息搬到自车的 BEV 网格上中间要串起“协同方坐标系 → 世界坐标系 → 自车当前帧坐标系”这条链任何一环的标定误差或时间戳错位都会让融合特征“糊掉”。糊掉的特征比没有特征更糟糕因为它会给网络提供错误的正激励。第二类是时间不一致问题。不同协同方的数据采集时刻不同传输延迟不同到达自车时的“年龄”不同。你在融合时如果把 300ms 前的他车 BEV 特征和当前帧的自车特征直接拼接网络学到的是错位的信息关联训练时 loss 可能还降得挺好看因为训练集里延迟分布固定一到实车就崩。第三类是可用性问题。协同通道不是永远在的。论文里这类系统通常会设计成“有协同就用、没协同就退化到单车”这个退化过程必须被显式训练不能指望网络自己学会。这就是后面要讲的教师-学生和通道丢弃策略存在的根本原因。2. 协同特征进入网络的通道设计融合发生在第几层决定了系统的上限如果只让我从这篇工作里带走一个工程判断那就是“融合位置的选择比融合模块的结构更重要”。你在感知输出层融合把对方的检测框搬过来实现最简单但信息损失最大而且检测框的类别体系和不确定性完全丢失你在原始传感器层融合把对方的图像拼过来信息最全但带宽和算力都承受不了标定难度也爆表。这篇工作选的是中间那条路——在 BEV 特征层融合用通信传特征、用位姿做对齐、用网络学融合权重。2.1 三种融合位置的真实取舍别只看论文里的漂亮数字我把三种常见融合位置的实际表现整理成一张表这张表里的判断来自我自己做过的对比实验和同行交流的经验不是论文里的数字但方向应该是一致的融合位置传输内容单帧带宽量级对齐难度信息保留度适合的落地阶段感知结果级检测框、跟踪 ID、语义地图几 KB 到几十 KB低只对齐位姿低丢失不确定性与细粒度几何早期验证、低带宽链路BEV 特征级压缩后的 BEV 特征图几百 KB 到几 MB中高位姿时间特征域对齐中高当前主流研究方向原始数据级图像、点云几 MB 到几十 MB极高需精确外参与时同步最高封闭园区、固定路侧为什么特征级是当下的甜点区把带宽算一遍就明白了。假设 BEV 网格是 200×200特征通道 256用 float16 存储单帧大小是 200×200×256×2 字节约 20.5 MB。如果按 10 Hz 传输就是 205 MB/s这个量级在真实车路协同链路上是不现实的。所以论文里这类方案必然要做特征压缩通道降维256 降到 32 或 64、空间下采样200×200 降到 50×50、感兴趣区域裁剪只传自车周围一定范围内的格子、量化float16 到 int8。这几招组合下来通常能把单帧压到几百 KB10 Hz 下就是几 MB/s才算进入可讨论的区间。我自己做过一组压缩对比结论是通道降维比空间下采样更伤性能ROI 裁剪最划算。原因是空间分辨率直接影响小目标的定位精度而通道维度里有很多冗余。所以如果带宽紧张优先砍通道其次砍远处区域最后才动近处的空间分辨率。这个顺序在论文里未必写但工程上非常好用。2.2 BEV 特征对齐位姿链路里每一环误差是怎么被放大的特征级融合最要命的一步是对齐。我给你一个可以直接抄的实现思路。假设协同方发来的是一张 BEV 特征图 $F_c$附带它生成该特征时的自车位姿 $T^{c}{t_c}$协同方在时刻 $t_c$ 的位姿包含位置和朝向以及特征图的网格参数原点偏移、分辨率。自车当前位姿是 $T^{e}{t_e}$。对齐分三步把协同方 BEV 网格上的每个格子中心按网格参数还原到协同方车体坐标系下的坐标用 $T^{c}_{t_c}$ 把这些点变换到世界坐标系用 $(T^{e}_{t_e})^{-1}$ 把世界坐标系的点变换到自车当前车体坐标系再按自车的网格参数落格。如果 $t_c \neq t_e$还要在中间插一步运动补偿用协同方在 $t_c$ 和 $t_e$ 之间的位姿变化把特征“推”到 $t_e$ 时刻。这一步在很多实现里被省略了然后你会看到融合特征在自车转弯时明显错位。误差放大的机制值得单独说。假设协同方定位的横向误差是 0.3 米自车定位误差也是 0.3 米两者独立时融合后的相对误差大概在 0.42 米量级。如果 BEV 分辨率是 0.5 米/格这个误差已经接近一个格子了。而 BEV 特征图上的物体边界通常只有一到两个格子的宽度误差超过半格边界就糊了后续的检测头和规划头拿到的就是一团加宽、模糊的响应。更麻烦的是这个误差是系统性的不是随机的——它会随着两车距离拉大而线性增长因为角度误差乘以距离所以远处区域的融合特征基本是废的。注意如果你的定位链路里用的是纯 IMU 递推加低频全局校正那么两次校正之间的位姿漂移会直接进入融合环节。这种情况下宁可减小融合半径只融合自车周围 30 米内的协同特征也不要强行融合远处。下面这段伪代码是我自己在实验里用的对齐 运动补偿骨架你可以对着改import numpy as np def align_coop_bev(coop_feat, coop_pose_tc, coop_pose_te, ego_pose_te, grid_cfg, out_hw, max_range): coop_feat: [C, Hc, Wc] 协同方发来的 BEV 特征 coop_pose_tc: 4x4 协同方在采集时刻 tc 的位姿世界系 coop_pose_te: 4x4 协同方在自车当前时刻 te 的位姿世界系需插值得到 ego_pose_te: 4x4 自车当前时刻位姿世界系 grid_cfg: 协同方网格参数 {res, x0, y0} out_hw: 输出网格 (H, W) max_range: 只融合自车周围的半径单位米 H, W out_hw res_out grid_cfg[res_out] # 1. 自车输出网格的每个格子中心转到世界系 ys, xs np.meshgrid(np.arange(H), np.arange(W), indexingij) pts_ego np.stack([ (xs - W / 2) * res_out, (ys - H / 2) * res_out, np.zeros_like(xs, dtypenp.float32), np.ones_like(xs, dtypenp.float32), ], axis-1).reshape(-1, 4) pts_world (ego_pose_te pts_ego.T).T # 2. 世界系 - 协同方在 te 时刻的车体系运动补偿后 pts_coop_te (np.linalg.inv(coop_pose_te) pts_world.T).T # 3. 协同方 te 时刻车体系 - 协同方 tc 时刻车体系历史特征所在坐标系 T_te_to_tc np.linalg.inv(coop_pose_tc) coop_pose_te pts_coop_tc (T_te_to_tc pts_coop_te.T).T # 4. 落到协同方特征图网格上做双线性采样 u pts_coop_tc[:, 0] / grid_cfg[res] - grid_cfg[x0] v pts_coop_tc[:, 1] / grid_cfg[res] - grid_cfg[y0] valid (u 0) (u coop_feat.shape[2] - 1) \ (v 0) (v coop_feat.shape[1] - 1) # 超出 max_range 的格子不融合避免远处误差污染 dist np.linalg.norm(pts_world[:, :2] - ego_pose_te[:2, 3], axis-1) valid dist max_range sampled bilinear_sample(coop_feat, u, v) # [N, C] out np.zeros((H * W, sampled.shape[-1]), dtypenp.float32) out[valid] sampled[valid] mask valid.reshape(H, W).astype(np.float32) return out.reshape(H, W, -1), mask这段代码里最关键的不是采样本身而是max_range和mask这两个东西。mask一定要作为额外通道送进融合网络让网络知道哪些格子的协同特征是有效的。我吃过一次教训早期版本没传 mask网络把“零填充”当成了“那里确实没有东西”结果在通信中断的帧上模型对遮挡区域的判断直接反转规划输出一条朝着遮挡区加速的轨迹。加上 mask 之后同样的中断场景模型会退化成保守策略。2.3 通信拓扑和带宽预算决定了你的架构能有多“重”论文里讨论协同通常会涉及通信拓扑是车车直连还是车到路侧再到云还是混合。这个选择不是学术问题是工程约束问题直接决定你的融合频率和融合范围。车车直连的延迟最低几十毫秒量级但覆盖范围随车流密度变化车少的时候没用路侧单元覆盖稳定但部署稀疏出了路口就断两者混合能补上覆盖盲区但你要处理两套时间基准和两套坐标系融合模块得能吃两种来源的特征。我在实际项目里的判断是如果你的目标场景是城市路口优先路侧因为路口恰恰是遮挡最严重、最需要协同的地方如果目标场景是高速或快速路优先车车因为那里没有路侧设施但车流密度高、跟车关系稳定。带宽预算反过来会约束你的模型设计。举个具体的账假设链路可用带宽是 5 MB/s融合频率 10 Hz那么每帧可用 500 KB。500 KB 除以 float16 的 2 字节是 25 万个数值。如果 BEV 空间分辨率定在 100×100覆盖前后 50 米、左右 50 米分辨率 1 米那通道数最多 25。这个通道数够不够我的经验是用于规划决策的协同特征16 到 32 通道基本能保住主要信息再往上收益递减明显。所以如果你的架构设计里融合通道写的是 256那要么你的带宽假设不现实要么你只在仿真里跑过。3. 训练期“看得全”推理期“看得少”教师-学生和退化训练是必需品这是我读这篇工作时最认同的一个设计取向协同信息在训练时通常是完整可得的数据集里各路侧、各车的数据都存着但部署时永远是残缺的。如果你直接拿完整协同数据训一个模型它在推理时遇到协同缺失性能会断崖式下跌而且跌得毫无预兆。解决办法在业界已经比较统一了——用教师-学生框架让“信息完整”的教师去指导“信息残缺”的学生。3.1 为什么不能在训练时就把协同通道随机关掉有人会问那我训练时直接随机丢弃部分协同输入不就让模型适应缺失了吗这个想法方向对但单独用效果一般。原因在于随机丢弃之后学生模型只能靠自己从残缺信息里“猜”出正确答案而规划任务的监督信号非常稀疏往往只有一条专家轨迹模型很难从中学到“缺失的那部分应该怎么补”。教师-学生的价值就在这里。教师模型在训练时能看到完整的协同特征它输出的中间表示BEV 特征、Agent 查询、规划查询或者轨迹分布包含了“如果信息完整世界应该是什么样”的知识。学生模型只看残缺输入但它的中间表示被拉向教师的中间表示。这样一来学生学到的不只是“残缺输入 → 正确轨迹”这个映射还学到了“残缺输入 → 完整世界的表征”这个更有泛化性的映射。具体到损失设计我见过三种做法各有取舍蒸馏对象实现复杂度增益表现适用情况最终轨迹 / 轨迹分布低中等快速验证阶段只想看方向对不对BEV 特征图中较高特征是融合层直接产物监督最直接中间查询 轨迹联合高最高有充足算力、追求极限性能我自己的经验是如果只做一层蒸馏选 BEV 特征如果算力允许加一层规划查询的蒸馏对闭环指标的帮助比开环 L2 更明显。因为开环 L2 主要考核“像不像专家轨迹”而闭环更看重“遇到没见过的状态能不能稳住”后者更依赖中间表征的质量。3.2 通道丢弃策略的细节比“随机丢”三个字复杂得多退化训练的核心是“怎么丢”。我总结了几条实操中验证过的原则按协同源丢不按通道丢。也就是说模拟“某个路侧单元掉线”或“某辆车退出协同”而不是随机把特征图的某些通道置零。按源丢更贴近真实故障模式网络学到的退化策略也更合理。按通道丢会让网络学到“某些通道不重要”这跟实际部署时的失效模式完全不匹配。丢弃概率要分层。我的配置是全协同可用 50%部分协同可用 30%完全无协同 20%。为什么保留 50% 的全协同因为教师蒸馏需要完整的正向样本如果全都是残缺样本学生会失去方向。为什么必须有 20% 的完全无协同因为这是最坏情况必须被显式训练否则一旦真的断链模型的表现会比纯单车模型还差——它已经习惯了有协同突然没了会更慌。丢弃要跟时间相关。真实的通信中断往往持续若干帧而不是单帧随机丢。所以我在实现里用的是“马尔可夫式”的丢弃当前帧是否可用取决于上一帧的状态用一个简单的状态转移矩阵控制。这样训练出来的模型在连续多帧断链的情况下表现明显更稳。class CoopDropoutScheduler: 按协同源做马尔可夫式丢弃模拟真实断链 def __init__(self, sources, p_keep0.95, p_recover0.3): self.state {s: True for s in sources} self.p_keep p_keep # 上一帧可用 - 本帧仍可用 self.p_recover p_recover # 上一帧不可用 - 本帧恢复 def step(self): for s in self.state: if self.state[s]: self.state[s] np.random.rand() self.p_keep else: self.state[s] np.random.rand() self.p_recover # 兜底保证至少 20% 的 batch 处于完全无协同状态在 dataloader 层控制 return dict(self.state)这段逻辑不复杂但它对最终指标的贡献远超我的预期。我在一个路口左转场景上做过消融不做退化训练断链时碰撞率飙升加上按源的马尔可夫丢弃后断链时的表现基本回到纯单车水平而全协同时的增益几乎没有损失。3.3 数据切分和时序标签是最容易被低估的坑协同数据集的切分不能按帧随机切。同一段连续场景里前后帧高度相关随机切分会让训练集和验证集“泄漏”你在验证集上看到的漂亮数字是假的。必须按场景片段切分而且如果数据集包含多个路口、多个时段还要保证验证集里的路口和训练集不重叠否则模型学到的是“这个路口的几何特征”而不是“如何利用协同信息”。时序标签这块坑更深。协同特征是有时间戳的如果你的标签比如未来的规划轨迹是按自车时间轴打的时间戳而输入特征里混着不同时刻的协同信息那么监督信号和输入之间就存在系统性的时间偏移。训练时模型会“学会”利用这个偏移因为偏移在训练集里是固定的部署时延迟分布一变就全乱了。我的处理办法是在数据加载阶段就把所有输入对齐到统一的时间基准自车当前帧并在配置文件里显式记录每个来源的原始时间戳方便后续排查。4. 复现时最耗时间的四类故障一份按现象索引的排查链路论文里的架构图看起来干净实际复现的时候你会有大量时间花在“为什么指标不涨”“为什么训练集收敛验证集不收敛”这类问题上。我把踩过的坑按现象整理成一份排查索引你可以直接拿去对照。4.1 指标不涨反跌先查时间对齐别急着改模型协同方案刚跑通、指标反而比纯单车基线差这是最常见的第一个坎。我的排查顺序是固定的第一步关掉协同通道只跑纯单车基线确认基线本身没问题。听起来很傻但我遇到过两次最后发现是基线复现的配置文件被改坏了跟协同模块一点关系没有。第二步检查时间戳对齐。具体做法是把协同特征和自车特征分别可视化到同一张 BEV 图上找一个静止的显著目标比如路口的杆子、建筑角点看两边是否重合。如果不重合量一下偏移方向和幅度通常是几十毫秒的时间错位造成的。60 km/h 下50 ms 就是 0.83 米的位移在 BEV 上超过一个格子。第三步检查坐标系符号。这个错误极其常见不同来源的坐标系有的是右手系、有的是左手系y 轴朝向、角度正方向都可能不同。我在一个项目里排查了整整两天最后发现是某个来源的朝向角用了顺时针为正而我们默认逆时针。加一个yaw_sign配置项就解决了但那两天真的很难受。第四步检查 mask 有没有传。前面说过零填充必须和“无效”区分开。这四步走完八成的问题能定位。如果还是不行再去看融合模块的结构和初始化。4.2 协同增益只在直道出现弯道和路口全无这个现象特别有诊断价值它几乎总是指向位姿漂移或者运动补偿缺失。直道上两车相对位姿变化小历史特征直接搬过来误差不大一进弯道几十毫秒前采集的特征在自车坐标系里已经转了好几度你不做补偿融合特征就是旋着糊上去的。我的验证方法是在弯道场景里把运动补偿开关做成可配置项分别跑一遍。如果开了补偿指标明显回升问题就确认了。补偿本身不难难的是你拿不到精确的中间位姿——如果协同方只发特征和“当前位姿”你就没法插值出采集时刻到当前时刻之间的运动。解决办法是在数据协议里要求协同方附带位姿序列或者速度、横摆角速度让接收端自己积分。这个协议设计在项目早期定后期改起来很痛苦。另一个隐蔽原因是外参标定误差在弯道被放大。路侧单元的安装外参如果朝向角差 1 度在 100 米外就是 1.7 米的横向误差直道上这个误差表现为整体偏移网络能部分适应弯道上表现为局部形变网络学不会。所以路侧外参一定要定期复核别指望一次标定用一年。4.3 延迟从 80 ms 抖到 400 ms融合策略要怎么改真实链路里的延迟不是常数。我在测试环境里记录到的分布是中位数 80 ms 左右95 分位能到 300 ms极端情况下 400 ms 以上。如果你的融合模块假设延迟恒定那它在长尾情况下的表现会非常差。我的处理分三层第一层时间戳门控。超过一定年龄比如 500 ms的协同特征直接丢弃不要试图融合。老特征提供的信息价值可能还不如带来的错位伤害。第二层年龄编码。把每个协同来源的“特征年龄”作为一个标量编码后拼接到融合特征上让网络自己学会根据年龄调整信任度。这一招效果出乎意料地好实现成本也低。第三层缓存与预测。对高频更新的来源缓存最近几帧用简单的匀速模型外推到当前时刻。这里不要上复杂的预测模型匀速加横摆角速度补偿就够了复杂模型引入的误差反而更大。4.4 训练集漂亮、闭环抖动问题多半在规划层的耦合开环指标比如轨迹 L2 误差、碰撞率和闭环表现之间的相关性比很多人想象的低。我见过开环 L2 降了 15%、闭环舒适度和完成率反而变差的案例。原因通常有两个一是协同特征让模型变得“激进”。模型能从协同信息里提前看到远处空旷于是倾向于加速但它的规划头没有学会处理“协同信息突然中断”的情况一旦中断它已经建立的速度优势收不回来就会出现急刹或者犹豫。二是融合模块和规划模块的梯度冲突。如果融合模块的监督信号比如特征重建损失和规划损失的量级不匹配训练时规划损失会被压制模型学到的融合特征是“好看但不好用”的。我的做法是给融合损失加一个较小的权重并且用梯度裁剪控制它进入主干的反传强度让规划损失主导优化方向。提示判断是不是梯度冲突最快的办法是分别记录融合损失和规划损失的梯度范数。如果融合损失的梯度范数长期高于规划损失基本可以确认存在冲突需要调权重。5. 从论文到能跑的东西一份务实的落地清单读完一篇论文到真正能让代码跑起来中间的差距通常比论文本身厚得多。我把复现这篇工作时认为必须提前定下来的事情列一遍按优先级排。5.1 坐标系和数据协议一定要在写模型之前定死这是我最想强调的一条。协同项目里模型代码可以改数据协议改了要全链路重来。我在协议里固定下来的字段包括每帧的唯一时间戳统一到毫秒级且明确是采集时刻还是发送时刻位姿包含位置、朝向角、以及朝向角的定义方式正方向、零点速度与横摆角速度用于插值和外推BEV 特征图的网格参数分辨率、原点偏移、行列方向特征的编码格式通道数、数据类型、量化方式有效性 mask明确哪些区域是真实观测、哪些是零填充来源标识与帧序号用于做丢包检测和乱序重排。这些字段看起来琐碎但只要缺一个你后面就要花几天去猜。我见过最惨的情况是对方没发帧序号结果乱序到达时整个融合结果都是错的排查了三天才发现。5.2 评估口径开环指标会骗人闭环又跑不动开环评估便宜、快但它只考核“像不像专家轨迹”。协同方案在开环上的增益往往被低估因为开环的专家轨迹本身就是在单车信息下产生的协同提供的额外信息没有对应的“更优轨迹”作为监督。所以只看开环你会觉得协同没什么用。闭环评估能反映真实价值但跑起来慢。我的折中方案是开环做日常回归闭环做阶段性验收。开环阶段重点关注分组指标遮挡场景单列闭环阶段重点关注三类指标——完成率、碰撞率、舒适度加加速度的分布。这三类指标里舒适度最容易被忽略但它是协同方案最容易退化的地方因为融合特征的抖动会直接传导到规划输出。5.3 一份可以照着填的参数速查表下面这些取值是我在复现和调参过程中沉淀下来的“起点值”不是最优值但能让你少走弯路。不同数据集和场景需要微调具体以你的实验结果为准参数建议起点调整方向与说明BEV 网格范围前后 50 m左右 50 m城区路口够用高速需拉长前后向BEV 分辨率0.5 m/格再细带宽吃不消再粗小目标丢失融合通道数32压缩后带宽允许可到 64收益递减融合半径上限40 到 50 m超出后位姿误差主导融合无益协同更新频率10 Hz低于 5 Hz 时决策滞后明显特征年龄门限500 ms超过直接丢弃教师蒸馏权重0.3 到 0.5太高会压制规划损失全协同样本比例约 50%低于 30% 蒸馏失去方向完全无协同比例约 20%必须保留训练退化能力历史帧数3 到 5 帧再多收益小且算力吃紧这张表里我觉得最值得强调的是“完全无协同比例”这一行。很多人在做退化训练时会不自觉地把这个比例设得很低比如 5%觉得“反正是极端情况”。但实测下来20% 左右是性价比最高的区间再低模型就学不会真正的退化策略。5.4 想继续往上做可以从这三个方向切第一个方向是融合的稀疏化。现在主流的做法是稠密 BEV 特征融合但协同信息的价值其实高度集中在少数关键区域被遮挡的那块、路口的那一角。如果能用一个轻量的注意力机制先预测“哪里需要协同信息”再做稀疏传输和稀疏融合带宽能降一个数量级这对落地价值极大。第二个方向是规划层直接消费协同意图。目前的方案基本是把协同信息融合进感知表征再由规划头隐式使用。但如果协同方能直接广播它的意图比如“我准备左转”“我要并线”规划层可以直接把这个意图作为条件输入做交互式决策。这在密集车流里的价值比感知融合更直接也更接近真正的协同驾驶。第三个方向是失效可解释性。协同系统最怕的不是性能不够而是“不知道什么时候不可信”。如果能给融合特征附带一个置信度估计并在置信度低时明确退化到保守策略整个系统的可用性会上一个台阶。这块目前论文里讨论得不多但我认为它是从 demo 走向产品的必经之路。最后分享一个我自己的小习惯每次改完融合模块我都会先把“无协同”和“全协同”两种极端配置各跑一遍看两者的差距。如果差距很小说明融合模块根本没起作用先去查 mask 和梯度如果差距很大但中间态部分协同表现很差说明退化训练不够。这两个极端值就像体温计比看整体指标更快定位问题。踩过几次坑之后我现在打开任何一份协同端到端的实验日志第一眼看的就是这两行数字。