MoE 与推测解码（Speculative Decoding）加速：为什么慢、什么时候慢、怎么让它不慢？

学术交流群：922230617

[0. 引言](#0. 引言)

[0.1 基础](#0.1 基础)

[0.1.1 算法机制](#0.1.1 算法机制)

[0.1.2 工程实现](#0.1.2 工程实现)

[0.1.3 模型架构](#0.1.3 模型架构)

[0.1.4 局限性与边界条件](#0.1.4 局限性与边界条件)

[0.2 MoE + SD 的核心问题：会变慢](#0.2 MoE + SD 的核心问题：会变慢)

[1. 为什么慢？](#1. 为什么慢？)

[1.1 核心机制：验证时的专家并集膨胀](#1.1 核心机制：验证时的专家并集膨胀)

[1.2 实验证据：验证开销 2x～3x，最坏 slowdown 1.5x](#1.2 实验证据：验证开销 2x～3x，最坏 slowdown 1.5x)

[1.3 为什么这是 MoE 特有的问题](#1.3 为什么这是 MoE 特有的问题)

[2. 什么时候慢？](#2. 什么时候慢？)

[2.1 任务、请求、迭代位置不同：Cascade](#2.1 任务、请求、迭代位置不同：Cascade)

[2.2 Batch size 与稀疏度：MoESD](#2.2 Batch size 与稀疏度：MoESD)

[2.3 Offloading 与 cache 未命中：AcceptMoE](#2.3 Offloading 与 cache 未命中：AcceptMoE)

[2.4 树状 draft 与长尾专家：MoE-Spec](#2.4 树状 draft 与长尾专家：MoE-Spec)

[2.5 什么时候反而有机会](#2.5 什么时候反而有机会)

[3. 怎么让它不慢](#3. 怎么让它不慢)

[3.1 训练时治本：Apple Coactivation](#3.1 训练时治本：Apple Coactivation)

[3.2 运行时调度：Cascade](#3.2 运行时调度：Cascade)

[3.3 Draft 选择降本：EcoSpec](#3.3 Draft 选择降本：EcoSpec)

[3.4 验证时降本：MoE-Spec 与 AcceptMoE](#3.4 验证时降本：MoE-Spec 与 AcceptMoE)

[3.4.1 MoE-Spec：固定 expert budget](#3.4.1 MoE-Spec：固定 expert budget)

[3.4.2 AcceptMoE：自 sizing + 缓存感知](#3.4.2 AcceptMoE：自 sizing + 缓存感知)

[3.4.3 本节小结](#3.4.3 本节小结)

[3.5 理论指导：MoESD Target Efficiency](#3.5 理论指导：MoESD Target Efficiency)

[3.5.1 数学推导：多大 Batch Size 能激活所有专家？](#3.5.1 数学推导：多大 Batch Size 能激活所有专家？)

[3.5.2 关键创新：Target Efficiency](#3.5.2 关键创新：Target Efficiency)

[3.5.3 性能建模：让加速过程白盒化](#3.5.3 性能建模：让加速过程白盒化)

[3.5.4 实验结果](#3.5.4 实验结果)

[4. 横向对比与工程实践](#4. 横向对比与工程实践)

[4.1 六篇论文横向对比以及总结](#4.1 六篇论文横向对比以及总结)

[4.2 工程落地建议](#4.2 工程落地建议)

参考文献

[Efficient Mixture-of-Experts with Speculative Decoding via Expert Coactivation](#Efficient Mixture-of-Experts with Speculative Decoding via Expert Coactivation)

[Utility-Driven Speculative Decoding for Mixture-of-Experts](#Utility-Driven Speculative Decoding for Mixture-of-Experts)

[Less Experts, Faster Decoding: Cost-Aware Speculative Decoding for Mixture-of-Experts](#Less Experts, Faster Decoding: Cost-Aware Speculative Decoding for Mixture-of-Experts)

[MoE-Spec: Expert Budgeting for Efficient Speculative Decoding](#MoE-Spec: Expert Budgeting for Efficient Speculative Decoding)

[AcceptMoE: Commitment-Weighted Self-Sizing Verifier Expert Sets for Efficient MoE Speculative Decoding](#AcceptMoE: Commitment-Weighted Self-Sizing Verifier Expert Sets for Efficient MoE Speculative Decoding)

[MoESD: Unveil Speculative Decoding's Potential for Accelerating Sparse MoE](#MoESD: Unveil Speculative Decoding's Potential for Accelerating Sparse MoE)

0. 引言

0.1 基础

SD 基础（包含原理图）可参考：

（2026|NAVER AI，推测解码/SD，置信门控，Loop-aware Training，用更多 draft 前向换更少 target 前向）DLoop：循环推测解码

本小节为补充信息。

MoE + SD 的原理图如下：

图中的结合方式是目前为了追求极致效率的一种 "强强联合"：

用 Dense 模型作为 draft 小模型快速猜；用 MoE 模型作为 target 大模型高效查。
由于 MoE 的稀疏激活特性（每次只激活部分专家），使得大模型在 "一次性并行验证" 时，计算量远小于同等参数量的稠密大模型（Dense Model），两者结合能最大化效率。

0.1.1 算法机制

拒绝后的 "纠正" 机制：

在标准 SD 算法中，如果某个 token（如 t_k）被拒绝，大模型（Target Model）会直接在该位置生成一个正确的 token 作为纠正，然后小模型再从这之后继续 "猜"。
大模型不仅负责 "评判"，还负责 "改错"。

Bonus Token（奖励 Token）：

如果小模型猜的 k 个 token 全部被接受，大模型通常会额外生成一个 token（Bonus Token）作为奖励。
这意味着一次前向传播可以生成 k+1 个 token，这是 SD 加速的核心来源之一。

0.1.2 工程实现

**KV Cache 的回滚（Rollback）：**这是 SD 工程落地最大的难点。

当 token 被拒绝时，大模型和小模型的 KV Cache 必须回滚到最后一个被接受的 token 的位置。
如果不能高效地操作 KV Cache，SD 的加速效果会被抵消。

词表（Tokenizer）对齐：

小模型（Draft）和大模型（Target）必须使用完全相同的 Tokenizer 和词表。
如果词表不同，小模型生成的 token 无法直接送入大模型验证概率，这套体系就无法运转。

超参数 k 的选择：

图中使用 k 个候选 token，其中，k 是一个需要精心调节的超参数。
k 太小，加速不明显；k 太大，小模型自回归生成耗时增加，且后面 token 被拒绝的概率会呈指数级上升，反而浪费算力。

0.1.3 模型架构

自回归（Autoregressive）与并行（Parallel）的对比：

图中步骤 1 的小模型生成 t_1...t_k，实际上是一个自回归的串行过程 （一个一个猜）；而步骤 2 的大模型验证，是一次性并行处理这 k 个 token 的。
这是速度提升的核心对比。

MoE 验证时的专家路由：

在验证 k 个 token 时，Router 是为每一个 token 独立选择专家的。
这意味着，同一个序列里的不同 token，可能被路由到完全不同的专家组合中。

0.1.4 局限性与边界条件

适用场景限制：

SD 在**内存带宽受限（Memory-bound）**的场景下加速效果最好（如单用户本地推理）。
在高度并行、计算受限（Compute-bound）的服务器批量推理场景下，SD 反而可能增加计算负担，降低吞吐量。

分布差异问题：如果小模型和大模型的分布差异过大（比如小模型太笨），导致拒绝率极高，那么 SD 不仅不能加速，反而会因为反复验证而变慢。

0.2 MoE + SD 的核心问题：会变慢

Speculative Decoding（SD，推测解码）在 Dense 模型上成立的关键假设是：

验证多个 token 和验证一个 token 的耗时差不多。

因为 Dense 模型每层都要加载全部权重，多验证几个 token 只是多一点计算，内存带宽瓶颈不变。所以 SD 能带来 1.4x～1.8x 加速。

但 MoE 打破了这一点。

MoE 每层有 N 个专家，每个 token 只选 top-k 个专家。单个 token 只加载 k 个专家权重。但 SD 验证时，一个窗口里有多个 token，不同 token 可能选择不同专家，target 模型必须加载它们的专家并集：

窗口越大，专家并集越接近全部专家 N，DRAM / HBM → GPU / NPU 的专家权重传输量暴涨。

结果：验证时间从 "几乎不变" 变成 "随专家数线性增长"，SD 的 ETR 收益被吃掉，甚至出现 slowdown。

多篇论文都观测到：MoE 下 SD 验证开销可达 2x～3x ，最坏 slowdown 到 1.5x。

【ETR：Effective Token Rate，有效 token 速率。

在推测解码（Speculative Decoding）中，目标模型一次前向验证可以接受多个 draft token，并额外生成一个 bonus token。因此，一次迭代实际输出的 token 数可能大于 1。

ETR 就是平均每次目标模型前向所生成的 token 数量。

举个例子：

如果一次验证接受了 3 个 draft token，加上 1 个 bonus token，这次迭代产出 4 个 token；
如果另一次只接受了 1 个，产出 2 个 token；
平均下来，ETR 可能是 2.5 或 3。

它和 接受率（acceptance rate） 不同：

接受率是单个 draft token 被接受的概率；
ETR 是实际产出速率，衡量 "每个验证步骤平均能产出多少 token"。

ETR 越高，说明推测解码越有效。

吞吐量可以近似为：

在 Cascade 中，utility 定义为：

其中 ETR 是收益项，cost 是推测迭代时间相对无推测基线的比值。所以 utility < 1 时，推测反而变慢。

】

所以，MoE + SD 的核心问题可以拆成三问：

为什么慢？

验证时专家并集膨胀，专家权重传输量随窗口大小增长，内存带宽成为瓶颈。

什么时候慢？

任务、batch size、稀疏度、offloading、树状 draft 都会影响。
小 batch、offloading、大树 draft 容易慢；中等 batch、高稀疏、private serving 反而有机会。

怎么让它不慢？

训练时、运行时、Draft 选择、验证时，各有解法。
本文选取的六篇论文正好覆盖了这条优化链上的不同阶段。

下面按这三问展开，六篇论文各归其位。

此处做一个缩写表格方便查阅，各论文信息见论文最后的参考文献一节。

缩写	论文名
Apple Coactivation	Efficient Mixture-of-Experts with Speculative Decoding via Expert Coactivation
Cascade	Utility-Driven Speculative Decoding for Mixture-of-Experts
MoESD	MoESD: Unveil Speculative Decoding's Potential for Accelerating Sparse MoE
MoE-Spec	MoE-Spec: Expert Budgeting for Efficient Speculative Decoding
EcoSpec	Less Experts, Faster Decoding: Cost-Aware Speculative Decoding for Mixture-of-Experts
AcceptMoE	AcceptMoE: Commitment-Weighted Self-Sizing Verifier Expert Sets for Efficient MoE Speculative Decoding

1. 为什么慢？

1.1 核心机制：验证时的专家并集膨胀

Dense 模型中，SD 验证 γ 个 token 和验证 1 个 token，每层都要加载全部权重，耗时几乎一样。

所以 SD 能 "免费" 验证多个 token，提高 ETR。

MoE 中，每个 token 只激活 top-k 专家。单个 token 只加载 k 个专家权重。

但 SD 验证时，一个窗口里有 γ+1 个 token，每个 token 独立路由，target 必须加载它们的并集：

当窗口变大，专家并集可能迅速接近全部专家 N。

这意味着：

需要从 DRAM/HBM 传输到 GPU/NPU 的专家权重数量增加；
验证时间不再固定，而是随专家并集大小线性增长；
SD 的 ETR 收益可能抵不过验证开销，甚至出现 slowdown。

换句话说，SD 在 Dense 上 "验证几乎免费" 的假设，在 MoE 上变成了 "验证成本取决于专家并集有多大"。

1.2 实验证据：验证开销 2x～3x，最坏 slowdown 1.5x

Cascade：在 Mixtral 8x7B 上，单个 token 激活 2/8 专家；3 个 draft token 可能激活最多 6 个专家，数据移动增加 3x；

验证开销：math 任务 3x，code 任务 2.3x，extraction 任务 2.6x（Figure 4，K=7）；
在 35 个 model-task 组合中，18 个出现 slowdown，最坏 1.5x（Figure 5）。

MoE-Spec：

OLMoE-1B-7B 上，127-token draft tree 平均激活 54/64 专家，接近全模型；
EAGLE-3 在 tree size 31 时速度达到峰值 1.95x，之后下降，因为长尾专家拖垮验证成本（Figure 4b）。

EcoSpec：

DeepSeek-V3.1（FP8）单个专家占用 44.04 MB HBM（Figure 1c）；
每层每步减少 0.2 个专家，就能减少约 0.5 GB 专家权重流量（Table 2）；
标准 SD 选择高置信度 draft token 时，可能路由到不相交专家，造成 expert scattering（Figure 1b）。

这些数据说明：MoE 下 SD 的验证开销不是固定的，而是随着 draft 窗口、树大小、专家并集大小动态变化。当并集接近全专家时，SD 的加速收益会被完全吃掉。

1.3 为什么这是 MoE 特有的问题

Dense 模型：所有 token 共享同一套 FFN 权重，验证多 token 不增加权重加载量。

MoE 模型：每个 token 选择不同专家，验证多 token 增加专家并集，权重加载量随并集大小增长。

所以，SD 在 Dense 上 "验证几乎免费" 的假设，在 MoE 上不成立。

这就是 MoE + SD 变慢的根本原因。

结论：MoE + SD 慢，不是因为 token 多，而是因为验证时专家并集膨胀，导致专家权重传输量随窗口大小增长，内存带宽成为瓶颈。

2. 什么时候慢？

不是所有 MoE + SD 都慢。

任务、batch size、稀疏度、offloading、树状 draft 都会影响。

这一节回答：什么时候慢、什么时候不慢、什么时候反而有机会。

2.1 任务、请求、迭代位置不同：Cascade

Cascade 发现，MoE 下 SD 是否加速，取决于任务、请求、甚至同一个请求的不同迭代阶段。

有的任务（如 code）SD 加速明显；有的任务（如 math）SD 在所有推测长度（Draft Token 数量）K 下都 slowdown（Figure 4）；
即使同一个任务，不同请求的 utility（= ETR / cost）也差异显著：有的请求全程 utility 低于 1，有的请求后期 utility 明显升高，黑色虚线是跨请求的调和平均 utility（Figure 7）。
同一个请求，不同迭代阶段 utility也会变化：有时高，有时低（Figure 6）；utility < 1 时，speculation 反而变慢。

【推测长度（Draft Token 数量）K，指的是推测 K 个 token 之后再验证。相关论文：

（2026|NAVER AI，推测解码/SD，置信门控，Loop-aware Training，用更多 draft 前向换更少 target 前向）DLoop：循环推测解码

】

原因：

1）任务维度：

差异源于 expert affinity，也就是说，不同任务的自然语言特性导致 相邻 token 重用专家的程度不同，从而验证 cost 不同。

2）请求维度：

差异只是作为观测（Figure 7），论文更多是把请求间差异作为需要在线决策的动机，而不是作为一个可解释的现象来拆解。
论文表述为："the solution must adapt to heterogeneous request streams and generalize across speculation techniques, MoE architectures, and hardware platforms."

3）迭代位置维度：

随着生成进行，draft 模型获得更多上下文，draft 质量可能提高，ETR 上升（draft 结果更多被接受，产生更多的 bonus token），utility 随之变化。
Figure 6 中的请求在第 10 个窗口之后 ETR 增益才超过成本，就是这个机制的例子。
但论文也承认这种变化有相位偏移（phase shifts，跳变），只是短期内有 temporal locality（跳变间的局部平滑），所以可以用近期 utility 预测未来。

结论：固定 K 不可靠，必须运行时动态判断。任务、请求、迭代位置三个维度都会影响 utility，这也是 Cascade 采用 iteration-level 在线决策的原因。

2.2 Batch size 与稀疏度：MoESD

MoESD 从理论和系统角度指出：MoE + SD 并非永远差，中等 batch size 下反而可能比 Dense 更受益。

原因：

小 batch：只激活少量专家，验证多 token 会加载更多专家，SD 不划算；
中等 batch：所有专家几乎都已被激活，验证多 token 不再额外加载专家，SD 反而有效；
大 batch：系统进入 compute-bound，SD 收益下降。

论文给出激活专家数的期望（t 个 token，每个token激活 K 个专家）：

并提出 target efficiency：

它表示单 token 前向时间与多 token 前向时间的比值，衡量 target 模型验证多 token 时相对单 token 的效率（Figure 3）。

实验结果：

Qwen2-57B-A14B 在中等 batch 下最高 2.29x speedup（Table 2）；
不同硬件平台上趋势一致（Table 2）；
越稀疏的 MoE，SD 有效的 batch 范围越宽（Figure 4）；
MoE 的 target efficiency 先升后降，而 Dense 持续下降，说明 MoE 在更大 batch 范围有潜力（Figure 3）。

结论：MoE + SD 不是永远差，关键看 batch size 和稀疏度。中等 batch 可能是 "效率缺口"，也是机会。

2.3 Offloading 与 cache 未命中：AcceptMoE

专家 offloading 时，传输成本不只看专家集大小，还看专家是否在 cache 中。

驻留专家：已经在 GPU 的 expert pool 里。token 要用它，直接算，无需 Host-to-device（H2D）传输；
非驻留专家：不在 pool 里。token 要用它，必须先从 host 内存加载到 GPU，触发 H2D 传输。触发权重加载，可能驱逐缓存专家；

GPU 的 expert pool 容量有限。新专家要进来，旧专家就得出去。AcceptMoE 用的是 LRU（Least Recently Used）：

最近最少使用的专家被踢出 pool；
刚用过、频繁用的专家尽量留在 pool 里。

这意味着：加载一个新专家，可能顺带把另一个专家挤出去。如果被挤出去的专家后面又要用，还得再传回来。所以 offloading 下的传输成本是动态的，和访问顺序、cache 命中率强相关。

如果验证 block 的专家并集超过 cache 容量，会分成多个 wave，每个 wave 都要等待专家加载。

所以 专家并集越大、cache 命中越差，wave 越多，验证越慢。
这也是为什么 Standard SD 在 offloading 下可能比 AR 还慢：AR 每步只处理一个 token，专家并集小；SD 一次验证很多 token，专家并集大，wave 多，H2D 传输把收益全吃掉了。

【举个例子，比如 GPU expert pool 的容量为 48，但某个 block 的专家并集有 70 个。GPU 一次放不下 70 个专家，怎么办？

分 wave：

第一波：选一批 token，它们的专家并集能塞进 48 个 slot，算完；
第二波：剩下的 token，再加载它们的专家，算完；
如果还不够，继续分第三波、第四波......

每个 wave 都要等专家从 host 内存加载到 GPU。wave 越多，等待时间越长。

】

AcceptMoE 实测：

Standard SD 在 offloading 下，65%～78% 的 wall time 花在等待专家权重（Figure 5a）；
在 8 个 Qwen 组合中，Standard SD 有 7 个比 Vanilla AR 还慢（Figure 4）；
AcceptMoE 通过 residency-aware pruning，把 fetch-stall 降到 27%～35%（Figure 5a）；H2D 流量降低 73.6%～77.1%，cache hit rate 提升 10.8～14.2 个百分点（Table 2）。

结论：offloading 场景下，SD 可能比 AR 还慢，必须把 cache 状态纳入决策。

2.4 树状 draft 与长尾专家：MoE-Spec

EAGLE-3 这类树状 SD 会验证 60+ draft tokens。

树越大，专家并集越接近全专家，但专家激活是长拖尾的（heavy-tailed）：

OLMoE 中 top 32/64 专家捕获 93% 路由概率（Figure 2c）；
尾部专家带宽成本高但贡献小：少数专家被很多 token 选中，贡献了大部分路由概率；而大量尾部专家只被极少数 token 选中，却仍然需要把完整的专家权重从 HBM 加载到 GPU。

注意，长尾专家是 MoE 路由的固有属性；在 SD 验证中，它会被 "一次验证多个 token" 放大：

树状 SD（60+ token）会把专家并集推到接近全专家，尾部专家被大量顺带激活，带宽成本显著；
链式 SD（K ≤ 3）一次验证 2～4 个 token，专家激活相对 moderate，但 expert scattering 仍存在（EcoSpec：, Figure 1b），只是程度较轻。

MoE-Spec 实测：

EAGLE-3 在 tree size 31 时速度达到峰值，之后下降，因为长尾专家拖垮验证成本（Figure 4b）。
EAGLE-3 在 tree size 255 时加载 54 个专家，速度降到 1.85x（Figure 4c）；
MoE-Spec 限制 B=32，速度继续提升到 2.1x（Figure 4b）；
不同任务路由集中度不同：代码任务 top 8 专家覆盖 90%+ 概率，摘要任务需要 24 个专家才到 90%（Figure 7）。

结论：树状 draft 越大，长尾专家越多，验证成本越高。必须限制专家预算。

2.5 什么时候反而有机会

综合四个视角，MoE + SD 什么时候慢、什么时候有机会，可以归纳为四条：

**固定 K 不可靠，必须运行时动态判断。**任务、请求、迭代位置三个维度都会影响 utility（Cascade，Figure 6/7），所以需要 iteration-level 在线决策，而不是 per-task 静态 K。
**MoE + SD 不是永远差，关键看 batch size 和稀疏度。**小 batch 下验证多 token 会额外加载专家，SD 不划算；中等 batch 下所有专家已激活，验证多 token 不再额外加载专家，MoE 反而可能比 Dense 更受益（MoESD，Figure 2/4）。越稀疏的 MoE，这个有效 batch 范围越宽。
**Offloading 场景下，SD 可能比 AR 还慢，必须把 cache 状态纳入决策。**传输成本不只看专家集大小，还看专家是否驻留；非驻留专家触发 H2D 加载，并可能 LRU 驱逐缓存专家；专家并集超过 pool 容量还会分 wave（AcceptMoE，Figure 4/5a，Table 2）。
**树状 draft 越大，被激活的尾部专家越多，验证成本越高。**尾部专家贡献小但每个都要完整加载权重，带宽成本被放大，必须限制专家预算（MoE-Spec，Figure 2c/4b）。

**结论：**MoE + SD 不是永远慢。任务/请求/迭代位置影响 utility，batch size 与稀疏度决定是否有机会，offloading 下 cache 状态可能让 SD 比 AR 还慢，树状 draft 越大越需要限制专家预算。四篇论文分别从运行时调度、batch 理论、offloading、树状验证四个角度，刻画了 MoE + SD 的适用边界。

3. 怎么让它不慢

上一节刻画了 MoE + SD 的适用边界。这一节回答：怎么优化？

按优化发生阶段分类：

训练时治本：Apple Coactivation
运行时调度：Cascade
Draft 选择降本：EcoSpec：
验证时降本：MoE-Spec 与 AcceptMoE
理论指导：MoESD Target Efficiency

3.1 训练时治本：Apple Coactivation

核心问题：SD 验证窗口越大，MoE 激活专家越多，DRAM→NPU 传输成为瓶颈（Figure 1a）。

核心思路 ：不改 SD 算法，也不改部署，而是改 MoE 的训练方式 ，让相邻 token 倾向于选择重叠专家，即提高 expert coactivation。

论文提出四个训练改动：

**1）全局负载均衡（Global load-balancing loss）：**把局部负载均衡换成全局负载均衡，避免 micro-batch 内强制所有专家都被选中，保护专家特化。

负载均衡损失表示为：

其中，N 是专家的数量，f(i, τ) 表示在序列 τ 中选择专家 i 的 token 所占的比例，p 是序列 τ 中被路由到专家 i 的所有 token 的总路由概率。

【这个公式的核心设计逻辑是：频率 × 概率。

如果一个专家被过度使用（频率 f 很高），同时模型给它的路由概率也很高（概率 p 很高），那么它们的乘积 f⋅p 就会很大。这个乘积会被累加到损失函数中。
为了最小化损失，模型会被迫降低这种 "既高频又高概率" 的专家权重，从而把流量分流给其他专家。

】

在训练集群中，多个节点上的进程并行计算梯度更新，每个进程将全局 batch B 划分为若干 micro-batches τ。因此，整个 batch 的损失为：

这种局部损失的一个缺点是，它会促使路由器在每个 micro-batches 中选择所有专家，即使该微batch的数据来自同一领域，从而不利于专家的特化。为缓解这一问题，论文改用全局负载均衡损失：

**2）共享专家（Shared experts）：**所有 token 共享一部分专家，保证至少 S 个专家总是被激活。

**3）一致性损失（Consistency loss）：**对相邻 token 的 router logits 加 KL 散度，让相邻 token 的路由分布更相似。SG 表示停止梯度（stop-gradient）。

**4）自回归专家选择（Autoregressive expert selection）：**在 SD 窗口内，后续 token 保留前一个 token 的 k-l 个专家，再补自己的 top-l：

这样每个窗口（γ+1 个 token）内专家数最多约 k+γl，不会爆炸。

【共享专家和负载均衡可参考我的博文：

（2024|ACL|DeepSeek & 北大，MoE，细粒度专家分割，共享专家隔离）DeepSeekMoE：迈向极致专家专精的 MoE 语言模型

1）什么是专家并行（Expert Parallelism，EP）？

在大模型训练中，如果 MoE 的专家总数太多（比如几十上百个），单张 GPU 放不下所有专家。EP 就是把不同的专家分配到不同的 GPU 上。

问题来了 ：如果某个 micro-batch 的数据，恰好把 90% 的 token 都路由给了 GPU-0 上的专家 1，而 GPU-1 上的专家 2 没被选中。结果就是：GPU-0 累死（算力打满），GPU-1 闲死（完全闲置），整个训练过程被最慢的 GPU 拖慢。
局部负载均衡的初衷：就是为了防止单次计算时出现这种 "贫富差距过大"，强行让每个 micro-batch 都把专家用均匀，从而保障 EP 的训练效率。

2）Apple 为何敢换全局负载均衡？

局部负载均衡为了迎合 EP 的硬件效率，强迫每个小batch必须 "端水"，结果破坏了专家特化（Expert Specialization） ，进而打散了相邻 token 的专家选择，严重削弱了专家连携（Coactivation），拖慢了推理。

Apple 敢于将其替换为全局负载均衡，基于以下三点精准的权衡：

Shared Experts 兜底（抵消 EP 倾斜）：这是 Apple 的关键设计。因为所有 token 都无条件经过 Shared Experts，这极大平滑了局部 micro-batch 倾斜带来的 EP 算力闲置问题，避免出现严重的 "闲死" 现象。
通信代价极小 ：计算全局负载均衡只需通过 All-Reduce 同步极小的统计向量（KB 级）。论文实测表明："实践中这一步并未造成训练瓶颈（in practice this step does not cause a bottleneck in training）"。
极其划算的 "算力经济账" ：MoE 是 "一次训练，长期推理"。Apple 牺牲了训练期微小的 EP 效率，却换来了极致的 Expert Coactivation，最终在推理配合 SD 时，拿到了 21% 的吞吐提升，且精度持平。

总结：局部负载均衡保的是训练时的硬件效率，全局负载均衡保的是推理时的极速。Apple 用轻量的通信代价，加上 Shared Experts 兜底，成功跨过了 EP 的算力陷阱，换来了最终 21% 的推理加速。

】

实验结果：1B total / 353M active 的 MoE，对比 352M Dense；

4 个 token 验证从 9 个专家降到 5 个专家（Figure 1a/1b）；
吞吐比标准 MoE 高 21%，在所有 SD window size 下都领先（Figure 1c）；
精度保持，且相对 Dense 有约 9% 相对提升（Figure 1d）；
消融显示，global load-balancing、shared experts、autoregressive expert selection 各自都能降低活跃专家数，组合后最低（Figure 3c），吞吐也最高（Figure 3d）。

**总结：**如果 MoE 可以重训，就从 router 训练上让专家 "抱团"，这是最治本的一类方法。

3.2 运行时调度：Cascade

核心问题：MoE 下 SD 是否加速取决于任务、请求、迭代位置。固定推测长度（Draft Token 数量）K 不可靠，有时 K=1 都会 slowdown。

核心思路：定义 speculation utility = ETR / cost：

所以只要最大化 utility，就能最小化 TPOT（the time per output time）（Figure 8）。

系统设计 Cascade（Figure 9）：

Test-and-Set 策略：周期性测试不同 K，测 utility，然后选最佳 K 进入 set 阶段（Figure 10）。
动态关闭 SD：当 utility < 1，直接 K=0，避免 slowdown。
Adaptive Back-Off：如果持续无效，指数级降低测试频率，限制测试开销（Figure 11）。
Hill-Climbing Search：根据 utility 随 K 的变化方向，快速搜索最优 K（Figure 12）。

实验结果：

静态 K 最坏 slowdown：K=1 时 26%，K=2 时 38%，K=3 时 54%；
Cascade 最坏 slowdown 限制在 5%（Figure 13）；
平均比 static-K 提升 7%～15%，部分场景相比无推测基线最高 1.6x（Figure 13）；
对 EAGLE 等 draft-based SD 也适用，与 static-K 表现相当（Figure 17）；
三项优化------dynamic spec disable、adaptive back-off、hill climbing------各自都有贡献，叠加后最好（Figure 18）。

总结：如果模型已训练好、线上请求异构，Cascade 是最实用的 "运行时保险丝"。

3.3 Draft 选择降本：EcoSpec

核心问题 ：现有 SD draft 选择主要看接受概率，但在 MoE 中，高置信度 token 可能路由到不相交专家，造成 expert scattering，增加专家权重内存流量（Figure 1b）。

核心方法：EcoSpec 在 draft generation 之后、target verification 之前，选择哪些 draft 节点进入验证（Figure 2）。

包含三个组件：

1）轻量级专家预测器（Lightweight Expert Predictor）

在验证前，用一个小模型（如 Qwen-0.6B 或 R1-Distill）预测 Draft Token 在目标 MoE 模型中可能激活的专家集合 K。无需频繁调用目标大模型。
论文在 DeepSeek-V3.1 上用 DeepSeek-R1-Distill-Qwen-1.5B，在 Qwen3/GPT-OSS 上用 Qwen3-0.6B，路由预测准确率分别为 80% / 82% / 93%。

2）全局专家缓存（Global Expert Buffer）

记录已选验证集覆盖的专家，用于估计候选的边际成本。

3）成本感知评分（Cost-Aware Scoring）

候选分数：

其中 P(t_i) 是累计 draft 概率，ΔCost 是引入的新专家数。

优先选高接受概率且复用已有专家的路径（Figure 3 示例：t_1 概率更高但引入 3 个新专家，t_2 概率略低但只引入 2 个新专家，最终选 t_2）。

实验结果：三个大 MoE：DeepSeek-V3.1 671B、Qwen3-235B-A22B、GPT-OSS-120B；

最高 1.62x speedup；Qwen3-235B 平均 1.36x，GPT-OSS 平均 1.31x，DeepSeek-V3.1 平均 1.15x（Table 1）；
Qwen3 HBM read 从 99.3GB 降到 88.1GB，节省 11.2GB/step（Table 2）；
predictor 开销约 4ms/step，远小于验证延迟的下降（Table 3）；
消融显示，marginal-cost scoring 优于 static global-cost（Table 4）；
与 GTO 组合后仍有一致提升（Table 5）。

总结：别只挑 "最可能对" 的 draft token，还要挑 "最省专家" 的 draft token。

3.4 验证时降本：MoE-Spec 与 AcceptMoE

这两篇都发生在 target 验证阶段，目标都是限制每层实际加载的专家集，所以放在一起。

3.4.1 MoE-Spec：固定 expert budget

核心问题：

EAGLE-3 这类树状 SD 会验证 60+ draft tokens。OLMoE 上 127-token 树可激活 54/64 专家，接近全模型（Figure 2b）。
但专家激活是 长拖尾的（heavy-tailed） ：OLMoE 中 top 32/64 专家捕获 93% 路由概率，被激活的尾部专家贡献小但每个都要完整加载权重（Figure 2c）。

核心方法（Figure 1）：训练无关的验证时专家预算（training-free verification-time expert budgeting）：

对 draft tree 中所有 token 计算路由概率；
按 某种策略给每个专家打重要性分数，选出 top-B 构成 shortlist S；
只加载 S 中的专家完成验证，对 "落选" 的 token 做 覆盖处理。

三种专家重要性排序策略：

1）Static Ranking（静态排序）

用校准数据统计每个专家被选中的频次：

取频次最高的 B 个。零运行时开销，甚至可以做永久剪枝（只部署 32/64 个专家，显存减半）。在中等预算（B ≥ N/2）下表现接近自适应方法，但预算很紧时会崩。

2）Router-Based Ranking（路由聚合，论文默认方法）

把 draft tree 上所有 token 的路由概率按专家求和：

取 s_i 最大的 B 个。不增加任何额外计算------router 本来就要算这些概率，只是多了一次求和与排序。它能自适应每棵树的路由模式，是论文的主方法。

3）Oracle Ranking（上界）

假设能拿到 target 模型的真实输出

贪心地逐个选择 "最能降低重建误差" 的专家：

这个不可用于实际加速（要跑全部专家），但给出了质量天花板。

**两种 token 覆盖策略：**选出 shortlist 后，那些 "自然路由落在 shortlist 之外" 的 token 怎么办？

1）Truncation（截断）

保留自然 top-k 路由，但 shortlist 外的专家贡献置零：

极端情况下某 token 一个专家都没命中，MoE 输出为零，只剩残差连接。

2）Substitution（替换，论文默认）

把 top-k 的选择限制在 shortlist 内部，缺失的专家用 shortlist 里分数最高的替代：

每个 token 仍然拿到恰好 k 个专家，只是可能不是 "原配"。实验发现两种策略效果相当，选 Substitution 主要是为了保持每 token 激活专家数恒定（见下图 5b）。

实验结果：

相比 EAGLE-3，吞吐提升 10%～30%，质量相当（Table 1）；
在 27/30 个 model-benchmark 配置上 speedup 超过 EAGLE（Table 1）；
EAGLE-3 在 tree size 31 后速度下降，MoE-Spec 持续提升到 tree size 255 的 2.1x（Figure 4b）。
Router-based ranking 在低预算下远优于 Static，接近 Oracle 上界（Figure 5a）；
Oracle 分析表明，更好的选择策略可再减少 25% 专家需求（Figure 6）；
路由集中任务（代码：MBPP, HumanEval）可容忍更紧预算；摘要任务（CNN/DM）路由分散，需要更多专家（Figure 7）；

**总结：**不训练模型，只在验证时 "砍掉长尾专家"，就能显著降低带宽。

3.4.2 AcceptMoE：自 sizing + 缓存感知

核心问题：

验证 token 数、激活专家并集大小、专家权重传输量是三个不同成本；
固定 expert budget 需要人工指定，且跨任务变化大；
offloading 下，传输成本还取决于专家是否在 cache 中。

核心方法（Figure 1）：

1）接受率加权的专家需求（Commitment-weighted demand）

由于 draft tree 中不同深度的节点被最终接受（commitment）的概率不同（越深概率越低，且兄弟节点互斥），AcceptMoE 摒弃了传统的均匀权重聚合：

首先，从离线验证轨迹估计每个 draft 位置被 commit 的概率（marginal commitment probability）：

其中，m_d 是在位置 d 处观察到的提议节点数量，c_d 是位于已接受输出前缀上的那些节点的数量。

然后，为每个 Token 分配重要性权重：

其中，N 表示 block 中位置 d 处的 token 数量，β 控制着概率估计的适用程度（默认 β = 0.5）。

计算专家的效用分数：

这样，更大概率被最终输出的 Token 会获得更高的路由权重，被丢弃分支的干扰更小。

2）自调整专家集（Self-Sizing Expert Sets）

AcceptMoE 不再需要人工指定专家预算 B，而是根据需求分布自动决定集合大小：

根锚点保留：始终保留深度为 0 的根 Token 的原始 Top-k 专家（Anchor）。
有效秩计算：对剩余专家的效用分布归一化后，计算信息熵的指数（即有效秩）：

需求越集中，n_er 越小，最终保留的专家集 S 就越小；需求越分散，保留的专家集就越大。

3）缓存感知剪枝（Residency-Aware Pruning）

当模型采用专家 offloading（部分专家在 CPU 内存中）时，AcceptMoE 引入了缓存感知剪枝（Figure2）。

在构建好候选专家集 S 后，找出其中不在 GPU 缓存（LRU）中的非驻留专家。
依据效用 u_e 从小到大排序，在不超过重路由预算 （Rerouting Budget）和最小集合大小约束的前提下，尽可能多地剪除这些非驻留专家。
这从根本上改变了专家选择逻辑：从传统的 "预测并预取专家" 转变为 "让专家选择适应当前的缓存状态"。

实验结果：12 个 model-task 组合，3 个 MoE target，4 个 benchmark；

平均精度比 Standard SD 低（Table 1）；
与 MoE-Spec 在 matched budget 下对比：AcceptMoE-B 平均精度 90.60%，MoE-Spec 88.15%（Table 1）；
全专家驻留吞吐比 Standard SD 高（Figure 3）；
物理 offloading 下吞吐比 Standard SD 高（Figure 4）；
H2D 流量降低 73.6%～77.1%，cache hit rate 提升 10.8～14.2 个百分点（Table 2）；
fetch-stall 从 65%～78% 降到 27%～35%（Figure 5a）；
self-sizing 与固定预算扫描对比：self-sized 点平均只比最佳固定预算低 0.97 个百分点，最差 1.83 个百分点（Figure 5b）。

**总结：**不需要手动给 expert budget，AcceptMoE 根据 commitment 和 cache 状态自动决定每层加载哪些专家。

3.4.3 本节小结

方法	作用环节	稀疏化的对象	核心机制	隐喻
ECOSPEC	Draft 生成后、验证前	Draft 节点（Token）	给节点打分：S(t_i) = P(t_i) / ΔCost。强制选中引入新专家少的路径。	"前置过滤"：连门都不让你进，选了省专家的 token 去验证。
MoE-Spec	Target 验证时	路由专家（Experts）	设死预算 B。聚合路由概率，每层只加载 Top-B 专家，砍掉长尾。	"硬性截断"：不管你 token 选了啥，每层我只给 B 个专家额度。
AcceptMoE	Target 验证时	路由专家（Experts）	self-sizing（熵决定数量）+ 缓存感知（优先保留驻留专家）。	"智能自适应裁剪"：不仅决定选谁，还动态决定选多少，甚至考虑 GPU 缓存里还剩啥。

这三篇与稀疏 MoE 一样都有稀疏化的味道：

MoE 解决的是一次前向计算中的 "参数稀疏性"（只算 top-k 专家）；
而这三篇解决的是 "数据/内存流量的稀疏性"。

EcoSpec 的 Figure 3 是这三篇里最直观的 "稀疏性" 教学图：

节点 t_1 的累计概率是 0.53，但它引入了 3 个新专家；
节点 t_2 的概率只有 0.4，但它复用了已有专家，只引入 2 个新专家。
最终 t_2 的得分 S=0.20>0.17，被优先选中。

这个图完美地展现了 "边际成本"（Marginal Cost） 的概念。它和 AcceptMoE 的思想如出一辙：

EcoSpec 维护了一个 Global Expert Buffer，边选边更新，看新 token 能带来多少增量成本。
AcceptMoE 的 Residency-aware pruning 也是在看：如果这个专家已经在显存里了（成本=0），那它被选中的概率就应该增加。

它们本质上都是一种 "贪心算法的启发式搜索"（Greedy Heuristic Search），通过动态更新状态（Buffer 或 Cache），引导系统走向全局成本最低的稀疏子集。

3.5 理论指导：MoESD Target Efficiency

3.5.1 数学推导：多大 Batch Size 能激活所有专家？

MoESD 从理论和系统角度指出：MoE + SD 并非永远差，中等 batch size 下反而可能比 Dense 更受益。

论文推导了期望激活专家数 N(t) 的公式。假设共有 E 个专家，每个Token激活 K 个专家，MoE稀疏度为 ρ=K/E，输入Token数为 t，则：

当 N(t)>0.95E 时，即可近似认为专家全激活。此时阈值 T_thres 为：

当 Batch Size 达到这个阈值时，SD 的验证阶段就不会带来额外的显存读取灾难，加速窗口正式打开。

3.5.2 关键创新：Target Efficiency

过去的研究多聚焦于优化接受率（Acceptance Rate, α） ，即 draft 模型猜得有多准。但 MoESD 指出，系统架构和工作负载对最终加速比的影响同样巨大。

为此，论文提出了一个新的系统性指标：Target Efficiency：

它衡量 target 模型验证多 token 时相对单 token 的效率。

如果 Target Efficiency 接近1，说明验证多个 Token 的代价极低，SD 加速效果会非常好。
如果 Target Efficiency 接近 1/γ，说明 MoE 进行了全量计算，加速失效。
通过实验（Figure 2）可以看出，随着 Batch Size 的增加，MoE 的 Target Efficiency 呈现先升后降 的趋势，完美对应了最终 SD 加速比的变化。而接受率 α 在 Batch Size 变化时几乎平稳，无法解释加速比的剧烈波动。

3.5.3 性能建模：让加速过程白盒化

为了拆解各项开销，论文基于 Roofline 模型（内存墙）建立了一个端到端的时间模型：

三大核心因素：

1）Roofline 效应：内存墙 vs 算力墙

在 GPU 上，计算和显存访问是交织的。输入 Token 数（t）增加时，执行时间的增长并非简单的线性：

Memory-Bound（显存受限区） ：当 t 很小时，计算量小，瓶颈在加载参数。此时无论算多少 Token，加载参数的时间是固定的，曲线平缓。
Compute-Bound（计算受限区） ：当 t 变大，加载时间不再是瓶颈，算力成了老大难。计算时间与 t 成正比，曲线变得陡峭。

为了用数学描述这个 "先平缓、后陡峭" 的拐点趋势，论文设计了一个分段函数：

λRP 就是那个拐点（经验 Ridge Point），s 控制着增长的速率。在拐点前，它像个温和的指数函数；在拐点后，它直接 "拉直" 变成线性函数。这种设计完美保持了函数的一阶梯度连续性，极其契合物理规律。

2）激活专家数 N(t)：显存访问量的直接来源。

在 MoE 模型中，Token 越多，通过 Router 路由到的专家就越多，需要从显存中加载的专家参数也就越多。
论文直接使用前面提到的公式 N(t) 来刻画这种显存访问量的增加。

3）专家负载 ‾T_exp：每个专家真正处理的平均 Token 数。

在 MoE 中，一个 Token 并不是被所有专家处理。假设输入了 t 个 Token，平均分给每个专家的 Token 数其实是 ‾T_exp（远小于t）。
因此，在套用 Roofline 模型计算 MoE 专家的耗时，应该用 G(‾T_exp)，而不是直接用 G(t)。
这就完美解释了为什么MoE 越稀疏，系统越不容易撞上算力墙（Compute-Bound）------因为每个专家实际干的活儿变少了。

建模算法如下：

以 verify_time 为例：

bisa：加载不可拆分的稠密参数（非 FFN 部分）所需的固定时间。
第二项：随 Token 数增加的密集计算（如 Attention 等）的 Roofline 耗时趋势。
第三项：加载 N 个被激活的专家参数所需的时间。
第四项：MoE 专家里实际计算部分的 Roofline 耗时趋势。

对于 draft 模型，因为通常都是稠密小模型，没有专家机制，所以公式极度简化，只包含 bias 和 Roofline 效应。

为什么要用最小二乘法去 "拟合" 真实数据，而不是"纯理论计算"？

论文给出了非常工程的解释（附录 C）：

算子实现差异巨大：同样是 Attention，用 FlashAttention-3 还是 PyTorch 原生实现，速度天差地别；Qwen 和 Mixtral 的 FFN 耗时表现也不完全按理论隐藏层维度走。
硬件黑盒：不同 GPU 的缓存（Cache）配置、线程内存交互模式等微架构细节是不公开的，纯理论算不准。

因此，论文使用 21 个实际测量点，去拟合模型中的 10 个未知超参数，拟合时间仅需 0.114 秒。这套模型在各种稀疏度（ρ）和 draft 长度（γ）下都能预测 GPU 的实际运行时间（Figure 4）。

3.5.4 实验结果

Qwen2-57B-A14B 在中等 batch 下最高 2.29x speedup（Table 1）；
不同硬件平台上趋势一致（Table 2）；
MoE 的 target efficiency 先升后降，而 Dense 持续下降，说明 MoE 在更大 batch 范围有潜力（Figure 3）；
越稀疏的 MoE，SD 有效的 batch 范围越宽（Figure 4）；

4. 横向对比与工程实践

前面三节我们完成了 "为什么慢 → 什么时候慢 → 怎么让它不慢" 的因果链拆解。这一节把六篇论文放在一起横向对比，并给出落地建议。

4.1 六篇论文横向对比以及总结

论文	优化阶段	是否训练	核心机制	典型效果
为什么慢
Cascade MoE-Spec EcoSpec	诊断	否	揭示专家并集膨胀导致验证开销 2-3x	最坏 slowdown 1.5x
什么时候慢
MoESD	理论指导	否	中等 batch 下专家已全激活，SD 反而有效	中等 batch 下最高 2.29x
Cascade	运行时视角	否	任务/请求/迭代位置影响 utility，固定 K 不可靠	静态 K 最坏 slowdown 54%
AcceptMoE	Offloading 视角	否	Cache 未命中导致 H2D 传输拖垮 SD	Offloading 下 SD 比 AR 还慢
MoE-Spec	树状 draft 视角	否	树越大，被顺带激活的尾部专家越多	EAGLE-3 tree size 31 后降速
怎么不慢
Apple Coactivation	训练时治本	是	Global LBL + Shared experts + Consistency loss + 自回归专家选择	吞吐 +21%，精度持平
Cascade	运行时调度	否	Utility = ETR/cost，Test-and-Set 动态调 K，utility<1 关闭 SD	最坏 slowdown 限制在 5%
EcoSpec	Draft 侧筛选	轻量 predictor	选高接受且专家复用高的 draft 节点，减少 expert scattering	最高 1.62x
MoE-Spec	Verifier 侧硬截断	否	每层只加载 top-B 专家，砍长尾	比 EAGLE-3 吞吐 +10-30%
AcceptMoE	Verifier 侧软裁剪	否	Commitment 加权 + 自 sizing + 缓存感知	全驻留 1.290x，offload 2.06x
MoESD	理论指导	否	提出 Target Efficiency = T_T(B,1) / T_T(B,γ)	判断 SD 机会区

1. 为什么慢？

SD 在 Dense 上 "验证几乎免费" 的假设，在 MoE 上不成立。验证多 token 会激活更多专家的并集，导致专家权重传输量增加，内存带宽成为瓶颈。

2. 什么时候慢？

任务、请求、迭代位置影响 utility；小 batch、offloading、大树 draft 容易慢；中等 batch、高稀疏反而有机会。

3. 怎么让它不慢？

训练时：让专家抱团（Apple Coactivation）；
运行时：用 utility 动态调 K（Cascade）；
Draft 选择：成本感知筛选节点（ECOSPEC）；
验证时：硬截断长尾（MoE-Spec）或软裁剪驻留专家（AcceptMoE）；
理论指导：用 Target Efficiency 判断机会区（MoESD）。

4.2 工程落地建议

如果在实际业务中部署 MoE + SD，可以参考以下决策树：

能重训 MoE（如自研模型）

→ 采用 Apple Coactivation：Global LBL + Shared experts + Consistency loss + 自回归专家选择。这是治本之法，从源头提高 coactivation，一劳永逸。
模型已训练好，线上请求异构

→ 加上 Cascade：用 utility 动态调 K，utility < 1 时直接关闭 SD，防止负优化。适合作为通用的 "运行时保险丝"。
用 EAGLE-3 等树状 SD，验证 token 多

→ 采用 MoE-Spec：每层限制 top-B 专家，直接砍掉长尾，显存带宽立省 10-30%。
大规模 MoE + 高置信度 draft 节点散乱

→ 采用 EcoSpec：在 Draft 选择时考虑专家复用，减少 expert scattering，适合 DeepSeek-V3、Qwen3 这种几百 B 的大模型。
专家需要 Offloading（显存装不下）

→ 采用 AcceptMoE：Commitment 加权 + 自 sizing + Residency-aware pruning，在物理显存受限时，把 H2D 传输降低 70%+。
中等 batch / Private Serving

→ 参考 MoESD 的 Target Efficiency 模型：先测一下当前配置，别默认 SD 对 MoE 无效，中等 batch 下可能反而有大机会。