Expert-as-a-Service: Towards Efficient, Scalable, and Robust Large-scale MoE Serving

作者/机构:
Ziming Liu (新加坡国立大学, 上海期智知重有限公司), Boyu Tian (上海期智知重有限公司), Guoteng Wang (上海期智知重有限公司), Zhen Jiang (上海期智知重有限公司), Peng Sun (上海期智知重有限公司), Zhenhua Han (上海期智知重有限公司), Tian Tang (上海期智知重有限公司), Xiaohe Hu (Infrawaves), Yanmin Jia (Infrawaves), Yan Zhang (Infrawaves), He Liu (Infrawaves), Mingjun Zhang (Infrawaves), Yiqi Zhang (新加坡国立大学), Qiaoling Chen (南洋理工大学), Shenggan Cheng (新加坡国立大学), Mingyu Gao (清华大学), Yang You (新加坡国立大学), Siyuan Feng (上海创新研究院, 上海期智知重有限公司)

---

A1 主要贡献

本文针对混合专家（MoE）模型在服务部署中因其动态、稀疏的专家利用率而对传统为密集架构设计的系统造成的稳定性挑战，提出了一种名为EaaS（Expert-as-a-Service）的新型服务系统，旨在实现高效、可扩展且鲁棒的MoE模型部署。

核心问题与研究目标：
现有的LLM服务框架（如vLLM, SGLang, TensorRT-LLM）在处理MoE模型时面临三大核心挑战：
1. 弹性差：部署单元庞大且僵化（例如，DeepSeek-V3/R1需要320个GPU作为基本扩展单元），导致扩展粒度粗，资源浪费严重。
2. 鲁棒性低：严重依赖在静态进程组中建立的大规模集体通信（如All-to-All），单个设备故障就可能导致整个服务中断，恢复成本高。
3. 负载不均衡：专家激活的分布因输入数据和任务而异，而静态分片策略无法适应这种动态性，导致部分设备过载而其他设备空闲，资源利用率低下。

为了解决这些问题，EaaS的核心研究目标是重新设计MoE服务架构，以实现细粒度的弹性、高鲁棒性和动态负载均衡。

创新点与主要贡献：
1. 提出EaaS，一种基于专家解耦的MoE服务新架构：EaaS的核心思想是将MoE模块（专家层）从模型的其余部分（如注意力层）中解耦，将专家作为独立的、无状态的服务进行管理。这种服务化架构带来了三大优势：
* 细粒度弹性：专家容量可以独立于注意力计算组件进行扩展，甚至可以一次只增加一个GPU，从而精确匹配需求，避免资源浪费。
* 高鲁棒性：通过点对点（P2P）通信取代脆弱的集体通信，单个专家服务器的故障不会导致系统崩溃。客户端可以透明地故障转移到副本，新服务器可以动态加入，无需重启整个集群。
* 动态负载均衡：可以根据实时负载动态复制“热门”专家，并将它们部署到未充分利用的硬件上，实时缓解性能瓶颈。

1. 设计并实现了一个高性能、无CPU参与的异步P2P通信库：为了支持解耦架构下动态、非对称的P2P交互，本文开发了一个基于底层IBGDA（InfiniBand GPUDirect Async）原语的通信库。该库克服了现有库（如NCCL缺乏单边P2P操作，NVSHEMEM限制性的对称缓冲区要求，以及其他方案依赖CPU导致无法完全使用CUDA图）的局限性，实现了灵活的缓冲区管理、高效的单边操作，并通过无CPU、无组的网络操作将开销降至最低。

   

2. 通过详尽的实验验证了EaaS的有效性：实验表明，EaaS在性能上与最先进的单体系统相当，同时提供了卓越的容错能力和可扩展性。

   • 在模拟硬件故障时，EaaS的吞吐量下降不到2%，而传统架构则会完全停机。
   • 通过对服务流量的动态细粒度适应，EaaS最多可节省37.5%的计算资源，展示了其在生产环境中大规模部署MoE模型的强大韧性。

下表展示了当前主流MoE模型虽然只激活部分参数，但仍需大量GPU资源来存储整个模型，因此分布式服务是必要的。

表1. MoE模型虽然只激活其总参数的一小部分，但容纳整个模型仍需要大量GPU资源，这使得分布式服务成为必需。

---

A3 背景知识与设计动机

2.1 混合专家模型：通过稀疏性实现扩展

