MOE推理流程解析

发布日期：2026/9/20 19:20:15      浏览量：

Qwen3-30B-A3B 的模型卡写着：总参数 305 亿，激活参数 33 亿，每个 token 从 128 个路由专家里选 8 个。
    很多人看到「33 亿激活」就默认这模型部署成本很低。这篇文章要纠正的正是这个误解：激活参数描述的是单个 token 的执行路径，它跟部署的内存占用没有关系。
    下面把 MoE 的服务链路拆开讲：路由器怎么选专家、运行时怎么把 token 分组成专家矩阵、本地 kernel 怎么执行、激活怎么在 GPU 之间流动，以及专家放置、负载不均、容量限制、量化这些工程问题。

一、MoE 层的基本结构
    一个稠密 transformer 对每个 token 施加同一个前馈网络。批处理改变输入矩阵的维度，但不改变哪些权重被执行。
    MoE 层把这个前馈网络换成多个专家。路由器为每个 token 给这些专家打分，只有被选中的专家对该 token 执行。
    这减少了每个 token 执行的专家计算量。但它并不能决定下一个 token 需要哪些权重——所以服务系统必须让每一个可选的专家都可用。
    这里有个容易被忽略的点：注意力仍然处理每个 token。路由器只控制专家分支。稀疏的专家激活并不会让注意力那条路径变稀疏。
    toy 例子：四专家层，路由器给每个 token 的所有专家打分，选出得分最高的两个。这两个专家各自独立地处理同一个 token 向量，层再把它们的输出组合起来，每个贡献按模型自己的路由权重加权。数学形式是：输出等于被选中专家集合上的加权和。
    要注意区分：token 到专家的路由发生在每个 MoE 层内部，这和「应用层的模型路由」（为一个请求选一个 LLM）完全不是一回事。
    另外，有些架构包含共享专家——这些专家不管路由器打多少分都处理每个 token。DeepSeekMoE 就用了共享专家隔离加路由专家。但不要假设每个模型都有共享专家，先查它的架构和 serving 实现。

二、一批 token 怎么变成专家专属矩阵
    路由器为每个 token 做了决定，但 GPU 无法高效地一次跑一个极小的专家操作。所以服务引擎要把路由决定转换成更大的、专家专属的矩阵。
    四个 token 进入一个四专家层、top-2 路由，路由器做出这些选择：T1 选 E1（权重 0.7）和 E3（0.3），T2 选 E1（0.4）和 E3（0.6），T3 选 E1（0.7）和 E2（0.3），T4 选 E2（0.8）和 E4（0.2）。
    运行时现在有八个 assignment，不是四个。每个 assignment 携带三样东西：token 向量、被选中的专家、路由权重。
运行时按专家分组这些 assignment：E1 收到 T1、T2、T3；E2 收到 T3、T4；E3 收到 T1、T2；E4 收到 T4。这些组变成行数分别为 3、2、2、1 的矩阵。
    每个专家处理自己的矩阵。运行时在每一行旁边保留原始 token ID，这个 ID 告诉它结果该送回哪里。T1 从 E1 得到一个结果、从 E3 得到一个结果，运行时把它们分别乘以 0.7 和 0.3，再把两个贡献相加得到 T1 的最终专家输出。
    这个分组步骤叫 dispatch，返回步骤叫 combine。两者都在同一块 GPU 上发生；多 GPU 会在它们之间加上网络传输。
一个专家 batch 统计的是 assignment，不是唯一的源 token。 top-2 路由下，每个 token 在专家矩阵里贡献两行。
    prefill 一次性处理很多 prompt token，所以专家可能收到很多行的矩阵，更大的矩阵通常更高效地利用 GPU。decode 每个活跃请求只加一个新 token，低并发下一个专家可能只有一两行——为这么点工作量启动一个矩阵 kernel，是在浪费 GPU 容量。并发更高时每个步骤会产生更多 assignment，grouped GEMM（分组通用矩阵乘法）把多个专家矩阵放进一次 kernel 启动，即使行数不同也能减少启动开销。有些引擎会把专家矩阵填充到固定大小，固定形状更容易调度，代价是在没有 token 的填充行上做计算。

