arXiv'26 | Wind-MTP：百万上下文里，MTP 草稿头才是那个隐形税

August 16, 2026

2026   ·   LLM   投机解码   长上下文   推理优化   论文解读  

arXiv’26 | Wind-MTP：百万上下文里，MTP 草稿头才是那个隐形税

原文：Wind-MTP: Removing the Full-Context Draft-KV Tax

1. 前言：先把背景交代清楚

你有没有想过这样一个问题：投机解码里的草稿模型，真的是”几乎免费”的吗？

这个领域的标准成本公式我们都背得出：

\[L = \frac{T_\text{draft} + T_\text{verify}}{\tau}\]

过去两年的主流工作都在给这个公式的不同项动刀。DFlash 用 Diffusion drafter 把 $T_\text{draft}$ 从串行变成一次并行 forward；DSpark 用半自回归 + 置信度调度，草稿质量（$\tau$）和验收长度两头兼顾；Cassandra 更狠，不训练、直接从 target 模型的 bitstream 里抠出一个 draft 模型，把草稿的训练成本都省了。这些工作的共识是：草稿阶段必须便宜。

但还有一类 drafter 大家一直默认它是免费的：模型自带的 MTP/NEXTN 头。DeepSeek、Qwen 这些旗舰模型出厂就内置了 multi-token prediction 头，它就挂在主干上，共享 embedding、只有一两层，看起来”顺手多猜几个 token”几乎不花时间。

这篇 Wind-MTP（arXiv 2607.21535）戳破的正是这个幻觉：在百万 token 的上下文里，MTP 草稿头是全系统最贵的那一环。 1M context、γ=6 时，草稿阶段给每个 decode step 白加 92%–138% 的时间——几乎翻倍。而在最难的任务上，原生 MTP 甚至会跑输完全不开投机解码的 dense 解码（0.80×）。

解法说破了不值钱：给草稿头的 attention 开一个滑动窗口（W=4032），验收侧原封不动。就这么一个”drop-in、零训练、无新 kernel”的改动，1M context 端到端再提速 11%–53%，而且输出严格无损。

2. 病根：草稿头也在读全量 KV

先看这笔税是怎么攒出来的。

MTP 头虽然轻（一两层），但它用的是全量 attention：每猜一个草稿 token，都要把当前上下文所有历史 KV 读一遍。γ 个草稿 token 就是 γ 遍。短上下文时这笔开销可以忽略——单层 draft 的 KV 每 token 只有 1–2KB，8–32K 上下文里也就 8–64MB，全在 L2 里。但到了 1M context：

  • draft 的 KV 膨胀到 1–2GB，每一步 γ 次 HBM 全量读；
  • 与此同时，新一代模型的 target 主干纷纷换上 GDN（Gated DeltaNet）、Mamba2 这类线性/递归注意力，verify 一步的成本本来就被压得很低——target 越来越快，草稿头越来越像拖着后腿的秤砣。

论文 Table 1 给了三个模型的每步成本（1M、d=7、B=1、单张 B200）：

模型 原生 MTP 加窗口后 差值
Qwen3.6-35B-A3B 26.4 ms 18.3 ms +44.3%
Qwen3.5-122B-A10B 34.5 ms 26.5 ms +30.2%
Nemotron-3-120B 33.1 ms 25.8 ms +28.3%

每步成本对比

nsys 的 kernel 级分解更直观：原生投机解码的 overhead 是 +92%–138%，窗口化后压到 +45%–72%。

3. 解法：只给草稿开窗口

3.1 方法本体

Wind-MTP 的改动小到可以在一个 PR 里写完：把草稿头的 paged block table 截短为 sink 块 + 最近 W 块（W=4032，n_sink=64，即 StreamingLLM 式的”attention sink + 滑动窗口”），target 的验收 attention 一个字都不动。

4K 的窗口只占 1M 上下文的 0.4%，等于把 99% 的草稿 KV 从读取路径上删掉。配套实现上用一个 n_sink+W+d 槽位的紧凑 ring buffer，把草稿 KV pool（占总 KV 的 7.7%–11.1%）也一并省了——同样的显存能多塞下一个 1M 请求，原生 MTP 直接 OOM 的批次它还能接着跑。

3.2 为什么是无损的

这点值得单独强调：投机解码的输出分布永远由 target 的验收决定，草稿只影响”提议什么”，不影响”接受什么”。 所以改草稿头的 attention 不存在精度损失——greedy 输出的差异都落在验收侧本来就有的 bf16 batched-verify 噪声里。

