KV Cache 调度工程：当压缩到 7% 之后

KV Cache 冷热调度：当 V4 把缓存压到 7%，调度问题怎么变

推理经济学三部曲 · DeepSeek V4 Flash 输出 2 元/百万 token，Claude Sonnet 5 输出 107 元。53 倍差距不是补贴——是物理。本系列从定价倒推到架构选择到工程调度，拆解一个 Token 的物理成本到底由什么决定。

整理日期：2026-08-08 定位：LLM 记忆架构演进系列的工程深化篇 依赖：memory/llm-memory-architecture-evolution.md + 推理定价物理底线分析 锚定模型：DeepSeek V4 Flash / V4 Pro（CSA+HCA 混合注意力，2026-04 技术报告）

引言：一张表看清 V4 改变了什么

在 V3 时代，KV cache 管理的核心矛盾是"装不下"——671B 参数的 MoE 模型已经吃掉大部分 HBM，剩下的空间要精打细算。V4 的 CSA+HCA 混合注意力把 KV cache 压到了 V3.2 的 7%（Flash）到 10%（Pro），这个数量级的改变让调度问题的性质发生了根本转变。

先看参数表：

一个直观的数字：在 V4 Flash 上跑 100 个并发请求、每个平均 3,200 tokens 上下文，全部 KV cache 加起来 仅 2 MB。这不是打字错误——2 MB，连 HBM 的零头都占不到。

这意味着 KV cache 冷热调度的重心从"装不下"变成了"搬得快"。问题没有消失，但变形了。

一、问题重新定义

KV cache 管理不是简单的"装不下就卸载"。它是一个有多约束的在线调度问题。但在 V4 时代，约束条件已经与 V3 时代截然不同。

三个同时发生的物理过程：

1. Decode 步：每生成一个 token，需要读全部 KV cache（attention 计算）+ 读激活权重
2. KV 增长：每生成一个 token，KV cache 增加若干字节——但在 V4 Flash 上，每 token 仅 ~6.3 bytes，4K 上下文总共 ~25 KB
3. 请求生命周期：请求到达 → prefill（KV cache 一次性生成）→ decode（KV cache 逐步增长）→ 完成（KV cache 可丢弃或缓存复用）

V4 时代的调度约束（与 V3 对比）：

核心问题已经变形： 给定 N 个并发请求，V4 上 KV cache 容量不再是约束。真正的问题是：① 如何通过 prefix 共享最大化减少 prefill 重复计算（因为 KV cache 小到几乎免费，但 prefill 的计算成本没有降低）；② CSA 层的稀疏选择模式如何影响 KV cache 的读取（大部分 KV cache 在 attention 计算时根本不被读取）；③ PD 分离架构下，KV cache 在 GPU 间通过 PCIe 传输时如何调度。

二、什么决定冷热？Attention 的访问模式

这一节的原理在 V3 和 V4 上都成立——attention 访问模式决定冷热，与模型架构无关。但 V4 的 CSA+HCA 架构在硬件层面就做了冷热分级，这是本质区别（详见第六章）。

CPU cache 的冷热由时间和空间局部性决定。KV cache 的冷热由 attention 访问模式 决定——这是本质区别。

发现一：Attention Sink

Liu et al. (2023) 发现 transformer 的注意力有"锚点效应"：前几个 token 和最后几个 token 接收到的注意力分数异常高，无论后面的 query 是什么。

这意味着 KV cache 中存在天然的热点：

• 前 ~64 token（attention sink）：几乎所有后续 query 都会 attend 到 → 永远热
• 最近窗口（如最后 128 token）：recency bias，高概率被 attend → 热
• 中间段：大部分情况下 attention 分散且稀疏 → 冷候选

工程含义：KV cache 的中间段是卸载的安全区。只要保留 sink token 和 recent window，attention 计算的精度损失通常可接受。

发现二：Prefix 共享

生产环境中大量请求共享前缀：

• System prompt（所有请求共享，几千 token）
• Few-shot examples（同一应用的请求共享）
• 文档/代码上下文（同一 session 的多轮对话）

DeepSeek 的实测数据（DualPath 论文披露）：在 API 服务中，约 30-40% 的 prefill 计算可以通过 prefix 复用消除。而在 Agent 多轮场景下，这个比例可达 98.7%。

这意味着：共享前缀的 KV cache 是最高价值的热数据——一次计算，多次复用。在 V4 上，虽然 KV cache 本身极小，但 prefill 计算的 FLOP 消耗并没有减少（13B 激活参数 × 2 × prefix_length）。Prefix 共享的价值因此 相对上升。

发现三：语义重要性波动

并非所有中间 token 都冷。某些 token 在特定 query 下变得重要：

• 实体名称、数字、关键词
• 结构化数据中的字段标签
• 代码中的函数签名

但语义重要性是 query-dependent 的——无法预先确定哪些 token 会变热。这是与 CPU cache 的根本差异：热度的决定因素不是历史访问模式，而是未来的 query 内容。

冷热分级模型（V4 视角）

综合三个发现，KV cache 的热度可以这样建模：

在 V4 Flash 上，4K 上下文的全部 KV cache 仅 ~25 KB。即使 P3 冷段占 60%，也才 ~15 KB——卸载它到 DRAM 节省的空间不值得 page-in 的延迟开销。V4 时代，冷热分级的意义从"节省空间"变成了"减少带宽争抢"和"指导 prefix 复用"。

三、现有系统的设计空间

vLLM PagedAttention：虚拟内存模型

核心设计：借鉴 OS 虚拟内存，把 KV cache 切成固定大小的 block（通常 16 token/block），用 block table 管理逻辑→物理映射。

