01 · 输入处理和逐步生成
提示词的所有 token 已知,Prefill 可以同时组织多个位置的前向,建立各层 KV,并得到生成首个输出 token 所需的结果。之后普通自回归 Decode 把刚选出的 token 送回模型,每轮产生下一个 token。
一个请求的下一轮依赖上一轮的结果;不同请求之间可以并行。第一个输出 token 通常由 Prefill 的结果选出,不需要先做一轮相同输入的 Decode。
02 · KV Cache 保存什么
对每层、每个已处理位置,保存该位置的 K 和 V。后续新查询读取这些历史 K/V,避免重新执行旧位置的整段前向。它不保存完整 N×N 的概率矩阵,也不能直接复用为上一轮的最终答案。
长度增长时 KV 通常也增长;GQA 的 KV 头数、精度、层数和每头维度影响每 token 大小。缓存兼容性还与模型、适配器、位置处理等条件有关。
依据:Transformers · How Caching Works ↗ · TensorRT-LLM · KV Cache System ↗
03 · 请求数不等于本轮 token 数
三个 Decode 请求通常每个本轮各处理一个 token;一个 Prefill 请求可能带来几千个 token。Batch 是本轮一起执行的工作集合,token budget 是调度器允许处理的 token 总预算。仅限制请求数不足以控制实际工作量。
| 工作 | 教学数量 |
|---|---|
| 3 个普通 Decode 请求 | 约 3 个查询 token,读取各自历史 KV。 |
| 1 个 2048 token Prefill | 2048 个查询位置,可分块安排。 |
| 连续批处理 | 每轮根据请求状态重新决定谁进入或离开。 |
04 · 用户看到的时间
TTFT 是请求到首个输出 token 的时间,可能包含排队、预处理和 Prefill。TPOT 是后续每个输出 token 的平均时间,ITL 更直接观察相邻输出的间隔。吞吐是整个服务每单位时间完成的请求或 token 数。
大批次可能提高服务吞吐,同时增加单请求输出间隔。因此容量、吞吐、延迟和质量需要一起比较。