AWS SageMaker Inference推出前缀感知路由，Llama 3.1 70B首token延迟最多降 77%
Amazon SageMaker Inference新增PREFIX_AWARE路由策略，把共享相同提示前缀的请求发往同一实例以复用KV缓存。在 7 台ml.p5.48xlarge上跑Llama 3.1 70B，P50 TTFT最多降低 77%，缓存命中率从约 25% 升到 80% 以上。
AI解读：一个LLM请求通常分两部分：固定前缀（系统指令、参考文档、对话历史）和末尾的可变用户输入。客服机器人每轮请求开头可能都是 3000 个token的同一段话，用户问题只有 50 个token。vLLM等框架的prefix caching能缓存已算过的KV对，但只在单实例内有效。
问题出在扩到多实例之后：默认随机路由把带同一段前缀的请求撒到不同机器上，哪台都攒不出稳定的缓存，prefix caching形同虚设。SageMaker的新策略直接看请求开头，把前缀相同的请求固定发给同一台机器，让那台机器的KV缓存真正热起来。
受影响最大的是RAG、多轮对话、模板化机器人和代码补全这几类负载：它们的共同点是大量请求共享同一段不短的文本。前缀越长收益越大，8000 token共享前缀的测试中P50 TTFT降了 71%到77%，缓存命中率从约 25%升到 82%，吞吐提高 15%到16%。
限制也很具体：需要至少两个实例，路由本身每次多花 1.3 到 1.9 毫秒，容器里的prefix caching必须打开，原生Invoke API按原始字节匹配前缀，JSON空白和键顺序不同就会被当成不同前缀；多租户想隔离缓存可以用X-Amzn-SageMaker-Prefix-Aware-Id头或prompt_cache_key字段。
Amazon SageMaker Inference推出一项名为前缀感知路由（prefix-aware routing）的新路由策略，把请求开头相同的请求稳定地发往同一个实例，使该实例上的KV缓存得以积累和复用。该策略以PREFIX_AWARE作为RoutingStrategy在生产变体上配置，无需改动模型容器或服务框架，也无需为请求打标签或自行管理亲和性。
AWS在Llama 3.1 70B Instruct、7 台ml.p5.48xlarge实例、vLLM（已启用prefix caching）上做了对比基准测试，覆盖单模型端点、推理组件端点、原生Invoke API和OpenAI兼容API共 16 种配置，全部 100% 成功。8000 token共享前缀、持续 1 小时的长上下文负载中，P50 TTFT降低 71% 至 77%，P90 TTFT降低 33% 至 37%，KV缓存命中率从约 25% 提升到 82%，吞吐提高 15% 至 16%。
为什么多实例下前缀缓存会失效
AWS在文中描述，一个LLM请求通常由固定部分（指令、参考文档、对话历史）和可变的用户输入组成。以客服机器人为例，每次请求开头都是同一段约 3000 token的“你是AnyCompany的支持代理，以下是我们的政策……”文字，末尾的客户问题可能只有 50 token。这意味成百上千次请求都在重复计算同一段开头。
vLLM、TensorRT-LLM等服务框架的prefix caching会缓存已计算前缀的KV对，命中时只处理新增token，能明显降低首token延迟（TTFT）。但一旦扩展到单实例之外，请求被随机分散到多台机器，同一段前缀落在A、B、C不同实例上，每台都因频率不够而建不起可靠缓存。AWS称这一策略正是为了解决“缓存功能存在、但路由层摊得太薄”的问题。
- 请求前缀相同的 10 个请求会全部落到同一台机器，该机器对该前缀的缓存保持热度。
- 不同前缀分散到不同实例。
- 默认随机路由适合请求可互换、不存在把特定请求发给特定实例收益的场景；LEAST_OUTSTANDING_REQUESTS适合处理时间差异大、需要均衡在途请求的场景。
基准测试的分场景结果与路由开销
长上下文负载使用 8000 token共享前缀、持续 1 小时，P90 TTFT降低 33% 至 37%，P50 TTFT降低 71% 至 77%，KV缓存命中率从约 25% 至 82%，吞吐提升 15% 至 16%。短上下文负载为变长ShareGPT风格对话、30 分钟，P90 TTFT降低 24% 至 37%，P50 TTFT降低 13% 至 16%，KV缓存命中率从约 30% 至 80%，吞吐提升 1.7% 至 2.0%。AWS的解释是共享前缀越长，每次命中所跳过的计算越多，收益越大。
路由逻辑本身每次请求带来 1.3 至 1.9 毫秒开销，而测试中模型TTFT处于 63 至 280 毫秒区间，AWS称该开销可忽略。流量分布方面，7 台实例各承接 13.3% 至 15.4% 的请求，与理想均分值相差在 1 个百分点以内。
- 长上下文：P90 TTFT降 33–37%，P50 TTFT降 71–77%，KV命中率从约 25% 到 82%，吞吐增 15–16%。
- 短上下文：P90 TTFT降 24–37%，P50 TTFT降 13–16%，KV命中率从约 30% 到 80%，吞吐增 1.7–2.0%。
- 路由开销 1.3–1.9 毫秒/请求，对比模型TTFT 63–280 毫秒。
- 16 种配置全部 100% 成功，流量分布与均匀切分相差不超过 1%。
适用负载与配置参数
AWS列出四类最能受益的场景：RAG应用中同一篇文档被多个用户提问时共享该文档前缀；多轮对话每轮携带完整历史，历史越长前缀越贵；模板化机器人或助手把政策、格式规则、人设定义随每次请求发送；代码补全在同一文件内工作时，每次补全请求共享该文件内容作为前缀。
启用时在端点配置中设置两个参数。PrefixLength取值 1024 至 65536，决定用请求的多长开头做路由：原生Invoke API按请求体开头的字节数计算，OpenAI兼容API按提取出的消息文本字符数计算，建议覆盖共享前缀再加一点缓冲。ConcurrencyThreshold取值 1 至 1024，是目标实例的在途请求上限，超过则把请求转给负载较低的实例。策略按生产变体设置，更新端点配置即可在三种策略间切换，无需重新部署模型。
- 至少需要两个实例，只有一个实例时所有策略都指向同一处。
- 容器内必须启用前缀缓存：vLLM近期版本默认开启，其他框架可能需要显式配置。
- 原生Invoke API按原始字节匹配，JSON空白、键顺序、格式差异都会改变路由，需保持一致的序列化。
- PrefixLength过短会把同前缀请求挤向一台实例触发溢出，过长会让temperature这类小差异把本应同组的请求打散。
- 可用SageMaker详细可观测性跟踪模型级KV缓存命中率，确认策略对该负载是否生效。
多租户隔离与推理组件支持
若不同租户共享相同提示指令但希望路由分开、保持缓存上下文独立，可传可选ID：原生Invoke API设置X-Amzn-SageMaker-Prefix-Aware-Id头（最多 64 个ASCII字符），OpenAI API在请求体加入prompt_cache_key字段。该ID与前缀组合后，相同前缀但不同ID的请求会落到不同实例。
该功能兼容推理组件端点和动态LoRA适配器：对推理组件的行为与单模型端点一致；对LoRA适配器，则在已加载该适配器的粘性实例集合内按前缀选择。调用方式不变，InvokeEndpoint、InvokeEndpointWithResponseStream以及OpenAI兼容的Chat Completion API都照旧使用。该功能已在SageMaker实时推理端点上可用，需更新AWS SDK或CLI到最新版本以使用新的RoutingStrategy和PrefixAwareRoutingConfig参数。
- 原生API：X-Amzn-SageMaker-Prefix-Aware-Id头，最长 64 个ASCII字符。
- OpenAI API：请求体中的prompt_cache_key字段。
- 路由完全在端点路由层完成，不需要改模型容器或服务框架。