技术深度解析
缓存感知路由利用了Transformer推理中的一个基本不对称性：处理请求的成本在很大程度上取决于键值（KV）缓存是否已被预填充。在典型的自回归LLM中，每个token的生成都需要关注序列中所有先前的token。KV缓存存储了这些中间表示，避免了冗余计算。当新请求到达时，如果其前缀与先前缓存的序列匹配——例如系统提示、用户的历史对话或常见的文档块——模型可以跳过为该前缀重新计算缓存的过程，从而在长上下文查询中节省高达80%的FLOPs。
核心架构涉及一个轻量级路由层，通常作为边车代理或独立的微服务实现，位于客户端和模型实例池（每个实例运行相同的LLM）之间。该路由器维护一个分布式缓存索引——将请求前缀的语义哈希映射到这些缓存所在的实例ID。当请求到达时，路由器计算请求前缀的语义哈希（例如，使用像`all-MiniLM-L6-v2`这样的小型嵌入模型，或基于token ID的局部敏感哈希）。然后它查询索引，找到已拥有该前缀缓存的实例。如果找到匹配项，请求被转发到该实例，实现缓存命中。如果没有匹配项，请求被发送到最近最少使用的实例，该实例将构建一个新的缓存。
多个开源项目正在率先采用这种方法。`vLLM`仓库（GitHub上超过40,000颗星）引入了PagedAttention和前缀缓存，允许共享公共前缀的多个请求重用KV缓存块。最近，`SGLang`（超过10,000颗星）添加了`RadixAttention`机制，将KV缓存组织为基数树，实现了高效的前缀匹配和缓存驱逐。另一个值得注意的项目是`FlexGen`（超过15,000颗星），它探索将KV缓存卸载到CPU内存和SSD，以进一步减轻GPU内存压力。这些项目表明，缓存感知路由不仅仅是理论上的——它正在被积极部署到生产中。
| 指标 | 冷启动（无缓存） | 缓存命中（前缀匹配） | 缓存命中（完整上下文） |
|---|---|---|---|
| 首Token时间（TTFT） | 500 ms | 80 ms | 20 ms |
| 每秒Token数 | 30 | 120 | 200 |
| 每百万Token成本（GPU小时） | $1.50 | $0.45 | $0.25 |
| 内存利用率（每请求） | 100% | 30% | 15% |
数据要点： 性能差距非常明显。与冷启动相比，缓存命中将TTFT降低了6倍，成本降低了3-6倍。对于高流量应用，这转化为巨大的节省。
路由算法本身必须在利用（将请求发送到缓存实例）和探索（确保缓存多样性）之间取得平衡。贪婪方法——总是路由到缓存重叠度最高的实例——可能导致热点和缓存污染。高级实现使用多臂老虎机框架，其中每个实例的缓存效用被建模为奖励分布，路由器通过概率采样来学习哪些实例对不同查询类型最有效。这对于多租户部署尤其重要，因为不同客户具有不同的使用模式。
关键参与者与案例研究
多家公司已经在生产中利用缓存感知路由，尽管许多公司将其视为竞争优势并保持细节保密。例如，OpenAI的API隐式地使用了前缀缓存——重用系统提示或对话历史的用户通常会在后续请求中观察到更低的延迟和成本。然而，该公司并未将其作为可控功能公开。
Anthropic的Claude API提供了一个“提示缓存”功能，明确允许开发者标记可重用的前缀，从而将长上下文任务的成本降低高达50%。这是缓存感知路由的直接商业应用，已被运行客户支持机器人和文档分析管道的企业广泛采用。
在开源方面，Together AI和Fireworks AI已围绕缓存感知路由构建了其推理平台。Together AI的推理引擎基于vLLM，使用跨越数百个GPU的分布式缓存索引，为Llama 3和Mistral等流行模型系列实现了60-70%的缓存命中率。Fireworks AI的平台更进一步，使用一个学习的路由模型，基于请求嵌入预测缓存命中概率，与简单的基于哈希的路由相比，额外降低了15%的成本。
| 平台 | 缓存命中率 | 成本降低 | 支持的模型 | 路由方法 |
|---|---|---|---|---|
| OpenAI (GPT-4o) | ~40%（隐式） | 20-30% | 专有模型 | 内部前缀缓存 |
| Anthropic (Claude 3.5) | ~55%（显式） | 40-50% | Claude系列 | 用户标记前缀 |
| Together AI | 60-70% | 50-60% | Llama, Mistral, Mixtral | 分布式缓存索引 |
| Fireworks AI | 65-75% | 55-65% | Llama, Mistral, Mixtral | 学习型路由模型 |