Charles's Castle

这篇回答的问题。 如何理解“性能反模式与失败案例”背后的核心机制、适用边界和下一步阅读路径。 很多算子优化失败，并不是因为工程师不够努力，而是因为掉进了一些反复出现的性能反模式。它们的共同特点是：单看局部实现似乎合理，放到真实系统里却会不断放大损失，并且往往伴随“理论上应该更快，实际上却不快”的现象。 把这些反模式单独

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

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

FlashAttention 经常被讲成“新的 attention 机制”，但它没有改变 dense attention 的数学定义，也没有把二次配对计算变成线性。它真正改变的是数据路径：不要把完整的 $QK^ top$ 分数矩阵和 softmax 概率矩阵写进 HBM，再读出来乘 $V$；而是在片上分块完成打分、归一

这篇回答的问题。 如何理解“Kernel 成本模型与选型”背后的核心机制、适用边界和下一步阅读路径。 很多性能决策如果没有成本模型，就会变成“凭经验猜”。虽然完整精确建模很难，但在工程上仍然需要一个够用的启发式成本模型，帮助判断： 1. 该优先做 fusion，还是优先做 layout 优化； 2. 该写 Triton

这篇回答的问题。 如何理解“硬件感知排查清单”背后的核心机制、适用边界和下一步阅读路径。 当一个 kernel 或训练/推理路径性能异常时，最容易犯的错误是只在软件层找原因。实际上很多问题只有带着硬件感知去排查，才能快速定位。 图源：NVIDIA Nsight Systems 文档。原图表达 GPU 时间线中 CPU/

大模型系统的很多瓶颈不是单卡 kernel 慢，而是通信路径选错。你可以有很强的 GPU、很快的 GEMM、很成熟的并行框架，但如果张量并行跨了慢链路，MoE token all-to-all 穿过拥塞网络，或者 GPU 到 NIC 走了错误 NUMA 域，端到端吞吐仍然会塌。 核心问题 并行训练和推理把一个模型拆到多

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

低精度话题里， FP8 和优化器 kernel 值得单独拿出来讲，因为它们主要影响的是训练主路径，而不是单纯的推理压缩。权重量化更多关注部署态显存和带宽；而 FP8 训练与 fused optimizer kernel 关心的是：在大规模训练中，如何把前向、反向、梯度、主权重、优化器状态和数值缩放组织成一套既快又稳的执

这页是 DeepGEMM 解读 的工程附录，重点放在源码阅读、API 地图、调用路径和接入检查。主页面负责建立系统判断，这页负责帮助你真的读仓库和评估能不能接进自己的服务链路。 图源：DeepSeek-V3 Technical Report。原图表达 FP8 训练不是单一 dtype，而是由 scale、累加、通信、存