执行摘要

修复了DeepEP后端下共享专家融合与EPLB（专家位置负载均衡）同时启用时的索引越界问题。当两个功能同时启用时，MoE层的topk后处理逻辑会将共享专家列错误地送入EPLB调度表，导致CUDA设备端断言错误。修复方案是在调度前分离共享专家列，仅对路由专家列进行重映射。该变更影响使用DeepEP后端且启用共享专家融合的场景，消除了崩溃风险，提升了系统稳定性。

功能与动机

根据PR body描述，问题出现在DeepEP后端同时启用两个特性时：

• --enforce-shared-experts-fusion：强制共享专家融合，将共享专家作为额外列附加到topk_ids中。
• --init-expert-location：初始化专家位置，启用EPLB调度。

biased_grouped_topk_gpu会将共享专家列（值固定为n_routed_experts=256）附加到topk_ids中。后续EPLB调度在_biased_grouped_topk_postprocess中使用topk_ids作为索引查询逻辑-物理调度表，但该表只有256个条目（索引0-255），导致索引256越界，引发CUDA设备端断言错误。

实现拆解

修改文件：python/sglang/srt/layers/moe/topk.py

关键改动在_post_process_topk_ids函数中，新增条件分支处理共享专家融合与EPLB的冲突：

if num_fused_shared_experts > 0 and is_deepep_class_backend():
    shared_cols = topk_ids[:, -num_fused_shared_experts:]
    routed_cols = topk_ids[:, :-num_fused_shared_experts]
    routed_cols = _biased_grouped_topk_postprocess(
        routed_cols, expert_location_dispatch_info, num_token_non_padded
    )
    topk_ids = torch.cat([routed_cols, shared_cols], dim=-1)
else:
    topk_ids = _biased_grouped_topk_postprocess(
        topk_ids, expert_location_dispatch_info, num_token_non_padded
    )

逻辑解析：

1. 当检测到共享专家融合且使用DeepEP后端时，将topk_ids分割为路由专家列和共享专家列。
2. 仅对路由专家列调用_biased_grouped_topk_postprocess进行EPLB调度重映射。
3. 将处理后的路由列与原始共享列重新拼接。
4. 其他情况（非DeepEP后端或无共享专家融合）走原有else分支。

评论区精华

review中仅有一次实质性讨论：

gemini-code-assist[bot] 建议重构条件逻辑以提高可读性和减少代码重复，通过预先确定要处理的列来避免重复调用_biased_grouped_topk_postprocess。

但作者未采纳该建议，最终代码保持了原有的if/else结构。ch-wan直接批准了PR，未提出进一步意见。

风险与影响

风险：

1. 回归风险：修改了MoE层topk后处理的核心逻辑，可能影响所有使用DeepEP后端且启用共享专家融合的场景。
2. 性能风险：新增了张量分割（[:, -num_fused_shared_experts:]）和拼接（torch.cat）操作，可能引入微小开销，但仅在特定条件（共享专家融合+DeepEP）下触发。
3. 测试覆盖不足：PR body提到已测试EP8和EP16，但未提供单元测试变更，依赖现有测试套件。

影响：

1. 对用户：修复了DeepEP后端下共享专家融合与EPLB同时启用时的崩溃问题，使该配置可用。
2. 对系统：消除了CUDA设备端断言错误，提升系统稳定性。
3. 对团队：明确了共享专家融合与EPLB调度的交互边界，为后续类似功能开发提供参考。

关联脉络

从近期历史PR看，MoE层持续优化是重点方向之一：

• PR #22642：优化MoE层DP注意力通信，将两阶段通信合并为reduce_scatterv，提升吞吐量7.7%。同属MoE层性能改进，但侧重通信模式而非调度逻辑。
• PR #21259：为HiCache添加Mooncake存储后端支持，兼容DSA和Mamba混合模型。同属DeepEP相关功能，可能涉及后端兼容性处理。

本PR揭示了MoE层中功能组合的边界问题：当多个优化特性（共享专家融合、EPLB调度）叠加时，可能产生未预期的交互冲突。这种问题在复杂系统中具有典型性，值得后续开发中注意类似场景。