MoE架构的核心思想。混合专家（MoE）已成为高效扩展大语言模型的主流架构。其核心思想是用大量更小、更专业的“专家”子网络替换密集的（dense）前馈网络（FFN）层。对于每个输入令牌（token），一个轻量级的门控网络会动态选择一小部分专家来执行计算。这种条件执行方式使得模型总参数量可以增长到数万亿，而单次推理的计算成本却不会成比例增加。

细粒度MoE带来的新挑战。近期的架构趋势已从少数大型专家（如Mixtral-8x7B【【索引编号9，Mixtral of experts，2024，arXiv】】）转向具有数千个更小专家的细粒度MoE（如DeepSeek-V3【【索引编号14，Deepseek-v3 technical report，2024，arXiv】】，Kimi-K2【【索引编号28，Kimi k2: Open agentic intelligence，2025，arXiv】】，Qwen3【【索引编号33，Qwen3 technical report，2025，arXiv】】）。如表1所示，这种方法在保持激活参数数量可控的同时，实现了巨大的模型规模。然而，这种细粒度稀疏性给服务系统带来了两大挑战：
* 计算强度低：在批量解码（batched decoding）过程中，令牌被分散到大量专家中。这意味着每个专家只处理批次中一小部分令牌，导致硬件利用率低下，除非使用极大（通常不切实际）的批处理大小。
* 动态工作负载不均衡：令牌级别的专家分配是高度动态且依赖于输入的。如图2所示，专家激活的分布在不同任务和数据集之间差异巨大。这种数据依赖的倾斜给静态资源分配方案带来了难以解决的负载均衡问题。

2.2 单体式MoE服务架构

当前主流的单体式架构。为了处理现代MoE模型的巨大规模（见表1），分布式服务成为必然选择。vLLM【【索引编号10，Efficient Memory Management for Large Language Model Serving with PagedAttention，2023，SOSP '23】】、SGLang【【索引编号35，SGLang: Efficient Execution of Structured Language Model Programs，2024，NeurIPS】】和TensorRT-LLM【【索引编号21，TensorRT-LLM，2024，NVIDIA】】等系统采用的主流方法可被定性为单体式架构。在这种设计中，整个模型，包括注意力层和专家层，被部署为一个单一、紧密耦合的分布式应用程序。

专家并行与集体通信的依赖。该架构的核心是专家并行（Expert Parallelism, EP），这是一种将专家分片（sharded）到一组GPU上的技术。为了将令牌从注意力层路由到指定的专家，这些系统严重依赖大规模集体通信原语，尤其是All-to-All。在MoE层计算期间，每个GPU将发往特定专家的令牌发送到托管该专家的GPU上。这需要一个集体数据交换，其中组内的每个GPU都与所有其他GPU进行通信。

单体式架构的根本局限性。这种对集体通信的依赖强制在初始化时创建一个静态的进程组。所有参与的GPU必须预先知晓，通信模式也是预先确定的。虽然对于静态工作负载有效，但这种单体的、基于组的设计创建了一个僵化的结构，不适合生产环境中LLM服务的动态和高要求特性。这种僵化性导致了三个根本性的限制：
* 粗粒度的弹性。静态进程组是部署和扩展的不可分割单元。要增加容量，必须配置一个全新的、大小和配置完全相同的组。无法只增加几个GPU来处理边际负载增长。这导致资源分配效率低下，因为系统必须为峰值需求进行过度配置。DeepSeek-V3【【索引编号14，Deepseek-v3 technical report，2024，arXiv】】推荐的320-GPU“基本扩展单元”就是这种粗粒度的明显例子。
* 脆弱性和低容错性。集体通信是脆弱的。静态组内单个GPU或网络链接的故障将导致All-to-All操作挂起或失败，从而使整个服务实例停滞。恢复需要重启整个组，这是一个缓慢且具有破坏性的过程，降低了服务的可用性。
* 静态且低效的负载均衡。专家到GPU的映射在服务启动时就已固定。这种静态分配无法适应动态的工作负载模式，例如图2所示的模式。如果某些专家变成“热点”（被频繁激活），托管它们的GPU就会成为性能瓶颈，而拥有“冷门”专家的GPU则处于空闲状态。单体式设计缺乏通过动态复制热门专家到未充分利用的硬件上来缓解这些不平衡的灵活性。

