MegaScale-Infer: Serving Mixture-of-Experts at Scale with Disaggregated Expert Parallelism

作者和机构： Ruidong Zhu1,2,◦,∗, Ziheng Jiang1,◦, Chao Jin1,2,◦,∗, Peng Wu1, Cesar A. Stuardo1, Dongyang Wang1, Xinlei Zhang1, Huaping Zhou1, Haoran Wei1, Yang Cheng1, Jianzhe Xiao1, Xinyi Zhang1, Lingjun Liu1, Haibin Lin1, Li-Wen Chang1, Jianxi Ye1, Xiao Yu1, Xuanzhe Liu2,†, Xin Jin2,†, Xin Liu1,†
1ByteDance Seed, 2Peking University ◦Equal Contribution, ∗Work done at ByteDance Seed, †Corresponding authors

主要贡献

MegaScale-Infer 是一个高效且成本有效的系统，用于服务大规模混合专家（MoE）模型。核心问题是：MoE的稀疏激活架构在推理过程中将前馈网络（FFN）从计算密集型转变为内存密集型，导致GPU利用率大幅降低和运营成本增加。具体而言，LLM推理的解码阶段主导过程，注意力模块因访问所有先前令牌的中间状态（键值缓存）而GPU利用率低，而FFN模块在令牌数量增加时利用率高；但MoE的稀疏性导致每个专家分配的令牌减少，FFN利用率降低，无法充分利用GPU计算能力。研究目标是：通过解聚合注意力与FFN模块，实现独立扩展、定制并行策略和异构部署，以提高GPU利用率并降低成本。创新点包括：引入解聚合专家并行（disaggregated expert parallelism），允许注意力使用数据并行复制，FFN使用专家并行扩展；设计乒乓流水线并行（ping-pong pipeline parallelism），将请求批次分割为微批次，在注意力与FFN间穿梭以隐藏通信开销；开发高性能M2N通信库，消除不必要的GPU到CPU数据复制、组初始化开销和GPU同步。实验结果显示，MegaScale-Infer在每GPU吞吐量上比最先进解决方案高1.90倍，并在异构集群中实现1.7倍的每单位成本吞吐量提升，已在公司推理服务中部署，降低服务成本1.5–2.0倍。

背景知识/关键Observation/设计原则

LLM推理特性。 Transformer-based LLM通常由多个层组成，每层包含一个注意力模块和一个FFN模块。与传统DNN推理不同，LLM推理遵循自回归模式。它以输入令牌序列（称为提示）作为输入，经过注意力与FFN模块的多次迭代生成输出令牌。在预填充阶段或第一次迭代中，模型计算提示中每对令牌间的注意力以产生第一个输出令牌。在此迭代中，为每个令牌存储中间表示或键值（KV）缓存。这些缓存表示随后用于计算注意力。在后续解码迭代中，LLM通过计算新生成令牌与所有先前令牌间的注意力来生成下一个令牌。自回归生成模式使注意力模块在预填充阶段为计算密集型，在解码阶段为内存密集型。即使使用请求批处理【[22]，Nvidia triton inference server，2025】，一种在高效LLM服务中广泛使用的优化，解码阶段的注意力仍保持相同的内存访问强度。这是因为每个请求有自己的输入和先前生成令牌的KV缓存，这些缓存彼此不同。在解码迭代中，每个请求必须访问其各自的KV缓存。相反，FFN的计算仅需从GPU内存加载相应模型权重到SRAM，这些权重可跨所有请求的令牌共享。因此，如图1(a)所示，批处理仅对FFN有效，以重用模型参数并提高GPU利用率。