• 优点：消除碎片化，block 级别分配/回收，支持非连续物理存储
• 冷热处理：P0/P1 在 HBM，P3 可以被 evict——但原始 PagedAttention 没有 DRAM/SSD 层级，evict 就是丢弃
• Prefix 共享：通过 RadixAttention 扩展实现（后来 SGLang 的贡献）
• 局限：block 粒度固定（16 token），对于 attention sink 这类只有几个 token 的热点有内部碎片
• V4 适配：V4 Flash 下一个 16-token block 仅 ~101 bytes，PagedAttention 的 block table 元数据可能比数据本身还大。需要增大 block 大小到 256-512 token，或改为基于 CSA block 的对齐

SGLang RadixAttention：前缀树复用

核心设计：把所有活跃请求的 KV cache 按前缀组织成 Radix Tree。相同前缀的请求共享同一组 KV block。

• 优点：自动发现 prefix 共享，无需手动标注 system prompt
• 冷热处理：前缀树节点按引用计数管理。引用计数高的节点留 HBM，低的可以降级
• 局限：前缀匹配是精确匹配——"几乎相同但不完全一样"的前缀无法复用
• V4 适配：在 V4 上，RadixAttention 的价值不在于节省 HBM 空间（KV cache 已经极小），而在于 节省 prefill 计算。每个共享前缀节点意味着一组请求不需要重新跑 prefill

DeepSeek 的实践：三级存储 + 前缀缓存（V4 生产环境）

DeepSeek V4 的生产环境已经在运行完整的三级存储架构。DualPath 论文（2026-02）确认了这一设计在 660B 生产模型上的运行状态。

层级架构：

HBM（80GB）    ← 活跃请求的 KV cache + P0/P1 热点（V4 Flash 上 KV 仅占 ~2 MB）
  ↕ PCIe Gen5（64 GB/s）
DRAM（1-2TB）  ← Prefix 缓存池 + 跨请求 KV 复用
  ↕ NVMe Gen5（7-14 GB/s）
SSD（4-8TB）   ← 跨会话持久缓存 + Agent 长链路历史

V4 时代的设计变化：

1. HBM 层的角色改变：在 V3 时代，HBM 是稀缺资源，KV cache 和权重争夺同一块空间。V4 Flash 的 KV cache 仅 ~2 MB，HBM 的 KV 预算几乎无限——三级存储的第一级就够用了
2. DRAM/SSD 层的新角色：不再是"KV cache 溢出区"，而是"prefix 复用池"。价值不在于节省 HBM，而在于减少 prefill 计算
3. PD 分离架构：Prefill 节点（P 节点）和 Decode 节点（D 节点）分离，KV cache 需要通过网络从 P 传到 D。V4 的极小 KV cache 让这个传输几乎免费——6.3 bytes/token × 3200 tokens = 20 KB/请求，100 个请求仅 2 MB，PCIe 64 GB/s 下 0.03ms 传完
4. 异步 page-in 仍然存在，但主要原因从"HBM 放不下"变成了"PD 分离时 KV cache 需要跨节点传输"

四、调度策略设计

问题形式化

每步 decode 时的调度决策：

输入：

• 当前 HBM 剩余空间 S_hbm（V4 Flash 上通常不是约束）
• 所有活跃请求的 KV cache 状态（位于哪一级）
• 每个请求的 attention 模式历史（CSA 层的稀疏选择记录）
• Prefix tree 状态（哪些前缀被多少请求共享）

输出：

• 本步需要 page-in 到 HBM 的 block 列表（V4 上主要发生在 PD 分离架构中）
• 本步需要从 HBM evict 到 DRAM 的 block 列表（V4 上极少发生）
• Prefix cache 的更新策略

目标（V4 时代的优先级重排）：

1. 最大化 prefix cache 命中率（减少 prefill 计算——头等大事）
2. 最小化 PD 分离时的 KV cache 传输延迟（跨节点带宽争抢）
3. 最小化 decode 延迟（CSA 层的稀疏 KV 读取模式优化）
4. 最小化 HBM 占用（已不再是约束）

策略一：分层 LRU + Attention Sink 豁免

最基础的策略。每级维护一个 LRU 队列，但 P0（attention sink）永远不 evict。

• HBM 队列：P0（永久）→ P1（recent window 随 decode 滑动）→ P2（按 LRU）
• DRAM 队列：从 HBM evict 来的 P2/P3，按 LRU
• SSD 队列：从 DRAM evict 来的，按引用计数（prefix 复用价值）

V4 适配：在 V4 Flash 上，LRU 的角色大幅缩减。HBM 有 ~67 GB 可用空间（扣除 13B 激活权重的 ~13 GB），而全部 KV cache 仅 ~2 MB。LRU 队列永远不满——evict 永远不触发。这个策略退化成"所有 KV 都在 HBM"。

优点：简单，可预测，overhead 小。 缺点：LRU 假设"最近访问的将来还会访问"——对 KV cache 不完全成立。但在 V4 上这个缺点不重要，因为根本没有 evict 压力。

策略二：Attention Score 驱动的预取

利用 attention 计算本身的信息。

核心观察：每步 decode 时，attention score 已经告诉你哪些历史 token 被关注了。可以把 attention score 高的 block 标记为"热"，低的标记为"冷"。

V4 适配：在 V4 上，CSA 层在架构级就做了类似的事情——只保留 top-k 压缩 KV 条目。策略二在 V4 上的角色从"调度优化"变成了"CSA 选择策略的软件干预"——如果推理引擎能获取 CSA 的选择模式，可以更精准地预取。

优点：精确反映实际访问模式。 缺点：

