让草稿模型别再自己读一遍历史

让草稿模型别再自己读一遍历史

先看两个数字。第一个：投机解码在普通任务上一次能通过四五个草稿 token，可到了 agent 干活的长上下文里，最好用的几个方案会掉到只剩一两个，跌幅超过 80%——上海交大戴国浩组（联合清华与无问芯穹）10 月 16 日挂出的论文 DLite 开篇就给了这张对比图。第二个：他们用 SGLang 实测 DeepSeek-V4 的多 token 预测模块，发现光是草稿侧 KV 缓存的更新和维护，就能吃掉端到端推理延迟的 10% 到 20%。也就是说，本该提速的机制，在 agent 场景里一边降速一边收过路费。

问题出在哪？论文把两个症状归到了同一个病因：草稿模型是一个独立的模型，它必须自己把全部历史上下文读一遍、存一遍。普通聊天里上下文短，这个成本无所谓；agent 场景里上下文又长又不停地演化，每轮交互都在变长——草稿模型重复编码的历史越来越长，预测越来越不准（接受率暴跌），KV 缓存越来越大（系统开销暴涨）。病因明确了，解法就顺理成章：历史反正已经被目标大模型处理过一遍了，草稿模型为什么还要自己再读一遍？DLite 的做法是直接拿目标模型已经算好的隐层表示当输入，草稿预测从「对越来越长的历史建模」变成「围绕当前解码位置做局部预测」——问题的复杂度不再随序列长度增长，草稿侧的历史 KV 缓存彻底清零。

具体实现是两层结构。底层是一个无历史的并行骨干：因为目标模型的隐层和普通 token 嵌入来源不同，模型学了一组「深度嵌入」来区分它们，隐层取自目标模型的哪些层也有讲究——首尾两层必留，中间层均匀采样，Qwen3-4B 取 12 层、8B 取 14 层。上层是一个低秩 RNN 式的轻量顺序头（秩 320/512）：并行预测天生看不见投机块内前面几个草稿 token，这个头负责把块内已生成的 token 递归压进一个状态里，把块内因果补回来，同时避开昂贵的全词表投影。训练用两阶段：先训一个结构同构、带历史的教师模型弥合结构差异，再和目标模型做分布对齐，全程 32 块 H800，数据是 Open-PerfectBlend 的 130 万样本加 NVIDIA Nemotron 的 60 万样本。

效果落在三个场景的对照表里。通用任务上，各家差异不大：Qwen3-4B 上 DLite 平均接受长度 6.38，略胜当前最优方案 DSpark 的 6.27——大家在这种舒服场景里都能一次过六七个 token。长上下文和 agent 任务上分出高下：SWE-Bench 上 DLite 加速 2.74 倍、平均接受 3.19 个 token，DSpark 只有 1.64 倍、1.88 个——70% 的领先就是这么算出来的；AgentLongBench 上更直观，并行草稿方案 DFlash 加速比掉到 0.95 倍，比干脆不开投机解码还慢，DLite 是 2.31 倍。代价不是零：DLite 在 agent 场景同样会退化（从 6.38 掉到 3 上下），只是退得远比同行浅。

有两个流传中的说法需要校准。其一，「首创」「首次系统性指出」这类字眼论文里没有——原文只说「我们发现增长的历史是两个问题的共同根源，并提出 DLite」；其二，「代码暂未公开」已经过时，仓库 10 月 7 日就建了，10 月 21 日还有推送，挂在 SJTU-DAI-Sys 名下，47 颗星，模型权重也上了 HuggingFace。

把这张图摆进更大的谱系里看会更有意思。这条 drafter 加速线上，EAGLE3 是自回归草稿（保因果但串行），DFlow、DFlash、DFlash2 是并行草稿（快但丢块内因果），DSpark 是当前最优，而 DLite 换了一条更釜底抽薪的路：草稿模型不再拥有自己的历史。同一晚我写过另一篇 ECHO——DeepSeek 系的 MTP 让主干末层自己当草稿头，DLite 让外部草稿头直接吃主干隐层，两个方案灵犀相通：既然历史在主干那里已经消化完毕，谁都别再背第二遍。Beam 刚开源时附带的 DFlash2 drafter 也在这个家族里。一个星期内，这条线的几家头部把同一个判断从三个方向各推了一步——草稿的未来不在更小的模型里，在更少的历史里。