北京
在大规模运行大语言模型（LLM）推理时，KV缓存常常迫使你在成本和性能之间做出两难选择：要么为不断增长的KV缓存租用容量过大的GPU实例，要么接受缓慢的首字延迟（TTFT），因为相同的提示词每次请求都要重新计算。对于在各类业务终端、RAG管道或多轮对话应用中部署Qwen、Llama、DeepSeek等公开基础模型的团队来说，这一权衡直接转化为更高的基础设施成本和更差的用户体验。 问题的根源很直接：在生成过程中，vLLM会将已处理过的每个token的注意力键和值存储在KV缓存中，因此无需在每一步都重新计算。前缀缓存通过跨请求复用共享前导token（如常见的系统提示词）的缓存来扩展这一思想。但在像ml.g6e.4xlarge（每GPU 48GB）这样的经济高效实例上，计入模型权重和运行时分配后，留给前缀缓存的内存十分有限，而且模型越大或并发越高，可用空间越发紧张。具体表现为：长提示词上的缓存命中率下降，相同的系统提示词在每次请求时都要重新预填充，水平扩展的vLLM副本各自维护隔离的缓存——路由到不同副本从功能上看等同于冷启动。 本文在Amazon SageMaker HyperPod上构建了一种分层KV缓存架构，将缓存层级从GPU内存和CPU内存进一步扩展到共享的分布式NVMe池。它基于HyperPod的两项能力——托管KV缓存分层（Managed Tiered KV Cache）和智能路由（Intelligent Routing），并引入Curvine作为共享的L2层（GPU→CPU→共享NVMe）轻量级分布式缓存文件系统。通过这种架构，你可以在各副本之间以接近本地磁盘的速度复用KV缓存。 下面我们详细说明如何一步步实现这一端到端方案。首先，我们会在HyperPod上配置包含GPU节点和NVMe存储节点的集群，并启用托管KV缓存分层。然后，部署vLLM实例时，我们让每个推理副本将KV缓存写入Curvine挂载的共享目录，同时利用智能路由将具有相同前缀的请求定向到同一副本组，以最大化缓存命中率。最后，通过负载测试对比传统独立缓存方案与分层缓存方案在TTFT、吞吐量和GPU利用率上的差异。实验表明，在长系统提示词和跨副本复用的场景下，分层缓存能显著降低重复预填充带来的计算开销，让每个GPU承载更多并发请求，从而在保持响应速度的同时降低单位推理成本。 这种架构特别适合以下场景：多模型多租户平台、需要共享系统指令的聊天应用、以及基于RAG的问答系统——因为这些场景中大量请求共享相同的前缀token，分层缓存带来的收益非常明显。对于已经使用Amazon SageMaker HyperPod的团队，无需修改现有vLLM代码，只需调整部署配置和路由策略即可接入这套方案。Curvine作为轻量级文件系统层，避免了传统远程缓存的高延迟，同时提供了分布式副本间的数据一致性，让系统在节点故障时也能快速恢复。 总之，GPU内存有限，但KV缓存不应成为瓶颈。通过将缓存分层延伸到NVMe池，并配合智能路由，你可以在不牺牲体验的情况下大幅降低大模型推理的大规模部署成本。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
