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