DrivoR：Driving on Registers

一句话理解：DrivoR 是一个学习版的"候选轨迹 + cost function"规划器——用一组可学习的 Camera Registers 把约 16000 个 ViT 视觉 token 主动压缩成 64 个 scene token，再用 Trajectory Decoder 生成多条候选轨迹、Scoring Decoder 分项打分并选出最终轨迹。它证明：一个不依赖 BEV / LiDAR / 大型轨迹字典的纯 Transformer，借助 DINOv2 + LoRA 微调与 register 压缩，就能在 NAVSIM 上接近人类驾驶员水平，同时推理速度比 ViT-L 方案快 3 倍。

核心贡献：提出了基于 register token 的学习型视觉压缩机制（camera-aware registers），在保留摄像头视角信息的前提下，将下游 Transformer 的 token 数量压缩约 250 倍而几乎不掉点；配合 LoRA 适配预训练 DINOv2、解耦的生成-评分双 decoder 与 Winner-Takes-All 多候选轨迹监督，用一个仅约 4000 万参数的轻量模型在 NAVSIM-v1/v2 与 HUGSIM 闭环仿真上均取得强结果。

1. 基本信息

论文题目：Driving on Registers
作者：Ellington Kirby、Alexandre Boulch、Yihong Xu、Yuan Yin、Gilles Puy、Éloi Zablocki、Andrei Bursuc、Spyros Gidaris、Renaud Marlet、Florent Bartoccioni、Anh-Quan Cao、Nermin Samet、Tuan-Hung VU、Matthieu Cord
机构：Valeo.ai 等
版本：arXiv:2601.05083v2，2026 年 2 月 3 日
任务：基于多摄像头图像和自车状态，直接生成并选择未来驾驶轨迹。

2. 一句话理解

DrivoR 可以看作一个学习版的“候选轨迹 + cost function”规划器：

多摄像头图像
    ↓
预训练 ViT 提取视觉特征
    ↓
Camera Registers 压缩成少量 Scene Tokens
    ↓
Trajectory Decoder 生成多条候选轨迹
    ↓
Scoring Decoder 分别评价安全、舒适、进度等
    ↓
按照综合分数选择最终轨迹

它的核心思想是：

不把所有图像 patch 都交给下游规划模块，而是让一组可学习的 register tokens 主动从图像中提取规划相关信息。

3. 研究背景

3.1 传统自动驾驶规划

传统自动驾驶系统通常包含：

感知 → 跟踪 → 预测 → 规划 → 控制

中间会显式产生很多结构化结果：

车辆和行人的 3D 检测框；
车道线；
可行驶区域；
交通灯状态；
其他交通参与者的预测轨迹；
地图元素。

这些模块需要大量标注，也可能因为模块之间的信息传递而损失信息。

端到端规划希望直接学习：

$$ \text{传感器输入}+\text{自车状态} \rightarrow \text{驾驶轨迹} $$

3.2 为什么要生成多条轨迹？

一个场景可能有多种合理驾驶行为。

例如前方有一辆慢车：

可以减速跟车；
可以向左变道；
可以向右变道；
也可以暂时保持速度。

如果模型只能输出一条轨迹，就容易把多种可能性平均成一条不自然的轨迹。

因此 DrivoR 输出多条候选轨迹，再让评分器选择其中一条。这和 PNC 中的：

候选轨迹生成 + 代价函数评价

非常相似。

3.3 ViT 带来的计算瓶颈

Vision Transformer（ViT）会把图像切成很多 patch，每个 patch 转成一个 token。

如果一张图像有约 4000 个视觉 tokens，4 个摄像头总共就是约：

$$ 4\times4000=16000 $$

个 tokens。

Transformer 注意力的计算量大致随 token 数量平方增长：

$$ O(N^2) $$

这些 tokens 如果被后面的轨迹生成器和评分器反复读取，计算量会很大。

常见做法是平均池化，但平均池化存在两个问题：

所有区域基本被同等对待；
不能根据当前场景动态决定哪些信息重要。

可是驾驶时：

前方摄像头通常比后方摄像头重要；
红绿灯、前车和道路边缘的重要性不同；
不同场景需要关注不同区域。

DrivoR 因此采用学习型的 token 压缩。