大规模LLM服务。 缩放定律【[50]，Scaling laws for neural language models，arXiv:2001.08361，2020】强调模型大小作为模型能力关键决定因素的重要性。为了实现最先进的模型能力，许多努力【[35]，Deepseek-v2: A strong, economical, and efficient mixture-of-experts language model，arXiv:2405.04434，2024】已投入将LLM扩展到数千亿参数。由于模型大小大，服务这些模型需要算法和系统优化。从算法角度，混合专家（MoE）模型在提升LLM性能方面显示出显著潜力，具有亚线性缩放计算复杂度，并在大规模模型实现中流行【[34]，Deepseek-v2: A strong, economical, and efficient mixture-of-experts language model，arXiv:2405.04434，2024；[35]，Deepseek-v2: A strong, economical, and efficient mixture-of-experts language model，arXiv:2405.04434，2024；[36]，Deepseek-v3 technical report，arXiv:2412.19437，2024；[52]，Gshard: Scaling giant models with conditional computation and automatic sharding，arXiv:2006.16668，2020】。本工作聚焦于Transformer-based LLM中的MoE。MoE模型用MoE层替换前馈网络（FFN）层，该层由多个作为专家的FFN组成，如图2(a)所示。MoE层内的门控网络基于每个令牌的嵌入向量与门控网络的可训练参数的矩阵乘法，将输入令牌路由到这些专家的子集，即top-k专家。MoE层的最终输出是所选专家输出的加权和。MoE的稀疏性质允许通过增加专家数量来缩放模型大小，而不线性提高计算成本。例如，Mixtral 8x22B【[70]，Mixtral 8x22b，2024】有约141B参数，但每个令牌的活跃参数仅约39B，使用top-2专家选择。从系统角度，由于单个设备的内存和计算容量有限，服务大规模LLM需要分布式方法。模型并行将模型参数分布到多个设备以提高效率。张量并行（TP）【[65]，Megatron-lm: Training multi-billion parameter language models using model parallelism，arXiv:1909.08053，2019】分割计算密集型操作如矩阵乘法以加速计算，但引入大量通信开销。因此，张量并行通常局限于单个节点的多GPU，其中节点内NVLink带宽通常远高于节点间网络带宽。流水线并行（PP）【[45]，Gpipe: Efficient training of giant neural networks using pipeline parallelism，Neural Information Processing Systems，2019】将模型层分成阶段，每个阶段在设备上运行以形成流水线。此方法由于阶段间通信略微增加推理时间，但随每个额外阶段线性缩放服务吞吐量。专为MoE设计的并行策略称为专家并行（EP）【[62]，Deepspeed-moe: Advancing mixture-of-experts inference and training to power next-generation ai scale，arXiv:2201.05596，2022】，也被广泛应用于MoE服务。如图2(b)所示，每个设备仅包含一些专家。因此，MoE层的正向传播需要两次all-to-all通信：一次将输入令牌发送到门控网络选择的专家，另一次发送回处理后的令牌。在EP中，每个专家的计算涉及完整矩阵乘法，与TP相比更利于GPU计算，其中单个矩阵乘法跨多个GPU分割。EP的潜在问题是专家间负载不均衡，以及top-k专家数量增加时通信量增加。因此，TP或EP是否更利于FFN高度依赖MoE模型结构和实时工作负载。

大规模MoE服务中的问题。 如§2.1所示，解码阶段的内存密集型注意力操作导致低GPU利用率，而FFN可通过请求批处理实现高效率。然而，MoE的稀疏性改变了这种情况。虽然稀疏性启用亚线性计算复杂度缩放，但显著降低推理效率。图1(b)展示了影响的示意图。给定解码阶段的请求批次，每个专家仅处理一部分，导致FFN的批次大小更小，从而降低GPU利用率。以Mixtral 8x22B为例。假设使用NVIDIA A100-SXM-80GB GPU，其计算能力为312 TFLOPS，内存带宽为2 TB/s，以bfloat16数据类型服务此模型。b × h 到 h × n GEMM（通用矩阵到矩阵乘法）所需的浮点操作是2bhn，其中b和h分别表示解码批次大小和模型隐藏维度大小。此GEMM需访问的参数数量是hn，对于bfloat16的数据量是2hn。令GPU的浮点计算能力为F，内存带宽为B。根据屋顶线模型【[74]，Roofline: an insightful visual performance model for multicore architectures，Communications of the ACM，2009】，GPU需要2bhn/F ≥ 2hn/B，即b ≥ F/B，以充分利用其矩阵乘法能力。对于A100 GPU，批次大小至少需156令牌（312 TFLOPS / 2 TB/s）。然而，给定批次大小156，每个专家分配的平均解码令牌数是156 × topk / #expert = 156 × 2 / 8 = 39，FFN模块的理论模型FLOPS利用率（MFU）为2/8 = 25%。正式地，稠密模型的批次大小与FFN的GPU利用率理论关系是util = min(B/b, 1)，但对于MoE，是util = min(topk / #expert * B F / b, 1)。理想情况下，可通过增加批次大小提升推理效率，但实践中许多因素限制批次大小。例如，更大批次大小可能损害在线模型服务的低延迟要求。此外，KV缓存的GPU内存约束限制批次大小增长。特别是对于大规模MoE，GPU内存更稀缺，导致最大批次大小更小。虽然用更多GPU扩大模型并行可能允许更大批次大小，但也引入更多通信开销。

