在大规模语言模型部署中，Mixture-of-Experts（MoE）架构通过稀疏激活机制实现了参数规模与计算成本之间的巧妙平衡。DeepSeek V4 继承并优化了其前代 V3 的 MoE 设计，在 671B 总参数规模下仅激活约 37B 参数即可完成单次 Token 处理，这一约 5.5% 的激活比例为模型提供了巨大的推理成本优势。然而，稀疏路由带来的核心挑战在于：当每个 Token 动态选择专家时，如何避免部分专家因过热而导致计算瓶颈，同时确保所有专家的利用率维持在健康区间。DeepSeek 通过辅助损失 free（Auxiliary-Loss-Free）的负载均衡策略与精细化的专家并行通信优化，给出了一套可在生产环境落地的工程方案。
Token 路由机制与 Top-K 选择策略
DeepSeek V4 的 MoE 层包含 256 个可路由专家（routed experts）以及若干共享专家（shared experts），每个输入 Token 的隐藏状态会与所有专家的嵌入向量进行相似度计算，生成一组亲和力分数（affinity scores）。随后，系统选取分数最高的前 K 个专家处理该 Token，K 的取值通常为 2 或 4，具体取决于所在层的深度配置。这种 Top-K 稀疏路由机制确保了每次前向传播仅需激活全部专家中的极小 subset，从而将单次推理的计算量控制在合理范围内。
路由过程的核心在于亲和力分数的归一化与加权组合。选定 K 个专家后，各专家的输出会按照其对应的亲和力分数进行加权求和，形成最终的 MoE 层输出。这一机制与传统的密集前馈网络形成了鲜明对比：后者必须激活全部参数完成计算，而前者通过动态路由实现了参数规模的按需调用。值得注意的是，DeepSeek 采用了 Sigmoid 门控机制而非 Softmax，这是为了允许同一个 Token 被分配到多个专家进行并行处理，避免路由决策的互斥约束。
在实际部署中，路由决策还需要考虑设备拓扑约束。DeepSeek 实现了设备感知路由（device-aware routing），即在某些配置下限制每个 Token 只能在特定设备子集内选择专家，从而控制跨节点通信开销。这一设计在大规模集群推理场景下尤为重要，因为跨节点的网络延迟往往成为吞吐量瓶颈。
辅助损失 free 的负载均衡实现
传统的 MoE 模型通常引入辅助损失（auxiliary loss）来惩罚专家利用不均的问题，迫使模型在训练过程中均匀分配负载。然而，过大的辅助损失会与主任务损失产生竞争，导致模型质量下降。DeepSeek V3/V4 放弃了对辅助损失的依赖，转而采用一种更具优雅性的方法：为每个专家引入可学习的偏置项（bias term），并将其叠加到亲和力分数上进行路由决策。
具体而言，每个专家 e 关联一个可学习的偏置 b_e。在每个训练步骤中，系统会统计各专家的实际负载情况，然后对过载专家的偏置进行衰减，对欠载专家的偏置进行增强。通过这种方式，偏置项会逐渐学会将流量引导向利用率不足的专家，而无需在损失函数中显式添加平衡项。这一机制的效果在实践中得到了验证：DeepSeek V3 在 14.8T Token 的训练数据上实现了稳定的负载分布，且主任务性能未因负载均衡策略而受损。
从工程实现角度，偏置项的更新策略需要精细设计。更新频率过高会导致路由振荡，过低则无法及时响应负载变化。实践中通常采用移动平均的方式平滑负载统计，并以学习率衰减的方式逐步调整偏置幅度。对于推理阶段的负载均衡，DeepSeek 还引入了冗余专家（redundant experts）机制：在推理服务的预填充（prefilling）阶段，系统会检测高负载专家并在多个 GPU 上复制其实例，将热点专家的请求分散到不同设备，从而在不影响模型质量的前提下提升整体吞吐量。V3 的预填充阶段部署了 32 个冗余专家，每个 GPU 除了本地 8 个专家外，还可额外承载一个热门专家的副本。
DeepEP 专家并行通信库
MoE 架构的实际部署离不开高效的专家间通信机制。当 Token 被路由到不同专家时，需要将数据从当前设备发送到目标专家所在的设备，这一过程称为 dispatch；各专家处理完成后，结果还需要汇总回原始设备，称为 combine。DeepSeek 开源的 DeepEP 库正是为这一场景量身打造的通信基础设施。
DeepEP 提供了两组内核实现，分别针对不同业务场景优化。第一组是常规内核（normal kernels），适用于模型训练和推理的预填充阶段，其设计目标是在高吞吐量场景下最大化带宽利用率。在 H800 GPU（NVLink 带宽约 160 GB/s）和 InfiniBand 400 Gb/s RDMA（约 50 GB/s）的配置下，8 路专家并行时 NVLink 域的 dispatch 带宽可达 153 GB/s，combine 带宽达 158 GB/s；跨节点 16 路专家并行时 RDMA 带宽约为 43 GB/s，32 路时可提升至 58 GB/s。这些数字接近硬件的理论带宽上限，体现了 DeepEP 在通信效率上的深度优化。
第二组是低延迟内核（low-latency kernels），专为推理解码阶段设计，强调端到端延迟的最小化。在 128 Token 批量、top-8 专家的配置下，8 路专家并行的 dispatch 延迟为 77 微秒，combine 延迟为 114 微秒；即使扩展到 256 路专家并行，延迟也仅增长至 192 微秒和 369 微秒，仍然保持在可控范围内。DeepEP 还实现了基于 hook 的通信计算重叠机制，允许 RDMA 传输在后台异步执行而不占用 GPU 的流多处理器（SM）资源，从而在保持低延迟的同时最大化计算利用率。
在数据精度方面，DeepEP 支持 FP8 dispatch 与 BF16 combine 的混合精度策略。FP8 用于专家间数据传输，可显著降低通信带宽需求；BF16 用于专家内部计算，兼顾数值稳定性和计算效率。这一设计在 V3 和 R1 系列的训练与推理中得到了充分验证。
部署参数与监控要点
将 DeepSeek V4 的 MoE 负载均衡策略落地到生产环境，需要关注以下关键参数与监控指标。首先，Top-K 值的选取应在 2 到 4 之间权衡，较大的 K 值能提升模型容量但增加通信开销，建议在首层使用较小的 K（如 2），在深层逐步增大。
其次，偏置项的更新周期建议设置为每 100 到 500 个 steps 一次，具体取决于训练批量大小和专家总数。监控方面，应重点关注各专家的激活频率标准差，理想情况下标准差应控制在均值的 20% 以内；若某些专家的利用率持续超过均值 50% 以上，应考虑增加冗余副本或调整偏置学习率。
对于推理服务，建议启用 DeepEP 的低延迟模式并将每路专家并行的 Token 批量控制在 256 以内，以获得最佳的尾延迟表现。同时，应为 InfiniBand 网络配置虚拟通道（Virtual Lanes）隔离，将 MoE 通信流量与其他业务流量分开，避免网络争用影响推理稳定性。
综合来看，DeepSeek V4 的 MoE 负载均衡策略通过辅助损失 free 的偏置学习机制实现了训练阶段的自然平衡，结合 DeepEP 的高效通信优化和部署阶段的冗余专家策略，构成了一套完整的从模型训练到服务部署的技术链路。这一方案的核心价值在于：它将负载均衡从一项需要手动干预的运维工作，转化为模型架构本身的内在属性，从而在大规模生产环境中实现了稳定且高效的资源利用。
资料来源：DeepSeek V3 Technical Report、DeepEP GitHub 仓库。