小红书与北京大学发布 UltraEP，挑战静态 MoE 负载均衡

小红书与北京大学发布了 UltraEP 研究，对大规模专家混合模型基础设施背后的一项基本假设提出了挑战。UltraEP MoE 负载均衡并不预测哪些专家将变得繁忙，而是在每一层的路由器揭示实际需求后作出响应。

这一区别非常重要，因为专家需求可能会随着微批次、层和提示词领域而变化。基于近期历史数据制定的放置方案，可能在系统使用之前就已过时。UltraEP 通过创建过载专家的临时副本，并在当前操作中重新路由 token 来应对这种情况。

作者报告称，在三个大型 MoE 模型中，UltraEP 达到了人为均衡训练理想水平的 94.6%。他们还报告称，其平均训练吞吐量比 Megatron-LM 高 42%，预填充吞吐量是 SGLang 的 1.56 倍。

这些结果来自团队自己的实验，而非独立复现。UltraEP 论文于 2026 年 6 月提交，作者包括来自北京大学、小红书、上海人工智能实验室的研究人员以及独立贡献者。

该论文提供了大量实现和评估细节。然而，它并未指出公开的 UltraEP 源代码仓库。因此，在运行时代码及其许可证可被公开验证之前，将这项工作描述为完全开源仍需谨慎。

更重要的在于其架构意义。UltraEP 将负载均衡从周期性的控制任务转移到每个 MoE 层的执行路径中。这使包括 EPLB 在内的成熟历史数据驱动方法面临直接压力。

UltraEP MoE 负载均衡在路由后作出响应

UltraEP 改变了分布式 MoE 系统决定如何均衡工作负载的时机。

专家混合模型包含许多称为专家的专用前馈网络。其路由器会将每个 token 分配给其中一小部分专家。

与每个 token 都使用所有参数相比，这种设计减少了活跃计算量，但也带来了一个分布式系统问题。在同一层中，热门专家接收的 token 可能远多于相邻专家。

专家并行将这些专家分布到多个 GPU 上。token 会前往托管其所选专家的设备，通常通过全互联通信传输，并在计算完成后返回。

持有热门专家的 GPU 必须处理更多 token。其他 GPU 会提前完成，并在同步点等待。最慢的秩随后可能决定整个操作的速度。

这种不均衡还会影响通信和内存。过载的秩会接收更多 token 激活值、传输更多数据，并需要更多临时内存。因此，一次路由决策可能产生三个相互关联的瓶颈。

现有均衡器通常使用近期测量结果来决定冗余专家副本应放置在何处。例如，DeepSeek 的 EPLB 项目会根据记录的负载计算均衡的专家放置方案。

当专家热度逐渐变化时，这种方法效果良好。但当提示词组成、token 内容或训练动态改变需求的速度快于重新均衡间隔时，其可靠性就会下降。

UltraEP 研究人员在大规模专家并行配置下测量了这一问题。他们报告称，不同层、工作负载和相邻微批次之间存在显著差异。DeepSeek-V3 训练呈现出尤为明显的短期波动。

UltraEP 会等待门控操作生成精确的路由分配，然后为该特定层和微批次计算均衡方案。

运行时可以在预留的 GPU 内存中实例化热门专家的额外物理副本。它还会在原始专家及其临时副本之间分配选中的 token。

这一过程不会改变模型的逻辑路由决策。token 仍然使用模型选择的专家。UltraEP 只改变由哪个物理副本执行计算。

这种分离对训练语义非常重要。作者表示，副本梯度会在反向传播期间聚合，而主参数仍由训练框架管理。

UltraEP 还会将临时副本排除在检查点和优化器状态之外。它们是执行资源，而不是新学习出的专家。

因此，这项进展不仅仅是又一个速度更快的内核。它提出，只要硬件能够足够快速地移动权重，专家放置就可以成为对实际路由的即时响应。

为何大型 MoE 系统会让过时方案代价高昂

随着模型在更大规模的 GPU 组上使用更多专家，这种压力也会增加。

