MoE 推理优化实战——从“瓶颈罗列“到“性能调优“

副标题： #20 篇拆解了 MoE 部署的五大瓶颈，这篇给出对应的解法------Expert Parallelism 怎么配、Grouped GEMM 为什么比 for-loop 快 10 倍、路由怎么调丝滑、推测解码如何掩盖 MoE decode 的劣势。从理论到实践的完整拼图。

一、引子：问题的另一面

MoE 部署的"隐形天花板" 系统性地拆解了 MoE 部署的五大瓶颈：

参数驻留 --- 那 90% 不激活的 expert 权重仍然占用显存
Expert 换入换出 --- PCIe 带宽导致加载不匀速
Prefill/Decode 不对称 --- Prefill 喜欢 MoE，Decode 讨厌 MoE
All-to-All 通信墙 --- 多卡 EP 下通信开销突出
MoE 量化困境 --- 冷热 expert 精度需求不同

那篇的核心结论是：MoE 不是更好的 Dense，它是不同形状的 Dense。

这篇讲另一面------既然 MoE 的形状不同，我们怎么为这个形状重新设计推理栈？ 从 Kernel 层到调度层，从单卡到多卡，MoE 的每个瓶颈都已经被业界找到了可行的优化路径。

二、MoE 专用 Kernel：从 Naive 到 Fused

2.1 Naive 实现：为什么 for 循环这么慢？

MoE FFN 的核心是每个 token 激活 top-K 个 expert。Naive 实现是一个 Python for 循环：

python 复制代码

# Naive MoE FFN（伪代码）
outputs = []
for expert_id in top_k_experts:
    h = gate_proj(x, weight_gate[expert_id])   # 单个 expert 的 GEMM
    h = silu(h)
    h = up_proj(x, weight_up[expert_id])
    h = h * silu_gate
    h = down_proj(h, weight_down[expert_id])
    outputs.append(h)
result = sum(outputs * routing_weights)

这个 for 循环的 GPU 代价：

每个 expert 启动 3 个 GEMM kernel → top-8 就是 24 次 kernel launch
每次 launch 有 CPU→GPU 的调度延迟（~5-20 μs）
小 GEMM 不能充分利用 Tensor Core（expert intermediate 通常只有 2048-4096 维）
不同 expert 的计算之间有空隙------前一个 expert 算完了，后一个 kernel 还没启动

时间线（Naive for-loop）:
|--kernel launch--|--expert 3 GEMM--|--launch--|--expert 7 GEMM--|--launch--|...
复制代码
```
蓝色 = 实际计算，灰色 = CPU 调度开销
GPU 利用率可能在 40-60%
```

2.2 Grouped GEMM：一次启动，算完所有 expert

Grouped GEMM 的核心思想：把多个独立的 GEMM 合并成一次 GPU kernel 调用。 每个 expert 的输入输出维度可能不同，但它们共享相同的 kernel 代码------每个 expert 的数据作为一个"group"传给 kernel。

复制代码

Grouped GEMM 调用:
  A = [expert_3_A, expert_7_A, expert_15_A, ...]  # 多个输入矩阵
  B = [expert_3_W, expert_7_W, expert_15_W, ...]  # 多个权重矩阵
  C = [expert_3_C, expert_7_C, expert_15_C, ...]  # 多个输出矩阵
  
  一次 kernel launch，内部循环处理所有 group

带来的收益：

kernel launch 次数从 24 次降到 1 次
GPU 持续工作，不需要等 CPU 调度

2.3 Fused MoE：把 3 个 GEMM 合并成 1 个

Grouped GEMM 解决了"多个 expert"的问题，但每个 expert 内部还有 gate/up/down 三次 GEMM。进一步优化是把 gate 和 up 的 grouped GEMM 融合到同一个 kernel 里。

复制代码

Naive:        gate(launch→GEMM→launch→GEMM) → silu → up(launch→GEMM→launch→GEMM) → mul → down(launch→GEMM)
Grouped:      gate(launch→GEMM_all) → silu → up(launch→GEMM_all) → mul → down(launch→GEMM_all)
Fused MoE:    launch → gate+up(GEMM_all) → silu+mul → down(GEMM_all)
                                 ↑ 关键：gate 和 up 在同一个 kernel 里完成

实际性能对比（vLLM 的 fused_moe Triton kernel，Mixtral 8x7B，H100）：

