帝国理工陆永青院士团队提出MoE推测解码新范式，专家卸载吞吐达到2.06倍！

智猩猩AI整理

编辑：BugMaker

MoE 模型已经把每个 token 的计算压到了少数几个专家上，但到了推测解码，另一个问题冒了出来。

一次验证的不只是一个 token，而是一棵 draft tree。树上不同节点可能走向不同专家，最后真正进入输出的只是少数节点，整棵 draft tree 却可能把更多专家卷进这次验证，带来额外的专家计算和权重访问。

8月4日，Imperial College London 联合 TileLang 背后的 AI Infra 团队 Tile-AI 提出AcceptMoE。英国皇家工程院院士、IEEE Fellow陆永青（Wayne Luk）参与其中，直接优化目标模型验证阶段的专家选择，让每轮验证自动决定哪些 MoE 专家值得参与。

它不要求用户提前指定固定的 expert budget，也不依赖额外的专家预测器。实验覆盖Qwen3-30B-A3B-Instruct-2507、Qwen3-Coder-30B-A3B-Instruct 和 GPT-OSS-120B。

在 SGLang 中，全部专家权重位于 GPU 时，AcceptMoE 吞吐量达到 Standard SD 的1.290 倍。采用物理专家卸载后，吞吐达到 Standard SD 的2.06 倍，同时将 Host-to-Device 数据传输量降低73.6%—77.1%。

代价并不大。12 个模型–任务组合上的平均准确率，仅比使用原生路由的 Standard SD低 0.27 个百分点。

01

少验证一些token，为什么

专家还是搬了一大堆

推测解码（Speculative Decoding）通常先让 draft model 一次提出多个候选 token，再交给目标模型并行验证。

放到混合专家模型（Mixture-of-Experts，MoE）上，每个 token 虽然只会选择 top-k 专家，但不同 draft node 选择的专家并不相同。

在原生路由下，一棵 draft tree 验证下来，真正需要访问的是所有节点所选专家的并集，也就是激活专家并集（activated-expert union）。

问题也出在这里。

很多 draft branch 最后都会被丢掉，可它们对应的专家权重已经产生了计算和访存开销。

论文引用的结果很直观。在 Qwen3-30B-A3B 上，EVICT 相比 EAGLE-3 将验证 token 数减少74.7%，激活专家数量却只减少32.5%。

少验证 token，并不意味着专家数量会同步减少。

已有的 verifier-side 方法 MoE-Spec 需要提前指定专家预算 B，并在每层固定保留排名最高的 B 个专家。，而且在汇总 Router 概率时，对 draft tree 中不同位置一视同仁。

但越深的节点，本来就越不容易真正进入最终输出。

AcceptMoE 要解决的，就是哪些专家值得留，以及到底应该留多少个。

02

不再固定专家数量，

AcceptMoE自己决定留谁

AcceptMoE 首先引入commitment probability，即某个草稿节点最终真正进入被接受输出前缀的概率。

这里不能简单理解成“token 接受率”。它表示某个 draft position 上的节点，最终真正进入 accepted output prefix 的概率。

团队提前从训练集验证轨迹中估计这个概率，再用它给 target Router 的分数加权。

直观来看，越可能真正进入输出的节点，它需要的专家就越重要。那些位于深层、最后大概率被丢弃的节点，对专家选择的影响会被压低。

接着，AcceptMoE 会保留一个root anchor，也就是 draft tree 根节点原本选择的 top-k 专家。根节点一定会进入输出，因此这部分专家优先保留。

剩下留多少专家，不再手动给一个 B。

AcceptMoE 根据专家需求分布的有效秩（effective rank）自动确定集合大小。需求集中时少留一些，需求分散时多留一些。

在 12 个模型–任务组合中，最终自动选择的平均专家集合规模约为23—34 个。

进入专家卸载场景后，问题又变了一层。

一个专家如果已经在 GPU 中，直接运行即可。没有驻留的专家，则需要从 CPU 内存加载。

AcceptMoE 因此加入Residency-Aware Pruning。它优先检查低需求的非驻留专家，在 rerouting budget 和最小集合规模允许的范围内继续裁剪。

不是预测下一步要加载谁，而是直接根据现在 GPU 里有什么，改变哪些专家还能被选择。

整个过程不需要额外 learned expert predictor，也不需要预设 expert budget。

03

全驻留1.29倍，专家卸载

直接做到2.06倍

实验统一采用 EAGLE-3 draft tree，设置5 个 draft steps、EAGLE top-k=10、64 个 draft tokens，测试 GSM8K、MATH500、HumanEval 和 MBPP。

全驻留实验运行在一张RTX PRO 6000 Blackwell上，batch size=1，并使用SGLang 0.5.12.post1。

AcceptMoE 在全部 12 个模型–任务组合中都超过 Standard SD，平均吞吐提升到1.290 倍，单项范围为1.217—1.339 倍，最高达到257 tokens/s。

更关键的是，AcceptMoE 和 Standard SD 的平均 accepted length 都约为4.39 个 token。

这部分加速并不是因为一次接受了更多 token，而是因为每次验证实际涉及的专家更少。

到了真正需要搬运专家权重的场景，差距进一步拉开。

在一张RTX 5090上，每层配置 48 个 expert slots。Standard SD 有65%—78%的运行时间花在等待专家权重加载上，AcceptMoE 将这一比例降到27%—35%。

最终，AcceptMoE 相比 Standard SD 的平均吞吐达到2.06 倍。

背后的数据传输变化更明显。

AcceptMoE 将三种目标模型的 H2D 专家权重传输量分别降低73.6%、77.1% 和 76.0%，专家缓存命中率则提高10.8、12.6 和 14.2 个百分点。

04

自动选专家，离最优固定

配置有多远

AcceptMoE 并不是简单地“少留几个专家”。

在相同 expert budget 下，使用 Commitment-Weighted Demand 的AcceptMoE-B 平均准确率达到 90.60%，MoE-Spec 为88.15%，前者高出2.45 个百分点。

也就是说，即使专家数量完全相同，挑哪些专家仍然很重要。

至于 Self-Sizing 能不能代替逐个任务调参，论文专门扫描了 5 个模型–任务组合。

AcceptMoE 自动选择出的点，与每个任务实测出的最佳固定预算相比，平均只低0.97 个百分点，最差差距为1.83 个百分点。

在论文扫描的最小固定预算点，准确率相较各自最佳实测配置最多下降 92.1 个百分点。一个模型上合适的 B，换到另一个模型也未必合适。

Residency-Aware Pruning 单独开启后，又能将专家权重传输量降低38.6%—48.6%，缓存命中率提高6.9—8.2 个百分点，吞吐量提高4.6%—15.1%。

对应的平均准确率变化只有−0.27 个百分点。

AcceptMoE 的思路其实很明确。

MoE 推测解码不能只盯着“验证了多少 token”，还要继续追问一句，这些 token 到底把多少专家卷进了这次验证，又有多少专家真的值得从 CPU 搬进 GPU。

关注+星标，获取AI前沿进展与优质开源项目