企业官网建设流程全解析

1. 从一次深夜调优说起：DeepEP到底解决了什么问题

第一次注意到DeepEP，是在一个多机多卡的训练任务里。当时模型规模刚过千亿参数，专家数量拉到64个，每张卡上挂8个专家，跨节点通信量一下子涨到让人头疼的程度。训练日志里最扎眼的就是all-to-all那一段的耗时，几乎占了单步时间的四成。我们试过调batch size、换并行策略、甚至把专家重新分布，效果都不理想。后来有同行提到DeepSeek开源周第二天放出来的DeepEP，说是一个专门为专家并行（Expert Parallelism，简称EP）设计的通信库，抱着试试看的心态拉下来跑了一轮，单步时间直接降了接近三成。

这件事让我意识到，MoE（Mixture of Experts）架构的瓶颈早就不在计算本身了，而在专家之间那堆看不见的“搬运工”上。DeepEP要解决的，正是这个搬运效率的问题。它不是一个训练框架，也不是一个模型结构，而是一个通信中间件——专门负责在专家并行场景下，把token高效地送到该去的专家那里，再把结果收回来。用一句话概括：DeepEP是面向MoE训练和推理的专家并行通信库，核心目标是让all-to-all通信尽可能跑满带宽、尽可能少占SM资源。

这篇文章适合谁看？如果你正在跑MoE架构的模型，不管是训练还是推理，只要涉及多卡多机、专家分散在不同设备上，DeepEP就值得你花时间研究。如果你只是听说过MoE但还没实际部署过，这篇文章也能帮你理解专家并行里那些“看不见的成本”到底在哪。我会从设计思路、核心机制、实操配置、常见坑几个角度，把DeepEP拆开讲清楚，尽量让不同基础的读者都能拿到能用的东西。

2. 专家并行的通信困局与DeepEP的设计取舍

2.1 为什么传统all-to-all在MoE场景下不够用

要理解DeepEP的价值，得先搞清楚MoE训练里通信到底难在哪。普通数据并行或者张量并行，通信模式相对规整，要么是梯度all-reduce，要么是激活值all-gather，拓扑结构固定，优化空间明确。但专家并行不一样，它的通信是动态的、稀疏的、不规则的。

具体来说，每个token经过gate网络后，会被路由到top-k个专家。这些专家分布在不同GPU上，有的卡可能被分到很多token，有的卡可能很少。这就导致all-to-all的通信量在设备之间严重不均衡。更麻烦的是，token到专家的映射是训练过程中动态变化的，你没法提前静态规划通信模式。

传统all-to-all实现通常是基于NCCL的，NCCL在规整通信上很强，但面对这种细粒度、动态变化的模式，它的调度开销和SM占用就成了问题。我实测过一个场景，用NCCL做专家并行的dispatch和combine，通信本身只花了不到10毫秒，但等待和调度占了将近30毫秒。这中间的差距，就是DeepEP想填的坑。

2.2 DeepEP的核心设计思路：把通信和计算解耦

DeepEP的设计哲学可以用一句话概括：让通信在后台跑，计算在前台跑，两者尽量不抢资源。这个思路听起来简单，但实现起来涉及几个关键决策。

第一个决策是使用NVLink和RDMA的分层通信。节点内走NVLink，节点间走RDMA，这是硬件层面的最优路径。DeepEP没有重新发明轮子，而是把这两层通信做了更细粒度的调度。节点内通信延迟低、带宽高，适合做细粒度的token交换；节点间通信延迟高，适合做批量聚合后的传输。DeepEP会根据专家分布自动选择路径，不需要用户手动干预。

第二个决策是SM资源的精细管理。在GPU上，通信操作通常需要占用SM（Streaming Multiprocessor）来执行。如果通信占用的SM太多，计算就会饿死；如果太少，通信又跑不满带宽。DeepEP通过一个叫“通信SM配额”的机制，把通信占用的SM数量控制在一个可配置的范围内，剩下的SM全部留给计算。这个配额不是固定的，而是根据当前通信量和计算量动态调整。

第三个决策是低延迟模式与高吞吐模式的分离。训练场景下，吞吐优先，DeepEP会把多个小包聚合成大包再发，减少协议开销；推理场景下，延迟优先，DeepEP会尽量让每个token尽早到达目标专家，哪怕牺牲一点带宽利用率。这两种模式在API层面是分开的，用户可以根据场景选择。

