大规模专家并行 (EP) 在 TensorRT-LLM 的设计动机与系统分析

热门资讯 2025年09月07日 14:56 1 admin

DeepSeek-V3 / R1 等模型采用大规模细粒度混合专家模型 (MoE) 架构，大幅提升了开源模型的质量。Llama 4 和 Qwen3 等新发布的开源模型的设计原则也采用了类似的大规模细粒度 MoE 架构。但大规模 MoE 模型为推理系统带来了新的挑战，如高显存需求和专家间负载失衡等。

之前，我们介绍过突破 DeepSeek R1 模型低延迟极限的 TensorRT-LLM 优化措施，多 Token 预测 (MTP) 的实现与优化以及提高 DeepSeek R1 吞吐量性能的优化措施。

DeepSeek 团队还分享了优化此类大规模专家并行 (EP) 模型 (如 DeepEP 和 EPLB) 的宝贵经验与实践。此外，DeepSeek 团队在这份[1] 技术报告中详细阐述了具体设计考虑因素。除此之外，社区中也有在其他推理引擎中实现大规模 EP 的优秀实践，例如 SGLang 团队的这个项目[2]。

这篇技术博客共分为上中下三篇，将介绍支持 TensorRT-LLM 中端到端大规模 EP 的详细设计与实现，主要包含以下内容：

如何使用 NVIDIA 多节点 NVLink (MNNVL) 硬件特性来实现高性能通信内核。

如何设计和实现在线专家负载均衡器，以动态平衡专家负载分布并适应在线流量模式的变化。我们将展示：

证明此类优化措施必要性的经验数据分析。

在线流量数据统计模块的实现。

复制和放置策略的设计与实现。

用于平衡多个 GPU 间在线工作负载的 MoE 权重负载和重新分配器。

为适应专家负载均衡器需求而对 MoE 路由器和计算模块进行的必要修改。

一些证明当前 TensorRT-LLM 中实现效果的初步数据。

未来的技术博客还将涵盖以下主题：

对 TensorRT-LLM 大规模 EP 实现的性能调优和优化的介绍。

如何在不使用 MNNVL 的情况下，为 Hopper 和其他 NVIDIA GPU 实现高效的大规模 EP 支持。

使用大规模 EP 并获得性能提升的最佳实践。

如何将大规模 EP 与其他系统优化技术相结合。

虽然本技术博客主要讨论 TensorRT-LLM，但我们相信其核心理念和实现方法也可用于其他推理引擎在 NVIDIA GPU 上的推理性能。此外，我们希望借助社区的力量，探索如何更好地将当前 TensorRT-LLM 大规模 EP 实现模块化，使其更容易被社区复用。

最后，本博客包含针对 Grace Blackwell 机架式系统的详细实现方式，例如使用 Grace Blackwell 机架式系统跨 GPU 连接的通信组件，以及使用 Grace CPU 与 Blackwell GPU 间高带宽 C2C 连接的 MoE 权重加载和重新分配模块等。但整体设计原则和软件架构仍适用于非此 NVIDIA GPU 系统。为了便于扩展到其他非此系统，我们有意识地关注了设计和实现的通用性。这些更改应能与现有其他组件轻松组合。

引入大规模 EP 的初衷

引入大规模 EP（本文中指 EP > 8）主要基于以下系统考量：

我们希望通过提高聚合显存带宽来加载专家权重，从而降低执行延迟。

我们希望通过增加有效批处理大小充分利用 GPU 算力。

需注意，当端到端 (E2E) 执行时间主要由 MoE GroupGEMM 计算主导时，引入大规模 EP 可显著提升性能。但若端到端执行时间未被 MoE GroupGEMM 计算主导，引入大规模 EP 提升的性能有限。

系统设计中不存在“免费的午餐”。当 EP 规模增大到超过 8（有时甚至不到 8）时，由于 MoE 模型的稀疏执行特性，会自动触发 EP 级别的负载失衡问题。

以下是一些基于特定数据集的经验观察（所有分析均使用 DeepSeek R1 模型在 32 个 GPU 上进行）：

对一个机器翻译数据集的观察结果

首先，我们将概述各层的整体失衡问题：

图 1. 从 rank 0 发送到所有 rank（包括 rank 0）的 Token 数（对应解码迭代 1950）及所有 MoE 层

如图 1 所示，在第 36 层的 MoE 中，从 rank 0 发送到 rank 13 的 Token 数明显更多。

如果我们放大第 36 层的 MoE 并记录其激活专家 rank 的分布，可以清楚地看到有一个 rank 被更频繁地激活：

图 2. 第 36 层每个专家 rank 接收的 Token 数量

如果我们将数据展平以查看每个专家接收的 Token 数量，可以发现有一些专家比其他专家更活跃：

图 3. 第 36 层每个专家接收的 Token 数量

值得注意的是，这种失衡问题在多次迭代中非常稳定，如下图所示：

图 4. 第 36 层每个专家在 50 个解码步骤内接收的 Token 总数，本地 batch size=256。

显然，图 4 中的热门专家与图 3 中仅包含单次解码迭代数据的专家相同。我们还对本地 batch size=1（对应单次请求）进行了基于持续时间的分析，观察到类似的模式：

