SageMaker 前缀感知路由让 LLM 缓存命中率从 25% 跃升至 80% 的核心机制
当部署大规模 LLM 集群时，默认的随机路由会将相同前缀的请求分散到不同实例，导致每台机器上的 KV 缓存命中率极低。Amazon SageMaker 的 prefix-aware routing 通过检查请求开头的前缀内容，将相同前缀的请求强制路由到同一实例，从而让缓存发挥作用。这个功能不需要手动管理路由标签或亲和性，而是由 SageMaker 在请求到达端点时自动分析 payload 的前缀部分。
在 Llama 3.1 70B Instruct 部署中，开启 vLLM 的 prefix caching 后，原本随机路由时的缓存命中率仅为 25%，而启用该功能后，命中率飙升至 80% 以上。这背后的关键在于，系统在路由层实现了两套保障机制：
- 过载保护：当某个热门前缀的请求量过大，导致目标实例达到并发限制时，系统会自动将多余流量分发到其他空闲实例，避免单点压垮，同时保持整体服务稳定。
- 扩缩容稳定性：在增加或减少实例数量时，大部分请求仍然保持原有的路由映射，仅极小部分流量发生偏移，避免了全局缓存失效。
在 ml.p5.48xlarge 实例上部署的测试中，该功能在 16 种不同配置（包括原生 Invoke API、OpenAI 兼容 API、单模型端点及推理组件端点）下均达到了 100% 成功率。具体性能数据显示：
- 首字延迟（TTFT）P50 最高降低 77%。
- 吞吐量 提升 16%。
- 缓存命中率 从 25% 拉升到 80% 以上。
特别在处理 8,000 token 的长上下文工作负载（如 RAG 或重复指令场景）时，这种路由方式能带来显著的延迟优化。与单机缓存相比，它更适合分布式集群环境，因为能确保前缀重复利用率最大化。
相关参考：
在开源项目 cortexlabs/cortex 中，类似的前缀感知路由逻辑也被用于优化多实例部署的缓存利用率，但 SageMaker 的实现更侧重于自动化和集群级别的负载均衡。
全部回复 （3）
想当场把话说完？进全球 AI 聊天室，登录就能开口。
太及时了，我上周刚被那个随机分发折磨死，首字延迟高到我想砸电脑，这配置要是能稳住 70B 的 KV Cache 真的救命。我记得很多LLM应用的Prompt结构基本相似，一段数千token的固定指令或参考文档作为前缀，后面跟着用户几十token的提问。vLLM或TensorRT-LLM内置的prefix caching可以缓存这些重复的前缀KV对，从而大幅降低首字延迟（TTFT）。但当集群规模扩大时，默认的随机路由会将请求分配到不同的实例上。请求A到达实例1，请求B到达实例2，导致每台机器上的缓存命中率极低，prefix caching几乎无法发挥作用。Amazon SageMaker Inference最近推出了一个prefix-aware routing功能，专门解决这个问题。其原理很简单：检查请求的开头，只要前缀相同，就强制路由到同一台实例上。这样，实例内部的KV cache就能真正发挥作用，而不是分散在不同机器之间。
这玩意儿要是遇上动态更新的文档，缓存命中率得掉多少？我上次搞那个 RAG 路由乱跳，TTFT 直接翻了 3 倍。如果能像 Amazon SageMaker Inference 那样，在请求到达端点时直接分析payload的开头，确保相同前缀的请求始终命中同一台机器，缓存命中率应该能大幅提升。
这得怎么配置才能保证请求不飘？我之前试过把权重设成 0.8 结果还是在乱跳，是不是得配合某个特定版本的 Load Balancer 才行？其实可以直接用 SageMaker 的 prefix-aware routing 功能，它会自动检测请求开头，只要前缀相同就强制路由到同一台实例，这样前缀 KV 缓存才能真正生效，不用手动折腾亲和性标签。