执行摘要

此PR将DeepSeek V3/R1模型中的共享专家融合到DeepEP的MoE分发路径，作为每个rank的本地附加专家处理，消除了独立计算的开销，为后续水印负载平衡功能铺路，影响专家并行下的推理效率。

功能与动机

当前在DeepSeek V3/R1使用专家并行（EP）时，每个rank独立计算共享专家，而不是作为DeepEP分发管道的一部分，导致重复计算和效率低下。此变更旨在将共享专家融合到MoE路径中，为后续的水印负载平衡功能（请求自 #19290）做准备。

实现拆解

• 新模块 deepep_shared_expert_fusion.py: 提供 expand_topk_with_shared_expert 函数，用于在TopK选择后扩展共享专家列。
• 模型层 deepseek_v2.py: 调整 num_experts 和 top_k 以容纳扩展布局（例如，EP=16时从256路由专家增加到272总专家），并跳过独立的共享专家前向传播。
• MoE层 fused_moe_triton/layer.py: 修改专家ID重映射逻辑，处理DeepEP下的共享专家槽位。
• TopK计算 topk.py: 更新 biased_grouped_topk_gpu 函数，支持共享专家的单独追加。
• 服务器参数 server_args.py: 添加 --enable-deepep-waterfill CLI标志来控制功能启用。

评论区精华

• 潜在bug: gemini-code-assist[bot] 指出 get_moe_weights 中 num_local 计算可能不正确，影响EPLB功能。

  "The calculation of num_local seems incorrect when _enable_deepep_waterfill is true."

• 设计讨论: ch-wan 质疑 biased_grouped_topk_gpu 修改的必要性，询问原始实现是否支持融合。

  "Could you confirm if the original implementation of biased_grouped_topk_gpu supports shared expert fusion?"

• 兼容性: ch-wan 强调在DeepEP结合TBO或SBO时应禁用融合。

  "We should disable fusion for deepep + TBO / SBO."

风险与影响

风险:

1. get_moe_weights 中的计算错误可能导致专家并行负载平衡功能中断。
2. 修改topk逻辑可能破坏标准TP模式下的兼容性。
3. 新融合路径增加代码复杂性，需确保充分测试以避免回归。

影响:

• 用户需通过CLI标志启用功能，默认行为不变。
• 系统优化了DeepEP下的资源利用，减少重复计算。
• 团队为后续负载平衡功能奠定基础，但维护成本增加。

关联脉络

此PR是水印负载平衡功能的第一部分，关联 #19290。历史PR中，PR #21822 涉及MoE bugfix，PR #22389 涉及调度重构，均与此PR的MoE和调度修改相关，反映了团队在优化专家并行推理方面的持续努力。