KV Cache 基础设施化：当缓存层脱离推理引擎

2026 年 6 月到 7 月，KV Cache 正在从推理引擎内部的一个内存管理优化，转变为一个由 GPU 厂商、存储厂商、开源社区三方同时下注的新基础设施层。存储原语、传输协议、调度路由、商业产品、硬件卸载五条线在六周内密集落地。这个层会由谁来定义，又会沉进物理介质多深？

一、六周内发生了什么

2026 年 5 月之前，KV Cache 的故事发生在推理引擎内部。vLLM 的 PagedAttention 在 GPU HBM 里管理 KV block 的生命周期；SGLang 的 RadixAttention 在单个 worker 内做前缀共享。这些优化不跨出单机边界。

5 月 7 日，vLLM 官方博客发表 Mooncake Store 深度集成文章——在 60 张 GB200 GPU 上，Mooncake 的分布式 KV 池实现了 3.8 倍吞吐量提升、TTFT 缩短 46 倍、端到端延迟缩短 8.6 倍。这是 KV Cache 第一次以"独立基础设施"的身份出现在生产级 benchmark 里。

接下来六周，五个层面的变化密集发生：

存储层：从引擎内部到独立存储后端。 vLLM 原生 OffloadingConnector 进化到支持三级架构（GPU HBM → CPU DRAM → 文件系统/对象存储）。LMCache 接入 Ceph、NetApp ONTAP S3、Redis 作为远端存储后端。llm-d（IBM/Red Hat/Google/Alibaba 联合，2026 年 3 月进入 CNCF Sandbox）推出 FS Backend，用 POSIX 文件系统的共享语义天然支持跨节点 KV 复用。AWS SageMaker 开始提供 KV offloading 一键部署。

传输层：两条路线同时生产化。 Mooncake Transfer Engine 走 RDMA GPUDirect 零拷贝路径，已集成进 vLLM、SGLang、TensorRT-LLM 三个主流引擎。LMCache v0.5.0 走 CPU DRAM P2P 共享路径，引入 HiddenStateStore。NVIDIA 的 NIXL（NVIDIA Inference Transfer Library）成为第三股力量——GTC 2025 发布，7 月 1.3 版本内置 DDN Infinia 存储插件，随 Dynamo 容器一起分发。

调度层：从 hash 路由到 ML 预测路由。 Ray 2.56.0（6 月 30 日）的 PrefixCacheAffinityRouter 把 KV 感知调度变成正式 release。llm-d 的 cache-aware scheduler 跟 Kubernetes Gateway API Inference Extension 深度集成。GKE Inference Gateway 更进一步——引入 XGBoost 模型预测每个请求的 TTFT 和 TPOT，用 ML 做路由决策。

商业层：存储厂商集体入场。 DDN Infinia 成为第一个原生集成进 NVIDIA NIXL 的存储产品（7 月开始随 Dynamo 容器发货）。VAST Data 联合 CoreWeave 实测 Dynamo KV offload：GPU 效率提升 90%，TTFT 缩短 20 倍。NetApp ONTAP S3 接入 LMCache。Xinnor 用 Lustre RO PCC + xiRAID 让共享存储在 KV Cache 场景达到接近本地 NVMe 的延迟。

硬件层：AFD 落地，LPU 入列。 NVIDIA Vera Rubin 平台引入 AFD（Attention-FFN Disaggregation）——GPU 做 attention，LPU 做 FFN，decode 阶段的计算管线被物理拆分到两种芯片上。LPX 机架（256 颗 Groq 3 LPU）的 40 PB/s 聚合 SRAM 带宽为 FFN 计算提供了远超 HBM 的带宽。

六周以前，这些组件散落在不同项目的 roadmap 里。六周以后，它们构成了一个完整的技术栈。但理解这个栈需要从一个更根本的问题开始：KV Cache 到底是什么——它的物理特征决定了上面的所有架构选择。

二、KV Cache 的物理特征

KV Cache 不是通用数据。它有一组独特的访问模式，这些模式决定了软件架构和硬件设计应该长什么样。不先理解这些物理特征，后面的所有分析都是空中楼阁。

Block 尺寸

KV Cache 的基本单元是 KV block——一组 token 的 Key 和 Value 矩阵。以一个典型万亿参数 MoE 模型（80 层、8 KV head（GQA）、128 head dim、FP8 精度）为例：

• 单 token 每层的 KV：8 head × 128 dim × 2(K+V) × 1 byte(FP8) = 2,048 bytes
• 单 token 全部 80 层的 KV：2,048 × 80 = 163,840 bytes ≈ 160 KB
• 一个 16-token block：~2.5 MB
• 一个 256-token block：~40 MB

KV block 的访问粒度是 MB 级，不是 CPU cache line（64B），也不是文件（GB 级）。这决定了寻址机制应该工作在什么粒度。

写入模式：write-once, append-only

Prefill 阶段一次写入全部 block，之后不再修改。Decode 阶段每个 token 追加一个新 block。绝大多数 KV block 在生命周期内只被写一次。

