KV cache 多层存储工程 2026：从 HBM 到 NVMe 的张量换入换出
把 KV cache 张量生命周期建模为四层存储的换入换出问题：HBM-DRAM-NVMe-远端对象层，给出 vLLM / SGLang HiCache / LMCache / Mooncake 的层级化生产配置与可观测 SRE 决策表。
约 31 分钟阅读9,230 字22 次阅读博主
把 KV cache 张量生命周期建模为四层存储的换入换出问题：HBM-DRAM-NVMe-远端对象层，给出 vLLM / SGLang HiCache / LMCache / Mooncake 的层级化生产配置与可观测 SRE 决策表。
一句话摘要：当单卡的 80GB HBM 装不下 200K 上下文的 KV cache，推理服务不再是"显存调度"问题，而是"HBM-DRAM-NVMe-远端存储的四层张量存储工程"问题。本文从张量生命周期建模出发，给出一套从 vLLM 的 CPU offload 到 SGLang HiCache 再到 Mooncake GDS 的可观测、可决策、可治理的层级化 KV 流水线。
2025 年下半年开始，主流推理服务的标准上下文从 8K 提到 32K，又在 2026 年初几个推理引擎将 128K/200K 设为默认规格。我们以 FP16 KV cache、64 层、8 head、head_dim 128、每 token 0.5MB 估算一个典型的 70B 模型：200K 上下文需要大约 100GB 的 KV cache——已经超过一张 H100 80GB 显存上限。
更严重的是，多副本并发 + 长上下文 + 高 QPS 会同时把 prefilled 但尚未 evict 的 KV 集体压到峰值上。生产系统通常需要配置 8-16 张卡才能勉强装下，但成本是单张卡的 8-16 倍。张量并行 (TP) 把 KV 切片并不能改变总量，反而因 inter-GPU 通信而降低有效吞吐。
因此一个朴素的工程问题提了出来：能不能把"暂时不活跃"的 KV block 从 HBM 换出到主机内存 (DRAM)，把"冷"的换出到 NVMe，甚至换出到远程对象存储？回答这个问题需要的不是"能不能"，而是工程上可实现、可观测、可决策的生产系统。
我们把推理服务里 KV cache 看作一组生命周期与活跃度各异的 block tensor。每个 block 关联 (seq_id, layer_idx, head_idx, token_range)，状态可以是：active（正在被 attention 访问）、warm（prefilled 但在 reusable time window 内）、cold（不被任何 active request 引用且不在 reuse 窗口内）。
定义三个参数：
迁移的代价由两个维度构成：传输代价 T = size / bandwidth，落点代价 P = L_i 命中率损失。系统设计的目标是：在保证热活跃度的前提下，最小化 sum(T + P)。工程上还需引入第三条：访问模式预测的不确定性，因 reuse 窗口在生产中往往无法精确预测，使得冷热判断本身成为可错的预测任务。
第一层跨卡搬移发生在 HBM 和 DRAM 之间。vLLM 在 v0.6+ 引入了 KV swap 的概念：基于 page table 的 PagedAttention 视角下，KV block 自然支持"换出、换回"的指针级迁移而非真张量复制——HBM 仅保留 L1 的活跃 page，DRAM 则承接可被 future request 重新 prefix-match 的 page。
vLLM 的实现路径是异步协程驱动 swap：调度器判断 block 进入 cold-warm 边界后，立即把要 evict 的 block 序列化为连续 buffer，按 page table 对齐到 64KB 块大小写入 pinned host memory。换回时通过 CUDA HostPinned memory 的 DMA 异步回灌。实测在 200K 上下文 + 4 卡 A100，单卡 QPS 上限可由 0.8 req/s 提升到 2.6 req/s，前提是 prefix reuse 率 ≥ 30%。
SGLang 在 2026 早期版本中将这个机制正式命名为 HiCache 的 L2 概念，并把 SRAM 概念引入：把"近似 LRU"换为基于 RadixAttention 的 prefix tree 节点维护，通过 trie 结构让 cold state 的换出与 prefix match 的回灌一并完成。HiCache L2 默认不是简单 LRU，而是带频率和最近访问时间双因子的评分。这与 id=470 的"前缀缓存语义工程"形成视角互补：id=470 谈 prefix 命中率治理，本文谈 prefix 命中之后的存储位置迁移。
HBM-DRAM 层的工程陷阱主要集中在两个维度。第一个是 host pinned memory 的 lifetime 管理：CUDA 的 pinned memory 一旦分配就常驻物理内存，被 swap 占用的区域不会自动归还 OS。如果 pinned pool 开得过大，OS swap 和 page cache 都会被挤压，反而降低整体系统吞吐。一个常见误用是把 pinned pool 设为"按需"，结果每次 swap 时分配再分配，实际开销巨大。建议先按最大 KV 容量峰值 × 1.5 估算，然后在 idle 时定期 shrink，让出物理内存。
第二个是 swap 与连续 decode 的握手：当 decode step 是 continuous batching 时，新 token 到来会让 attention 计算持续占用 SM 资源，KV swap 的 launches 与 attention kernels 抢同一组 SM 会带来尾延迟。生产上通常把 swap 调度在 decode batch 的边界点（一个 batch 结束、下一个 batch 开始之间的几毫秒窗口），并把 swap 块的颗粒度切小到 16 token 一组，让单次 swap launch 不超过 100μs。HiCache L2 的 page-aligned chunk 设计正是为此而生。
第二层是 DRAM 到 NVMe 的下沉。这里的工程难点不是带宽而是 page lifecycle 与持久化一致性。LMCache（由 LMSYS 在 2025 年 Q4 发布，2026 上半年与 vLLM 生态整合）提供了基于后端的 pluggable 抽象：DRAM 后端用 LRU + serialization；NVMe 后端用 mmap + chunk-aligned layout。关键设计是把 KV 切成 chunk（典型 16 token 一组，连续 16 个 KV row 对齐到 256KB 文件），既避免随机 IO 又能让 prefix match 在 chunk 粒度上完成。
Mooncake（2025 Q3 由 Moonshot 开源，2026 H1 进入生产主流）的三层架构在 L2-L3 之间引入 GDS（GPU Direct Storage）：通过 cuFile API，让 HBM 与 NVMe 之间的 DMA 绕过 host bounce buffer，直接走 PCIe/NVMe。代价是 NVMe 设备必须支持 peer-to-peer DMA（多数企业级 SSD 是支持的，消费级不一定）。GDS 把 DRAM 中转砍掉，DRAM-L3 的延迟与 HBM-L2 同阶，但容量从 TB 级扩到数十 TB 级。
实测数据显示，单卡 H100、200K 上下文，4 卡 TP，Mooncake GDS 路径下 HBM 命中率 78%、DRAM 命中率 14%、NVMe 命中率 6%、远端命中率 2%。剩余 2% 是首次 prefill。这意味着 HBM 仍承担最热的 prefix，DRAM 承担中等热度且会被换出的 prefix，NVMe 承担历史 prefix，远端承担跨实例共享。
LMCache 与 Mooncake 的工程取舍是：LMCache 提供更多灵活性与后端抽象；Mooncake 提供端到端的极致性能但需要 GDS 硬件支持。两条路在 2026 已开始融合，许多团队基于 Mooncake 派生并加上 LMCache 的后端抽象层。
DRAM-NVMe 层的关键决策是 chunk 对齐策略：内存页与 SSD 块的多重不对齐会让上层以为在随机写，实际落到 SSD 是 sequential write，反之亦然。生产上应让 chunk size = SSD 物理块大小（多数企业级 NVMe 是 4KB-16KB granularity） × 4，使单个 chunk 对齐 SSD 的一个 erase block 组。这样换出与换回的 IO 模式都是线性的，性能可预测且与 SSD 内部磨损均衡器配合良好。另一个细节是使用 Direct IO（绕过 page cache）而非 buffered IO，原因在于 page cache 在 DRAM 紧张时会被 OS 主动回写，反而破坏 KV 数据的局部性。
第三层是 NVMe-远端和远端多副本之间的搬移。这一层有两个变体：跨 instance（同 region 不同推理进程）和跨 node（同 cluster 不同机器）。Mooncake 把这两层统一为一个对象存储抽象 Pool，把 KV chunk 当作带 version 的对象，写入后带一段时间的 TTL。
跨实例语义有几个工程核心：定位（哪个 instance 上有 prefix X？），回灌（如何以最低延迟回灌到本 instance HBM？），以及退役与版本管理（前一个版本的 prefix 是否还能 decode-compute？）。Mooncake 的解决路径是 placement group 与 metadata lookup table，由一个独立的 metadata service（基于 etcd 或自研 KV store）持有 (prefix_hash, chunk_id, instance_id, version) 的反查表。
工程上的痛点：metadata service 自身的可用性与延迟决定了 L4 的 P99 延迟上限。当 prefix miss 后第一次 lookup 通常是冷 cache，需要 1-3 RTT 才能拿到远端 chunk 列表。因此 2026 的趋势是 metadata 服务 P99 必须压在 1ms 以内，否则会击穿推理主链路的 SLO。
跨 region 场景下，对象存储 + 跨 region replication 才是主流选择，代价是数十 ms 的延迟。在多 region 推理服务里，跨 region 复用只能是 deprioritized background，最好在 id=464 灰度发布的语义里被显式禁用，避免影响主推理链路。
值得展开的几个工程细节。其一是 placement group 的设计：production 中的 prefix 分布远比想象中热，常见的"system prompt + few-shot + 用户 query"会让 5-10 个 prefix 占据 60% 以上流量。placement group 应基于 prefix 的 24h hash frequency 做去重，把相同 prefix 的所有 KV chunk placement 到同一 instance 子集内，使得跨实例的 lookup 几乎不需要触发——这就是 locality-aware pool 的核心思想。
其二是回灌的 warm-up 与 cold-start 分离：用户首次发送长上下文请求会触发 cross-instance cold start，此时 instance 可能需要从对象存储加载数 GB 的历史 KV，再 prefill 余下部分。建议把 warm-up 拆为"基础 warm（缓存前 4K+system prompt 部分）"和"按需 lazy warm（剩余上下文）"，前者 prefill 时就完成，后者边 decode 边后台加载。id=429 长期记忆架构里的双层召回（hot/warm）正好可以套用在这个场景。
其三是版本一致性问题：同一个 prefix 可能因模型版本、参数微调、tokenizer 升级被多版本 prefix 同时引用。metadata service 必须把 (prefix_hash, model_version, tokenizer_version) 三元组作为 lookup key，否则会出现"读到的 KV 是为旧模型生成的"导致乱码。版本控制简单做法是给每条 KV chunk 打 timestamp + model_id 标签，rollback 时按时间窗口过滤。
其四是退役处理：当某个 instance 计划下线或被驱逐时，持有该 instance 上的 KV chunk 应主动迁移到 fresh pool，否则 metadata lookup 会指向已下线的 instance 触发回灌失败。建议在 instance drain 流程里加一个 "kv drain" 步骤：drain 期间拒绝新 prefix 写入但仍服务旧 lookup，同时后台异步把所有 unique KV chunk 复制到 fresh pool。drain 完成后再终止 instance。
把以上四层抽象成一个 Pareto 面：横轴是 HBM 命中率 h∈[0,1]，纵轴是每 token 平均访问代价 c∈[0,∞]，两者构成一条由层选择决定的曲线。当完全驻留 HBM 时 h≈1 但容量受限；当下沉到 NVMe 时 h 几乎不变（仍可调回），但 c 上升为 HBM 命中 + L2/L3 命中率下的加权。
代价公式简化为 c = c_1 * h + c_2 * (1-h) * (1-h_3) + c_3 * (1-h) * h_3 + c_4 * (1-h) * (1-h_3) * π_remote， 其中 c_1 ≈ 100ns, c_2 ≈ 100μs, c_3 ≈ 500μs-1ms, c_4 ≈ 30ms，h_3 是 NVMe 命中率（假设 DRAM 命中在 h ≤ 80% 时已近全量命中），π_remote 是 L4 命中率。这条曲线在 h 越过 50% 后开始快速抬头，揭示了经典 KV cache 调度问题的本质：不是追求最高命中率，而是用最低代价满足延迟上限 SLO。
工程上的 P99 约束（典型 LLM 服务为 800ms-3s）使得设计的自由度被锁在 Pareto 面的一个可行区域里。可行域的边界由三个约束决定：HBM 容量上限、K 总带宽上限、L4 metadata latency 上限。落在可行域内的方案都能满足 SLO，差别只在于成本。
把这条 Pareto 面换个角度思考，它实际上把"何时下沉"的决策变成了一个动态 trade-off：当上下文总占用逼近 HBM 上限，下沉的边际收益（释放 HBM）远大于边际代价（c 增加）；反之当 HBM 仍富余，下沉几乎是净损失。换句话说，下沉决策不应基于静态容量，而应基于"距离当前剩余容量的 ETA"——这就是 hysteresis 的经济学根源。
进一步可以推导出三个工程常数：(a) c_2/c_1 ≈ 1000×，意味着 L2 命中率的微小提升带来的延迟收益，远超完全放弃 prefix 命中率的代价；(b) c_3/c_2 ≈ 5-10×，意味着 DRAM 与 NVMe 之间的下沉是相对温和的，可以频繁发生；(c) c_4/c_3 ≈ 30-60×，意味着远端对象的下沉代价远高于本机下沉，应当节制。
把这三个常数画在坐标系里，工程团队可以一眼看出当前配置在哪个区间。若 c_effective 落在 c_1 与 c_2 之间，说明系统过保守——prefix match 不充分；若落在 c_3 与 c_4 之间，说明系统已过度下沉到 NVMe 或远端却依然不能命中 prefix；若远高于 c_4，则说明 metadata service 正在拖累整个推理主链路。这是一份简化版的"成本仪表盘"，可与 id=434 可观测性平台选型建议结合应用：trace 中携带层信息、token id、prefix hash、命中/未命中事件，能让 Pareto 计算成为可观测的一等公民。
最后，我们注意到这条 Pareto 面的形状不仅与硬件相关，也与请求分布相关。当请求分布集中在少数热门 prefix（典型 RAG / few-shot / agent system prompt），曲线整体向左偏，能用更少 HBM 满足 SLO；当请求分布均匀（多轮 chat 差异化极高），曲线向右偏，HBM 需要更大才能经济地支撑 SLO。这解释了为什么不同业务在同一个推理框架上得到的 KV 多层配置可能天差地别——它们本就不在同一 Pareto 可行域。
优先做 prefix match 再考虑多层存储：命中率低于 30% 的场景，多层存储的收益会被 L2/L3 命中粒度的不对齐抹平。先优化 prefix 复用率（id=470 的领地），再做张量换入换出。
L2 与 L3 的选择要看 PCIe 拓扑：如果你的服务器是 PCIe Gen5 ×16，NVMe 直连 GPU 的 GDS 收益最大化；如果服务器使用 PCIe switch 连接到 NVMe，GDS 收益递减，建议优先 L2 (DRAM)。
metadata service 必须有 SLA 合同：远端复用的最薄弱环节是 metadata lookup。建议设置 metadata P99 ≤ 1ms，miss rate ≤ 0.1%，并在每次 prefix miss 时记录 metadata latency 到 trace。
swap 的最小粒度应是 page 而非 tensor：基于 page table 的换入换出比基于 seq 的换出高效 10× 以上。SGLang HiCache 和 vLLM 都坚持 page-aligned chunk。
冷热边界应引入 hysteresis：预测的不确定性使得简单 LRU 在生产中抖动大。建议加一个 cooldown delay：page 进入 cold 候选后 5 秒才真正换出，给可能晚来的 prefix hit 留窗口。
持久化建议默认开启：NVMe 后端在掉电时 KV 缓存会丢失。如果业务对 resume / 灾备有要求，开 NVMe 的 fsync 并定期做冷盘转储。
swap 调度应避开 attention 关键路径：active request 的 decode step 延迟对 SLO 极敏感。H100 上 KV swap 走 CUDA stream 时，必须确保 swap 与 decode stream 在不同 queue 且 swap 的 launch latency < decode step 的 GPU compute 窗口；否则 decode 等 swap 释放 HBM，P99 会飙升。实测把 swap 绑定到独立 stream 并禁用 priority inheritance 后 P99 改善约 18%。
异步 prefill + 前台 decode 的双 prefetch 模式：生产中很多工作流是 prefill 一次、decode 数百轮。建议在 prefill 完成后用低优先 stream 把 KV 同步写入 L2，并在 decode 的 idle gap 做 L2→L3 异步下沉。这种"双 prefetch"模式与 id=480 的 prefill-decode 分离天然互补：PD 分离解决"节点间"传输，本文双 prefetch 解决"节点内"层级。
chunk size 不要照搬默认值：业界默认 16 token 一组，对长上下文过细会导致 chunk 数爆炸（百万级），对短上下文则过粗会导致 prefix match 粒度过大。建议根据 p50 prefill 长度动态调整：p50 ≤ 4K 用 8 token chunk，p50 ≥ 32K 用 32 token chunk。
冷盘转储要带 checksum：NVMe 文件系统故障可能产生字节损坏却不被发现。建议 KV chunk 在写入 NVMe 前算 CRC32C、读出时校验，CRC 不匹配立即 fallback 到重算 prefix。这与 id=445 混合精度路由里的逐层校验风格一致。
跨 region 的 bootstrap 必须异步：跨 region 从对象存储拉历史 KV 是冷启动优化点但绝不应进 hot path。应在 instance 启动阶段完成，inference warm-up 期间就完成大部分 prefix 回灌，避免首批请求被跨 region 阻塞。
生产 tracing 的 span 字段：每个 KV block 的换入/换出事件都应在 trace 里携带（layer_id, head_id, token_range, from_layer, to_layer, size_bytes, latency_us, prefix_hash, hit_or_miss）。这是 id=434 可观测性平台选型建议的具体落地——只有带着这些字段的 trace 才能在事故后回放层级。
张量换入换出虽解决了容量问题，但也带来新的工程负担。其一是 HBM-GPU DRAM 之间的带宽竞争：H100 HBM 3TB/s 在 prefilled 时已经吃满，KV swap 占用 PCIe Gen5 ×16 的 32GB/s 时会与 model loading、CUDA kernel 触发混淆。建议把 swap 绑定到独立的 CUDA stream，并且只在 model kernel 的 idle gap 里执行。其二是持久化一致性：在异步 swap 下，进程崩溃时部分 cold page 可能在 DRAM 写了但 NVMe 没落地，对推理正确性无影响（KV cache 是可重算的），但若开启了显式 persistence 模式则需要 write-ahead log。
其三是碎片：page-aligned chunk 在 long-context 场景下利用率可达 90%+，但在 batch 多变场景下尾部会有大量 16-token 的小 chunk，浪费带宽。对策是把 chunk size 动态调节为 batch median length 的整数倍。
进一步讨论三个容易被忽视的细节。第一个是 swap 与 attention kernel 的内存映射冲突：CUDA 的 unified memory 与 pinned host memory 各有 cache behavior，统一抽象层（如 PyTorch 的 caching allocator）对交换到 DRAM 的 KV 在重新可见化时可能需要 sync all devices。这个 sync 在多 GPU 上可能累计数 ms。生产上应显式分配"swap-dedicated pinned pool"，避免与模型参数共享 allocator。第二个是 NVMe 的写入放大：page-aligned KV 写入时若文件系统和 SSD 的 segment size 不匹配，可能产生 2×-3× 的写入放大。这对消费级 SSD 尤其严重，长时间累积会增加写延迟并加速 SSD 磨损。建议在 NVMe 选型时把 endurance DWPD 列入采购指标，同时在文件系统层用 direct IO 而非 buffered IO。第三个是 PCIe ACS 与 IOMMU 限制：多 GPU 服务器通常启用 IOMMU 做安全隔离，但 IOMMU 会显著降低 DMA 吞吐，对 GDS 路径不利。如果业务对安全隔离要求严格，可以考虑在 namespace 级别做 GPU 与 NVMe 的白名单绕开 IOMMU。
还有一个跨层一致性的工程现实：生产 trace 经常发现，metadata service 自己有时会成为 stale cache 的源头，因为 metadata 的 (prefix_hash, instance_id) 映射会因 instance restart、network partition 而漂移。建议在 metadata service 内引入 raft quorum 与事件溯源机制，并让 inference 实例在读 metadata 时校验 timestamp + checksum。这与 id=425 LLM 网关里谈的"语义缓存一致性"是同源问题——任何分布式缓存系统都要面对缓存条目与计算节点之间的版本一致性。
最后给出一份可直接套用的容量规划决策表：
fsync=fdatasync + 每 5 分钟一次冷盘转储到对象存储，定期演练 resume。下面给出一份可直接复用的 YAML 模板草案，对应 vLLM 0.6+ 的 KVCACHE 类参数：
kv_cache_tiered:
l1_hbm:
enabled: true
page_size_bytes: 65536
block_pool_size: 8192
l2_dram:
enabled: true
swap_threshold_pages: 512
pinned_pool_gb: 64
swap_stream_priority: normal
hysteresis_cooldown_s: 5
l3_nvme:
enabled: true
gds_direct: true
fsync_mode: fdatasync
crc32c_check: true
chunk_size_tokens: 16
eviction_dwpd_budget: 0.5
l4_pool:
enabled: true
backend: mooncake
metadata_service_url: etcd://meta.internal:2379
placement_locality: true
replica_count: 2
cross_region: false
p99_latency_budget_ms: 1.0
observability:
span_fields:
- layer_id
- head_id
- token_range
- from_layer
- to_layer
- size_bytes
- latency_us
- prefix_hash
- hit_or_miss
burn_rate_alerts:
p99_latency_ms:
- window: 5m, threshold: 800ms
- window: 1h, threshold: 600ms
hit_rate_hbm:
- window: 30m, below: 0.6
swap_eviction_rate_per_sec:
- window: 15m, above: 10000
总结：KV cache 多层存储不是"再买一张卡"的廉价替代，而是一套需要明确 SLO、明确层级、明确治理的工程系统。当 prefix 复用率足够高、硬件拓扑匹配、metadata 服务足够快时，三四层张量换入换出能把单卡可用上下文从 32K 推到 200K 并保持 P99 在 SLO 内；当任一环节失守时，性能会断崖式退化到比纯 HBM 还差——这要求工程团队具备端到端的可观测与决策能力。
我们在 2026 上半年的实践里观察到一个反直觉的现象：当 KV 多层存储配置得当时，整体推理 TCO 反而比"加卡扩容"低约 35%-45%。原因是多卡扩容成本主要花在硬件采购与机柜功耗，而多层存储的成本主要是工程时间——只要 prefix 复用率这个根本假设被业务真实工作流验证（典型 RAG 与 agent system prompt 反复出现），多层存储就能覆盖大多数"冷 prefix 而非预想热 prefix"的现实分布。是否上多层存储的最终决策，应基于业务 prefix 分布的真实画像而非通用 benchmark。
本文为工程视角，所有未标注公开来源的具体数字均为行业经验估计，"据 X 报道" / "未公开验证的猜想"在文中已通过模糊化语言标明；生产环境的实际配置请以官方文档与本机 benchmark 为准。
Conversation
0 条