4. Register 机制

4.1 Register 是什么？

假设原始输入是：

$$ [x_1,x_2,\ldots,x_M] $$

其中 $x_i$ 是 patch tokens。

增加 $R$ 个 registers 后，输入变成：

$$ [r_1,r_2,\ldots,r_R,x_1,x_2,\ldots,x_M] $$

没有固定图像位置；
不对应某个固定物体；
一开始只是随机初始化的向量；
会和所有 patch tokens 一起经过 Transformer；
最终可以作为全局场景摘要。

经过多层 Transformer 后，模型只取：

$$ [r_1^{(L)},\ldots,r_R^{(L)}] $$

而不是继续使用全部 patch tokens。

4.2 Register 如何读取图像信息？

在 self-attention 中，一个 register 会根据 query-key 相似度决定关注哪些 patch。

对于第 $j$ 个 register：

$$ \alpha_{jk} = \operatorname{softmax} \left( \frac{q_j^\top k_k}{\sqrt d} \right) $$

然后聚合各个 token 的 value：

$$ r'_j=\sum_k\alpha_{jk}v_k $$

直观地说：

每个 register 都像一个记录员，会自己决定当前场景中哪些区域值得记录。

经过多层注意力后，不同 registers 可能逐渐分工：

一个关注前车；
一个关注红绿灯；
一个关注道路左边缘；
一个关注右侧道路边缘；
一个关注行人或非机动车。

这些语义不是人工指定的，而是由轨迹损失和评分损失间接学出来的。

4.3 Register 与平均池化的区别

平均池化近似于：

$$ s=\frac{1}{M}\sum_{i=1}^{M}x_i $$

所有 token 被近似等权处理。

$$ s_j=\sum_{i=1}^{M}\alpha_{ji}x_i $$

其中权重 $\alpha_{ji}$ 由网络根据场景动态决定。

因此：

平均池化是固定、均匀的压缩；
register 是学习的、内容相关的压缩；
多个 registers 可以形成多个不同侧重点的场景摘要。

4.4 Camera-aware Registers

DrivoR 使用 4 个摄像头：

front；
front-left；
front-right；
back。

每个摄像头使用 16 个专属 registers：

$$ 4\times16=64 $$

个 scene tokens。

数据流是：

Front 图像       → ViT → 16 个 front registers
Front-left 图像  → ViT → 16 个 front-left registers
Front-right 图像 → ViT → 16 个 front-right registers
Back 图像        → ViT → 16 个 back registers

最后将四组 registers 拼接成 scene tokens。

专属 registers 的作用是保留摄像头来源：

前视 token 表示前方信息；
左前 token 表示左侧信息；
右前 token 表示右侧信息；
后视 token 表示后方信息。

这比把所有摄像头信息混成一组平均特征更适合驾驶任务。

4.5 Register 与 ViT 原始 Register 的区别

原始 ViT 中的 register 最初用于解决一种注意力问题。

有些 ViT 会让少数 patch token 变成“注意力垃圾桶”或“草稿空间”：

它们吸收大量注意力；
特征范数异常；
但不一定对应真实图像区域；
可能导致特征图出现伪影。

DrivoR 进一步利用这些 token 的全局汇总能力，将它们作为场景压缩后的输出。

4.6 Register 压缩节省的是哪部分计算？

需要注意：

Register 并不是让 ViT 从始至终只处理 64 个 tokens。

ViT 内部仍然需要处理 patch tokens。它主要压缩的是：

ViT 输出之后
→ trajectory decoder 和 scoring decoder

原本下游可能处理约 16000 个 tokens，现在只处理 64 个 scene tokens。

因此它主要降低：

下游 Transformer 的计算量；
下游显存占用；
轨迹生成和评分的计算成本。

5. LoRA 在 DrivoR 中的作用

5.1 为什么要微调 DINOv2？

DrivoR 使用预训练 DINOv2 ViT-S。

DINOv2 已经学到了通用视觉能力，但它原本不是为端到端驾驶设计的，也不知道：

哪些区域对轨迹规划重要；
哪些信息应该写入 registers；
如何区分安全相关和进度相关的视觉信息；
多摄像头信息如何服务规划。