这与 CPU cache（可能被反复修改）和数据库（随机更新）截然不同。write-once 意味着 coherence 机制不需要跟踪"谁修改了这块数据"——一旦写完，就是 immutable。

读取模式：全量扫描 + 跨 session 随机

Decode 阶段每生成一个 token，需要读取当前 session 的全部历史 KV block。读取是 全量扫描——不是随机抓几块，是把整个 session 的 KV 都过一遍。

但跨 session 来看，调度器决定读哪个 session 的 KV——所以从全局视角，读取是随机的。

生命周期：秒到分钟级

Session 开始时创建，session 结束时删除。绝大多数 KV Cache 存活几秒到几分钟。不做持久化——session 断了，KV 就没用了。

这与存储产品的假设完全不同。存储系统为"数据不能丢"设计（持久化、副本、EC）。KV Cache 丢了可以重算——代价是几十毫秒到几秒的 prefill 时间。

共享模式：multi-reader, single-writer

公共前缀（系统 prompt、文档上下文）被多个 session 共享。一个生产者写入，N 个消费者读取。跨 session 共享前缀的 KV block 是 KV Cache 基础设施的核心价值来源——agentic 场景实测 94.2% 的 cache 命中率说明这个共享模式不是边缘 case，而是主流负载。

一致性要求：session-scoped

同一 session 内强一致：decode 读到的 KV 必须包含之前所有 decode 步骤追加的 block。读到不完整 KV 会直接导致模型生成错误 token。

跨 session 不需要一致性：不同 session 的 KV 互相独立，可以并行读写不干扰。

带宽需求推算

128K 上下文、1000 并发 session 的推理集群：

• KV Cache 总量：1000 × 128K × 160 KB/token ≈ 20 TB
• Decode 每 token 的 KV 读取带宽（每 session）：128K × 160 KB / decode_step_latency。如果 decode step = 50ms，单 session 读取带宽 ≈ 400 GB/s
• 1000 个并发 session 同时 decode：聚合读取带宽需求 ≈ 400 TB/s

对比：一个 8×Rubin GPU 节点的 HBM 聚合带宽约 176 TB/s。单节点的 HBM 带宽不够——KV Cache 的读取带宽需求超出单机能力约 2.3 倍。 加 GPU 可以增加带宽，但每加一台 GPU 节点也加了一整套算力和成本，而 KV Cache 只需要带宽，不需要等比例的算力增长。

这个数字说明了为什么 KV Cache 必须跨节点共享：不是因为一个 GPU 放不下全部 KV（虽然也放不下），而是因为一个 GPU 的 HBM 带宽喂不饱 decode 的读取需求。

与训练存储的本质区别

训练是写密集的长顺序 IO——梯度更新、checkpoint 保存，都是大块顺序写。推理是大量小粒度随机读写——KV block 级别的 load/save，频繁但小。训练存储的市场逻辑（大容量、高带宽、顺序优化）不完全适用于推理存储。推理需要的是：低延迟随机访问、高并发小 IO、block 级生命周期管理。

三、四层软件版图

KV Cache 基础设施的软件栈在六周内形成了四层结构。每层有 2-3 个生产级实现，各自有不同的设计哲学。

存储原语层（KV 放在哪）：

• vLLM 原生多级卸载（RFC #38260）：引擎内嵌。TieringManager 三级（HBM → DRAM → FS/PD peer），跨 TP 的 KV block 规范化为 TP=1 canonical form。
• LMCache：独立缓存中间件。三级存储（HBM → DRAM → NVMe/Redis/S3），v0.5.0+ MP 模式作为独立守护进程运行。LMCache 团队参与维护 vLLM Production Stack。学术论文（arXiv 2510.09665v2）首次系统性定义了 offloading 和 PD disaggregation 的边界。
• Mooncake Store：分布式 KV 池。RDMA GPUDirect 路径，KV block 从 GPU HBM 直接搬到远端 DRAM/SSD。FAST 2025 Best Paper 披露：Kimi 生产环境数千节点，日处理 1000 亿 token，A800 多承载 115% 请求，H800 多承载 107%。
• llm-d FS Backend：零依赖路径。KV block 写进任意 POSIX 文件系统，共享语义天然支持跨节点复用。2026 年 3 月进入 CNCF Sandbox。v0.4.0（2025 年 12 月）在 DeepSeek V3.1 + H200 上每输出 token 延迟降低 40%。
• NVIDIA Dynamo KVBM：GPU 厂商路径。内置 KV Block Manager，三层架构（LLM runtime → 逻辑块管理 → NIXL transport），原生集成 KV-aware routing。

传输协议层（KV 怎么移动）：

• RDMA 流派（Mooncake Transfer Engine / NIXL）：GPUDirect 零拷贝，Multi-NIC pooling，topology-aware。已集成进 vLLM、SGLang、TensorRT-LLM。
• P2P CPU Memory 流派（LMCache）：CPU DRAM 直接共享。实测 32 个 10K token 长上下文场景，TTFT 缩短 4 倍，round time 缩短 5 倍（LMCache blog，2026-06）。
• 文件系统路径（llm-d）：POSIX 语义保证一致性，延迟比 RDMA 高一个数量级，但跨域共享天然支持。Xinnor 实测配合 Lustre RO PCC + xiRAID 可逼近本地 NVMe。

