Charles's Castle

这页先按“论文证据节点”读：先问它解决哪一个瓶颈，再看核心图表、实验 setting 和不能外推的边界。背景概念先回 论文专题讲解 和 扩散模型。 前置 ：不必先读完所有相关论文，但要知道本篇的输入、训练/推理路径和评测口径分别对应什么。 主线关系 ：读完后把结论回填到「扩散模型」路线里，判断它改变的是机制、成本、数据

这页先按“论文证据节点”读：先问它解决哪一个瓶颈，再看核心图表、实验 setting 和不能外推的边界。背景概念先回 论文专题讲解 和 扩散模型。 前置 ：不必先读完所有相关论文，但要知道本篇的输入、训练/推理路径和评测口径分别对应什么。 主线关系 ：读完后把结论回填到「扩散模型」路线里，判断它改变的是机制、成本、数据

这页先按“论文证据节点”读：先问它解决哪一个瓶颈，再看核心图表、实验 setting 和不能外推的边界。背景概念先回 论文专题讲解 和 扩散模型。 前置 ：不必先读完所有相关论文，但要知道本篇的输入、训练/推理路径和评测口径分别对应什么。 主线关系 ：读完后把结论回填到「扩散模型」路线里，判断它改变的是机制、成本、数据

很多 kernel 优化最终之所以有效，不是因为它在所有 shape 上都快，而是因为它精准命中了真实 workload 中最常出现的那些 shape bucket。 因此在进入特化和 autotune 之前，先理解 workload 分布本身，往往比直接写新 kernel 更重要。 这页先回答“Workload 建模

Triton 在 AI 系统里越来越重要，不是因为它能完全替代 CUDA，而是因为它提供了一种适合张量 kernel 的中层抽象：比手写 CUDA 更接近矩阵块和张量块思维，又比纯图编译的黑盒代码生成更可控。 这页先回答“Triton 编程模型与自动调优”在「算子与编译器」里的位置：它解决什么局部问题，依赖哪些前置，最

很多 kernel 项目最难的阶段，不是把第一版做快，而是把它长期维持在“正确、快、可升级”的状态。一个高性能算子如果没有测试、性能回归和版本维护机制，最终很容易退化成： 这页先回答“Kernel 测试、回归与维护”在「算子与编译器」里的位置：它解决什么局部问题，依赖哪些前置，最后会影响哪类工程或研究判断。 前置 ：先

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

很多高性能系统并不是靠“一个万能 kernel”获胜，而是靠一整套运行时 dispatch 机制：根据 shape、dtype、layout、设备类型、batch 形态和任务阶段，为当前请求挑选最合适的 kernel 路径。 也就是说，真正的性能系统不仅要有好 kernel，还要有 挑 kernel 的能力 。 这页先

做算子优化时，最常见的失败不是“技术不够强”，而是没有先判断瓶颈类型，benchmark 设计不可靠，看到局部提速就误以为端到端受益，或者没有把案例还原成通用方法。 这页先回答“Roofline 建模与性能案例”在「算子与编译器」里的位置：它解决什么局部问题，依赖哪些前置，最后会影响哪类工程或研究判断。 前置 ：先理解

在很多大模型系统里，真正频繁拖慢整体速度的，并不总是最大的 GEMM，而是那些“单次看起来不大、但出现极其频繁”的算子：reduction、softmax、layernorm、rmsnorm、rope、gather、scatter、layout transform。它们通常更偏带宽受限，很适合做融合，对 shape、s