三、本地执行流水线：专家 GEMM 只是其中一步
    一个 MoE 层做的事不止专家矩阵乘法。它必须选专家、重排 token 行、执行专家、恢复 token 顺序。每个阶段都可能吃掉可观的时间。
    路由器先为每个合格专家产生一个分数，top-k 操作保留被选中的专家索引和它们的权重。运行时随后重排 token 行，让每个专家收到一个连续的矩阵。这个重排叫 permutation，它读 token 向量、按专家顺序写出，同时记录一个逆映射供 combine 用。
    在小的 decode batch 里，移动行的耗时可能和乘法本身一样多。
    grouped GEMM 在一次 kernel 启动里执行多个专家矩阵，这些矩阵可以有不同行数，分组减少启动次数但不改变内容。专家随后施加自己的激活和输出投影，运行时用逆映射恢复 token 顺序，施加路由权重并把匹配 token ID 的贡献相加。
    kernel 融合把原本要分开启动的操作合并起来，一条融合路径可能避免把中间激活写回 GPU 内存，因此能减少启动成本和内存流量。但融合支持是有条件的——某个 kernel 可能只支持特定数据类型、batch 形状或量化格式，不支持的组合只能走更模块化的路径。
    激活量化又带来一个选择：可以在 dispatch 前量化、从而少传字节，也可以在更高精度下 dispatch、到专家计算前再量化。前者省带宽，但把转换工作提前了。
    一条关键建议：把路由、permutation、专家 GEMM、combine 分开测量。一个合并的 MoE 计时器无法指出慢的是哪个阶段。

四、权重驻留与运行时内存：三个不同的参数量
MoE 部署涉及三个不同的参数计数：
    · 总参数描述 checkpoint
    · 激活参数描述单个 token 的执行路径
    · 驻留参数描述当前对服务系统可用的权重
    这三个数不必相等。一个 token 触碰一个小专家子集，下一个 token 可能选另一个子集。
完全驻留的部署把每个可选专家都放在 GPU 上，同时还要存注意力、嵌入、归一化和输出权重——稀疏路由不会移除这些权重中的任何一个。
    算一下：Qwen3-30B-A3B 的 305 亿参数，每个两字节，光权重就要约 61GB（十进制 56.8GB）。这还只是权重下界，部署还需要临时激活和通信缓冲区，内存分配器会预留额外空间，KV cache 要存活跃序列的注意力状态——这些都不在 61GB 这个估算里。
    权重量化让每个参数占更少字节，分片把权重分散到多张 GPU，但两者都不改变 checkpoint 包含多少参数。稀疏激活减少专家计算，但不减少总权重存储。
    专家卸载把部分专家放在 CPU 内存里，路由选中它时再把权重传到 GPU——省了 GPU 内存，代价是多一条更慢的传输路径。一个缺席的专家可能在权重搬运期间卡住解码。缓存能帮上忙（当同一批专家被反复使用时），预取只在未来选择可预测时有用。

五、专家并行下的 dispatch 与 combine
    专家并行把不同专家分配给不同 GPU。四个专家两张卡：GPU A 拥有 E1 和 E2，GPU B 拥有 E3 和 E4。一个 token 从 GPU A 开始并选中了 E1 和 E3：E1 的 assignment 留在 A，E3 的必须传到 B。
    网络记录包含 token 向量和路由元数据。元数据标识 token、目标专家、源 GPU 和路由权重——目标端需要这些字段才能正确返回结果。每张 GPU 把本地和收到的 assignment 按专家分组，为每个活跃的本地专家执行一个矩阵，然后远程结果回到源 GPU，源 GPU 用保存的标识恢复 token 顺序、施加路由权重、把匹配的贡献相加。
    GPU 多了之后，每张卡可能向多个对端发送 assignment，产生 all-to-all 通信模式。专家权重通常留在被分配的 GPU 上——网络搬运的是 token 激活和元数据，不是专家权重。
    每一层 MoE 都重复这个交换。一个很小的 dispatch 延迟会在整个模型上累加。 有独立计算可用时，重叠能藏掉一部分延迟。DeepEP 为大 batch 和小 batch 提供分开的通信路径：吞吐路径针对更大的传输，低延迟路径针对 decode 步骤（那里启动时间更要紧）。

