890 字节一个 Token：读懂 DeepSeek 的 KV Cache 压缩

当 模型 处理 长 文档 时，它 要 为 上下文 中 的 每个 Token 保存 注意力 的 Key 和 Value，这 份 中间 结果 就是 KV Cache。它 随 上下文 长度 线性 增长，决定 了 一张 卡 上 能 同时 跑 多少 个 长 会话。这也 是 为什么 长 上下文 的 成本，往往 卡 在 记忆 而 不是 权重 上。

KV Cache 有 多 占 地方，可以 用 公开 模型 算 一笔 账。按 Qwen3-8B 的 公开 配置，在 BF16 或 FP16、每个 数值 占 2 字节 的 条件 下，每个 Token 对应 的 KV 数据 是 147456 字节，约 147KB。计算 方式 是 2 份 K/V 乘 36 层 乘 8 个 KV 头 乘 每头 128 维 乘 2 字节。这 还 没有 计入 缓存 管理 等 额外 开销。

DeepSeek 在 V4.1 Flash 上 做 的 是 压缩。官方 给 出 的 对比 是：相比 上一代，模型 对 HBM 的 需求 减少 到 四分之一，对 SSD 的 需求 减少 到 八分之一；相对 初代 模型，KV Cache 已经 缩小 了 437 倍。综合 官方 与 多方 描述，V4.1 Flash 每个 Token 的 KV Cache 约 890 字节。

为什么 要 盯 着 这 个 数字？因为 缓存 命中 的 费用 在 Agent 类 任务 中 占比 很高。一次 编码 Agent 任务 会 反复 读 代码、查 资料、跑 测试，历史 越 积 越 多。显存 装 不 下 时，系统 会 清掉 部分 缓存，下 一轮 需要 时 又 得 重新 做 Prefill，用户 等 第一个 Token 的 时间 也 就 变长。

工程 上 的 出路 是 分层。正在 生成 的 数据 留在 HBM，短期 可能 复用 的 放进 CPU 侧 DDR 内存，更 久 没 访问 的 下沉 到 SSD 或 远端 存储。像 vLLM 的 KV Offloading 就 支持 把 缓存 块 卸载 到 CPU 内存，并 配置 次级 存储 层，取回 时 经过 CPU 侧 缓存 层。

所以，890 字节 不 只是 一个 数字。它 意味着 同样 的 显存 能 撑 起 更多 并发 长 会话，也 意味着 自建 推理 服务 的 团队 少 买 一些 卡。对 采购 与 运维 来说，KV Cache 的 大小 已经 和 模型 的 效果 一样，值得 写进 选型 清单。