因此需要让 ViT 适应驾驶任务。

5.2 LoRA 的基本形式

原始线性层为：

$$ y=W_0x $$

完整微调会直接修改 $W_0$。

LoRA 则冻结原始权重，只增加低秩更新：

$$ W'=W_0+\Delta W $$$$ \Delta W=BA $$

其中：

$$ A\in\mathbb{R}^{r\times d_{\text{in}}} $$$$ B\in\mathbb{R}^{d_{\text{out}}\times r} $$

$r$ 是低秩维度。

DrivoR 使用的 LoRA rank 是：

$$ r=32 $$

前向计算可以写成：

$$ y=W_0x+\frac{\alpha}{r}BAx $$

原始 DINOv2 权重 $W_0$ 不更新，只训练 $A$ 和 $B$。

5.3 为什么 LoRA 能帮助 registers？

LoRA 可以调整 ViT 的注意力和特征变换路径：

修改 Query：改变 register 想寻找什么；
修改 Key：改变 patch 如何被识别；
修改 Value：改变 patch 提供给 register 的内容；
修改 FFN：改变 token 特征如何被进一步变换。

因此 LoRA 可以让 ViT 学会：

把通用视觉特征
重新组织成
适合轨迹生成和评分的场景摘要

5.4 LoRA 通常作用于哪些层？

标准 ViT-LoRA 实现常见的目标模块包括：

Attention 的 $Q$ 投影；
Attention 的 $K$ 投影；
Attention 的 $V$ 投影；
Attention 输出投影；
FFN 的第一层；
FFN 的第二层。

但需要区分：

DrivoR 正文只明确说明使用 DINOv2 ViT-S、LoRA rank=32，并参考已有工作实现；正文没有逐层公开 LoRA 的确切 target modules、缩放系数或 dropout 设置。

因此，具体 target layer 应以作者代码为准。上面列出的是标准 ViT-LoRA 的常见实现，而不是论文正文已经明确公布的全部细节。

5.5 LoRA 与 registers 的参数分工

DINOv2 原始权重：通用视觉能力，冻结
LoRA 参数：把视觉能力适配到驾驶任务
Camera registers：保存每个摄像头的压缩信息
Trajectory decoder：生成候选轨迹
Scoring decoder：评估候选轨迹

5.6 为什么不用完整微调？

论文消融表明，在 register 压缩设置下：

只训练 registers、冻结视觉骨干：约 84.4 PDMS；
使用 LoRA：约 90.0 PDMS；
完整微调：约 88.4 PDMS。

只训练 registers 的问题是：

registers 虽然可以学习，但原来的 ViT 信息路由没有改变，未必能有效把驾驶相关信息写入 registers。

完整微调的问题是：

参数量和优化器状态更大；
可能破坏 DINOv2 的通用视觉能力；
更容易过拟合；
对学习率和训练策略更敏感。

LoRA 在保留预训练能力的同时，提供了足够的任务适应能力。

5.7 LoRA 可以用于其他层吗？

可以，但不一定都适合。

卷积层

卷积核也可以做低秩更新：

$$ W'=W_0+BA $$

或者使用两个小卷积组成低秩分支。

Patch Embedding

ViT 的 patch embedding 本质上通常是线性投影，也可以加入 LoRA。

Embedding 表

可以修改 token embedding，但是否有收益取决于任务。

LayerNorm

LayerNorm 参数通常只有缩放和偏移向量，参数量很小，通常直接训练，而不是做低秩分解。

激活函数

理论上可以修改，但这不再是标准 LoRA，而且容易破坏预训练模型行为。

LoRA 最适合修改：

参数量大、结构重要、且本身是线性变换的模块。

6. 轨迹生成器

6.1 Transformer Decoder 结构

Trajectory decoder 使用标准 Transformer decoder，每层包括：

self-attention；
对 scene tokens 的 cross-attention；
FFN；
残差连接。

默认设置：

4 层 Transformer；
内部维度 256；
FFN 扩展因子 4。

6.2 Trajectory Queries

模型维护一组可学习的 trajectory queries：

$$ Q_{\text{traj}} $$

每一个 query 最终对应一条候选轨迹。

这些 queries：

随机初始化；
在训练中更新；
可以逐渐学习不同的驾驶模式。

