Elastic EP in SGLang: Achieving Partial Failure Tolerance for DeepSeek MoE Deployments

发表时间: 2026-03 · Blog post by The Mooncake Team, Volcano Engine (lmsys.org)

原文: https://lmsys.org/blog/2026-03-25-eep-partial-failure-tolerance

The Mooncake Team, Volcano Engine

速读

一句话结论 本文在 SGLang 中引入 Elastic EP（弹性专家并行）机制，通过解除专家与 GPU 的硬绑定并引入冗余备份，在 DeepSeek 等 MoE 模型部署中实现局部故障容错，将系统恢复时间从数分钟缩短至 10 秒内，且常规性能无损。

要解决什么问题 部署超大规模混合专家（MoE）模型必须采用横跨 32 张 GPU 及以上的“宽”专家并行（EP）策略。这种规模能聚合海量显存以支撑超大批次大小，从而降低单个 token 成本；同时跨 GPU 的显存带宽聚合能直接降低每个输出 token 的耗时（TPOT）。然而，扩大 EP 规模引入了严重的可靠性卡点。传统架构中故障的“爆炸半径”与并行组规模成正比，由于专家被僵硬绑定在特定硬件上，并行规模越大，单点硬件或进程故障导致整个推理实例宕机的概率就越高。原有机制无法实现单实例内的局部故障容错，一旦局部崩溃必须耗费数分钟全面重启服务器，造成巨大算力浪费和严重停机。

怎么做的 为绕开专家与硬件强绑定导致的脆弱性，核心思路是引入 Elastic EP 机制，将专家权重与特定 GPU 的映射解耦，并在集群中维护冗余专家副本。当检测到局部故障时，系统动态重分配专家权重，将 token 瞬间重路由到存活专家上，在不中断推理的情况下实现容错。该机制由两层架构修改与一个底层通信库构成。首先是调度器层（Scheduler Layer），作为高层网关持续监控数据并行（DP）节点健康状态。发现故障时立即剔除该节点，确保新请求只分配给健康资源，在调度层实现零中断容错。其次是专家并行层（Expert Parallel Layer），负责底层动态容错执行。故障发生时，该层实时调整专家到 GPU 的映射，将丢失的专家重新分配给 EP 组内存活成员，确保 MoE 推理数学逻辑正确并与剩余资源对齐。为支撑这两层，系统集成 Mooncake EP 作为容错后端与核心通信层。它提供具备严格容错能力的通用集合通信原语（如 broadcast 和 allgather），以及专为 MoE 稀疏激活设计的容错 EP 原语（dispatch 和 combine）。此外，它利用 GPU Direct RDMA 实现高吞吐 token 分发，并基于底层网络控制实现超时快速故障检测。部署时需在内存中开启专家权重备份，以此决定系统能容忍的故障上限。

效果如何 实验基于 DeepSeek V3.2 模型。在极限弹性测试中，采用 4 节点（共 32 张 GPU，EP 与 DP 均设为 32）集群，配置 256 个冗余专家，最高容忍 16 个 rank 故障。通过手动终止进程模拟故障并用 sglang.bench_serving 测试。结果表明，在 1 到 16 个 rank 故障场景下，Elastic EP 重新分配权重并恢复服务的中断时间均在 10 秒内（如 1 个 rank 故障需 6.8 秒，16 个 rank 需 6.2 秒），比传统全面重启的 2 到 3 分钟减少 90%。代价是故障恢复后因可用资源减少，整体吞吐量会下降（如 1 个 rank 故障后吞吐量降至 5552.41 tokens/sec，16 个 rank 降至 2825.44 tokens/sec）。静态性能评估采用 4 节点配置（2 个 prefill 节点，2 个 decode 节点，每节点 8 张 GPU），对比基线是代表传统非容错路线的标准 DeepEP 方法。结果显示，使用 Elastic EP 的吞吐量为 3560.21 tokens/sec，首个 token 延迟（TTFT）为 19399.24 毫秒，TPOT 为 54.25 毫秒，与标准 DeepEP（吞吐量 3626.38 tokens/sec，TTFT 21227.86 毫秒，TPOT 52.88 毫秒）几乎一致，证明常规状态下零静态性能损耗。局限在于需额外消耗内存存储冗余专家权重。

