M50：自回归推理数据流：Prefill、Decode、KV Cache 与服务指标

内容类型：预习教材（不代表已完成）
日期：2026-10-12
阶段：P1 · AI Model Engineering 90
周次：W8 · 推理、KV Cache、量化与 serving
节奏：周一概念与阅读
状态：教材已备；学习未完成
标签：prefill、decode、kv-cache、ttft、throughput

一句话定义

大模型推理分为并行处理输入的 prefill 与逐 token 生成的 decode；KV cache 用内存保存历史注意力状态，避免每一步重复计算全部前缀。

学习目标

1. 能画出 tokenization→prefill→KV cache→decode→停止的流程。
2. 区分 TTFT、inter-token latency、总延迟与吞吐。
3. 理解 batching、precision 与 memory bandwidth 对两个阶段的不同影响。

核心知识

Prefill 一次处理整个输入序列，为每层计算表示并建立 key/value cache。矩阵规模大、并行度高，常更偏计算密集。输入越长，首 token 前需做的工作越多。

Decode 每次只输入最新 token，读取全部历史 K/V 并产生下一个 token。单步计算较小但反复执行，数据搬运与内存带宽经常成为瓶颈。输出越长，decode 步数越多。

KV cache 保存每层、每个历史位置、每个 KV head 的 key 与 value。它降低重复计算，却随 batch、context、层数、head 维度和字节精度增长。多用户长上下文服务常先受 cache 内存约束。

常用指标回答不同问题：

• TTFT：请求到首 token，主要受排队、tokenization 和 prefill 影响。
• TPOT / inter-token latency：后续 token 间隔，聚焦 decode。
• E2E latency：完整回答完成时间，受输出长度强烈影响。
• Throughput：系统单位时间处理的 tokens/requests，可能以牺牲单请求延迟换取。

机制/推导

无 cache 时，第 t 步会重新计算长度 t 的整个前缀；有 cache 时，只为新 token 计算 Q/K/V，并让新 Q 与已缓存 K 做注意力。这样避免重复生成旧位置的 K/V。注意力读取历史仍随 t 增长，因此 cache 不是把 decode 变成常数成本。

KV cache 粗略字节数可写为：

2 × layers × batch × sequence × kv_heads × head_dim × bytes_per_element

前面的 2 表示 K 和 V。不同架构使用 MHA、GQA 或 MQA，kv_heads 不同；实际还包括内存对齐和运行时开销。

Batching 在 prefill 可提高设备利用率，在 decode 则要协调不同到达时间和长度。continuous batching 动态加入/移出序列，提高总体吞吐，却可能增加排队或尾延迟。

最小练习或观察步骤

1. 画一个 4-token prompt 生成 3-token 回答的时间轴，标出 prefill 与三个 decode step。
2. 在每层画出新 token 的 Q，以及历史 K/V 从 cache 被读取的位置。
3. 选一个玩具配置，手算 KV cache 粗略容量；明确假设的层数、KV heads、精度与序列长度。
4. 为短问答、长文档摘要、批量离线抽取分别选主要指标。
5. 写出增加输入长度、输出长度和 batch 时，TTFT、TPOT、内存可能如何变化；标为假设而非结果。
6. 将一次请求的质量、速度与资源指标分开记录。

常见误区

• 把 TTFT 与完整生成延迟混为一个数。
• 认为 KV cache 消除了 attention 对上下文长度的全部成本。
• 只报告 tokens/s，不说明是输入、输出还是总 token。
• batch 越大越好，忽略单请求排队和尾延迟。
• 模型权重能放入内存，就认为长上下文并发也一定能运行。

金融 / Web3 / 文档场景连接

实时风控辅助更在意 TTFT 与尾延迟；批量合同抽取更在意总吞吐；长监管文档问答会显著消耗 prefill 与 KV cache。服务设计应从工作负载出发，而不是用单一“每秒 token”排名所有后端。

自检问题

1. prefill 与 decode 的主要工作有什么不同？
2. KV cache 节省了什么，又增加了什么？
3. 输入变长和输出变长分别主要影响哪些指标？
4. 为什么吞吐优化可能损害交互延迟？

专业课程对齐

• 精读 vLLM PagedAttention 设计文档 中 key/value cache 块布局、query-key dot product 与 value reduction 的 kernel 路径。
• 精读 Stanford CS336 的 Transformer inference、systems 与 scaling 课题，将 prefill/decode 的计算密度和内存带宽差异放回整体系统。
• 选读 Hugging Face LLM Course 的 generation 相关章节，只用来识别 tokenizer、generation config 与 stopping criteria 边界。

深入学习提示

先画 tokenization→prefill→cache→decode→stop，再读 vLLM kernel，最后用 CS336 连到服务指标。手算 KV bytes：2×layers×batch×sequence×kv_heads×head_dim×bytes，并观察 MHA/GQA 的 kv_heads 差异。代码路径上分清 prefill 一次写入多个 cache slot 与 decode 每次追加一个 slot；指标要拆 TTFT、TPOT、E2E latency、tokens/s 与队列时间。反例是开启 cache 后只看总耗时，未分离输入/输出长度，或宣称 cache 使 decode 成为常数成本。

学后填写区

• 我的推理数据流图：
• KV cache 手算假设与结果：
• 一个目标工作负载：
• 对它最重要的两个指标：
• 尚不确定的瓶颈：