细粒度 MoE 模型可以包含数百个较小的专家。大型专家并行组可能会将这些专家分布到 32 或 64 个秩上。

这种配置使每个秩仅持有整个专家池的一小部分。因此，一个专家的需求变化会更直接地映射到单个设备的工作负载上。

当每个秩上的专家更少时，可用于抵消偏斜的无关工作负载也更少。系统会对单个热点更加敏感。

NVIDIA 的 Megatron Core 指南记录了多种路由器均衡选项，包括辅助损失、序列级损失、全局损失和动态专家偏置。

这些技术会影响模型的路由分布，但无法消除路由器处理真实 token 后每时每刻出现的波动。

训练工作负载会随着模型学习而变化。采样会引入额外抖动，不同层也可能形成不同的路由模式。

推理预填充的可预测性更低。预填充会在逐 token 生成开始前处理输入提示词。提示词长度、主题、到达率和批次组成可能同时发生变化。

编程批次的需求集中方式可能与数学或长上下文批次不同。将互不相关的请求组合起来，几秒后就可能产生另一种模式。

UltraEP 的作者认为，基于历史数据的专家放置无法足够紧密地跟随这些变化。在他们的实验中，EPLB 被配置为每三个全局训练批次以及每 50 个预填充步骤重新均衡一次。

论文报告称，过时的放置方案有时会加剧秩之间的不均衡。需求转移后，曾经热门的专家可能仍保留副本，而新的热点依然集中在一处。

这正是 UltraEP 背后的主要较量：基于精确实时数据进行均衡，与依据历史负载进行周期性预测之间的竞争。

这场较量的本质并不是小红书与 NVIDIA 或 SGLang 这些公司之间的对抗。Megatron-LM 和 SGLang 是集成框架和实验基线，二者都有可能承载新的均衡系统。

真正面临压力的是那些将专家放置视为慢速控制平面决策的基础设施设计。UltraEP 将这一决策拉入了热路径。

论文在 128 个 GPU 上评估了 GLM-4.5-106B 的训练。Qwen3-235B 和 DeepSeek-V3 的训练则使用了分布在四个机架上的 256 个 GPU。

Qwen3-235B-A22B 是展示相关规模的一个实用示例。官方 Qwen 仓库将其描述为一个拥有 2350 亿参数、每个 token 激活 220 亿参数的模型。

在生产测试中，研究人员使用了内部 RefMoE-288B-A16B 模型，并采用 32 路专家并行。他们报告称，UltraEP 在该次运行中维持了超过理想吞吐量 92% 的水平。

团队还报告称，与未启用均衡的采样时段相比，平均性能提升了 9.6%。论文称，其训练损失曲线遵循了预期轨迹。

这项生产测试很有价值，因为它超出了短期基准测试窗口。然而，论文并未披露完整的工作负载、集群经济性或运行故障历史。

因此，该结果支持 UltraEP 在作者环境中的生产可行性，但并不能证明每个大型 MoE 集群都能获得类似收益。

该机制依赖高速专家复制

UltraEP 通过同时解决放置和 token 重路由问题，并将大部分副本传输隐藏在计算过程中来发挥作用。

运行时首先获取路由后生成的精确负载矩阵。该矩阵记录了来自每个源秩的多少个 token 选择了各个逻辑专家。

随后，UltraEP 会搜索目标工作负载阈值。其目标是在遵守可用副本槽位限制的同时，使每个 GPU 秩都低于该阈值。

配额驱动的规划器决定哪些热门专家需要副本、这些副本应在哪里运行，以及每个实例应接收多少个 token。

这种联合决策不同于先选择专家副本、再分配 token 的做法。只有当方案为副本分配了有效工作时，才会创建该副本。

规划器还倾向于保证局部性。token 可以先消耗附近或本地专家实例的容量，然后系统再将剩余需求发送到其他位置。

设定聚合配额后，运行时会将其转换为逐 token 的目标位置。论文将这一步描述为在累积配额上执行局部查找。

规划器完全在 GPU 上运行，从而避免在每一层内部进行 CPU 同步和主机与设备之间的元数据传输。