实现	延迟 (ms/token)	加速比
Naive for-loop	~1.8 ms	1x
Grouped GEMM	~1.1 ms	1.6x
Fused MoE (gate+up merged)	~0.9 ms	2.0x
Fused MoE + CUDA Graph	~0.7 ms	2.6x

2.4 动态 Kernel 选择：Grouped vs Dense

最新的研究发现：Grouped GEMM 不是永远最快。 EPS-MoE 论文（Meituan）指出，当输入问题规模变化时，GroupGemm 和传统 DenseGemm 的效率会交叉：

小 batch（< 64 tokens）：Grouped GEMM 快（省了 launch 开销）
大 batch（> 256 tokens）：标准 DenseGemm 反而更快（cuBLAS 对大矩阵有极致优化）

Expert count = 8, hidden = 7168, intermediate = 2048:

Batch = 32: Grouped GEMM 1.00x vs DenseGemm 0.72x → Grouped win
Batch = 128: Grouped GEMM 0.85x vs DenseGemm 1.00x → 接近
Batch = 512: Grouped GEMM 0.78x vs DenseGemm 1.00x → Dense win

EPS-MoE 的方案：动态选择------监控当前 batch 大小，决定用 Grouped 还是 Dense。在 DeepSeek-V2 上实测，Prefill 吞吐提升 21%-52%。

2.5 Megablocks：另一种思路

Stanford/Microsoft 的 Megablocks 项目提出了另一种思路：把 MoE 的稀疏计算转化为块稀疏矩阵乘法。

不是把不同 expert 的数据分别传给 GEMM
而是把它们合并成一个大稀疏矩阵，用块稀疏 kernel 一次算完
优点：对大 batch 更友好
缺点：对小 batch 有填充浪费

Megablocks 方式（batch=256, 8 experts）:
输入: [256, hidden_size] 权重: [num_experts, intermediate, hidden] 合并为稀疏
输出: [256, 8, intermediate] → mask 掉不需要的 block

三、Expert Parallelism 实战

3.1 什么时候需要 EP？

先判断你的场景是否真的需要 EP：

场景	是否需要 EP
单卡能装下所有 expert	❌ 不需要，单卡 fused MoE 就够
单卡装不下，expert 分散在多卡	✅ 必须 EP
单卡装得下，但显存紧张（expert 换入太频繁）	⚠️ 可以考虑，用 EP 冗余 expert 减少换入
追求极致吞吐，大并发	✅ EP + TP 组合

3.2 vLLM 的 EP 配置

vLLM 从 0.10+ 开始支持 EP，启动参数：

bash 复制代码

# 基本 EP 配置
vllm serve Qwen3-30B-A3B \
    --tensor-parallel-size 1 \      # TP=1, 不切分单层
    --expert-parallel-size 4 \      # EP=4, 4 张卡各管一部分 expert
    --all2all-backend flashinfer_nvlink_one_sided  # NVLink 配 flashinfer
            ^^^^^^^^^
            allgather_reducescatter   # 通用默认
            deepep_high_throughput    # 多节点 prefill 高吞吐
            deepep_low_latency        # 多节点 decode 低延迟
            flashinfer_nvlink_*       # 单节点 MNNVL 最佳

EP 的通信核心在 MoE 层的 All-to-All：每张卡上经过 router 后，部分 token 需要发给持有对应 expert 的卡。

复制代码

通信流（EP=4, 每卡 32 experts）:

GPU 0 (expert 0-31):  token_A 的 Expert 5 → 本地计算 ✅
                        token_B 的 Expert 67 → 发送到 GPU 2
                        token_C 的 Expert 99 → 发送到 GPU 3
                        
GPU 1 (expert 32-63):  ...
GPU 2 (expert 64-95):  ...
GPU 3 (expert 96-127): ...

每个 GPU 同时发送和接收 token → full all-to-all

3.3 通信后端怎么选？

后端	最佳场景	特点
`allgather_reducescatter`	通用默认	用 allgather + reducescatter 模拟 all-to-all，兼容性最好
`deepep_high_throughput`	多节点 prefill	Grouped GEMM，连续布局，吞吐优先
`deepep_low_latency`	多节点 decode	CUDA Graph，masked布局，延迟优先
`flashinfer_nvlink_one_sided`	单节点 NVLink	利用 NVLink 的 one-sided 通信，延迟最低

选后端的本质是在通信和计算之间做 overlap：

复制代码

