Charles's Castle

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

这页是 DeepGEMM 解读 的工程附录，重点放在源码阅读、API 地图、调用路径和接入检查。主页面负责建立系统判断，这页负责帮助你真的读仓库和评估能不能接进自己的服务链路。 这页先回答“DeepGEMM 源码与接入”在「算子与编译器」里的位置：它解决什么局部问题，依赖哪些前置，最后会影响哪类工程或研究判断。 前置

DeepGEMM 值得单独讲，不是因为它只是一个更快的 GEMM 库，而是因为它把现代大模型算子工程中的几个关键趋势压缩到同一个样本里：细粒度 FP8 scaling、Hopper/Blackwell 硬件特化、运行时 JIT、MoE grouped GEMM、decode masked layout，以及从单个 GE

AI kernel 工程里常见误解是：既然已有 torch.compile 、Triton、cuBLAS、TensorRT，为什么还要理解 CUTLASS 、 CuTe 、模板库、DSL 和图编译器？真正原因是，AI 系统不是单一抽象层能解决的。不同工具分别负责图级融合、库级高性能基元、模板级可组合 kernel，以及

很多人第一次写自定义 kernel 时，会把注意力放在“这个 kernel 跑得够不够快”。但在真实工程里，性能只是其中一部分。一个自定义算子想真正进入训练或推理系统，还必须解决框架调用、autograd、图编译、profiler、shape / dtype / device dispatch、fallback、测试和

CUDA 之所以长期是 AI kernel 的主语言，不只是因为它能在 GPU 上写程序，而是因为它把并行执行模型、内存层次和同步机制暴露得足够直接。理解 CUDA 的关键不是背 API，而是看清三件事：线程如何被调度，数据如何在 register、shared memory、L2 和 HBM 之间移动，为什么很多优化

当模型开始使用数据并行、张量并行、流水线并行、专家并行和上下文并行时，通信就不再是“附属开销”，而是训练与推理系统的主路径之一。很多大模型系统之所以吞吐上不去，不是因为 GPU 算得慢，而是因为 all-reduce 太频繁、all-gather 太重、reduce-scatter 时机不对、通信和计算没有重叠、拓扑映

真正高性能的 AI kernel，往往并不只靠一个技巧，而是若干模式叠加的结果：tiling、双缓冲、流水线、persistent kernel、epilogue fusion、threadblock swizzle、shape specialization、autotune。理解这些模式，能帮助你把很多看似不同的实现

这页是推理章节的第一课。目标不是让你记住所有 serving 框架名字，而是让你能跟着一次请求，分清它什么时候在排队、什么时候在 prefill、什么时候在 decode、什么时候被 KV cache 和调度拖住。 这页先回答“推理服务系统”在「推理」里的位置：它解决什么局部问题，依赖哪些前置，最后会影响哪类工程或研究

模型推理已经不只是“加载权重然后调用 generate ”。真正决定线上成本和时延的，是一层专门的运行时系统：它管理 continuous batching、KV cache、prefix cache、paged attention、量化 kernel、图捕获、路由、分布式执行、多模型共存和 tracing。 vLLM