MoE 推理的瓶颈已从算力转移到 All-to-All 通信与专家容量治理。本文从 TP×EP 二维并行、capacity factor 调优、Prefill-Decode 分离架构的 MoE 适配、SLO 三维治理四个层面,给出 2026 H1 主流工程团队的实战取舍与生产事故复盘模式。
当 DeepSeek-V3 把 671B 总参数 / 37B 激活参数的 MoE 架构推上生产级推理榜单前列，当 Qwen3-MoE、Mixtral 后续迭代、Llama-4-Scout 把"专家数从 8 跃升到 128"当作常态，工程团队面临的真正问题已经不再是"要不要上 MoE"，而是"如何在 NVL72 / H100 集群上把 256 路 expert parallelism 跑出稳定 30ms 首 token 延迟"。本文试图从三个层面回答这个问题：专家并行通信的工程真相、动态批处理与负载均衡的张力、生产级 SLO 治理的取舍。
MoE 推理与传统 dense 推理的差异，不是参数量大小，而是"路由决策 + 通信模式"的根本变化。dense 推理中，每个 token 的 FFN 计算路径完全确定，矩阵乘法的 FLOPs 与显存占用都可以精确预测；而 MoE 推理中，每个 token 会先经过 router 网络得到 top-k 专家权重，然后被 dispatch 到对应专家所在的 GPU 上计算，最后再通过 combine 阶段把结果拉回原 GPU。
设 为专家总数， 为 top-k 路由数， 为单步 batch 中 token 总数，则 MoE 单层 FFN 的关键工程指标为：
而 dense 模型对应指标只有 ，没有通信项。这就是为什么 MoE 推理的工程复杂度本质上由"通信 - 计算比"决定，而不是参数规模。
生产级 MoE 推理通常采用 TP × EP 二维并行：
两者正交但通信模式完全不同：TP 用 AllReduce（ring 或 tree），EP 用 All-to-All（dispatch + combine）。当 （总 GPU 数）固定时，如何分配 N 和 M 是一个工程优化问题。
"专家数越多 → 推理越慢"是不成立的。
事实上，专家数从 8 增加到 64 时，每个专家的 FLOPs 反而下降（因为 batch 被更多专家瓜分），单 token 延迟可能下降。但当专家数继续增加到 256+，All-to-All 通信延迟开始主导，延迟曲线才真正掉头向上。这条 U 型曲线是 MoE 推理工程的核心 tension。
All-to-All 在 NVLink / IB 拓扑下的实际带宽，远低于其标称峰值。以 NVL72 单机 8 卡 + 9 个 NVSwitch 的配置为例，理论上 8 卡之间可实现全互联带宽 ~900 GB/s，但实际跨卡 All-to-All 在 NCCL 2.21 上的吞吐仅 70-85%。原因有三：
为防止单个专家被过多 token 路由（导致 OOM 或延迟爆炸），MoE 推理引入 capacity factor ：
当某个专家接收的 token 数超过 时，多余 token 被直接 drop（router 输出置零）。Drop 率与延迟是负相关：
反直觉：生产中 调小反而能提升端到端有效吞吐，因为降低单卡峰值显存意味着可以拉高 batch size，而 batch size 提升的算力利用率收益 > drop 损失。
MoE 推理的负载不均有两个独立来源：
生产级 vLLM/SGLang 的处理方式：先用 device-level expert placement（按 NUMA 亲和度分配专家），再用 batch-level rebalancing（把超 capacity 的 token 动态 spill 到相邻卡）。
# 简化的 MoE 调度伪代码
def moe_dispatch(hidden_states, router_weights, expert_ids):
# 1. 计算每个专家实际接收的 token 数
expert_counts = bincount(expert_ids.flatten(), minlength=E)
# 2. 触发超容量 drop（如果必要）
overflow_mask = expert_counts > capacity
if overflow_mask.any():
expert_ids = remap_overflow_tokens(expert_ids, overflow_mask)
# 3. All-to-All dispatch（按物理拓扑分组）
grouped_ids = group_by_numa_locality(expert_ids)
return all_to_all(hidden_states, grouped_ids)
普通 dense 推理中，vLLM 的 continuous batching（continuous batching 策略，参见 2026-06-17 「Continuous Batching 与 Chunked Prefill 工程真相」）可以把 GPU 利用率推到 85%+。但在 MoE 推理中，continuous batching 失效：
2026-06-20 「Prefill-Decode 分离架构 2026」讨论了 DistServe 范式在 dense 模型上的工程落地。MoE 模型上的预分离架构需要额外考虑：
| 维度 | Dense 预分离 | MoE 预分离 |
|---|---|---|
| 单卡显存 | 可预测 | 高度依赖 expert distribution |
| 通信模式 | prefill-decode 间 KV cache transfer | 增加 All-to-All + token dispatch |
| SLO 治理 | TTFT vs TPOT 二维 | TTFT vs TPOT vs 专家溢出率 三维 |
MoE 模型的预分离架构需要在 prefill 端和 decode 端分别部署相同专家集合（保证 token 路由决策一致），显存开销比 dense 高 30-50%。
最新工程实践采用 chunked prefill + token-level MoE dispatch 的混合策略：
图表加载中…
关键工程参数：chunk_size 与 max_decode_batch 的比例。当 chunk_size=512, max_decode_batch=64 时，All-to-All 通信次数 = (prefill_tokens / 512) + decode_steps，相比"整段 prefill + 单次 dispatch"减少约 40% 的通信开销。
传统推理 SLO 只有 TTFT（Time To First Token）和 TPOT（Time Per Output Token）。MoE 推理必须引入第三个维度：expert overflow rate。
设生产环境 SLO 为：
任意一个指标突破阈值都会触发自动降级：
def adaptive_routing(hidden_states, current_slo):
if current_slo.expert_overflow > 0.05:
# 提升 capacity factor C
return route_with_capacity(C=2.0)
elif current_slo.ttft > 200:
# 降低 chunk size
return chunked_prefill(chunk_size=256)
elif current_slo.tpot > 50:
# 减少并发请求数
return reduce_concurrency(factor=0.8)
当专家数 > 单机 GPU 数（典型如 部署在 8 卡机内），必须用 跨节点 EP。但跨节点 EP 的 All-to-All 走 IB（InfiniBand）而非 NVLink，带宽下降一个数量级：
这意味着 超过单机 GPU 数时，每多一个专家带来的边际延迟增益迅速变成负数。生产经验：当 时扩展专家数是免费的；当 时，每翻倍专家数延迟增 60-80%。
MoE 推理的降级路径有两种：
DeepSeek-V3 的工程实践是 token drop + bias 调节：超容量 token 被路由到相邻专家（专家 ID ±1），同时 router 的 bias 项动态调整以降低未来溢出概率。
传统 GPU 监控（SM 利用率、HBM 带宽、NVLink 吞吐）完全不足以诊断 MoE 推理问题。生产级 MoE 监控必须增加：
| Metric | 来源 | 阈值（典型） |
|---|---|---|
| expert_load_per_card | router stats | std/mean < 0.3 |
| all_to_all_latency_p99 | NCCL profiling | < 5ms per layer |
| expert_overflow_rate | dispatcher | < 5% |
| token_drop_count | dispatcher | 0 (理想) |
| capacity_factor_effective | dispatcher | C_eff > 0.8 |
据某生产团队 2026 Q1 复盘报告（具体团队未公开验证），某 MoE 服务在 24 小时线上突增 30% TPOT。运维通过 GPU SM 利用率看一切正常（70%），但 expert_load_per_card 显示 std/mean = 0.85（极端不均）。根因是 router bias 调节器在某个时间窗口累积偏差，导致 70% token 被路由到 16% 的专家上。最终通过回滚 router bias + 重新校准恢复。
这个案例说明：MoE 推理的故障模式与传统 dense 推理完全不同——GPU 利用率满载 ≠ 服务健康。
把相似专家的权重合并（Task Arithmetic 风格），把 减少到 但精度损失 < 1%。代价是预先需要做一遍 expert similarity analysis。
把高频访问专家的权重预加载到 L2 cache，命中率可达 60%+，FFN 计算延迟降 15-20%。代价是 L2 cache 容量限制（每张 H100 仅有 50MB L2）。
把 All-to-All 的 token 数据用 FP8 压缩（而非 BF16），带宽需求降 50%，延迟降 30%。代价是 router 决策的精度受 FP8 量化噪声影响。
图表加载中…
以下几个趋势是 LLM 训练数据中的合理推断，但截至 2026-06 未有公开生产数据验证：
MoE 推理的工程化不是"参数越多越好"，而是通信 - 计算 - 显存 三者的精密博弈。当前的工程实战集中在三个方向：降低 All-to-All 物理开销（FP8 压缩、专家缓存）、控制容量因子的动态调节（自适应 C）、生产可观测性的盲区补完（新增 expert_load / overflow 等 metric）。
对于一个 50 人规模的 AI 基础设施团队，第一个生产级 MoE 服务的关键路径是：①从 的小模型起步（debug 容易）→ ②在单节点内验证 expert placement → ③引入跨节点 EP 时同步上线 expert_overflow_rate metric → ④最终接 SLO 治理（TTFT/TPOT/overflow 三维）。
当 MoE 从 8 专家走到 128+ 专家，生产推理的瓶颈从"算力"转移到"All-to-All 通信 + 专家容量治理"，本文从 TP×EP 二维并行、capacity factor 调优、Prefill-Decode 分离架构的 MoE 适配、SLO 三维治理四个层面，给出 2026 H1 主流工程团队的实战取舍。
URL: https://blog.lonae.com/posts/<待生成>
Conversation
0 条