• 额外计算 overhead（统计 + 决策）
• CSA 层的选择由模型权重决定，不是运行时 attention score——干预空间有限
• HCA 层的密集注意力不需要预取优化

策略三：Prefix Tree + 引用计数

专门针对 P2（共享前缀）的管理。这是 V4 时代投入产出比最高的策略。

设计：

1. 维护一棵 Radix Tree，每个节点代表一个 KV cache block 序列
2. 每个节点有引用计数 ref_count（多少活跃请求正在使用这个前缀）
3. ref_count > 0 的节点永远在 HBM（V4 上几乎所有节点都在 HBM，空间不是问题）
4. ref_count = 0 但有复用历史的节点放 DRAM（prefix cache）
5. DRAM 满时按"上次使用时间 + 历史命中率"综合评分 evict 到 SSD

关键优化——自适应前缀粒度：

• 前缀树的分支粒度不固定。对于 system prompt 这种高度共享的前缀，用粗粒度（几百 token 一个节点）减少管理 overhead
• 对于多轮对话中的上下文，用细粒度（几十 token）提高命中率

V4 上的核心价值：V4 Flash 的 prefill 计算量是 2 × 13B = 26 GFLOP/token。一个 1,500 token 的 system prompt 被复用 99 次，节省的 prefill FLOP 是 1,500 × 26 GFLOP × 99 = 3.86 PFLOP——相当于在 16 PFLOP/s 算力下节省 ~0.24s 的计算时间。而存储这些前缀的 KV cache 仅 1,500 × 6.3 bytes = 9.5 KB——存储成本可忽略，计算节省巨大。Prefix Tree 在 V4 上是纯粹的"算力节省器"。

策略四：Speculative Prefetch（推测性预取）

核心思想：不要等 decode 步发现需要某个 block 才去 page-in，提前预测。

信号源：

1. 请求的 prompt 结构：如果是多轮对话，下一轮大概率会 attend 到上一轮的回答 → 提前把上一轮 KV cache 从 DRAM 拉回 HBM
2. CSA 选择模式历史：CSA 的 top-k 选择有一定的模式稳定性，如果过去 N 步中某些 KV 条目被持续选中，提前预取
3. Batch 内相关性：同一 batch 中类似请求的 CSA 选择模式可以互相参考

实现：在 decode 的间隙（GPU 在做矩阵乘法时）异步执行 page-in。V4 Flash 下一个 16-token block 的 KV cache ≈ 101 bytes。PCIe Gen5 64 GB/s 可以在 0.001ms 内传输 101 bytes——完全隐藏在 decode 的 10-15ms 计算时间里。

量化：V4 Flash 的 block 太小，使得 Speculative Prefetch 的工程价值在 V4 上主要体现在 PD 分离架构——Prefill 节点算完 KV cache 后，需要把 KV 传给 Decode 节点。提前预测哪些请求会被路由到哪个 D 节点，提前传输，才能真正消除延迟。

五、策略对比基准：数据告诉我们什么

前四节描述的四种策略是设计空间的四个象限。但工程师真正需要回答的问题是：在 V4 时代，这些策略的相对价值如何变化？

5.1 公开数据点

三个来源的生产级或论文级数据：

DeepSeek DualPath（2026-02 论文，660B 生产模型，V4 生产环境验证）

• Workload：Agentic 多轮对话，平均 157 轮交互
• 平均上下文长度：32,700 tokens
• 每轮新增 token：仅 429（其余全部可复用）
• KV-Cache 命中率：98.7%（(32700−429)/32700）
• Cache-Compute Ratio：22 GB/PFLOP
• 双路径加载（Storage-to-Decode + Storage-to-Prefill）后，吞吐提升 1.87×/1.96×
• 核心瓶颈：不是算力，而是存储 I/O 带宽——PE 端 NIC 饱和，DE 端 NIC 空闲
• V4 适配解读：DualPath 的核心发现在 V4 上更加极端——KV cache 更小，但 prefill 计算节省的价值更高。瓶颈从"存储 I/O 带宽"进一步聚焦到"网络带宽"（PD 分离时）

SGLang RadixAttention 论文及生产实测（多种 workload）

• RadixAttention 相比无 prefix cache 的基线，缓存命中率提升 3-5×
• 分场景加速比（以 TTFT 衡量）：

vLLM PagedAttention 论文

• Block 级管理消除了内部/外部碎片，显存利用率从 ~60%（连续分配）提升到 ~95%+
• 但原始 PagedAttention 没有 DRAM/SSD 层级——evict 即丢弃，不涉及跨层调度
• Prefix cache 作为后续扩展加入（vLLM Automatic Prefix Caching），命中率取决于 workload 的前缀重复度
• V4 适配注释：PagedAttention 的 block 级管理在 V4 下面临粒度问题——16 token block 仅 ~101 bytes，block table 元数据 overhead 比例过高。需要重新设计 block 大小

5.2 四策略横向对比（V4 视角）

综合上述数据和工程推演，四种调度策略在 V4 时代的价值排序：

5.3 关键判断

数据揭示了三个 V4 时代的工程结论：

判断一：Prefix 共享的价值在 V4 上不降反升。 V3 时代 prefix 共享节省 HBM 空间 + 节省 prefill 计算，两个价值并存。V4 时代 HBM 空间不再紧张，但 prefill 计算的成本没有降低——每节省一次 prefill，等于节省 26 GFLOP/token（V4 Flash）。Prefix Tree 从"空间优化器"变成了"纯算力优化器"。

