企业官网建设流程全解析

海光 DCU 图集成实录：一次 2.98x 融合如何在完整推理里消失

那次海光 DCU gfx936 实验最开始几乎完美。

一个 QKV split、Q/K RMSNorm、MRoPE、gate 提取和 KV Cache 写入的融合 kernel，在海光 DCU 上把 T=1 的 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 看，这段逻辑没有问题。T=1 走融合，T>1 走原路径。

但模型的 AOT 图第一次使用 T=4096 进行 trace，token 维虽然被标记为动态，Dynamo 仍把这次看到的分支专门化了。qkv.shape[0] == 1 被折叠成 false。

服务能够正常启动，日志也显示功能已经启用，但真正的 Decode marker 一次都没有出现。

也就是说：

kernel 正确 kernel 很快 服务正常 但优化路径从未命中

如果只看“服务 READY”和吞吐结果，很可能误以为 kernel 无收益。实际上，这一轮甚至没有测试到目标 kernel。

第二幕：用 custom op 跨过动态图分支

为避免 Python shape 分支被图编译吃掉，下一版把融合封装成不透明 custom op。

整模型图始终调用同一个 op，真正的运行时选择放到 op 内部：

T=1 -> fused QKV/norm/RoPE/cache T>1 -> baseline-style prefill fallback + normal cache update

这个结构跨过了编译门槛。服务启动后，两类 marker 都出现了：

PREFILL_FALLBACK_HIT DECODE_HIT

为了验证 T>1 fallback，本地还把它单独编译成 full graph，并在以下形状上对照：

T = 65 / 1024 / 1680 / 4096

Q/K norm、MRoPE、V/gate 和两份 cache 都逐位一致。

到这里，证据链看起来再次完整：

• T=1 primitive 2.9789x；
• T=1 所有输出逐位一致；
• T>1 fallback 多个 shape 逐位一致；
• custom op 在真实服务中确认命中；
• CUDAGraph 能够捕获和重放。

但端点结果仍然给出了完全不同的答案。

第三幕：完整服务的结果崩了

固定 10 请求测试的结果如下：

表面上的吞吐下降是被输出轨迹变化污染的，不能当作真实性能退化；但这组结果已经足够否决当前集成：

• 输出 token 数不同；
• 3 个请求文本发生变化；
• p99 TPOT 没有出现预期中的 Decode 节省；
• p99 TTFT 增长到 76 秒以上。

最奇怪的是，T=1 primitive 明明逐位一致。漂移究竟来自哪里？

第四幕：关掉快 kernel，漂移仍然存在

为了做归因，下一次运行强制 T=1 也走 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 不一致。

这一步把责任从 T=1 快 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 是假数据”。

T=1 原始 JSON 明确记录：

baseline: 0.067680 ms candidate: 0.022720 ms speedup: 2.978873x Q/K/V/gate/cache mismatch: 0

这个 primitive 既快又正确。

失败的是“如何把它接入动态整模型图”，而不是 primitive 本身。

这种区分非常重要：

这次实验留下的五条经验

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 integration：dispatch、图编译、生成文本与端点指标

这能避免把一个优秀的 gfx936 primitive，误写成已经完成的服务级优化。

结语

这条路线从 2.9789x、逐位一致开始，最后以 3/10 文本漂移和没有 TPOT 收益结束。

它并不是一次无效实验。相反，它清楚地说明了海光 DCU 大模型优化中最容易被忽略的一层：

kernel 是局部实现，计算图边界是系统实现。

只有当快 kernel、动态图 dispatch、AOT 编译、CUDAGraph 和完整生成同时成立时，2.98x 才能真正进入服务。