AI辅助整理：本文基于下方列出的公开原始来源改写，不代替原文。
核心摘要： 亚马逊为SageMaker实时推理端点新增前缀感知路由策略，把提示词开头相同的请求稳定送到同一实例，让KV缓存真正被复用。官方在Llama 3.1 70B、7台ml.p5.48xlarge上的基准显示，8000令牌共享前缀的长上下文场景P50首字延迟降低71%至77%，吞吐提升15%至16%，KV缓存命中率从约25%升到80%以上。该策略按生产变体配置，无需改动模型容器或调用方式。
业务背景：重复的提示词开头正在消耗推理算力
企业把大模型接进客服、销售和知识问答后，请求结构高度相似：开头是一段固定的系统指令、政策说明或检索到的文档，末尾才是用户真正输入的那几十个令牌。官方举例说，一段3000令牌的指令可能对应只有50令牌的用户提问，成百上千次请求都在重复计算同一段开头。
推理框架早已给出解法，即前缀缓存：把已计算过的键值对缓存下来，下次遇到相同开头直接复用。但问题出在扩容之后——请求被随机分散到多台实例，每台都看不到足够多的重复前缀，缓存建不起来，能力形同虚设。
问题定位：缓存能力有，但路由把请求摊得太薄
官方明确指出，当端点后面是一组机器时，同一个3000令牌前缀这次落到实例A、下次落到实例B、再下次落到实例C，每台实例都从头计算，因为谁都没有频繁看到它。前缀缓存功能存在，但路由层把请求分散得太细，导致它帮不上忙。
这正是企业推理集群常见的隐性浪费：算力买了，缓存开了，效果却没有兑现。
AI怎么落地：按请求开头做一致性路由
SageMaker推理新增前缀感知路由，查看每个请求的开头，把开头相同的请求持续送到同一实例，让该实例的KV缓存真正积累并复用。用户不需要给请求打标签，也不需要自己管理亲和性，端点根据请求内容自动完成。
官方内置两道保护：一是过载保护，某个前缀极热而目标实例已满时，请求改投较空闲实例，并发上限由用户配置；二是扩缩容期间行为稳定，增删实例时大多数请求仍去往原实例，只有少量流量迁移，缓存不会每次扩缩容就被清空。
实施步骤：两个参数加一次端点配置更新
在创建端点配置时选择PREFIX_AWARE策略，并设置两个参数：PrefixLength（1024至65536）决定用请求开头多少内容做路由，原生Invoke API按字节计、OpenAI兼容API按提取出的消息文本字符计；ConcurrencyThreshold（1至1024）决定目标实例在途请求达到多少时触发溢出改投。
官方强调无需改动模型容器或服务框架，路由完全发生在端点层；调用方式不变，InvokeEndpoint与OpenAI兼容的Chat Completion接口照旧。切换策略只需更新端点配置，不必重新部署模型。
结果证据与边界：长上下文收益最大
官方基准显示，8000令牌共享前缀的长上下文负载下，P90首字延迟降低33%至37%，P50降低71%至77%，KV缓存命中率从约25%至82%，吞吐提升15%至16%。短上下文负载下P90降低24%至37%，P50降低13%至16%，吞吐提升1.7%至2.0%。
边界同样清楚：共享前缀越长收益越大；至少需要两个实例，单实例下任何策略都一样；原生Invoke API按原始字节路由，JSON空白、键顺序和格式差异都会影响命中，需要保持序列化一致；PrefixLength过短会把请求挤到一台实例触发溢出，过长则会把本应聚合的请求打散。
可复制动作：把这项优化纳入推理平台默认配置
对已有RAG、多轮对话、模板化机器人和代码补全场景，可先在预发环境按共享前缀长度加少量缓冲设置PrefixLength，观察KV缓存命中率与首字延迟变化，再逐步推广。
同时把缓存命中率纳入日常监控指标，配合详细可观测性在模型层面跟踪，确认策略对自身负载确实有效，而不是照搬默认值。
证据与边界
- 官方基准基于Llama 3.1 70B Instruct与7台ml.p5.48xlarge，vLLM开启前缀缓存，16种测试配置全部100%成功。
- 长上下文场景为8000令牌共享前缀、持续1小时；短上下文为变长ShareGPT式对话、30分钟。
- 路由开销1.3至1.9毫秒，测试中模型首字延迟区间为63至280毫秒。
- 多租户隔离通过请求头或prompt_cache_key实现，来源未披露具体客户部署案例。
企业今天可以做什么
先确认推理框架已开启前缀缓存（vLLM近期版本默认开启）；再按共享前缀长度设置PrefixLength（1024至65536），并设置ConcurrencyThreshold防止单实例过载；多租户场景用X-Amzn-SageMaker-Prefix-Aware-Id或prompt_cache_key隔离缓存；上线后开启详细可观测性，跟踪KV缓存命中率验证效果。