判断二：Attention Score 驱动的调度在 V4 上价值大幅缩水。 CSA 层在架构级已经做了"稀疏选择"——大部分 KV 条目在 attention 计算时根本不被读取。软件层的 attention score 统计在 CSA 之上能做的增量有限。唯一有价值的场景是分析 CSA 的选择模式，用于 PD 分离架构的预取决策。

判断三：Speculative Prefetch 的重心从"本地 page-in"转向"跨节点 KV 传输"。 V4 Flash 的 KV cache 太小（~2 MB），本地 HBM↔DRAM 的 page-in 毫无压力。但在 PD 分离架构下，P 节点完成 prefill 后需要把 KV 传给 D 节点——提前预测路由并预传，才是 V4 时代 Speculative Prefetch 的主战场。

组合策略推荐（V4 时代）： 以策略三（Prefix Tree）为核心——这是投入产出比最高的优化。策略一（LRU）退化为默认兜底，无需特别投入。策略二（Attention Score）仅在 CSA 选择模式分析有研究价值。策略四（Speculative Prefetch）在 PD 分离部署中是关键优化。DeepSeek 的 DualPath 框架本质上就是策略三 + 策略四的组合。

六、CSA+HCA 对调度策略的复合影响

V4 的 CSA（压缩稀疏注意力）和 HCA（分层分块注意力）不只是压缩 KV cache——它们在架构级重新定义了"冷热"的含义。

四代注意力机制的对比

标准 MHA 假设： 上表 ~320 KB 对应 ~100B 参数模型，96 层，64 头，128 head_dim，FP16。 | 4K 上下文每请求 | ~1.3 GB | ~121 MB | ~350 KB | ~25 KB | ~36 KB | | HBM 可容纳请求数（80GB 扣权重后） | 7-8 | 27-28 | ~1万 | ~130万 | ~90万 | | 16-token block 大小 | 5.1 KB | 496 bytes | 1.4 KB | 101 bytes | 144 bytes | | HBM→DRAM page-in 延迟/block | 0.08ms | 0.007ms | 0.02ms | 0.002ms | 0.002ms |

KV cache 缩小的阶梯： 标准 MHA → V3 MLA 是 ~10× 压缩（压缩 latent 维度）。V3 MLA → V3.2 优化是进一步 ~340× 压缩（推测是更激进的 latent 维度 + 共享机制）。V3.2 → V4 Flash 是再 ~14× 压缩（CSA 的稀疏选择 + HCA 的块级压缩）。从 MHA 到 V4 Flash，总压缩比达到 ~50,000×。

CSA 对调度的额外影响：架构级冷热分级

CSA 的核心机制是：在注意力计算前，用可学习的压缩网络对 KV 序列做 top-k 选择，只保留信息量高的 KV 条目参与 attention。这意味着：

大部分 KV cache 在 attention 计算时根本不被读取。 这不是"很少被读取"——是架构级的、确定性的跳过。CSA 层的 KV cache 天然分两级：

• 被选中的条目（热）：CSA 的 top-k 选择结果，当前步会被 attend
• 未被选中的条目（冷）：当前步不会被 attend，但未来 query 可能选中

这比 V3 时代依赖 LRU 或 attention score 做冷热分级 激进得多。V3 的 MLA 是所有 KV 都参与 attention，冷热分级是软件层的调度决策。V4 的 CSA 是架构级就决定了哪些 KV 被读取，软件层只需要决定"不被读取的 KV 放在哪"。

工程含义： 在 V4 Flash 上，CSA 层的冷 KV 条目可以激进卸载——但实际上无需卸载，因为全部 KV cache（含冷条目）仅 ~2 MB。架构级的冷热分级更多是 信息价值——调度器可以利用 CSA 的选择模式来优化 prefix cache 的淘汰策略：如果某些 KV 条目在过去 N 步中从未被 CSA 选中，它们的复用价值确实低，可以从 prefix tree 中降级。

HCA 对调度的影响：密集注意力层不可卸载

与 CSA 相反，HCA（分层分块注意力）做的是块内标准注意力——所有 KV 条目都会参与计算。这意味着：

• HCA 层的 KV cache 不能卸载：所有条目都可能被 attend，没有 CSA 那种架构级的跳过
• HCA 层的 KV cache 是 "全热" 的：无论 query 是什么，块内所有 token 都会被读到

CSA+HCA 混合架构因此创造了一种 天然的双层冷热结构：

这个双层结构是 V4 独有的。V3 的 MLA 所有层都是同构的，冷热分级完全依赖软件。V4 的 CSA+HCA 在硬件级给出了冷热标签，软件调度器只需要在此基础上做 prefix 复用和 PD 分离的优化。

工程权衡：block 大小的再思考

V4 Flash 的每 token KV cache 仅 ~6.3 bytes。如果沿用 V3 时代的 16-token block：

• 每 block 大小：16 × 6.3 = 101 bytes
• Block table 中每个条目（逻辑地址 + 物理地址 + 状态标记）：约 16-24 bytes
• 元数据占比：16-24%

这意味着接近 1/4 的 block 管理开销。V4 时代需要 大幅增大 block 大小：

建议 V4 Flash 使用 256-token block 作为默认值。元数据 overhead 降至 ~1.2%，同时保持足够的调度粒度。

七、工程化挑战

挑战一：PD 分离架构下的 KV cache 传输

V4 时代，KV cache 容量不再是瓶颈，但 Prefill-Decode 分离架构 引入了新的调度维度。

PD 分离的核心流程：

1. P 节点完成 prefill，生成 KV cache
2. KV cache 从 P 节点传输到 D 节点
3. D 节点开始 decode

V4 Flash 的传输成本：

