AWS 在 Amazon SageMaker Inference 推出“前缀感知路由”，通过将相同提示词前缀的请求持续路由到同一实例以提高 KV 缓存复用率。AWS 自测显示在长上下文负载下 P50 首Token延迟可降71%–77%，KV命中率显著提升，但实际收益取决于部署场景和配置。
亚马逊云服务（AWS）宣布，Amazon SageMaker Inference新增“前缀感知路由”（prefix-aware routing）功能。该机制会识别请求开头的共同提示词前缀，并将具有相同前缀的请求持续发送到同一推理实例，以提高大语言模型（LLM）KV缓存的复用率。
AWS表示，在其使用Llama 3.1 70B Instruct进行的基准测试中，前缀感知路由让长上下文负载的P50首Token延迟（TTFT）降低71%至77%，KV缓存命中率从约25%提高到82%，吞吐量提高15%至16%。不过，这些数字来自AWS自测，并不等同于所有生产部署环境都能获得相同收益。
AWS于2026年9月10日在官方博客发布了这一功能介绍：Reduce LLM latency with prefix-aware routing on Amazon SageMaker Inference。
多实例部署削弱了前缀缓存的效果
LLM请求通常由两部分组成：一部分是固定的系统指令、参考文档或对话历史，另一部分是每次请求变化的用户输入。对于客服机器人、RAG应用或代码补全工具而言，固定部分可能占据数千个token。
vLLM和TensorRT-LLM等推理框架可以把已经计算过的提示词前缀转换成KV缓存。当后续请求使用相同前缀时，模型可以跳过部分重复计算，只处理新增内容，从而缩短TTFT。
但在多实例部署中，默认的随机路由可能把相同前缀的请求分散到不同机器。每个实例接收到的请求数量不足以稳定积累相应缓存，结果是框架虽然启用了前缀缓存，缓存却没有得到充分利用。
SageMaker的新路由策略试图解决这一调度层问题：相同的请求前缀通常会被映射到同一个实例，不同前缀则可以分散到不同实例。应用开发者不需要自行维护实例亲和性或为每个请求手动添加路由标签。
AWS基准测试：长前缀负载收益更明显
AWS称，测试在7个ml.p5.48xlarge实例上进行，使用vLLM部署Llama 3.1 70B Instruct，并开启前缀缓存。测试覆盖单模型端点、推理组件端点、原生Invoke API以及OpenAI兼容API，共测试16种配置，所有测试的请求成功率为100%。
在共享约8,000个token前缀、持续运行一小时的长上下文负载中，与默认随机路由相比：
- 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毫秒之间。7个实例的请求分布为13.3%至15.4%，仍保持在接近均匀的范围内。
过载保护与扩缩容稳定性是关键设计
前缀路由也带来了一个新的风险：如果某个前缀特别热门，所有相关请求可能集中到同一个实例。为避免形成热点，SageMaker允许配置并发阈值。当目标实例达到阈值时，请求会溢出到负载较低的其他实例，代价是该次请求可能无法命中原有缓存。
AWS还称，在增加或移除实例时，大部分请求会继续发送到原先负责的实例，只有一小部分流量会因实例数量变化而迁移。这一设计旨在减少扩缩容导致的缓存失效和性能波动。
SageMaker目前提供三种实时端点路由策略：默认的RANDOM、根据在途请求数选择实例的LEAST_OUTSTANDING_REQUESTS，以及此次新增的PREFIX_AWARE。其中，随机路由更适合请求彼此独立的通用负载；最少未完成请求路由适合请求处理时间差异较大的场景；前缀感知路由则面向启用了前缀缓存的LLM工作负载。
AWS的创建端点配置文档显示，PREFIX_AWARE属于端点配置中的路由策略选项。
配置重点不只是打开一个开关
AWS介绍的配置中，有两个参数尤其重要。PrefixLength决定用于路由判断的请求前缀长度，范围为1,024至65,536；ConcurrencyThreshold决定目标实例允许承载的最大在途请求数，范围为1至1,024。
在原生SageMaker Invoke API中，前缀长度按照请求体开头的字节计算；在OpenAI兼容API中，则根据提取出的消息文本字符计算。这意味着，同一提示词如果采用不同的JSON空白、字段顺序或序列化格式，可能被视为不同前缀。开发者需要保持请求序列化方式一致，并根据共享前缀长度设置合理的缓冲区。
AWS还指出，前缀感知路由本身不会替代模型容器或推理框架中的缓存配置。只有当vLLM等服务框架真正启用了前缀缓存，请求被稳定地送到同一实例后才会产生实际复用效果。此前，AIFlux也曾报道Hugging Face对Transformers后端进行优化，使其在vLLM中达到原生级推理性能，这类推理引擎能力与路由层优化共同构成了LLM服务的性能基础。
对于多租户场景，如果不同租户使用相同系统提示词、但又需要保持缓存上下文隔离，AWS提供了额外的路由标识。原生API可以使用X-Amzn-SageMaker-Prefix-Aware-Id请求头，OpenAI兼容API则可以在请求体中加入prompt_cache_key。该标识会与前缀共同参与路由判断。
适用场景集中在重复上下文工作负载
AWS列出的适用场景包括RAG、长对话、模板化助手和代码补全。RAG系统可能会把同一份文档置于多个问题之前；多轮对话会在每个回合重复发送此前的会话历史；企业助手会持续携带固定的政策、格式和角色指令；代码补全工具则可能在同一文件上连续生成多个补全请求。
这些场景的共同点不是“使用了某个特定模型”，而是大量请求共享提示词开头，并且服务端能够保留和复用对应KV状态。对于完全不同的短请求、前缀变化频繁的应用，或者无法开启前缀缓存的部署，路由策略的价值可能较低。
AWS建议部署方启用详细可观测性，持续观察模型层面的KV缓存命中率、请求延迟和实例负载，而不是仅凭单次基准测试判断效果。实际收益还会受到模型、上下文长度、请求分布、缓存容量、并发限制以及扩缩容方式等因素影响。
前缀感知路由的意义，在于把LLM推理优化从模型和硬件层进一步延伸到请求调度层。它不能消除长上下文推理的全部成本，但如果企业工作负载中存在稳定、重复且足够长的提示词前缀，将请求送到“已经见过这段上下文”的实例，可能比单纯增加GPU数量更直接地改善首Token延迟和吞吐量。
AWS官方公告：Reduce LLM latency with prefix-aware routing on Amazon SageMaker Inference。
此外，SageMaker与Hugging Face之间的部署衔接也已有相关工具支持，读者可参考AIFlux此前的Amazon SageMaker一键从Hugging Face直达部署流程报道。