近期工作的局限性。像MegaScale-Infer【【索引编号36，MegaScale-Infer: Serving Mixture-of-Experts at Scale with Disaggregated Expert Parallelism，2025，arXiv】】和StepMesh【【索引编号32，Step-3 is Large yet Affordable: Model-system Co-design for Cost-effective Decoding，2025，arXiv】】等近期工作探索了将注意力和MoE层解耦为不同层次的方案。然而，它们仍然依赖于这些层次之间静态的、基于组的集体通信。它们实际上创建了两个耦合的单体组，因此继承了同样根本性的限制：弹性差、脆弱和静态负载管理。这些挑战凸显了单体式服务系统的静态、僵化特性与细粒度MoE模型的动态、稀疏计算模式之间的根本架构不匹配。这促使我们放弃单体范式，转向一种更灵活、鲁棒且面向服务的设计。

2.3 效率和可扩展性的挑战

单体式架构在生产环境中的实际问题。尽管单体式架构功能上可行，但其僵化性在生产环境中部署时会产生严峻的实际挑战，特别是对于大规模模型即服务（MaaS）提供商。这些挑战表现为运营效率低下、可靠性差和性能瓶颈。

低效的资源配置与高昂的运营成本。单体式设计及其粗粒度、不可分割的扩展单元，带来了高昂的“入门”成本，并迫使资源配置效率低下。MaaS提供商必须为峰值需求分配资源，这意味着一个大型GPU集群（例如，DeepSeek-V3的320-GPU单元）即使在流量低谷期也必须保持占用。这导致大量资源闲置并推高了运营成本，因为提供商需要为闲置的、紧密耦合的硬件付费。此外，这种不灵活性使得提供商无法动态调整注意力与专家计算资源的比例以匹配变化的工作负载特性，导致采用一种“一刀切”的分配方式，而这种方式很少是最佳的。

差的容错性与高昂的恢复开销。静态进程组内资源的紧密耦合使得整个服务实例极其脆弱。像All-to-All这样的集体通信原语要求每个参与者都健康；单个GPU或网络链接的故障就可能导致集体通信无限期挂起，引发级联故障，使整个服务宕机。如图3所示，硬件故障在大型集群中是常见事件。在单体系统中，从此类事件中恢复是一个成本高昂、具有破坏性的过程，需要重启整个数百个GPU的部署。这会导致显著的停机时间、用户请求被丢弃，并严重影响服务水平目标（SLO）。

静态负载均衡与性能瓶颈。专家到特定GPU的分配在部署时就已固定。这种静态分配从根本上无法适应专家激活模式的动态、输入依赖特性（如图2所示）。因此，当某些专家因工作负载成为“热点”时，托管它们的GPU会不堪重负，产生瓶颈。同时，托管“冷门”或不常用专家的GPU则未被充分利用。整体吞吐量因此受制于最过载的单个设备，而非总容量。这种静态不平衡阻碍了系统发挥其潜在性能，并导致昂贵GPU资源的低效使用。

2.4 架构转向：利用专家的无状态特性

单体式架构的根本缺陷。上文详述的弹性、鲁棒性和负载均衡等严峻挑战并非独立问题，它们是单体式设计中一个根本架构缺陷的症候：有状态和无状态计算的紧密耦合。一个LLM服务进程有两个不同的组件：

• 有状态的注意力层：这些层维护键值（KV）缓存，存储每个独立生成序列的上下文状态。该组件本质上是有状态且与会话相关的。
• 无状态的MoE层：MoE层中的专家网络执行纯粹的、幂等的函数。它们以令牌的隐藏状态为输入并产生输出，不保留同一序列中先前令牌的任何内存或状态。

解耦是解决问题的关键。单体式架构将无状态、灵活的MoE层束缚在有状态、僵化的注意力组件上。这迫使整个系统作为一个单一、有状态、不可分割的单元进行管理，从而继承了两者的最坏特性。这个核心洞见——专家的无状态性——提供了一个明确的架构转向。通过解耦这些组件，我们可以设计一个将专家视为它们本质上所是的独立、无状态服务的系统。这种解耦直接为先前确定的挑战提供了解决方案：