例如：

直行；
左转；
右转；
跟车；
减速；
变道。

自车状态会编码后加到 trajectory queries 上，包括：

位姿；
速度；
加速度；
驾驶指令。

之后 trajectory decoder 读取 scene tokens，输出候选轨迹。

6.3 轨迹表示

第 $i$ 条候选轨迹记为：

$$ \tau_i\in\mathbb{R}^{n_p\times3} $$

每个时间点的 pose 为：

$$ (x,y,\theta) $$

其中：

$x$：纵向位移；
$y$：横向位移；
$\theta$：航向角。

所有坐标都在当前时刻的自车坐标系中表达。

轨迹从当前时刻之后开始，一直预测到：

$$ t+T $$

相邻 pose 的时间间隔均匀。

6.4 Winner-Takes-All 轨迹损失

给定人工参考轨迹 $\hat{\tau}$，只监督预测结果中距离它最近的一条：

$$ L_{\text{traj}} = \min_i|\tau_i-\hat{\tau}|_1 $$

这叫 Winner-Takes-All（WTA），也可以理解成 Minimum-over-N。

它允许不同 query 产生不同合理轨迹，而不是要求所有 query 都回归同一条轨迹。

6.5 更长轨迹目标

论文还尝试加入一条更远的目标轨迹 $\hat{\tau}'$。

构造过程：

原始参考轨迹时长为 $T$；
另一条参考轨迹时长为 $T\'>T$；
用 cubic spline 将它重新采样到 $T$；
得到一条更激进、更强调前进的轨迹。

损失为：

