LLM推理慢，先看Prefill和Decode：Amit Shekhar的学习清单

Amit Shekhar在X上列了一份LLM Inference Engineering清单。内容从Prefill vs Decode、KV Cache、PagedAttention，一路排到vLLM、SGLang、GPU和TPU。清单本身像目录，真正有价值的是顺序：先理解生成循环，再谈内存、吞吐、引擎和硬件。

先拆生成循环

Amit Shekhar是Outcome School创始人。他把学习路径的起点放在自回归生成和Prefill/Decode上，这个选择很实际。线上问题经常从这里冒出来：为什么首token快，后面吐字慢；为什么长上下文一上来就吃掉大量显存；为什么并发一高，GPU看起来忙，吞吐却上不去。

Prefill读prompt，计算密集；Decode逐token写答案，更受内存带宽限制。有网友在回复里提到，Prefill和Decode的分野解释了本地Qwen为什么首token感觉正常，后面却变慢。这个观察不新，但很准。很多推理优化文章从模型结构讲起，这份清单从生成循环讲起，反而更接近生产环境里的症状。

内存和attention决定长会话成本

KV Cache是第一个关键点。模型生成每个token时，没必要把历史Key和Value重新算一遍，缓存下来能省大量重复计算。问题也跟着来：长会话的KV Cache会膨胀，显存被吃掉，能同时服务的用户数下降。

PagedAttention解决的是KV Cache的内存浪费和碎片问题，思路借用了操作系统分页。Flash Attention处理attention本身的计算和显存访问效率。Grouped Query Attention则从模型结构上减少Key/Value头数量，降低缓存开销。Amit的仓库里还单独列了KV Cache Compression，讲量化、token淘汰、跨头共享和低秩压缩。

有网友在Qwen3.5-4B长上下文上做了q4_0和q8_0的配对试验，10次里9次答案一致，并问课程是否覆盖KV cache量化。这个结果只能当个案，不能直接推广。Amit没有在回复里展开这个问题，不过仓库里已经有KV Cache Compression一篇。

吞吐和延迟是另一条线

Continuous Batching让GPU在每个decode step都尽量塞满请求，不再等一整批静态任务跑完。Speculative Decoding用小模型先猜几个token，大模型再验证，猜对就省时间。Token Streaming把生成结果边算边推给前端，用户感知的等待时间会短很多。Prompt Caching复用相同前缀的KV Cache，适合系统提示词固定、多轮对话或agent场景。

这些技术解决的不是同一个问题。首token延迟、单token输出速度、整体吞吐、长会话显存成本，各自有对应的优化点。把所有手段堆在一起，未必更快。

引擎和硬件放在后面

清单后半段进入vLLM、SGLang、TensorRT-LLM、GGUF、Ollama，以及GPU、CUDA Kernels、TPU和LPU。vLLM的核心是PagedAttention和continuous batching，SGLang的核心是RadixAttention对前缀的复用。有网友问vLLM和SGLang哪个更容易理解吞吐，Amit的清单把两者并列，仓库里分别拆了PagedAttention和RadixAttention。

对开发背景的人，这份清单适合当复习索引。对非技术读者，它也能解释产品体验背后的技术分层：首token延迟看Prefill，后续吐字速度看Decode，长会话成本看KV Cache和PagedAttention，并发能力看Continuous Batching和引擎调度。

Amit给出的资源仓库在这里：https://github.com/amitshekhariitbhu/llm-inference-engineering 。原文链接：https://x.com/amitiitbhu/status/2115878569993969850 。仓库说明里写了，这个系列会继续更新。

如果只记一个结论：先分清Prefill和Decode，再去看每个优化动的是哪一段。换GPU通常排后面。