这篇笔记记录一次很窄的接入设计：在 verl release/v0.8.0 的 Qwen3.5 GRPO + FSDP 路径里，NPU 已经有 RMSNorm、RoPE、MoE GMM 等 patch，但 Gated Delta Net / GDN 仍然落在原始 eager 路径。目标不是改 GRPO 算法，而是给模型 forward 里的 chunk_gated_delta_rule 加一个可配置的 Triton 优先路径。

参考对象是 MindSpeed-MM 提交 5aaf0791d00abcbf5dd16af10091f4391030ad00：它把 Qwen3.5 的 GDN 计算模式显式化为 gdn_compute_mode，并区分 triton、ascendc、eager。本文给出的 verl 方案先接入 Triton，保留 eager 回退；AscendC 自定义算子作为后续扩展。

• DeepSeek V4 加大了与Ascend的合作；
• 在华为稼先上的技术报告，除了Ascend C对attention有算子优化；
• 通过pytorch的算子自动融合 AutoFuse 处理一些非常规的计算，可以实现E2E加速31%。并且说可以修改一行之间开启。

故了解相关概念，但是实际上 AutoFuse只适合非常规计算特别多，又没有人力投入的情况，可以考虑AutoFuse。但是对于Qwen3.5 这种优化后就只有一半Matmul/GMM，一半GDN的情况，AutoFuse接入的收益就不足了。

• triton 虽然主流，大部分硬件都支持，虽然能快速拿到一部分收益，但是却较难极致性能。
• 但是Ascend C / PyPTO 又过于Ascend定制化，(学了怎么跳槽啊)
• 寻找一种更底层，支持极致性能的通用算子编程语言，是极致性能优化里不可或缺的一环。

• Ascend上训练编译成全图有功能问题，导致下发问题并不能像GPU一样完全解决；
• 在浦江实验室的经验是，triton确实能快速拿到2～3倍的收益，如果算子还有问题就能考虑