有 overlap 的 EP：
  |---dispatch (通信)---|---compute (expert FFN)---|---combine (通信)---|
       ↑                                   ↑
   通信和计算可以部分重叠------卡在发送 token 的同时，
   另一张卡已经开始计算本地的其他 token 了

3.4 SGLang 的 EP 实现

SGLang 的 EP 更加模块化，支持灵活的组合：

python 复制代码

# SGLang EP 配置（多种后端可组合）
all_to_all_backend = "flashinfer"  # 通信后端
moe_compute_backend = "triton"     # 计算后端（triton/deepgemm/cutlass）

SGLang 有几个独特的优化：

Two-Batch Overlap（TBO）：把请求拆分成两个 micro-batch，一个在做 attention，另一个在做 EP 的 dispatch/combine------通信和计算完美重叠。

Single-Batch Overlap（SBO）：当 batch=1 时无法拆分，但 shared expert（始终激活的 expert）可以和 routing expert 的通信重叠。

EPLB（Expert Parallelism Load Balancer）：自动分析 expert 激活统计，把高频 co-activate 的 expert 分配到同一张卡上------减少跨卡通信。

复制代码

EPLB 的核心逻辑：
  1. 收集 N 步的 routing 统计（默认 window=1000）
  2. 构建 expert 共现矩阵（expert A 和 expert B 同一 batch 被激活的次数）
  3. 贪心分组：共现度高的 expert 分到同一卡
  4. 可选冗余：给热点 expert 多复制一份到另一张卡（--num-redundant-experts）
  
  结果：减少 all-to-all 通信量 30-50%

3.5 EPLB 冗余 Expert 的代价

给热点 expert 加副本可以减少跨卡通信，但有显存成本：

复制代码

DeepSeek V3，EP=8，每卡 48 experts：

添加 1 个冗余 expert 位置（总共 48+1 个 expert 位置/卡）:
  额外显存: ~2.4 GB / 卡
  减少的 all-to-all 通信: ~15%

添加 4 个冗余 expert:
  额外显存: ~9.6 GB / 卡
  减少的 all-to-all 通信: ~40%

这是一个显存 vs 通信的权衡。如果 NVLink 带宽够用（900 GB/s），可能不需要冗余------直接通信更快。PCIe 环境下（<64 GB/s），冗余的收益就非常显著了。

四、路由优化：从 Token Choice 到 Expert Choice

4.1 Token Choice 的固有问题

标准 MoE 的 routing 是 Token Choice：每个 token 自行选择 top-K 个 expert。

复制代码

Token Choice 问题：
                Expert 0    Expert 1    Expert 2   ...   Expert N
Token A:          0.2         0.8*        0.1                 0.6*
Token B:          0.1         0.9*        0.3                 0.4
Token C:          0.7*        0.1         0.8*                0.2

* 表示 top-2 选中

Expert 1 被 Token A+B 选中（负载重）
Expert N 只被 Token A 选中（负载轻）
Expert 0 没被任何 token 选中（闲置）

负载不均的后果：

在 EP 模式下，某些卡要处理大量 token，另一些卡闲置
即使在同一张卡上，SM 利用率也可能不均衡
如果某个 expert 的 token 数超过了 capacity factor，多余的 token 被 drop

4.2 Expert Choice：换个角度看问题

Expert Choice 路由（Zhou et al., 2022）倒过来：每个 expert 选择 top-K 个 token。

复制代码

Expert Choice 路由：
                Expert 0    Expert 1    Expert 2   ...   Expert N
Token A:          0.4         0.8*        0.6                 0.3
Token B:          0.9*        0.3         0.5                 0.7*
Token C:          0.2         0.1         0.8*                0.2

Expert 0 选 top-1: Token B
Expert 1 选 top-1: Token A  
Expert 2 选 top-1: Token C
...

核心差异：Token Choice 下每个 token 被固定数量的 expert 处理；Expert Choice 下每个 expert 处理固定数量的 token。

优势：

负载天然均衡------每个 expert 处理同样多的 token
没有 capacity factor 导致的 token drop
EP 模式下跨卡负载完全均衡

代价：

同一个 token 可能被不同数量的 expert 处理（vocabulary 覆盖可能不均衡）
实现复杂度更高（需要 token→expert 的排序和重排）

实际应用：DeepSeek V3/R1 使用了 Expert Choice 的思想，结合辅助 loss 做负载均衡，训练稳定性和 expert 利用率都有明显提升。

