🚗 自动驾驶仿真与感知

闭环评测：Bench2Drive 协议与成败案例

Closed-Loop Eval: The Bench2Drive Protocol & Case Studies

13 章·8 分钟·9 篇技术深读

开环 vs 闭环

两种评测的本质区别

维度	开环 (Open-loop)	闭环 (Closed-loop)
数据来源	回放预录数据集	实时仿真，Agent 决策驱动
Agent 行为影响环境？	否	是
评测指标	L2 轨迹偏差（ADE/FDE）	Driving Score（路线完成 + 违规惩罚）
协议感受性	不暴露累积误差	暴露所有累积误差
计算成本	低（一次前向）	高（持续运行 CARLA）

开环为什么不够

开环评测的流程：给定 nuScenes/NAVSIM 的图像序列 → 模型预测轨迹 → 和数据集里记录的真实轨迹比 L2 误差。问题：

预测不影响后续输入

模型在第 $t$ 帧预测了一条偏离 GT 的轨迹，但第 $t+1$ 帧的输入仍然是 GT 轨迹对应的图像——回放数据集不会因为模型走偏而改变。这掩盖了一个致命问题：累积误差。

真实驾驶里，第 $t$ 帧的偏离会让第 $t+1$ 帧看到完全不同的场景（车开到了别的位置），进而触发连锁反应。开环评测看不到这种连锁——它在”平行宇宙”里评测，假设模型永远在 GT 轨迹上。

L2 误差不等于安全

两条轨迹 L2 误差都是 0.5 米，但：

一条在宽阔直道上偏 0.5 米——没事。
一条在窄桥上偏 0.5 米——掉下桥。

L2 误差是平均距离，抹平了场景依赖性。开环没法区分这两种情况。

闭环的真实性

闭环评测里，模型的每个决策真实执行：

第 $t$ 帧模型输出轨迹 → Pure Pursuit 转成 apply_control → CARLA 物理执行 → Ego 真的移动。
第 $t+1$ 帧 CARLA 根据 Ego 新位置渲染图像——如果 $t$ 帧走偏了， $t+1$ 帧看到的场景就变了。
碰撞、违规真实发生，被事件检测器记录。

这种”决策影响环境、环境影响下一帧决策”的循环，是真实驾驶的本质。闭环评测忠实反映了模型的实际驾驶能力，包括累积误差、长尾失败、对场景的鲁棒性。

闭环的代价

闭环评测远比开环贵：

算力：每条路线要持续跑几千帧，每帧一次完整 CARLA 渲染 + 模型推理。220 条路线全跑完需要几十甚至上百 GPU 小时。
时间：实时跑（20 Hz）一条路线要几分钟到几十分钟，220 条是几十小时。
不可重现的随机性：闭环里 NPC 行为有随机性（TM 的概率参数），同一模型两次跑可能分数略不同。要多次平均。

这是为什么很多方法只做开环——闭环太贵。SparseDriveV2 是少数两种都做的方案，这本身是工程实力的体现。

闭环暴露的失败模式

闭环评测特有的失败（开环看不到）：

累积偏离：每帧小偏差，几百帧后大幅偏离车道。
场景依赖崩溃：在某种场景（弯道、特定天气）下系统性失败，开环的平均指标被多数场景稀释。
交互失败：和 NPC 的博弈失败（如 cut-in 时没让速），开环里 NPC 走 GT 轨迹不会触发。

EP06 的失败案例（ALG 域差、SCN 场景几何）就是闭环才暴露的——开环平均分数高，但闭环里某些场景直接失败。

参考

Bench2Drive：考试协议

Bench2Drive 是什么

Bench2Drive（2024 年 arXiv，NeurIPS 2024）是建立在 CARLA Leaderboard 2.0 之上的标准化闭环考试协议。它的目标是：给端到端自动驾驶模型一个统一、可复现、覆盖面广的闭环评测。

协议核心是把”跑一圈看分数”这个黑盒标准化成五步流水线：

① 加载 checkpoint  →  ② 连 CARLA + 同步模式  →  ③ 加载路线  →  ④ Agent 自动驾驶  →  ⑤ 汇总分数

220 条路线，44 种场景

Bench2Drive 预定义了 220 条测试路线，覆盖 44 种交互场景。每条路线是一条从起点到终点的行驶路径，沿途会触发预定的场景（由 ScenarioRunner 的行为树编排）。

