arXiv'26 | EcoSpec：MoE 投机解码别只顾接受率，草稿会把专家撒得到处都是

August 16, 2026

2026   ·   LLM   MoE   投机解码   推理优化   论文解读  

arXiv’26 | EcoSpec：MoE 投机解码别只顾接受率，草稿会把专家撒得到处都是

原文：Less Experts, Faster Decoding: Cost-Aware Speculative Decoding for Mixture-of-Experts

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

你有没有想过这样一个问题：在 MoE 模型上做投机解码，”验收”到底要付多少钱？

标准叙事里这笔账很好算：target 模型并行验收 γ 个草稿 token 是一次 prefill 式的 forward，多算几个 token 的边际成本很低——所以只要草稿接受率 $\tau$ 够高，就稳赚。DSpark 那篇讲的就是怎么用置信度调度把每轮验收的预算花在刀刃上。

但这个”边际成本很低”的前提，在 MoE 上悄悄变质了。MoE 的验收成本不由 token 数决定，而由这批 token 激活的专家并集决定。论文给了一个很扎心的量化：EAGLE-3 在 Qwen3-235B 上，每个验收步平均要激活 23.7 个专家/层——而普通 AR 解码 top-8 路由只需要 8 个；DeepSeek-V3.1 配 MTP 更夸张，31.4 个。一个 DeepSeek 专家（FP8）就是 44MB 的 HBM 流量，草稿 token 每多”撒”出一个新专家，就是 44MB 的搬运费。

论文管这个现象叫 expert scattering（专家散射）：按”接受概率最高”选出来的草稿 token，各自路由到互不相交的专家上——草稿在概率空间里抱团，在专家空间里却四散开花。

今天这篇 EcoSpec（arXiv 2607.12696）做的事一句话讲完：选草稿的时候，把”会激活哪些专家”算进成本函数——在不改变验收规则（严格无损）的前提下，DeepSeek-V3.1（671B）、Qwen3-235B、GPT-OSS-120B 上端到端最高 1.62× 加速。

这条问题和我在 ST-MoE expert-prefetch 里聊过的洞察是一体两面：expert 激活不是随机的，有很强的可预测性——那篇用它来做”提前把专家搬上片”的预取，这篇用它来做”选草稿时避开冷门专家”的调度。而”MoE 推理被内存带宽卡死”这个大背景，我在 SMoE 那篇里也铺垫过：expert 权重搬不动，才是整个端侧/免裁剪 MoE 部署的核心矛盾。

2. 病根：验收成本 = 专家并集，而不是 token 数

先把账算细。投机解码每轮：

  1. drafter 打出 γ 个草稿 token（组成树或链）；
  2. target 并行验收：这 γ+1 个 token 一起过 MoE 层。

第 2 步里每个 token 各自路由到 top-k 个专家。需要加载的专家是这些集合的并集。γ 个 token 如果路由高度重叠（比如都走同样 8 个专家），验收只比单 token 多一点 FLOPs；如果互不相交，验收的专家加载量直接 ×γ。

而”按接受概率选草稿”的策略天然往第二种情况跑偏：概率高的草稿 token 分布在语义空间的不同区域，路由自然分散。论文的统计：Qwen3-235B 上 EAGLE-3 平均 23.7 专家/层 ≈ top-8 的 3 倍带宽需求；更糟的是 batch 稍大就撞带宽墙——batch=4 时 EAGLE-3 的加速直接掉到 1.00×（不赚不赔），专家足迹膨胀到 54.9 个/层。

MoE 投机解码的带宽瓶颈

3. 方法：把专家成本写进草稿选择

EcoSpec 在 drafter 和验收之间插了三个组件，验收规则本身一个字不动（所以输出分布与 target 严格一致，无损）：

（1）轻量 Expert Predictor。一个小 decoder LM（Qwen3-0.6B / DeepSeek-R1-Distill-Qwen-1.5B），离线用真实 router 轨迹训练（逐层交叉熵），推理时对每个草稿 token 输出各层的路由预测 logits，取 Top-K 得到预测专家集。预测准确率：GPT-OSS-120B 93%、Qwen3-235B 82%、DeepSeek-V3.1 80%。每步开销约 4ms。