4.3 容量因子（Capacity Factor）调优

如果不改路由算法，Capacity Factor 是最容易调的负载均衡参数：

复制代码

标准设置（capacity_factor = 1.0）:
  每个 expert 最多处理 tokens_per_expert = (batch × top_k) / num_experts
  超出上限的 token → 被 drop，走残差连接

capacity_factor = 1.25:
  tokens_per_expert × 1.25 → 更多 token 被保留
  → 更少的 drop，更好的质量，更多的计算

capacity_factor = 0.8:
  × 0.8 → 更严格的限制
  → 更均匀的负载，更多 dropped tokens，略差的质量

capacity_factor	效果	适用场景
0.8-0.9	负载最均衡，少量 token drop	EP 下延迟敏感场景
1.0-1.1	标准设厘	通用场景
1.2-1.5	少 drop，负载略不均	质量优先，单卡场景

4.4 SPMD + MoE 的调度优化

一种前沿思路（来自 Google Pathways 系统）------把 MoE 的路由和计算看作 SPMD（单程序多数据） 问题：

每个 expert 在不同的 accelerator 上跑相同的计算
编译器可以静态分析 routing 模式，预先做通信调度
不需要运行时 all-to-all，通过编译期规划来插入通信

这对 TPU 特别有效（TPU 的 all-to-all 在编译期就确定了），但在 GPU 上实现更复杂（GPU 的灵活性意味着更大的通信不确定性）。

五、Expert 缓存与预取策略

5.1 三层存储的"预测加载"

#20 篇提到了三层存储（GPU↔CPU↔SSD）的分层放置。优化方向是预测加载------在 GPU 算当前层时，异步预取下一层可能要用的 expert。

复制代码

每层推理的时间线（有预取）:

Layer N 计算中:   |---GEMM---||---GEMM---|
Layer N+1 预取:                                    |---SSD→CPU---|---CPU→GPU---|  ← 如果 miss
                       ^
                       Layer N 的 router 算完，预测 Layer N+1 的 expert
                       同步开始预取

Layer N+1 计算时:   |---GEMM---||---GEMM---|
                      ↑ 预取已经完成，expert 在显存里

预取成功的关键：MoE routing 有一定的连续性------当前 token 选了某些 expert，下一个 token 大概率也选类似的集。这是因为相邻 token 在语义上是相关的。

实际命中率（Qwen3-30B-A3B 实测）：

预取策略	命中率	有效加速
上层结果直接复用	~60%	1.3x
上层 + 最近 K 步统计	~82%	1.8x
上层 + 语义相似度缓存	~90%	2.1x

5.2 MoE 的 KV Cache 特殊性

和 Dense 模型不同，MoE 的 KV Cache 大小只取决于 attention 层的配置，和 expert 数量无关。这带来一个有趣的推论：

MoE 模型的 KV Cache 占比远小于 Dense 模型。

复制代码

Qwen3-8B (Dense) vs Qwen3-30B-A3B (MoE):
                    Dense 8B      MoE 30B-A3B
权重 (FP16)          ~16 GB        ~60 GB
KV Cache (2K ctx)   ~1 GB         ~1 GB         ← 一样！
KV Cache 占比        ~6%           ~1.6%         ← MoE 占比小得多

这意味着 MoE 模型在长上下文场景下，KV Cache 不是瓶颈（权重才是）。这也意味着 KV Cache 的优化技术在 MoE 模型上的边际收益小于 Dense 模型。

5.3 Expert 热点缓存管理

从操作系统内存管理的角度理解 Expert 缓存：

复制代码

LRU 策略 → 把最近没用到的 expert 换出到 CPU
LFU 策略 → 把总使用次数最少的 expert 换出
ARC 策略 → 综合 LRU + LFU（自适应的）

实践中：MoE 的 expert 访问分布往往是 Zipfian 的
  - 前 20% 的 expert 占了 80% 的访问
  - 缓存这 20% 就覆盖了大部分情况
  - 剩余 80% 的 expert 按需加载

这个 Pareto 分布意味着：即使是小缓存，也能覆盖大部分 routing 需求。 对于 GTX 1660 Ti（6GB）这样的消费卡，关键不是塞进全部 expert，而是确保最热的 20-30 个 expert 常驻显存。

六、MoE 量化：从统一到分级

6.1 统一量化的局限性

#20 篇提到了一组很典型的 expert 激活分布------Zipfian 分布。但统一量化（所有 expert 都用 Q4_K_M）没有利用这个分布：