A1 主要贡献

大规模混合专家（MoE）模型在高效服务部署时，必须采用横跨大量GPU的“宽”专家并行（Expert Parallelism, EP）策略。然而，扩大EP规模会带来严重的可靠性瓶颈：由于专家被僵硬地绑定在特定硬件上，单个硬件或进程的故障会导致整个推理实例崩溃，需要耗费数分钟全面重启，造成资源浪费和灾难性停机。SGLang此前的MoE模式缺乏原生支持单个实例内的部分故障容错（partial failure tolerance）能力。

为了解决这一问题，本文的核心创新点在于向SGLang框架中引入了Elastic EP（弹性专家并行）。该方案通过解耦专家与特定GPU之间的强绑定关系，并在集群中维护冗余的专家权重，使得系统能够在检测到局部硬件或进程故障时，瞬间重新分配专家权重并将Token重新路由到存活的专家上。这一设计在不牺牲系统规模和静态性能的前提下，实现了服务在秒级（<10秒）内的无缝恢复，将传统重启造成的停机时间缩减了90%以上。

A3 背景知识与关键Observation

宽专家并行（Wide EP）的必要性：为了高效部署大规模混合专家（MoE）模型，采用横跨32个或更多GPU的“宽”专家并行（EP）策略不仅是一种选择，更是必不可少的硬性需求。这种宽EP设计主要基于两个关键原因：首先，它能够聚合支持超大批处理大小（Batch Size）所需的海量显存，而维持大Batch Size是降低生产环境中每个Token总体成本的根本驱动力；其次，通过在众多GPU上扩展聚合的内存带宽，可以显著降低每个输出Token的时间（TPOT），从而确保生成过程的高速与敏捷响应。

宽EP带来的脆弱性与可靠性瓶颈：扩大EP规模会不可避免地引入严重的系统可靠性瓶颈。在传统的EP架构设计中，故障的“爆炸半径”（即故障波及范围）与EP组的大小呈严格的正比例关系。因为模型专家（Experts）被僵硬地绑定在特定的硬件资源上，EP组的规模越大，因单一硬件故障或进程崩溃导致整个推理实例宕机的统计概率就越高。

传统架构的恢复代价：在原有的系统设置中，一旦发生局部故障，必须强制要求对整个服务器进行全面重启。这一恢复过程通常需要耗费数分钟的时间，这不仅导致了巨大的计算资源浪费，还引发了灾难性的服务停机时间，并严重破坏了用户体验。由于SGLang之前的MoE模式在设计上原生不支持在单个实例内部实现部分故障容错（partial failure tolerance），因此迫切需要一种能在不牺牲部署规模的前提下，最小化对现有系统破坏的全新解决方案。

A2 方法细节

Elastic EP的核心解耦机制：Elastic EP解决大规模MoE推理脆弱性问题的核心在于，它彻底解耦了专家（Experts）与特定GPU之间的僵硬映射关系。系统通过在集群中持续维护冗余的专家权重，一旦检测到局部的硬件或进程故障，能够立即重新分配丢失的专家权重，并将Token瞬间重新路由（reroute）到存活的专家节点上。这确保了在不中断当前正在进行的推理过程的情况下，实现部分故障容错。当前，动态进程恢复功能也正在PR #15771 中进行积极的开发。

调度层（Scheduler Layer）的高层设计与过滤机制：为了实现上述弹性，解决方案在SGLang架构中引入了第一个关键的结构性变化——调度层。该层位于高层，专注于调度逻辑，并作为整个系统的守门员。它负责持续维护数据并行（DP）等级（ranks）的健康状态。如果某个rank发生故障，调度器会立即将其从可用资源池中过滤掉，确保新的批处理（batches）和请求只被分配给状态健康的资源。通过这种机制，它从源头上阻止了推理任务被路由到已失效的rank上，从而在调度层面上以零中断的方式提供了部分故障容错能力（该设计对应PR：#11657）。