• 独立、细粒度的扩展。解耦允许专家服务器池独立于处理注意力的前端进行扩展。提供商可以一次性增减一个托管专家的GPU，以精确匹配对专家的计算需求，而不是配置僵化的、单体的320-GPU块，从而消除了与过度配置相关的大量资源闲置和高运营成本。注意力与专家计算的比例可以根据工作负载动态调整，而不是被固定的硬件拓扑所限制。
• 通过复制实现鲁棒性。专家的无状态性使其非常适合复制。它们成为可互换、可替代的资源。如果一个专家服务器发生故障，请求可以透明地重新路由到一个副本，而不会干扰注意力GPU上的有状态KV缓存。这将集体通信脆弱的、全有或全无的故障模型替换为健壮的、优雅降级的服务模型。恢复就像一个新专家服务器注册其可用性一样简单，无需进行成本高昂、导致服务中断的整个组重启。
• 通过服务实例化实现动态负载均衡。面向服务的设计打破了专家到特定GPU的静态映射。当系统检测到某些专家已成为“热点”（如图2所示）时，它可以动态地在集群中未充分利用的GPU上实例化这些特定专家的新副本。这些新实例可以立即开始处理请求，分担负载并实时缓解瓶颈。这将负载管理从静态的、部署前的猜测转变为动态的、自适应的系统优化。

EaaS的设计基石。这种从单体的、紧密耦合的系统到解耦的、面向服务的系统的架构转向，构成了我们方法论的基石。基于这些原则，我们设计了EaaS，一个用于大规模MoE模型服务的系统，该系统本质上是弹性的、鲁棒的且高效的。我们将在下一节详细介绍其设计。

---

A2 方法细节

3 系统设计

本节详细介绍为大规模MoE模型设计的服务系统EaaS的架构。内容包括系统的解耦架构、共享通信缓冲区设计以及异步专家服务器操作，这些对于实现可扩展性和鲁棒性至关重要。

3.1 架构概述

EaaS的范式转变。如图4所示，EaaS框架代表了MoE模型推理的范式转变。传统的专家并行（图4(a)）采用单体部署，将注意力和专家层紧密耦合在一个静态组内。这种设计僵化，易受单点故障影响，且扩展性不佳。与此不同，EaaS采用了解耦的、面向服务的架构（图4(b)）。

EaaS的核心组件。EaaS架构将无状态的MoE层从有状态的组件（如注意力层）中解耦，创建了两个可独立扩展的实体：
1. 注意力客户端：这些单元处理密集计算，如注意力机制。当遇到MoE层时，客户端的路由器通过异步点对点（P2P）通信将激活值分派给相应的专家服务器。
2. 可扩展的专家服务器：每个服务器托管一部分专家，并作为独立的、无状态的服务运行，专门执行专家计算。

解耦架构的优势。这种架构上的解耦消除了对共享、静态通信组的需求，从而实现了细粒度的弹性和增强的容错能力。因此，客户端和服务器都可以独立扩展以应对动态工作负载，确保单个组件的故障不会导致系统范围的中断。

3.2 共享通信缓冲区设计

缓冲区结构。客户端和专家服务器之间的交互通过一个为高效、异步数据交换而设计的共享通信缓冲区进行协调。如图5所示，每个客户端在服务器上被分配一个专用的缓冲槽，该槽由一个状态标志、一个头部和一个数据负载组成。

缓冲区状态标志。一个单字节的标志用于表示缓冲区的状态，以协调客户端与服务器的交互。这些状态包括："0"（空闲），表示客户端可以写入；"1"（客户端写入完成），表示服务器可以处理；"2"（服务器计算完成），表示客户端可以读取；"3"（离线），用于标记一个不活跃的客户端。

头部（Header）。此部分包含用于请求处理的元数据，包括layer_id和batch_size。它也可以包含数据大小信息以用于内存管理。

数据负载（Data Payload）。此部分存放计算所需的核心数据，包括令牌激活值（隐藏状态）、每个令牌的expert_id映射以及用于加权输出的router_score。

设计优势。这种结构化的缓冲区设计清晰地划分了职责：客户端管理写入请求和读取结果，而服务器只负责读取请求和写入结果。状态标志确保了在没有直接通信的情况下实现正确的同步。

3.3 异步服务器操作

服务器的独立性原则。EaaS的一个基本原则是专家服务器在操作上的完全独立和异步。至关重要的是，服务器不主动与客户端进行任何同步或直接通信。相反，它在一个连续的、无状态的循环中运行，仅对共享通信缓冲区的状态做出响应。