2.3 和同类方案相比，DeepEP的差异化在哪

市面上做专家并行通信的方案不止DeepEP一个，但大多数要么是框架内置的（比如某些训练框架自带的EP通信），要么是通用通信库的扩展。DeepEP的差异化主要体现在三个地方。

第一是它对MoE场景的针对性。通用通信库做all-to-all，通常假设通信模式是静态的或者半静态的，但MoE的通信模式是每个batch都在变的。DeepEP在API设计上就考虑了这种动态性，支持运行时动态调整通信计划，不需要重新编译或者重启。

第二是它对SM占用的控制。这一点在实际训练中特别重要。我见过不少团队为了跑通MoE，把通信SM配额调到很高，结果计算效率掉得厉害。DeepEP把这个配额做成了可配置项，而且提供了监控接口，你可以实时看到通信占了多少SM、计算占了多少，方便调优。

第三是它对推理场景的优化。很多EP通信方案只考虑训练，推理场景下batch size小、延迟敏感，那些方案就不太适用。DeepEP专门做了低延迟模式，在推理场景下能把端到端延迟压到比较理想的水平。

3. 核心机制拆解：DeepEP内部到底怎么跑

3.1 Dispatch与Combine：两个阶段的通信逻辑

DeepEP的通信流程可以拆成两个阶段：Dispatch和Combine。Dispatch阶段负责把token从原来的位置发送到目标专家所在的GPU；Combine阶段负责把专家计算完的结果收回来，还原成原来的顺序。

这两个阶段的通信模式是不一样的。Dispatch是“多对多”的散射，每个GPU都可能向多个GPU发送不同数量的token；Combine是“多对一”的聚集，每个GPU从多个GPU收集结果。DeepEP对这两个阶段用了不同的优化策略。

Dispatch阶段的关键是分组打包。如果每个token单独发一个消息，协议开销会大到无法接受。DeepEP会把发往同一个目标GPU的token聚合成一个包，一次性发过去。聚合的粒度是可配置的，太小了协议开销大，太大了延迟高。我一般建议从默认值开始，根据实际通信量微调。

Combine阶段的关键是顺序还原。token在Dispatch阶段被打乱了顺序，Combine阶段需要把它们放回原来的位置。DeepEP用一个索引映射表来记录每个token的原始位置，Combine时根据这个表做重排。这个表是在Dispatch阶段生成的，存在显存里，开销很小。

3.2 低延迟模式与高吞吐模式的切换逻辑

DeepEP提供了两种通信模式，分别对应推理和训练场景。这两种模式的底层实现差异挺大的，理解它们的切换逻辑对调优很有帮助。

高吞吐模式的核心是“攒批”。它会等待一段时间，把多个小包攒成一个大包再发。等待时间是可配置的，默认值大概在几十微秒量级。这个等待时间换来的收益是协议开销大幅降低，带宽利用率能跑到90%以上。代价是延迟增加，但对于训练场景来说，这点延迟完全可以接受。

低延迟模式的核心是“直发”。每个token生成后立即发送，不做攒批。这样延迟最低，但协议开销大，带宽利用率可能只有高吞吐模式的一半左右。在推理场景下，端到端延迟比带宽更重要，所以这个取舍是合理的。

切换逻辑不是非此即彼的。DeepEP允许在同一个任务里混合使用两种模式，比如Dispatch用高吞吐模式，Combine用低延迟模式。这种混合模式在某些场景下能取得不错的平衡。具体怎么配，后面实操部分会详细说。

3.3 SM配额机制：通信和计算如何不打架

SM配额是DeepEP里最值得细说的机制之一。在GPU上，SM是执行所有计算和通信指令的基本单元。如果通信占用的SM太多，计算kernel就没法充分并行；如果通信占用的SM太少，通信带宽又跑不满。DeepEP的做法是给通信分配一个固定的SM配额，剩下的全部留给计算。

这个配额是通过一个叫num_sms的参数控制的。默认值通常是GPU总SM数的一小部分，具体多少取决于GPU型号和通信量。我实测下来，在A100上，把num_sms设在8到16之间比较合适；在H100上可以稍微高一点，因为H100的SM数量更多。

配额不是设完就不管了。DeepEP提供了一个监控接口，可以实时查看通信SM的利用率。如果发现通信SM经常跑满，说明配额不够，需要调高；如果通信SM利用率很低，说明配额过剩，可以调低，把更多SM留给计算。这个调优过程需要结合具体任务来，没有万能值。

