海光 DCU 图集成实录一次 2.98x 融合如何在完整推理里消失那次海光 DCU gfx936 实验最开始几乎完美。一个 QKV split、Q/K RMSNorm、MRoPE、gate 提取和 KV Cache 写入的融合 kernel在海光 DCU 上把 T1 的 CUDAGraph 时间从 0.067680 ms 降到了 0.022720 ms。speedup: 2.9789x saving: 44.960 us/layer更难得的是Q、K、V、gate、key cache 和 value cache 全部逐位一致。16 个相关层累积起来纸面上大约能省44.960 us × 16 0.719 ms/token这不是零点几微秒的边角料而是一条看起来真正能改变 Decode 的路线。然后事情开始一层一层地变复杂。第一幕kernel 很快但运行时根本没有调用它最初的集成逻辑很直接ifenabledandqkv.shape[0]1:run_fused_decode_kernel()else:run_original_path()从 Python 看这段逻辑没有问题。T1 走融合T1 走原路径。但模型的 AOT 图第一次使用 T4096 进行 tracetoken 维虽然被标记为动态Dynamo 仍把这次看到的分支专门化了。qkv.shape[0] 1 被折叠成 false。服务能够正常启动日志也显示功能已经启用但真正的 Decode marker 一次都没有出现。也就是说kernel 正确 kernel 很快 服务正常 但优化路径从未命中如果只看“服务 READY”和吞吐结果很可能误以为 kernel 无收益。实际上这一轮甚至没有测试到目标 kernel。第二幕用 custom op 跨过动态图分支为避免 Python shape 分支被图编译吃掉下一版把融合封装成不透明 custom op。整模型图始终调用同一个 op真正的运行时选择放到 op 内部T1 - fused QKV/norm/RoPE/cache T1 - baseline-style prefill fallback normal cache update这个结构跨过了编译门槛。服务启动后两类 marker 都出现了PREFILL_FALLBACK_HIT DECODE_HIT为了验证 T1 fallback本地还把它单独编译成 full graph并在以下形状上对照T 65 / 1024 / 1680 / 4096Q/K norm、MRoPE、V/gate 和两份 cache 都逐位一致。到这里证据链看起来再次完整T1 primitive 2.9789xT1 所有输出逐位一致T1 fallback 多个 shape 逐位一致custom op 在真实服务中确认命中CUDAGraph 能够捕获和重放。但端点结果仍然给出了完全不同的答案。第三幕完整服务的结果崩了固定 10 请求测试的结果如下指标基线融合版本output throughput11.85412698.8003979mean TPOT44.3409 ms44.2464 msp99 TPOT45.0079 ms46.7338 msp99 TTFT34390.062 ms76289.081 ms输出 token 总数17861716文本不一致0/103/10completed/failed10/010/0表面上的吞吐下降是被输出轨迹变化污染的不能当作真实性能退化但这组结果已经足够否决当前集成输出 token 数不同3 个请求文本发生变化p99 TPOT 没有出现预期中的 Decode 节省p99 TTFT 增长到 76 秒以上。最奇怪的是T1 primitive 明明逐位一致。漂移究竟来自哪里第四幕关掉快 kernel漂移仍然存在为了做归因下一次运行强制 T1 也走 fallback使 fused Decode kernel 完全不执行。只跑前三个请求因为其中包含两个已知漂移样本基线前三个请求 token: 631 fallback-only token: 601 不一致索引: 0 / 2 candidate mean TPOT: 44.3829 ms completed/failed: 3 / 0融合 Decode 版本在这三个请求中产生 602 个 token并且同样是索引 0、2 不一致。这一步把责任从 T1 快 kernel 上移开了。主要漂移发生在把 Prefill 的 Q/K norm 和 MRoPE 从原始整模型图中搬到独立 custom-op fallback 之后。独立 full graph 能逐位一致并不代表它放回原始模型时仍采用相同的数值调度。真正的问题计算图也是数值实现的一部分从数学表达式看fallback 执行的仍然是split Q/K/V/gate - Q/K RMSNorm - MRoPE - cache update但编译器看到的图边界已经变化。原始实现中这些操作位于整模型 AOT 图内Inductor 可以联合选择reduction tree中间张量是否物化BF16/FP32 转换位置pointwise 与 reduction 的融合边界内存 stride 和临时布局。搬进独立 custom op 后即使 op 内部又被编译成 full graph它也不再处于原来的全局图上下文中。数学没变图边界变了图边界一变浮点执行顺序也可能变化。为什么 2.98x 没有错这次实验不能总结为“2.98x 是假数据”。T1 原始 JSON 明确记录baseline: 0.067680 ms candidate: 0.022720 ms speedup: 2.978873x Q/K/V/gate/cache mismatch: 0这个 primitive 既快又正确。失败的是“如何把它接入动态整模型图”而不是 primitive 本身。这种区分非常重要层级结论单 kernel通过T1 CUDAGraph通过T1 独立 fallback通过动态 custom-op 集成能运行完整生成不通过端到端性能未兑现这次实验留下的五条经验1. marker 比 ENABLED 日志更重要功能开关打开不代表目标 kernel 命中。必须记录真实运行时 dispatch。2. Python shape 分支可能在 trace 时被专门化动态维度不代表所有 Python 控制流都会保持动态。3. 独立 full graph 不能替代原始整模型图它只能证明独立边界内的正确性不能证明编译器在整模型中选择相同归约计划。4. custom op 不只是一个接口封装它会改变图可见性、融合范围和中间张量边界因此可能改变数值调度。5. 最终正确性必须落到生成文本如果只比较 primitive这条路线已经“成功”加入 10 个真实请求后结论才变得完整。对海光 DCU 算子生态的意义海光 DCU 上已经有越来越多可以直接运行或移植的 Triton、HIP 和 AITER 类 kernel但“在 gfx936 上编译通过”只是起点。真正进入 vLLM 还要跨过动态图、AOTAutograd、Inductor、custom op metadata 和 CUDAGraph。因此论坛里分享一个海光 DCU 融合算子时最好把证据分成两部分DCU primitive性能与逐位正确性 DCU integrationdispatch、图编译、生成文本与端点指标这能避免把一个优秀的 gfx936 primitive误写成已经完成的服务级优化。结语这条路线从 2.9789x、逐位一致开始最后以 3/10 文本漂移和没有 TPOT 收益结束。它并不是一次无效实验。相反它清楚地说明了海光 DCU 大模型优化中最容易被忽略的一层kernel 是局部实现计算图边界是系统实现。只有当快 kernel、动态图 dispatch、AOT 编译、CUDAGraph 和完整生成同时成立时2.98x 才能真正进入服务。
