采用 Mixture-of-Experts（MoE）架构的大型语言模型在没有相应计算量增加的情况下显著提升了模型容量。然而，这种方法也引入了一些挑战，尤其是在 GPU 之间的通信方面。在 MoE 模型中，对于任何给定的 token，只有一部分专家是活跃的，因此在设备之间高效地交换数据至关重要。传统的全对全（all-to-all）通信方法可能会造成瓶颈，增加延迟，并导致 GPU 资源利用不足。在对延迟敏感的场景中，如实时推理，即使是微小的延迟也可能影响整体性能。此外，尽管低精度运算（如 FP8）有助于减少内存使用，但需要精心优化以保持模型质量。这些问题凸显了需要一个针对专家并行（expert parallelism）特定需求量身定制的通信库。
DeepSeek AI 最近推出了 DeepEP，这是一个专门为 MoE 模型和专家并行（EP）设计的通信库。DeepEP 解决了在 GPU 之间分发和聚合 token 时固有的低效问题。该库提供了高吞吐量、低延迟的全对全 GPU 内核——通常称为 MoE 分发和合并内核——在训练和推理期间简化了数据交换。值得注意的是，DeepEP 支持低精度运算（包括 FP8），与 DeepSeek-V3 论文中详细描述的技术一致。此次发布直接应对了在节点内和节点间环境中扩展 MoE 架构的挑战。
技术概述和优势
DeepEP 提供了两种主要类型的内核，以满足不同的操作需求：
-
普通内核（Normal Kernels）： 这些内核针对需要高吞吐量的场景进行了优化，例如推理的预填充阶段或训练。它们通过利用 NVLink 和 RDMA 网络技术，高效地在 GPU 之间转发数据。例如，在带有 NVLink 的 Hopper GPU 上进行的测试显示，节点内通信的吞吐量约为 153 GB/s，而使用 CX7 InfiniBand（大约 50 GB/s 带宽）的节点间测试实现了约 43–47 GB/s 的稳定性能。通过最大化可用带宽，这些内核减少了在 token 分发和结果合并期间的通信开销。
-
低延迟内核（Low-Latency Kernels）： 对于响应速度至关重要的推理任务，DeepEP 提供了仅依赖 RDMA 的低延迟内核。这些内核专门处理小批量数据——在实时应用中很常见——据报道，涉及八个专家的分发操作的延迟低至 163 微秒。设计中还包含了一种基于钩子（hook-based）的通信-计算重叠技术，允许数据传输与计算同时进行，而不占用 GPU 流式多处理器（SMs）。
DeepEP 还通过自适应配置提供了灵活性。用户可以调整参数，如正在使用的 SM 数量，或设置环境变量（例如，NVSHMEM_IB_SL）以管理流量隔离。自适应路由目前在低延迟内核中得到支持，有助于在高负载下均匀分配网络流量，从而提高鲁棒性。
性能洞察和实际成果
DeepEP 的性能指标值得关注。在使用普通内核进行的典型测试中，节点内通信的吞吐量可高达 153 GB/s，而节点间设置在 RDMA 上保持约 43–47 GB/s。低延迟内核在生产场景中特别有效；对于使用八个专家处理的 128 个 token 的一批数据，分发延迟可低至 163 微秒。这些改进意味着整体推理过程变得更加高效，允许使用更大的批量大小，并使计算和通信之间的重叠更加顺畅。
实际上，这些优化带来了更快的推理解码响应时间和更高的训练场景吞吐量。包含 FP8 支持不仅降低了内存占用，还促进了更快的数据传输，这对于在资源有限的环境中部署模型至关重要。
结论
DeepEP 是对大规模语言模型部署领域的一项深思熟虑的贡献。通过解决 MoE 架构中的关键通信瓶颈，它使训练和推理更加高效。其双内核方法——一套旨在实现高吞吐量，另一套旨在实现低延迟——为各种应用提供了灵活性。内置对低精度运算的支持，并配备自适应配置机制，DeepEP 为研究人员和开发人员提供了一个实用的工具，以进一步优化专家并行。
详见：https://github.com/deepseek-ai/DeepEP
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