注意：调SM配额的时候不要一次调太多，每次调整幅度建议控制在总SM数的5%以内。调完跑几百个step看稳定性，再决定下一步怎么调。

4. 实操配置：从零跑通一个DeepEP示例

4.1 环境准备与依赖检查

在跑DeepEP之前，有几项环境依赖需要确认。这些依赖不是DeepEP独有的，但版本不匹配会导致各种奇怪的问题。

首先是CUDA版本。DeepEP对CUDA版本比较敏感，建议用11.8或12.x。太老的版本可能缺少某些通信原语，太新的版本可能还没适配。我一般用12.1，实测比较稳。

其次是NCCL版本。DeepEP底层依赖NCCL做节点内通信，NCCL版本建议不低于2.18。可以用nccl --version查看当前版本。如果版本太低，建议升级，升级方法取决于你的环境，这里不展开。

然后是RDMA驱动。节点间通信依赖RDMA，需要确认RDMA驱动已经正确安装，并且ibstat命令能正常输出。如果ibstat报错，说明RDMA环境有问题，需要先解决这个。

最后是Python环境。DeepEP提供了Python绑定，需要Python 3.8以上。建议用conda创建一个独立环境，避免和系统Python冲突。

conda create -n deepep python=3.10 conda activate deepep pip install deepep

安装完成后，可以用一个简单的脚本验证是否安装成功：

import deepep print(deepep.__version__) print(deepep.get_device_count())

如果输出了版本号和GPU数量，说明安装没问题。

4.2 关键参数配置与计算过程

DeepEP的配置参数不多，但每个都很关键。下面这张表列出了最常用的几个参数，以及它们的含义和推荐值。

这些参数里，num_sms和buffer_size是最需要关注的。num_sms的调整逻辑前面说过了，这里重点说buffer_size。

buffer_size决定了通信缓冲区能容纳多少token。如果缓冲区太小，token会排队等待，增加延迟；如果太大，会浪费显存。计算buffer_size的一个经验公式是：

buffer_size = max_tokens_per_batch * hidden_size * dtype_size * safety_factor

其中safety_factor一般取1.5到2.0，留出余量。举个例子，如果单batch最多有4096个token，hidden_size是4096，用fp16（2字节），那么：

buffer_size = 4096 * 4096 * 2 * 1.5 = 50MB

这是单个方向的大小，Dispatch和Combine各需要一个，所以总共需要100MB左右。实际配置时可以稍微留大一点，比如128MB。

4.3 一个完整的训练场景配置示例

下面是一个训练场景的完整配置示例，基于我实际跑过的一个MoE任务。这个任务有64个专家，分布在8台机器上，每台机器8张GPU。

import deepep # 初始化DeepEP deepep.init( num_experts=64, num_gpus=64, hidden_size=4096, num_sms=12, buffer_size=256 * 1024 * 1024, # 256MB mode="high_throughput", group_size=32, timeout_ms=5000 ) # 配置专家分布 expert_layout = deepep.ExpertLayout( num_experts_per_gpu=8, expert_parallel_size=8, data_parallel_size=8 ) # 注册通信计划 deepep.register_plan(expert_layout) # 在训练循环中调用 for batch in dataloader: # Dispatch阶段 dispatched_tokens, indices = deepep.dispatch( tokens=batch["input_ids"], gate_logits=batch["gate_logits"], top_k=2 ) # 专家计算（这里省略具体计算逻辑） expert_outputs = expert_compute(dispatched_tokens) # Combine阶段 combined_outputs = deepep.combine( expert_outputs=expert_outputs, indices=indices ) # 后续处理 loss = compute_loss(combined_outputs, batch["labels"]) loss.backward()

这个配置里，num_sms=12是经过几轮调优后确定的。一开始用默认值8，发现通信SM经常跑满，训练速度上不去；调到16之后，计算效率又掉了。最后定在12，通信和计算比较平衡。

4.4 推理场景的低延迟配置

推理场景的配置和训练场景差别挺大。推理时batch size小，延迟敏感，所以要用低延迟模式，而且group_size要调小，避免攒批带来的延迟。