机会与挑战。 为解决MoE稀疏性导致的低效，我们发现解聚合注意力模块与FFN模块自然提供两个关键优势：独立缩放。这允许我们独立缩放带注意力模块的服务实例，为每个FFN模块聚合解码请求。这使FFN模块成为计算密集型并实现最佳GPU利用率。异构部署。解聚合架构自然分离注意力与FFN模块的部署，允许为每个使用最具成本效益的GPU。它还开启使用专用硬件和软件分别加速注意力和FFN计算的机会。实现注意力与FFN高效解聚合有两个主要技术挑战。首先，由于每个令牌必须重复且顺序通过注意力和FFN模块，解聚合这些组件引入空闲期。具体而言，注意力模块在FFN模块计算时保持空闲，反之亦然。两个模块在等待网络传输输出时也可能空闲。因此，必须在注意力和FFN模块间建立乒乓流水线以确保连续利用。而且，此流水线应与每个模块的模型并行策略精心共同设计，以最大化GPU利用率，同时遵守延迟要求。其次，解聚合启用的独立缩放需要M2N和N2M通信在M个注意力GPU与N个专家GPU间，取代每个MoE层中传统的All-to-All通信。然而，直接利用现有库的点对点通信原语导致显著性能下降，突显需要专为M2N模式定制的专用通信库。

方法细节

MegaScale-Infer概述。 在本工作中，我们提出MegaScale-Infer，一个设计用于高效服务大规模基于MoE的LLM的系统。遵循先前工作【[60]，Splitwise: Efficient generative llm inference using phase splitting，ACM/IEEE ISCA，2024；[82]，DistServe: Disaggregating prefill and decoding for goodput-optimized large language model serving，USENIX OSDI，2024】，MegaScale-Infer将预填充和解码解耦到单独集群，以消除它们的干扰并满足各自的延迟要求。本文聚焦于解码阶段，旨在解决其低效问题。图3展示了服务单个模型副本的MegaScale-Infer运行时实例的整体架构。通过将注意力和FFN模块解聚合到分别的注意力节点和专家节点，MegaScale-Infer允许注意力和FFN的独立缩放和异构部署，显著提升系统效率并降低服务成本。解聚合专家并行。为了促进大规模MoE服务，MegaScale-Infer采用一种称为解聚合专家并行的混合并行策略。每个专家节点通常由单个物理服务器内的1-8个GPU组成，并存储一个专家的参数。所有专家节点共同形成专家并行组。注意力模块的参数（例如QKV和输出投影的权重矩阵）在每个注意力节点上复制，其中也存储键值缓存。张量并行在每个注意力/专家节点内采用，以利用GPU间的高带宽连接（例如NVLink）。MegaScale-Infer还设计了专为解聚合架构定制的乒乓流水线并行策略，将请求的微批次输入到注意力和专家节点，以在通信或等待其他节点结果时保持它们忙碌。MegaScale-Infer基于专为解聚合专家并行设计的性能模型确定详细部署计划。高性能M2N通信。MegaScale-Infer采用定制M2N通信库，在每个注意力节点与专家节点对间传输中间输出。为实现高效稳定的数据传输，该库移除不必要的GPU到CPU数据复制、组初始化开销和GPU同步。它还提出针对此场景的流量导向优化。

乒乓流水线并行。 由于我们将FFN模块从注意力模块解耦，使用单个请求批次将导致注意力节点和专家节点在另一模块忙碌时出现空闲时间。GPU在节点间通信期间也保持空闲。为解决此问题，如图4所示，我们将请求批次分割为m个微批次，在注意力节点与专家节点间创建乒乓流水线。这些节点执行微批次的正向传播，并在每个MoE层中交换中间结果两次。此设置允许正向计算覆盖通信开销，从而实现更高GPU利用率。令Ta和Te分别表示微批次在注意力节点和专家节点上的计算时间。我们定义Tf = max{Ta, Te}为其最大值。Tc表示从注意力节点到专家节点的通信时间以及反之，由于双向通信共享相同网络配置。我们的目标是重叠通信与计算，保持GPU充分利用。实现此目标的必要条件是：
约束1旨在最小化跨MoE层的计算依赖引起的GPU空闲时间。约束2和约束3描述隐藏通信开销的方法。具体而言，单个微批次的通信时间必须短于注意力和专家的前向计算时间，且每个节点上全局批次的单个MoE层的前向时间必须足以覆盖单个微批次通过该层所需的时间。然后，我们可以使用公式m ≥ 2 × (1 + Tc/Tf)，其中0 < Tc/Tf < 1，获得所需的最小微批次数量。对于通信快速的部署（Tc < Tf），至少需要3个微批次。对于通信相对较慢的，至少需要4个微批次。令MoE层数为L。如图4所示，考虑注意力节点与专家节点间的不均衡计算，一个微批次的解码迭代延迟可估计为：
全局批次的总迭代延迟为：

