引言:离散扩散 + 端到端驾驶 = 新范式?
2025-2026 年,端到端自动驾驶的路线之争愈演愈烈。主流阵营分为两派。
自回归(AR)派以 GPT-driver 和 VLA 系列为代表,token-by-token 顺序输出轨迹,串行解码慢,端侧只能跑小模型。连续 Diffusion 派以 UniAD、DriveWM、PlanningDiffuser 为代表,在连续空间去噪生成轨迹,但通常需要额外的 anchor 或 goal 系统辅助,破坏了原始数据分布。
理想汽车(Li Auto)的 ReflectDrive-2(CVPR 2026)选择了第三条路:离散扩散模型做端到端规划。乍看像是 ReflectDrive 的小幅迭代,但细读论文与 AutoEdit 部分会发现,这是对量产级 E2E 方案的一次结构性重新设计——把"起草—自修正"作为一等公民写进模型,并通过 RL 让两个阶段在同一闭环奖励下共同进化。
本文是对该论文的单篇精读。除了完整还原方法与实验,本文还重点回答两个问题:第一,离散扩散在 AD 上和 LLaDA 这类语言侧离散扩散到底是什么关系;第二,91.0 PDMS(NAVSIM v1 navtest)的成绩里,“离散化"本身贡献了多少,“RL 联合优化"又贡献了多少。
一、为什么选离散扩散
三条路线的本质对比
flowchart LR
subgraph AR["自回归 (AR)"]
direction TB
AR1["t₁: 输出 token 1"]
AR2["t₂: 输出 token 2,依赖 t₁"]
AR3["t₃: 输出 token 3,依赖 t₁,t₂"]
AR1 --> AR2 --> AR3
AR_style["串行瓶颈
端侧小模型
探索成熟"]
end
subgraph ContDiff["连续 Diffusion"]
direction TB
CD1["连续噪声注入"]
CD2["连续空间去噪 N 步"]
CD3["输出连续轨迹坐标"]
CD1 --> CD2 --> CD3
CD_style["需要额外 anchor 系统
打破数据分布规律
并行生成"]
end
subgraph DiscDiff["离散扩散 (本方案)"]
direction TB
DD1["Token 级掩码注入"]
DD2["双向并行去噪 N 步"]
DD3["输出离散 token 序列"]
DD1 --> DD2 --> DD3
DD_style["全并行解码
统一词表方便预训练
Token2Token 支持 AutoEdit
RL 探索空间清晰"]
end
AR --- ContDiff --- DiscDiff选择离散扩散的几个理由
离散扩散对 E2E 规划而言并非时髦标签,而是因为它同时拿到了几个互补特性。第一,所有输入(视觉、自车状态、导航)一旦离散化为统一 token,就可以与轨迹 token 在同一个 Transformer 中互相注意,模态融合不再需要桥接模块。第二,去噪过程是并行解码,每一步同时刷新所有 mask 位置,相对 AR 的 串行解码在序列长度增长时优势显著。第工三,离散空间下的 token-to-token 改写天然支持局部修正:模型可以读"当前轨迹"的全部 token 并对每一位单独决定是否替换——这就是后文 AutoEdit 的基础。第四,RL 在离散动作空间中可以直接套用 PPO 风格的策略梯度,信用分配比连续 Diffusion 上的 score matching + reward shaping 更干净。
代价当然也存在:要把轨迹离散化就要预先学一个 codebook,而 codebook 的设计本身是个非平凡问题。第六节会把这一点和 LLaDA 这类语言侧离散扩散对照展开。
二、模型架构:0.8B 参数的紧凑设计
整体架构
flowchart LR
subgraph Input["多模态输入"]
CAM["三路环视相机
左前 / 正前 / 右前
各 2 个时间帧"]
NAV["导航指令 tokens
(文本编码后)"]
EGO["自车状态 tokens
速度 / 航向等"]
end
subgraph Encoder["视觉编码器 ViT (0.1B)"]
direction TB
V1[Patch Embedding]
V2[Transformer Blocks]
V1 --> V2
end
subgraph Backbone["掩码扩散语言模型 (0.7B)"]
direction TB
B1["Prompt Tokens
因果注意力 Causal Attention
支持 KV 缓存复用"]
B2["Trajectory Token 块
双向注意力 Bidirectional Attention
支持扩散去噪"]
B3["Action Expert FFN
隐层 4096→1024 精简
+ Action Head 输出层"]
B1 --> B2 --> B3
end
subgraph Output["输出"]
OUT["16 个离散 trajectory tokens
8 个航路点 × 2 坐标
(纵向 x + 横向 y)"]
end
CAM --> Encoder
Encoder --> Backbone
NAV --> Backbone
EGO --> Backbone
Backbone --> OUT
style Encoder fill:#e1f5fe
style Backbone fill:#fff3e0
style Output fill:#e8f5e9关键设计决策
注意力模式混合
模型在同一个 Transformer 中混合使用两种注意力机制:
Prompt 部分采用因果注意力,历史帧信息按时间因果传播并支持 KV Cache 复用,流式场景中前一帧的计算结果可以直接转写到下一帧;Trajectory 部分采用双向注意力,因为扩散去噪本质上要求每个待恢复位置都能看到序列的全局上下文。
Action Expert FFN 精简
标准 FFN 隐层维度为 4096,Action Expert 将其缩减到 1024:
精简后 Action Expert FFN 在 NVIDIA Thor 上的延迟从 2.47ms 降到 0.95ms(详见论文 Table 5)。耐人寻味的是精简后多个轨迹指标(meanSADE、path-minFDE@20/40、path-meanADE@80)反而轻微改善——隐层 4096 在 8 个航路点这一规模的数据上可能已经过参数化。
三、离散扩散建模:数学框架
前向过程(Masking)
以概率 独立地将每个轨迹 token 替换为 [MASK]:
其中 是 mask ratio,从 (全 mask)逐步降低到接近 0。
去噪过程
双向 Transformer 根据多模态上下文(视觉特征 + 导航 + 自车状态 + 已恢复的轨迹 token)预测被遮蔽位置的原值:
损失函数:全位置交叉熵
一个关键设计选择是在所有位置(而非仅 mask 位置)计算损失:
这比仅对 mask 位置计算损失(如 LLaDA 采用的 加权)更稳定,因为它为未 mask 位置也提供了梯度信号,使预测分布更加连贯一致。
四、“决策-起草-反思”:三阶段推理范式
ReflectDrive-2 把人类驾驶员"先定方向、写草稿、反复修改"的思维过程形式化为一个可微分推理流程。
flowchart TB
subgraph Stage1["阶段一:决策 Decision"]
direction TB
GP["目标点后验 p(goal)
从 BEV 离散坐标中
top-k 采样 + NMS"]
GP --> SAMPLES["多个候选目标 tokens
每个代表一种行为意图:
保持车道 / 让行 / 超车 ..."]
end
subgraph Stage2["阶段二:起草 Drafting"]
direction TB
ANCHOR["固定目标 token 于轨迹末端
其余位置初始化为 [MASK]"]
ANCHOR --> DENOISE["少量并行去噪轮次 (3步)
每步提交最高置信度预测"]
DENOISE --> DRAFT["草稿轨迹
(结构合理但细节粗糙)"]
end
subgraph Stage3["阶段三:反思/自动编辑 AutoEdit"]
direction TB
INPUT_EDIT["输入:具体轨迹 token(非 [MASK])
模型预测每个位置的替换 token"]
INPUT_EDIT --> COMMIT["置信度 Commit Mask
决定哪些位置需要更新"]
COMMIT --> EDITED["编辑后最终轨迹
目标 token 始终不变
可迭代多轮"]
end
Stage1 -->|"选择一个目标"| Stage2 -->|"token-to-token 改写"| Stage3
style Stage1 fill:#e3f2fd
style Stage2 fill:#fff8e1
style Stage3 fill:#e8f5e9阶段一:决策 —— 目标点后验
每个目标点是离散 BEV 坐标对 ,固定为轨迹序列的最后一个航路点,作为行为锚点:
通过 NMS 去重后获得多样化候选,每种候选代表一种高层行为假设(超车、让行、变道等)。
阶段二:起草 —— 锚定式并行解码
选定目标后,将目标 token 固定于轨迹末端(第 16 个 token 位置),其余 15 个位置初始化为 [MASK],运行 3 轮并行去噪:每轮所有位置同时预测,取最高置信度结果 commit。
阶段三:反思 —— AutoEdit
AutoEdit 是整个范式的灵魂。与传统 diffusion 的"迭代去噪"不同,AutoEdit 做的是 token-level 的就地改写:
它的几个关键特性使其区别于一般的去噪迭代:输入是具体 token 而非 [MASK],模型看到的是"当前方案”;逐位置评估是否需要改写并由 commit mask 控制;目标 token 始终锁定,行为意图不被篡改;可迭代多轮,反复打磨直到收敛。
sequenceDiagram
participant D as 起草器 Drafting
participant T as 轨迹 Tokens
participant E as 编辑器 AutoEdit
D->>T: 初始化 [goal, [MASK], ..., [MASK]]
loop 去噪轮次 × 3
D->>T: 双向预测所有 [MASK] 位置
T->>D: 提交最高置信度预测
end
Note over T: 草稿完成 (Draft)
loop AutoEdit 轮次 × 3
E->>T: 读取完整轨迹 token 序列
T->>E: 上下文 + 当前轨迹
E->>E: 逐位置预测替换 token
E->>T: 仅更新置信度超过阈值的位置
Note over T: 部分位置被改写
end
Note over T: 最终规划输出五、训练策略:从 SFT 到 RL 的联合优化
第一阶段:监督微调(SFT)
监督阶段采用三重联合损失。
第一项是掩码扩散损失 ,第三节已给出定义,是训练的基础。
第二项是结构感知扰动损失 ,专门为 AutoEdit 设计的监督信号。对专家轨迹施加两类物理合理的扰动后训练模型恢复——纵向进度扰动 ( 模拟激进/超速, 模拟保守/进度不足),以及横向航向扰动 (模拟偏航漂移):
第三项是可行驶区域场损失 ,利用感知模块输出的可行驶区域(drivable area)构造距离变换代价场,直接在 logits 上施加空间惩罚:
其中 DAC 代价场 , 为像素到最近可行驶区域边界的距离。如果模型给不可行驶区域分配了高概率,代价场产生的大梯度会强制纠正。
总监督目标:
第二阶段:RL 联合优化 —— 核心突破
这是整篇论文最重要的贡献。传统做法把起草器和编辑器解耦独立优化——起草器只管生成"看起来像专家"的草稿,但并不知道编辑器能修正什么;编辑器只管把草稿修得更像专家,但缺乏整体驾驶奖励的指引。两者各自达到了"局部最优”,但 AutoEdit 在解耦设定下的增益只有约 +0.3 PDMS(NAVSIM v1 navtest),几乎可以忽略。
ReflectDrive-2 的做法是把起草和 AutoEdit 阶段的 token 转换拼接成一个完整动作序列:
终端奖励(NAVSIM v1 navtest PDMS 闭环规划分数)只分配给编辑后的最终轨迹,然后通过 PPO 策略梯度 + group-relative advantage 回传到所有实际发生 token 变更的位置:
几个细节决定了这套 RL 能否稳定跑通。Group-relative advantage 在同一采样组内相对化,是 GRPO 风格的方差缩减。Token 变更指示器 保证信用只分配给真正被更新的位置,避免对"保持不变"的 token 产生虚假梯度。PPO clip 限制策略更新幅度,KL 项把 约束在 SFT checkpoint 附近。
联合优化带来的涌现效应是:起草器学会产出可修正的草稿(编辑后得分高于编辑前),编辑器学会朝驾驶奖励方向而不是 token 级不确定性方向修正。AutoEdit 的增益从 +0.3 跳到 +1.9 PDMS,差不多 6 倍。这是 89.1 到 91.0 PDMS 的全部来源。
六、离散扩散 vs LLaDA:不是简单移植
把 ReflectDrive-2 称作"AD 领域的 LLaDA"是诱人但危险的类比。LLaDA 是语言侧的 token-level discrete diffusion:状态空间是离散 token id(vocab size 在 12 万量级,LLaDA-8B 为 126,464,接近 LLaMA3 的 128K),forward noising 是对每个 token 以一定概率独立替换为 [MASK],去噪目标是从被 mask 的句子里恢复原 token。看上去 ReflectDrive-2 把同一套机制搬到了轨迹上——但只要按下面四个维度展开,就会发现这两者其实只在表面同构。
Codebook 的设计。LLaDA 的 codebook 是预定义的语言 token 词表,BPE 分词在大规模文本预训练前就已经固化。ReflectDrive-2 必须先学一个 trajectory-specific codebook:8 个航路点的 16 维坐标序列要被量化成离散 token,词表大小通常在 256-1024 之间。codebook 学习本身是非平凡问题——VQ-VAE 式架构在图像和音频上反复出现的 codebook collapse 与 dead code 现象,在轨迹空间到底有没有?专家轨迹分布相对集中(多数时段是匀速直行),codebook 的有效维度很容易塌缩到少量"主流"token,长尾行为对应的 token 可能从训练初期就接近死码。论文没有详细汇报 codebook 的健康度指标,这是一个待补的实验。
Forward process 的物理意义。LLaDA 的"以概率 把 token 替换为 [MASK]“在语言上对应"以 的强度模糊化语义”,物理意义清晰;ReflectDrive-2 把同样的 random replacement 套到 trajectory token 上,问题在于:两个相邻 waypoint 各自独立 mask 之后再去噪,模型是否会重建出"瞬移"或"急转弯"这种物理不可行的轨迹?语言空间允许"局部不合语法"的中间态——读者可以忍受;轨迹空间不允许局部不合物理的中间态——它会立刻穿墙。论文用 (可行驶区域场损失)和 (结构感知扰动)打了两层补丁,本质上是在用辅助监督把"物理可行性"硬塞回 forward process 的归纳偏置——这与 LLaDA 不需要任何此类辅助形成鲜明对照。
Reflection 机制的不同含义。把 LLaDA 的 self-editing 用到一句话上,本质是 self-consistency:让 LLM 重新读自己生成的句子并在 token 级修正,靠的是模型自身对语言分布的判断。ReflectDrive-2 的 reflection 走的是另一条逻辑:修正依据是"轨迹的物理可行性 / 约束满足"——可行驶区域、碰撞时间、舒适度等都是模型外部的硬约束,而非靠"轨迹分布的自洽性"做自我裁判。前者是 self-consistency,后者是 self-validity。把两者用同一个词"reflection"包装容易掩盖底层差异。
AutoEdit 在 LLaDA 没有直接对应。LLaDA 的迭代过程是 mask、unmask、再 mask 的循环;ReflectDrive-2 的 AutoEdit 是 token 到 token 的就地改写,输入端就没有 [MASK],模型读到的是一个"完整候选解"并逐位置决定是否替换。这种 read-then-rewrite 的算子在语言侧并不常用——LLaDA 系列论文中找不到完全对应的概念。AutoEdit 更像是为 AD 量身设计的新算子,利用了"轨迹具有外部物理校验信号"这一与语言任务不同的特殊性,并非从语言侧迁移过来的成熟模式。
把四条放在一起看,离散扩散在 AD 上更像是"trajectory 可以被视作 discrete sequence"这一假设的硬编码:codebook、forward noising、reflection 的具体形式都要为这一假设付出额外的工程代价,并非 LLaDA 范式的直接移植。这一假设在 NAVSIM v1 navtest 这种短时窗(8 个航路点)规划上看起来是工作的——91.0 PDMS 是证据——但它在更长时窗、更复杂城市路网上是否仍然成立,是这条技术路线接下来必须回答的开放问题。
七、实验结果
NAVSIM v1 navtest 主表
| 方法 | 传感器 | NC↑ | DAC↑ | TTC↑ | Comf.↑ | EP↑ | PDMS↑ |
|---|---|---|---|---|---|---|---|
| UniAD | Cam | 97.8 | 91.9 | 92.9 | 100.0 | 78.8 | 83.4 |
| TransFuser | C&L | 97.7 | 92.8 | 92.8 | 100.0 | 79.2 | 84.0 |
| Hydra-MDP | C&L | 98.3 | 96.0 | 94.6 | 100.0 | 78.7 | 86.5 |
| DiffusionDrive | C&L | 98.2 | 96.2 | 94.7 | 100.0 | 82.2 | 88.1 |
| GoalFlow | C&L | 98.4 | 98.3 | 94.6 | 100.0 | 85.0 | 90.3 |
| AutoVLA | Cam | 98.4 | 95.6 | 98.0 | 99.9 | 81.9 | 89.1 |
| DriveVLA-W0 | Cam | 98.7 | 99.1 | 95.3 | 99.3 | 83.3 | 90.2 |
| ReCogDrive | Cam | 97.9 | 97.3 | 94.9 | 100.0 | 87.3 | 90.8 |
| ReflectDrive-2 | Cam | 97.3 | 98.1 | 92.5 | 100.0 | 89.4 | 91.0 |
所有数字均在 NAVSIM v1 navtest 上报告。EP(前进效率)89.4 是最显眼的一项,远超 GoalFlow 的 85.0 和 ReCogDrive 的 87.3——离散扩散规划的轨迹在空间利用率上占优。值得提醒的是与 GoalFlow(Cam+LiDAR)相比,ReflectDrive-2 是纯相机输入。
Best-of-6 oracle 设定下 PDMS 进一步抬到 94.8,与 NAVSIM 给出的 Human reference 94.8 持平——选择能力(候选多样性 + 评分器)的天花板已经够到了人类水平。
AutoEdit ablation:RL 是放大器
| 训练设置 | w/o AutoEdit | w/ AutoEdit | Δ PDMS | 增益倍数 |
|---|---|---|---|---|
| DLM only | 84.8 | 85.0 | +0.2 | — |
| DLM + DACF (field loss) | 87.2 | 87.3 | +0.1 | — |
| DLM + DACF + AutoEdit train | 87.7 | 88.0 | +0.3 | 基线 |
| DLM + DACF + AutoEdit + RL | 89.1 | 91.0 | +1.9 | 6.3× |
监督训练下 AutoEdit 最多贡献 +0.3 PDMS(NAVSIM v1 navtest);RL 联合优化后增益跳到 +1.9,约 6.3 倍。这是 89.1 到 91.0 的全部来源,也是本文最核心的实验证据。其他消融(DACF 的 +2.4、AutoEdit 训练目标的 +0.5、RL 阶段对 EP/TTC 的 trade-off)详见论文 Table 3;FFN 精简与 Thor 部署的细分数字详见论文 Table 4-5。
八、部署:Thor 上 31.8 ms/帧
在 NVIDIA Thor 上,通过共享前缀 KV 缓存复用、可变缓存回退与合并改写、Action Expert FFN 精简到 1024、CUDA Kernel 融合 token 更新、以及 ASD(alternating-step decoding,交替步解码)五项优化,全步推理延迟从 45.0 ms 压到平均 31.8 ms/帧,满足 30 fps 的实车要求(详见论文 Table 4-5)。ASD 的核心思路是"全步帧 + 轻量帧"交替——全步帧跑完整三阶段,轻量帧只对前一帧的规划做刚体变换 + 1+1 步短时 AutoEdit;轻量帧延迟 18.6 ms,整体 PDMS 损失仅 0.20。
九、开放问题
第一是离散化在 AD 决策上是否必要。从第六节实验表读出来的事实是:91.0 PDMS(NAVSIM v1 navtest)相比同时期 ReCogDrive 90.8、DriveVLA-W0 90.2 的差距其实在 0.2-0.8 PDMS 范围内,而 AutoEdit + RL 联合优化贡献了 +1.9 PDMS。换句话说,“赢"的主要来源是"在完整 draft-then-edit 链路上做 RL"这一训练范式,“离散化轨迹"本身的独立贡献其实不大。这就引出一个干净的实验假设:把同样的 draft-then-edit + RL 联合优化范式套到连续 Diffusion 上(continuous diffusion + 局部修正算子 + 终端奖励 PPO),能不能拿到接近 91.0 的 PDMS?如果能,那么离散化就是工程便利问题;如果不能,那一定要回答"离散化提供了什么连续空间提供不了的归纳偏置”。论文没有给出这一对比,是个缺口。
第二是实时性的硬天花板。31.8 ms/帧 + 2-3 步 reflection 已经把 30 Hz 控制频率的预算几乎用满。如果未来场景复杂度上升(城市路网、密集人群、长 horizon),需要 ≥ 4 步 reflection 才能稳定收敛,那么"离散扩散 + reflection"作为 AD policy 的范式就会撞上一个 fundamental latency bottleneck——这是和"连续 Diffusion + 1 步去噪 head"路线的根本区别(后者推理步数可以蒸馏到 1)。ASD 的"轻量帧 + 全步帧"交替本质是在用工程手段平摊这个 bottleneck,但只能平摊不能消除。
第三是codebook 在 OOD 轨迹上的失败模式。trajectory codebook 必须在训练数据(NAVSIM 训练集)上学到——但 NAVSIM 的轨迹分布是否充分覆盖了部署场景的全部物理可行轨迹?如果部署时碰到一个训练集里没出现的"急刹 + 反向偏转避让"动作,最接近的 codebook entry 是哪个?模型会优雅地用一组次优 token 拼出近似轨迹,还是会硬塞到一个完全错误的 cluster 上?论文在 NAVSIM 之外没有给出 OOD 评估——而这恰恰是量产关心的部分。一个值得加做的实验是:在 codebook 上做 codebook-distance 直方图,统计 OOD 场景下最近邻距离的尾部分布,作为部署风险的代理指标。
参考文献
1. ReflectDrive-2: Reinforcement-Learning-Aligned Self-Editing for Discrete Diffusion Driving. arXiv:2605.04647†
2. ReflectDrive (v1): 前作,首次将 self-editing 引入端到端规划
3. NAVSIM: End-to-end autonomous driving benchmark (v1 navtest split used in this article)
4. LLaDA: Large Language Diffusion with mAsking. 语言侧 masked discrete diffusion 的代表工作,本文第六节对照基准
5. GoalFlow / DiffusionDrive / DriveVLA-W0 / ReCogDrive: NAVSIM v1 navtest 同期对比方法,数字均来自各自原文
† 该 arXiv ID 为 2026 年的预占位编号,待论文正式公开后更新到最终 ID。