扩散语言模型加速的双轴难题：LATCH 如何用验证对象区分何时停与在哪加速

你不能通过检查每一粒米是否煮熟，来判断一道炒饭能不能上桌——你只能尝一勺。

2026 年 7 月底，arXiv 上挂出一篇让我读完后坐直的论文：NYMCU 和 Albany 团队的《Where and When to Commit: Candidate-Aware Decoding for Diffusion Language Models》。论文讨论的核心问题听起来很窄——怎么让扩散语言模型（DLM）跑得更快——但它给出的答案，触及了一个比 DLM 本身更深的工程原则：决策的颗粒度，必须和它所依据的证据颗粒度匹配。

这个原则不只适用于语言模型，它适用于所有需要"什么时候停"的 AI 系统。

一、场景：DLM 的"半成品"困境

先把背景拉清楚。

传统自回归模型（GPT 那一类）生成文本是从左到右一个 token 一个 token 吐出来的，像打字机。你看到第 5 个 token 时，前 4 个已经定了，改不了。

扩散语言模型（DLM）不一样。它从一段全遮罩的序列开始，像一张被涂黑的纸，然后一步步去遮罩。每一步，模型对每一个位置都给出一个临时预测。在第 10 步，位置 3 可能猜是"猫"，位置 7 猜是"是"，位置 12 猜是"动物"。到第 20 步，这些猜测可能都变了，也可能没变。

关键观察：在很多任务上，DLM 的候选答案在第 50 步就已经和第 100 步（完全去噪）的最终答案一样了。剩下的 50 步是浪费的算力。

这给了一个非常诱人的加速机会：能不能在答案稳定后就提前停？这就是所谓的 generation-time early exit。

听起来简单，做起来极难。因为"答案稳定了"这件事，你不知道。

二、已有的两条加速路线，和它们为什么失败

论文最值钱的地方，是它先把 DLM 加速的"两条轴"讲清楚了。这两条轴之前是被混在一起的。

第一条轴：WHERE（在哪加速）

这是 adaptive sampling 做的事。Fast-dLLM、SlowFast、KLASS 这些方法决定的是：在每一步去遮罩时，有多少位置可以"提前定下来"（commit）。比如 256 个位置，可能第 30 步就有 200 个位置置信度够高，可以直接固定，剩下 56 个继续慢慢去遮罩。

这条轴的本质是：在解码还在继续时，加快某些位置的提交速度。

第二条轴：WHEN（何时停）

这是 generation-time early exit 做的事。Prophet、SchED 这些方法决定的是：整个序列什么时候可以彻底停？什么时候可以宣布"答案已经稳定，把所有剩余遮罩位置一次性填满，结束"。

这条轴的本质是：整个序列的终止决策。

论文的关键洞察在这句话里：

A sampling commit fixes one position; termination freezes every remaining position at once, the answer included. The two axes therefore demand different evidence.

一个位置提交，固定的是一个 token。一次终止，固定的是所有剩余位置——包括答案本身。这两件事需要的证据，根本不在一个量级上。

而现有方法的问题，恰恰是把一个轴的证据用在了另一个轴的决策上。

Prophet 的失败：Prophet 用一个固定监控区域（比如序列末尾的某段）的置信度来判断"能不能停"。但这个区域可能看起来稳定，而真正的候选答案还在变。Prophet 一旦触发，就把所有剩余遮罩位置一次性填满，没有回头路。在 GSM8K、MATH 这种多步推理任务上，Prophet 的精度下降最多达 69 个百分点。

SlowFast 的失败：它只管"加快位置提交"，不管"答案是否稳定"。在所有 10 个长推理评测上，精度下降都超过了 2 个百分点的容忍线。

KLASS 的失败：只在它校准过的 LLaDA 上能用，换到 Dream 上就掉 5-52 个百分点。

问题的根源不是这些方法不够精细，而是它们问错了问题。

三、LATCH 的核心洞察：验证对象 > 验证信号

论文提出了一个叫 LATCH 的框架（Localized Acceleration with Tracked-Candidate Halting），由两个组件构成：CVC 管"何时停"，BWEC 管"在哪加速"。

但真正值得讲的不是这两个组件本身，而是它们背后的设计原则。论文里有一句话，我认为是整篇论文的题眼：

What separates LATCH from ever-finer per-position stability rules is the object being verified, not the signal; even if every position individually stabilized, no position-level rule could certify that the answer the task asks for exists and has stopped changing, a question only candidate extraction can pose.

翻译成人话：你可以检查每一个位置是否稳定，但"每个位置都稳定"不等于"答案稳定了"。因为"答案"不是一个位置，答案是从位置中 提取 出来的东西——它可能跨多个 token，可能在不同位置之间漂移。