部署计划搜索。 考虑乒乓流水线并行，MegaScale-Infer部署计划的搜索空间包括注意力节点（tpa）和专家节点（tpe）的张量并行大小、注意力节点数量（na）、微批次数量以及全局批次大小（B）。我们的目标是最小化每单位成本的吞吐量，同时遵守SLO约束。算法1展示了给定硬件设置和模型配置的搜索最优部署计划的伪代码。它枚举可行的tpa和tpe，受GPU内存容量限制。对于每对tpa和tpe，它根据约束1计算注意力节点数量，以尽可能平衡计算时间。然后，算法在具有不同微批次数量的部署计划间比较每单位成本的吞吐量。使用SIMULATE函数，它通过二分搜索确定满足SLO的最大全局批次大小，并获得最优计划。算法1的复杂度是O(M^2 N_m)，其中M是每服务器GPU限制，N_m是最大微批次数量。通常，M有四个选择（例如{1,2,4,8}）在现代集群中。我们将N_m设为4，因为分割成太多微批次会降低专家节点的GEMM效率，从而增加延迟。因此，搜索空间保持可管理。性能模拟。然后，我们深入MoE层分析Ta、Te和Tc的模拟。Ta包括两个GEMM：QKV Project和Attn Output，而Te包括另两个GEMM：FFN Input和FFN Output。它们的输入和参数形状如表2所示。注意力GEMM和FFN GEMM的算术强度分别为O(ba)和O(be)，关系为ba × m × na = be × m × E/K = B。注意力模块是内存密集型，因为它需要访问批次中所有令牌的KV缓存。令平均序列长度为s，KV缓存访问时间几乎与bas成比例。张量并行同步时间是O(bah(tpa − 1)/tpa)。因此，我们可以将Ta建模为k1 ba + k2，并类似地将Te建模为k3 be + k4，其中ki值可通过剖析和插值获得，如先前工作【[82]，DistServe: Disaggregating prefill and decoding for goodput-optimized large language model serving，USENIX OSDI，2024】。因此，na = (be E)/(ba K)可设为(k1 E)/(k3 K)以平衡Ta和Te。对于Tc，它等于发送和接收的最大时间。我们剖析网络带宽利用率与消息大小的关系以估计Tc。具体而言，
其中Wa和We分别表示注意力节点和专家节点上每个GPU的网络带宽。除了约束1、2和3，搜索过程中还有两个约束：
约束8表示bfloat16 KV缓存大小的GPU内存容量限制。吞吐量每单位成本是B / (T_total tpa na Cost_a + tpe E Cost_e)。

异构部署。 MegaScale-Infer支持注意力节点和专家节点的异构硬件设置。具体而言，我们为注意力节点使用每成本更高内存带宽和更大每成本内存容量的GPU，因为这些节点是内存密集型，大部分时间花在内存访问上，并需要大量存储KV缓存。类似地，对于计算密集型的专家节点，我们使用计算能力更具成本效益的GPU。表3列出了选定NVIDIA GPU的性能规格、价格和相应比率。我们枚举使用每种类型GPU作为注意力或专家节点硬件的场景，以确定最优部署计划。直观地，H20更适合注意力，由于其大内存容量和高每单位成本内存带宽。同时，L40S GPU对专家更具成本效益。异构部署还可通过利用每单位计算或带宽更低能耗的硬件来降低能耗。例如，H20和L40S GPU的最大功耗分别为500W和350W。在相同功耗下，L40S提供更高计算性能，而H20提供更高带宽。我们在§7.2中展示了异构部署在成本和能效上的改进。

