@_avichawla: https://x.com/_avichawla/status/2100876555409039605
摘要
这篇文章解释了Mixture-of-Experts (MoE) 推理的工程方面,详细介绍了令牌路由、专家批处理、GPU分配和性能权衡,以实现高效的服务。
查看缓存全文
缓存时间: 2026/09/19 06:53
MoE 推理工程详解
你需要了解的一切:MoE 服务引擎如何路由令牌、批量专家计算、跨 GPU 分布权重,以及如何管理通信和负载不均衡。本文涵盖专家并行、分组 GEMM、拓扑感知放置、内存需求、推理优化,以及决定延迟与吞吐量的权衡。
稠密 Transformer 对所有令牌应用相同的前馈网络。批处理会改变输入矩阵维度,但不会改变执行哪些权重。
MoE 层用多个专家替换该前馈网络。路由器为每个令牌对这些专家进行评分。只有被选中的专家会为该令牌执行计算。
这减少了每个令牌执行的专家计算量。但由于无法确定下一个令牌需要哪些权重,服务系统必须为每个可选择的专家做好准备。
Qwen3-30B-A3B 模型卡显示其总参数量为 305 亿,激活参数量为 33 亿。每个令牌从 128 个路由专家中选择 8 个。
服务器仍需提供完整模型。它需要注意力权重、嵌入层、专家权重、临时缓冲区,以及不断增长的键值缓存。33 亿这个数字大致描述了活跃计算量,并不反映部署的内存占用量或专家权重大小。
激活参数估算单个令牌的执行路径。驻留参数决定部署所需的权重内存。
本文将跟踪令牌通过 MoE 服务路径的全过程,剖析路由器如何选择专家、运行时如何将令牌分组为专家批次、本地内核如何执行计算,以及激活值如何在 GPU 间移动。
随后将探讨专家放置、负载不均衡、容量限制、量化,以及揭示性能瓶颈是计算能力、内存带宽还是互联通信的测量指标。
MoE 层结构与令牌路由
Transformer 层先执行注意力计算再执行前馈计算。注意力机制混合跨令牌位置的信息。前馈网络则独立变换每个令牌位置。
MoE 层用多个专家替换一个稠密前馈网络。每个专家都是独立的前馈网络。
注意力仍然处理所有令牌。路由器仅控制专家分支。因此稀疏专家激活不会使注意力路径稀疏。
考虑一个包含四个专家的示例层。其路由器为单个令牌向量对所有专家评分。该层选择得分最高的两个专家。
这两个专家独立处理相同的令牌向量。层随后组合它们的输出。特定模型的路由权重决定每个专家的贡献。
加权专家输出可表示为:
y = Σ_{e∈S(x)} w_e(x) · E_e(x)
其中:
- x 是令牌的输入向量。
- S(x) 是其选定的专家集合。
- E_e 是专家 e,w_e(x) 是其路由权重。
- 输出向量为 y。
求和仅覆盖选定专家。每个专家变换相同的输入向量。其路由权重在加法前缩放该专家的贡献。
路由器选择若干专家函数。层加权求和其输出。不同架构对这些权重使用不同的归一化规则。
令牌到专家的路由发生在每个 MoE 层内部。这不同于应用级模型路由(即为整个请求选择 LLM)。
该示例层为清晰起见采用 top-two 路由。Qwen3-30B-A3B 每个令牌选择 128 个专家中的 8 个。其模型卡还报告了 48 层。
部分架构包含共享专家。无论路由器评分如何,这些专家都会处理所有令牌。DeepSeekMoE 在路由专家之外使用了共享专家隔离。
共享专家为每个令牌执行。路由专家有条件执行。只有设计包含共享专家的模型使用这种划分。
不要假设每个模型都有共享专家。请先检查其架构和服务实现。
路由器改变了每个 MoE 层内部的前馈计算。批处理推理随后必须调度具有不同目标专家和矩阵大小的令牌-专家分配。
批处理如何转换为专家特定矩阵
路由器为每个令牌做出决策。GPU 无法高效地一次运行一个微小的专家操作。因此,服务引擎将路由决策转换为更大的专家特定矩阵。
考虑四个令牌进入一个采用 top-two 路由的四专家层。路由器做出如下选择:
- 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)。
运行时现在有八个分配,而非四个。每个分配包含三部分:令牌向量、选定专家和路由权重。
运行时按专家分组这些分配。E1 接收 T1、T2 和 T3。E2 接收 T3 和 T4。E3 接收 T1 和 T2。E4 接收 T4。这些组成为具有三行、两行、两行和一行的矩阵。
每个专家处理自己的矩阵。运行时在每行旁保留原始令牌 ID。该 ID 告诉它每个结果必须返回何处。
- T1 从 E1 接收一个结果,从 E3 接收另一个结果。
- 运行时将它们分别乘以 0.7 和 0.3。
- 然后将两者贡献相加以产生 T1 的最终专家输出。
- 相同的组合步骤适用于每个令牌。
此分组步骤称为 分发 (dispatch)。返回步骤称为 合并 (combine)。两者都在一个 GPU 上发生。多个 GPU 则在网络传输间添加。
专家批次计数分配,而非唯一源令牌。采用 top-two 路由时,每个令牌在专家矩阵中贡献两行。
预填充在一次处理中处理许多提示令牌。因此,专家可能接收包含许多行的矩阵。更大的矩阵通常能更高效地使用 GPU。
解码为每个活跃请求添加一个新令牌。低并发可能导致专家只有一两行为工作。为如此少的工作启动矩阵内核会浪费 GPU 容量。
更高的并发在每个步骤中创建更多分配。分组通用矩阵乘法 (grouped GEMM) 在一次启动中运行多个专家矩阵。即使行数不同,它也能减少启动开销。
某些引擎将专家矩阵填充到固定大小。固定形状使内核调度更容易。代价是在填充的、不包含令牌的行上进行计算。
预填充和解码没有固定的性能特征。提示长度和请求数量改变其专家矩阵大小。隐藏宽度和硬件决定这些矩阵运行的效率。
分组 GEMM 将现有专家工作打包到更少的启动中。它无法为未收到令牌的专家创造工作。
总之,路由创建分配。分发将其分组为专家矩阵。合并将结果返回其原始令牌。下一节将跟踪这些矩阵在一个 GPU 上的流转。
本地 MoE 执行流水线
MoE 层执行的操作远不止专家矩阵乘法。实际上,它必须选择专家、重排令牌行、执行专家,并恢复令牌顺序。每个阶段都可能消耗可观的时间。
路由器首先为每个合格专家产生一个分数。top-k 操作保留选定的专家索引及其权重。运行时随后重排令牌行,使每个专家接收一个连续矩阵。
此重排称为 置换 (permutation)。它读取令牌向量并按专家顺序写入。它还记录一个用于合并步骤的逆映射。小的解码批次可能花费与乘法相当的时间用于移动行。
分组 GEMM 在一次内核启动中执行多个专家矩阵。这些矩阵可能具有不同的行数。分组减少了启动次数,而不改变其内容。
专家随后应用其激活函数和输出投影。运行时使用逆映射恢复令牌顺序。它应用路由权重并将匹配令牌 ID 的贡献相加。
分组 GEMM 不改变分配数量。它以更少的启动执行现有的专家批次。
内核融合连接了原本需要单独启动的操作。融合路径可能避免将中间激活写入 GPU 内存。因此可以减少启动开销和内存流量。
融合支持是有条件的。内核可能仅支持特定数据类型、批处理形状或量化格式。不支持的组合必须使用更模块化的路径。
激活量化提供了另一个选择。运行时可以在分发前量化并发送更少的字节。也可以在高精度下分发,并在专家计算前量化。第一种选择节省带宽但增加了早期的转换工作。
解码通常为每个专家提供一个小矩阵。因此,权重读取、行移动和内核启动可能占主导地位。预填充通常提供更多行,这使得矩阵效率更为重要。
融合路径移除了操作间受支持的边界。它不增加专家批次大小,也不改变路由器选择或分配计数。
单独测量路由、置换、专家 GEMM 和合并。单一的 MoE 计时器无法识别慢阶段。
总之,专家 GEMM 只是本地执行的一部分。小批次通常暴露移动和启动的成本。
模型权重驻留与运行时内存
MoE 部署使用三种不同的参数计数。总参数描述检查点。激活参数描述单个令牌的执行路径。驻留参数描述当前服务系统可用的权重。
这些计数不必匹配。一个令牌接触一小部分专家子集。下一个令牌可以选择另一个子集。
完全驻留的部署在 GPU 上保留每个可选择的专家。它还存储注意力、嵌入层、归一化和输出权重。稀疏路由不会移除这些权重中的任何一个。
以两字节存储 Qwen3-30B-A3B 的 305 亿参数仅需约 61 GB 或 56.8 GB,这仅是权重本身。
以下表达式给出了权重存储的下限:
- B(权重) 是存储权重的字节数。
- P 是总参数计数。
- B(已存储) 是每个存储参数使用的字节数。
该表达式将参数计数乘以每个参数的字节数。对于 Qwen 的数据,得到 610 亿字节。十进制 GB 将此数除以 10 亿。该结果仅包含权重。
部署还需要临时激活和通信缓冲区。内存分配器预留额外空间。键值缓存存储活跃序列的注意力状态。这些都不在 61 GB 估算中。
永远不要在此估算中用 33 亿替换 305 亿。激活参数不决定检查点存储的权重字节数。
权重量化以更少的字节存储每个参数。分片将权重跨 GPU 划分。两者都不改变检查点包含的参数数量。
稀疏激活减少了专家计算,但不减少总权重存储。尽管活跃浮点运算量适中,模型可能仍需要权重分片。
专家卸载将部分专家保留在 CPU 内存中。当路由选择该专家时,运行时将其传输到 GPU。这节省了 GPU 内存,但增加了较慢的传输路径。
缺失的专家在权重移动时可能暂停解码。缓存有助于重复使用相同专家的情况。预取仅在可预测未来选择时才有帮助。
这些数字不隐含固定的 GPU 数量。精度、分片、预留内存和 KV 容量会改变答案。
总之,激活参数估算计算量。驻留参数决定权重内存。分片通过分散权重解决容量问题,但路由的激活可能随后跨 GPU。
专家并行分发与合并
专家并行将不同专家分配给不同 GPU。考虑两个 GPU 上的四个专家。GPU A 拥有 E1 和 E2。GPU B 拥有 E3 和 E4。
一个令牌起始于 GPU A 并选择 E1 和 E3。其 E1 分配留在 GPU A 上。其 E3 分配必须传输到 GPU B。
网络记录包含令牌向量和路由元数据。元数据标识令牌、目标专家、源 GPU 和路由权重。目标需要这些字段以正确返回结果。
每个 GPU 按专家分组本地和接收的分配。它为每个活跃的本地专家执行一个矩阵。远程结果随后传回其源 GPU。
源 GPU 使用保存的标识符恢复令牌顺序。它应用每个路由权重并求和匹配的贡献。这完成了合并步骤。
对于多个 GPU,每个 GPU 可能向多个对等端发送分配。这产生了一种全对全通信模式。计算完成后,合并将专家结果发送回去。
专家权重通常保留在其分配的 GPU 上。网络传输令牌激活和元数据,而非专家权重。填充和临时缓冲区可能增加传输的字节数。
以下上限估算分发激活载荷:
- B(分发) 是分发的激活载荷。
- T 是进入 MoE 层的令牌数。
- K 是每个令牌选择的专家数。
- H 是隐藏宽度。
- b 是每个激活值的字节数。
该乘积为每个分配计算一个完整的隐藏向量。在考虑局部性之前,这是一个上限。留在单个 GPU 上的分配不消耗网络带宽。
实际流量取决于有多少分配是远程的。元数据和填充增加字节数。专家复制可以使部分分配本地化。合并在返回方向增加流量。
该估算仅涵盖激活载荷。它不包括协议开销,且无法在没有拓扑和消息大小测量的情况下预测延迟。
每个 MoE 层重复此交换。微小的分发延迟可能在整个模型中累积。当独立计算可用时,重叠可隐藏部分延迟。
DeepEP 为大批次和小批次提供单独的通信路径。其高吞吐量路径针对较大传输。其低延迟路径针对解码步骤(启动时间更重要)。
内核带宽不是端到端的服务速度。完整请求还包括注意力、调度、采样、缓存工作和每个模型层。
总之,专家并行保持权重就位并移动分配。它增加了分布式权重容量,但添加了重复的激活流量。
网络拓扑与专家放置
并非每个 GPU 链路具有相同成本。服务器内的 GPU 可能使用 NVLink 或 NVSwitch。不同服务器的 GPU 可能使用 InfiniBand 或以太网。
跨服务器传输通常比服务器内传输成本更高。专家放置决定每个专家存储在哪个 GPU 上。该选择决定了路由跨越较慢链路的频率。
一种常见布局将频繁的专家流量保留在 NVLink 域内。另一种并行布局将层分布到不同服务器上。最佳边界取决于模型和集群。
放置改变物理目标,而不改变路由器输出。频繁选择的专家可以移动到更靠近其令牌源的位置。运行时还可以创建一个逻辑专家的物理副本。
路由约束是不同的,因为它们限制了模型的选择。DeepSeek-V3 使用节点限制路由。每个令牌只能到达有限数量节点上的专家。该规则属于训练后的架构。
节点限制路由是该模型训练后架构的一部分。训练后添加类似限制可能会改变选定专家和模型质量。
放置需要路由跟踪和拓扑测量。路由跟踪显示哪些专家接收工作。拓扑测量显示每个目的地的成本。
相似文章
先共享,再路由剩余:一种面向Token自适应MoE计算的统一框架
本文提出UniF-MoE,一种用于Token自适应混合专家计算的统一框架,该框架首先共享专家间的可复用计算,然后路由剩余的残余需求,从而在DomainBed和GLUE基准上提升性能,同时减少激活计算量、延迟和内存占用。
Transformer 中的专家混合模型 (MoEs)
Hugging Face 的博客文章,介绍 Transformer 中的专家混合模型 (MoEs) 架构,涵盖从密集模型到稀疏模型的转变、权重加载优化、专家并行计算以及基于 MoE 的语言模型训练技术。
@jbhuang0604: Huge! It’s amazing how often Noam’s papers end up at the center of the field. In many tutorial videos I’ve made, they’v…
The article provides a detailed explanation of Mixture of Experts (MoE) in transformers, covering routing, load balancing, and recent innovations like fine-grained experts. It also highlights the significance of Noam Shazeer's research contributions and his move from Google to OpenAI.
@yibie: https://x.com/yibie/status/2101491585741394047
本文详细解释了MoE(混合专家)推理工程,纠正了关于激活参数与部署成本的误解,并深入探讨了路由器选择、运行时分组、GPU执行、内存管理和专家并行等技术细节。
多层级MoE缓存
讨论MoE模型的多层级缓存策略,通过将频繁激活的专家保留在GPU上来提升推理速度,参考了PowerInfer和llama.cpp分支等现有实现。