KV 缓存

Transformer 模型在生成每个 token 时，需要计算所有先前 token 的键（Key）和值（Value）向量，这些张量合称 KV 缓存。

KV Cache机制中，复用已缓存的KV值为命中，上下文变化导致缓存失效需重新计算为未命中

据 DeepSeek 数据，所有输入 token 中有 96% 命中缓存。

大多数公司只把提示缓存保留五分钟，而 DeepSeek 将缓存时间拉长到数天：面向 agent 流量保留三天，面向聊天保留七天。

TTFT（首 Token 等待时间）主要由预填充阶段决定，计算量与上下文长度近似成正比；前缀缓存（prefix caching）可复用已算好的 KV 状态，仅对新增部分做预填充。

模型权重只是显存占用的一部分，推理过程中还需要为激活值、KV 缓存、上下文窗口等预留空间。

同一个 Q8_0 文件运行两次，第二次使用 q8_0 的 K/V 缓存，KL 为 0.0038，比将权重从 BF16 量化为 Q8_0（KL 0.0022）的影响还大。

由于专家剪枝保留了注意力架构和 KV 缓存格式，KV 缓存交接不需要任何缓存转换，运行时只需在两个阶段之间切换权重掩码。

对于多轮对话或长文档问答，如果每次请求都重新计算整个上下文的 KV，算力开销会随上下文长度平方级增长。

提示词的组织顺序会直接影响缓存命中率，进而影响实际账单。

实际 token 生成速度通常只能达到理论值的 50%–70%，受计算单元调度、KV 缓存读写、量化反量化开销等因素影响。

Prefill 阶段处理完整输入上下文，为所有输入 token 计算注意力并生成 KV 缓存，属于计算密集型操作，耗时与输入长度强相关。

vLLM 实现了 decode 节点将已计算的 KV 块回传给 prefill 节点的双向 KV 传输机制，消除了多轮对话中公共前缀的重复 prefill 计算。

在 Agent 会话中，多轮调用共享同一份上下文前缀，理论上存在大量可复用的 KV 缓存块。