海光 DCU 算子移植案例shape 一样layout 不一样结果会彻底失真开场在海光 DCU 上移植一个上游 kernel最危险的情况不是编译失败也不是 shape 对不上而是shape 完全正确 kernel 正常执行 速度看起来更快 但每个元素的语义位置都错了本地移植一条 GDN Decode 融合路径时就遇到了这种问题。上游 kernel 面向 Qwen3-Next 的 per-head interleaved layout本地 Qwen3.5 则输出连续的 Q、K、V、Z 和 B、A 分组。两边 tensor 的总元素数和外部 shape 都能对上直接传入也不会越界但 kernel 会把正确的数据当成错误的逻辑分量读取。结果曾经出现“吞吐提升约 68%”同时 10/10 文本全部错误、所有请求都生成到最大长度。1. 一个很有吸引力的 standalone 结果目标形状为H16 HV48 K128 V128 conv width4 dtypeBF16在上游 interleaved layout 下融合路径的 CUDAGraph 结果为Token 数基线融合实现加速比T140.6752 us14.0568 us2.8936xT245.3776 us17.0344 us2.6639xT450.4928 us36.4920 us1.3837xT1 每层节省 26.6184 us48 层的纸面累计约为26.6184 us × 48 ≈ 1.28 ms/token从绝对时间看这是一条值得集成的路线。2. Shape 契约为什么没有发现问题上游 Qwen3-Next kernel 消费的是按 K head 交错排列的数据。可以把它抽象成head0: Q K V Z B A head1: Q K V Z B A ...本地 Qwen3.5 投影输出则是连续分组qkvz [all Q, all K, all V, all Z] ba [all B, all A]两种布局包含同样数量的 Q、K、V、Z、B、A 元素所以tensor 总长度相同dtype 相同外部 shape 可以相同指针合法kernel 不一定越界。但同一个 offset 在两种布局中代表不同的逻辑元素。这类错误无法靠 shape assertion 发现。3. 第一次真实命中看起来快了 68%一次集成中融合路径真正命中但 Prefill 和 Decode 的数据语义已经错误。结果为基线 output throughput: 11.2668847 融合版本: 18.9294178 输出 token: 10240 文本不一致: 10/10所有请求都生成到最大输出长度因此表面上的约 68% 不是性能收益而是 workload 已经变化。生成轨迹错误后每个请求执行的 token 数不同recurrent state 不同停止条件不同吞吐分母和分子都改变。这组数据只能证明集成错误不能用来评价 kernel 性能。4. 恢复 Prefill 后Decode 仍然错误下一版恢复了原始 Prefill只在 Decode 使用上游 kernel但布局问题仍未修复指标基线直接接入上游布局output throughput11.26688472.3278524输出 token1786293文本不一致0/1010/10mean TPOT44.3025 ms44.0333 msp99 TPOT45.0044 ms44.5871 msTPOT 看起来下降了不到 1%但这同样没有解释价值因为 recurrent state 和输出轨迹已经完全不同。当 tokens 从 1786 变成 293 时不能把 44.0333 ms 与正确路径的 44.3025 ms 当作公平 A/B。5. 显式 layout adapter 能修正语义为了验证根因本地加入显式 adapter把 Qwen3.5 连续分组转换成上游 interleaved layout。初始捕获结果为baseline: 0.0229056 ms adapter: 0.0207440 ms event speedup: 1.1042xZ 和 conv state 逐位一致core 与 SSM state 的相对 L2 约为 4.1e-4 和 4.4e-4输出 finite。这证明 layout mismatch 可以修复。但进一步审计发现初始 baseline 多计入了一次生产路径中不存在的 Z copy因此 1.1042x 偏乐观。移除不公平 copy 后baseline: 20.27319 us adapter: 19.94199 us speedup: 1.01661x语义修好后转换成本几乎吃掉了融合收益。6. 最终 native flat-layout kernel为了避免 adapter 的 split、view、cat 和 reshape最终实现直接按照 Qwen3.5 的 flat layout 读取激活只改变 kernel 内的地址映射。公平结果为baseline: 20.27239 us native: 17.04439 us speedup: 1.18939x saving: 3.22800 us/layer48 层累计约 0.15494 ms/token。该路径还进行了 1024 步连续状态更新。第 1024 步core relative L2: 3.6856e-3finite SSM relative L2: 3.6981e-5finite Z / conv state: bitwise exact 重复运行: bitwise deterministic正确性和确定性得到了控制但绝对节省仍不足以进入完整服务。这也反向证明最初 2.8936x 的一大部分来自上游 Qwen3-Next 布局准备开销而不是本地 Qwen3.5 生产基线中真实存在的可消除时间。7. 在海光 DCU 上移植 kernel应检查什么7.1 不只记录 shape还要记录语义布局至少写清每一段逻辑变量的 offsethead-major 还是 group-majorinterleaved 还是 contiguousstride 与 storage orderkernel 每个 lane 实际读取的逻辑元素。7.2 用 one-hot 输入验证映射随机误差有时难以定位错位。one-hot 可以直接回答输入的第 i 个逻辑元素 最终被 kernel 当成了谁7.3 把 layout conversion 纳入计时如果上游 kernel 需要 adaptersplit/cat/reshape 和额外写回都必须进入 CUDAGraph 测量窗口。7.4 输出轨迹变化后停止讨论性能只要 token 数或文本发生变化端点吞吐和 TPOT 就不再是同一 workload 的比较。7.5 在真实 gfx936 软件栈重新建立基线上游论文或 PR 的 baseline 可能包含本地模型根本不需要的 layout 工作。移植到海光 DCU 后必须针对本地模型和 DTK 环境重新测量。8. 结论这次海光 DCU 移植经历了三个阶段上游 interleaved layout: 2.8936x但不是 Qwen3.5 的公平基线 显式 adapter: 1.01661x语义修复但转换成本很高 native Qwen3.5 flat layout: 1.18939x每层节省 3.228 us最重要的教训是Shape 只描述 tensor 有多大layout 才描述每个元素是谁。在海光 DCU 上复用上游 Triton、HIP 或 AITER kernel 时编译成功和 shape 对齐远远不够。只有语义布局、数值轨迹和完整服务都一致局部加速才有意义。本文数据来自本地 gfx936/Qwen3.5 GDN 实验只用于说明 layout contract 对算子移植的影响。不同模型布局需要独立验证。# 海光 DCU 算子移植案例shape 一样layout 不一样结果会彻底失真开场在海光 DCU 上移植一个上游 kernel最危险的情况不是编译失败也不是 shape 对不上而是shape 完全正确 kernel 正常执行 速度看起来更快 但每个元素的语义位置都错了本地移植一条 GDN Decode 融合路径时就遇到了这种问题。上游 kernel 面向 Qwen3-Next 的 per-head interleaved layout本地 Qwen3.5 则输出连续的 Q、K、V、Z 和 B、A 分组。两边 tensor 的总元素数和外部 shape 都能对上直接传入也不会越界但 kernel 会把正确的数据当成错误的逻辑分量读取。结果曾经出现“吞吐提升约 68%”同时 10/10 文本全部错误、所有请求都生成到最大长度。1. 一个很有吸引力的 standalone 结果目标形状为H16 HV48 K128 V128 conv width4 dtypeBF16在上游 interleaved layout 下融合路径的 CUDAGraph 结果为Token 数基线融合实现加速比T140.6752 us14.0568 us2.8936xT245.3776 us17.0344 us2.6639xT450.4928 us36.4920 us1.3837xT1 每层节省 26.6184 us48 层的纸面累计约为26.6184 us × 48 ≈ 1.28 ms/token从绝对时间看这是一条值得集成的路线。2. Shape 契约为什么没有发现问题上游 Qwen3-Next kernel 消费的是按 K head 交错排列的数据。可以把它抽象成head0: Q K V Z B A head1: Q K V Z B A ...本地 Qwen3.5 投影输出则是连续分组qkvz [all Q, all K, all V, all Z] ba [all B, all A]两种布局包含同样数量的 Q、K、V、Z、B、A 元素所以tensor 总长度相同dtype 相同外部 shape 可以相同指针合法kernel 不一定越界。但同一个 offset 在两种布局中代表不同的逻辑元素。这类错误无法靠 shape assertion 发现。3. 第一次真实命中看起来快了 68%一次集成中融合路径真正命中但 Prefill 和 Decode 的数据语义已经错误。结果为基线 output throughput: 11.2668847 融合版本: 18.9294178 输出 token: 10240 文本不一致: 10/10所有请求都生成到最大输出长度因此表面上的约 68% 不是性能收益而是 workload 已经变化。生成轨迹错误后每个请求执行的 token 数不同recurrent state 不同停止条件不同吞吐分母和分子都改变。这组数据只能证明集成错误不能用来评价 kernel 性能。4. 恢复 Prefill 后Decode 仍然错误下一版恢复了原始 Prefill只在 Decode 使用上游 kernel但布局问题仍未修复指标基线直接接入上游布局output throughput11.26688472.3278524输出 token1786293文本不一致0/1010/10mean TPOT44.3025 ms44.0333 msp99 TPOT45.0044 ms44.5871 msTPOT 看起来下降了不到 1%但这同样没有解释价值因为 recurrent state 和输出轨迹已经完全不同。当 tokens 从 1786 变成 293 时不能把 44.0333 ms 与正确路径的 44.3025 ms 当作公平 A/B。5. 显式 layout adapter 能修正语义为了验证根因本地加入显式 adapter把 Qwen3.5 连续分组转换成上游 interleaved layout。初始捕获结果为baseline: 0.0229056 ms adapter: 0.0207440 ms event speedup: 1.1042xZ 和 conv state 逐位一致core 与 SSM state 的相对 L2 约为 4.1e-4 和 4.4e-4输出 finite。这证明 layout mismatch 可以修复。但进一步审计发现初始 baseline 多计入了一次生产路径中不存在的 Z copy因此 1.1042x 偏乐观。移除不公平 copy 后baseline: 20.27319 us adapter: 19.94199 us speedup: 1.01661x语义修好后转换成本几乎吃掉了融合收益。6. 最终 native flat-layout kernel为了避免 adapter 的 split、view、cat 和 reshape最终实现直接按照 Qwen3.5 的 flat layout 读取激活只改变 kernel 内的地址映射。公平结果为baseline: 20.27239 us native: 17.04439 us speedup: 1.18939x saving: 3.22800 us/layer48 层累计约 0.15494 ms/token。该路径还进行了 1024 步连续状态更新。第 1024 步core relative L2: 3.6856e-3finite SSM relative L2: 3.6981e-5finite Z / conv state: bitwise exact 重复运行: bitwise deterministic正确性和确定性得到了控制但绝对节省仍不足以进入完整服务。这也反向证明最初 2.8936x 的一大部分来自上游 Qwen3-Next 布局准备开销而不是本地 Qwen3.5 生产基线中真实存在的可消除时间。7. 在海光 DCU 上移植 kernel应检查什么7.1 不只记录 shape还要记录语义布局至少写清每一段逻辑变量的 offsethead-major 还是 group-majorinterleaved 还是 contiguousstride 与 storage orderkernel 每个 lane 实际读取的逻辑元素。7.2 用 one-hot 输入验证映射随机误差有时难以定位错位。one-hot 可以直接回答输入的第 i 个逻辑元素 最终被 kernel 当成了谁7.3 把 layout conversion 纳入计时如果上游 kernel 需要 adaptersplit/cat/reshape 和额外写回都必须进入 CUDAGraph 测量窗口。7.4 输出轨迹变化后停止讨论性能只要 token 数或文本发生变化端点吞吐和 TPOT 就不再是同一 workload 的比较。7.5 在真实 gfx936 软件栈重新建立基线上游论文或 PR 的 baseline 可能包含本地模型根本不需要的 layout 工作。移植到海光 DCU 后必须针对本地模型和 DTK 环境重新测量。8. 结论这次海光 DCU 移植经历了三个阶段上游 interleaved layout: 2.8936x但不是 Qwen3.5 的公平基线 显式 adapter: 1.01661x语义修复但转换成本很高 native Qwen3.5 flat layout: 1.18939x每层节省 3.228 us最重要的教训是Shape 只描述 tensor 有多大layout 才描述每个元素是谁。在海光 DCU 上复用上游 Triton、HIP 或 AITER kernel 时编译成功和 shape 对齐远远不够。只有语义布局、数值轨迹和完整服务都一致局部加速才有意义。本文数据来自本地 gfx936/Qwen3.5 GDN 实验只用于说明 layout contract 对算子移植的影响。不同模型布局需要独立验证。