高性能M2N通信动机。 在MoE推理中，令牌分发和聚合（即注意力与FFN模块间的通信）依赖点对点原语，因为目的地动态确定。为激励为令牌分发定制通信库的需要，我们首先突出现有解决方案NCCL【[8]，NCCL Optimized primitives for inter-GPU communication，2025】的局限性。具体而言，我们将NCCL与perftest【[20]，OFED Performance Tests，2025】比较，后者是一个网络微基准，旨在从简单CPU客户端角度测量延迟和吞吐量，便利支持GPU内存缓冲作为源和目的地。我们使用perftest作为基线，以建立可实现延迟的下界，以类似于MoE推理中令牌路由的方式动态分发数据。图5展示了当单个发送者向N中的每个接收者发送128K字节时观察到的延迟，其中|N| = {8,16,32}。基于此实验，我们得出以下观察：高额外开销。图5(a)展示了两种备选方案的中位延迟。虽然缩放趋势似乎遵循类似模式，但NCCL的延迟显著超过基线。在更高百分位的不稳定性。在图5(b)中突显的性能问题在更高百分位一致加剧。在99th百分位，基线仅经历轻微延迟增加，而NCCL显示显著激增，特别是缩放到32或更多接收者时。这些问题的根本原因是多方面的，源于NCCL中特定设计选择，不适合此特定用例。对于开销，我们首先注意NCCL网络需要中间复制【[11]，NCCL Data Transfer Between GPU and Proxy，2025】将数据从GPU内存传输到执行网络操作的CPU代理。虽然用户缓冲注册【[9]，NCCL User-buffer Registration，2025】等功能旨在减少这些复制，但未完全消除。其次，点对点组操作【[10]，NCCL Group Operations，2025】以最多8个操作的批次处理，这在接收者数量缩放时引起有害影响。第三，作为通用集体通信库，NCCL从通用组操作设置中产生开销，包括准备和启动N个发送操作批次、内部处理和验证等。虽然这些步骤对确保广泛适用性至关重要，但它们引入不必要的延迟，并可优化，尽管无法完全消除。对于稳定性，此问题更复杂，可能源于多个来源，包括OS、内存、网络和GPU热差异【[26]，The influence of operating systems on the performance of collective operations at extreme scale，IEEE International Conference on Cluster Computing，2006；[39]，Fail-slow at scale: Evidence of hardware performance faults in large production systems，USENIX Conference on File and Storage Technologies，2018；[43]，Characterizing the influence of system noise on large-scale applications by simulation，The International Conference for High Performance Computing, Networking, Storage, and Analysis，2010；[66]，Not all gpus are created equal: Characterizing variability in large-scale, accelerator-rich systems，The International Conference for High Performance Computing, Networking, Storage, and Analysis，2022；[69]，Vsensor: leveraging fixed-workload snippets of programs for performance variance detection，ACM PPoPP，2018；[78]，Gvarp: Detecting performance variance on large-scale heterogeneous systems，The International Conference for High Performance Computing, Networking, Storage, and Analysis，2024；[81]，Vapro: performance variance detection and diagnosis for production-run parallel applications，ACM PPoPP，2022】。先前研究突出常见不稳定性来源往往源于GPU同步操作和设备内存访问【[41]，Drgpu: A top-down profiler for gpu applications，ACM/SPEC International Conference on Performance Engineering，2023；[83]，Gpa: A gpu performance advisor based on instruction sampling，IEEE/ACM International Symposium on Code Generation and Optimization，2021】，两者在NCCL中普遍存在，但在基线中缺失。基于这些洞见，我们构建高性能通信库，目标是消除不必要的GPU到CPU复制、组初始化/处理开销和GPU同步/内存访问。图6和图7展示了我们M2N库中发送者和接收者的架构及其交互。

M2N发送者。 图6描绘了M2N发送者的组件。为了符合流导向编程模型，① M2N发送者利用CUDA事件【[12]，CUDA runtime API: cudaEventQuery，2025】等待先前内核，并确保② 预注册张量被正确填充。然后，为确保流中下一个内核在传输完成后启动，M2N发送者利用CUDA驱动程序操作【[15]，CUDA driver API: cuStreamWaitValue32，2025】来③ 阻塞流。一旦流被阻塞，数据传输分两个步骤进行：首先，④ 我们的内部CPU通信库（图中表示为Core Sender）使用RDMA write with immediate【[14]，NVIDIA Available RDMA Operations，2025】高效传输张量。其次，为保证预注册张量的正确利用，⑤ 发送者从相应完成队列【[13]，NVIDIA RDMA Key Concepts，2025】轮询完成，确认数据已写入远程缓冲。最后，M2N发送者⑥ 通过更新共享内存标志解阻塞流，允许其他内核继续重用注册内存。此设计消除复杂GPU同步、GPU到CPU复制和组初始化开销，所有这些都导致显著延迟问题，特别是对于相对小的张量大小，如图11和图12所示。

M2N接收者。 图7展示了M2N接收者的组件。就像其对等组件一样，M2N接收者也需遵守流导向编程模型。具体而言，它们① 在CUDA事件上等待以确保② 预注册张量不再使用，并③ 阻塞流以保证后续内核在操作完成前不继续。一旦流被阻塞，数据收集分两个步骤进行：首先，接收者必须验证数据已从相应发送者成功传输，这通过④ 轮询相关完成队列高效实现。其次，为确保GPU级数据一致性，我们的内部CPU通信库（图中表示为Core Receiver）利用GDRCopy【[16]，NVIDIA GDR Copy，2025】并执行⑤ flush操作【[1]，NCCL GDR Flush Operation，2022】。最后，M2N接收者⑥ 通过更新共享内存标志解阻塞流，允许其他内核继续利用注册内存。此更简单设计消除GPU到GPU复制的需要，并有效减少接收者的GPU利用开销。