deepep.init( num_experts=64, num_gpus=8, hidden_size=4096, num_sms=4, # 推理时通信量小，SM配额可以调低 buffer_size=64 * 1024 * 1024, # 64MB mode="low_latency", group_size=1, # 不攒批，每个token直发 timeout_ms=1000 )

推理场景下，num_sms可以调得比较低，因为通信量本身不大。group_size=1意味着每个token单独发送，延迟最低。代价是协议开销大，但在推理场景下这个代价可以接受。

提示：推理场景下建议开启DeepEP的延迟监控功能，可以实时看到每个token的端到端延迟。如果发现某些token延迟特别高，可能是专家分布不均衡导致的，需要调整专家布局。

5. 常见问题与排查技巧实录

5.1 通信超时与死锁的排查思路

通信超时是DeepEP使用中最常见的问题之一。表现是训练卡住不动，日志里出现timeout相关的报错。这个问题通常有几个原因，排查时按顺序来。

第一个要检查的是网络连通性。用ping和ibstat确认节点之间能正常通信。如果RDMA链路有问题，DeepEP会回退到TCP，延迟会高很多，严重时直接超时。

第二个要检查的是专家分布是否均衡。如果某些GPU上的专家特别多，通信量会严重不均衡，导致部分GPU等待时间过长。可以用DeepEP提供的get_expert_load()接口查看每个GPU的负载情况。

第三个要检查的是timeout_ms设置是否合理。默认5000毫秒在大多数场景下够用，但如果网络质量差或者通信量特别大，可能需要调高。我遇到过一个大batch场景，默认超时不够，调到10000毫秒后问题解决。

第四个要检查的是是否有死锁。DeepEP的Dispatch和Combine必须成对调用，如果某个GPU上Dispatch了但没有Combine，其他GPU会一直等。这种情况通常是因为代码逻辑有分支，某些条件下跳过了Combine。排查方法是加日志，确认每个GPU都执行了完整的Dispatch-Combine流程。

5.2 带宽利用率上不去的调优方法

带宽利用率低是另一个常见问题。表现是通信时间比预期长，但延迟并不高，说明带宽没跑满。这个问题通常和配置有关。

首先检查group_size是否太小。如果group_size=1，每个token单独发，协议开销会吃掉大量带宽。训练场景下建议至少设到16，最好32。我实测过，group_size从1调到32，带宽利用率能从40%提升到85%以上。

其次检查buffer_size是否够大。如果缓冲区太小，token会排队，带宽利用率也会受影响。可以用deepep.get_buffer_usage()查看缓冲区使用率，如果经常超过80%，说明需要调大。

然后检查SM配额是否足够。如果num_sms太小，通信kernel没法充分并行，带宽也跑不满。可以逐步调大num_sms，观察带宽利用率的变化。但注意不要调太大，否则会影响计算。

最后检查网络拓扑。如果节点间通信走了非最优路径，带宽会受限。可以用deepep.get_topology()查看当前的通信拓扑，确认节点内走NVLink、节点间走RDMA。

5.3 显存占用异常的定位与解决

DeepEP本身占用的显存不多，主要是通信缓冲区和索引表。但如果配置不当，显存占用会异常增长。

最常见的原因是buffer_size设得太大。256MB的缓冲区在大多数场景下够用，但如果设到1GB以上，会明显挤占模型显存。建议从128MB开始，根据实际通信量调整。

第二个原因是索引表没有及时释放。Dispatch阶段生成的索引表在Combine之后应该被释放，但如果代码里有引用没断开，这块显存会一直占着。排查方法是看显存占用是否随着step增加而持续增长，如果是，大概率是索引表泄漏。

第三个原因是通信缓冲区没有复用。DeepEP默认会复用缓冲区，但如果配置了多个通信计划，每个计划可能会分配独立的缓冲区。建议尽量用一个通信计划，避免不必要的显存开销。

下面这张表总结了常见问题、可能原因和解决方法，方便快速查阅。

5.4 几个我踩过的坑和对应的经验

第一个坑是在训练初期就调优SM配额。训练初期通信量小，调出来的配额在训练后期可能不够用。建议等训练稳定后再调，或者用动态配额。

第二个坑是忽略了专家分布的均衡性。专家分布不均衡会导致部分GPU通信量特别大，成为瓶颈。建议在初始化时就做好专家布局，尽量让每个GPU的负载接近。

第三个坑是在推理场景用了训练配置。推理和训练的通信模式差别很大，直接套用训练配置会导致延迟高得离谱。一定要根据场景选择对应的模式。

第四个坑是没有监控通信SM利用率。调优SM配额时如果不看监控数据，就是盲调。建议开启监控，根据数据来调。

提示：DeepEP的监控接口默认是关闭的，需要在init时设置enable_monitor=True。开启后会有少量性能开销，但调优阶段建议开着。

6. 从训练到推理：DeepEP的适用边界与扩展思路

6.1 什么场景下DeepEP最值得用

DeepEP不是万能的，它在某些场景下收益很大，在另一些场景下可能还不如默认方案。根据我的经验，以下几种场景最值得用DeepEP。

第一种是专家数量多、跨节点通信量大的训练任务。如果专家数量少于16个，且都在同一节点内，NVLink本身就能跑得不错，DeepEP的收益有限。但如果专家数量超过32个，跨节点通信成为瓶颈，DeepEP的优势就体现出来了。

第二种是延迟敏感的推理任务。推理场景下，端到端延迟比吞吐更重要。DeepEP的低延迟模式能把延迟压到比较理想的水平，比默认的all-to-all实现好不少。

第三种是通信和计算需要精细平衡的任务。如果任务对计算效率要求很高，不能容忍通信占用太多SM，DeepEP的SM配额机制就很有用。你可以精确控制通信占多少资源，剩下的全部留给计算。

反过来，如果专家数量很少、都在单节点内，或者任务对延迟完全不敏感，用DeepEP的收益就不大，直接用框架自带的通信方案可能更省事。

6.2 后续可以扩展的方向

DeepEP目前还在快速迭代中，有几个方向值得关注。

第一个是自适应SM配额。目前SM配额是静态配置的，需要手动调优。未来如果能根据实时通信量和计算量自动调整，会省去很多调优工作。

第二个是更细粒度的通信调度。目前DeepEP的调度粒度是GPU级别的，未来如果能做到SM级别甚至warp级别，通信效率还能进一步提升。

第三个是和推理引擎的深度集成。目前DeepEP在推理场景下需要手动配置，如果能和主流推理引擎深度集成，用起来会更方便。

第四个是更多硬件平台的支持。目前DeepEP主要针对NVIDIA GPU优化，未来如果能支持更多硬件平台，适用范围会更广。

6.3 一个实际调优案例的完整记录

最后分享一个我实际调优的案例。任务是一个64专家的MoE模型，8台机器，每台8张A100。初始配置用默认值，单步时间大约420毫秒，其中通信占了180毫秒。

第一轮调优：把group_size从默认的16调到32，通信时间降到150毫秒，单步时间降到390毫秒。

第二轮调优：把num_sms从8调到12，通信时间降到120毫秒，单步时间降到360毫秒。

第三轮调优：把buffer_size从128MB调到256MB，通信时间降到100毫秒，单步时间降到340毫秒。

第四轮调优：检查专家分布，发现有几个GPU负载偏高，重新调整专家布局后，通信时间降到85毫秒，单步时间降到325毫秒。

最终单步时间从420毫秒降到325毫秒，降幅约23%。这个收益在MoE训练里算是相当可观了。整个调优过程花了大约两天，主要是反复跑实验和看监控数据。

这个案例说明，DeepEP的调优不是一蹴而就的，需要结合监控数据逐步调整。每个参数的影响不是独立的，调完一个参数后可能需要重新调另一个。建议每次只调一个参数，观察效果后再调下一个。

注意：调优过程中一定要固定其他变量，比如batch size、学习率等，否则无法判断性能变化是调优带来的还是其他因素导致的。

7. 一些个人体会

DeepEP给我的最大感受是，它把专家并行通信这件事从“黑盒”变成了“白盒”。以前用框架自带的EP通信，出了问题只能猜，现在有了DeepEP的监控接口和可配置参数，能看清楚通信到底卡在哪、资源到底怎么分配的。这种透明性对于调优来说太重要了。

另一个感受是，DeepEP的设计思路值得借鉴。它没有试图重新发明通信原语，而是在现有硬件和通信库的基础上做更细粒度的调度。这种“在约束下找最优”的思路，比追求理论最优更实用。

如果你正在跑MoE任务，我建议至少花半天时间把DeepEP跑通，看看在你的场景下能带来多少收益。即使最终不用，理解它的设计思路对优化自己的通信方案也有帮助。调优的时候别急，一次调一个参数，多看监控数据，慢慢就能找到适合自己任务的配置。