海光 DCU 算子优化为什么 1.32x 仍可能不值得接入摘要性能表格最吸引眼球的通常是加速比但在大模型推理中真正决定端到端价值的往往是“每次调用究竟省了多少微秒”。本文整理三组海光 DCU gfx936 本地实测。第一组 kernel 达到 1.31631x第二组达到 1.18939x第三组甚至完成了 314/314 的精确修复但它们最终都没有进入完整服务。原因并不是实现失败而是每层绝对节省只有 1.76-3.23 微秒乘上层数后仍不足以改变约 44 ms/token 的 Decode 主体。这篇文章讨论一种比“看加速比”更可靠的 DCU 优化预算方法。1. 加速比会放大小算子的视觉效果假设一个 kernel 从 13 微秒降到 10 微秒speedup 13 / 10 1.30x absolute saving 3 us1.30x 看起来很明显但如果完整 Decode 每 token 需要 44 ms那么单层 3 微秒只占3 us / 44,000 us 0.0068%只有当这个 kernel 在很多层、每个 token 都稳定命中时才可能积累出可见收益。更实用的预算公式是saving_per_token saving_per_call × calls_per_layer × layer_count × hit_rate然后再与完整 token 时间比较而不是只看局部 speedup。2. 案例一1.31631x但每层只省 3.10840 微秒本地测试过一条 fused split GDR HIP kernel。CUDAGraph event median 使用 7 组样本每组 400 次 replay路径耗时当前 Triton BF16 state12.93559 usHIP FP32 swizzled state9.82719 us加速比1.31631x每层节省3.10840 us如果模型中有 48 个相关层理想化累计节省为3.10840 us × 48 149.20 us/token 0.14920 ms/token相对于约 44 ms 的 Decode 时间上限约为 0.34%。而且这个估算还没有计入状态格式转换额外 FP32 显存流量runtime allocation图集成和 dispatch 开销。也就是说1.31631x 已经是好看的局部数字但 3.10840 微秒才是决定是否继续投入的数字。3. 案例二适配真实布局后2.89x 变成 1.19x另一个 GDN 融合原型在上游布局中曾测到40.6752 us - 14.0568 us speedup: 2.8936x saving: 26.6184 us/layer但真实 Qwen3.5 激活布局与该上游 kernel 的输入布局不同。把真实布局和必要的数据整理纳入公平比较后最终 native flat-layout 结果是路径耗时真实布局基线20.27239 usnative flat kernel17.04439 us加速比1.18939x每层节省3.22800 us48 层的理想累计节省3.22800 us × 48 154.944 us/token 0.15494 ms/token这个结果并不差。它说明 kernel 已经正确适配了目标布局也证明了局部融合有效。但它同样无法跨过端点门槛完整服务中还有大量 Linear、Attention、状态更新和运行时开销0.15494 ms/token 很容易被稀释。这个案例还说明一个常见问题上游 benchmark 的基线布局如果比本地生产布局更重直接照搬加速比会高估收益。4. 案例三正确性完全修好物理上限仍然太小本地还研究过一种“快速近似结果 低置信度精确修复”的 GDN 输出方案。经过 gfx936 MMAC 路径重建后选中的 314 行实现了vendor exact: 314 / 314从正确性角度看这是一个完整闭环。但 CUDAGraph 计时为路径耗时vendor full55.0400 usLLMM153.2800 us精确 repair 本身21.4400 usdebug repair61.6000 us这里有一个决定性的物理上限vendor - LLMM1 1.7600 us/layer 48 layers 84.48 us/token即使假设置信度检测和修复完全免费最多也只能省 1.76 微秒/层。真实实现必然还有检测、索引、repair 和写回开销因此不可能从这条结构中获得更高的端到端收益。正确性修到 314/314并不能改变这条性能上限。5. 什么时候加速比才有意义加速比不是无用而是必须与以下信息一起看问题需要的证据单次省多少绝对微秒差一枚 token 调用几次profile 调用计数有多少层命中模型结构所有请求都命中吗dispatch marker能否与其他工作重叠CUDAGraph/trace集成需要额外转换吗完整数据流计时最终是否值得端点 A/B尤其对 10-30 微秒级 kernel1.2x、1.3x 很容易出现但它们可能只对应 2-4 微秒的绝对节省。相反一个只快 1.08x 的大权重 GEMV如果每 token 重复上百次反而可能产生更明显的服务收益。6. 给 DCU kernel 设立物理门槛在写实现之前可以先反推最低门槛。假设目标是让 44 ms/token 的 Decode 改善 1%required saving 44 ms × 1% 0.44 ms/token如果目标 kernel 出现于 48 层required per-layer saving 0.44 ms / 48 ≈ 9.17 us/layer如果还要考虑集成稀释、运行波动和额外开销standalone 门槛应该更高而不是刚好等于 9.17 微秒。先算这个门槛可以快速淘汰“比例很好看、绝对时间不够”的路线。7. 海光 DCU 上为什么更要看绝对微秒本文三组数据都来自 gfx936 的 device-event 或 CUDAGraph 计时。它们反映了海光 DCU kernel 评估中一个很实用的特点很多 recurrent、gating 和 repair primitive 本身只有十几到几十微秒比例很容易变得好看但完整 Decode 仍是数十毫秒量级。因此在海光 DCU 上筛选新 kernel 时可以先用下面的顺序gfx936 实机绝对微秒 - 每 token 命中次数 - 层数累计 - 完整服务 TPOT这比先追求一个醒目的 speedup 更节省工程时间也更适合在论坛中比较不同实现的真实价值。8. 结论三组本地 DCU 实验给出了相同结论1.31631x 对应 3.10840 us/layer1.18939x 对应 3.22800 us/layer314/314 精确修复的零成本上限也只有 1.7600 us/layer。这些实现并非没有技术价值。它们证明了 kernel、布局和数值路径能够成立但不足以改变完整服务的主要时间墙。因此评估 DCU 算子时建议把表格第一列从 speedup 改成每层省多少微秒每个 token 能累计多少毫秒。加速比负责描述局部改善绝对时间预算才负责决定工程方向。本文数据来自本地固定环境的 CUDAGraph 与 standalone 测量。文中的端到端上限是基于实测每 token 时间和调用层数的物理估算不等同于已经完成的服务吞吐结果。