服务器工作流程。服务器的操作流程按以下步骤顺序进行。首先，服务器持续异步地轮询分配给它的所有客户端缓冲区的状态标志。一旦识别出所有缓冲区都处于“1”（客户端写入完成）状态，它会聚合来自多个客户端的这些待处理请求，形成一个动态批次。随后，来自这个聚合批次的令牌被重组并高效处理，利用诸如分组GEMM（grouped GEMM）等优化内核以实现最大的硬件利用率。计算完成后，服务器将结果——即专家输出的加权和——写回到相应客户端缓冲区的数据负载部分。最后，服务器将每个已处理缓冲区的状态标志更新为“2”（服务器计算完成），从而向相应客户端发出信号，表示结果可供检索。

异步操作对系统的贡献。这种完全独立的操作模式是系统鲁棒性和可扩展性的内在组成部分。服务器的无状态特性及其与静态客户端组的独立性使其能够抵御客户端故障。新的服务器可以动态地集成到池中以管理增加的负载，客户端可以透明地故障转移到副本服务器而无需中断服务。这种设计有效地将专家模块转变为一个可扩展、鲁棒且按需提供的计算服务。

3.4 容错机制

基于监控器的容错设计。EaaS架构的解耦和异步特性，在一个中央监控器的支持下，提供了固有的容错能力，确保了高服务可用性。如图6所示，系统设计用于通过基于心跳的健康跟踪机制优雅地处理客户端和服务器的故障。

客户端故障处理。当一个注意力客户端下线时，监控器会检测到该客户端心跳信号的丢失。随后，它会通知所有相关的专家服务器该故障。收到通知后，服务器会释放分配给下线客户端的通信缓冲区，防止资源锁定，并确保故障保持局部化。此事件仅影响由该特定客户端处理的推理请求；所有其他客户端和服务器继续不间断地运行，保持了整体系统的稳定性。

服务器故障处理。系统对服务器故障的韧性是通过复制无状态专家服务来实现的，并通过两种检测途径进行处理。首先，中央监控器可以检测到服务器心跳的丢失，并主动通知所有客户端。其次，如果一个请求的轮询周期超过了预定义的超时阈值，客户端可以独立地推断出服务器故障。在任何一种情况下，客户端都会立即更新其本地的专家到服务器的映射，将失败的服务器从其可用资源列表中移除。然后，它会自动将原始请求重新传输到托管所需专家副本的备用服务器。这种故障转移机制被设计为透明的，并且对最终的推理结果影响可以忽略不计，从而确保了服务的持续和鲁棒交付。

4 优化

EaaS是一个集成的、端到端的MoE服务系统，它结合了基于SGLang【【索引编号35，SGLang: Efficient Execution of Structured Language Model Programs，2024，NeurIPS】】的注意力客户端、一个基于IBGDA【【索引编号20，Improving network performance of HPC systems using NVIDIA Magnum IO NVSHMEM and GPUDirect Async，2022，NVIDIA】】的RDMA非对称异步点对点（P2P）通信库，以及一个自行设计的【【索引编号24，Triton，2021，OpenAI】】MoE服务器。为了减少CPU的参与并利用CUDA Graph【【索引编号18，Getting Started with CUDA Graphs，2019，NVIDIA】】来降低内核启动开销，我们开发了定制的Triton和CUDA内核。

4.1 专家服务器的内核优化

解决非均匀工作负载。EaaS架构中的一个关键挑战是管理大规模MoE服务中因批次不平衡而产生的非均匀工作负载，这通常导致GPU利用率不足。我们通过专门的内核优化（算法1）来解决这个问题，该优化使用静态GPU网格。每个块独立地遍历有效令牌，跳过空批次，并使用共享内存以跨步方式分发令牌。这种设计有效地在GPU线程间平衡了工作负载，使服务器能够适应不平衡而不会产生空闲线程或同步开销。

Require: num_tokens_per_batch: Array of token counts per batch
Require: batch_count: Number of batches
Require: process_a_token: The function to process a single token
1: Alloc shared memory: sh_num_tokens[MAX_BATCHES]
2: Initialize: token_idx ← threadIdx.x
3: Load sh_num_tokens ← num_tokens_per_batch
4: for batch_idx = 0 to batch_count − 1 do
5:   num_tokens_in_this_batch ← sh_num_tokens[batch_idx]
6:   while token_idx < num_tokens_in_this_batch do
7:     Call process_a_token(batch_idx, token_idx)
8:     token_idx ← token_idx + blockDim.x
9:   end while
10:  token_idx ← token_idx − num_tokens_in_this_batch
11: end for