这一选择解决了实时均衡的一个明显问题：如果计算精确方案造成的模型停顿时间超过负载不均衡本身，那么该方案就几乎没有价值。

规划只是问题的一半。目标 GPU 必须先获得专家的当前权重，才能处理重新分配的 token。

训练让这一过程更加困难，因为权重会在优化器更新后发生变化。运行时不能假设在许多批次之前复制的副本仍然是最新的。

UltraEP 会在每个秩上预留冗余专家槽位。在某一层运行期间，它使用设备端传输任务将所需的专家状态流式传输到这些槽位中。

论文将其称为持久化分块流式传输。专家张量会被划分成更小的分块，使传输能够持续使用机架网络，并与其他工作重叠执行。

当许多 GPU 请求同一个专家时，单个源秩可能成为通信热点。UltraEP 通过基于中继的扇出机制来解决这一问题。

原始持有者将数据块发送到选定的中继秩。在传输继续进行的同时，这些秩再将数据块转发到其他目标位置。

这种结构会将传出流量分散到拥有可用带宽的设备上。它更像一棵流式分发树，而不是由单个源反复执行点对点复制。

研究人员报告称，其通信设计复制专家状态的速度比评估中的主流通信后端快 3.1 至 5.5 倍。

UltraEP 与 DeepSeek 的 DeepEP 库集成，用于 token 的分发和合并。DeepEP 负责移动经过路由的 token 数据，而 UltraEP 则管理动态专家复制和负载均衡。

据报告，独立的 UltraEP 运行时包含约 9,600 行 C++ 和 Python 代码，其中包括设备内核。Megatron-LM 和 SGLang 的各项集成所需新增代码均少于 1,000 行。

这种模块化特性对采用至关重要。绑定到单一模型框架的均衡器进入生产环境的路径会狭窄得多。

该设计还保留了由框架管理的主专家状态。临时副本使用共享内部缓冲区，从而避免重复的优化器状态和检查点的永久膨胀。

这些选择解释了 UltraEP 如何在层粒度上重新平衡。它们也揭示了其核心依赖：该系统假设机架级节点内部具备异常高速的通信能力。

基准测试收益存在硬件边界

UltraEP 最显著的效果适用于机架级 GPU 互联架构，而非普通的多节点集群。

机架级节点将高带宽纵向扩展连接从单台服务器扩展到更大范围。论文的测试环境在每个机架的 16 台服务器中部署了 64 个 GPU。

作者报告称，该机架的纵向扩展链路所提供的带宽是其横向扩展 RDMA 网络的八到十倍。

UltraEP 将每个专家并行组限制在这一速度更快的域内。数据并行或流水线并行负责跨机架扩展。

这种拓扑为运行时提供了足够的带宽，使其能够在路由之后迁移专家权重，而不会完全暴露传输延迟。

传统以太网或带宽较低的 RDMA 集群可能无法满足这一条件。复制专家状态的代价可能高于等待过载的秩。

论文并未声称其在通用集群上都能获得同样的性能。其标题与系统设计明确针对机架级节点。

这一限制并不会否定该方法，而是界定了它适用的市场。

NVIDIA、AMD 和云服务提供商正在构建更密集、配备高速加速器互联架构的机架级系统。UltraEP 将这类硬件视为一种可编程资源，用于动态执行模型。

报告中的训练对比使用 Megatron-LM 作为不进行负载均衡的基线。在 GLM-4.5-106B、Qwen3-235B 和 DeepSeek-V3 上，UltraEP 将平均吞吐量提升了 42%。

其他接受评估的均衡方案也提升了吞吐量，但幅度较小。论文将它们表现较弱归因于布局延迟、复制预算有限或重路由效果不佳。

UltraEP 的平均训练吞吐量达到了强制均衡理想值的 94.6%。该理想值通过修改路由器来均匀分配 token，因此它代表的是人为设定的上限，而非可部署的模型行为。

在服务预填充阶段，UltraEP 的平均吞吐量达到了理想值的 93.9%。据报告，各项测试结果介于 90% 至 97% 之间。