调度路由层（请求分给哪个节点）：

• Ray 2.56.0 PrefixCacheAffinityRouter：两层策略（负载均衡时走前缀树路由，不均时退化为 Power of Two Choices）。局限：只在 ReplicaGroup 内路由。
• Mooncake Conductor（RFC 阶段）："三明治架构"，Conductor 调度层夹住推理引擎和 KV Store。
• llm-d cache-aware scheduler + GKE Inference Gateway：K8s Gateway API 集成。GKE 引入 XGBoost ML 预测路由。
• NVIDIA Dynamo KV-aware routing：配合 KVBM，支持 aggregated 和 disaggregated 两种模式。

运维治理层（谁管多租户和 SLA）：

Mooncake Store 三件套（分级调度、租户配额、高可用）是最早的信号。vLLM Hybrid KV Cache Manager 管理 HBM 内部资源分配。Dynamo 的治理跟 NIXL 插件生态绑定。

四、接口契约：引擎在哪里结束，缓存层从哪里开始

四层版图回答了"谁在做什么"。但一个更根本的问题没有触及：KV Cache 基础设施层和推理引擎之间的接口边界到底在哪？哪些职责属于引擎，哪些可以剥离出去？

当前的事实标准：vLLM KVConnector 接口

vLLM 的 KVConnectorBase_V1 是目前唯一被广泛实现的接口契约。它把 KV Cache 管理分成两侧：

调度侧（Scheduler-side）——引擎问缓存层："这个请求的前缀你已经有了多少？"

• get_num_new_matched_tokens() 返回外部缓存中已匹配的 token 数
• 引擎据此跳过已有前缀的 prefill 计算
• 匹配逻辑由缓存层自定义（精确前缀 hash、语义匹配等）

执行侧（Worker-side）——缓存层把 KV 数据搬进引擎的显存：

• start_load_kv() 在请求到达前异步预加载
• wait_for_save() 在请求结束后异步写回
• KV 数据最终写入 vLLM 的 PagedAttention 管理的 HBM 页面

这个接口的清晰之处在于：引擎拥有 KV 的数据格式和 HBM 内部管理，缓存层拥有跨实例的存储、传输和匹配。 两者的契约通过两个原子操作约定：一次读（load）、一次写（save），中间的存储介质、传输协议、淘汰策略都是缓存层的黑盒。

接口边界上的三个张力

张力一：TP 规范化。 当 KV block 从 GPU HBM 卸载到二级存储时，不同 tensor parallelism rank 产生的 KV 分片格式不同。缓存层需要在二级存储中规范化为 TP=1 的 canonical form——这意味着缓存层需要理解引擎的 tensor parallelism，即使它不做计算。缓存层不是纯粹的"存取"角色，它需要知道模型在 GPU 集群上的几何形状。

张力二：语义复用。 vLLM RFC #44223（2026 年新提）提出了"语义 KV Cache 复用"——不要求精确前缀匹配，允许近似或跨请求的 KV 复用。同一份文档被不同 prompt 引用时，已有 KV cache 可以被部分复用。但这要求缓存层做匹配判断，而匹配正确性直接影响推理质量。如果语义匹配出错，模型会在错误的 attention 状态上生成 token，结果不可预测。这个 RFC 目前被保守地限制在"前缀锚定的连续复用"范围内，但它打开了一个方向：缓存层可能从"存储服务"演变为"推理质量相关服务"。

张力三：混合注意力模型。 当模型同时使用 full attention 和 sliding-window attention（如 Mistral、Gemini），不同层的 KV cache 生命周期不同。Sliding-window 层的 KV 在窗口外就可以丢弃，full attention 层的 KV 需要完整保留。缓存层必须理解模型的注意力架构才能做正确的淘汰策略——这不是简单的 LRU 可以覆盖的。

独立 KV Cache 产品的功能要求

从以上张力中推导出独立 KV Cache 产品需要的完整能力清单：

最后两行是最大的空白。当前所有方案都假设同一个引擎（vLLM → vLLM、SGLang → SGLang）。如果一个 Mooncake Store 实例同时服务 vLLM 和 SGLang worker，KV 格式兼容性是未验证的。这不是技术细节——它是"KV Cache 基础设施"能否真正独立于推理引擎的根本问题。

五、多机集群部署的六大挑战

到这里为止的分析都停留在单实例或小集群视角。但生产推理集群是多机、多副本、跨交换层的。当 KV Cache 基础设施部署到真实的多机集群时，六个硬问题会同时爆发。

挑战一：拓扑感知——KV Cache 放在哪台机器

一个典型的 PD 分离推理集群：P 集群（Prefill）8-32 台 GPU 服务器，D 集群（Decode）16-64 台。网络走 Spine-Leaf 或 Fat-Tree。

KV Cache 从 P 节点产生，需要被 D 节点消费。P 有 32 台，D 有 64 台——哪个 P 的 KV 要送到哪个 D？

