MoE 路由的七个取舍：token 都挤向最热专家，延迟反而更高

MoE 层里，router 给每个 token 打分，只让得分最高的几个专家执行。直觉上，专家越集中越省计算。实际可能更慢：大量 token 挤向同一批专家，其他专家空转；固定容量下部分分配可能被丢弃；跨 GPU 时工作不均和通信开销会吃掉计算节省。Avi Chawla 在 这条推文 和长文里把 7 种生产路由策略、dispatch/combine、专家并行和 benchmark 细节串了一遍。有网友把这个问题比作 GPU 早高峰，另一个回复更短：sparse model, dense traffic jam。

先补背景。dense transformer 每个 token 都过同一个 FFN。MoE 层换成多个专家加一个 router，每个 token 只走选中的专家。Qwen3-30B-A3B 的模型卡写得很清楚：总参数 30.5B，激活参数 3.3B，48 层，每个 token 从 128 个 routed experts 里选 8 个。3.3B 描述的是单 token 执行路径的粗略计算量，不决定部署显存。服务端仍要准备 attention、embedding、全部专家权重、临时缓冲和 KV cache。按每个参数 2 字节存权重，30.5B 约 61GB，或 56.8GiB，且只算权重。

七种路由策略

Token-choice routing：每个 token 按 router 分数选 top-k 专家。每 token 的专家数固定，专家负载可变，所以要靠负载均衡机制防止流量堆到少数专家。

Expert-choice routing：每个专家在固定容量内挑分数最高的 token。专家工作量更均衡，单个 token 拿到的专家计算量可能不同。

Dynamic routing：不同 token 选不同数量的专家。基于置信度的变体会在路由分数不明确时多给专家，但 router 置信度并不直接等于 token 难度。

Balanced assignment：做全局匹配，在专家负载约束下分配 token。部分 token 可能去不了最高分专家，换更均衡的分配，匹配计算本身也有开销。

Hash-based routing：用确定性哈希把 token 映射到专家，没有学习门控。省掉 router 学习，专家选择对上下文的适应能力也更弱。

Soft MoE routing：专家通过 slot 处理 token 表示的加权混合。一个 slot 可以合并多个 token 的信息，专家处理的内容因此改变。

Group-limited routing：router 先限制候选专家组，再选专家。组划分对应硬件放置时，可以减少跨设备或跨节点通信。

这些选择会影响 serving engine 如何批处理专家计算、如何在 GPU 间分活。Avi 特意提醒：均匀分配 token 不保证低延迟。专家 batch 仍可能很小，token 在设备间搬来搬去要时间。

一个 batch 怎么变成专家矩阵

路由先给每个 token 产生 assignment。一个 token 选两个专家，就产生两条 assignment。runtime 按专家分组，把 token 向量、目标专家、路由权重打包。分组后的矩阵行数不同。grouped GEMM 用一次 kernel launch 跑多个专家矩阵，减少启动开销。有的引擎把专家矩阵 padding 到固定大小，方便调度，代价是空行也做计算。小 decode batch 最容易暴露问题：每个专家只有一两行，kernel 启动和搬运可能比矩阵乘还贵。有网友在回复里追问 padding 浪费，另一位说工程上会用动态分组或稀疏计算缓解，Avi 的长文没有展开。

测量要拆开：routing、permutation、expert GEMM、combine 分别计时。一个总的 MoE timer 看不出慢在哪。

专家并行把权重留在原地

专家并行把不同专家放到不同 GPU。token 的 assignment 如果落到远端专家，就把激活和 metadata 发过去，算完再回来。多层重复后，all-to-all 通信会累积。DeepEP 提供吞吐路径和低延迟路径，分别面向大传输和 decode 小步。网络拓扑决定跨 NVLink、InfiniBand、Ethernet 的成本。放置热专家可以靠近 token 来源，但别把热专家堆到一个节点上，过载后最慢 GPU 决定层延迟。

vLLM 的 EP 部署指南给了一个具体例子：TP=2、DP=4 时，attention 分 4 组，每组 2 个 rank，专家层可以用 8 个 rank 的 EP 组。复制专家能分流，但吃 GPU 显存，也挤压 KV cache。重平衡改变物理目的地，不改变 router 选中的逻辑专家。

尾延迟和 top-k 的边界

一个专家收到一半 assignment，它所在 GPU 就要算更大的矩阵。其他 GPU 早算完也得等。平均利用率看不出这种尾延迟，要按 serving step 记录 assignment 数、dispatch 时间、专家执行时间、combine 时间和 GPU 空闲时间。

优化分两类。fusion、grouped GEMM、放置、通信重叠只改执行方式。量化改存储权重或传输激活的数值。减少 top-k 改执行专家集合，输出会变。Avi 引用论文 Training-Free Halving of Activated Experts：在 Qwen3.6-35B-A3B 上，从 8 个专家减到 4 个，标准做法损失 4.65 MMLU 分，调整参考质量后损失 0.35 分；在 Qwen3.5-397B-A17B 上从 10 个减到 5 个，损失 0.55 分。论文只覆盖特定 checkpoint 和评测，不能当成通用规则。容量限制和丢弃 token 也看具体 runtime，MoE 推理不会因为专家忙就自动丢 token。

排查顺序

先确认权重和 KV cache 容量，再 profile 每个阶段，再测 assignment 偏斜和按通信域统计的字节数，最后用同一请求 trace 比 placement、kernel、量化或 top-k。一次只改一个变量。低并发和高并发、短 prompt 和长 prompt 都要测。记录 TTFT、TPOT、p95 延迟和 GPU 级空闲时间。

Avi 在长文最后问：你的部署会先查内存、专家计算还是通信。这个问题没有统一答案。先把三件事分开：存权重、算选中专家、搬 routed activations。测清楚哪一项最贵，再决定动哪里。

原文：7 MoE routing strategies，MoE inference engineering。