智猩猩AI整理
编辑：林夕
今年4月，DeepSeek先更新了DeepEP V2，随后，DeepSeek-V4预览版正式发布。
而如今，DeepSeek刚发布V4.1-Flash，V4.1-Pro也已经被官方提前“点名”。在下一款模型还没亮相之前，DeepSeek又把目光投向了大模型底层基础设施。
这一次，DeepSeek更新了DeepEP，最新代码进一步补充了面向MoE训练的通信能力。
这次没有新模型，也没有Benchmark，更新直接落在MoE训练的通信层。
从Buffer拆分、显存规划，到批量集合通信、冗余专家处理，再到缓存与Engram支持，DeepEP V2.5对原有架构进行了进一步调整。
DeepEP是一套面向专家并行（Expert Parallelism，EP）的高性能通信库，主要负责MoE模型中的Token Dispatch和Combine。
官方目前将EP作为核心能力，同时提供Pipeline Parallelism、Context Parallelism和Engram等实验性能力。
对于MoE模型来说，参数规模可以做得很大，但每个Token实际只会激活少量专家。
随着专家数量和GPU规模不断扩大，Token需要在不同GPU之间频繁传输，专家计算完成后还要再把结果汇总回来。
GPU算力决定了模型能跑多快，GPU之间的通信效率同样会影响训练吞吐。尤其是在大规模MoE训练中，通信很容易成为影响整体效率的关键环节。
DeepEP解决的就是这部分通信问题。
因此，这次V2.5首先改动了DeepEP的核心组件——Buffer。
此前DeepEP V2将高吞吐、低延迟的EP通信统一到ElasticBuffer接口，并重新设计了专家并行通信。
官方资料显示，V2相比V1大幅减少了通信所需的SM资源，同时将扩展范围提升到了更大的scale-up和scale-out规模。
到了V2.5，原来的ElasticBuffer进一步拆分成EPBuffer、EngramBuffer、PPBuffer和BucketBuffer。
其中，EPBuffer负责专家并行通信，PPBuffer面向流水线并行，EngramBuffer对应远程内存场景，BucketBuffer则用于批量集合通信。
几个Buffer依然共享统一的生命周期管理，但不同通信场景开始由不同组件负责。
与此同时，V2.5加入了 BufferAllocator。
创建通信Buffer之前，系统会先计算对称张量的布局和显存需求，再进行实际分配。
对于大模型训练来说，GPU显存需要同时放置模型参数、激活值、梯度以及通信过程中的临时数据。
Buffer提前规划，可以减少通信内存分配带来的浪费，也让不同通信组件的显存使用更加可控。
V2.5另一个明显变化，是BucketBuffer开始支持更通用的集合通信。
包括all-gather、reduce-scatter和all-reduce在内的批量通信操作，都可以通过这套Buffer体系处理，普通PyTorch张量也能够复用同一套通信会话。
也就是说，DeepEP虽然仍然以MoE专家并行为核心，但底层通信组件已经开始覆盖更多分布式训练场景。
这次更新还加入了对冗余专家的通信支持。
MoE采用稀疏激活，一个Token只会选择少量专家参与计算。但训练过程中，不同专家接收到的Token数量可能并不均衡，因此实际系统会通过专家复制等方式缓解热点专家带来的负载压力。
DeepEP V2.5新增了对应的通信机制。
例如，lb_prefetch_weights可以在专家计算之前，通过NVLink预取专家权重和量化尺度；lb_reduce_grads则会在反向传播阶段，把冗余专家产生的FP32梯度重新累加到原始专家。
专家复制之后，权重怎么搬、梯度怎么合，也被纳入了DeepEP的通信体系。
除此之外，V2.5还补充了延迟EP收尾、缓存扩展布局以及专家间零填充等能力，并进一步完善多层Engram存储，可以让不同层的数据分别存放在GPU或CPU上。
旧版本的V1 API、NVSHMEM后端以及相关旧文档则被清理。
从整个版本演进来看，DeepEP V2已经不再是简单对V1进行性能优化。
官方将V2定位为对Expert Parallelism的一次完整重构，并从NVSHMEM后端转向更轻量的NCCL Gin后端。
官方此前还披露，针对类似DeepSeek-V3的训练场景，DeepEP V2可以将通信所需的SM资源从V1的24个降低到4—6个，同时保持相当或更好的性能。
这次更新更重要的变化，还是通信架构本身的拆分和能力补齐。
对于超大规模MoE训练来说，Token需要在不同GPU之间持续流动，专家复制需要同步权重和梯度，不同通信任务还要争夺有限的显存和SM资源。
因此，模型规模继续扩大之后，训练系统的瓶颈也会越来越多地落到这些底层环节上。
DeepEP从最初面向MoE专家并行的高性能通信库，到V2重新设计Expert Parallelism，再到V2.5进一步拆分Buffer、加入集合通信和冗余专家处理，正在覆盖越来越多MoE训练中的基础通信问题。
从4月的DeepEP V2，到如今的V2.5，DeepSeek一直在继续补齐大规模MoE训练所需要的底层基础设施。
模型还在继续升级，支撑这些模型运行的通信、显存和分布式基础设施，也在同步往更大规模推进。
这次DeepEP V2.5，就是DeepSeek继续把这部分底层能力开源出来的一次更新。