拓扑代价量化： 假设 P 节点和 KV 池在同一 Leaf 下，RTT ~1μs，带宽 400 Gbps（50 GB/s）。跨 Spine：RTT ~3-5μs，带宽被 spine 收敛比限制（可能 100-200 Gbps）。128K 上下文的 KV Cache 约 10-25 GB，同一 Leaf 下传输需要 0.2-0.5 秒，跨 Spine 需要 0.5-2.5 秒。

cache 有价值的物理条件： 传输延迟 < prefill 重算时间。对 128K 上下文，prefill 重算约 2-5 秒（取决于 GPU 型号和模型大小）。跨 Spine 取 KV 花 1 秒 → 有价值（比重算快）。对 4K 短上下文，prefill 重算约 30-50ms → 跨 Leaf 取 KV 花 100ms 就不如重算了。

核心问题： 一个拓扑无感的 KV Cache 池会把同一个 session 的 KV 散到整个集群。Mooncake Conductor 在论文中试图解决但还在 RFC。LMCache MP 目前不做拓扑感知。

挑战二：一致性——多轮 agentic 的 session 迁移竞态

多轮 agentic 场景：Round 1 在 D#7 上 decode，Round 2 调度器把请求迁移到 D#12（因为 D#7 负载高了）。D#7 写回的 Round 2 KV 可能还没 flush 完，D#12 就开始读了。

读到不完整 KV 的后果：模型在不完整的 attention 状态上生成 token，输出质量不可预测。

当前方案：LMCache 用 LRU + 异步写入，一致性保证弱——cache miss 时回退到重算 prefill，正确性靠"重算"兜底。Mooncake Store 用 master 做版本管理，但 consistency model 在论文里没有详细描述。

需要的是 session-scoped 的 read-after-write consistency——同一个 session 内保证读到最新 KV，不同 session 之间可以放松。这不是全局强一致性（太重），也不是 eventual consistency（太弱）。

挑战三：故障域——KV 池挂了怎么办

独立 KV Cache 池成为推理链路的关键依赖后，它的可用性直接影响推理服务。

故障后果推算： 假设集群平时依赖 90% 的 cache 命中率（典型 agentic 场景），KV 池故障导致命中率跌到 0%。Prefill 集群的负载 = 原来 10% 的 prefill 工作 + 重新承接另外 90% 的 prefill → 负载暴增 10 倍。如果命中率是 94.2%（Codex 实测），负载暴增 17 倍。P 集群没有 10-17 倍的冗余算力，直接排队或拒绝服务。

冗余成本： KV Cache 池需要副本。1000 并发 session × 50GB KV/session = 50TB 池总量，三副本 150TB 内存/SSD。

降级而非恢复： KV Cache 丢失的代价是重算 prefill（数秒），不是数据丢失。所以故障恢复策略可以是"降级"——池挂了，回退到无 cache 模式。但前提是 P 集群有冗余算力消化突发 prefill。如果没有冗余，故障会级联。

挑战四：网络带宽经济——传输 vs 重算的成本交叉点

带宽需求算例： 128K 上下文 × 1000 QPS 的集群。每个 prefill 产生 ~25GB KV Cache（FP8）。如果 cache miss，1000 个 prefill/秒产生 25 TB/s 的 KV 传输需求。在 400 Gbps（50 GB/s）InfiniBand NDR 上，需要 500 条链路才能消化——物理不可能。

成本交叉点分析：

cache 命中率的盈亏平衡点取决于三个变量：

1. 重算成本 = prefill 的 GPU 计算时间 × GPU 小时价格
2. 传输成本 = KV block 大小 × 网络传输时间（含排队）
3. 存储成本 = KV block 占用的存储空间 × 存储单价 × 存活时间

以 128K 上下文、H100 GPU（$2.5/小时）、400Gbps 网络为例：

• 单次 prefill 重算：~3 秒 × $2.5/3600 ≈ $0.002/请求
• 单次 KV 传输（25GB / 50GB/s）：~0.5 秒，网络分摊成本 ≈ $0.0003/请求（基于网络设备成本摊销估算）
• KV 存储（25GB × DRAM $3/GB/月 × 60 秒存活）：25 × ($3 ÷ (30×24×3600)) × 60 ≈ $0.0017/请求

传输 + 存储成本 ($0.002) ≈ 重算成本 ($0.002)——成本趋同。 这意味着 cache 的经济价值不在于单次请求的成本差，而在于命中率。当命中率高时，存储成本被大量命中请求均摊（每个 session 只存一份 KV，被多个请求复用），单次命中分摊的存储成本远低于 $0.0017。当命中率低时，存储成本无法被有效均摊。

盈亏平衡点约在 50% 命中率。 高于 50%，cache 的均摊成本低于重算，有价值。低于 50%，不如直接重算。agentic 场景实测 94.2% 命中率远超平衡点——cache 有巨大经济价值。但短上下文场景命中率可能低于 50%，cache 的经济性需要具体分析。

这个分析对架构选择有直接影响：长上下文 + 高并发 + agentic 多轮场景，命中率高，cache 价值大。短上下文、低并发的场景，cache 的经济性存疑。KV Cache 基础设施的目标市场是长上下文 + 高并发的推理场景。

