Charles's Castle

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 优化不是把一段 for 循环拆成很多线程就结束。真正要判断的是：一个算子里的数据，从 HBM 进来以后，怎样经过 L2、shared memory、register、Tensor Core 或普通 CUDA core，最后再写回 HBM。只要这条数据路径画不清，thread、block、warp、occupa

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

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

离线测一个模型，常见做法是加载权重、喂 prompt、看 tokens/s。真正上线后，用户看到的不是这一个数字，而是一条请求链：排队、鉴权、路由、prefill、KV cache 分配、decode 循环、采样、detokenize、安全检查、工具调用、流式返回、日志追踪。任何一段慢，都会把“模型很快”变成“服务很慢

推理运行时不是“把模型权重加载起来”的薄壳。它真正负责的是一条在线生产线：请求进入队列，prompt 做 prefill，随后逐 token decode，KV cache 随输出增长，batch 每一步都在变化，最后结果以 streaming 或一次性响应返回给应用。 同一份权重换一个 serving runtime

现代推理系统已经很少只是“给模型一个 prompt 然后生成答案”。很多真实系统更接近下面这种结构： $$ text retrieval rightarrow text context assembly rightarrow text model rightarrow text tools/agents $$ 如果只想

这篇回答的问题。 如何理解“容量规划与推理优化”背后的核心机制、适用边界和下一步阅读路径。 推理系统上线后，团队很快会遇到两个问题：现在还能撑多久，下一步该先优化哪里。这两个问题表面像“算资源”，本质是在做系统建模。大模型推理容量不是固定常数，而是请求分布、输入输出长度、模型结构、batch 策略、缓存命中、工具调用和