流量导向优化。 我们还引入几个从我们设计规模测试中的经验观察得出的流量导向优化。高优先级ACK。我们最初观察到在带乒乓流水线并行的双向通信中延迟退化。详细分析揭示ACK数据包经常排队或以低优先级传输（例如轮询调度），导致大量QP数据包。因此，接收侧在响应ACK数据包时经历延迟，导致M2N发送者瓶颈。为解决此问题，我们将ACK数据包分配到高优先级队列，将它们与数据数据包隔离，并经验性地微调相关权重配置。拥塞控制微调。我们观察到在不均衡通信场景中延迟显著退化，其中每个接收者要发送的数据量显著变化。为解决此，我们微调拥塞控制算法以最小化速率限制效果并允许更快收敛。与DeepEP的比较。由DeepSeek提出的DeepEP【[5]，Deepep: an efficient expert-parallel communication library，2025；[35]，Deepseek-v2: A strong, economical, and efficient mixture-of-experts language model，arXiv:2405.04434，2024；[80]，Insights into deepseek-v3: Scaling challenges and reflections on hardware for ai architectures，arXiv:2505.09343，2025】也优化大规模专家并行服务的网络通信。我们方法与DeepEP的关键区别在于通信策略：我们利用CPU进行节点间通信，而DeepEP采用不涉及CPU代理的直接GPU到GPU通信【[2]，NVIDIA GPUDirect async，2022】。GPU到GPU通信方法在发送者和接收者侧消耗GPU计算资源【[19]，NVIDIA Streaming multiprocessors，2025】。相反，我们的CPU到CPU通信避免分配GPU计算资源，从而允许计算内核充分利用GPU。而且，GPU到GPU通信需要仔细协调以缓解通信与计算内核间的争用。DeepEP采用自定义PTX（类汇编）指令【[18]，NVIDIA PTX，2025】以最小化L2缓存使用——内核类型间共享的资源。相比之下，我们的设计不需要此类低级优化。当处理单个QP内的请求时，我们方法中的CPU实现更低延迟，因为其更高时钟速度允许它比GPU更快发出门铃。然而，GPU提供更强的并行处理能力，多个SM可独立管理QP。因此，DeepEP方法以消耗GPU SM资源为代价可实现更高数据包传输速率，并在数据包大小非常小时产生更好吞吐量。在我们场景中，每个发送者-接收者对间传输的数据量通常达到数百千字节（§7.3）。在此规模，单线程CPU足以饱和带宽。如果专家数量进一步增加且每连接通信量变小，利用GPU的优越并行处理能力可能在吞吐量方面提供更大优势。

融合内核。 为进一步提高效率并降低延迟，我们实现了两种融合内核。第一种是重叠TP的通信与相邻计算。虽然节点内TP通常使用如NVLINK的高速互连进行通信，但仍引入不可忽略开销。为解决此问题，我们利用Flux【[29]，Flux: Fast software-based communication overlap on gpus through kernel fusion，arXiv:2406.06858，2024】将通信与相邻GEMM操作融合，例如在单个内核中实现all-gather和后续GEMM。第二种是融合顺序内存密集型操作。MoE包括几个小内存密集型操作序列。例如，注意力节点需要在门控后为每个令牌选择top-k专家，计算中间结果如发送到每个专家节点的令牌数和归一化令牌权重，然后执行数据移动以将令牌分散到各自专家。我们通过将这些步骤与门控计算融合来优化此过程，减少内核启动和内存访问。

高性能M2N通信库实现。 我们将通信库构建为Pytorch扩展【[21]，Torch Custom C++ and CUDA Extensions，2025】，大约4900行C/C++和5000行Python代码。我们的库由如GPUDirect【[17]，NVIDIA GPUDirect，2025】和GDRCopy的技术支持。我们还仔细设计网络监控工具以深入网络和流量相关优化。

负载均衡。 在真实世界流量中，不同专家间的负载可能显著变化。为实现热和冷专家间的负载均衡，我们基于专家流行度部署带设备冗余。具体而言，我们解决将M个专家分布到N个节点上的优化问题。目标是最小化max_{j=1..N} C_j，其中C_j = \sum_{i=1..M} x_{i,j} \cdot max(a_i, K) 表示对应于延迟的计算成本。x_{i,j} 表示分配分数，\sum_{j=1..N} x_{i,j} = 1。a_i 表示计算专家i活跃令牌的成本，K表示冷专家的最低成本。该算法采用贪婪逼近策略解决此优化问题，并基于先前时间段内的流量生成专家计划。