• 每请求 KV cache：3,200 tokens × 6.3 bytes = 20.2 KB
• 100 并发请求：2.02 MB
• PCIe Gen5 64 GB/s：传输时间 0.03ms（可忽略）
• 万兆网络 10 GB/s：传输时间 0.2ms（仍然可忽略）

这比 V3 时代（100 并发 × 3,200 × 31 KB = 9.9 GB，PCIe 传输需 0.15s）改善了 5,000 倍。PD 分离架构在 V4 上几乎无延迟代价。

但真正的瓶颈是网络带宽争抢。 如果同时有 MoE 专家参数在 GPU 间传输，KV cache 的传输需要和专家加载竞争同一 PCIe/NVLink 带宽。V4 Flash 的 284B 总参数分布在 8 个 GPU 上，每步 decode 需要加载路由选中的专家——专家加载带宽可能是 KV cache 传输的 数千倍。

挑战二：Block 合并与压缩

请求完成后，它的 KV cache 可能被释放或降级。但如果另一个请求与它共享部分前缀，需要 拆分 block：共享部分保留，独有部分释放。

Radix Tree 天然支持这个——节点分裂/合并。V4 上的特殊之处是 block 太小（256-token block 仅 1.6 KB），合并/拆分操作的 overhead 相对较高。建议 V4 上的 Radix Tree 使用 更大的节点粒度（如 512-1024 token），减少操作频次。

挑战三：跨 GPU 的 KV cache 分布

多 GPU 张量并行时，KV cache 分散在不同 GPU 上。V4 Flash 的 CSA+HCA 层在不同 GPU 上的分布策略：

• CSA 层的 top-k 选择结果需要 allreduce 同步
• HCA 层的块内注意力在不同 GPU 上各算一部分
• 但 KV cache 太小（每 GPU 上可能只有 ~0.25 MB），跨 GPU 同步开销远大于数据传输

调度决策需要协调多个 GPU：

• 同一请求的 KV cache 应该在同一个 GPU 上（避免跨 GPU 读取）
• Prefix 共享的 block 只需在一个 GPU 上存一份
• V4 的新挑战：CSA 的 top-k 选择结果是模型权重决定的，不在运行时调度——调度器只能在 CSA 选择 "之下" 做 prefix 和 PD 优化

挑战四：精度损失

KV cache 从 HBM 卸载到 DRAM/SSD 本身不丢精度（位级精确）。V4 Flash 的 FP8 KV cache 已经是 8-bit 量化，进一步量化到 INT4 的收益有限：

• V4 Flash FP8：6.3 bytes/token（当前生产状态）
• 理论 INT4：3.15 bytes/token（精度损失 3-5%）
• 绝对节省：3.15 bytes/token × 3,200 × 100 = 1 MB

节省 1 MB HBM 不值得 3-5% 的精度损失。V4 时代，KV cache 量化基本没有必要——cache 已经太小了。分级量化策略（P0 FP8 / P3 INT4）的收益也不显著，因为 P3 段的全部 KV cache 可能只有 ~1 MB。

八、端到端案例：8×H100 跑 V4 Flash MoE

前面几节的定性分析需要一个"算完的案例"来检验。我们用一个具体的部署场景走一遍全流程。

8.1 场景设定

硬件：8×H100 80GB 服务器

• 总 HBM：640 GB
• 单卡带宽：3.35 TB/s
• 8 卡聚合算力（FP8）：~16 PFLOP/s
• PCIe Gen5：64 GB/s
• DRAM：1 TB
• NVMe SSD：8 TB

模型：DeepSeek V4 Flash MoE

• 总参数：284B
• 每 token 激活参数：13B
• 注意力机制：CSA+HCA 混合
• KV cache 每 token（FP8）：~6.3 bytes（V3.2 MLA 的 7%）
• 每 token 推理 FLOP：2 × 13B = 26 GFLOP
• 原生上下文长度：1M tokens

权重部署： 284B FP8 ≈ 284 GB，跨 8 张 H100 分布。每卡分担 ~35.5 GB 权重。激活参数 13B 分摊到 8 卡 ≈ 1.6 GB/卡（共享层 + 路由专家），但每步实际加载的激活专家权重更大。保守估计每卡活跃权重 ~13 GB（含 MoE 路由的 all-to-all 通信缓冲），剩余 ~67 GB/卡 可用于 KV cache 和其他缓冲。

KV cache 预算： 640 GB - 284 GB（权重）= 356 GB。但实际 KV cache 仅需 ~2 MB（见下文），HBM 空间完全不是约束。

8.2 Workload

共享前缀：

• System prompt：1,500 tokens（全部 100 个请求共享）
• Few-shot examples：500 tokens（每组 20 个请求共享，共 5 组）

8.3 策略 A：LRU + 无 Prefix 共享

每个请求独立计算全部 prefill。

Prefill 计算：

• 总 prefill token 数：20 × 8,000 + 80 × 2,000 = 320,000 tokens
• 每 token prefill FLOP：2 × 13B = 26 GFLOP
• 总 prefill FLOP：320,000 × 26 GFLOP = 8.32 PFLOP
• 在 16 PFLOP/s 的聚合算力下：8.32 / 16 = 0.52s（理论值）
• 实际因 MoE 专家加载 overhead（284B 总参数跨 GPU 分布，每步需加载路由专家），约 0.7-0.9s

KV cache 占用：

• 每 token FP8：6.3 bytes
• 每请求（平均 3,200 tokens）：3,200 × 6.3 = 20.2 KB
• 100 请求总计：100 × 20.2 KB = 2.02 MB

KV cache 仅占 356 GB 预算的 0.0006%。V4 Flash 的 KV cache 在 8×H100 上几乎不存在。瓶颈完全在 prefill 计算和 MoE 专家加载带宽。

