今天大模型的钱，大头不在训练而在推理——OpenAI 每天生成上千亿词，推理是 7×24 小时在烧。可推理慢有个反直觉的真相：多数时候 GPU 不是在算，而是在等数据。本文对应 Datawhale diy-llm 第十章，按一条主线重组：先讲清推理与训练"算力 vs 带宽"的瓶颈区别，再拆开 Prefill/Decode 两阶段与 KV Cache，用"算术强度"点破内存受限的本质与批处理的拼车效应，理清延迟与吞吐的矛盾，最后把线性注意力/扩散、推测解码/MTP、提示词压缩等五花八门的优化技术归到三条路线上，配以重绘的示意图与论文原图。

前两讲都在单张卡上做文章——可当模型大到一张卡根本装不下，故事就变了。这一讲把战场搬到多卡多机：先看清新瓶颈不再是 HBM 访存，而是慢得多的"卡间通信"；再用一条恒等式（All-Reduce = Reduce-Scatter + All-Gather）讲透集合通信的成本；然后把数据、张量、流水线、序列四种并行统一到"一份负载、四种切法"的框架里，逐一拆解 ZeRO/FSDP 如何把单卡显存从 120GB 压到 1.9GB、张量并行为何只能关在节点内、流水线的气泡怎么挤掉；最后落到"先快后慢、由内向外"的组合法则。

上一讲讲清了 GPU 优化的靶心——减少访存、提高复用；这一讲是动手篇：你怎么知道自己打中了？答案只有一个——测量。全文沿一条工程闭环展开：先用基准测试"测得准"（绕开异步执行的计时陷阱），再用性能剖析"找得到"瓶颈 kernel，最后用算子融合"改得对"，并把 CUDA C++、Triton、torch.compile 三条落地路径放到同一个 GELU 上对比，最后给出"什么时候才值得亲自写 kernel"的决策框架。

一条主线贯穿全文——GPU 的瓶颈从来不在算力，而在访存。先看清 CPU 与 GPU 的设计哲学差异，再拆解 GPU 的执行模型与分层内存，用屋顶线模型确立"减少访存、提高复用"这一优化总纲；随后把低精度、算子融合、重计算、内存合并、分块五种技术统一到这条主线上，最后落到两个经典案例：训练/推理通用的 FlashAttention 与推理期 KV Cache 管理的 PagedAttention。

跟随斯坦福 CS336 第二讲，从“训练要多久”和“显存放得下多大模型”两个真实问题出发，系统讲解张量机制、浮点精度、FLOPs 估算与训练全流程的资源核算方法。