研究人员重放了从 SGLang 捕获的路由轨迹，以确保不同均衡算法面对一致的负载条件。他们报告称，其吞吐量是 SGLang 的 1.56 倍、EPLB 的 1.29 倍。

SGLang 已经支持多种专家并行通信与计算后端。其专家并行文档展示了部署结果如何取决于硬件、量化方式和后端选择。

UltraEP 与 SGLang 的对比使用了 0.5.9 版本以及一个指定的 commit。该领域的软件发展迅速，后续框架版本可能会缩小或改变测得的差距。

评估还主要关注训练和服务预填充，并未将 UltraEP 描述为适用于自回归解码的通用解决方案。

解码在每一步中处理的新 token 数量较少，而且通常受内存限制。在这些更短的操作期间迁移完整的专家权重，意味着不同的成本关系。

基准测试方法还存在另一项限制。针对三个公开模型的训练对比均从后期检查点恢复，并继续运行了 20 个全局批次。

研究人员选择这一窗口是为了覆盖多个均衡间隔。它无法替代针对每个基线开展的完整独立训练。

作者确实进行了时间更长的内部生产训练，并报告称收敛性得以保持。然而，外部研究人员无法复现其私有模型、语料库或确切的云环境。

内存开销同样值得关注。UltraEP 为冗余专家预留了槽位，不过论文报告称，均衡后的 token 激活峰值内存有所下降。

运营团队仍必须为临时权重和通信缓冲区预留容量。适当的预留量将取决于专家规模、精度、工作负载偏斜程度和拓扑结构。

最后，公开可用性仍不明确。论文披露了实现规模和集成细节，但没有提供可见的 UltraEP 仓库链接。

公开论文并不等同于开源软件。在代码、构建说明和许可证发布之前，外部团队可以研究其机制，但无法直接审计其实现。

UltraEP 的结果改变了 MoE 基础设施之争

论文表明，未来的 MoE 效率提升将来自对工作负载状态的响应，而不只是改进静态内核。

分布式 MoE 优化通常集中在三个方面。团队改进 token 分发、融合分组矩阵运算，并在训练期间调整路由器行为。

UltraEP 增加了另一个层面。它在看到路由器的实际决策后，改变物理执行布局。

这种设计不会取代通信库或高速矩阵内核。它位于这些组件之上，决定每项专家计算应在哪里执行。

这种区别为收益叠加创造了空间。一个部署方案可以同时采用更好的路由目标、优化的全对全分发、更快的专家内核以及实时物理复制。

基于历史的放置方式不会消失。当需求变化缓慢，或者硬件无法快速迁移专家权重时，它仍然成本更低。

预测还可以在确切需求到来之前为系统做好准备。混合方案可以使用历史数据确定基础布局，再利用精确负载进行有限修正。

UltraEP 使这种比较变得可量化。未来的系统需要证明，当精确负载修正具备实用性后，预测式放置是否仍有竞争力。

这项工作还改变了基础设施团队理解利用率的方式。较低的平均 GPU 利用率可能掩盖的是同步问题，而非内核性能不足。

如果一个秩过载而其他秩都在等待，提高平均内核速度可能几乎无法改变关键路径。均衡最慢的秩可以带来更大的系统级收益。

这一经验并不仅适用于基础模型训练。分类、文档分析、推荐、验证和批量推理服务中也会出现大规模预填充工作负载。

处理多种企业文档的公司可能会面临快速变化的专家需求。法律文本、源代码、财务报告和客服对话可能会激活不同的专家组合。

这类工作负载也会以不均衡的批次到达。队列可能毫无预兆地从简短的客户消息转变为冗长的技术文档。

据报告，UltraEP 的优势会随着这种波动而扩大。这使该系统不仅与预训练前沿模型的团队相关，也与处理异构提示词的运营团队相关。

不过，其经济价值取决于利用率和硬件成本。吞吐量的百分比提升并不意味着迁移到机架级架构必然划算。