优化DeepGEMM性能。第二个挑战来自于在每个服务器上托管大量专家。标准的DeepGEMM实现会产生性能瓶颈，因为它低效地遍历所有可能的专家组（其中大多数是未激活的），并为每个组都进行一次低吞吐量的全局内存读取。为了解决这个问题，我们引入了一个“组收缩”（group-shrink）内核，该内核使用GPU前缀扫描来分离出活跃的组，并将其元数据移到前面，以便我们可以提前停止。然后，修改DeepGEMM调度器以遍历这个紧凑的张量，该张量被一次性加载到共享内存中，从而消除了低效的、重复的内存读取。

优化效果。这些内核级别的优化，与我们的动态批处理和令牌重组策略相结合，使得专家服务器能够维持高GPU利用率和吞吐量。通过有效管理这些动态和稀疏的MoE工作负载，我们的系统克服了负载不平衡和资源利用不足的传统瓶颈。

4.2 注意力客户端中的双批次重叠技术

解决通信延迟瓶颈。在EaaS架构中，一个关键的性能瓶颈是从注意力客户端向远程专家服务器分派令牌所固有的通信延迟。这个网络往返时间可能迫使客户端的GPU在等待结果时处于空闲状态，从而在执行流水线中产生“气泡”，直接降低整体吞吐量。为了应对这种低效率，我们实现了DoubleBatch-Overlap【【索引编号14，Deepseek-v3 technical report，2024，arXiv】】策略，这是一种专门设计用来重叠通信和远程计算延迟的流水线技术。

工作原理。该策略通过在客户端的流水线中维持两个活动批次来确保GPU的持续工作。过程如下：当一个先前分派的批次（批次A）正在由远程专家服务器处理时，客户端的GPU不会等待。相反，它会立即开始为下一个批次（批次B）进行计算密集型的注意力计算。这种时间上的重叠是关键机制；批次B的注意力计算有效地隐藏了批次A的网络和处理延迟。结果是，当批次A的专家结果返回到客户端时，批次B已经完全准备好分派。这种无缝的交接创建了一个连续、重叠的工作流，将潜在的空闲时间转化为生产性计算。通过最小化GPU停顿，这种方法直接提高了资源利用率，维持了更高的操作强度以提高系统吞-吐量，并减少了每个请求的端到端延迟。

4.3 使用CUDA图进行端到端加速

CUDA图的作用。启动大量小型CUDA内核所带来的高开销会限制LLM的推理性能。CUDA图通过将整个内核启动序列捕获到一个单一、可重用的单元中来解决这个问题，从而减少了CPU的启动开销。

无CPU通信库的关键作用。我们使用基于IBGDA的无CPU通信库，对于最大化该技术的优势至关重要。因为所有网络操作都是从GPU发起而无需CPU干预，我们可以在注意力客户端上将从注意力计算、数据分派到结果接收和最终处理的完整端到端工作流捕获到一个单一的CUDA图中。这种整体捕获几乎消除了客户端整个操作循环中所有的CPU端启动开销。

系统级优化。通过在客户端和服务器上都启用基于图的执行，EaaS最小化了整个分布式系统的内核启动开销，从而提高了整体效率并降低了延迟。

4.4 灵活的IBGDA连接

连接建立过程。我们利用客户端-服务器架构来管理IBGDA连接，这确保了EaaS服务的灵活部署。建立新IBGDA连接的过程如图7所示。首先，客户端向服务器发起一个HTTP请求①，传输其IBGDA P2P通信句柄（P2P Comm）。收到此请求后，服务器执行镜像操作②。同时，客户端开始更改其QP状态并通知服务器③④。最后，客户端和服务器完成GPU缓冲区的注册，并交换各自的MR和缓冲区地址⑤⑥，在它们的映射中标记对端的就绪状态。

全局状态维护与容错。为了维护连接状态的统一全局视图，我们引入了一个中央监控器。该监控器跟踪所有客户端和服务器的健康状况，并在某个rank上线或下线时进行广播。它可以利用像ZooKeeper【【索引编号7，ZooKeeper: wait-free coordination for internet-scale systems，2010，USENIXATC'10】】这样的分布式一致性组件来实现。图6说明了系统针对客户端和服务器故障的容错机制。当服务器停止服务时，监控器的心跳机制会检测到变化，使其客户端能够更新映射并切换到另一个可用的服务器。反之，服务器将释放任何失去心跳的客户端的缓冲区。这使得实例数量的改变无需重启。得益于监控器和基于客户端-服务器的IBGDA连接，EaaS仅需按需重建连接。这避免了在动态扩展或容错事件中重建整个通信组的昂贵开销。