（2）全局 Expert Buffer。维护”已被已选草稿覆盖的专家集合”——只有新引入的专家才算成本。这是边际成本的关键：第一个走某专家的 token 付全款，后面的搭便车。

（3）Cost-Aware Draft Selection。候选草稿按下面这个分数贪心选择：

\[S(t) = \frac{P(t)}{\Delta \text{Cost}(t \mid \mathcal{B}) + \epsilon}\]

$P(t)$ 是根到该节点路径的累积草稿概率（接受率的代理），$\Delta\text{Cost}$ 是该路径专家足迹相对 buffer 的增量。每选一个 token 就更新 $\mathcal{B}$。这个分数天然前缀一致（子节点不会因为同样 buffer 下的成本反超父节点），贪心选择没有结构上的坑。

EcoSpec 框架

4. 效果

4.1 主结果（8×H200，γ=4，贪心 T=0，7 个 benchmark）

模型 baseline EcoSpec 专家/层
Qwen3-235B-A22B EAGLE-3 1.22× 1.36×（MTBench 最高 1.62×） 23.7→20.5
GPT-OSS-120B EAGLE-3 1.14× 1.31×（MMStar/AMC 最高 1.45×） 11.6→10.6
DeepSeek-V3.1 MTP 1.10× 1.15× 31.4→31.2

主结果表

关键佐证——接受长度几乎没掉（Qwen3 贪心 2.41→2.32）：提速全部来自”验收变便宜”，而不是”草稿变准”。这和纯提 τ 的路线（EAGLE 系列）是正交的另一条轴。

4.2 HBM 流量与延迟拆解（Qwen3，T=0）

  • 验收延迟 0.832s→0.730s，整步 0.840s→0.742s；
  • HBM 读取 99.3GB→88.1GB（−11.2GB，−11.3%）；
  • 三个模型里 Qwen3 省得最多——它的专家使用模式集中，重叠空间大；DeepSeek 的均衡路由最难省（−1.0%），但它的单专家最大（44MB），每层每步只要省 0.2 个专家，一轮投机解码就省约 0.5GB 流量。

4.3 消融与鲁棒性

  • 边际成本 vs 静态全局成本：buffer 增量式的打分明显更好（Qwen3 GSM8K 1.28×→1.39×）——”谁先来谁付全款”的建模是必要的；
  • 预测器鲁棒性：预测准确率掉到 50% 时 Qwen3 加速从 1.39× 退到 1.17×；而 oracle 专家集的结果（20.4）和收敛预测器（20.5）几乎一样——82–93% 的准确率已经够用，不是瓶颈；
  • batch 扩展：batch=4 时 EAGLE-3 归零（1.00×），EcoSpec 还能保住 1.09×（专家足迹 45.7 vs 54.9）——成本感知在带宽更紧张的并发场景下更值钱；
  • γ 扫描：γ=4 是甜点，γ 再大验收的专家并集膨胀，收益反而缩水。

5. 我的 Take

这篇论文最值得咀嚼的是它换掉的那把尺子：投机解码的收益函数，从”接受了几个 token”换成了”每 GB 带宽换几个 token”。在 dense 模型上这两者是单调对应的，在 MoE 上不是——中间隔着一个路由并集。

DSpark 用置信度决定”验收多长”，EcoSpec 用专家成本决定”选哪条草稿”——两者其实可以叠（一个管 verify 预算，一个管 draft 选择，公式里一个压分子一个提分母）。往前看，随着 MoE 成为旗舰标配、投机解码成为默认配置，“草稿的专家足迹”会变成推理栈里一个需要显式管理的量，就像 KV Cache 的显存一样。预测路由这个组件（80–93% 准确率、4ms 开销）以后大概会在各种系统论文里反复出场。

如果这篇文章涉及的 MoE 推理、投机解码优化你想系统深入，可以看看我之前出版的《动手学AutoML：从 NAS 到大语言模型优化实战》，书里大模型优化章节讲的稀疏化与效率权衡，和本文”专家足迹管理”是同一套设计思路。

动手学AutoML书籍封面

Flag Counter