团队需要将额外预留的内存、互联架构要求、工程复杂度和可靠性，与更高吞吐量的价值进行比较。

他们还需要运维控制机制。动态专家复制会在缓冲区管理、同步、梯度聚合和传输调度方面引入新的故障模式。

论文呈现的是一个经过精心协同设计的运行时，而不是任何集群都能安全启用的配置开关。

对于 Megatron-LM、SGLang、vLLM 和 DeepEP 的贡献者而言，UltraEP 提供了一个具体的实现目标。框架维护者可以测试类似的规划机制是否应被纳入现有运行时。

对于加速器厂商而言，论文凸显了对等内存访问和设备发起通信的价值。如果软件无法高效调度不规则的专家传输，仅有更快的链路仍然不够。

对于模型设计者而言，这些结果减轻了与专门化路由相关的一项系统代价。更好的执行均衡可能允许路由遵循 token 的实际需求，而不必强制施加人为的严格均匀性。

这一点十分微妙。路由器侧的均衡损失可以推动 token 分配趋向于均等的专家利用率，但过大的压力可能会干扰专家的专业化。

UltraEP 尝试保留模型的逻辑选择，仅均衡其物理执行。如果能被独立复现，这种分离可能会成为它最重要的贡献。

UltraEP 发布后值得关注的事项

三个信号将决定 UltraEP 是成为一种基础设施范式，还是仍停留在引人注目的研究原型阶段。

第一个信号是公开代码。一个可验证的仓库应包含运行时、支持的硬件、构建流程、框架补丁、测试和许可证。

开放代码将允许外部团队检查 GPU 规划器和复制流水线。它还可以明确“开源 UltraEP”一词描述的是软件，还是仅指公开发布的研究。

在 Qwen3-235B 上进行独立复现将进一步增强报告结论的可信度。可比结果应披露 GPU 类型、互联架构拓扑、精度、批次设置和框架 commit。

如果独立团队的结果接近论文报告的 94.6% 训练结果，精确负载均衡作为一种可重复技术的可信度将会提升。如果差距较大，则可能表明其优势依赖于特定环境。

第二个信号是对单一机架架构以外环境的支持。在不同机架级平台上进行测试，可以揭示性能有多少来自算法，又有多少来自特定的互联架构。

在较小集群上的结果同样具有参考价值。它们可以确定动态复制不再具备成本效益的带宽阈值。

解码支持也是这一信号的组成部分。UltraEP 目前针对训练和预填充，因为这些场景可能有足够的计算量来隐藏权重传输。

未来的解码设计需要不同的复制策略、更小的传输单元，或者在多个步骤之间实现更高程度的复用。如果无法解决解码问题，UltraEP 将只能专注于服务流程的一部分。

第三个信号是框架采用情况。原生或实验性集成到 Megatron-LM、SGLang、vLLM 或 DeepEP 中，将使该系统能够接触更广泛的工作负载。

框架采用还将促成与更新内核和通信后端之间更公平的比较。当前基线代表的是作者评估所使用的特定版本。

生产遥测数据比单次基准测试更重要。运营团队应报告尾延迟、内存余量、规划器开销、复制体变动频率，以及硬件故障期间的行为。

他们还应衡量完整运行过程中的准确率和训练收敛性。物理重路由理应保留模型语义，但长期部署比短期续训能够提供更有力的检验。

UltraEP MoE 负载均衡提出了一个明确主张：当机架级通信使即时复制的成本变得可接受时，精确的路由信息可以胜过基于历史的放置方式。

论文中的数据在作者的环境内支持这一主张。42% 的训练增益和 1.56 倍的预填充结果足以引起重视，但还不足以跳过复现验证。

开发者在规划部署之前，应等待代码和可复现的基准测试。基础设施采购方应确认其互联架构能否支持在每一层的关键路径上迁移专家。

评估这项研究的团队可以将论文、基准测试笔记和部署决策保存在可搜索的工程知识库中。当前最重要的问题是，独立结果能否让 UltraEP 从一篇令人印象深刻的论文转变为可部署的 MoE 基础设施。