# 百万 token 的成本账

> 长上下文的账从“算力与显存”两笔变成了三笔：预填充的计算、常驻 HBM 的全局 KV、落到 SSD 的持久化 KV。先把账算清，再看 V4.1 在哪几个因子上动了刀。

- 作者：David（道雾轩）
- 专栏：DeepSeek V4.1 Flash 深度解析（https://daiw.net/manual/deepseek-v4-flash.md）
- 最后更新：2026-09-19
- 原文：https://daiw.net/manual/deepseek-v4-flash/million-token-cost
- 转载与引用：请注明出处并附原文链接（https://daiw.net/about/copyright）

V4 时代，长上下文的账主要是两笔：每一步要算多少、缓存要占多少显存。V4.1 的技术报告把问题重新表述了一遍：长时程 Agent 普及之后，模型负载越来越“输入重”；稀疏注意力已经把长序列的计算压下去不少，但**预填充仍然昂贵，庞大的 KV 缓存继续挤占 HBM 与 SSD 的容量和传输带宽**，这三样合起来成了进一步降低部署成本的主要瓶颈 [1]。

这一章先把这三笔账摆清楚，后面几章讲的每个机制都能在这里找到位置。

## 三笔账

| 账目 | 随上下文长度 $L$ 怎么涨 | 卡在哪 | V4.1 的对策 |
| --- | --- | --- | --- |
| **预填充计算** | 每个没命中缓存的输入 token 都要过一遍网络 | 算力 | [CED](https://daiw.net/manual/deepseek-v4-flash/ced)：大部分输入 token 只走前 20 层 |
| **运行时全局 KV**（常驻 HBM） | $O(L)$ | 显存容量、解码时的读带宽 | [CSA2](https://daiw.net/manual/deepseek-v4-flash/csa2)：跨层共享，加上 FP4 存储 |
| **持久化 KV**（SSD 或主机内存） | $O(L)$，按会话累积，要保留几十小时 | 存储容量、加载带宽 | [SWA 有界重放](https://daiw.net/manual/deepseek-v4-flash/swa-bounded-replay)：滑动窗口缓存不再落盘 |

第三笔是 V4.1 报告里新提到台前的。DeepSeek 的服务会把算过的前缀 KV 存起来，下次同一前缀的请求直接复用，这就是 API 里“缓存命中”价格的来历。Agent 每调用一次工具，就把越来越长的上下文重新发一遍，命中率越高越省钱，而命中的前提是缓存得存得下、取得快 [1]。

## 解码时每步要读多少

生成第 $L+1$ 个 token 时，注意力要拿当前 query 去和前面的 key 做内积，再对 value 加权求和。不做稀疏的话：

> **每生成一个 token，都要把整个 KV 缓存从显存里读一遍。**

长上下文解码慢的主要原因不在算力，而在**内存带宽**：内积本身很便宜，但缓存哪怕压到几十 GB，每步完整读一遍也会把带宽吃满。所以长上下文推理的性能画像是：

- **预填充阶段**：算力受限，输入越长，要算的越多。
- **解码阶段**：带宽受限，每步要读的缓存越多越慢。

缓存变小能同时缓解两件事：显存省了，每步要读的字节也少了。V4.1 报告给出的结果是，把上下文从 4K 拉长 256 倍到 1M，单 token 解码 FLOPs 只增加约 1/4，远小于 V4-Flash 的增幅（这张图按 BF16、FP8、FP4 运算分别计 1、0.5、0.25 的权重折算）[1]。

## 缓存大小的四个因子

一份全局 KV 缓存的大小，粗略是四项相乘：

> **缓存 ≈ 序列长度 × 存缓存的层数 × 每条目的维度 × 每个数的字节数**

V4.1 报告把前三项称为三个“相乘的维度”：条目大小（GQA 减少 KV 头、MLA 共享一个小的潜向量）、序列维（每 $m$ 个 token 压成一条，比如 V4 的 CSA 与 HCA）、层维（一些层复用别的层的缓存和选择结果）[1]。再加上精度，就是四条路线（条目维度那一条的来龙去脉见《AI 大模型解构》[5]）：

| 因子 | 代表做法 | V4-Flash | **V4.1-Flash** |
| --- | --- | --- | --- |
| 每条目的维度 | MQA、GQA、MLA | 单个 512 维、所有查询头共享的 KV | 同左 |
| 序列长度 | 把 $m$ 个 token 压成一条 | CSA 压 4 倍、HCA 压 128 倍 | 编码器压 2 倍，解码器不压 |
| 存缓存的层数 | 跨层复用 | 41 层各存一份 | **只有 4 层产生全局 KV** |
| 每个数的字节数 | 降精度 | 主 KV 用 FP8（RoPE 部分 BF16） | **主 KV 用 FP4** |

这张表里藏着一个反直觉的地方：**V4.1 在序列维上反而压得更轻了**（2 倍和 1 倍，前代是 4 倍和 128 倍），省下来的部分几乎全部来自层数和字节数。本专栏初版在回顾里猜过“压缩路线的下一步是压得更狠”，V4.1 走的是另一个方向。

<Callout type="info">
  为什么序列维不再往狠里压？报告没有正面解释。它给出的视角是：V4 可以看成“以滑动窗口处理局部、再用压缩的全局上下文做补充”的结构，所以 V4.1 把力气花在**简化全局分支**上，同时基本保留局部注意力的设计 [1]。压序列损失的是“哪些 token 还记得”，压层数与精度损失的是“每条缓存记得多细”——两类风险的性质不同，这一点在[前代那几章](https://daiw.net/manual/deepseek-v4-flash/csa)里还会看到。
</Callout>

## 四代的账

模型卡里有一张各代 DeepSeek 模型每 token 全局 KV 缓存的对比图 [2]：

| 模型 | 发布 | 每 token 全局 KV | 相比上一行 | 100 万 token 约合 |
| --- | --- | --- | --- | --- |
| DeepSeek-V1 | 2023-11 | 389,120 字节 | — | 389 GB |
| DeepSeek-V3.2 | 2025-12 | 48,068 字节 | 缩小 8.1 倍 | 48 GB |
| DeepSeek-V4-Flash | 2026-04 | 3,514 字节 | 缩小 13.7 倍 | 3.5 GB |
| **DeepSeek-V4.1-Flash** | 2026-09 | **890 字节** | 缩小 3.9 倍 | **0.89 GB** |

最后一列是本专栏按字节数乘 100 万粗算的。从 V1 到 V4.1，每 token 的全局缓存缩小了约 437 倍，这也是官方公告里的说法 [3]。

## V4 那两个百分比，属于 V4-Pro

本专栏初版在这里写过“V4 在百万 token 场景下只需要 V3.2 约 27% 的单 token 推理 FLOPs 和约 10% 的 KV 缓存”，并把它当成 V4-Flash 的数字。**这是误读**：V4 论文写的是 V4-Pro 为 27% 与 10%，**V4-Flash 更低，为 10% 与 7%** [4]。上表里 3,514 ÷ 48,068 ≈ 7.3%，和 7% 对得上。

<Callout type="warn">
  上面所有比例都来自 DeepSeek 自己的报告与模型卡，属于**官方口径**，对比对象和测算方法由厂商选定。另外两点要记住：一是这些是**每 token 的全局 KV**，不含每层固定 128 个 token 的滑动窗口缓存；二是“持久化缓存只剩 1/8”依赖于部署策略（滑动窗口缓存不再落盘），不是模型本身的属性，[有界重放那一章](https://daiw.net/manual/deepseek-v4-flash/swa-bounded-replay)会讲它的代价。
</Callout>

下一章拆第一个新机制：怎么让输入 token 少走一半的层。👉 [CED：输入 8B、输出 16B](https://daiw.net/manual/deepseek-v4-flash/ced)

## 参考文献

- [1] DeepSeek-AI. “DeepSeek-V4.1-Flash: Pushing the Limits of KV Cache Compression.” 2026-09. [arXiv:2609.19969](https://arxiv.org/abs/2609.19969) —— 摘要与第 1 节的问题陈述、第 2.3 节“三个相乘的维度”、图 2 的解码 FLOPs 曲线及其精度折算方法。
- [2] Hugging Face 模型卡：[deepseek-ai/DeepSeek-V4.1-Flash](https://huggingface.co/deepseek-ai/DeepSeek-V4.1-Flash) —— 各代每 token 全局 KV 缓存对比图的四个数字。
- [3] DeepSeek. “DeepSeek-V4.1-Flash 发布.” 2026-09-10. [api-docs.deepseek.com/zh-cn/news/news260910](https://api-docs.deepseek.com/zh-cn/news/news260910) —— “相对于初代模型，KV Cache 已经缩小了 437 倍”。
- [4] DeepSeek-AI. “DeepSeek-V4: Towards Highly Efficient Million-Token Context Intelligence.” 2026-04. [arXiv:2606.19348](https://arxiv.org/abs/2606.19348) —— V4-Pro 与 V4-Flash 各自相对 V3.2 的 FLOPs 与 KV 缓存比例、V4 的 KV 存储格式。
- [5] 本站《AI 大模型解构》[注意力：从 MHA 到 MQA、GQA、MLA](https://daiw.net/manual/llm-anatomy/attention-mha-gqa-mla) —— 条目维度这条压缩路线的完整梳理。