挑战五：版本生命周期——模型更新时 KV 全失效

模型更新（微调、权重更新、架构调整）→ 之前版本生成的 KV Cache 无法使用。不同模型的 attention head 数、layer 数、hidden dim 都可能不同。

更微妙的是，同一模型的不同 checkpoint（微调后），KV Cache 技术上可复用，但语义上可能不一致——微调后模型的 attention 模式可能变了，旧 KV Cache 的 attention 状态不再准确。长上下文场景下可能导致质量退化。

KV Cache 是版本绑定的临时数据，不是持久资产。 每次模型更新，整个 KV Cache 池需要失效重建。这与存储产品的"持久化"价值主张冲突。正确的运维策略是灰度更新——新请求用新模型生成 KV，旧 KV 自然过期淘汰，不做全量失效。

挑战六：可信边界——多租户共享的物理隔离

KV Cache 是用户与模型对话的完整上下文——包含 prompt、对话历史、工具调用结果。在多租户共享 KV Cache 池的场景下，"租户 A 能不能看到租户 B 的 KV block"不只是配额问题，是数据安全问题。

侧信道风险： 共享内存池中，攻击者理论上可以通过测量 cache 访问时间推断其他租户的 KV block 访问模式——cache timing side-channel。Mooncake 的租户配额机制限制了存储空间分配，但不阻止物理层面的时序观测。

TEE 的局限： GPU 侧的 TEE（如 NVIDIA Confidential Computing H100）保护 GPU 内部计算，但 KV Cache 一旦卸载到 CPU DRAM 或外部存储池，就离开了 TEE 保护范围。被卸载的 KV block 需要自己的加密/隔离机制。

当前空白： 没有任何 KV Cache 基础设施产品提供硬件级的跨租户隔离。Mooncake 的租户配额是软件层面的逻辑隔离。如果 KV Cache 真的要成为跨租户共享的基础设施层——像云上的对象存储一样被不同客户信任——可信边界必须从软件逻辑隔离进化到物理级保证。

六大挑战的共同指向

这六个挑战的共同根源指向同一个方向：当前的计算-内存架构假设——GPU 做所有计算，PCIe/网络做所有连接，软件管理所有层级——已经被 KV Cache 的需求压穿。 纯软件方案可以缓解但无法根本解决。每一次 load/store KV block 都要经过软件管理的内存层次，每一跳都增加延迟和不确定性。

这个问题的根本解需要在硬件层重新思考 memory hierarchy 中 KV Cache 的位置。

六、从工作负载推演理想硬件

这是全文技术含量最高的一章。方法论：从第二章的物理特征和第五章的六大挑战出发，推导硬件应该提供什么能力，排除不合适的方案，推演理想形态。

方法论边界声明： 本章中，NVIDIA AFD、Groq 3 LPU 规格、Mooncake benchmark 数据是已公开的事实。KV Memory Node、GPU 端 KV Cache Controller、Memory Fabric 是本文基于物理约束推演的设计空间——不是产品预测，是架构方向分析。

6.1 先排除 CXL/PCIe 路径

CXL 看起来是一个自然选择：开放标准、cache-coherent、memory disaggregation 的成熟 spec。在分析它适不适合 KV Cache 之前，先承认它的优点：

CXL 的理论优势： Type-3 设备（memory expander）的 cache coherence 语义跟 KV Cache 的 write-once 特征天然匹配——KV block 写一次后很少修改，Type-3 设备的 coherence 开销（snoop 等）对这种 workload 几乎为零。CXL 4.0 提供 128 GT/s 带宽和 pool 化能力。Samsung CMM-D 实测性能接近 DRAM。

但 CXL 建立在 PCIe 物理层之上，这个基因决定了三个天花板：

天花板一：延迟。 CXL 3.0 端到端延迟 ~200-500ns（含 PCIe TLP 封装/解封装、CXL flit 处理、switch 转发）。对比 HBM ~10ns、NVLink ~50ns。Decode 热路径上每个 token 需要 80 次 attention 层的 KV 读取（80 层模型），CXL 的延迟在单次 decode step 中累积：80 × 300ns ≈ 24μs。对 decode step（20-50ms）占 0.05-0.1%——单次可接受，但高并发下有感。

天花板二：协议语义。 CXL 是 cache-line 级（64B）的 coherence。KV block 是 MB 级的（2.5-40MB）。用 cache-line coherence 管理 MB 级数据，相当于用显微镜搬砖——工具的粒度跟任务的粒度不匹配。大量 coherence protocol overhead 用在了不需要的地方。

天花板三：交换层次。 CXL 走 PCIe switch 层次。CXL 3.0 的 Fabric Manager 允许 port-based routing 部分绕开传统交换机，但每个 CXL hop 的 flit 处理延迟（~50ns/hop）仍然存在。与 NVLink bridge 的零 hop 直连相比，多跳场景仍然积累延迟。KV Cache 的带宽需求需要无交换层次的直连互联——类似 NVLink bridge 模式（GPU-to-GPU 直连）。PCIe 的交换架构是 IO 设备的范式，不是 memory 的范式。