44 种场景覆盖自动驾驶的主要交互类型：

类别	场景示例
切入/切出	`cut_in_left`、`cut_in_right`、`opposite_lane_cut_in`
横穿	`object_crossing`、`pedestrian_crossing`
路口	`junction_left_turn`、`junction_right_turn`、`signalized_junction`
超车/让行	`overtake`、`yield_to_emergency_vehicle`
静态障碍	`static_object`、`construction`
…	共 44 种

220 条 = 44 种场景 × 5 条左右变种（不同地图、不同天气、不同触发位置）。这种覆盖让评测不只看平均分，还能看每种场景的专项能力——模型在哪类交互上弱。

五步流水线详解

① 加载 checkpoint

model = SparseDriveV2(cfg)
model.load_checkpoint('sparsedrive_v2.pth')
model.eval()

加载训练好的模型权重，设成 eval 模式（关闭 dropout/batchnorm 更新）。

② 连 CARLA + 同步模式

client = carla.Client('localhost', 2000)
world = client.get_world()
settings = world.get_settings()
settings.synchronous_mode = True
settings.fixed_delta_seconds = 0.05   # 20 Hz
world.apply_settings(settings)

同步模式是闭环评测的前提（EP03 详述）——保证时序确定、可复现。

③ 加载路线

route = load_route('Town04_cut_in_right_001.xml')
tm = client.get_trafficmanager(8000)
tm.set_synchronous_mode(True)
scenario_runner = ScenarioRunner(world, route, tm)  # 行为树编排 NPC

路线 XML 定义了起点、终点、沿途触发的场景。ScenarioRunner 把这些转成 py_trees 行为树，按 Ego 的位置触发对应 NPC 动作。

④ Agent 自动驾驶

每 50 ms（一帧）：

while not route_finished:
    world.tick()                              # 推进仿真
    images = collect_six_cameras()             # 6 路图像
    trajectory = model.infer(images)           # 模型推理
    control = pure_pursuit(trajectory, ego)    # 轨迹跟踪
    ego.apply_control(control)                 # 执行控制
    check_violations(frame)                    # 违规检测

Agent 完全自主决策，没有任何 GT 辅助——这就是”考试”。

⑤ 汇总分数

220 条路线跑完，每条都有 Route Completion 和 Infraction 记录，汇总成三个核心分数（详见 B06）：

Driving Score (DS)：综合路线完成 + 违规惩罚。
Route Completion (RC)：平均路线完成率。
Success Rate (SR)：完整跑完路线的比例。

为什么是 220 条而不是更多

220 是覆盖度和评测成本的平衡：

太少（如 44 条）：每种场景只 1 条，方差大、不够鲁棒。
太多（如 1000 条）：跑完全套要上百 GPU 小时，迭代慢。

220 条让每种场景平均 5 条，统计上稳定，又能在一夜跑完。这是 Bench2Drive 工程上的妥协。

参考

闭环评测流水线

单帧流水线

每帧（50 ms）的完整数据流，和 EP03 的 tick 循环一致，但闭环评测额外强调违规检测：

world.tick()                       ① 仿真推进 0.05s
       │
       ▼
6 相机同步采集                      ② 传感器采样（同 frame ID）
       │
       ▼
SparseDriveV2 推理                 ③ 感知 → 建图 → 规划
       │
       ▼
Pure Pursuit → apply_control       ④ 轨迹转控制，发给 Ego
       │
       ▼
check_violations(frame)            ⑤ 违规检测（每帧都查）
       │
       ▼
（下一帧）

注意违规检测是每帧进行的，不是事后总结。碰撞检测器、Lane Invasion 检测器在事件发生那一帧就触发回调，把违规记进日志。这是闭环评测能精确归因的前提。

违规检测的几种机制

违规	检测方式	触发时机
碰撞（车/人/物）	`sensor.other.collision` 检测器	碰撞瞬间
压线	`sensor.other.lane_invasion` 检测器	轮子压线
闯红灯	协议层判断（红绿灯状态 + 停车线）	Ego 越线时
偏离路线	协议层判断（Ego 位置 vs 路线多边形）	持续偏出
超时	时间统计	超过路线时限

