Charles's Castle

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

低精度计算和量化落到系统里时，本质上是内核与数据布局问题。很多团队第一次做量化时都会踩到同一个坑：权重文件变小了，理论带宽需求下降了，但端到端吞吐并没有变好，甚至变差。原因往往是 kernel 路径没有真正适配低精度数据格式。 低精度与量化 kernel 的重点是： 当你已经决定使用 BF16、FP8、INT8、INT

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

很多性能决策如果没有成本模型，就会变成“凭经验猜”。虽然完整精确建模很难，但在工程上仍然需要一个够用的启发式成本模型，帮助判断： 1. 该优先做 fusion，还是优先做 layout 优化； 2. 该写 Triton，还是直接调用现成库； 3. 某个 shape 值不值得特化； 4. 某条路径更可能受带宽、launc

当一个 kernel 或训练/推理路径性能异常时，最容易犯的错误是只在软件层找原因。实际上很多问题只有带着硬件感知去排查，才能快速定位。 图源：NVIDIA Nsight Systems 文档。原图表达 GPU 时间线中 CPU/GPU 等待和空洞如何暴露系统瓶颈；读图重点是把硬件排查从“猜 kernel 慢”改成先看

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

现代 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 训练由 scale、累加、通信、存储和高精保护共同组成；读图重点是：读 DeepGEMM 源码时先追

DeepGEMM 值得单独讲，因为它把现代大模型算子工程中的几个关键趋势压缩到同一个样本里：细粒度 FP8 scaling、Hopper/Blackwell 硬件特化、运行时 JIT、MoE grouped GEMM、decode masked layout，以及从单个 GEMM 走向融合通信与计算的 Mega MoE