有效 batch size： decode 阶段 100 个请求可全部并行，batch size = 100。事实上，由于 KV cache 几乎不占空间，batch size 的实际上限取决于 HBM 中能放多少激活权重的副本——理论上可以支持数千个并发请求。

8.4 策略 C：Prefix Tree + 引用计数

用 Radix Tree 管理共享前缀。

Prefix 复用节省的 prefill 计算：

• 实际需要 prefill 的 token：320,000 - 196,000 = 124,000 tokens
• Prefill FLOP：124,000 × 26 GFLOP = 3.22 PFLOP
• Prefill 时间：3.22 / 16 ≈ 0.20s（比策略 A 的 0.52s 缩短 61%）
• 实际含 MoE overhead：约 0.3-0.4s

TTFT（首 Token 延迟）对比：

• 策略 A 下，新请求需要等待全量 prefill 完成。2K 上下文的 TTFT ≈ 2,000 × 26 GFLOP / (16 PFLOP/s / 100) ≈ 3.25ms（100 路并行）。但实际因 batch 内争抢 MoE 专家加载带宽，TTFT 约 30-60ms。
• 策略 C 下，80% 的 system prompt + few-shot 可从缓存直接读取，实际 prefill 仅需计算用户独特部分（~500 tokens for short requests）。TTFT 降至 10-20ms，下降约 60-70%。

Prefix cache 的存储成本：

• System prompt KV cache：1,500 × 6.3 bytes = 9.5 KB
• 5 组 Few-shot KV cache：5 × 500 × 6.3 bytes = 15.8 KB
• 合计：25.3 KB
• 占用 HBM：可忽略

8.5 经济性：$/Mtoken

以 8×H100 服务器的小时租赁成本估算（云市场价约 $12/hr/GPU，8 卡 = $96/hr）：

Decode 成本（两种策略相同）：

• 13B 激活参数，每 token decode FLOP ≈ 2 × 13B = 26 GFLOP
• Batch size 100，每步生成 100 tokens
• 每步 decode 时间：26 GFLOP × 100 / 16 PFLOP/s = 0.16ms（理论值）
• 实际 decode 速度（含 MoE 专家加载、CSA 选择 overhead）：约 50-70 tokens/s/请求（注：篇一的 ~200 tok/s 是 decode-only 理论值；此处 50-70 是含 prefill 竞争 + MoE all-to-all + 实际调度的端到端值，3-4× 差距来自生产系统的非理想因素）
• 100 并发 × 60 tokens/s = 6,000 tokens/s 总吞吐
• 每小时生成：6,000 × 3,600 = 21.6M tokens
• Decode 成本：$96 / 21.6M = $4.4/Mtoken

Prefill 成本（策略差异主要在这里）：

综合 $/Mtoken：

• 策略 A：约 $6-7/Mtoken（prefill + decode 混合）
• 策略 C：约 $4.5-5.5/Mtoken
• 差异约 20-25%——Prefix 共享的投入产出比仍然显著。此估算保守，未计入 prefix 命中后更紧凑的 batch 调度带来的 decode 侧间接收益

对标 V4 Flash 官方定价： ¥2/Mtoken（约 $0.28/Mtoken）。我们的 8×H100 部署成本远高于官方定价——这说明 DeepSeek 通过昇腾 950PR 硬件成本优势（单价约 H200 的 1/3.6）+ 更大的集群规模 + 更激进的 PD 分析实现了远低于 H100 集群的单价。H100 部署 V4 Flash 不是有竞争力的方案——但案例分析揭示了成本结构。

8.6 案例小结

核心发现：V4 Flash 的 KV cache 已经小到不再是任何意义上的瓶颈——100 并发请求仅 2 MB，连 HBM 的零头都占不到。真正的战场转移到了三个地方：

1. Prefill 计算节省：Prefix 共享是最高 ROI 的优化。每节省一次 prefill，等于节省 26 GFLOP/token。KV cache 小到免费存储，但 prefill 的计算一分钱也没省。
2. MoE 专家加载带宽：284B 总参数跨 8 GPU 分布，每步 decode 需要加载路由选中的专家。这是 V4 Flash 推理延迟的主要来源。
3. PCIe 带宽在 PD 分离架构下：P 节点和 D 节点之间的专家参数传输（不是 KV cache 传输——后者可忽略）

这与 DeepSeek DualPath 论文的结论一致——在 98.7% 命中率下，推理瓶颈已从"算力"转移到"存储 I/O 带宽"。V4 Flash 上进一步转移到了"MoE 专家加载带宽"。

九、设计决策矩阵

把上述分析汇总为一个 V4 时代的设计决策框架：

十、开放问题

1. CSA 选择模式的可预测性：CSA 的 top-k 选择由模型权重决定，在给定输入下是确定的。如果离线分析 CSA 的选择模式（哪些 KV 条目被高频选中），可以指导 prefix cache 的淘汰策略。但这需要深入到模型内部的 instrumentation，当前推理框架（vLLM、SGLang）不支持。

2. MoE × KV cache 的联合调度：V4 Flash 中，每步 decode 激活 13B 参数（路由选中的专家）。被激活专家的参数和对应层的 KV cache 是"同时热"的——两者可以联合调度。但 V4 上 KV cache 太小，联合调度的收益主要在 专家参数预加载 + KV cache 读取的带宽分配 上。

3. PD 分离架构的最优路由：P 节点完成 prefill 后，需要把 KV cache 传给 D 节点。V4 Flash 的 KV cache 极小（20 KB/请求），传输本身不是问题。但选择哪个 D 节点——考虑到 D 节点上的 MoE 专家分布和当前负载——是一个有意义的调度问题。

