海光 DCU 长上下文 Attention：从 page784 到 page832
摘要在大模型推理中，Attention 的公式通常不是最难的部分，真正决定性能的往往是数据如何落在显存里，以及硬件一次能够以什么粒度把这些数据取出来。 本文以 Qwen3.5 的官方 prefix-off 长上下文路径为例，讨论一个看似很小、实际上贯穿 vLLM 配置、KV Cache、paged attention 和 DCU kernel dispatch 的问题：该路径的默认物理 KV Cache page 是 784 tokens，而海光 DCU gfx936 上的 vendor paged-attention 路径要求 page 长度满足 64-token 对齐。最终我们没有把...
海光 DCU 上 Qwen3.5 推理性能工程：从 Prefill/Decode 热点到端到端收益
摘要在大模型推理优化中，最容易被误读的一件事，是把某个 kernel 的局部加速比直接当成服务吞吐的提升。一个 kernel 即使在独立测试中快了 1.08 倍，完整服务也可能只快几个百分点，甚至几乎没有变化。 本文以海光 DCU gfx936 路径上的 Qwen3.5-27B BF16 推理为例，使用本地已经完成的 profile、kernel microbench 和同容器端点 A/B 数据，回答三个问题： Prefill 和 Decode 分别被什么算子限制； 为什么 BF16 的 M=1 GEMM/GEMV 会成为 Decode 的主要性能墙； 一...
海光 DCU Profile 实战：如何从六万个 GPU kernel 还原一枚 Token
开场在海光 DCU 上给大模型做 profile，最难的通常不是“能不能生成 trace”，而是 trace 生成以后该怎么看。 一次 Qwen3.5-27B BF16 本地采样共产生： 1234总事件: 235,964GPU 事件: 61,804kernel 事件: 60,124GPU event 总时长: 5773.493 ms 直接按 kernel 总耗时排序，只能看到一长串 Tensile、Triton、Attention 和自定义 kernel 名称。它不会主动告诉你： 哪些属于 Prefill； 哪些属于 Decode； 一个 kernel 每 ...
编译成功不等于生效：海光 DCU vLLM 增量编译验真
我在海光 DCU 上修改 vLLM kernel 时，最浪费时间的一次并不是编译报错。 那次编译正常结束，服务能够启动，接口也能返回结果，性能测试甚至给出了一个看起来可以解释的变化。后来重新核对运行环境，我才发现一个更麻烦的问题：源码、构建产物和服务实际加载的文件并不是同一套状态。此前围绕性能做出的判断，只能全部作废。 这件事改变了我的调试顺序。现在每次改完 ROCm kernel，我不会立刻看吞吐，而是先回答一个更基础的问题： 正在海光 DCU 上执行的，究竟是不是我刚刚修改、编译并准备测试的那份代码？ 本文记录的是我在 gfx936 架构海光 DCU 上实际使用过的一套 vLLM...