六、网络拓扑与专家放置
    不是每条 GPU 链路成本相同。同一台服务器内的 GPU 可能走 NVLink 或 NVSwitch，跨服务器的可能走 InfiniBand 或 Ethernet。跨服务器传输通常比服务器内贵。
    专家放置决定每张 GPU 存哪些专家，而这个选择决定了路由有多频繁地跨过更慢的链路。常见布局之一是把频繁的专家流量留在 NVLink 域内，另一种是把层分散到多台服务器——最佳边界取决于模型和集群。
    放置改变的是物理目的地，不改变路由器输出。一个被频繁选中的专家可以被移得离它的 token 来源更近。运行时也可以为一个逻辑专家创建物理副本。
    注意区分：路由约束不一样，因为它限制模型的选择。DeepSeek-V3 用节点受限路由，每个 token 只能到达有限数量节点上的专家——那条规则属于被训练出来的架构。
    放置需要路由轨迹和拓扑测量。路由轨迹显示哪些专家收到工作，拓扑测量显示每个目的地的成本。光靠专家热度无法捕捉链路成本。 把热门专家放在一起可能减少网络流量，也可能压垮一台服务器；分散它们能平衡计算，但可能增加跨服务器流量。复制只在有空闲 GPU 内存时才有用。
    按通信域分别测量字节数和时间——一个全集群的流量计数器无法区分便宜的节点内移动和昂贵的跨节点移动。

七、三种并行布局
三种并行布局划分的是不同种类的工作：
    · 张量并行把一次矩阵操作拆到多张 GPU 上，每张算一部分结果，然后交换部分结果来完成这一层
    · 专家并行分配整个专家或专家分片，token assignment 移向被选中的专家，它的流量取决于路由和放置
    · 数据并行把不同请求分给不同副本
    真实部署会组合这些布局：注意力层和专家层可以用不同的 GPU 组。举个具体的：张量并行度 2、数据并行度 4，注意力就在 4 个组里各用 2 张卡运行，而专家层可以把全部 8 张卡当成一个专家并行组。
    vLLM 的专家并行部署指南记录了这个混合做法：开启专家并行后，EP 组大小等于张量并行度乘以数据并行度；当 TP 大于 1 时，注意力在每个数据并行组内使用张量并行。
    三种布局付的代价不同：张量并行在每次矩阵操作内部通信，专家并行搬运路由后的激活，数据并行消耗复制组件的内存。低并发会让专家并行的传输效率变差，弱的互联也会产生同样结果，张量并行则在集合通信占主导时吃力。

八、负载不均与 rank 级尾延迟
    路由很少把工作分得完美。假设一个专家收到一半的 assignment，它所在的那张 GPU 就得处理一个比其他卡大得多的矩阵。
其他 GPU 可能早早做完然后等待。这一层要等每个必需的贡献都返回才算完成，所以最慢的那个参与 GPU 决定了整个步骤的延迟。
    要区分两种不均：专家不均发生在单个模型副本内部，请求不均发生在接受不同工作负载的副本之间——它们需要不同的测量和修复方式。
    测量上要记录每个服务步骤的 assignment 计数，以及 dispatch 时间、专家执行时间、combine 时间、GPU 空闲时间。这些数据能显示是某个专家还是某条链路定了尾部。
    放置可以把经常被一起选中的专家分开，一个热门专家可以移到不那么忙的 GPU 上——这些改动不改变路由器的决定。