方法细节中的引用汇总。
- [1]：NCCL GDR Flush Operation，2022，GitHub issue，无URL。引用在M2N接收者flush操作描述中，用于确保数据一致性。
- [2]：NVIDIA GPUDirect async，2022，NVIDIA博客，用于比较DeepEP的GPU到GPU通信。
- [5]：Deepep: an efficient expert-parallel communication library，2025，GitHub，用于比较DeepEP。
- [8]：NCCL Optimized primitives for inter-GPU communication，2025，GitHub，用于动机中的比较。
- [9]：NCCL User-buffer Registration，2025，NVIDIA文档，用于开销分析。
- [10]：NCCL Group Operations，2025，NVIDIA文档，用于开销分析。
- [11]：NCCL Data Transfer Between GPU and Proxy，2025，GitHub issue，用于开销分析。
- [12]：CUDA runtime API: cudaEventQuery，2025，NVIDIA文档，用于M2N发送者等待内核。
- [13]：NVIDIA RDMA Key Concepts，2025，NVIDIA文档，用于M2N发送者轮询完成。
- [14]：NVIDIA Available RDMA Operations，2025，NVIDIA文档，用于RDMA write。
- [15]：CUDA driver API: cuStreamWaitValue32，2025，NVIDIA文档，用于阻塞流。
- [16]：NVIDIA GDR Copy，2025，GitHub，用于flush操作。
- [17]：NVIDIA GPUDirect，2025，NVIDIA开发者，用于库支持。
- [18]：NVIDIA PTX，2025，NVIDIA博客，用于DeepEP比较。
- [19]：NVIDIA Streaming multiprocessors，2025，NVIDIA文档，用于GPU资源消耗。
- [20]：OFED Performance Tests，2025，GitHub，用于基准比较。
- [21]：Torch Custom C++ and CUDA Extensions，2025，PyTorch教程，用于库实现。
- [22]：Nvidia triton inference server，2025，NVIDIA开发者，用于LLM推理特性。
- [26]：The influence of operating systems on the performance of collective operations at extreme scale，2006，IEEE International Conference on Cluster Computing，用于不稳定性来源。
- [29]：Flux: Fast software-based communication overlap on gpus through kernel fusion，2024，arXiv:2406.06858，用于融合内核。
- [35]：Deepseek-v2: A strong, economical, and efficient mixture-of-experts language model，2024，arXiv:2405.04434，用于DeepEP比较和大规模LLM。
- [39]：Fail-slow at scale: Evidence of hardware performance faults in large production systems，2018，USENIX Conference on File and Storage Technologies，用于不稳定性。
- [41]：Drgpu: A top-down profiler for gpu applications，2023，ACM/SPEC International Conference on Performance Engineering，用于不稳定性来源。
- [43]：Characterizing the influence of system noise on large-scale applications by simulation，2010，The International Conference for High Performance Computing, Networking, Storage, and Analysis，用于不稳定性。
- [45]：Gpipe: Efficient training of giant neural networks using pipeline parallelism，2019，Neural Information Processing Systems，用于流水线并行。
- [50]：Scaling laws for neural language models，2020，arXiv:2001.08361，用于缩放定律。
- [60]：Splitwise: Efficient generative llm inference using phase splitting，2024，ACM/IEEE ISCA，用于预填充/解码解耦。
- [62]：Deepspeed-moe: Advancing mixture-of-experts inference and training to power next-generation ai scale，2022，arXiv:2201.05596，用于专家并行。
- [65]：Megatron-lm: Training multi-billion parameter language models using model parallelism，2019，arXiv:1909.08053，用于张量并行。
- [66]：Not all gpus are created equal: Characterizing variability in large-scale, accelerator-rich systems，2022，The International Conference for High Performance Computing, Networking, Storage, and Analysis，用于不稳定性。
- [69]：Vsensor: leveraging fixed-workload snippets of programs for performance variance detection，2018，ACM PPoPP，用于不稳定性。
- [70]：Mixtral 8x22b，2024，Mistral AI，用于MoE示例。
- [74]：Roofline: an insightful visual performance model for multicore architectures，2009，Communications of the ACM，用于屋顶线模型。
- [78]：Gvarp: Detecting performance variance on large-scale heterogeneous systems，2024，The International Conference for High Performance Computing, Networking, Storage, and Analysis，用于不稳定性。
- [80]：Insights into deepseek-v3: Scaling challenges and reflections on hardware for ai architectures，2025，arXiv:2505.09343，用于DeepEP比较。
- [81]：Vapro: performance variance detection and diagnosis for production-run parallel applications，2022，ACM PPoPP，用于不稳定性。
- [82]：DistServe: Disaggregating prefill and decoding for goodput-optimized large language model serving，2024，USENIX OSDI，用于预填充/解码解耦和性能模拟。
- [83]：Gpa: A gpu performance advisor based on instruction sampling，2021，IEEE/ACM International Symposium on Code Generation and Optimization，用于不稳定性来源。

实验环境