前两个用 CARLA 的物理事件检测器（EP02 详述），后三个是 Bench2Drive 协议层自己实现的——因为它们依赖 OpenDRIVE 拓扑和路线定义，CARLA 单个传感器判不了。

220 条路线的批处理

闭环评测不是跑一条就完，是220 条全跑：

results = []
for route_xml in all_220_routes:
    reset_world(world)                    # 重置仿真状态
    load_route(route_xml)                 # 加载路线和场景
    route_result = run_one_route(model, world, route_xml)  # 跑完整条
    results.append(route_result)

final_score = aggregate(results)          # 汇总成 DS/RC/SR

每条路线之间要彻底重置：

销毁所有上一轮的 Actor（Ego、NPC、传感器）。
重置 TM 状态。
重新 spawn Ego 和加载新路线的 NPC。

漏掉重置会导致状态泄漏（上一轮的 NPC 还在，干扰下一轮），分数不可信。

评测的可复现性要求

Bench2Drive 要求同一 checkpoint 两次评测分数接近。这要求：

同步模式：保证时序确定。
TM 同步：NPC 行为和 Server 同步。
固定随机种子：TM 的概率参数（闯红灯概率等）用固定种子，否则两次跑 NPC 行为不同。
CARLA 版本固定：不同 CARLA 版本物理略有差异，要锁定版本。

即使如此，闭环评测仍有少量随机性（浮点累积、TM 内部抖动），所以严格对比时要多次跑取平均。

50 ms 硬截止的实际意义

每帧必须在 50 ms 内完成推理和控制，否则：

推理超时 → tick() 卡住 → 仿真冻结（EP03 详述）。
强行降频 → 控制响应慢，可能撞车。

SparseDriveV2 的 sparse + scoring 设计让推理能在预算内完成（详见 EP05 的 Coarse-to-Fine）。如果模型推理要 100 ms，要么被迫降到 10 Hz（控制变糙），要么超时被判失败。这是为什么”轻量高效”不只是工程优化，是闭环可行的硬要求。

易错点

重置不彻底：上一轮 NPC 残留污染下一轮，分数虚低。
违规检测漏挂：忘记挂 collision 检测器，碰撞不计分——分数虚高但无效。
超时阈值设错：路线时限太短，正常驾驶也判超时。

参考

违规与扣分公式

Driving Score 的定义

Bench2Drive（继承 CARLA Leaderboard 2.0）的最终分数：

$\boxed{\text{Driving Score} = \text{Route Completion} \times \text{Infraction Penalty}}$

Route Completion (RC)：路线完成率， $[0, 1]$ 。Ego 走了路线全长的百分比。
Infraction Penalty：违规惩罚系数，所有违规的乘积。

注意是乘法——一次严重违规就能把分数砍半，不会因为”开得远”被稀释。这体现了”既要开得远，又要开得安全”。

各违规的惩罚系数

来自 CARLA Leaderboard 2.0 的标准定义（Bench2Drive 完全沿用）：

违规类型	惩罚系数	说明
碰撞行人	$\times 0.50$	最严重
碰撞车辆	$\times 0.60$
碰撞静态物体	$\times 0.65$
闯红灯	$\times 0.70$
闯 stop sign	$\times 0.80$
偏离路线车道	$\times 0.95$ （按时间窗累乘）	持续违规

碰撞是一次性事件：发生一次就乘一次系数。压线/偏离是持续违规：每持续一段时间（时间窗）就乘一次 $\times 0.95$ ，所以压线越久惩罚越重：

$\text{Infraction Penalty} = \prod_{i \in \text{碰撞}} c_i \times \prod_{j \in \text{红灯}} 0.7 \times 0.95^{N_{\text{lane windows}}}$

一个数值例子

假设一条路线：

Route Completion = 0.95（走了 95%）。
撞了一次车： $\times 0.60$ 。
闯了一次红灯： $\times 0.70$ 。
压线持续了 3 个时间窗： $0.95^3 \approx 0.857$ 。

$\text{DS} = 0.95 \times 0.60 \times 0.70 \times 0.857 \approx 0.342$

满分 1.0，这一条路线只有 0.342。可见违规的乘法惩罚非常严厉——一次撞车 + 一次闯灯就砍到三分之一。这就是为什么闭环评测区分”开得远”和”开得好”。

超时的特殊处理

超时不进乘法公式，而是直接判该路线零分：

$\text{若超时：} \text{DS} = 0$

