详细内容或原文请订阅后点击阅览
使用 Curvine 在 Amazon SageMaker HyperPod 上为大型 LLM 提供分层 KV 缓存
大规模运行大型语言模型推理会迫使 KV 缓存进行权衡：GPU 实例规模过大或首次生成令牌的时间过长。本文在 Amazon SageMaker HyperPod 上构建了一个分层 KV 缓存，将缓存扩展到使用 Curvine 的共享分布式 NVMe 池中，因此副本可以在经济高效的实例上以接近本地磁盘的速度重用缓存。
来源:亚马逊云科技 _机器学习大规模运行大型语言模型 (LLM) 推理通常会迫使 KV 缓存进行权衡：您要么购买超大的 GPU 实例以适应不断增长的 KV 缓存，要么接受较慢的首次令牌时间 (TTFT)，因为每次请求时都会重新计算相同的提示。对于跨每个业务线端点、检索增强生成 (RAG) 管道或多轮对话应用程序部署广泛的公开可用基础模型 (FM) 目录（例如 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 缓存。
解决方案设计
图1：分层KV缓存架构
图 2：Curvine 架构
Curvine 的工作原理（集群视图）：