结论：CXL 不适合作为 KV Cache 的 hot tier 互联。 它可以在 cold tier（跨域共享、低频访问的 KV block）有一席之地，但 decode 热路径上的 KV Cache 需要的是 NVLink 级的延迟和带宽，不是 PCIe 级的。

6.2 从物理特征推演硬件需求

第二章定义了 KV Cache 的六个物理特征。每个特征推导出一个硬件需求：

物理特征 → 硬件需求 1：block 级寻址（2.5-40MB 粒度）

KV block 是 MB 级，不需要 cache line（64B）粒度的 coherence，也不需要文件系统 inode。需要的是 以 block 为单位的内容寻址机制——给 block 一个 ID（token prefix hash），硬件直接定位物理位置。

软件做这件事的代价：hash → metadata table lookup → 物理地址 → DMA 传输，三次间接。100 万个 KV block 的索引需要数 GB 内存。如果 memory controller 硬件理解 block 语义，单次访问定位——类似 CAM 但工作在 MB 级粒度。

物理特征 → 硬件需求 2：write-once coherence

KV Cache 的 99% block 是 write-once-read-many。标准 MESI/MOESI coherence 协议为每个 cache line 维护状态（Modified/Exclusive/Shared/Invalid），因为 CPU 多核场景下 cache line 可能被任意修改。为 write-once 数据维护 MESI 状态是纯粹浪费。

需要的是 分区 coherence 模型：写入中的 block 获取 exclusive（防读到不完整数据），写完后降级为 read-only shared，之后不再跟踪。软件通过 hint（block header 的 done bit）告诉硬件切换状态。这比标准 coherence 轻一个数量级。

物理特征 → 硬件需求 3：带宽独立扩展

400 TB/s 的 KV Cache 读取带宽需求，不可能靠加 GPU 来满足——加 GPU 也加算力（和成本）。KV Cache 不需要更多算力，只需要更多带宽来读取它。

需要的是 memory-only 物理节点——没有 GPU，只有大量高带宽内存 + 高带宽互联接口。纯带宽/容量节点，不带算力。

物理特征 → 硬件需求 4：session-scoped 一致性域

标准分布式系统的全局一致性太重。跨 session 不需要一致性。需要的是 hardware-enforced 的 session affinity——同一 session 的 KV block 物理聚集到同一个一致性域，域内保证 read-after-write，域间无 coherence 开销。

软件靠调度器做 best-effort 的 session affinity，但负载不均时 session 会被迁移。硬件 partition 能保证即使在迁移过程中一致性也由 hardware mechanism 保证。

物理特征 → 硬件需求 5：嵌入式版本控制

模型更新 → KV Cache 全失效。如果 memory controller 在 block header 嵌入 model_id，cache lookup 时硬件自动过滤不兼容版本——不增加软件开销。不兼容 block 在下次写入时自动回收。

很小的硬件改动（block header 加几个 bit），但消除了软件层面的 race condition。

6.3 推演出的硬件形态

五个硬件需求指向一个完整的硬件系统：

组件 A：KV Memory Node（新增数据中心节点类型）

不是 GPU 节点（不计算），不是 CPU 节点（不调度），不是存储节点（不做持久化）。一种新类型：

• 大容量高带宽内存：TB 级 DRAM，带宽目标 50-100 TB/s per node
• KV-aware memory controller：理解 block 语义，content-addressed lookup，write-once coherence，model_id 过滤
• 内置压缩引擎：FP8/INT4 或自定义压缩，减少带宽压力
• 高带宽互联接口：到 GPU 节点链路 ≥ 1 TB/s，NVLink 级延迟（~50-100ns）
• 独立故障域：独立供电、散热、管理平面
• Session partition：硬件支持把内存分为多个逻辑一致性域

物理形态：1U-2U 机架式设备，前面板全是内存模块，没有 GPU。通过高带宽 memory-semantic fabric 连到同机架的 GPU 节点。

组件 B：GPU 端 KV Cache Controller（GPU silicon 内部模块）

介于 GPU memory controller 和 NVLink controller 之间的新模块：

• 异步 prefetch engine：decode 需要某个 KV block 之前，提前从 KV Memory Node 预取到 HBM
• write-back buffer：prefill 完成后 KV block 先进 buffer，异步刷到 KV Memory Node，不阻塞推理 pipeline
• coherence partition manager：管理本 GPU 上活跃 session 的 coherence state，跟 KV Memory Node 协调

组件 C：Memory Fabric（互联层）

KV Memory Node 跟 GPU 节点之间的物理互联。不是 PCIe/CXL，而是 memory-semantic 直连：

• 延迟 ≤ 100ns（接近 NVLink，远优于 CXL/PCIe）
• 每链路带宽 ≥ 1 TB/s
• 多端口：一个 KV Memory Node 同时连 4-8 个 GPU 节点
• Partition 能力：fabric switch 支持端口分组为多个 coherence partition

物理实现候选：NVLink 扩展（NVIDIA 控制标准，已有 Grace CPU + GPU 互联经验），或定制 memory fabric。不走 PCIe。

6.4 AFD 与 KV Cache 的带宽经济学