为什么这么严？因为超时通常意味着模型卡住了（在路口死等、原地不动），这种”开不动”比”开得慢但安全”严重得多——它根本没在完成任务。乘法惩罚对超时不合适（超时 RC 可能还很高），所以单独判零。

Bench2Drive 对 Leaderboard 的修改

Bench2Drive 在 Leaderboard 2.0 基础上做了一处调整：移除了 minimum speed penalty（最低速度惩罚）。原 Leaderboard 2.0 会惩罚开得太慢（低于某速度就扣分），但 Bench2Drive 认为端到端模型安全优先，慢一点不该扣分，所以去掉了这条。

另外 Bench2Drive 把 TickRunTime（单路线最大帧数）从 2000 扩展到 4000，给模型更多时间完成长路线。

三个核心分数

汇总 220 条路线后，得到三个指标：

指标	计算	含义
Driving Score (DS)	所有路线 DS 的平均	综合能力
Route Completion (RC)	所有路线 RC 的平均	开得远不远
Success Rate (SR)	完整完成路线的比例	完成能力

SparseDriveV2 的 DS 89.15 意味着平均每条路线的”完成率 × 违规惩罚”是 0.8915——这是个非常高的分数（多数方案在 0.5–0.7）。

易错点

乘法 vs 加法：误以为是加法（扣分）会导致严重低估惩罚力度。乘法让多次违规指数级扣分。
RC 上限是 1.0：即使开过头了也不会超过 1，所以 DS 上限就是 1.0。
碰撞类型区分：撞行人和撞车惩罚不同，撞行人更重——这反映了交通伦理优先级。

参考

失败案例一：ALG 域差（弯道）

什么是 ALG 类失败

Bench2Drive 的自动诊断脚本（verify_batch）把每个失败 case 归到三类身份（EP07 详述）：

ENG（工程）：参数控制问题，改配置能修。
ALG（算法）：模型本身的局限，要重训或微调。
SCN（场景）：Bench2Drive 场景设计问题，不是模型的错。

ALG 类失败的特征是：模型在某个数据分布外的场景上系统性失败，不是偶发 bug。

这个失败案例的现象

Town04 的弯道路段，Ego 进入弯道后：

SparseDriveV2 输出近乎直线的轨迹（在弯道上该转弯却没转）。
自动诊断显示：steer 全程为 0（控制层从未发转向指令）。
81% 的 tick 已 off-road（绝大多数帧车都在路外）。

这是一个典型的”模型看不见弯道”的失败。

根因：训练数据的域差

SparseDriveV2 在 nuScenes 和 NAVSIM 数据上训练。这两个数据集的特点：

nuScenes：波士顿、新加坡城市采集，以直道和缓弯为主，急弯极少。
NAVSIM：聚合多个数据集，同样以常规城市直道为主。

模型从这些数据学到的”驾驶先验”是：大部分时候直行就行，偶尔微调方向。它在训练分布内表现优秀（NAVSIM EPDMS 90.1），但分布外（OOD）的 CARLA Town04 急弯上，模型没见过这种几何，输出的轨迹自然偏向它熟悉的”直行”。

形式化地说，设训练数据分布为 $P_{\text{train}}$ ，测试分布为 $P_{\text{test}}$ 。当 $P_{\text{test}}$ 含有 $P_{\text{train}}$ 里几乎没有的弯道样本时，模型在这些样本上的输出不可信——这是经典的**协变量偏移（covariate shift）**问题。

为什么 steer 全程为 0

steer 由 Pure Pursuit 根据模型输出轨迹计算（EP03 详述）：

$\delta = \arctan\left(\frac{2L \sin\alpha}{L_d}\right)$

如果模型输出的轨迹是直线（前方所有目标点都在 Ego 正前方），那么前瞻点的横向偏移 $\sin\alpha \approx 0$ ，于是 $\delta \approx 0$ ——纯跟踪忠实地把”直线轨迹”转成”零转向”。所以 steer = 0 是控制层忠实地执行了模型的（错误）决策，不是控制器 bug。

这印证了 ALG 诊断：问题在模型的轨迹输出，不在工程管道。

为什么 81% tick off-road

车进入弯道后，模型输出直线 → 车继续直行 → 物理上车冲出弯道 → off-road。一旦 off-road，后续帧的图像全是路外场景（草地、护栏），模型更没见过，继续输出直线——形成恶性循环。81% tick off-road 说明失败一旦发生就不可恢复，模型没有”我已经偏了，赶紧修正”的能力。