4.5 专家的动态负载均衡

兼容性与扩展性。EaaS与当前主流的MoE负载均衡方案兼容，例如EPLB【【索引编号3，Expert Parallelism Load Balancer (EPLB)，2025，deepseek ai】】，该方案通过重排序和添加冗余专家来平衡专家并行实例间的负载。此外，EaaS可以利用现有的负载均衡策略提供更广泛的均衡方法。具体来说，有三类可能的方法。首先，与专家并行不同，EaaS不限制每个专家服务器上的专家数量必须相同。这为通过调整每个服务器上的专家数量来进行负载均衡提供了机会。其次，基于上文讨论的灵活IBGDA连接机制，EaaS可以通过增减“热门”和“冷门”专家的服务实例数量来动态平衡负载。最后，由于解耦的部署架构，还可以通过更改托管专家的实例的计算/内存规格来平衡负载。

总结与未来工作。总之，在现有负载均衡策略的基础上，EaaS为部署MoE模型推理服务提供了更丰富的负载均衡方法，特别是在云服务等场景中。我们还将在未来的工作中探索专为EaaS设计的负载均衡算法。

---

A4 实验环境与结果

5.1 评估设置

• 硬件配置：我们使用了16个计算节点，每个节点配备8个NVIDIA Hopper GPU（80GB）。节点内GPU通过NVLink连接，节点间通过8个400Gbps的RoCE链路连接。
• 软件配置：实验环境基于PyTorch 2.7.1，Python 3.12和CUDA 12.6。
• 模型与工作负载：我们在大规模场景下评估了DeepSeek-R1【【索引编号5，Deepseek-r1: Incentivizing reasoning capability in llms via reinforcement learning，2025，arXiv】】 671B模型。工作负载采用ShareGPT【【索引编号29，ShareGPT，2023，ShareGPT Team】】数据集，为减少长尾效应，最大响应长度限制在768个令牌。
• 基线系统：
  • SGLang【【索引编号35，SGLang: Efficient Execution of Structured Language Model Programs，2024，NeurIPS】】（commit ID: 51cdd81f）：一个先进的推理引擎。我们比较了其两种模式：张量并行（TP）和专家并行（EP），后者使用了高性能通信库DeepEP【【索引编号14，Deepseek-v3 technical report，2024，arXiv】】。
  • vLLM【【索引编号10，Efficient Memory Management for Large Language Model Serving with PagedAttention，2023，SOSP '23】】（commit ID: 9b01870）：另一个主流推理引擎，同样与DeepEP结合使用。
  • StepMesh【【索引编号31，Step-3 is Large yet Affordable: Model-system Co-design for Cost-effective Decoding，2025，arXiv】】: 由于MegaScale-Infer【【索引编号36，MegaScale-Infer: Serving Mixture-of-Experts at Scale with Disaggregated Expert Parallelism，2025，arXiv】】代码未开源，我们使用StepMesh来对比我们提出的无CPU通信库的端到端开销。
• 实验细节：SGLang和EaaS都实现了基于Mooncake【【索引编号25，Mooncake: A KVCache-centric Disaggregated Architecture for LLM Serving，2025，arXiv】】的Prefill-Decode（PD）分离，而vLLM的此功能尚在实验阶段未使用。为保证公平，主要评估中未加入负载均衡算法，但在消融研究中进行了探讨。
• 关键指标：我们主要测量两个指标：吞吐量（侧重于解码阶段）和令牌间延迟（Inter-Token Latency, ITL）。所有指标均使用SGLang的基准测试脚本在所有提交的请求上进行端到端测量。

5.2 端到端评估

我们在两种配置下评估了EaaS的整体性能：(1) 128个GPU（8个节点用于prefill，8个用于decode）和(2) 48个GPU（2个节点用于prefill，4个用于decode）。

• 实验内容：对比EaaS与SGLang+DeepEP（SGL-EP）、SGLang+TP（SGL-TP）和vLLM+DeepEP在不同请求负载下的吞吐量和令牌间延迟。
• 实验结果（图8和图9）：
  • SGL-EP：在请求量较小时表现出有竞争力的吞吐量和延迟，但在高负载下，由于其数据并行注意力（Data Parallel Attention）的请求传输和负载均衡限制，出现了明显的长尾延迟。
  • SGL-TP：由于其推理单元较小（每单元16个GPU），保持了低且稳定的ITL。但这也导致需要多次复制模型权重，减少了每个GPU的可用内存，限制了最大批处理大小，从而导致吞吐量显著低于其他方法。
  • vLLM：在大规模配置下实现了高吞吐量，但其令牌间延迟相对较高。
  • EaaS：得益于其高效的通信库以及在注意力和专家计算之间均衡的资源分配，EaaS在保持可接受延迟的同时，实现了强大的吞吐量。