草稿 attention 窗口化前后

3.3 为什么 acceptance 几乎不掉

这是全文最有趣的部分：把草稿的视野从 1M 砍到 4K，接受长度为什么不崩？论文给了三层证据：

  1. 剂量反应曲线：窗口从 1K/2K/4K/8K/原生 扫过去，Qwen-35B 的接受长度是 3.79/4.74/4.74/4.16/4.49——4K 窗口的 τ 比原生全量还高一点，TPOT 却从 6.04ms 降到 3.85ms。存在一个明确的联合最优；
  2. 草稿提议几乎不变：直接在运行时做 A/B 探针，窗口化后草稿 top-1 提议 86%–94% 的步骤完全不变，翻转基本发生在概率接近平局的 token 上（flip margin ≈0.49 vs 平均 5.16）；
  3. 机制解释：这三个模型的草稿头都架在递归混合底座上（GDN / Mamba2），远距离信息本来就由递归状态携带，attention 只需要管局部。甚至 Nemotron 这种 NoPE 模型窗口内 attention 质量只有 0.160，top-1 提议依然保住 86%——因为 Mamba2 状态里编码了远处上下文。

一句话：这类混合架构的草稿头根本不怎么用长程 attention，却一直在为它付全量的钱。

4. 端到端效果

4.1 主结果（1M、d=7、B=1、RULER niah_multiquery）

模型 vs 原生 MTP vs dense τ 变化 TPOT
Qwen3.6-35B +53% 2.55× 4.49→4.74 5.94→3.89 ms
Qwen3.5-122B +11% 1.75× 5.57→4.74 6.09→5.46 ms
Nemotron-3-120B +23% 1.58× 3.75→3.61 8.77→7.15 ms

端到端加速

注意 122B 那行：τ 明明掉了（5.57→4.74），TPOT 还是降了——成本端的赢大于接受端的输。而且任务越难、接受率越低的场景，窗口化的优势越大（简单多值任务 +4%，困难 CWE 任务 +38%）——因为原生 MTP 在这些场景里本来就亏，窗口把它救回正收益。

4.2 上下文越长，省得越多

“窗口楔子”（windowing wedge）随上下文增长：261K→1M，Qwen-35B 的成本优势从 +27% 涨到 +43%，每步节省的绝对时间从 3.4ms 翻到 7.9ms。这个趋势跟”上下文越来越长”的行业方向完全同向。

窗口优势随上下文增长

4.3 吞吐与硬件复现

  • 单卡 B200 批量扫描：窗口化在 6 个面板里 5 个 Pareto 占优；Qwen-35B 单用户 218 tok/s（dense 的 2.2×），B=5 时峰值 473 tok/s/GPU；
  • 2×B200 TP2：全批量 Pareto 占优，单用户比 dense 快 1.4–2.5×；
  • H100 + FP8 公开 checkpoint（RedHatAI/Qwen3.6-35B-A3B-FP8）复现：dense 12.26ms → 原生 7.48ms（1.64×）→ 窗口化 5.05ms（2.43×），τ 还略升（4.34→4.53）；
  • 后端消融很诚实：窗口化跑在较慢的 Triton 后端（原生用 FlashInfer），单后端 handicap 约 6×，赢的仍然是窗口本身。

5. 我的 Take

投机解码这个领域卷了两年”草稿怎么打”，这篇提醒大家抬头看一眼：草稿的执行成本本身也在被上下文长度通货膨胀侵蚀。而且它不是孤立现象——target 侧换线性注意力（我在 NSA 和 DeepSeek V3.2 的解读里聊过稀疏化的趋势）之后，草稿侧不变就等于退化。

Wind-MTP 的价值在于把修复做到了极致轻：零训练、无新 kernel、严格无损、一行配置级别的改动，还顺手用 ring buffer 把草稿 KV 的显存也吐出来了。我预期这类”草稿侧窗口化/稀疏化“会迅速变成长上下文推理栈的默认配置——就像 target 侧的窗口化和稀疏化已经在发生的那样。

如果这篇文章涉及的投机解码、长上下文推理优化你想系统深入，可以看看我之前出版的《动手学AutoML：从 NAS 到大语言模型优化实战》，书里有专门一章讲 LLM 推理效率与 KV Cache 优化，本文讨论的 decode 阶段 memory-bound 问题正是那一章的主线。

动手学AutoML书籍封面

Flag Counter