这也是闭环评测特有的现象：开环里走偏了下一帧还是 GT 图像，闭环里走偏了就真的回不来。

解决方向：针对 CARLA 弯道微调

视频给的解法是轻量微调：

在 CARLA 采集的弯道数据上加训几个 epoch。
让模型见到急弯几何，学会输出弯曲轨迹。
不需要从头重训，只在已有 checkpoint 上微调。

这是处理域差的常用方法——目标域微调（target domain fine-tuning）。代价是：需要采集 CARLA 弯道数据（带 GT 监督），且微调过多可能牺牲原训练分布上的性能（灾难性遗忘）。

这类失败的普遍启示

ALG 域差是端到端自动驾驶的核心挑战：

真实部署也会遇到训练集没见过的场景（新城市、新天气、新道路几何）。
闭环评测的价值就是提前暴露这些 OOD 失败，而不是等真车上路才发现。
单一数据集训练的模型，泛化性有硬上限——这是为什么业界追求多数据集联合训练、仿真数据补充。

参考

失败案例二：SCN 场景几何（cut_in_right）

这个失败和 ALG 的本质不同

cut_in_right 这条 case 看上去也是 Ego 表现不好，但诊断脚本把它归为 SCN（场景几何问题）——不是模型的错，是 Bench2Drive 的场景设计在这个路段失效了。区分 ALG 和 SCN 是诚实评测的关键：不能把场景设计的锅扣到模型头上。

现象：Ego 减速了，但 NPC 没真切入

仔细看 NPC 的轨迹：

NPC 从右后方追上 Ego。
但它从未真正切入 Ego 车道。
而是沿弯道走了一条平行路径——横向距离从 2.9 米单调增大到 12 米。

也就是说，NPC 离 Ego 越来越远，根本没有”切入”这个动作发生。Ego 的减速其实是合理的（看到右侧有车接近，谨慎减速），但场景设计的”NPC 切入 Ego 前方”这个考题根本没被执行。

根因：行为树在弯道段找不到合法切入路径

这是 EP03 提过的同一类问题的具体表现。cut_in_right 场景由 ScenarioRunner 的行为树编排，行为树里有个 ChangeLane 节点要求 NPC 切到 Ego 车道。但这个节点依赖 CARLA 在该路段生成合法的 LaneChange waypoint——即 OpenDRIVE 里两个相邻车道之间有合法的变道拓扑。

Town04 的这段弯道上，OpenDRIVE 的车道定义没有提供 LaneChange 拓扑（可能是弯道曲率太大、或车道类型不允许变道）。CARLA 拒绝生成变道 waypoint，于是：

行为树的 ChangeLane 节点永远返回 FAILURE。
行为树的回退逻辑让 NPC 退而求其次，沿当前车道走。
结果 NPC 走了一条和 Ego 平行的路径，横向距离越来越大。

形式化地说，场景设计假设了一个前提” $\exists$ 合法 LaneChange 拓扑”，但这个前提在特定路段不成立，整个场景就空转了。

为什么横向距离从 2.9m 单调增大到 12m

弯道的几何特性：两辆车沿不同曲率的车道走时，弯道越深，车道之间的横向距离变化越大。NPC 在外侧车道、Ego 在内侧车道，沿弯道前进时两者的横向距离因弯道几何被动拉开——这不是 NPC 主动远离 Ego，是几何必然。

12 米意味着 NPC 已经离 Ego 很远，根本构不成”切入”场景。诊断脚本看到”NPC 从未进入 Ego 车道”，判定为 SCN。

为什么这是 SCN 不是 ALG

区分的关键：模型有没有做错。

如果 NPC 真的切入了，Ego 没让速撞了——那是 ALG（模型该让没让）。
这里 NPC 根本没切入，Ego 减速是合理反应——模型没错。
错的是场景：行为树设计假设的”切入”动作在这个路段没法发生。

把这种 case 归为 ALG 会冤枉模型——模型的实际能力被低估了。SCN 诊断的意义就是剔除场景设计缺陷造成的虚假失败，让分数反映模型真实能力。

这类问题的工程启示

SCN 类问题暴露了仿真评测协议本身的局限：