专家并行层（Expert Parallel Layer）的底层执行与动态映射：第二个结构性变化是底层的专家并行层，该层专注于具体执行，并承担了动态容错的繁重工作。它通过实时动态调整专家到GPU的映射关系，来管理和应对EP组内部发生的故障。当故障实际发生时，该层会瞬间将所需的专家权重重新分配并覆盖到所有存活的EP成员节点上。这一操作确保了MoE推理在数学计算上能够被正确解析，并与当前可用的硬件资源保持严格对齐，从而避免了对实际底层执行造成严重的计算中断（相关实现对应PRs：#10423, #10606, #17374, #12068）。这两个层级协同工作，成功将原本脆弱的MoE流水线转变为一个高度弹性的推理引擎。

Elastic EP在4-GPU场景下的系统架构与工作流
Elastic EP在4-GPU场景下的系统架构与工作流

Mooncake通信库的角色与能力支撑：为了在系统中有效落地Elastic EP，系统必须依赖一个具备高弹性的通信库，该库需要能够处理动态的拓扑变化，同时在部分故障的极端条件下依然保证MoE推理在数学计算上的绝对正确。Mooncake EP正是这样一个在广泛的PyTorch生态系统中备受认可的稳健解决方案，它同时作为容错后端和专家并行（EP）的核心通信层，完美契合了这一迫切需求。

Mooncake EP提供的关键通信特性：作为系统的通信骨干，Mooncake EP提供了以下几项至关重要的底层能力：

  • 弹性通用集合通信（Resilient General Collectives）：它确保了标准的集合通信原语（例如broadcast和allgather）具备严格的容错能力。
  • 专用的EP原语容错（Specialized EP Primitives）：它针对专家并行所必需的专用通信原语（特别是dispatch和combine）提供了容错处理机制，这对于管理大型MoE模型中固有的稀疏激活模式起到了决定性作用。
  • 高性能RDMA与快速故障检测（High-Performance RDMA & Rapid Fault Detection）：通过重度利用GPU Direct RDMA技术，Mooncake在整个集群内实现了极高吞吐量和极低延迟的Token分发。更重要的是，它利用这种底层的网络控制能力，实现了一套基于超时（timeout-based）的快速故障检测机制。
  • 与SGLang的无缝集成（Seamless SGLang Integration）：尽管该库底层的网络实现极其复杂，但其设计初衷是与SGLang现有的执行流和调度逻辑实现无缝集成。这种即插即用的高兼容性，最大限度地减少了对系统进行大规模重构的需求，同时立竿见影地解锁了部分故障容错能力。

A4 实验环境

  • 测试模型：DeepSeek V3.2。
  • 硬件配置（极端故障恢复测试）：共4个物理节点，总计32张GPU（参数设置为 ep_size=dp_size=32）。
  • 硬件配置（静态性能测试）：共4个物理节点（其中2个配置为prefill节点，2个配置为decode节点），每个节点配备8张GPU。
  • 软件与系统配置：
    • 冗余参数：配置了256个冗余专家（redundant experts），系统最高可容忍16个rank的节点故障。
    • 通信后端：启用Mooncake作为容错的Torch分布式后端（--elastic-ep-backend mooncake）及EP通信后端（--moe-a2a-backend mooncake）。
    • 网络设备：通过 --mooncake-ib-device <comma-separated-ib-device-list> 指定用于Mooncake通信的InfiniBand（IB）网卡设备。
    • 其他依赖：需禁用系统默认的自定义all-reduce（--disable-custom-all-reduce），并启用内存中的专家权重备份（--enable-elastic-expert-backup）以支持故障场景下的快速权重恢复。
    • 测试工具：使用 sglang.bench_serving 进行服务基准测试，并依赖 EPLBManager 的日志来测量权重重新分配和恢复服务所需的时间。

A4 实验结果