NVIDIA 的 AFD（Attention-FFN Disaggregation）需要在这章里定位——它不是 KV Cache 的直接解决方案，但改变了 KV Cache 的带宽经济学。

不做 AFD 时 decode 的带宽竞争： decode 每 token，GPU HBM 带宽被 KV Cache 读取和 FFN 权重读取分摊。两者争抢同一条管道——这是"decode 带宽墙"。

软件缓解手段及其天花板：

• 大 batch：FFN 权重被 batch 内 token 分摊 → 但 KV Cache 容量压力爆发
• GQA：KV Cache 压缩 → 已经是标配，增量有限
• FP8 KV Cache：带宽减半 → 可用但不是质变
• 投机解码：2-3× 加速 → 不改变架构瓶颈
• HBM 带宽增长：H100→Rubin 提升 ~6.5× → 被上下文增长（4K→128K = 32×）吃掉

软件路径可以推迟带宽墙 3-5 倍，但不能拆除它。

做 AFD 后： LPU 的 SRAM（~500MB，150 TB/s）承担 FFN 计算。GPU 的 HBM 带宽不再被 FFN 权重占用，几乎全部给 KV Cache。KV Cache 的有效带宽提升 2-3 倍（取决于 FFN 在原来带宽中占多少份额）。

但 AFD 放大了 KV Cache 卸载需求——decode 更快 → 单 GPU 更多并发 → 更大 KV Cache footprint → 更依赖外部存储池。AFD 优化 compute 侧效率，KV Cache 基础设施优化 storage/transfer 侧容量。两者互补，不可互相替代。

AFD 只对 MoE 模型有效——利用 Expert All-to-All 通信通道传输激活值。稠密模型 AFD 通信开销太大。这意味着 AFD 的价值取决于模型架构趋势。

6.5 硬件介质分级

排除 CXL 后的介质分级：

每级延迟差 10-50×，物理决定。HBM 到 RDMA 之间 100 倍的空白正是 NVLink Memory Node 需要填补的。 CXL 原本想填补这个空白，但 PCIe 物理层的延迟和交换层次决定了它只能落在 HBM 和 RDMA 之间的偏 RDMA 侧——不够接近 GPU 的热路径。

6.6 结论：KV Cache 是 memory hierarchy management 问题

KV Cache 的特征（block 级粒度、write-once、session-scoped 一致性、秒级生命周期、带宽密集）更像 CPU 的 L1/L2/L3 cache → DRAM → swap 层级管理，而不是分布式存储。

历史上 memory hierarchy management 从来是软硬件协同的——CPU cache line 大小、TLB 结构、NUMA affinity 都是硬件定义机制、软件优化策略。KV Cache 很可能走同一条路：今天全靠软件（LMCache/Mooncake），未来硬件提供 block 级寻址和 session partition，软件退化为策略层。

七、竞争格局：三足鼎立

从硬件推演回到现实——当前所有玩家都还在做软件。但第六章的分析告诉我们，这个领域的终局是软硬件协同。哪些玩家有入场券？

路线一：引擎内嵌（llm-d / vLLM native）。 KV cache 作为引擎的 OffloadingConnector 模块。llm-d 进入 CNCF Sandbox，K8s 原生。局限：跨实例 cache 受限于调度范围，存储计算扩缩绑定。

路线二：独立缓存系统（LMCache / Mooncake）。 LMCache 独立守护进程 + Mooncake 分布式 KV 池。2025 年 5 月宣布战略合作。优势：存储计算解耦。局限：额外序列化开销，跨项目协调。

路线三：GPU 厂商主导（NVIDIA Dynamo / KVBM / NIXL）。 Dynamo 编排层 + KVBM 内置缓存 + NIXL 传输 + DDN/VAST 存储插件。NVIDIA 控制全栈。如果第六章推演的 NVLink Memory Node 是正确方向，只有 NVIDIA 能做（控制 NVLink 标准）。

谁会赢：

• 单集群、NVIDIA 硬件：Dynamo + KVBM。NVIDIA 控制全栈，第三方空间被压缩
• 混合硬件、AMD/Intel：Mooncake + LMCache。跨硬件传输层
• K8s 原生：llm-d。CNCF 背书，但缺独立传输层
• 跨集群/跨云：文件系统路径。RDMA 受限网络拓扑，POSIX 天然跨域

存储厂商的角色： DDN 从独立售卖产品变成 NIXL 默认插件。VAST Data 联合 CoreWeave 证明存储厂商在 KV Cache 层可创造可量化价值（GPU 效率 +90%，TTFT 缩短 20×）。KV Cache 存储不会成为独立品类，但会改变存储阵列选型标准——超低尾延迟和 KV 级小 IO 性能成为推理场景硬指标。

八、路由层的进化

KV 感知路由在六周内完成了三代跳跃：

第一代：hash 亲和性。 GKE/llm-d 的基本模式——hash token prefix，查哪个 replica 有 cache。简单可预测，不感知负载。

第二代：prefix tree + 负载感知。 Ray 2.56.0——负载均衡时走前缀树，不均时退化为 Power of Two Choices。