4. 超长上下文（1M tokens）下的新瓶颈：虽然 V4 Flash 的 KV cache 每 token 仅 6.3 bytes，但 1M tokens 上下文的 KV cache 总量 = 6.3 MB——仍然不大。真正的挑战是 CSA 在 1M 长度下的选择精度衰减，以及 HCA 的块间摘要在超长序列下的信息丢失。这是架构级问题，不是调度能解决的。

十一、KV Cache 差分编码：CSA+HCA 之上的正交优化

开放问题中最值得展开的技术方向是 KV cache 差分编码（Delta Encoding）。如果它可行，可能在 CSA+HCA 的基础上进一步压缩 KV cache。

但需要先承认一个 V4 时代的尴尬事实：CSA+HCA 已经把 KV cache 压到极低，差分编码的边际收益可能递减。

11.1 问题

当前所有 KV cache 管理策略——无论 LRU、Attention Score 还是 Prefix Tree——都建立在同一个假设上：每个 token 的 KV 向量是独立的、完整的、不可压缩的。量化方案（FP8→INT4→TurboQuant 的极坐标压缩）在精度上做妥协，但不改变"逐 token 独立存储"的范式。

CSA+HCA 改变了这个范式的一部分——CSA 在架构级做了稀疏选择，HCA 做了块级压缩。但被选中保留的 KV 条目仍然是独立存储的完整向量。差分编码针对的就是这部分。

11.2 技术原理：帧间预测类比

视频压缩领域有一个成熟的范式——帧间预测（Inter-frame Prediction）：

• I 帧（关键帧）：完整存储
• P 帧（预测帧）：只存相对于前一帧的运动矢量 + 残差
• B 帧（双向预测帧）：参考前后帧做插值

在自然语言序列中，语义连续的 token 段（如一句话中的连续词、一段代码中的连续行）的 KV 向量通常高度相似。如果把每个 token 的完整 KV 看作"I 帧"，那么：

• KV Delta：只存 ΔKV_t = KV_t - KV_{t-1}（残差）
• KV P-Frame：对语义连续段，只存一个"关键帧"+ 后续 token 的增量
• KV B-Frame：对中间段，用前后关键帧插值

11.3 理论收益估算（以 V4 Flash 为基准）

V4 Flash CSA+HCA FP8 下，每 token KV cache 约 6.3 bytes。如果差分编码能将连续段的增量压缩到原始大小的 1/4（类比 H.264 的 P 帧压缩比）：

对比当前主流压缩方案在 V4 Flash 上的效果：

• CSA+HCA 本身（vs 标准 MHA）：~50,000× 压缩
• INT4 量化（vs FP8）：2× 压缩（精度损失 3-5%）
• TurboQuant（Google 2026-03）：6× 压缩（精度零损失）
• 差分编码（理论，叠加在 CSA+HCA 上）：额外 5-13× 压缩

11.4 边际收益递减的判断

这里必须做一个诚实的判断。

在 V3 时代（MLA FP8 ~31 KB/token），差分编码的理论收益是 6-12× 压缩——从 31 KB 降到 2.5-5 KB。绝对节省 26-28 KB/token，对 100 并发请求来说是 8-9 GB HBM。意义重大。

在 V4 Flash 时代（CSA+HCA FP8 ~6.3 bytes/token），差分编码的理论收益同样是 5-13× 压缩——从 6.3 bytes 降到 0.5-1.2 bytes。但绝对节省仅 5-6 bytes/token，对 100 并发请求来说只有 1.6-1.9 MB。节省 1.6 MB 在 640 GB HBM 上的意义接近于零。

差分编码在 V4 上的价值不在于节省存储空间，而可能在于：

1. 减少 PD 分离时的 KV cache 传输量：虽然 V4 Flash 的 KV cache 已经很小（2 MB/100 请求），但在超大规模部署（10,000+ 并发请求 × 长上下文）下，PD 分离的网络带宽仍可能成为瓶颈。差分编码可以将传输量再降一个数量级。
2. 减少 HBM 带宽争抢：虽然 KV cache 占用空间小，但每步 decode 都要读全部 KV。V4 Flash 的 3,200 tokens × 6.3 bytes = 20 KB/请求/步，100 并发 = 2 MB/步。差分编码后降到 ~0.4 MB/步——减少了 HBM 带宽占用，为 MoE 专家加载留出更多带宽。
3. 超长上下文场景：1M tokens × 6.3 bytes = 6.3 MB/请求。100 个 1M 上下文请求 = 630 MB——开始有意义了。差分编码降到 ~120 MB，节省 510 MB HBM。在极端长上下文场景下，差分编码仍然有价值。

11.5 当前研究状态

截至 2026 年中，差分编码在标准 Transformer KV cache 中的应用仍处于早期探索阶段，但相邻领域已有重要线索：

线索一：上海交大 dLLM-Cache（2025） 上海交大 EPIC Lab 在扩散式语言模型（dLLM）中提出了 dLLM-Cache，核心思路高度相似——识别相邻去噪步之间变化较小的特征，只更新变化较大的部分。实测在 LLaDA、Dream 等模型上实现 最高 9.1× 推理加速，零精度损失。这证明了"相邻步 KV 冗余"在非自回归模型中是可利用的。

线索二：Mamba/RWKV 的隐式差分 状态空间模型（Mamba、RWV）天然使用递归状态更新——隐式地只保存"增量"。TTT-Linear（Stanford, 2024）将隐藏状态本身定义为一个可学习的模型，本质是极激进的差分压缩。这些架构证明了"不存完整历史 KV，只存压缩状态"在原理上是可行的。

