Amazon SageMaker HyperPod 携手 Curvine 实现分层 KV 缓存，大幅提升 LLM 推理效率
大规模运行大型语言模型（LLM）推理时，KV 缓存常常面临两难选择：要么为不断增长的 KV 缓存支付昂贵的 GPU 实例费用，要么忍受缓慢的首次令牌生成时间（TTFT），因为相同的提示词在每个请求中都会被重新计算。对于在多个业务线端点、RAG 管道或多轮对话应用中部署 Qwen、Llama、DeepSeek 等众多公开基础模型的团队而言，这一权衡直接转化为更高的基础设施成本和更差的用户体验。
问题的根源在于，vLLM 在生成过程中会将已处理过的每个令牌的注意力键值存储在 KV 缓存中，以避免重复计算。前缀缓存通过跨请求复用共享的起始令牌（如通用系统提示词）进一步优化。然而，在像 ml.g6e.4xlarge（每 GPU 48 GB）这样具有成本效益的实例上，扣除模型权重和运行时分配后，可用于前缀缓存的内存非常有限，且随着模型规模或并发度的增加而进一步收紧。长提示词的缓存命中率下降，相同的系统提示词在每个请求中都被重新预填充，水平扩展的 vLLM 副本各自维护独立的缓存，路由到不同副本时实际上相当于冷启动。
本文介绍了一种在 Amazon SageMaker HyperPod 上构建的分层 KV 缓存架构，将缓存层次从 GPU 和 CPU 内存扩展到共享的分布式 NVMe 存储池。该架构基于 HyperPod 的托管分层 KV 缓存和智能路由两项能力，并引入轻量级分布式缓存文件系统 Curvine 作为共享的 L2 层（GPU 到 CPU 到共享 NVMe）。通过这种设置，您可以在副本之间以接近本地磁盘的速度复用 KV 缓存。
在测试部署中，该架构实现了高达 100% 的跨 Pod 缓存命中率，TTFT 提升最高 2.7 倍，跨节点 L2 读取延迟约为 56 毫秒（针对约 1,900 个令牌的提示词）。这意味着，以前需要 P5 实例的工作负载现在可以在更经济的实例上运行。
