执行摘要
本 PR 通过引入双流异步执行、专用融合内核和参数优化，显著提升了 GLM4.7 模型在 NPU 硬件上的推理性能。修改涉及核心模型逻辑和硬件后端，在保持准确性的同时实现吞吐量提升，但对正确性和同步机制存在潜在风险，建议团队关注测试覆盖和代码维护。
功能与动机
PR 动机明确为优化 GLM4.7 在 NPU 上的性能，解决推理效率瓶颈。作者在 body 中说明：“Optimize glm4.7 performance on NPU.”，并通过启用双流处理专家、融合 RMSNorm 与偏置操作、以及集成单操作处理 QKV-RMSNorm-RoPE 来实现目标，旨在提升资源利用率和执行速度。
实现拆解
实现方案按模块拆解如下：
- 流管理模块（
python/sglang/srt/hardware_backend/npu/utils.py）：新增 process_shared_expert、wait_share_stream 等函数，支持共享和路由专家的异步执行，核心代码片段：
def process_shared_expert(hidden_states, forward_func):
stream = get_share_stream()
if stream is None:
stream = torch.get_device_module().Stream()
set_share_stream(stream)
stream.wait_stream(torch.get_device_module().current_stream())
with torch.get_device_module().stream(stream):
shared_output = forward_func(hidden_states)
return shared_output
- 量化层优化（
python/sglang/srt/layers/quantization/modelslim/modelslim.py）：修改 _rmsnorm_forward_oot，移除 post_residual_addition 参数并引入 NPU 专用内核，简化操作路径。
- 模型逻辑集成（
python/sglang/srt/models/glm4_moe.py）：在 forward_prepare 中添加条件分支，NPU 路径下使用 split_qkv_rmsnorm_rope 融合操作；在 forward_deepep 中根据环境变量启用双流，优化专家处理流程。
评论区精华
review 讨论中突出了几个关键交锋：
- 正确性担忧：gemini-code-assist[bot] 强调：“The
split_qkv_rmsnorm_rope function correctly replicates the behavior... Thorough testing is recommended to prevent accuracy regressions.” 指向新路径需严格验证。
- 兼容性质疑：RuixuanZhang06 直接询问：“why remove post_residual_addition, you need ensure all call sites...”，突显参数变更的风险。
- 同步机制：gemini-code-assist[bot] 多次评论流同步函数需正确放置，如“Verify that this waiting mechanism is sufficient for all data dependencies”，反映设计细节的重要性。
风险与影响
风险分析：
- 新内核路径可能引入回归，需全面测试确保等效性。
- 流异步执行若同步不当，可导致数据竞争或错误结果。
- 参数移除可能破坏现有调用，需验证所有使用点。
- NPU 专用代码降低可移植性，增加维护复杂度。
影响评估：
- 用户端：GLM4.7 在 NPU 上性能提升，吞吐量从测试数据看有改善。
- 系统端：增强 NPU 支持，优化并行处理能力，但增加平台特定依赖。
- 团队端：引入复杂流管理，提升技术债务，需加强测试和文档。
关联脉络
与历史 PR 关联显示 NPU 优化是仓库的持续方向：
- PR 21633 为 NPU 添加 MOVA 支持，涉及类似内核优化和硬件集成。
- PR 21998 优化 NPU 文档，反映整体 NPU 生态建设。
这些 PR 共同揭示仓库在扩展 NPU 功能、提升性能方面的演进趋势，本 PR 是这一脉络中的关键步骤，专注于 GLM4.7 模型优化。
参与讨论