百万 token 的成本账
长上下文的账从“算力与显存”两笔变成了三笔：预填充的计算、常驻 HBM 的全局 KV、落到 SSD 的持久化 KV。先把账算清，再看 V4.1 在哪几个因子上动了刀。
V4 时代，长上下文的账主要是两笔：每一步要算多少、缓存要占多少显存。V4.1 的技术报告把问题重新表述了一遍：长时程 Agent 普及之后，模型负载越来越“输入重”；稀疏注意力已经把长序列的计算压下去不少，但预填充仍然昂贵，庞大的 KV 缓存继续挤占 HBM 与 SSD 的容量和传输带宽，这三样合起来成了进一步降低部署成本的主要瓶颈 [1]。
这一章先把这三笔账摆清楚，后面几章讲的每个机制都能在这里找到位置。
三笔账
| 账目 | 随上下文长度 怎么涨 | 卡在哪 | V4.1 的对策 |
|---|---|---|---|
| 预填充计算 | 每个没命中缓存的输入 token 都要过一遍网络 | 算力 | CED：大部分输入 token 只走前 20 层 |
| 运行时全局 KV（常驻 HBM） | 显存容量、解码时的读带宽 | CSA2：跨层共享，加上 FP4 存储 | |
| 持久化 KV（SSD 或主机内存） | ，按会话累积，要保留几十小时 | 存储容量、加载带宽 | SWA 有界重放：滑动窗口缓存不再落盘 |
第三笔是 V4.1 报告里新提到台前的。DeepSeek 的服务会把算过的前缀 KV 存起来，下次同一前缀的请求直接复用，这就是 API 里“缓存命中”价格的来历。Agent 每调用一次工具，就把越来越长的上下文重新发一遍，命中率越高越省钱，而命中的前提是缓存得存得下、取得快 [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 共享一个小的潜向量）、序列维（每 个 token 压成一条，比如 V4 的 CSA 与 HCA）、层维（一些层复用别的层的缓存和选择结果）[1]。再加上精度，就是四条路线（条目维度那一条的来龙去脉见《AI 大模型解构》[5]）：
| 因子 | 代表做法 | V4-Flash | V4.1-Flash |
|---|---|---|---|
| 每条目的维度 | MQA、GQA、MLA | 单个 512 维、所有查询头共享的 KV | 同左 |
| 序列长度 | 把 个 token 压成一条 | CSA 压 4 倍、HCA 压 128 倍 | 编码器压 2 倍，解码器不压 |
| 存缓存的层数 | 跨层复用 | 41 层各存一份 | 只有 4 层产生全局 KV |
| 每个数的字节数 | 降精度 | 主 KV 用 FP8（RoPE 部分 BF16） | 主 KV 用 FP4 |
这张表里藏着一个反直觉的地方：V4.1 在序列维上反而压得更轻了（2 倍和 1 倍，前代是 4 倍和 128 倍），省下来的部分几乎全部来自层数和字节数。本专栏初版在回顾里猜过“压缩路线的下一步是压得更狠”，V4.1 走的是另一个方向。
为什么序列维不再往狠里压？报告没有正面解释。它给出的视角是：V4 可以看成“以滑动窗口处理局部、再用压缩的全局上下文做补充”的结构，所以 V4.1 把力气花在简化全局分支上，同时基本保留局部注意力的设计 [1]。压序列损失的是“哪些 token 还记得”，压层数与精度损失的是“每条缓存记得多细”——两类风险的性质不同，这一点在前代那几章里还会看到。
四代的账
模型卡里有一张各代 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% 对得上。
上面所有比例都来自 DeepSeek 自己的报告与模型卡，属于官方口径，对比对象和测算方法由厂商选定。另外两点要记住：一是这些是每 token 的全局 KV，不含每层固定 128 个 token 的滑动窗口缓存；二是“持久化缓存只剩 1/8”依赖于部署策略（滑动窗口缓存不再落盘），不是模型本身的属性，有界重放那一章会讲它的代价。
下一章拆第一个新机制：怎么让输入 token 少走一半的层。👉 CED：输入 8B、输出 16B
参考文献
- [1] DeepSeek-AI. “DeepSeek-V4.1-Flash: Pushing the Limits of KV Cache Compression.” 2026-09. arXiv:2609.19969 —— 摘要与第 1 节的问题陈述、第 2.3 节“三个相乘的维度”、图 2 的解码 FLOPs 曲线及其精度折算方法。
- [2] Hugging Face 模型卡：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 —— “相对于初代模型，KV Cache 已经缩小了 437 倍”。
- [4] DeepSeek-AI. “DeepSeek-V4: Towards Highly Efficient Million-Token Context Intelligence.” 2026-04. arXiv:2606.19348 —— V4-Pro 与 V4-Flash 各自相对 V3.2 的 FLOPs 与 KV 缓存比例、V4 的 KV 存储格式。
- [5] 本站《AI 大模型解构》注意力：从 MHA 到 MQA、GQA、MLA —— 条目维度这条压缩路线的完整梳理。