Charles's Castle

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

很多 kernel 优化最后不是败在“不会写更快代码”，而是败在三件事上：没有正确测量，优化方向从一开始就错了；没有可靠验证，性能上去了但结果悄悄错了；没有处理数值稳定性，速度和精度之间出现不可接受的偏差。 这页先回答“Profiling、调试与数值稳定”在「算子与编译器」里的位置：它解决什么局部问题，依赖哪些前置，最

很多算子优化失败，并不是因为工程师不够努力，而是因为掉进了一些反复出现的性能反模式。它们的共同特点是：单看局部实现似乎合理，放到真实系统里却会不断放大损失，并且往往伴随“理论上应该更快，实际上却不快”的现象。 这页先回答“性能反模式与失败案例”在「算子与编译器」里的位置：它解决什么局部问题，依赖哪些前置，最后会影响哪类

稀疏计算和 MoE （Mixture of Experts）常被看成“模型结构创新”，但一旦真正训练或部署，问题很快就会变成 kernel 与通信系统问题。原因很简单： 稠密模型的热点大多是规则大矩阵，稀疏和 MoE 的热点则往往是 token 重排、路由、gather/scatter、all-to-all 和不均匀负

低精度计算和量化，表面上看是在“减少位宽、节省显存”，但真正落到系统里时，本质上是内核与数据布局问题。很多团队第一次做量化时都会踩到同一个坑：权重文件变小了，理论带宽需求下降了，但端到端吞吐并没有变好，甚至变差。原因往往不是量化方法本身，而是 kernel 路径没有真正适配低精度数据格式。 这页先回答“低精度与量化 K

长上下文系统和 FlashAttention 的关系，不只是“长上下文需要更快 attention”这么简单。更准确地说，长上下文之所以会不断推动 attention 内核演化，是因为随着序列长度上升，attention 的瓶颈会从“算没算对”迅速转向“数据怎么搬、历史怎么存、解码时怎么读”。 这页先回答“FlashA

很多性能决策如果没有成本模型，就会变成“凭经验猜”。虽然完整精确建模很难，但在工程上仍然需要一个够用的启发式成本模型，帮助判断： 这页先回答“Kernel 成本模型与选型”在「算子与编译器」里的位置：它解决什么局部问题，依赖哪些前置，最后会影响哪类工程或研究判断。 前置 ：先理解张量 shape、显存层次和 GEMM；

当一个 kernel 或训练/推理路径性能异常时，最容易犯的错误是只在软件层找原因。实际上很多问题只有带着硬件感知去排查，才能快速定位。 这页先回答“硬件感知排查清单”在「算子与编译器」里的位置：它解决什么局部问题，依赖哪些前置，最后会影响哪类工程或研究判断。 前置 ：先理解张量 shape、显存层次和 GEMM；系统

很多大模型系统瓶颈并不是某个 kernel 写得不够好，而是并行策略和物理拓扑映射错位了。你可以拥有很强的 GPU、很快的单卡 kernel、很成熟的并行框架，但如果： 这页先回答“GPU 互联与拓扑映射”在「算子与编译器」里的位置：它解决什么局部问题，依赖哪些前置，最后会影响哪类工程或研究判断。 前置 ：先理解张量

现代 AI kernel 的性能，大多围绕数据如何穿过 GEMM、Attention、Norm、Quantization 和 Memory Movement 这一串热点算子被决定。GEMM 是计算主引擎，Attention 是序列模型的结构性热点，融合 kernel 则试图减少中间读写和 launch 开销，让系统更接