场景是预定义的：Bench2Drive 的 44 种场景是人工设计的，设计时假设的路网拓扑不一定在所有测试路段都成立。
行为树依赖底层 API：ChangeLane 依赖 CARLA 的 waypoint 生成，而 waypoint 依赖 OpenDRIVE 拓扑——多层依赖，任一层失效场景就空转。
诚实比掩盖重要：发现 SCN 问题后，正确做法是修复场景（如 EP07 的 T1：自己写子类强制 NPC 切入），而不是假装没问题。

EP07 的整个调试主线就是修这类 SCN 问题——让场景真的发生它该发生的交互，否则评测分数没有意义。

参考

训练 Pipeline

两阶段训练策略

SparseDriveV2 的训练分两个阶段，这是端到端模型的标准做法（UniAD、VAD 等都用类似策略）：

阶段 1：感知预训练           阶段 2：端到端联合训练
─────────────────           ─────────────────────
冻结规划模块                  解冻所有模块
只训练感知（检测+建图）        梯度从规划回传到感知
100 epoch                    10 epoch
目标：感知充分收敛            目标：联合优化，感知为规划服务

为什么不能从头联合训练

如果从一开始就让所有模块（感知 + 规划）一起训练，会遇到两个问题：

梯度信号混乱

规划模块需要的输入是有意义的感知特征。但训练初期感知模块输出的是垃圾（随机初始化），规划模块基于垃圾特征学规划，梯度回传给感知的信号也是混乱的——“我应该怎么调整感知才能让这个垃圾规划更好？” 没有意义。两个模块互相拖累，训练不收敛。

任务竞争

感知 loss（检测 mAP）和规划 loss（轨迹误差）在训练初期方向可能冲突。感知模块同时被两个目标拉扯，收敛慢。

阶段 1：感知预训练

# 伪代码
freeze(planning_module)
for epoch in range(100):
    for batch in dataloader:
        images, gt_det, gt_map = batch
        det_pred, map_pred = perception_module(images)
        loss = det_loss(det_pred, gt_det) + map_loss(map_pred, gt_map)
        loss.backward()
        optimizer.step()

只训练感知模块（detection + mapping），用它们各自的 GT 监督。100 个 epoch 让检测和建图充分收敛——这一阶段结束时，感知模块能输出高质量的目标和地图。

这相当于让”感知老师”先学会本职工作，再去配合”规划学生”。

阶段 2：端到端联合训练

# 伪代码
unfreeze(planning_module)  # 解冻所有模块
for epoch in range(10):
    for batch in dataloader:
        images, gt_det, gt_map, gt_traj = batch
        det_pred, map_pred, plan_traj = full_model(images)
        loss = (det_loss(det_pred, gt_det)
                + map_loss(map_pred, gt_map)
                + motion_loss(...)
                + plan_loss(plan_traj, gt_traj))
        loss.backward()
        optimizer.step()

解冻所有模块，规划 loss 的梯度回传到感知。因为感知已经预训练好（输出有意义特征），规划模块能基于稳定输入学习，梯度信号清晰。

只训 10 epoch 是关键——感知已经收敛，不需要再大改；规划模块在好的感知基础上少量迭代就能学会。过多 epoch 会过拟合或灾难性遗忘（感知为了规划牺牲检测精度）。

训练成本对比

模型	GPU	时长	总 GPU 小时
UniAD	A100 × 8	~144h	~1152
SparseDriveV2	L20 × 8	~10h	~80

效率提升超过一个数量级（~14×）。原因：

Backbone 更小（ResNet-34 vs ResNet-101）。
Sparse 操作算得快（query 级别 vs BEV 全网格）。
两阶段策略收敛快（感知预训练让联合训练只需少量 epoch）。

注意 L20 和 A100 算力不同（A100 更强），即使折算后 SparseDriveV2 的训练效率仍显著优于 UniAD。这是 sparse 范式在训练侧的红利——不只是推理快，训练也快。

为什么 L20 够用

L20 是 48GB 显存、算力介于 A10 和 A100 之间的 GPU。SparseDriveV2 能在 L20 上训是因为：

模型小（5000 万参数），显存占用低。
Sparse 操作的中间激活也小（不维护大 BEV）。
batch size 不需要很大就能有效训练。

这让 SparseDriveV2 的训练更亲民——不需要顶配 A100/H100 集群，普通实验室的 L20/A10 就能复现。