线索三：Attention Score 稀疏性研究 H2O、PyramidKV 等工作表明，在长上下文中，attention 分数高度集中在少数 token 上——95%+ 的 KV 向量对最终 attention 输出的贡献低于噪声阈值。这间接证明了大量 KV 向量是"可压缩冗余"。CSA 在架构级利用了这一点——它的 top-k 选择本质上就是 H2O 的思路固化到模型权重中。

线索四：FlashMemory-DeepSeek-V4 论文（2026） DeepSeek 在 V4 发布同时公开了 FlashMemory 论文，描述了 V4 生产环境的 KV cache 管理框架。论文确认了 CSA+HCA 的 KV cache 压缩比例，并展示了在昇腾 950PR 硬件上的端到端延迟数据。这是目前最接近 V4 生产数据的公开文献。

空白地带： 将差分编码直接应用于标准 Transformer 的自回归 KV cache，且在 CSA+HCA 架构之上——目前没有公开发表的方案。这是一个明确的研究空白，但其商业价值在常规上下文长度（<32K）下可能有限。

11.6 如果可行，意味着什么（V4 视角）

对推理经济学的影响：

以 V4 Flash 为例（8×H100 部署，100 并发，平均 3,200 tokens）：

• 当前 CSA+HCA FP8 KV cache：~2 MB（可忽略）
• 差分编码后（假设 5× 压缩）：~0.4 MB（更加可忽略）
• 节省的 1.6 MB HBM 没有任何实际意义

但在 1M 超长上下文场景下：

• 当前 CSA+HCA FP8 KV cache（100 并发 × 1M tokens）：630 MB
• 差分编码后：~126 MB
• 节省的 504 MB 有意义——可以为 MoE 专家留出更多 HBM 空间

对架构演进的影响：

如果差分编码在 CSA+HCA 之上还能实现 5-13× 压缩，那么 1M token 超长上下文的 KV cache 成本从 ~6 MB/请求 降到 ~0.5-1.2 MB/请求。这让超长上下文推理的 带宽成本（而非存储成本）显著降低——每步 decode 需要读取的 KV 数据量减少，HBM 带宽争抢缓解。

对调度策略的影响：

差分编码改变冷热分级的框架。当 KV cache 被编码为"I 帧 + P 帧序列"后：

• I 帧天然是 P0（必须 HBM 常驻）
• P 帧天然是 P2/P3（极小体积，传输成本可忽略）
• PD 分离时的 KV 传输量进一步降低

但在 V4 Flash 上，这个改善的绝对值太小，对常规场景几乎不可感知。

原创判断：

差分编码在 V3 时代是一个被低估的方向，在 V4 时代则面临边际收益递减的尴尬。

CSA+HCA 已经在架构级做了激进的 KV 压缩——稀疏选择 + 块级压缩 + 条件记忆。差分编码是在这个已经极小的基数上再做压缩，绝对收益有限。但差分编码与 CSA+HCA 是 正交的——两者作用于不同维度（CSA 作用于"哪些 KV 被读取"，差分编码作用于"被读取的 KV 如何编码"）。在超长上下文（>128K）场景下，正交叠加的价值仍然存在。

更值得关注的方向是 CSA 选择模式的离线分析——如果能把 CSA 在不同输入下的 top-k 选择模式建模出来，就可以在不运行模型的情况下预测哪些 KV 条目会被选中。这比差分编码更有工程价值，因为它直接影响 prefix cache 的淘汰策略和 PD 分离的路由决策。

差分编码不是 V4 时代的银弹。V4 时代真正的战场是 MoE 专家加载带宽、PD 分离路由优化、和 prefill 计算的最大化复用。

后续验证（2026-08-11）： 本文讨论的"压缩到 7% 之后怎么办"已在 FMS 2026 上获得硬件层答案——NVIDIA ICMSP 把 SSD 变成 KV Cache 的正式内存节点，CXL 内存池和 GPU-Direct SSD 构成分层管理。详见《FMS 2026：存储层级正在长出新的一层》。

参考来源

• DeepSeek V4 技术报告（2026-04）— V4 Flash（284B/13B）和 V4 Pro（1.6T/49B）架构，CSA+HCA 混合注意力，KV Cache 降至 V3.2 的 7%/10%
• FlashMemory-DeepSeek-V4 论文（2026）— V4 生产环境 KV cache 管理框架，CSA+HCA 端到端延迟数据
• Liu et al. "Lost in the Middle: How Language Models Use Long Contexts"（attention sink 现象）
• vLLM / PagedAttention 论文（Kwon et al., 2023）— Block 级虚拟内存管理，显存利用率 ~60%→95%+
• SGLang / RadixAttention 论文（Zheng et al., 2023）— 前缀树复用，缓存命中率提升 3-5×
• DeepSeek V3 技术报告（2024）— MLA 设计，671B MoE / 37B 激活，FP8（历史基准）
• DeepSeek DualPath 论文（2026-02）— 660B 生产模型，KV-Cache 命中率 98.7%，吞吐提升 1.87×/1.96×（V4 生产环境验证）
• TurboQuant（Google, 2026-03）— 极坐标量化 + JL 变换，6× 压缩零损失
• dLLM-Cache（上海交大 EPIC Lab, 2025）— 扩散语言模型 KV 缓存复用，9.1× 加速
• TTT-Linear（Stanford, 2024）— 可学习的隐藏状态，线性复杂度长上下文
• H2O、PyramidKV — Attention Score 稀疏性，KV 剪枝
• FlashAttention (Dao et al.) — KV 连续性约束的来源
• 唐杰团队 LLM Memory 综述（2026-08）— 架构级记忆分类框架