ASSCG：自动驾驶慢思考，不该每一帧都问 LLM
Paper Signal # 自动驾驶 / LLM / Fast-Slow Planning / Gate / GRPO | 论文：ASSCG: Just-Right Gating over Chattering for Fast-Slow LLM Planning in Autonomous Driving这篇论文真正讨论的不是“LLM 能不能做自动驾驶规划”，而是一个更工程的问题：慢系统什么时候值得被调用，什么时候应该复用，什么时候反而应该被压下去。ASSCG 给出的答案是，把 LLM 慢系统调用变成逐帧的 Query / Cache / Drop 决策。核心结果很直接：在 nuPlan Hard20 上，AdaptiveAsyncDriver + ASSCG 得到 67.28，比 AsyncDriver 高 +2.28，同时平均端到端推理延迟降低约 60%；在 NAVSIM 的 RecogDrive-based 双系统上，PDMS 达到 91.4，相对 ReCogDrive 高 +0.6，平均速度提升约 25%。
图注：这张图概括 ASSCG 的核心逻辑：慢系统并非越频繁越好，关键是把 Query、Cache、Drop 放在正确的时间窗口里。01 问题不是“要不要 LLM”，而是“何时信 LLM”
自动驾驶规划里的 LLM / VLM 慢系统，价值在于常识、语义理解和长尾场景解释；代价也很明确：推理慢、算力重、闭环控制链路里不好逐帧等待。
快慢系统范式因此很自然：快规划器每帧跑，慢系统低频给高层指导。但论文指出，现有做法常常落在两个极端：要么固定间隔调用，要么用“场景复杂度”这类启发式触发。
这两个方案都容易失准。固定间隔看不见场景内部的时间变化；复杂度触发又未必等于“这一次慢推理真的会改善规划”。更关键的是，慢系统并不总是正收益，某些片段里它会因为距离估计、遮挡理解或交互规则判断错误而把规划带偏。
因此，ASSCG 的立意可以概括成一句话：自动驾驶 LLM 规划需要的不是更多慢思考，而是可治理的慢思考生命周期管理。
图注：固定间隔、复杂度触发和 ASSCG 的对比：ASSCG 不按场景级频率做粗调，而是在每一帧选择 Query / Cache / Drop。02 三个动作：Query、Cache、Drop
ASSCG 的动作空间很克制，只有三个 token，但这三个 token 刚好覆盖了慢系统调用的生命周期。
- Query：调用慢系统，刷新 reference memory buffer。适合场景状态发生实质变化、缓存指导不再新鲜、慢推理的边际收益大于调用成本的时刻。
- Cache：不调用慢系统，继续复用缓存指导。适合慢指导仍然有效、重复查询不会明显改变控制结果的 Equivalent Interval。
- Drop：不只是“不调用”，而是主动忽略缓存慢指导，用 zero feature 代替。适合慢指导可能过期、误导或处在 Failure Interval 的片段。
这里最值得注意的是 Drop。很多加速方案只关心少问几次，ASSCG 则承认慢系统会“负贡献”，并给系统一个显式的撤销通道。
图注：从业务链路看，ASSCG 像一个慢系统调用网关：判断是否发起慢推理、是否复用缓存、是否屏蔽慢指导，再把结果送入快规划器。03 三类时间窗口：为什么慢系统会失效
论文为了分析“何时问慢系统”提出了三个概念。这三个概念比单纯讨论 query rate 更有解释力。
- Equivalent Interval (EI)：重新问慢系统几乎不会带来新信息，缓存指导仍然足够新鲜。这时继续 Query 主要是在浪费算力。
- Effective Interval (EfI)：当前慢指导确实被快规划器有效使用，应该被缓存和延展。
- Failure Interval (FI)：调用慢系统反而让下游表现变差，此时应该避免慢指导介入，甚至主动 Drop。
图注：论文 Fig.2 的直行案例：ASSCG 只在第 0、22、89 帧查询慢系统，却避免了 always-query baseline 的碰撞；图中同时展示 EI、FI、EfI。这个案例非常关键：慢系统不是连续越密越安全。车辆在第 25 到 40 帧附近进入 Failure Interval，慢指导会伤害决策；ASSCG 通过少量查询和选择性压制，反而得到更稳定的闭环行为。
04 框架：慢系统被接入，但不再主导每一帧
在 AsyncDriver 版本里，底层快规划器是 GameFormer-style planner；慢系统是 LLaMA2-13B 经 LoRA 做驾驶域适配后的 LLM。插入 ASSCG 后，原始 AsyncDriver 参数被冻结，只训练门控模块，这样实验能更干净地检验“调度和使用慢系统”本身的贡献。
图注：ASSCG 总体框架：当前场景编码、缓存相似度、距离上次慢查询的时间等信号进入 RWKV gate，输出 Query / Cache / Drop。ASSCG 的输入包括当前场景 embedding、reference memory buffer、当前特征与 buffer 的余弦相似度，以及距离上次 slow query 的时间特征。论文使用 attention pool 聚合线索，再交给 RWKV-7 blocks 建模长时序上下文。
为什么选择 RWKV？因为门控需要看完整 episode 的历史，Transformer 注意力的长上下文成本会随长度上升；RWKV 在缓存状态后更适合逐帧在线推理。
05 公式：慢指导如何进入快规划器
慢系统的输出不是直接替代快规划器，而是作为 instruction feature 注入 decoder block 的 cross-attention。论文给出的核心形式如下：
图注：h 是由慢指导投影得到的 instruction feature，s 是 scene feature，g 是可学习 gate；慢指导通过第一项影响 scene feature。这条公式背后的工程含义是：慢系统并不直接开车，而是在快规划器的中间表示里提供额外语义线索。ASSCG 决定这条慢指导路径是否更新、复用或屏蔽。
06 训练：从固定频率伪标签，到带成本的 RL
训练分两步。第一步是 SFT：作者在训练场景里跑一组固定查询频率，例如 1、3、5、10、20、50、100 帧一次以及 Never-Query，选出每个场景闭环得分最高的 rollout，并把对应动作序列作为伪标签。
第二步是 GRPO-style reinforcement fine-tuning。此时目标不再是模仿固定频率，而是直接优化闭环分数，同时扣除 Query 成本。
图注：奖励由势函数变化和慢系统调用成本组成；Query 越频繁，成本项越大。SFT 解决“门控先学会基本行为”，RL 解决“固定频率伪标签不够细”。这也是 ASSCG 相比单纯网格搜索更重要的地方：它最终学的是逐帧策略，而不是某个场景类型的常数 K。07 结果：少问，但不是粗暴少问
先看 nuPlan Hard20。ASSCG 的总分是 67.28，高于 AsyncDriver 的 65.00，也高于 VLM-planner 的 66.66。更细地看，它的路线进度并不是最高，但在 drivable area、direction、comfort、collision、TTC 等安全与规则项上更稳。
图注：关键数字单独整理成结果板；原论文表格随后给出完整指标。
图注：nuPlan Hard20 主结果：ASSCG 以 67.28 达到最高综合分，安全和规则相关分项更稳。nuPlan 的综合分本身也解释了为什么“只追进度”不够。论文附录给出分数计算：
图注：nuPlan score 把进度、TTC、限速、舒适性与碰撞、可行驶区域、方向等约束相乘；某些硬约束失效会直接拉低总分。再看效率。AsyncDriver 每帧都调用慢系统，平均 0.80 s/frame；固定 5 帧调用一次能降到 0.32 s/frame，但分数掉到 64.27。ASSCG 也保持 0.32 s/frame，却把分数推到 67.28。
这就是本文最有说服力的结果：ASSCG 并不是简单减少慢系统调用，而是在类似固定 5 帧的延迟预算下，学到了更好的调用时机和屏蔽时机。
图注：NAVSIM 与延迟对比：在 RecogDrive-based 双系统上，ASSCG 得到 91.4 PDMS；在 AsyncDriver 上保持 0.32 s/frame 同时提升分数。NAVSIM 上的版本更像一个 one-shot binary gate：fast 分支是轻量 ViT-based planner，slow 分支保留 ReCogDrive 的 InternVL-2B VLM。每个场景只选一个分支执行，gate 本身约 19 ms，slow branch 约 355 ms，fast branch 约 97 ms。论文报告 learned policy 选择 slow branch 的比例约 40%，平均端到端约 270 ms。
08 固定频率为什么不够
附录里的 fixed-schedule grid search 很能说明问题。14 类 Hard20 场景的最佳固定 K 差异巨大：有的需要 K=1，有的 K=3、5、10、20、50；表中甚至出现 High lateral acceleration 类型下 Never-Query 最优。
图注：按场景类型搜索最佳固定查询频率：最佳 K 从 1 到 50 都有，部分场景类型甚至更适合 Never-Query。这说明“固定每 K 帧问一次”不是一个稳健的工程策略。更重要的是，这张表仍然只是 type-level 固定 K，同一场景类型内部还会有更细的时间变化。ASSCG 的逐帧门控正是为了解决这层粒度。
09 消融：Drop 和 RWKV 都不是装饰
训练策略上，SFT 从 65.00 提到 66.21；加 PPO 到 66.76；SFT+GRPO 到 67.28。论文解释 PPO 存在不稳定和 mode collapse，可能与组合式闭环指标和长时序回报估计有关。
图注：训练策略和 backbone 消融：GRPO 带来最高分；RWKV 与 Transformer 分数接近，但长上下文最后一帧延迟更低。控制策略对比也很清楚：All Query 是 65.00，All Drop 是 62.05，第一帧 Query 后一直 Cache 是 63.71，随机策略只有 62 左右。ASSCG 达到 67.28，平均查询间隔 5.26 帧。论文还报告动作比例约为 Cache:Query:Drop ≈ 6:2:1。
图注：不同控制策略对比：全 Query、全 Drop、只 Cache 和随机策略都不如 ASSCG。最容易被忽略的是 Drop 消融。把动作空间从 Query/Cache/Drop 限制成 Query/Cache 后，平均查询间隔差不多，但分数从 67.28 降到 66.71。
图注：Drop 动作消融与使用统计：去掉 Drop 后分数下降；Drop 出现在 12% 的帧、45% 的 episode 中。这证明 Drop 不是为了进一步省算力，而是为了避免慢指导在 Failure Interval 里继续影响快规划器。换句话说，ASSCG 的价值不只在“问得少”，也在“敢于不信”。10 迁移到 NAVSIM：从三动作到二分支选择
在 NAVSIM 上，由于任务是 one-shot 4s 轨迹预测，ASSCG 去掉 buffer 和 time-since-last-call 特征，动作空间也从 Query/Cache/Drop 简化成 fast vs. slow 二分类。
图注：RecogDrive-based NAVSIM 快慢系统：fast 分支和 slow 分支共享扩散规划器形式，但不共享权重；ASSCG 选择执行哪一个分支。这部分的意义是验证“门控慢系统调用”不是只绑定 AsyncDriver。论文还补充了替换 Qwen3VL-8B slow branch 的结果：PDMS 约 91.37，并比始终使用该 slow branch 加速约 24.7%。
11 这篇论文的价值和边界
ASSCG 的价值在于把 LLM 规划从“能力叙事”推进到“调用治理”。它没有假设 LLM 永远正确，也没有把慢系统包装成越多越好，而是把慢推理当作一种高成本、可能正收益也可能负收益的资源。
- 工程价值：给快慢系统一个清晰接口，只要求 fast branch、optional slow branch 和 cached guidance representation，能相对自然地插入现有双系统规划器。
- 方法价值：用 Query / Cache / Drop 显式表达慢系统生命周期，尤其是 Drop 把“慢指导有害”从隐含异常变成可学习动作。
- 评测价值：同时报告闭环得分和延迟，避免只看 planner 分数却忽略在线部署成本。
- 边界：实验验证的是“在已有快慢系统中如何使用慢分支”，并不能直接证明所有 benchmark 或所有场景都必须依赖 LLM reasoning。
更高层的启发是，自动驾驶里的大模型不应该只按模型能力大小来管理，而应该按“数据-训练-推理-缓存-失效”的生命周期来管理。ASSCG 正好提供了推理阶段的一个可学习控制器。12 资源链接
- 论文：https://arxiv.org/abs/2606.25509
- 项目页：https://williamxuanyu.github.io/asscg/
- 代码仓库：https://github.com/WilliamXuanYu/ASSCG。截至 2026-06-28，仓库 README 仍显示
Coming soon~!，可先关注后续代码释放。
13 结论
ASSCG 最值得记住的判断是：自动驾驶 LLM 规划的下一步，不只是把慢系统做得更强，而是让系统知道什么时候该慢、什么时候该复用、什么时候该切断慢指导。
- 慢系统不是越常问越好，关键是每一次调用的边际价值。
- 缓存不是偷懒，而是在 Equivalent / Effective Interval 中延展慢指导收益。
- Drop 是自动驾驶 LLM 规划里很重要的安全阀：当慢指导可能误导时，系统必须有能力不信它。
从这个角度看，ASSCG 做的不是一个小型调度器，而是在给自动驾驶快慢系统补上一层推理资源生命周期管理。
10个月宝宝每天需要喝多少奶粉？