图 5. 第 36 层每个专家在 400 次解码迭代内接收的 Token 总数，本地 batch size=1。

综上所述，针对该机器翻译数据集的研究结果可总结为：

某些层中存在一些热点，部分 EP 所在 GPU 的负载可能远高于其他 EP。

其原因可能是最热门专家或多个热门专家位于同一 rank。

路由 Token 的分布可能在数十至数百个迭代步骤甚至更多迭代步骤内保持一致。

在单个请求的执行中，不同迭代步之间也存在相同的热门专家。

另一个实际问题是上述观察结果在其他数据集上是否会发生显著变化。因此，我们对 GSM8K 数据集进行了类似的分析。

对 GSM8K 数据集的观察结果

图 6. 从 rank 0 发送到所有 rank 的 Token 数（对应第 1950 个迭代步）及所有 MoE 层

如图 6 所示，与图 1 相比，GSM8K 数据集中的热门层变成了第 57 层而非第 36 层。那么 GSM8K 数据集中第 36 层的具体情况如何？

图 7. 从 EP rank 0 发送到其他 EP rank 的 Token 数（仍以迭代 1950、MoE 第 36 层为例）

从图 7 可以清楚地看到，工作负载失衡于不同数据集（图 2 所示）中观察到的情况不同。在图 8 中可以观察到在 GSM8K 数据集上，工作负载的失衡在多次迭代中也相对稳定。这与之前的机器翻译数据集相同。

图 8. 从 EP rank 0 发送到所有 rank 的 Token 总数（MoE 第 57 层，50 个解码步骤内，本地 batch size=256）

如果我们将每个 GPU EP 层面的数据展平为专家层面，可以得到下图。

图 9. 第 57 层的每个专家在 50 个解码步骤内接收的 Token 总数，本地 batch size=256

单个请求中也存在类似的失衡模式。

图 10. 单次请求下第 57 层的每个专家在 400 个解码步骤内接收的 Token 总数

如果使用另一个请求，我们仍然可以观察到专家失衡问题。虽然热门专家可能不同，但有一些是共同的（在此示例中是专家 10）。

图 11. 单次请求下第 57 层每个专家在 400 个解码步骤内接收的 Token 总数

通过对两个数据集的数据分析，我们得出以下结论：

EP 级别工作负载失衡问题在多个数据集的大规模 EP 推理中较为常见。且 EP 失衡的严重程度可能因层而异。此外，EP 失衡的问题具有数据集敏感性。

EP rank 级别失衡问题可能由某个最热门的专家或多个热门专家长期占据同一 EP rank 引起。

EP rank 失衡分布在数十到数百次迭代中相对稳定。

尽管 EP rank 失衡分布在时间维度上具有稳定性，但不同请求的 EP 失衡分布可能有所不同。

这些发现可指导我们对 TensorRT-LLM 大规模 EP 实现的设计考量：

设计时需考虑 EP 失衡问题以确保端到端的性能。

基于实时在线请求流量的在线 EP 负载均衡器（而非仅实现离线 EP 负载均衡器）对确保 EP 均衡器的稳健性至关重要。

可运用 EP rank 失衡分布的时间维度稳定性，以高效的方式将 MoE 权重重新分配至不同 EP rank。

在下一篇文章中，我们将深入探讨 TensorRT-LLM 大规模 EP 的整体实现架构、负载均衡策略与性能优化实践。

引用

[1] DeepSeek-V3 技术报告:

https://arxiv.org/abs/2412.19437

[2] SGLang 团队项目：

https://lmsys.org/blog/2025-05-05-large-scale-ep/

作者

杨东旭

现任职于 NVIDIA Compute Arch 部门。主要负责 LLM 推理系统的开发和性能优化。加入 NVIDIA 之前，曾从事搜索系统的 GPU 加速和开发工作。

乔显杰

NVIDIA Compute Arch 部门高级架构师，主要负责 LLM 推理的性能评估和优化。加入 NVIDIA 之前，他曾从事推荐系统的 GPU 加速研发工作。

谢开宇

NVIDIA Compute Arch 部门高级架构师，主要负责 TensorRT-LLM 项目的开发，专注在系统性能和优化工作。

朱恩伟

NVIDIA DevTech 部门高级工程师，主要负责 TensorRT-LLM 项目的开发和性能优化。

陈晓明

NVIDIA Compute Arch 部门的首席架构师和高级经理，对深度学习模型的算法软硬件协同设计感兴趣，最近从事大语言模型推理的性能建模、分析和优化。

三分钟了解“微信小程序安徽麻将能作假吗”（输赢有什么规律)

给大家科普一下“微信小程序陕西麻将怎么才能拿到好牌”（开挂辅助器脚本)

发表评论

大规模专家并行 (EP) 在 TensorRT-LLM 的设计动机与系统分析

三分钟了解“微信小程序安徽麻将能作假吗”（输赢有什么规律)

给大家科普一下“微信小程序陕西麻将怎么才能拿到好牌”（开挂辅助器脚本)

最新评论

最新留言

标签列表