KV缓存路由：减少冗余的LLM预填工作

当重复的提示前缀不断出现在您的LLM流量中时，KV缓存路由显得尤为重要。如果正确的请求落在正确的副本上，服务引擎可以重用缓存的注意力状态，而无需一次又一次地重新计算相同的预填充令牌。.

这听起来像是一个基础设施细节，但它很快就会成为一个产品问题。长系统提示、RAG上下文、少样本示例和多轮聊天历史会使预填充工作变得昂贵。当每个副本重新计算相同的前缀时，团队需要付出延迟、GPU时间和容量规划的代价。.

ShareAI为开发者提供一个API，用于150多个模型、市场可见性、路由和故障转移。KV缓存路由位于模型服务基础设施的下一层。对ShareAI读者来说，有用的结论很简单：路由决策在AI堆栈的每一层都很重要，从模型选择到哪个GPU副本处理重复的提示。.

为什么KV缓存路由很重要

在LLM推理过程中，模型首先在预填充阶段处理输入提示。它构建一个键值缓存，通常称为KV缓存，以便后续生成的令牌可以回溯到已处理的上下文。.

前缀缓存允许服务引擎在后续请求共享相同的提示开头时重用该缓存。 vLLM自动前缀缓存文档 将其描述为重用共享前缀的KV缓存，使新请求可以跳过共享部分的计算。. SGLang前缀缓存 使用相关的理念来共享常见令牌序列的KV缓存。.

这对于许多请求以相同方式开始的工作负载尤为重要：支持代理使用大型系统提示、RAG应用程序使用重复的文档块、编码代理使用存储库指令或携带对话历史的聊天产品。.

轮询负载均衡的局限性

前缀缓存在一个副本上最简单。同一进程看到重复的前缀，并且如果内存可用，可以重用其缓存。问题出现在服务水平扩展时。.

使用标准的轮询负载均衡器，请求一可能在副本A上预热缓存，而具有相同前缀的请求二落在副本B上。副本B没有该缓存状态，因此它重新计算相同的预填充工作。请求三可能落在副本C上，再次错过缓存。.

随着副本数量的增加，简单的负载均衡可能会将相关请求分散到更多机器上。模型服务集群可能看起来是平衡的，但前缀缓存命中率下降。这就是KV缓存路由试图解决的差距。.

三个实用的路由级别

1. 会话亲和性

会话亲和性将来自同一用户、工作区、租户或对话的流量路由到同一副本。这是多轮对话最简单的起点，因为后续提示通常共享之前的上下文。.

权衡在于用户身份并不总是与提示相似性相同。两个用户可能共享相同的长系统提示，但仍然被路由到不同的副本。当添加或移除副本时，会话亲和性也可能受到干扰。.

2. 前缀哈希路由

前缀哈希路由使用提示本身作为路由键。路由器对提示的稳定开头进行哈希，并将匹配的前缀发送到同一副本。.

当重复的系统提示、少样本示例或共享的检索上下文比用户身份更重要时，这种方法效果更好。困难在于选择前缀边界。如果哈希包含时间戳、请求 ID 或用户特定字段，路由键会碎片化，缓存重用会崩溃。.

3. 缓存事件感知路由

最先进的方法是跟踪哪些缓存块驻留在哪些副本上，然后在考虑负载的同时将每个请求路由到缓存重叠最佳的副本。 llm-d 路由器项目 描述了一个端点选择器，该选择器在选择请求去向时考虑 KV 缓存位置、当前负载和优先级。.

这更复杂，但对于高吞吐量的集群来说，这是正确的方向，因为缓存未命中是可测量的、昂贵的且频繁的。.

何时跳过它

KV 缓存路由并不总是值得复杂化。当提示较短、主要是唯一的或以批处理方式处理且结构重复较少时，它适配性较弱。.

文档摘要、创意生成、一次性提取以及许多异步批处理任务可能没有足够的共享前缀重叠来证明缓存感知路由的合理性。在这些情况下，普通的负载均衡可能更简洁。.

实际测试是测量：缓存命中率、首次令牌时间、吞吐量、队列深度、GPU内存压力以及每个完成任务的成本。如果缓存感知路由没有改变这些数字，请先修复提示结构。.

与 ShareAI 的契合点

