用 Amazon SageMaker 的前缀感知路由能把 Llama 3.1 70B 的

很多 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 就能真正跑起来，而不是在不同机器之间打散。

它是怎么在路由层做分发的

这个路由策略是自动化的，不需要开发者手动给请求打标签或管理亲和性。SageMaker 在请求到达端点时直接分析 payload 的开头，确保相同前缀的请求始终命中同一台机器，让缓存保持「热度」。

为了防止某些热门前缀把单台机器跑死，它内置了两套保障机制：

• 过载保护： 如果某个前缀请求量太大，目标实例达到预设的并发上限（concurrency limit）后，系统会自动将多余请求路由到其他较空闲的实例。虽然这次请求会丢失缓存命中，但保证了服务不会宕机。
• 扩缩容稳定性： 在增加或减少实例数量时，大部分请求依然能维持原有的路由映射，只有极小部分流量会发生偏移，避免了每次 scaling 导致全局缓存失效。

Llama 3.1 70B 的实测数据

为了验证效果，他们在 7 台 ml.p5.48xlarge 实例上部署了 Llama 3.1 70B Instruct，配合 vLLM（开启 prefix caching），将前缀感知路由与默认的随机路由进行了对比。测试覆盖了原生 Invoke API、OpenAI 兼容 API、单模型端点及推理组件端点共 16 种配置，成功率 100%。

具体的性能提升非常明显：

• 首字延迟： P50 TTFT 最高降低了 77%。
• 吞吐量： 提升了最高 16%。
• 缓存命中率： 从随机路由时的 25% 左右直接拉升到了 80% 以上。

尤其是处理长上下文工作负载时（比如 8,000 token 的共享前缀），这种路由方式带来的延迟优化极其显著。如果你在做复杂的 RAG 或者有大量重复指令的 Agent，这种路由方案比单纯在单机上开缓存要实用得多。