复制为一个逻辑专家创建多个物理副本：路由器选的还是同一个逻辑专家，运行时把它的 assignment 发给可用的副本。代价是复制消耗 GPU 内存、留给 KV cache 的空间变少，移动专家也要消耗带宽，而且一段短暂的流量尖峰可能在再平衡完成前就结束了。
    平均利用率解释不了 MoE 的尾延迟。要逐步骤、逐 GPU 测量。

九、哪些优化是安全的，哪些会改数值
MoE 优化分两组，这个区分很重要：
    只改变执行的：融合、grouped GEMM、放置、通信重叠。它们保留逻辑上的专家选择，改变运行时怎么干活（仍可能出现小的浮点差异）。
    会改变数值或被选计算的：量化改变存储的权重或传输的激活，减少内存和网络流量，但引入数值误差，所以质量必须在目标工作负载上测。降低 top-k 改变被执行的专家集合，它从加权和里移除了专家贡献，重新归一化剩下的权重又改变一次结果。
    举一组具体数字（来自 Training-Free Halving of Activated Experts 这篇论文）：在 Qwen3.6-35B-A3B 上，按标准做法把八个专家减到四个，掉了 4.65 个 MMLU 点；改用更大的参考集做归一化质量后，实测损失降到 0.35 个点。同一方法在 Qwen3.5-397B-A17B 上把十个专家减到五个，掉了 0.55 个点。论文作者还发现，困惑度和任务准确率偏好不同的设置。
一句话区分：专家并行改变被选中计算在哪里跑，降低 top-k 改变哪些计算跑。它们不是等价的优化。
    容量限制也要小心。有些训练系统会限制分配给一个专家的 token 数，特定运行时可能也实现了推理侧限制。MoE 推理不会在专家繁忙时自动丢弃 token——容量或丢弃规则属于特定模型或运行时，用之前先查实现。

十、基准怎么设计
    一个有用的基准每次只改变一个服务决策。保持 checkpoint、精度、prompt、输出限制和请求到达率不变，然后只改并行布局或 kernel 路径。
    从能装下模型的最小受支持布局开始，接着加一个同服务器布局，只有在量过这些基线之后才去测跨服务器的专家并行。
要同时测低并发和高并发，用短 prompt 和长 prompt——这能把小的 decode 矩阵和 prompt 密集的 prefill 工作区分开。
记录 prefill 与输出吞吐、首 token 时间、每输出 token 时间、token 间延迟、p95 请求延迟。尾部测量能暴露由某一张热点 GPU 造成的延迟。
    到了 GPU 层，要按网络域记录字节数、assignment 计数、专家时间、空闲时间；把路由、permutation、dispatch、GEMM、combine、unpermutation 拆开；还要记录驻留权重和剩余 KV 容量。
    每个阶段的解读：dispatch 时间高 → 指向拓扑、局部性或消息大小；某张 GPU 持续慢 → 指向路由偏斜或放置不佳；内存占用高但专家计算低 → 是权重容量问题，KV cache 剩余空间小能印证这个判断。

十一、工程检查清单
    Qwen3-30B-A3B 有 305 亿总参数、33 亿激活参数。总数决定权重存储，激活数估算每个 token 的执行路径。
一个 MoE 服务步骤包含：路由、token permutation、dispatch、分组专家计算、combine、unpermutation。多 GPU 部署额外增加通信域、专家放置和 rank 级负载不均。
    验证顺序建议这样：先确认权重和 KV cache 容量 → 再剖析 MoE 路径的每个阶段 → 然后测量 assignment 偏斜和按通信域分的字节数 → 最后把放置、kernel、量化或 top-k 的改动对照同一条请求轨迹比较。
放置和 kernel 改动针对运行时开销，量化改变数值，top-k 改变被执行的专家集合。把这些实验分开，性能收益和模型质量变化才能归因。
    最后一句总结得很好：MoE 推理一旦把三个量分开看就变得容易诊断——部署必须存储模型权重、执行被选中的专家、搬运路由后的激活。在改动服务布局之前，先把这三个量各自量一遍。
链接

原文（Avi Chawla）：https://x.com/_avichawla/article/2100876555409039605