这就像你不能通过检查每一粒米是否煮熟来判断一道炒饭能不能上桌。每一粒米都煮熟了，不代表这道菜做好了——因为"这道菜做好了"是关于 菜 的判断，不是关于 米 的判断。你需要的是尝一口炒饭本身，而不是检查每一粒米。

LATCH 的 CVC（Confidence-Verified Commit）做的就是这件事：每一步都重新提取候选答案，然后检查这个候选答案的置信度和稳定性。如果候选答案本身在持续稳定，那就可以停；如果候选答案还在变，哪怕每个位置的置信度都很高，也不能停。

这里有个非常漂亮的工程细节：CVC 用的是任务格式感知的解析器来提取候选答案。比如 GSM8K 的输出格式是 The answer is XXX，CVC 就在每一步从当前去遮罩的序列里提取这个 XXX。如果 XXX 在变，就不能停。这叫 format-aware but prompt-anchor-free——它知道答案长什么样，但不需要你提前告诉它答案在哪。

这和 Prophet 形成鲜明对比。Prophet 需要一个 suffix prompt（后缀提示），你得提前知道答案大概在序列末尾的某个区域，然后监控那个区域。但很多任务的答案位置不固定——比如推理链中间突然给出答案，或者答案在多个位置之间跳。Prophet 的固定监控区域在这些场景下就失效了。

CVC 的"动态重提取"绕过了这个问题：答案在哪，我就去哪验证。

四、BWEC：把"在哪加速"和"何时停"分开

CVC 只管"何时停"，那"在哪加速"呢？这是 BWEC（Block-Wise Early Commit）的工作。

DLM 的序列通常被分成多个 block。比如 256 长度的序列可能分成 4 个 block，每个 64。BWEC 的逻辑是：

• 非最终 block：用便宜的局部规则加速。这些 block 通常是中间推理过程，不是最终答案，用简单的置信度阈值就够了。
• 最终 block：保留原始调度，由 CVC 全局监控。

这个设计非常克制。BWEC 没有试图用一个统一规则管所有 block，而是承认：不同 block 的重要性不一样，应该用不同强度的验证。最终 block 装着答案，要严格；中间 block 装着推理，可以宽松。

这又回到了那个原则：决策的颗粒度要和证据的颗粒度匹配。最终 block 的决策（能不能停）用候选答案级别的证据；非最终 block 的决策（这个位置能不能提前 commit）用位置级别的证据。各管各的，不串台。

五、数据：一组超参数，两个 backbone，11 个任务

实验结果是我见过最干净的之一。

评测范围：11 个任务，覆盖短答案（MMLU、HellaSwag、WinoGrande、PIQA、TruthfulQA、ARC-C）和长推理（GSM8K、MATH、SVAMP、ASDiv、GSM-Hard），2 个 backbone（LLaDA-8B-Instruct、Dream-7B-Instruct），共 22 个评测设置。

核心数据：

最让我印象深刻的是这行：

with one frozen hyperparameter set that transfers cross-backbone untuned

一组超参数，在两个完全不同的 DLM backbone 上都不用调。这在当前 LLM 实验里几乎见不到——大家都在 per-task、per-model 调参。LATCH 能做到不调，是因为它的设计本身是任务格式感知的，不依赖具体模型的数值特性。

论文还给了一个非常有说服力的失败案例分析：在 GSM8K 上，Prophet 在第 30 步触发终止（因为它的固定监控区域看起来稳定了），但真正的候选答案在第 80 步才稳定。CVC 在第 80 步才触发，因为它每一步都重新提取答案，发现答案还在变。

六、工程洞察：三个比 DLM 本身更深的启示

这篇论文的价值不止在于 DLM 加速。它给了三个可以迁移的工程原则。

原则一：决策颗粒度 = 证据颗粒度

这是论文的核心。你在做"序列级"决策（终止）时，不能用"位置级"证据（单个位置的置信度）。你在做"位置级"决策（单个位置 commit）时，不需要"序列级"证据（整个答案稳定）。混用就是灾难。

这个原则可以直接迁移到 Agent 系统设计：监控的颗粒度要和被监控对象的颗粒度一致。一个 Agent 的"任务完成"判断，不能用"每一步都看起来正常"来代替——你需要的是对"任务本身"的验证，不是对"每一步"的验证。这和步子哥之前关注的 Heddle、CodeRescue 的"颗粒度同构"原理完全同构。

原则二：验证对象 > 验证信号

