海光 DCU BF16 M=1 实测：hipBLASLt 为什么输给 rocBLAS

海光 DCU BF16 M1 实测hipBLASLt 为什么输给 rocBLAS实验摘要hipBLASLt 提供更灵活的矩阵布局、heuristic 和 epilogue 能力因此在选择 DCU GEMM 后端时很容易产生一个直觉对 Decode 的 M1 GEMM直接使用 hipBLASLt至少不应该比传统 rocBLAS 更慢。本地在海光 DCU gfx936 上对四个真实 BF16 Decode shape 进行了直接测试。hipBLASLt 能够正常编译和执行但安装环境对每个问题只暴露一个 heuristic四个 shape 全部落后于当前 rocBLAS 路径。最明显的 lm_head 形状中hipBLASLt: 4.69 ms rocBLAS: 1.94848 ms 相对性能: 0.415x这份实验说明库的接口能力和某个固定 shape 上是否拥有高质量 kernel是两件不同的事。1. 实验问题长上下文 Decode 中query 维度通常为 1大量 Linear 会转化为 M1 GEMM。本地 profile 映射出的四类形状为模块MNK每 token 调用数MLP down projection512011740864GDN output projection51201614448Attention output projection51201512016lm_head248320151201这里采用库调用语义中的 M、N、K 记法。四类 shape 的共同点是 N1属于典型的矩阵向量路径。实验只回答一个问题在当前 gfx936 软件栈中 hipBLASLt 对这些固定 BF16 M1 shape 能否直接替代当前 rocBLAS 路径2. hipBLASLt 直接测试hipBLASLt BF16 路径成功编译并运行。对每个问题当前安装库只返回一个可用 heuristic。结果如下ShapehipBLASLtrocBLAS 参考hipBLASLt/rocBLASMLP down0.40 ms0.19424 ms0.486xGDN out0.15 ms0.09376 ms0.625xAttention o_proj0.13 ms0.09104 ms0.700xlm_head4.69 ms1.94848 ms0.415x四个比值都小于 1表示 hipBLASLt 更慢。换成更直观的耗时倍数ShapehipBLASLt 耗时约为 rocBLAS 的MLP down2.06 倍GDN out1.60 倍Attention o_proj1.43 倍lm_head2.41 倍这不是几个百分点的波动而是明确的 kernel 质量差距因此没有继续接入完整服务。3. rocBLAS 是否还有隐藏的大幅优化为了确认参考路径并非随意选择本地还对相同四类 M1 问题运行了 rocBLAS/Tensile solution tune并用三组 baseline/override 交错比较。3.1 MLP downbaseline median: 0.194720 / 0.194400 / 0.194240 ms override median: 0.193600 / 0.191840 / 0.190720 ms pair speedup: 1.0058x / 1.0133x / 1.0185x median speedup: 1.0133x output: exact强制 solution 确实更换了 kernel但中位收益只有 1.33%没有形成结构性提升。3.2 GDN outpair speedup: 0.9250x / 1.1187x / 1.0121x median speedup: 1.0121x日志显示 baseline 与 override 最终使用相同 Tensile kernel。这里的中位差异更接近共享环境波动而不是新 solution 的收益。3.3 Attention o_projpair speedup: 1.0327x / 0.9458x / 1.0305x median speedup: 1.0289x checksum exact: false三组结果同时出现回退和提升输出 checksum 也发生变化不能作为稳定候选。3.4 lm_headpair speedup: 1.0001x / 1.0071x / 1.0016x median speedup: 1.0012xbaseline 与 override 使用相同 kernel结果基本中性。4. 为什么“更现代的库”不保证更快4.1 后端能力取决于 shape 覆盖hipBLASLt 的优势需要具体 heuristic 和 kernel 支撑。接口支持 BF16、布局和 epilogue不代表安装库对每个 N1 shape 都拥有成熟实现。4.2 M1 与大 GEMM 是不同问题大 GEMM 可以用更大的 tile 和更高并行度摊销调度成本。N1 时问题更接近权重流式读取和归约可用并行维度更少tile 选择空间不同kernel launch 与 reduction 占比更高大 GEMM 上优秀的 heuristic 未必适合 GEMV。4.3 默认 rocBLAS 路径可能已经命中专用解当前 rocBLAS/Tensile 参考在四个 shape 上都明显领先直接 hipBLASLt。后续 tune 又只找到约 0%-1.3% 的稳定空间说明这些 M1 问题已经命中相对成熟的实现。4.4 heuristic 数量本身是一条信号本地 hipBLASLt 对每个问题只暴露一个 heuristic。没有第二个可比较候选时继续扫 workspace 或手工猜测 ID 缺乏证据基础。5. 如何公平比较两个 GEMM 后端建议至少固定完全相同的 M、N、K 和转置语义相同 BF16 输入与 FP32 accumulation 约束相同输出布局相同 warmup 和 device event 计时相同进程状态输出 checksum 或逐元素误差实际选中的 kernel 名称heuristic 数量和 workspace 大小。只比较 API 调用耗时而不记录最终 kernel很难判断差异来自库、heuristic 还是布局转换。6. 对海光 DCU 后端选型的启示这组结果对海光 DCU 开发者最直接的价值不是判断哪个库“总体更强”而是提醒后端选择必须绑定实际 DTK 版本、gfx936 库文件和目标 shape。在海光 DCU 上评估 Linear 后端时建议记录当前安装库实际返回了多少个 heuristic最终命中的 Tensile 或 hipBLASLt kernel真实 M1 shape而不是只测规则的大矩阵是否包含布局转换和 workspace 成本相同 BF16 语义下的输出 checksum。这样得到的是“当前海光 DCU 软件栈上这个 shape 应选谁”而不是脱离环境比较 API 名称。7. 实验结论在本地 gfx936 软件栈中直接 hipBLASLt BF16 M1 路径对四个真实 Decode shape 的相对性能为MLP down: 0.486x GDN out: 0.625x Attention out: 0.700x lm_head: 0.415x四项全部慢于当前 rocBLAS 参考。进一步对 rocBLAS solution 进行 tune也没有发现稳定的大幅空间。因此针对这组 shape更可靠的结论是不能按库名选择后端必须按目标 shape 和当前软件栈实测。hipBLASLt 仍可能在大 GEMM、不同布局、不同 epilogue 或其他版本的软件栈上占优本文只否定“当前环境下直接替换这四个 M1 BF16 shape”这一具体方案。本文数据来自本地固定 gfx936 环境。表中的 rocBLAS 与 hipBLASLt 时间绑定于对应 shape、dtype 和安装库版本不应外推为两个库在所有工作负载上的统一排名。