参考

Loss Function

五个分量的总损失

SparseDriveV2 的总损失是五个分量的加权和：

$\mathcal{L} = \lambda_{\text{det}}\mathcal{L}_{\text{det}} + \lambda_{\text{map}}\mathcal{L}_{\text{map}} + \lambda_{\text{motion}}\mathcal{L}_{\text{motion}} + \lambda_{\text{plan}}\mathcal{L}_{\text{plan}} + \lambda_{\text{depth}}\mathcal{L}_{\text{depth}}$

分量	监督什么	GT 来源
$\mathcal{L}_{\text{det}}$	检测：3D 包围盒（位置/尺寸/朝向/速度）+ 类别	数据集标注 / CARLA Actor 状态
$\mathcal{L}_{\text{map}}$	建图：20 点 polyline	矢量化地图标注
$\mathcal{L}_{\text{motion}}$	运动预测：NPC 未来轨迹	数据集记录的真实未来轨迹
$\mathcal{L}_{\text{plan}}$	规划：Ego 未来轨迹	Ego 实际走过的轨迹
$\mathcal{L}_{\text{depth}}$	深度监督（辅助）：图像深度	CARLA Depth 相机 / 立体匹配

Winner-Takes-All（WTA）：多假设的优化技巧

运动预测和规划都输出多个候选（运动预测对每个 NPC 输出多条轨迹，规划在 26 万候选里打分）。直接对所有候选算 loss 会让模型困惑——“我应该让哪一条接近 GT？”

WTA 的解法：只有最接近 GT 的那个 mode（候选）参与 loss：

$\mathcal{L}_{\text{motion}} = \min_{m \in \text{modes}} \text{ADE}(\tau_m, \tau^{\text{GT}})$

即从所有候选 mode 里选 ADE（平均位移误差）最小的那个，只对它算回归 loss。

这个设计的意义：

避免模式坍缩：每条 mode 都有机会成为”最接近 GT 的”，模型被鼓励让不同 mode 覆盖不同模式（左转、直行、右转各一条），而不是全部坍缩到 GT 附近。
训练稳定：模型不用同时优化多条 mode 都逼近 GT（互相干扰），只优化一条最像的。
保留多样性：训练后不同 mode 自然分化成不同驾驶意图。

对 SparseDriveV2 的规划来说，WTA 体现在：在 26 万候选里，只让最接近 GT 轨迹的那条候选的分数最大化（其他候选作为负样本对比）。这就是 B08 提到的对比学习式 loss。

深度监督的辅助作用

$\mathcal{L}_{\text{depth}}$ 是辅助任务——它不直接服务最终规划，但帮助 backbone 学到更好的几何表示。

形式化地说，让 Image Encoder 同时预测每个像素的深度：

$\mathcal{L}_{\text{depth}} = \text{SmoothL1}(\hat{D}, D^{\text{GT}})$

$D^{\text{GT}}$ 来自 CARLA 的 Depth 相机（训练时有，推理时无）。这个 loss 强迫 backbone 从单目图像学到深度感知能力——这对后续 3D 几何任务（检测、规划）有迁移帮助。辅助任务用较小的 $\lambda_{\text{depth}}$ ，避免喧宾夺主。

各分量的 GT 来源

理解 loss 的关键是知道每个分量的 GT 从哪来：

分量	训练数据 GT 来源	推理时可见？
检测	nuScenes 3D 标注	否
建图	矢量化地图	否
运动预测	数据集记录的未来轨迹	否
规划	Ego 实际未来轨迹	否
深度	CARLA Depth / 立体匹配	否

所有 GT 都只在训练时用。推理时模型只看 6 张 RGB（EP02 强调过）。这是端到端的标准约束——GT 是训练的老师，不是考试的答案。

多任务联合训练的根本意义

所有 loss 一起回传，梯度共享 backbone：

$\frac{\partial \mathcal{L}}{\partial \theta_{\text{backbone}}} = \sum_k \lambda_k \frac{\partial \mathcal{L}_k}{\partial \theta_{\text{backbone}}}$

backbone 同时被五个任务优化——它学到的特征要同时利于检测、建图、运动预测、规划、深度。这种多任务正则化让 backbone 学到更通用、更鲁棒的低层表示，比单任务训练泛化性好。