$$ L_{\text{traj}} = \min_i \left( |\tau_i-\hat{\tau}|_1 + |\tau_i-\hat{\tau}'|_1 \right) $$

实验显示：

NAVSIM-v1 更奖励进度，因此该目标有帮助；
NAVSIM-v2 有自车状态扰动，更需要保守和可恢复的驾驶，因此该目标反而降低表现。

7. 评分器

7.1 为什么需要独立评分器？

生成器负责回答：

“有哪些可能的驾驶方案？”

评分器负责回答：

“这些方案分别有多安全、多舒适、多高效？”

这两个问题关注的视觉信息不完全相同。

例如：

生成左转轨迹时，主要需要观察前方道路；
判断左转轨迹是否会撞到侧方车辆时，可能需要重点看左侧或后方摄像头。

因此 DrivoR 使用两个独立 decoder：

Trajectory Decoder：生成轨迹
Scoring Decoder：评价轨迹

7.2 评分器如何输入轨迹？

对于每条生成的轨迹 $\tau_i$：

用 MLP 将轨迹映射成 $D_{\text{score}}$ 维 query；
所有轨迹对应的 score queries 输入 scoring decoder；
scoring decoder 通过 cross-attention 读取 scene tokens；
输出各个子分数。

7.3 轨迹重新嵌入与 stop-gradient

DrivoR 不直接复用 trajectory decoder 的隐藏 token，而是：

解码轨迹
  ↓
MLP 重新嵌入
  ↓
stop-gradient
  ↓
评分 decoder

原因是 trajectory decoder 的隐藏 token 中包含生成轨迹时使用的额外隐式信息。

如果评分器直接读取这些 token，它可能依赖生成器内部状态，而不是仅仅判断“这条轨迹本身好不好”。

重新嵌入后，评分器主要看到：

已经解码出来的轨迹；
scene tokens。

同时：

评分损失可以回传到 perception encoder 和 registers；
评分损失不能反向影响 trajectory decoder。

这样可以避免两个分支互相干扰。

8. 子分数与 BCE 损失

8.1 六个子分数

DrivoR 预测 PDMS 中的六类子分数：

NC：No-fault Collision，无责碰撞；
DAC：Drivable Area Compliance，可行驶区域遵守；
DDC：Driving Direction Compliance，行驶方向遵守；
TTC：Time to Collision，碰撞时间风险；
EP：Ego Progress，自车前进进度；
Comfort：自车舒适性。

每个子分数有独立的 MLP 输出头。

8.2 为什么使用 BCE？

论文没有证明 BCE 必然优于 MSE 或 L1，因此这里更准确地说是一个与评分形式匹配的工程选择。

这些子分数通常被归一化到 $[0,1]$：

0：表现差或违反要求；
1：表现好；
中间值：部分满足。

对于碰撞、道路合规等指标，它们接近二分类：

安全 → 1
碰撞 → 0

BCE 正适合这种目标：

$$ \operatorname{BCE}(p,y) = -y\log p-(1-y)\log(1-p) $$

对于 TTC、EP、Comfort 等连续指标，BCE 也可以把 $[0,1]$ 的连续值作为 soft label 使用。

例如目标分数为 0.8：

$$ \operatorname{BCE}(p,0.8) = -0.8\log p-0.2\log(1-p) $$

所以这里的 BCE 不一定意味着所有任务都是严格分类，而是把每个子分数视作一个 0 到 1 的质量概率。

8.3 为什么分别预测子分数？

PDMS 不是简单平均，而是：

安全和合规项采用乘法；
舒适和进度项采用加权平均。

如果直接回归最终 PDMS：

不同子项会混在一起；
乘法结构更难学习；
难以知道一条轨迹为什么得分低；
推理时无法灵活修改驾驶偏好。

分别预测子分数后，可以：

保留可解释性；
分别学习不同质量因素；
在推理时重新设置权重；
生成安全型、舒适型或积极型驾驶策略。

8.4 评分损失

对于第 $c$ 个子分数和第 $i$ 条候选轨迹：

$$ L_{\text{score}} = \sum_c\lambda_c\sum_i \operatorname{BCE} \left( G_{\theta_c}(\tau_i), G_c(\tau_i) \right) $$

其中：

$G_c(\tau_i)$：oracle scorer 给出的真实子分数；
$G_{\theta_c}(\tau_i)$：模型预测的子分数；
$\lambda_c$：子分数损失权重。

训练时论文将所有 $\lambda_c$ 设置为 1。

9. 推理时的行为控制

推理时，模型可以把子分数组合成总分：

$$ S(\tau_i)=\sum_c w_c\,G_{\theta_c}(\tau_i) $$

然后选择：

$$ \tau^*=\arg\max_i S(\tau_i) $$

改变权重 $w_c$，就可以改变驾驶行为。

安全型

提高 NC、DAC、TTC 权重，结果通常是：

更早减速；
更少激进变道；
轨迹更短；
碰撞风险更低。

舒适型

提高 Comfort 权重：

减少急加速；
减少急减速；
减少急转向；
轨迹更加平滑。

积极型

提高 EP 权重：

更重视向目标前进；
速度可能更高；
轨迹可能更激进。

这和 PNC 中调节不同 cost term 的权重很像，但 learned score 并不等同于人工设计的 cost function。

10. 总训练损失

最终损失是：

$$ L=L_{\text{traj}}+\lambda_sL_{\text{score}} $$

训练时：

$$ \lambda_s=1 $$

因此轨迹生成损失和评分损失等权。

11. PDMS 和 EPDMS 指标

11.1 两类指标

子指标分成两组。

惩罚类 $G_p$

用于衡量是否违反驾驶规则，例如：

无责碰撞；
可行驶区域；
行驶方向；
交通线；
其他硬约束。

它们采用乘法：

$$ \prod_{c\in G_p} G_c(\tau_i)^{\kappa_c^p} $$

只要某个硬约束分数为 0，总分就可能为 0。

行为类 $G_b$

用于衡量驾驶质量，例如：

TTC；
自车进度；
舒适性；
车道保持。

它们采用加权平均：

$$ \frac{1}{Z} \sum_{c\in G_b} \kappa_c^bG_c(\tau_i) $$

其中：

$$ Z=\sum_{c\in G_b}\kappa_c^b $$

这样可以在进度和舒适之间进行折中。

11.2 PDMS 权重

PDMS 中的典型权重为：

NC：1；
DAC：1；
DDC：0；
TTC：5；
EP：5；
Comfort：2。

补充材料还列出：

TLC：Traffic-line Compliance；
LK：Lane Keeping；
HC：History Comfort；
EC：Extended Comfort。

11.3 EPDMS 权重

NAVSIM-v2 使用扩展指标 EPDMS。论文补充材料中给出的推理权重为：

子分数	PDMS	EPDMS
NC	1	10
DAC	1	13
DDC	0	6
TTC	5	14
EP	5	15
Comfort	2	2

NAVSIM-v2 对安全、道路合规和进度的重视程度更高。

12. 实验设置

12.1 模型配置

输入：

4 个摄像头；
front、front-left、front-right、back。

视觉编码器：

DINOv2 ViT-S；
LoRA rank=32；
每个摄像头默认 16 个 registers；
总共 64 个 scene tokens。

解码器：

trajectory decoder：4 层；
scoring decoder：4 层；
内部维度：256；
FFN 扩展因子：4。

初始化：

camera registers：$\mathcal{N}(0,10^{-6})$；
初始 trajectory tokens：$\mathcal{N}(0,10^{-6})$。

训练：

AdamW；
学习率 $2\times10^{-4}$；
cosine annealing；
4 张 NVIDIA A100；
模型约 4000 万参数。

默认消融设置：

使用 navtrain；
训练 10 个 epoch；
在 navval 上比较。

最终训练设置：

NAVSIM-v1：navtrain+navval，25 个 epoch；
NAVSIM-v2：navtrain，10 个 epoch。

13. Benchmark 与主要结果

13.1 NAVSIM-v1

NAVSIM-v1 基于 nuPlan，并作为 OpenScene 的子集构建。

相比只比较预测轨迹与人工轨迹相似度的传统指标，PDMS 更接近闭环驾驶评价，考虑：

碰撞；
驶出可行驶区域；
行驶方向；
近碰撞；
舒适性；
前进进度。

主要 PDMS 结果：

方法	PDMS
Human driver	94.8
RAP-DINO	93.8
DrivoR(train)	93.1
DrivoR(trainval)	93.7
DrivoR +65k SimScale	94.0
DrivoR +134k SimScale	94.6

结论：

DrivoR 在纯摄像头设置下取得很强结果；
加入额外合成数据后接近人类驾驶员；
不依赖 LiDAR、BEV 或大型轨迹字典。

13.2 NAVSIM-v2

NAVSIM-v2 在第二阶段使用 Gaussian Splatting 产生新场景变化，并扰动自车状态：

平移；
旋转；
其他状态变化。

这会迫使模型泛化到训练分布之外。

EPDMS 结果：

方法	EPDMS
GTRS-D	45.0
GTRS-A	45.4
ZTRS	48.1
DrivoR	48.3
DrivoR +65k SimScale	52.3
DrivoR +134k SimScale	54.6

DrivoR 使用 134k 额外 SimScale 数据时达到 54.6，超过使用更多额外数据的对比方法。

论文指出，NAVSIM-v2 官方评估曾存在与人类驾驶错误过滤有关的 bug。补充材料同时报告了修复前和修复后的结果；修复后，DrivoR 在轻量模型中表现尤其突出。

13.3 HUGSIM 闭环仿真

HUGSIM 将以下数据集中的场景重建成照片级 3D 环境：

KITTI-360；
nuScenes；
PandaSet；
Waymo。

模型在环境中真正控制自车运动，摄像头视角会随自车位置改变。

DrivoR 只在 NAVSIM-v1 上训练，不做 HUGSIM 微调，采用零样本评估：

方法	Road Completion	HD-Score
VAD	31.4	13.4
LTF	38.9	23.7
UniAD	45.9	32.7
DrivoR	49.8	35.7

DrivoR 在表中基线中取得最高平均 RC 和 HD-Score。

作者还修正了 HUGSIM 评估代码中的问题：

舒适性指标中的加速度范围不一致；
规划轨迹传给控制器时航向角计算错误。

14. 效率分析

单张 A100、单样本前向推理结果：

方法	参数量	GFLOPs	峰值显存	前向时间
RAP-DINO ViT-H	888M	4760	4.2GB	690ms
GTRS-D ViT-L	321M	1730	1.6GB	400ms
ZTRS	81M	840	1.0GB	193ms
DrivoR	41M	351	0.5GB	110ms

相对于 ViT-L 版本的 GTRS：

推理速度超过 3 倍；
GFLOPs 约降低 3 倍；
峰值显存约降低 3 倍；
性能反而更高。

论文提醒，FVCore 当前没有统计 Scaled Dot Product Attention，因此 GFLOPs 不是完整的绝对计算量，但相对比较仍然有参考价值。

15. 消融实验

15.1 预训练的重要性

初始化方式	PDMS
随机初始化	70.1
ImageNet-21k	87.5
DINOv2	90.0

DINOv2 相比随机初始化提升接近 20 分。

结论：

高质量预训练视觉表示对端到端规划非常重要。

15.2 压缩方法比较

比较：

不压缩；
平均池化；
Transformer decoder 压缩；
register 压缩。

核心结果：

不压缩：约 16000 个 scene tokens，PDMS 90.2；
pooling：64 个 scene tokens，PDMS 89.7；
decoder 压缩：64 个 scene tokens，PDMS 89.3；
register 压缩：64 个 scene tokens，PDMS 90.0。

论文还指出，register 压缩只增加约 0.6M 的训练参数。

15.3 Register 的注意力分工

前视摄像头的 registers：

相互相似度较低；
关注不同区域；
表现出明显的功能分工。

可视化中能看到它们关注：

红绿灯；
前车；
人行道；
道路边缘。

后视摄像头的 registers：

相互相似度较高；
大多数 token 表示逐渐塌缩；
通常只有少数 token 保持独立。

这与驾驶直觉一致：

前方视野需要精细理解
后方视野通常只需要粗略监控

平均池化无法自然产生这种“不同摄像头使用不同压缩强度”的效果。

15.4 Register 数量

不同 register 数量的结果：

每摄像头 registers	总 scene tokens	PDMS
5	20	约 89.7/88.1
8	32	89.7
16	64	90.0
32	128	89.8

性能在 16 到 32 个之间达到平台，因此默认选择每个摄像头 16 个 registers。

DINOv2 原有 registers 与新增 registers 一起使用并没有带来收益。论文推测，原有 registers 已经针对通用视觉任务形成专门化表示，不一定适合驾驶规划。

15.5 微调策略

只训练 registers、冻结 ViT：表现明显较差；
LoRA：达到约 90.0 PDMS；
完整微调：约 88.4 PDMS。

LoRA 在性能和稳定性之间取得了更好的平衡。

15.6 候选轨迹数量

候选轨迹数	PDMS
1	80.1
8	87.6
16	88.1
32	89.5
64	90.0
128	90.0

从 1 条增加到 64 条时性能持续提升，64 条以后基本饱和。

这验证了多模态候选轨迹的重要性。

15.7 生成和评分是否应该分开？

设置	PDMS
一个分支同时生成和评分	84.7
两个 decoder，但不做解耦	86.8
两个 decoder + 重新嵌入 + stop-gradient + 6 个子分数	90.0
两个 decoder + 解耦，但只预测 1 个总分	88.2

注意力可视化显示：

轨迹生成主要依赖前视图；
评分器会根据轨迹形状和风险转向左侧或后方摄像头。

因此生成和评分需要共享场景信息，但不应完全共享内部表示。

15.8 单 token 和多 token 表示轨迹

补充实验比较：

每个 pose 使用一个 token；
整条轨迹使用一个 token，再一次性解码。

结果：

轨迹表示	PDMS
Multi-token	83.9
Single-token	90.0

单 token 方案生成的轨迹更加平滑、噪声更少。

直观上：

多 token 方案还需要额外学习时间连续性；
单 token 方案更容易直接表达整条轨迹的整体形状。

15.9 更长目标轨迹

训练目标	NAVSIM-v1 PDMS	NAVSIM-v2 EPDMS
仅 $t+T$	90.0	39.4
同时加入 $t+T'$	90.6	37.8

更长目标：

对奖励进度的 NAVSIM-v1 有帮助；
对需要谨慎处理状态扰动的 NAVSIM-v2 有害。

15.10 训练 epoch

NAVSIM-v1：

训练时间增加时 PDMS 持续提高；
大约 25 个 epoch 达到平台。

NAVSIM-v2：

EPDMS 随训练 epoch 增加而下降；
使用 competition split 也会降低表现。

最终选择：

NAVSIM-v1：25 epoch；
NAVSIM-v2：10 epoch。

这说明不同 benchmark 的最优训练策略不同。

16. 行为调节实验

论文构造了一个 Safety-Oriented Agent。

相比默认 agent，它使用更偏向安全的子分数权重。

结果表现为：

碰撞和安全指标更好；
舒适性更好；
轨迹更短；
行驶速度更低；
前进进度下降；
在 NAVSIM-v2 的 OOD 场景中更适合。

这证明评分器不仅能给轨迹排序，还可以在推理阶段改变驾驶风格。

17. 局限性与失败案例

17.1 没有使用历史帧

DrivoR 只看当前时刻的图像，没有历史帧。

在某些场景中：

前视图缺少明显目标；
单帧无法判断自车已经处于什么位置；
模型可能过度依赖右侧摄像头；
轨迹可能过早切弯；
甚至可能出现错误方向行驶。

加入历史帧可能帮助模型理解：

自车之前的运动；
场景变化；
当前轨迹意图；
交通参与者运动趋势。

17.2 评分器可能关注错误摄像头

在一个穿越红绿灯路口的案例中，评分器主要关注后视摄像头，而不是可见的红绿灯。

作者推测：

如果把 Traffic Light Compliance 加入评分组件，可能会迫使评分器更关注红绿灯。

虽然当时没有显式使用该评分项，但模型的交通线相关分数仍然很高。

17.3 行为权重与泛化之间的权衡

更积极的模型：

进度更高；
轨迹更激进；
可能在分布内场景表现好。

更保守的模型：

进度降低；
安全性和舒适性提高；
在 OOD 场景中更稳健。

这说明“最佳驾驶策略”依赖评价环境和场景分布。

18. 与 PNC 的对应关系

DrivoR 部件	PNC 中的近似对应
Trajectory queries	不同驾驶意图或候选轨迹生成器
Trajectory decoder	候选轨迹规划器
Scoring decoder	学习得到的 cost/reward 评估器
NC/DAC/TTC	碰撞和约束代价
EP	进度奖励
Comfort	舒适性代价
Score weights	PNC 中各 cost term 的权重
Camera registers	隐式学习的场景状态摘要
LoRA	对预训练感知特征的任务适配

需要注意：

learned score 不等同于人工 cost function；
registers 不等同于显式障碍物或车道线；
DrivoR 没有显式输出完整 BEV 或结构化环境模型；
它学习的是对规划有用的隐式中间表示。

19. 最终核心结论

Register 是学习型视觉压缩器：它们没有固定位置，通过 self-attention 主动从 patch tokens 中提取重要信息。
Camera-aware registers 保留视角信息：每个摄像头拥有专属 registers，因此前视、侧视和后视信息不会被简单混合。
Register 压缩显著降低下游计算：约 16000 个视觉 tokens 被压缩成 64 个 scene tokens，下游 decoder 计算量大幅下降。
LoRA 负责适配，不负责压缩：registers 负责保存摘要，LoRA 负责让预训练 ViT 学会如何提取和组织驾驶相关信息。
多候选轨迹比单轨迹更适合驾驶多模态：64 条候选轨迹已经基本达到性能平台。
生成器与评分器应该解耦：生成轨迹和判断轨迹的视觉关注区域不同，独立分支更合理。
分别预测子分数比直接预测总分更有解释性和可控性：推理时可以重新设置安全、舒适、进度等权重。
BCE 是匹配 $[0,1]$ 子分数的工程选择：论文没有证明 BCE 绝对优于 MSE；真正重要的是分解预测子分数并重新组合。
简单的纯 Transformer 也可以取得很强结果：DrivoR 不使用 BEV、LiDAR 或大型轨迹字典，也能在多个 benchmark 上达到很高性能。

20. 仍待讨论的问题

Register 是否可以直接对应可解释的驾驶语义？
如何让 registers 融合历史帧？
是否应该让不同摄像头使用不同数量的 registers？
LoRA 的最佳 target modules 是只改 $Q,V$，还是同时改 FFN？
BCE、MSE、排序损失对轨迹选择的影响有何区别？
如何避免评分器在复杂场景中关注错误摄像头？
如何把 learned scorer 与传统 PNC cost function 更紧密地结合？
如何将地图、LiDAR 或车辆历史状态加入 register 压缩框架？