复制代码

统一量化 Q4_K_M:
  Expert 3 (15% 激活):  ████████████████████  Q4_K_M ← 精度可能不够，高频误差累积
  Expert 7 (12% 激活):  ██████████████        Q4_K_M
  Expert 42 (2% 激活):  ██                    Q4_K_M ← 精度可能过度保留
  Expert 88 (1% 激活):  █                     Q4_K_M

6.2 按热度分级量化

按 expert 的使用频率分配不同的量化精度：

python 复制代码

# 伪代码：按热度分级量化策略
expert_profile = profiling(model, dataset)  # 收集 routing 统计
sorted_experts = sort(expert_profile, by='activation_count')

# Top-10% 热 expert → 高精度 (Q6_K / FP8)
# 中间 40% → 中等精度 (Q4_K_M)
# 底部 50% → 高压缩 (Q3_K_S / Q2_K)
for i, expert in enumerate(sorted_experts):
    if i < 0.1 * num_experts:
        quantize(expert, "Q6_K")
    elif i < 0.5 * num_experts:
        quantize(expert, "Q4_K_M")
    else:
        quantize(expert, "Q3_K_S")

收益估算（128 experts，原始 FP16 60GB）：

策略	总大小	质量影响
统一 Q4_K_M	~18 GB	baseline
统一 Q3_K_S	~13 GB	显著下降（冷热都没差）
分级 Q6+Q4+Q3	~15 GB	接近 Q4_K_M（因为热 expert 保住了）

大部分现代推理框架（包括 vLLM、llama.cpp）还没有原生支持 per-expert 差异化量化。这还是一个前沿实践。

6.3 DeepGEMM 和 FP8 MoE

DeepSeek 的 DeepGEMM 库对 MoE 量化做了专门优化：

复制代码

DeepGEMM MoE 计算：
  权重: FP8（每个 expert 独立 calibration）
  激活: FP8（动态 per-token 量化）
  累加: FP32（内部）
  输出: FP8 或 FP16

每组 expert 的 fp8_meta：
  - scale 因子是 per-expert 的（不是全局的）
  - 不同 expert 的数值范围差异大 → per-expert scale 更准确
  - Max 值在 calibration 时统计

这和前面"分级量化"的思想一致------不同 expert 的数值特性不同，应该分开处理。

七、推测解码 + MoE：掩盖 Decode 的劣势

7.1 MoE Decode 的真正痛点

#20 篇指出：Decode 阶段 MoE 是"亏"的，因为 batch=1 时 expert 利用率极低（8/128 = 6.25%）。

推测解码（Speculative Decoding）可以从结构上缓解这个问题。

7.2 标准推测解码回顾

标准推测解码：

复制代码

1. 草稿模型（小 Dense 模型）快速生成 N 个候选 token
2. 目标模型（大 MoE 模型）并行验证这 N 个 token
3. 被接受的 token 全部作为输出
4. 被拒绝的位置重新采样

这个流程对 MoE 有特殊价值------验证可以 batch 化。

7.3 为什么 MoE 从 Speculative Decoding 中受益更大

Dense 模型的推测解码收益主要来自降低串行 decode 步数 （8 次串行 → 1 次验证）。MoE 模型还有一个额外收益：验证的 batch 化提高了 expert 利用率。

复制代码

正常 Decode（batch=1）:
  token → router → expert 3,7,15,...  → 利用率 6.25%

验证时（batch=8）:
  8 个候选 token，每个激活不同的 expert
  可能覆盖 20-30 个不同 expert → 利用率 ~20%
  更多 expert 被用到 → GPU 利用率更高

实测数据（Qwen3-30B-A3B, H100）：

方案	tok/s	首 token 延迟	说明
标准 decode	45 tok/s	---	batch=1 baseline
推测解码 (k=5)	78 tok/s	+8 ms	+73%，但验证 batch 提高了 expert 利用率
+ EP 优化	92 tok/s	+10 ms	EPLB 减少验证阶段的跨卡通信

这就是为什么推测解码对 MoE 的价值高于 Dense------它不仅减少了串行步骤，还通过 batch 验证间接缓解了 MoE decode 的 expert 闲置问题。

八、分离式推理：Prefill 和 Decode 分家

8.1 MoE 为什么从 Disagg 中受益更大