这就是端到端优于模块化的根本原因：模块化方案里每个模块独立训练自己的 backbone（或共享但目标单一），而端到端用一个 backbone 同时服务所有任务，特征利用效率高得多。

易错点

WTA 的 mode 选择要可微：min 操作不可微，要用软最小（softmax 加权）或 hard 选择 + 直通梯度（straight-through）。
$\lambda$ 权重敏感：某个 $\lambda$ 太大会让那个任务主导，其他任务被忽略。要按任务难度和量级调。
深度 GT 单位：CARLA Depth 输出单位是米，要和模型预测的深度尺度对齐。

参考

全面对比：UniAD → SparseDriveV2

五个维度的范式变迁

维度	UniAD	VAD	SparseDrive v1	SparseDriveV2
表示	Dense BEV	Vectorized（仍需 BEV encoder）	Sparse query	Sparse query
规划	单条回归	单条回归	6 条生成	26 万打分
Backbone	ResNet-101 (44.5M)	ResNet-50/101	ResNet-50	ResNet-34 (21.8M)
训练	A100×8, ~144h	中等	中等	L20×8, ~10h
推理	~1.8 FPS	较快	实时	实时（>20 Hz）
评测	开环	开环	开环	闭环 + 开环

每一行都是从重到轻、从慢到快、从开环到闭环的演进。

表示：Dense → Vectorized → Sparse

这条主线是计算量的逐级压缩：

$\underbrace{O(H \cdot W)}_{\text{Dense}} \;\longrightarrow\; \underbrace{O(N_{\text{vec}} \cdot L) + O(H \cdot W)}_{\text{Vectorized}} \;\longrightarrow\; \underbrace{O(N_q \cdot K)}_{\text{Sparse}}$

Sparse 的计算量比 Dense 小约 4 个数量级（详见 EP04 B05）。表示层面的稀疏化是效率提升的根本来源——backbone 能瘦身、训练能加速、推理能实时，都源于此。

规划：回归 → 打分

v1 的 6 条生成轨迹 vs V2 的 26 万候选打分，是优化难度的根本降低：

回归：连续空间回归，难优化、易模式崩塌。
打分：排序问题，训练稳定、覆盖率高（详见 EP04 B08）。

打分式的前提是候选池足够密，V2 的 Factorized Vocabulary 解决了这个前提（EP05 B08）。

Backbone：大 → 小

ResNet-101 (44.5M) → ResNet-34 (21.8M)，参数量减半。这看似只是工程优化，实则是 sparse 范式的红利：

Dense BEV 依赖 backbone 把整张图编码好，需要大 backbone。
Sparse 的 query 自己精确采样，对 backbone 全局表示能力要求低，可以瘦身。

backbone 瘦身直接带来训练快、推理快、显存省。

训练：144h → 10h

14× 加速来自三个因素叠加：

Backbone 小（前向/反向都快）。
Sparse 操作快（中间激活小）。
两阶段策略收敛快（感知预训练让联合训练只需 10 epoch）。

这是范式红利，不是单点 trick——同样的算法用更重的 backbone 训练会慢，但 SparseDriveV2 不需要重 backbone。

评测：闭环是最大区别

UniAD、VAD、SparseDrive v1 都主要做开环（nuScenes planning）。SparseDriveV2 是唯一在 CARLA 上做真正闭环评测的。

这不是小事——闭环评测：

暴露累积误差、场景依赖失败、交互失败（开环看不到）。
需要推理实时（50 ms 硬截止），倒逼模型高效。
提供真实驾驶能力的可信度量。

SparseDriveV2 能做闭环，前提是它够快（实时推理）+ 够鲁棒（不崩溃）。这反过来验证了 sparse + scoring 范式的工程可行性——不只是 paper 数字好看，是真的能开车。

一个容易被忽略的对比维度

除了上述硬指标，还有一个软维度：可调试性。

UniAD 的 BEV 表示：可看（能可视化 BEV 特征），但抽象。
SparseDriveV2 的 query：每个 query 显式对应一个目标/地图元素，带明确几何位置——出 bug 时能精确归因（哪个 query 错了、为什么）。

这种可解释性在工程迭代里价值巨大——EP07 的失败分类（ENG/ALG/SCN）就依赖这种可调试性。

参考

开启：视频讲到哪，技术深读自动跟到哪

0:00 0:00