• 结论：EaaS展示了与SGLang和vLLM等最先进系统相媲美的端到端性能，并额外提供了容错等功能。

5.3 可扩展性

• 实验内容：通过弱扩展实验评估EaaS的可扩展性，展示其动态、成本效益高的资源分配能力。
• 实验结果（图11）：
  • EaaS在从32个GPU扩展到64个GPU时，吞吐量呈现出近线性的成比例增长，表明资源利用高效且开销小。
  • 相比之下，SGL-EP和vLLM-EP等单体系统由于其架构僵化，无法在非标准GPU数量（如40、48、56）的配置上运行，只能进行粗粒度的扩展。
• 结论：EaaS的服务化设计支持按需精确配置资源。例如，当流量从8192减少到5120时，基线系统仍需配置64个解码GPU，而EaaS可以缩减至40或48个GPU，在维持相同解码吞吐量水平的同时，节省高达37.5%的计算资源。

5.4 容错能力

• 实验内容：在64个GPU进行解码的设置下，随机逐个禁用10个GPU，并测量恢复期间的平均解码吞吐量。
• 实验结果（图10）：
  • SGL-EP和vLLM-EP：由于所有解码GPU属于同一个通信组，单个GPU的故障需要重启整个组，导致服务在恢复期间完全中断。
  • SGL-TP：由于其执行单元较小（16个GPU），更具弹性，故障时只需重启一个单元，其余单元可继续运行。
  • EaaS：通过在服务器上预先复制专家，原本发往离线服务器的请求可以被重定向到有备份的另一台服务器。同时，注意力客户端独立运行，其故障可由PD分离引擎的路由机制高效处理。
• 结论：当GPU发生故障时，EaaS的解码吞吐量下降不到2%，表现出极高的韧性。

5.5 与其他非对称通信库的比较

• 实验内容：在模拟DeepSeek R1模型解码阶段的真实场景下，比较EaaS的通信库与StepMesh的端到端往返延迟。设置了对称（2客户端-2服务器）和非对称（1客户端-3服务器）两种场景。
• 实验结果（图12）：
  • EaaS始终比StepMesh延迟更低。在批处理大小为512时，两种场景下的开销分别降低了49.6%和34.7%。
• 结论：EaaS的性能优势源于两点：一是利用IBGDA绕过CPU，消除了访问主机内存队列和CPU控制指令的开销；二是完全无CPU的流程使得通信内核的启动开销可以通过CUDA图捕捉进一步降低。这证明了无CPU通信库的重要性，并表明降低通信库级别的开销能直接转化为更低的端到端推理延迟。

5.6 消融研究

• 实验内容：为了解EaaS中各关键组件的贡献，我们通过选择性地禁用它们来衡量吞吐量的变化。我们考察了三个优化点：(1) CUDA图捕捉，(2) 内核收缩（kernel shrinking），(3) 双批处理（double batching）。
• 实验结果（图13）：
  • 以批处理大小4096为例，禁用CUDA图导致吞吐量急剧下降91.9%，因为CPU侧内核启动开销反复出现。
  • 没有内核收缩，吞吐量下降14.9%，原因是稀疏专家组的调度效率低下。
  • 移除双批处理策略导致吞吐量下降25.9%，因为通信延迟不再被重叠的注意力计算所掩盖。
  • 此外，结合DeepSeek的专家负载均衡算法后，EaaS的性能分别提升了2.4%、4.4%和5.1%。
• 结论：所有这三个优化对于实现EaaS的整体效率都至关重要。

---

A5 结论

我们提出了EaaS，一个专为大规模混合专家（MoE）模型设计的服务系统。通过将MoE层解耦为独立的服务，EaaS实现了细粒度的弹性、鲁棒的容错能力和高效率。其核心是一个无CPU参与的异步P2P通信库，与现有解决方案相比，它提供了额外的加速。我们的评估表明，EaaS在吞吐量和延迟方面与最先进的系统相当，同时在故障情况下保持了韧性并具有强大的可扩展性。这种面向服务的范式为在生产环境中部署大规模MoE模型建立了一个灵活高效的基础。