Charles's Castle

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

当模型开始使用数据并行、张量并行、流水线并行、专家并行和上下文并行时，通信就成为训练与推理系统的主路径之一。很多大模型系统吞吐上不去，原因常常是 all-reduce 太频繁、all-gather 太重、reduce-scatter 时机不对、通信和计算没有重叠、拓扑映射不合理，或者某些 collective 让快 G

真正高性能的 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 策略、缓存命中、工具调用和 SLO 共同决定。 推理优化需要从零散技巧整理成容量规划和瓶颈归因框架。 图源：vLLM 官方博客。原图表

模型上线后，需要持续回答四个问题：线上发生了什么、质量有没有变好、成本和稳定性是否可控、异常能不能回放并进入下一轮修复。可观测性回答“系统现在如何运行”，在线评测回答“这次变化是否值得保留”。两者应被设计成同一套闭环，而不是两个互不相干的 dashboard。 线上系统是否真的变好，要放在推理链路、容量约束、RAG/A