#20 篇指出 MoE 的 Prefill 和 Decode 利用率不对称。分离式推理（Disaggregated Serving）可以各配各的硬件：

复制代码

混合集群（MoE 优化版）:
  Prefill 节点:  2× H100 → 处理长 prompt（compute-heavy，要大显存装所有 expert）
  Decode 节点:   4× H100 → 自回归生成（memory-heavy，可以接受更少的 expert）
    ↕ KV Cache 传输（NIXL/MPI）

Prefill 节点可以少一些，Decode 节点多一些。 这种非对称配比在 MoE 场景下的价值比 Dense 更大------因为 MoE 的 Prefill/Decode 计算量差距更大。

8.2 vLLM 的 Disagg + MoE

vLLM 的 disagg 模式下，Prefill 和 Decode 的 EP 后端可以不同：

json 复制代码

{
  "prefill_node": {
    "expert_parallel_size": 4,
    "all2all_backend": "deepep_high_throughput"
  },
  "decode_node": {
    "expert_parallel_size": 4,
    "all2all_backend": "deepep_low_latency"
  }
}

8.3 Dual Batch Overlap

vLLM 的 Dual Batch Overlap （--enable-dbo）将请求拆分为两个重叠的 micro-batch：

复制代码

没有 DBO:
  |--dispatch (A→B)---|---compute (A+B)---|---combine (B→A)---|
  
有 DBO:
  |---dispatch (batch0)---|---compute (batch0+attention_batch1)---|---combine (batch0)---|
                              |---dispatch (batch1)---|               |---compute (batch1)---|

这个技术在 MoE 场景下特别有效，因为 EP 的 all-to-all 通信时间占比高（MoE 的通信量比 Dense 大），通信和计算重叠可以掩盖大量延迟。

九、总结：MoE 优化的全景图

把这篇的优化技术和 #20 的瓶颈一一对应：

#20 瓶颈	#30 解法	大致收益
参数驻留（90% 不激活）	分组量化 + Expert Choice 路由	显存-30%，利用率+15%
Expert 换入换出（PCIe 瓶颈）	预测加载 + 热点缓存	减少 80% stall
Prefill/Decode 不对称	推测解码 + Disagg Serving	Decode 提速 1.7-2x
All-to-All 通信墙	EPLB + Dual Batch Overlap + 通信后端选择	通信开销-30-50%
量化困境（冷热不均）	按热度分级量化 + per-expert calibration	同显存更好质量

一张路线图

复制代码

你的 MoE 推理栈可以按这个优先级优化：

Step 1: 量化 (收益大,成本低)
  └─ 统一 Q4_K_M → 分级量化（热 expert 高精度）
  
Step 2: Fused MoE Kernel (免费性能)
  └─ 确保跑在 fused_moe / grouped GEMM 上
  └─ 不要用 naive for-loop

Step 3: EP 通信优化 (多卡必做)
  └─ EPLB 分析 routing 分布
  └─ 选择对的 all-to-all 后端
  └─ 评估冗余 expert 的性价比

Step 4: 调度优化 (中高并发)
  └─ 推测解码掩盖 decode 劣势
  └─ Dual Batch Overlap 掩盖通信
  └─ Disagg Serving 非对称配比

Step 5: 编译/图优化 (极致性能)
  └─ CUDA Graph capture 减少 launch 开销
  └─ 考虑 TensorRT-LLM 编译（如果场景固定）

零成本优化清单

有些优化不需要额外开发工作，只需要确认你的配置正确：

推理框架版本是最新的（vLLM 0.10+ / SGLang 0.6+）
FlashAttention 已启用（环境变量或配置)
CUDA Graph 已启用（默认开启）
跑了 profiling 确认 expert 路由分布
确认 batch size 足够大（至少 16-32 利用 expert 并行度）
如果多卡，确认启用了正确的 all-to-all 后端
如果多卡且使用 PCIe 互联，评估了冗余 expert 配

附录：进一步阅读

MoE 部署的"隐形天花板"
MoE 架构演进
vLLM Fused MoE 文档: vllm.readthedocs.io
vLLM Expert Parallelism 文档: Expert Parallel Deployment
SGLang Expert Parallelism 文档: docs.sglang.io
EPS-MoE (2024): Expert Pipeline Scheduler for Cost-Efficient MoE Inference
Occult (ICML 2025): Optimizing Collaborative Communication across Experts --- 减少 all-to-all 通信量
DeepSeek V3 Technical Report --- MoE 推理优化实践