Charles's Castle

很多 kernel 优化最终有效，是因为它精准命中了真实 workload 中最常出现的那些 shape bucket。 因此在进入特化和 autotune 之前，先理解 workload 分布本身，往往比直接写新 kernel 更重要。 图源：vLLM 官方博客。原图表达请求调度、KV 管理和 worker 执行之间

Triton 不是“Python 版 CUDA”。它真正提供的是一种适合神经网络张量算子的中间层：你不用手写每个 thread 的同步和访存细节，但仍然要明确一个 program instance 负责哪块输出、怎样计算地址、怎样处理边界、怎样累加、怎样选择 tile，以及编译和 autotune 什么时候发生。 读

很多 kernel 项目最难的阶段，是把第一版长期维持在“正确、快、可升级”的状态。一个高性能算子如果没有测试、性能回归和版本维护机制，最终很容易退化成： 1. 只在作者机器上能跑； 2. 一升级框架就坏； 3. 新 GPU 一上来性能掉很多； 4. 某些边界 shape 悄悄出错； 5. 没人敢继续改。 因此算子工程

训练里的 attention kernel 和在线服务里的 attention kernel，看起来在算同一个公式，实际上往往面对完全不同的系统条件。训练时更像规则的大矩阵运算；服务时尤其是 decode 阶段，更像一个在动态批处理、KV 页面管理、长短请求混杂和 tail latency 约束下运作的内存系统。 因此

很多高性能系统靠一整套运行时 dispatch 机制获胜：根据 shape、dtype、layout、设备类型、batch 形态和任务阶段，为当前请求挑选最合适的 kernel 路径。 也就是说，真正的性能系统不仅要有好 kernel，还要有 挑 kernel 的能力 。 图源：vLLM 官方博客。原图表达 runti

做算子优化时，最常见的失败来自瓶颈类型判断缺失、benchmark 设计不可靠、把局部提速误判成端到端受益，或者没有把案例还原成通用方法。 Roofline、benchmark 设计和典型案例要一起看，才能把“性能感觉”变成“性能判断”：先判断该往算力、带宽、layout 还是 launch 开销上用力，再谈优化动作是

大模型系统里最容易被低估的，不一定是最大的 GEMM，而是那些每层、每步、每个 token 都会经过的小算子：reduction、softmax、LayerNorm、RMSNorm、RoPE、gather、scatter、layout transform、pack/unpack。它们单次 FLOPs 不多，但会反复读写

很多 kernel 调优到了后期，真正需要看的已经不只是源码，而是编译之后到底生成了什么。因为同一段高层代码，可能在不同编译器、不同版本、不同 GPU 上生成完全不同的底层结果。 这也是为什么成熟的算子工程师，最终都会形成一个习惯： 必要时看 PTX，看 SASS，看寄存器和指令路径，而不是只相信源码意图。 图源：NV

很多 kernel 优化最后败在三件事上：没有正确测量，优化方向从一开始就错了；没有可靠验证，性能上去了但结果悄悄错了；没有处理数值稳定性，速度和精度之间出现不可接受的偏差。 成熟算子工程要建立从热点识别、性能定位、正确性验证到数值验收的完整闭环。 Profiling 先于优化 AI 系统里的直觉经常误导人： 1. 以

很多算子优化失败，常常是因为掉进了一些反复出现的性能反模式。它们的共同特点是：单看局部实现似乎合理，放到真实系统里却会不断放大损失，并且往往伴随“理论上应该更快，实际上却不快”的现象。 把这些反模式单独列出来很有价值，因为它能帮助你少走很多弯路。 反模式一：只看 FLOPs，不看数据流 最常见的误判是 ：算法 FLOP