如今，通过互联网传输 KV cache，已经可能比重新计算它更快、更便宜。以上下文约 100,000 个 token 的 DeepSeek-V4-Pro 为例，压缩后的 KV cache 约为 1 GB。在满负载的 10 Gbps 链路上传输它大约需要 0.8 秒，按 AWS 出站流量（egress）计费约 0.09 美元；而在 AWS 8×B200 集群上重新计算它，大约需要 15 秒，成本为 0.47 美元。
芝加哥大学的 Siddhant Ray、Nick Feamster 和 Junchen Jiang 于 2026 年 8 月 2 日在 arXiv 上发表了论文《An Internet for the KV Cache: Rethinking Classical Infrastructure Boundaries in the LLM Inference Age》（《KV Cache 的互联网：在 LLM 推理时代重新思考传统基础设施边界》）。论文提出构建一张“KV cache 的互联网”：一种把已缓存的推理状态视为待分发内容的基础设施，在不同存储层级、地域（region）和云服务商之间放置与迁移这些状态。目前，这类状态大多停留在单个服务系统、数据中心或云平台内部。Agent、检索、工具调用和多轮对话会一次又一次地访问相互重叠的上下文，因此无论下一个请求在哪里运行，复用对应的 KV cache 都能省去 prefill 计算。
存储还是重算，并没有唯一的答案。模型架构、基础设施的价格，以及应用在复用上下文之前要等待多久，三者共同决定了结果。本文改编自该论文，将解释这一取舍，以及还有哪些部分有待构建。
为什么现在要重新审视基础设施？
有三个方向正在改变推理的经济性：
- 模型优化：例如混合专家（mixture-of-experts，MoE）执行和稀疏注意力（sparse attention），减少了推理所需的计算量，或需要访问的历史状态。
- KV cache 优化：融合（blending）与编辑扩大了复用范围，压缩缩小了缓存状态的体积，内存压缩整理（memory compaction）则减少了需要保留的上下文。
- 系统优化：例如 prefill–decode（P/D）分离、调度、卸载（offloading）以及更快的互连，提升了 GPU、CPU、存储和网络各层级之间的利用率与数据迁移效率。LMCache 为这种迁移提供了基础构件（building blocks）。
对于 100,000 个 token，借助 DeepSeek-V4-Pro 的压缩缓存格式，KV cache 从 DeepSeek-V3.2 的 9 GB 缩小到 1 GB，缩减约 9 倍。在算力方面，NVIDIA Rubin 提供 50 PFLOPS 的 NVFP4 推理算力，而 Blackwell Ultra 为 15 PFLOPS，提升了 3.3 倍。
这些进展同时改变了决策的两端：计算 KV cache 的成本，以及存储和迁移它的成本。基础设施需要把这两方面放在一起统筹决策。
何时传输上下文优于重新计算
开篇的例子使用的是 DeepSeek-V4-Pro（1.6T-A49B：总参数约 1.6 万亿，激活参数 490 亿），其全精度、压缩后的 KV cache 在约 100,000 个 token 时占用约 1 GB。传输数据假设互联网链路为满负载的 10 Gbps，并按 AWS 互联网出站流量费率计算；重算数据假设使用 AWS 8×B200 集群。在这些假设下，传输约快 19 倍，成本约低 5.2 倍。
这一比较对照的是传输时间与出站流量成本，以及 prefill 时间与计算成本；存储成本则属于下文更全面的决策的一部分。传输定价和 GPU 定价决定了其中的经济性。本文中的 AWS 价格来自论文的分析，仅作示例说明，并非对任何服务商或配置的推荐，也不代表任何受支持的 LMCache 部署方式。
对于在工具调用之间反复访问上下文的 agent 来说，距离下一次复用之间的这段时间，正好提供了在需要之前预先获取（prefetch）状态的机会。
KV cache 成为共享的推理资源
KV cache 代表了模型在生成过程中可以使用的上下文。让这种表示保持可用，服务系统就能在不同请求和工作流之间复用已经完成的计算。
这一视角与 LMCache 此前的文章 《Stop Calling It KV Cache: It’s Something Much Bigger》（《别再只叫它 KV Cache：它远不止于此》）一脉相承。KV cache 正在成为一种存储、通信与调度原语（primitive），LMCache、TensorRT-LLM、llm-d 和 NVIDIA Dynamo 等系统都已提供了这种能力的一部分。
存储还是重算？正确答案不止一个
这一决策比较的是 CacheCost（存储和传输可复用状态的成本）与 PrefillCost（重新计算它的成本）。
在盈亏平衡点（break-even）上，两个比值相等。模型侧比值是 prefill 计算量除以 KV cache 大小。基础设施侧比值是存储与传输成本相对于 GPU 计算成本的比值，其中也包含了应用的复用时机。当基础设施侧比值低于模型侧比值时，存储更便宜；因此，更换模型、服务商，或改变距下次复用的时间，都可能改变决策结果。
| # | 模型 | 基础设施 | 复用间隔（K） | 基础设施侧比值 | 模型侧比值 | 结论 |
|---|---|---|---|---|---|---|
| 1 | DeepSeek-V4-Pro | AWS B200 + S3 存储桶 | 1 天 | 0.436 | 11.410 | 存储更便宜 |
| 2 | DeepSeek-V4-Pro | AWS B200 + S3 存储桶 | 1 个月 | 13.083 | 11.410 | 重算更便宜 |
| 3 | DeepSeek-V4-Pro | GCP B200 + GCS | 1 天 | 0.670 | 11.410 | 存储更便宜 |
| 4 | DeepSeek-V4-Pro | Azure B200 + Blob Hot LRS | 1 个月 | 5.512 | 11.410 | 存储更便宜 |
| 5 | DeepSeek-V4-Pro | GMI B200 + 高配存储 | 1 天 | 20.250 | 11.410 | 重算更便宜 |
| 6 | DeepSeek-V4-Flash | AWS B200 + S3 存储桶 | 1 天 | 0.436 | 4.325 | 存储更便宜 |
| 7 | DeepSeek-V4-Flash | AWS B200 + S3 存储桶 | 1 个月 | 13.083 | 4.325 | 重算更便宜 |
表 1：不同模型、基础设施与复用设置下的存储与重算对比。来源：Ray、Feamster 和 Jiang，arXiv:2608.01526v1，表 1。
对于 AWS 上的 DeepSeek-V4-Pro，复用间隔从一天变为一个月，结论就会反转。而在一个月的间隔下，换成 Azure 配置，结论又会再次反转。部分重算（partial recomputation）和融合（blending）则在这两个极端之间提供了更多选择。
让代价高昂的 miss 更少发生
前缀缓存（prefix caching）能捕获完全相同的共享前缀，但输入一旦发生变化，后续的缓存状态就可能无法复用。即使命中率很高，也可能掩盖代价高昂的长上下文 miss。
降低 miss 的频率和代价同样重要。借助 CacheBlend 和 Cache-Craft 等技术复用非前缀片段（chunk），可以扩大可复用上下文的范围，包括检索到的片段以不同顺序出现的情况。
为下一代工作负载做好准备
运行时间更长、彼此互联的 agent，将需要跨工作流、跨环境地获取上下文。互联网视频分发提供了一个有益的类比：分发基础设施的进步，能够催生出日后大规模依赖它的应用。
KV cache 的互联网
当今的云边界决定了数据放置
云架构和定价机制都鼓励把存储放在计算附近。地域（region）和可用区（availability zone）边界会影响延迟和传输费用，AWS 传输成本概览和 Google Cloud 网络定价都说明了这一点。
SkyPilot 和 SkyServe 等系统让计算资源的放置更加灵活。而 KV cache 的分发还需要细粒度的状态发现、预取（prefetching）以及重算兜底（recomputation fallback）。
随处存储，随处使用
该架构设想根据预期需求，在不同存储层级、地域和服务商之间放置与迁移 KV cache。
Agent 工作流带来了有用的灵活性：一段上下文可能在几秒、几分钟或几小时后被复用。很快就要用到的状态可以留在 GPU 附近；较晚才会用到的状态则可以迁移到更便宜、更远的存储上，并在复用之前预取回来。
控制平面（control plane）负责发现可用状态、估算带宽和交付截止时间，并决定是传输、复制、部分获取还是重算这些状态。如果交付变得过慢或成本过高，系统可以转而重算，并更新其放置策略。
网络由此成为推理决策的一项输入：带宽、延迟、拥塞和价格共同决定哪种操作最优。
还有哪些需要构建？
要实现这一架构，需要在三个方面取得进展：
- 网络感知的数据迁移：需要让传输成本和延迟变得可见，并配备相应的传输与路由机制，使 KV cache 能够跨越基础设施边界、可预测地交付。
- 自适应基础设施与控制平面：需要整合发现、放置、压缩、预取、调度与重算。传输延迟或失败时，应触发平滑降级（graceful fallback）并调整放置策略。
- 服务商、监管方与用户之间的协调：需要明确所有权、定价、隐私、正确性以及故障责任的归属。类似互联网工程任务组（IETF）的标准化工作，将有助于形成可互操作的传输与安全协议，包括由用户掌控的存储。
展望
互联网规模的 KV cache 管理需要新的协议、抽象和控制平面。LMCache 及其他服务系统提供了有用的基础构件。要实现更宏大的愿景，则需要围绕复用来统筹计算、存储和网络。
核心主张：把可复用的推理状态放在存储、交付与重算三者综合起来最能满足工作负载成本和延迟需求的地方。
业界延伸阅读：Anthropic 的 prompt caching、借助 NVIDIA Dynamo 缓解 KV cache 瓶颈、Google Cloud 基于 Managed Lustre 的外部 KV cache，以及 AWS 结合 FSx for Lustre 与 TurboQuant 的 GPUDirect 方案。
本文改编自 Ray、Feamster 和 Jiang 的论文《An Internet for the KV Cache: Rethinking Classical Infrastructure Boundaries in the LLM Inference Age》（arXiv:2608.01526v1），采用 CC BY 4.0 许可协议。Siddhant Ray 是芝加哥大学的博士研究生。