论文最深刻的一句话："What separates LATCH from ever-finer per-position stability rules is the object being verified, not the signal."

你可以把位置级别的稳定性规则做得越来越精细，但只要验证的是"位置"而不是"答案"，就永远问不出"答案是否稳定"这个问题。因为这个问题只有 提取答案 这个动作才能提出。

这像不像 AI 评测领域的"评测盲区定律"？你测什么就优化什么，不测的就是问题藏身处。LATCH 的洞察是它的镜像：你验证什么就信任什么，不验证的就是风险藏身处。Prophet 验证位置，就只敢信任位置；CVC 验证候选答案，才敢信任候选答案。

原则三：格式感知 > 提示锚定

Prophet 需要 suffix prompt（你得告诉它答案大概在哪），LATCH 只需要 task format（它知道答案长什么样，自己找）。这是一个从"提示工程"到"格式工程"的范式转移。

提示锚定是脆弱的——换个任务格式就失效；格式感知是鲁棒的——只要任务有结构化输出，LATCH 就能工作。这也是为什么一组超参数能跨 backbone：它依赖的是任务格式，不是模型特性。

七、和概念谱系的连接

步子哥之前我们梳理过"换层面解决问题"七部曲：章鱼 RNA 编辑→黏菌外化记忆→鸟类量子磁感应→SOPHIA 分工→EvoThink 原子推理→Möbius RoPE 拓扑干预→螳螂虾声子盾牌。LATCH 可以作为第八个成员。

LATCH 的"换层面"体现在：它没有试图把位置级别的稳定性规则做得更精细（在同一个层面优化），而是换到候选答案级别（换一个层面）。位置稳定 ≠ 答案稳定，这是两个不同层面的概念，不能用同一个指标衡量。

同时，LATCH 也丰富了"评测盲区定律"：Prophet 的失败不是因为监控区域不够大或阈值不够精，而是因为它监控的对象（位置）和它要保证的对象（答案）不是同一个东西。监控盲区不只是"没测到"，还包括"测错了对象"。

八、局限与开放问题

论文很诚实地讨论了局限：

• 依赖答案可提取性：CVC 需要能从中间状态提取候选答案。如果任务格式是自由生成（比如写一首诗），没有明确的"答案"概念，CVC 就退化成普通的位置级规则。论文在 Appendix H 讨论了这个"答案跨度假设"什么时候会崩。

• Dream 上的特殊情况：Dream-7B 在 GSM8K/MATH 上很少在解码后期留下可提取的候选答案，所以 CVC-only 在这些任务上反而比 baseline 慢（0.46-0.47×）。BWEC 在这里救了回来，通过加速非最终 block。

• 长推理加速比短答案低：短答案 9-17×，长推理只有 2-3.3×。这是因为长推理的答案稳定得晚，CVC 必须等到最后。这不是 LATCH 的失败，而是任务本身的特性——你不能在答案还没稳定时就宣布它稳定了。

九、代码与复现

论文宣称代码在 https://github.com/ming053l/LATCH-dLLM。我写这篇文章时去看了，仓库还没公开（论文 7 月 30 日刚挂出来，代码可能还在整理）。但论文的算法描述非常完整，CVC 和 BWEC 的公式都给了，超参数也全列了，理论上可以自己复现。

十、个人思考

这篇论文让我想到一个更广的问题：AI 系统的"停止决策"是一个被严重低估的工程问题。

不只是 DLM——RL agent 的训练什么时候停？推理什么时候停？工具调用什么时候停？这些问题目前都用粗糙的启发式在处理：max steps、max tokens、loss 下降到某个阈值。但 LATCH 提醒我们：停止决策的颗粒度，决定了系统的效率和可靠性的上限。

LATCH 的 CVC 给了一个漂亮的范例：停止决策应该基于"你要的东西"的稳定性，而不是"你容易测量的东西"的稳定性。这两者之间的差距，就是效率的浪费和可靠性的隐患。

在 Agent 时代，这个原则会越来越重要。当 Agent 的轨迹越来越长、越来越复杂，"什么时候停"会变成一个比"怎么走"更难的问题。LATCH 给了一个可以借鉴的设计模板：找到你要验证的对象，每一步都重新提取它，只在它稳定时才停。

这个原则，比 DLM 加速本身更值钱。

论文：arXiv:2607.28166
代码：https://github.com/ming053l/LATCH-dLLM（论文发表时未公开）
评测：11 任务 × 2 backbone = 22 设置，全部在 2.0 点精度容忍内
加速：短答案 9.3-17.8×，长推理 2.0-3.3×
关键洞察：验证对象 > 验证信号；决策颗粒度 = 证据颗粒度