# 海光 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。 ~~~text speedup: 2.9789x saving: 44.960 us/layer ~~~ 更难得的是，Q、K、V、gate、key cache 和 value cache 全部逐位一致。 16 个相关层累积起来，纸面上大约能省： ~~~text 44.960 us × 16 = 0.719 ms/token ~~~ 这不是零点几微秒的边角料，而是一条看起来真正能改变 Decode 的路线。 然后，事情开始一层一层地变复杂。 --- ## 第一幕：kernel 很快，但运行时根本没有调用它 最初的集成逻辑很直接： ~~~python if enabled and qkv.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 一次都没有出现。 也就是说： ~~~text kernel 正确 kernel 很快 服务正常 但优化路径从未命中 ~~~ 如果只看“服务 READY”和吞吐结果，很可能误以为 kernel 无收益。实际上，这一轮甚至没有测试到目标 kernel。 --- ## 第二幕：用 custom op 跨过动态图分支 为避免 Python shape 分支被图编译吃掉，下一版把融合封装成不透明 custom op。 整模型图始终调用同一个 op，真正的运行时选择放到 op 内部： ~~~text T=1 -> fused QKV/norm/RoPE/cache T>1 -> baseline-style prefill fallback + normal cache update ~~~ 这个结构跨过了编译门槛。服务启动后，两类 marker 都出现了： ~~~text PREFILL_FALLBACK_HIT DECODE_HIT ~~~ 为了验证 T>1 fallback，本地还把它单独编译成 full graph，并在以下形状上对照： ~~~text 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 请求测试的结果如下： | 指标 | 基线 | 融合版本 | |---|---:|---:| | output throughput | 11.8541269 | 8.8003979 | | mean TPOT | 44.3409 ms | 44.2464 ms | | p99 TPOT | 45.0079 ms | 46.7338 ms | | p99 TTFT | 34390.062 ms | 76289.081 ms | | 输出 token 总数 | 1786 | 1716 | | 文本不一致 | 0/10 | 3/10 | | completed/failed | 10/0 | 10/0 | 表面上的吞吐下降是被输出轨迹变化污染的，不能当作真实性能退化；但这组结果已经足够否决当前集成： - 输出 token 数不同； - 3 个请求文本发生变化； - p99 TPOT 没有出现预期中的 Decode 节省； - p99 TTFT 增长到 76 秒以上。 最奇怪的是，T=1 primitive 明明逐位一致。漂移究竟来自哪里？ --- ## 第四幕：关掉快 kernel，漂移仍然存在 为了做归因，下一次运行强制 T=1 也走 fallback，使 fused Decode kernel 完全不执行。 只跑前三个请求，因为其中包含两个已知漂移样本： ~~~text 基线前三个请求 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 执行的仍然是： ~~~text 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 明确记录： ~~~text baseline: 0.067680 ms candidate: 0.022720 ms speedup: 2.978873x Q/K/V/gate/cache mismatch: 0 ~~~ 这个 primitive 既快又正确。 失败的是“如何把它接入动态整模型图”，而不是 primitive 本身。 这种区分非常重要： | 层级 | 结论 | |---|---| | 单 kernel | 通过 | | T=1 CUDAGraph | 通过 | | T>1 独立 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 融合算子时，最好把证据分成两部分： ~~~text DCU primitive：性能与逐位正确性 DCU integration：dispatch、图编译、生成文本与端点指标 ~~~ 这能避免把一个优秀的 gfx936 primitive，误写成已经完成的服务级优化。 ## 结语 这条路线从 2.9789x、逐位一致开始，最后以 3/10 文本漂移和没有 TPOT 收益结束。 它并不是一次无效实验。相反，它清楚地说明了海光 DCU 大模型优化中最容易被忽略的一层： > kernel 是局部实现，计算图边界是系统实现。 只有当快 kernel、动态图 dispatch、AOT 编译、CUDAGraph 和完整生成同时成立时，2.98x 才能真正进入服务。