KV 缓存

KV Cache是Transformer架构的核心推理优化机制，其显存占用量会随序列长度和并发批次线性增长

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

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

KV缓存将已计算的Key-Value矩阵存储在显存中实现增量计算，代价是显存占用随序列长度线性增长

KV缓存的大小随上下文长度线性增长，处理更长文本时显存消耗会显著增加

该模型窗口承诺支持约百万级 token，但底层 KV 池实际只能容纳 681,280 个 token。

事故根源在于推理引擎对共享 KV 缓存内存页的管理方式，而非模型本身或开发方 z.ai。

FP4 精度损失对 KV 缓存这类对长程依赖敏感的数据更为苛刻，通常需要配合逐通道或逐 token 缩放策略，以及可能的敏感层保留高精度做法。

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

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

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

KV cache 占用的显存随上下文长度和对话轮次增长，是长上下文部署中显存与延迟的主要来源。

模型权重只是显存占用的一部分，推理过程中还需要为激活值、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 计算。