1

F.softmax + TopK + 手动分组 (gate 路由)

自定义 CUDA kernel 一步完成

npu_moe_gating_top_k_softmax（61µs vs 114µs，1.87×）已融合

分步写法在 64 experts / top-8 下 kernel launch 开销 > 计算本身

改调 NPU 融合算子，需改代码，且 sigmoid 路由要换 npu_moe_gating_top_k

2

token.reshape → expert 分组 → 排序 (Permute)

Triton kernel 原地重排

MoeTokenPermuteWithEP 融合排序+重排

朴素实现内存读写 4 次，NPU 上带宽瓶颈先于算力

用 CANN 融合算子，输出布局与 CUDA 不一致，下游 expert 计算要适配

3

expert 计算 → 还原原始顺序 (Unpermute)

自定义反向 scatter

MoeTokenUnpermuteWithEP 融合

反向路由索引若用 PyTorch 原生，回退 CPU 极慢

必须用 NPU 融合版，否则 MoE 层吞吐掉 40%+

4

AllToAll(token) 跨卡专家分发

NCCL all_to_all_single

HCCL all_to_all_single + moe.all_to_all 封装

通信与计算串行时，all-to-all 把省下的算力全吃回去——这是 MoE 在 NPU 上"没比稠密快"的头号原因

必须上 MC2 通算融合（通信与 expert 计算流水线化），否则无效

5

GroupedMatmul (多 expert 批处理)

Triton grouped_gemm

grouped_matmul (ops-transformer)

稀疏度高（top-1/2、64+ experts）收益大；密集激活时重排开销抵消收益​

稀疏度低时反向不融合反而更快，需按 top-k/expert 数动态选择

6

反向 all_to_all + 梯度路由

NCCL + 自定义反向内核

HCCL 支持，但反向梯度路由逻辑需额外 kernel​

训练时反向通算融合复杂度远高于推理，当前 GMM 融合主要面向推理​

训练态要么退化为串行通信，要么自写 Ascend C 反向 kernel

7

动态路由（路由结果随训练步变化）

Triton 动态 shape kernel

控制流融合困难，硬件向量化执行分支代价高​

动态 shape 下融合算子失效，回退到多个小算子

用 torch.compile + 静态 shape 缓存缓解，或接受降级

8

F.softmax / F.cross_entropy

指数运算 + 分母累加，FP16 易上/下溢

官方要求 FP32 输入，底层只接受 FP32

误用 FP16 输入 → loss 爆炸或 silently 漂移

强制 upcast，或开动态 loss scale

9

F.layer_norm / F.rms_norm

算方差涉及累加，低精度误差累积

LayerNorm/RMSNorm 必须用 FP32 算，PyTorch 无原生 RMSNorm 易写错

用 FP16 跑 LN → 收敛差 2–3%、训练不稳定

自实现时强制 x.float() 计算再转回半精度

10

F.scaled_dot_product_attention (SDPA)

Attention 分数 × V 的 matmul 需 FP32 保数值稳定

CANN 6.0 不原生支持 SDPA，会回退到 matmul+softmax 朴素实现（慢 3×）；7.0+ 才路由到 FlashAttention

老版本 CANN 上 Attention 既慢又易溢出

升级 CANN ≥7.0，或显式调用 npu_fusion_attention

11

matmul(Q, K^T) in Attention

大 LLM 注意力分数易上溢

需 FP32 累加

FP16 累加 → 注意力分布塌缩

用 npu_prompt_flash_attention（已融合 RoPE+softmax）

12

梯度 all_reduce / reduce_scatter

梯度/激活值累加

必须 upcast 到 FP32 通信，否则数值不稳定

半精度通信 → 多卡训练精度较单卡低 1–3%

通信前 cast，或用 combine_grad=True

13

动态 Loss Scale 检查

NPU 浮点异常语义与 GPU 不同

昇腾浮点异常检查机制与 GPU 有差异，频繁 scale 变化敏感

动态 loss scale 抖动 → 收敛失败

改静态 loss scale（128/256/512/1024），或 growth_factor=1.0 锁死

14

Embedding / 输出层

第一层、最后一层对精度极敏感

官方要求 FP32

半精度 embedding → 困惑度升 2 点

强制 FP32 输入层与 LM head

15

torch.jit.trace + 动态控制流

动态图跟踪

CANN 7.0 前部分动态图跟踪失败

trace 静默出错 → 推理结果偏差

改用 torch.compile（CANN 7.0+）

16

dist.init_process_group(backend="nccl")

NCCL

需改为 HCCL 后端，接口语义近似但超时/建链语义不同​

直接复制 GPU 代码 → 建链失败或 hang

用 torch_npu_run 分级 tcpstore，配置 HCCL_EVENT_TIMEOUT

17

dist.all_to_all_single

NCCL

HCCL 支持，但临时 tensor 未释放会导致内存上涨（CANN 7.0 才修复）

长训 OOM，肉眼难定位

升级 CANN ≥7.0，或手动 empty_cache

18

dist.all_gather (不等长输入输出)

NCCL

CANN 7.0 才原生支持不等长 allgather/reducescatter​

老版本处理变长序列 → 报错或 hack

升级或 padding 到等长

19

torch.compile + inductor

CUDA 图编译

CANN 2.6.0 预览版仍不支持 inductor​

依赖 inductor 的模型直接报错

用 torch.compile 的 NPU 后端或退 eager

20

第三方 CUDA 扩展（apex / xformers / flash-attn）

C++/CUDA 内核

未针对 NPU 编译则完全无法运行​

import 报错，或静默走 CPU fallback 性能断崖

用 torch_npu 对应融合算子替代，或自写 Ascend C

21

pg_options 通信域参数

NCCL

CANN 7.0 才支持通过 pg_options 配置 HCCL 通信域

多通信组调优失效

升级或用环境变量替代

22

硬件故障感知 / 弹性训练

CUDA 无对应

CANN 7.0 新增硬件延时故障感知与恢复

老版本卡死无感知

升级 + 配 MindCluster 容错

稠密 LLM（Qwen-72B 类）

表二（精度）+ 表三（版本）

基本可以（≥95% 算子 1:1）

FlashAttention 调用、loss scale 策略、通信后端

MoE 大模型（DeepSeek-V4 / Qwen-MoE）

表一（MoE 通算融合）为主​

不可以​

Gate 路由、Permute/Unpermute、AllToAll、反向梯度路由

视觉 / 检测（YOLO / DINO 类）

表三（apex / torchvision C++ ops）

部分可以

NMS、IoU 等需 npu_batch_nms 替代

动态图 / RL 训练（PPO / GRPO）

表二（动态 shape）+ 表三

较难

torch.compile 不可用处需手写 kernel