实验一：极端故障恢复测试（Extreme Resilience Test）

  • 实验内容：在32张GPU（ep_size=32）且配置256个冗余专家的环境下运行DeepSeek V3.2。主动终止部分正在运行的进程，以模拟不同规模的节点故障（分别模拟1、2、4、8、16个rank故障）。测试系统重新分配丢失的专家权重并恢复服务所需的时间，以及恢复后剩余资源的吞吐量。
  • 实验结果：在所有规模的故障模拟中，服务中断时间均严格控制在10秒以内（具体在6.2秒至6.8秒之间波动）。与传统全面重启所需的2-3分钟相比，中断时间大幅缩减了90%。系统在恢复后能够继续正确执行推理任务，吞吐量因可用硬件资源的减少而呈比例下降。
  • 数据支撑：
    • 1个rank故障：中断时间 6.8 秒，剩余吞吐量 5552.41 tokens/sec。
    • 2个rank故障：中断时间 6.5 秒，剩余吞吐量 5431.50 tokens/sec。
    • 4个rank故障：中断时间 6.8 秒，剩余吞吐量 5265.12 tokens/sec。
    • 8个rank故障：中断时间 6.4 秒，剩余吞吐量 4479.84 tokens/sec。
    • 16个rank故障：中断时间 6.2 秒，剩余吞吐量 2825.44 tokens/sec。

实验二：静态性能无损验证（Zero Static Performance Degradation）

  • 实验内容：在4节点（32 GPU，分prefill和decode节点）环境下运行DeepSeek V3.2，对比使用Elastic EP（即Mooncake EP）与标准DeepEP方法在无故障正常运行时的各项关键性能指标。
  • 实验结果：引入Elastic EP并未带来任何静态性能下降，其服务性能与标准的DeepEP方法完全匹配。
  • 数据支撑：
    • Elastic EP方案：吞吐量 3560.21 tokens/sec，平均首字延迟（TTFT） 19399.24 ms，平均每个输出Token时间（TPOT） 54.25 ms。
    • 标准DeepEP方案：吞吐量 3626.38 tokens/sec，平均首字延迟（TTFT） 21227.86 ms，平均每个输出Token时间（TPOT） 52.88 ms。

A5 结论

本文成功在SGLang框架中设计并落地了Elastic EP（弹性专家并行）架构，彻底解决了大规模MoE模型在宽泛专家并行部署中面临的单点故障脆弱性问题。通过解耦专家与GPU的物理绑定，并深度集成具备高弹性与高性能RDMA能力的Mooncake通信库，系统在调度层和执行层实现了无缝协同。实验表明，该方案不仅能在极端故障下实现秒级（<10秒）的快速业务恢复，且在正常运行状态下实现了零静态性能损耗。未来，随着动态进程恢复功能（PR #15771）的并入，系统的端到端弹性容错能力将得到进一步完善。

A7 补充细节

替代方案NIXL EP的引入：在Elastic EP框架下，NVIDIA Dynamo团队近期提出并实现了一个名为NIXL EP的全新方案。作为Elastic EP生态的一部分，用户可以通过在SGLang服务器启动参数中设置 --moe-a2a-backend nixl 来启用并体验该后端实现。

开源协作与致谢：本方案的成功落地得益于广泛的社区协作。论文特别致谢了SGLang核心团队（包括Shangming Cai, Cheng Wan, Jingyi Chen, Lianmin Zheng等）、Mooncake团队（包括Xun Sun, Pingchuan Ma, Haoran Hu, Feng Ren, Mingxing Zhang等）、火山引擎团队（Han Han, Shan Lu, Qin Qi, Yang Zhang等）、Approaching AI（Yue Chen, Zhanhao Cao, Ke Yang等）、京东（Ziwei Yuan, Junlin Wei, Lianzhi Lin等）以及阿里云（Xinpeng Zhao, Xuchun Shang, Teng Ma等）的持续贡献。此外，NVIDIA Dynamo团队在支持与贡献方面也发挥了重要作用。相关技术实现的完整PR总结可参考 https://github.com/sgl-project/sglang/pull/8961，底层通信库源码可访问 https://github.com/kvcache-ai/Mooncake。