ShareAI 是一个 AI 市场和 API，而不是 GPU 集群内部的模型服务负载均衡器。开发者使用 ShareAI 通过一个 API 访问多个模型，比较市场信号，路由请求，管理使用情况，并在路由性能下降时进行故障转移。.

这仍然使 KV 缓存路由相关。如果您运营自己的推理堆栈，它可以帮助您提出更好的基础设施问题。如果您使用托管模型，它可以帮助您评估为什么两个具有类似模型名称的路由在实际工作负载下可能表现不同。.

对于构建者，这也与定价相关。一个具有长提示、重复 RAG 上下文或代理循环的应用程序可能会导致非常不均匀的 AI 使用。ShareAI Builder 允许应用程序所有者通过 ShareAI 路由 AI 推理流量，设置利润或附加费，让客户为路由使用支付 ShareAI，并根据生成的使用量每月获得付款。应用程序本身仍然在 ShareAI 之外构建。.

对于模型选择和路由评估，从以下开始 ShareAI 模型市场的模型 ID. 。对于实施基础知识，请使用 ShareAI API参考文档.

KV 缓存路由检查表

• 将稳定的提示内容放在前面：系统提示、工具规则、示例和重复的上下文。.
• 将动态字段放在后面：时间戳、请求 ID、用户特定事实和一次性指令。.
• 在路由更改前后测量缓存命中率。.
• 一起观察首次令牌时间、吞吐量、队列深度和 VRAM 压力。.
• 在构建缓存事件感知路由之前，从前缀哈希路由开始。.
• 按工作负载拆分路由规则，而不是强制执行一个全局策略。.
• 将成本和延迟保持在应用程序级别可见，而不仅仅是在推理集群内部。.

常见问题

什么是KV缓存路由？

KV缓存路由是一种路由策略，它将具有重复提示前缀的请求发送到可能已经持有匹配KV缓存的副本。其目标是减少冗余的预填充计算。.

KV缓存路由与前缀缓存有何不同？

前缀缓存是模型服务引擎能够重用共享提示前缀的缓存状态的能力。KV缓存路由是一种流量分配策略，帮助匹配的请求落到已经存在该缓存状态的地方。.

为什么轮询路由会影响前缀缓存？

轮询路由将请求分散到各个副本，而不知道哪个副本拥有哪个缓存前缀。一个重复的提示可能会因为落到不同的副本上而错过缓存。.

哪些工作负载最适合KV缓存路由？

多轮对话、RAG、编码代理、支持代理、少样本提示以及具有长共享系统提示的应用程序是最适合的候选者，因为它们会重用大量的提示前缀。.

团队在什么时候应该跳过KV缓存路由？

当提示较短、主要是唯一的，或者是以批处理为主且重复结构较少时，应跳过。在这些情况下，路由的复杂性可能价值不大。.

vLLM和SGLang是否支持前缀缓存？

是的。vLLM文档记录了自动前缀缓存，而SGLang文档记录了针对常见令牌序列的共享KV缓存的前缀缓存。当涉及多个副本时，服务引擎仍然需要路由支持。.

KV缓存路由与语义缓存是一样的吗？

不是。KV缓存路由适用于推理服务中精确或近似结构的前缀重用。语义缓存基于含义存储和重用响应或中间结果，通常使用嵌入或相似性阈值。.

ShareAI是否取代了支持KV缓存感知的负载均衡器？

不可以。ShareAI 是一个用于模型访问、路由、故障转移、使用和计费的 AI 市场和 API 层。KV 缓存感知路由是为运行推理副本的团队提供的低级模型服务基础设施。.

构建者应该如何看待 KV 缓存路由？

构建者应将缓存行为视为 AI 密集型应用程序中的一个成本驱动因素。如果他们的应用程序使用不均，ShareAI 可以帮助路由和货币化这些 AI 流量，同时应用程序仍然在 ShareAI 之外构建和拥有。.

团队在更改路由之前应该测量什么？

测量缓存命中率、首次令牌时间、吞吐量、队列深度、VRAM 压力、每任务成本和输出质量。路由更改应改善工作负载，而不仅仅是仪表板。.

KV 缓存路由能否降低 AI API 成本？

它可以降低为自己服务模型的团队的基础设施成本，因为减少冗余预填充工作可以提高 GPU 效率。对于托管 API，其效果取决于提供商是否在价格或性能中体现了这些节省。.