执行摘要
- 一句话：修复非NPU设备上 fused_moe 导入失败问题
- 推荐动作：此PR是必要的bugfix，逻辑简单，适合快速合入。建议开发者注意类似的条件导入模式，避免全局导入导致跨平台问题。
功能与动机
由PR #18172 引入的变更导致非NPU设备上afmoe.py在导入时尝试加载fused_moe_npu模块，但该模块仅适用于NPU环境。此PR旨在修复该回归问题，确保在非NPU设备上也能正常加载模型。
实现拆解
- 移除通用fallback导入：删除原有的
if not _is_npu: from sglang.srt.layers.moe.fused_moe_triton import fused_moe 分支，消除对triton_utils的全局依赖。
- 保持NPU专用导入：将原来的
else 分支改为 if _is_npu: 条件导入，仅在NPU环境下从 sglang.srt.hardware_backend.npu.quantization.fused_moe_method_npu 导入 fused_moe_npu 并重命名为 fused_moe。
- 注意：文件顶部第50行仍保留了对
sglang.srt.layers.moe.moe_runner.triton_utils.fused_moe 的全局导入，这导致在非NPU设备上仍会尝试加载triton相关代码。但根据review讨论，该全局导入目前不会被用到（因为非NPU设备使用MoeRunner而不是直接调用fused_moe），且triton通常作为必需依赖存在，因此风险可控。
关键文件：
python/sglang/srt/models/afmoe.py（模块 模型层；类别 source；类型 data-contract）: 唯一变更文件，修复了fused_moe的条件导入逻辑，确保非NPU设备可以正常加载afmoe模型。
关键符号：未识别
关键源码片段
python/sglang/srt/models/afmoe.py
唯一变更文件，修复了fused_moe的条件导入逻辑，确保非NPU设备可以正常加载afmoe模型。
# python/sglang/srt/models/afmoe.py ( 关键导入段 )
# 注：第 50 行仍有全局导入 from moe_runner.triton_utils import fused_moe，
# 但该导入在非 NPU 场景下不会被实际调用（使用 MoeRunner），且 triton 是通用依赖，风险较低。
_is_npu = is_npu()
# 仅当设备为 NPU 时，才从 NPU 专用路径导入 fused_moe_npu 并重命名为 fused_moe
if _is_npu:
from sglang.srt.hardware_backend.npu.quantization.fused_moe_method_npu import (
fused_moe_npu as fused_moe,
)
评论区精华
gemini-code-assist[bot] 指出：第50行的全局导入 from sglang.srt.layers.moe.moe_runner.triton_utils import fused_moe 仍然存在，如果NPU环境中没有triton，该导入会导致模型加载失败。建议将triton相关导入移到else分支中。
结论：该建议未被采纳，因为triton是sglang的通用依赖，在NPU环境中一般也会安装triton；另外该导入最终仅在MoeRunner逻辑中使用，不会影响afmoe模型本身的加载。合并者ping1jing2批准了PR并合并。
- 全局导入triton_utils.fused_moe的潜在问题 (design): 未采纳。因为triton是sglang的通用依赖，NPU环境中通常也会安装；且该导入仅用于MoeRunner，不影响afmoe模型加载。
风险与影响
- 风险：
- 回归风险（低）：如果非NPU设备上triton未被安装，第50行的全局导入仍会导致导入失败。但triton通常是sglang的必需依赖，因此实际影响有限。
- NPU兼容性（低）：变更仅影响导入逻辑，对运行时行为无影响。
- 影响：用户影响：修复了非NPU设备（如CUDA）上afmoe模型无法加载的问题。系统影响：导入逻辑简化，仅影响afmoe.py一个文件。团队影响：降低了后续开发者因误用条件导入导致跨平台兼容问题的风险。
- 风险标记：缺少测试覆盖, 非核心路径变更
关联脉络
- PR #18172 feat: Add NPU fused MoE kernel support: 该PR引入了导致此bug的条件导入逻辑，本次变更是对其的修复。
参与讨论