大模型推理正在陷入一场“隐形内存战争”。GPU显存不够用，但谁都不敢说自己不需要更多。
这背后的技术矛盾并不复杂。当一个大模型处理一段长文本或多轮对话时，它需要把每个已处理token的注意力键值对（即KV Cache）暂存在GPU显存里，避免每一步都重复计算。问题是，这个缓存会随着上下文长度线性增长。当模型处理一个128K token的上下文、batch size为4时，KV Cache要吃掉约81%的GPU显存。这是Dnotitia在STAR-KV论文中给出的基准数据，针对的是LLaMA-3.1-8B这个参数量并不算大的模型。企业级部署中，这个比例只会更高。
AWS和OPPO的工程团队最近给出了一套具体的解法。8月12日，AWS发布了一篇技术博客，详细介绍了如何在Amazon SageMaker HyperPod上，通过引入OPPO开源的分布式缓存文件系统Curvine，构建一个三层KV Cache架构，从GPU到CPU内存再到跨节点的共享NVMe池。在测试部署中，这套方案实现了最高100%的跨Pod缓存命中率，首token延迟（TTFT）最多提升2.7倍。跨节点L2读取延迟约56毫秒，处理的是约1,925个token的提示词。
这不是一个孤立的实验。它指向一个正在发生的行业转向：KV Cache正在从“每个推理副本各自为政”走向“共享、分层、持久化”。
三层缓存：从贵族到平民的显存经济学
要理解这套方案的价值，先得看清一个问题：为什么大模型推理这么贵？
答案很大程度上藏在KV Cache里。一个7B参数模型在bf16精度下，权重约占14GB显存，在48GB的GPU上还剩30GB以上的空间给KV Cache，看上去还算宽裕。但换成32B参数模型，权重就要吃掉约64GB，连一块48GB的GPU都放不下。即使通过张量并行分片到多卡，留给KV Cache的空间也急剧缩水。在高并发场景下，缓存很快就被填满，频繁驱逐，命中率断崖式下降。
更糟糕的是，传统部署方式下，每个vLLM推理副本维护着独立的缓存池。请求路由到不同副本，本质上就是一次“冷启动”，所有前缀都要重新计算，TTFT直接爆炸。
AWS和OPPO的方案把KV Cache从单机私有池变成了集群共享池，分三层来组织：
L0 即 GPU显存缓存。 这是vLLM原生paged-attention层，存储最热门的KV块，访问延迟最低。它的容量就是GPU扣除模型权重后剩下的空间。对于小模型，这层绰绰有余；大模型下，这层很快就会被撑满。
L1 即 CPU内存卸载。 当GPU块被驱逐时，LMCache在它们被丢弃前将其捕获到主机DRAM中。这由SageMaker HyperPod Inference Operator自动管理，只需在配置中设置enableL1Cache: true。它是Pod本地的，速度很快，但容量受限于单机内存。
L2 即 共享分布式NVMe池。 这是跨副本复用的关键。Curvine将集群中每个节点本地的NVMe硬盘（G6e/P5实例标配）池化成一个统一命名空间，通过FUSE客户端挂载为ReadWriteMany持久卷进入每个推理Pod。LMCache通过它的fs://连接器读写这个分布式池，对上层应用来说，就像在读写本地目录一样。
这套架构的核心逻辑很直白：把最热的数据留在GPU里，温数据放在CPU内存，冷数据放到NVMe池。但因为是共享的，所有副本都能访问。这就是“分层”的意义。
Curvine：从OPPO内部走出的分布式缓存
Curvine是这套架构中L2层的核心组件。它由OPPO大数据架构团队开发，创始人和维护者是OPPO大数据架构负责人David Fu（傅巍），核心开发者包括Zejun Lv、Long Jiang和Seanx。团队此前在阿里云和去哪儿网积累了多年的大数据和云计算基础设施经验。
Curvine本质上是一个轻量级分布式缓存文件系统，位于应用和底层存储（如S3、HDFS、NAS）之间。它通过CLI、SDK、FUSE和CSI四种方式暴露给客户端。Primary Nodes负责元数据，Workers提供数据服务，并利用本地磁盘缓存实现低延迟I/O。
在这次部署中，Curvine的技术细节颇为硬核：每个数据块在两个不同节点上分别保存一份副本（主副本加备份副本），通过哈希环进行分片，默认块大小为4MB。在NVMe上，它使用了PMDK、SPDK、io_uring等高性能I/O技术栈，数据路径走FUSE + RDMA。基准测试的数据印证了这套架构的可行性：同节点L2写入吞吐约9.6 GB/s，跨节点L2读取吞吐约1.8 GB/s。写入本地NVMe的路径仅需3到4毫秒，追加2,048个token的KV Cache（约109 MB）几乎不构成感知延迟。
智能路由：让缓存真正“有用”
但光有共享缓存还不够。如果请求被随机路由到没有缓存数据的副本，L2层再快也没用。
AWS的方案同时引入了智能路由（Intelligent Routing）。当请求到达时，路由层根据请求的文本前缀，计算其与各Pod缓存内容的Jaccard相似度，将有缓存命中概率最高的请求定向到对应的Pod。路由策略基于一致性哈希环，确保在Pod扩缩容时路由的稳定性。
这套机制的效果在基准测试中非常清晰。在1,000到2,500个token的提示词范围内，Pod B实现了100%的跨Pod缓存命中。Pod B从未预填充过这些请求，但通过共享L2层，它直接读取了Pod A写入的缓存。冷启动时774毫秒的请求，在缓存命中后仅需287毫秒完成。超过3,000个token时，相对加速比回落到2.2倍，但绝对节省反而更大，每请求节省490毫秒。
这是一个典型的“分层正确”的故事：短提示词（500个token以下）在L0/L1层命中，L2来回的代价和重新计算差不多；中等提示词（1,000到2,500 token）获得最大加速比；长提示词（3,000 token以上）虽然相对加速比下降，但绝对节省最大。智能路由的作用就是让每个请求尽可能落在它最该落的那一层。
从NVIDIA到Google：一场围绕KV Cache的“军备竞赛”
Curvine加SageMaker HyperPod方案并非孤例。2026年以来，KV Cache的优化已经成为AI基础设施领域最拥挤的赛道之一。
NVIDIA在CES 2026上发布了Inference Context Memory Storage Platform（ICMSP，后更名为CMX），将GPU KV Cache延伸到NVMe存储，构建了四层缓存层级，背后有NVMe存储合作伙伴组成的生态。到了GTC 2026，NVIDIA又推出了STX参考架构，进一步把KV Cache的持久化和共享化推向新高度。
Google则在ICLR 2026上推出了TurboQuant，通过更激进的量化压缩KV Cache来缓解显存压力。Dnotitia的STAR-KV在ICML 2026上获得了Spotlight论文（占全部投稿的约2.2%，占被接收论文的约8.4%），实现了高达20倍的KV Cache压缩，同时将注意力计算速度提升最高6.9倍。
Red Hat在其分布式AI推理部署指南中讨论了“解耦的KV Cache池”模式，Mooncake等开源项目也在探索将KV Cache从vLLM实例中独立出来的架构。
各路玩家从不同方向切入同一个问题：GPU显存不够用，而KV Cache正在成为大模型推理的“阿克琉斯之踵”。
怎么看？
从技术演进的角度看，分层KV Cache正在从“锦上添花”变成“必选项”。
原因很简单：模型的上下文窗口在持续扩张。从最初的4K、8K，到现在的128K、1M，长上下文已经出现在前沿模型中。而Agent、RAG、多轮对话等应用场景对长上下文的需求只会越来越强。KV Cache的规模增长是指数级的，而GPU显存的增长是线性的。这个剪刀差，终将迫使每一家部署大模型的企业重新思考推理架构。
从商业竞争的角度看，Curvine这类开源方案提供了另一种选择。NVIDIA的CMX是封闭生态的一部分，依赖其NVMe存储合作伙伴。Google的TurboQuant是方法论层面的优化。而Curvine加SageMaker HyperPod的组合，是一个可落地、可复现、开源的工程方案。它不需要特殊的硬件，不需要厂商锁定的软件栈，只需要AWS已有的G6e实例和OPPO开源的Curvine。对于已经在AWS上部署推理业务的企业来说，这是一个成本可控的升级路径。这套架构让原本需要P5实例的负载可以运行在成本更低的G6e实例上，具体节省幅度取决于模型大小和流量分布。
当然，这套方案也有其局限。它依赖于NVMe本地盘，对于使用EBS作为存储的实例并不适用。Curvine本身是一个较新的项目，生产环境的成熟度还需要时间验证。跨节点L2读取延迟56毫秒，虽然远低于跨网络重新计算的代价，但和GPU本地的纳秒级延迟相比，差距仍然巨大。在500个token以下的短提示词场景中，L2层的性价比甚至不如直接重新计算。
但方向是明确的。大模型推理的“内存战争”已经打响，而KV Cache的分层、共享和持久化，正在成为新的行业标准。对于每一家部署大模型的企业来说，现在开始思考自己的缓存架构，可能比焦虑下一个模型参数更大，要实际得多。
在这场战争中，赢家不一定是最能烧钱买GPU的那一个，而是最能用好每一GB显存、每一块NVMe硬盘的那一个。
快报