第三代：ML 预测路由。 GKE predicted-latency-based routing——XGBoost 实时预测 TTFT/TPOT，结合 prefix-cache-affinity filter。意义不在于"用了 ML"，而在于目标函数从"cache 命中率"变成了"预测延迟"。两者在大多数时候一致，但在负载不均或硬件异构时会分离。ML 路由处理分离，规则路由不能。

ML 路由的代价：需要训练数据（冷启动差）、预测 server 额外延迟、模型漂移风险。

九、验证过的性能数字

• 46 倍 TTFT 缩短来自 agentic trace 测试（prefix-heavy 特性放大 KV 复用收益）
• VAST 的 20× 和 Mooncake 的 46× baseline 不同，不矛盾
• llm-d 的 40% baseline 是已优化过的 vLLM 部署

十、架构推演结论

短期（1-2 年）：纯软件产品

LMCache/Mooncake/Dynamo 的软件组合覆盖分级存储和路由。六大集群挑战靠软件尽力补：拓扑感知靠调度器、一致性靠版本控制、故障靠降级、带宽靠 cost model、版本靠 model_id 标记、可信边界靠软件逻辑隔离。

AFD 在 Vera Rubin 上落地，改变 decode 带宽经济学——GPU HBM 带宽更多给 KV Cache，但 KV Cache footprint 同时增大。AFD 优化 compute 侧，KV Cache 基础设施优化 storage/transfer 侧，两者互补。

这个阶段的 KV Cache 产品是纯软件——运行在现有硬件的内存层次上（HBM → DRAM → NVMe → 网络）。

中期（3-5 年）：NVLink-attached Memory Node 出现

触发条件：万 GPU 级推理集群 + agentic 负载主流 + 软件 metadata 开销和一致性延迟成为可测量瓶颈。

NVIDIA 最有可能走这条路——控制 NVLink 标准 + GPU 设计 + NVLink Switch。NVLink Memory Node 不需要 GPU，只需要大量高带宽内存 + NVLink 端口 + 基础 KV block 管理。GPU 通过 NVLink 直接读取，延迟 ~50-100ns，带宽跟 GPU-to-GPU 互联一个量级。

软件 control plane 不需要大改（还是分级存储 + 路由），但 HBM 到 RDMA 之间的 100 倍延迟空白被 NVLink Memory Node 填补。一致性在 NVLink 域内由硬件保证，域间由软件管理。

长期（5 年+）：KV-aware 硬件成熟

block 级 content addressing、write-once coherence、session-scoped partition 进入硬件标准。KV Cache "产品"退化为 control plane——做跨层 cost-optimized placement 决策（什么时候放 HBM、什么时候推 NVLink Memory、什么时候卸载到 RDMA、什么时候重算）。data plane 由硬件接管。

最有力的证明将来自训练→推理的 KV Cache 穿越——如果一份 KV 可以在训练 checkpoint 保存后直接部署给推理使用，KV Cache 才真正从引擎临时状态变成了持久化资产。目前这条路径没有任何产品级实现，但它定义了"基础设施化"的天花板。

最终判断：KV Cache 基础设施会像 NUMA 一样——软件定义策略，硬件提供机制。 但 2026-2028 年它还是软件产品。硬件协同要等推理集群规模和 agentic 负载把软件方案逼到物理极限。

检验点

1. Mooncake Conductor 的调度逻辑是否被其他项目吸收？ 关注到 2026 年底，Conductor 的 prefill+decode 配对和 KV 池布局优化是否出现在 Dynamo 或 llm-d 中。

2. LMCache 是否引入自己的调度组件？ 目前是"独立存储 + 引擎自带调度"。如果开始做调度，说明独立派认为路由必须脱离引擎。

3. NIXL 插件生态扩展速度。 到 2026 年底，VAST Data/NetApp/Pure Storage 中有 2 家以上成为原生插件，说明 NVIDIA 的"存储厂商集成"策略在快速复制。

4. AFD 在生产环境中的实际表现。 Vera Rubin NVL72 + LPX 在 2026 Q3-Q4 大规模交付后，attention（GPU）与 FFN（LPU）之间的 hidden state 传输开销成为可测量指标。如果传输开销不成为关键瓶颈，AFD 改善 KV Cache 有效带宽的价值被验证。

---

数据来源与声明： 本文基于公开信息撰写，综合参考了 vLLM 官方文档及 RFC #38260/#44223、Mooncake 论文（FAST 2025 Best Paper）及 GitHub 文档、LMCache 博客及学术论文（arXiv 2510.09665v2）、NVIDIA Dynamo/NIXL/Groq 3 LPX/Vera Rubin 官方文档及技术博客、DDN 及 VAST Data 官方博客、GKE Inference Gateway 文档、llm-d 项目文档及 CNCF 公告、Ray 2.56.0 release notes、Samsung CXL CMM-D 白皮书、Astera Labs Leo Memory 技术文档、CXL-SpecKV（arXiv 2512.11920）、Spheron Network 部署指南、SiliconANGLE RAISE Summit 2026 报道。不构成投资建议。文中数据截至 2026 年 7 月 12 日。