AWS 在 SageMaker HyperPod 上实现 LLM 分层 KV 缓存

AWS 在 Amazon SageMaker HyperPod 上推出了一套面向大模型推理的分层 KV 缓存架构，借助 Curvine 分布式缓存文件系统，把 KV 缓存从 GPU 显存延伸到 CPU 内存和跨节点共享 NVMe，解决长前缀场景下缓存命中率低、TTFT 退化的问题。测试数据显示，该方案可实现最高 100% 的跨 Pod 缓存命中率、约 2.7 倍的 TTFT 提升，以及约 56 毫秒的跨节点 L2 读取延迟。

背景：KV 缓存的两难

vLLM 在生成阶段把已处理 token 的 attention keys 和 values 保存在 KV 缓存中，避免每步重算；前缀缓存（prefix caching）则在此基础上复用共享前缀（如系统提示词）的缓存。然而在 G6e 等成本敏感实例（如 ml.g6e.4xlarge，单卡 48 GB）上，扣除模型权重和运行时分配后，留给前缀缓存的显存有限，且模型越大、并发越高越紧张。横向扩展的 vLLM 副本各自维护独立缓存，请求被路由到不同副本时相当于冷启动，重复的前缀会被反复预填充。

三层缓存架构设计

方案将缓存层级从单 Pod 内部扩展为三级：L0 为 GPU HBM、L1 为节点本地 CPU 内存、L2 为基于 Curvine 的跨节点共享 NVMe 池，并由缓存感知的请求路由层在副本之间调度请求。

L0：GPU 前缀缓存

这是 vLLM 原生的 paged-attention 层，存放最热的 KV block，访问延迟最低，但容量受限于扣除权重后的剩余显存。以 48 GB 单卡为例：7B 模型（bf16）约占用 14 GB 权重，L0 余量充足；32B 模型约需 64 GB 权重，单卡已放不下，即使分片后留给 KV 的空间也很小。这是把缓存扩展到 GPU 之外的根本动机。

L1：CPU 内存卸载

GPU block 被驱逐时由 LMCache 在宿主 DRAM 中接管，作为 Pod 本地的安全网，速度快、容量可通过 InferenceEndpointConfig CRD 中的 enableL1Cache: true 和 InstanceMemoryAllocationPercentage（建议从 20% 起步）配置。

L2：共享分布式 NVMe 池

Curvine 把 G6e/P5 实例自带的本地 NVMe 盘聚合成单一命名空间，通过 FUSE 客户端以 ReadWriteMany PVC 挂载到每个推理 Pod。LMCache 通过 fs:// 连接器读写，对上层表现为本地目录。由于所有 Pod 挂载同一命名空间，一个副本写入的 KV block 可立即被其他副本读取。Curvine 的运行结构简单：Master 节点负责元数据与日志（持久化到 EBS），Worker 组件运行在各 GPU 节点上、数据落在本地 NVMe（通常挂载于 /opt/dlami/nvme/curvine-data）；Worker 宕机时其所存缓存可由 KV 重算恢复，不存在数据丢失风险。

智能路由：把请求送到对的副本

三级缓存要发挥全部收益，需要请求落到已持有相关 KV block 的副本上。HyperPod Inference Operator 内置路由器支持三种策略：

• prefix-aware（默认）：维护前缀树，适合多轮对话、共享系统提示词；
• kv-aware：查询各 worker 缓存状态，适合长文档处理与长时间会话；
• round-robin：无状态批量推理与压测。

整个机制对客户端透明，无需修改业务侧代码。

落地方式与收益

整套方案由作为 Amazon EKS 插件安装的 Inference Operator 管理生命周期，自动部署带分层缓存配置的 vLLM Pod。AWS 在测试部署中验证了：跨 Pod 缓存命中率最高可达 100%，TTFT 最高改善约 2.7 倍，跨节点 L2 读取延迟约 56 毫秒（针对约 1900 token 的 prompt）。结果意味着原本需要 P5 实例承担的工作负载可下移到成本更低的 G6e 实例，从而降低单端点成本；具体节省幅度取决于模型规模与流量分布。