数据集：从公司生产环境中获取的数据集，用于实验工作负载。中位输入长度571令牌，中位输出长度159令牌。
模型架构：Mixtral 8x22B（141B参数，32层，top-2专家，8专家/层，隐藏维度6144，注意力头32，GQA组8），DBRX（132B参数，40层，top-4专家，16专家/层，隐藏维度6144，注意力头32，GQA组8），ScaledMoE（317B参数，32层，top-2专家，32专家/层，隐藏维度8192，注意力头64，GQA组8）。所有模型权重、激活和KV缓存使用bfloat16数据类型。
硬件配置：两个集群。第一集群：8节点，每节点8个NVIDIA 80GB Ampere GPU、128 CPU、2 TB主机内存、8个200 Gbps Infiniband NIC。节点内GPU通过400GB/s NVLINK互连。第二集群（异构）：NVIDIA H20节点（900GB/s NVLINK，4个400 Gbps NIC）和L40S节点（PCIe节点内通信，2个400 Gbps NIC）。H20：96GB内存、2 TB/s带宽、228 TFLOPS计算、500W功耗；L40S：48GB内存、1.8 TB/s带宽、900 TFLOPS计算、350W功耗。
软件配置：基于PyTorch扩展实现，C/C++和Python代码，支持GPUDirect和GDRCopy。基线：vLLM和TensorRT-LLM，支持FlashAttention、PagedAttention和连续批处理。所有系统在评估时时间分离预填充和解码阶段。

实验结果

端到端实验（同构部署）。 实验内容：在NVIDIA 80GB Ampere GPU上评估不同MoE模型的性能。基线vLLM和TensorRT-LLM在单节点服务Mixtral 8x22B和DBRX，在两节点服务Scaled-MoE。结果：MegaScale-Infer在每GPU解码吞吐量上比vLLM高2.56倍，比TensorRT-LLM高1.28倍（图8(a)）；对于Scaled-MoE，比vLLM高7.11倍，比TensorRT-LLM高1.90倍。分析：通过解聚合聚合请求，提高FFN批次大小，使其从内存密集转向计算密集。令牌间平均时间与基线相当（图8(b)）。端到端每GPU吞吐量（包括预填充）提高1.18倍（图8(c)）。TBT约束为150ms。

端到端实验（异构部署）。 实验内容：在H20（注意力）和L40S（专家）的异构集群上评估。基线分别在H20和L40S上评估。结果：MegaScale-Infer在每单位成本解码吞吐量上比H20上的vLLM高3.24倍，比TensorRT-LLM高1.86倍（图9(a)）。令牌间平均时间与基线相当，比L40S基线略好（图9(b)）。端到端每单位成本吞吐量提高1.66倍（图9(c)）。每单位功耗解码吞吐量高1.80倍，端到端高1.72倍（图10(a)(b)）。分析：利用H20的高带宽和L40S的计算成本效益。

M2N通信性能。 实验内容：变化数据大小（每个发送者到接收者的字节）和发送者/接收者数量（M/N）。每个GPU带200Gbps NIC。结果：MegaScale-Infer在所有数据大小下比NCCL低延迟、高吞吐量；对于小数据，中位延迟降低80.8%，P99降低96.2%，吞吐量提高9.9倍；对于256KB（典型），中位延迟降低68.2%，P99降低92.9%，吞吐量提高4.2倍（图11）。缩放M/N时，尾延迟降低54.7%-96.9%，吞吐量提高3.3×-5.8×（图12）。分析：优化消除复制、组开销和同步。

消融研究（解聚合专家并行和M2N优化效果）。 实验内容：与vLLM比较，添加解聚合和M2N优化。结果：解聚合（用NCCL）提高4.66倍吞吐量；添加M2N进一步提高1.53倍（图13）。分析：解聚合聚合批次，提高专家效率；M2N隐藏通信。

消融研究（乒乓流水线并行效果）。 实验内容：变化微批次数量m，保持微批次大小恒定。结果：m=1时低吞吐量；m=2提高1.9倍；m=3进一步提高1.10×-1.38×；更大m边际改进（图14）。分析：m>1减少空闲，m=3重叠通信，大模型受益更多。

消融研究（部署计划影响）。 实验内容：使用DBRX，变化注意力数据并行度（DP）。m=3固定。结果：DP=1-4时延迟恒定，吞吐量线性缩放；DP=8时峰值吞吐量，延迟相似；更高DP增加延迟，降低吞吐量（图15）。分析：平衡计算时间最小化空闲。

部署经验。 实验内容：生产部署在近10,000 GPU集群。结果：异构部署降低相同流量成本1.5–2.0倍。专家负载不均衡（图16(a)），解码稳定（图16(b)），预填充波动（图16(c)）。注意力负载通过剖析平衡。