2月25日消息，继昨天开源Flash MLA后，DeepSeek今日向公众开源了DeepEP——第一个用于MoE模型训练和推理的开源EP通信库。
据介绍，DeepEP是一个用于MoE（混合专家）模型训练和推理的EP（Expert Parallelism）通信库，它为所有GPU内核提供高吞吐量和低延迟，也称为MoE调度和组合。该库还支持低精度操作，包括FP8。
同时，DeepEP针对NVLink（NVLink是英伟达开发的高速互联技术，主要用于GPU之间的通信，提升带宽和降低延迟）到RDMA（远程直接内存访问，一种网络数据传输技术，用于跨节点高效通信）的非对称带宽转发场景进行了 优化，不仅提供了高吞吐量，还支持SM（Streaming Multiprocessors）数量控制，兼顾训练和推理任务的高吞吐量表现。
对于对延迟敏感的推理解码，DeepEP包含一组低延迟内核和纯RDMA，以最大限度地减少延迟。该库还引入了一种基于钩子的通信计算重叠方法，该方法不占用任何SM资源。
DeepSeek称，DeepEP的实现可能与DeepSeek-V3论文略有不同。
DeepSeek还列出了DeepEP的实际性能：
在H800（NVLink的最大带宽约为160 GB/s）上测试常规内核，每台设备都连接到一块CX7 InfiniBand 400 Gb/s的RDMA网卡（最大带宽约为50 GB/s），并且遵循DeepSeek-V3/R1预训练设置（每批次4096个Tokens，7168个隐藏层单元，前4个组，前8个专家（模型），使用FP8格式进行调度，使用BF16格式进行合并）。
在H800上测试低延迟内核，每台H800都连接到一块CX7 InfiniBand 400 Gb/s的RDMA网卡（最大带宽约为50 GB/s），遵循DeepSeek-V3/R1的典型生产环境设置（每批次128个Tokens，7168个隐藏层单元，前8个专家（模型），采用FP8格式进行调度，采用BF16格式进行合并）。
DeepEP运行环境要求：
Hopper GPU（以后可能支持更多架构或设备）
Python 3.8及以上版本
CUDA 12.3及以上
PyTorch 2.1及以上版本
NVLink用于内部节点通信
用于节点间通信的RDMA网络
（免责声明：本网站内容主要来自原创、合作伙伴供稿和第三方自媒体作者投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。
任何单位或个人认为本网站中的网页或链接内容可能涉嫌侵犯其知识产权或存在不实内容时，应及时向本网站提出书面权利通知或不实情况说明，并提供身份证明、权属证明及详细侵权或不实情况证明。本网站在收到上述法律文件后，将会依法尽快联系相关文章源头核实，沟通删除相关内容或断开相关链接。 ）
