Amazon SageMaker 前缀感知路由降低延迟，但关键在于重复上下文

AWS 测试显示，Amazon SageMaker 的前缀感知路由通过改变重复提示词的去向，将首个令牌生成时间的中位数最多降低了 77%。SageMaker 不再无视内容地分发每个请求，而是能够将开头相同的请求持续发送到同一个模型实例，从而提高已计算上下文仍可用的概率。

这一结果挑战了大语言模型端点扩展中的一个基本假设：当常规负载均衡将请求与有价值的缓存数据分离时，增加实例并不会自动带来高效推理。一个集群即使拥有充足的加速器容量，仍可能反复处理相同的指令、文档或对话历史。

因此，AWS 正将路由定位为推理优化技术栈的一部分，与模型引擎、加速器和缓存软件并列。其直接针对的是不感知缓存的负载均衡：后者虽然能均匀分配工作，却忽略了各实例已经掌握的内容。AWS 报告了显著收益，不过最亮眼的数据来自受控的长上下文基准测试，而非独立的生产环境测试。

Amazon SageMaker 前缀感知路由改变了默认权衡

AWS 将提示词局部性从应用层面的临时方案，带入了托管端点的路由层。

AWS 于 2026 年 9 月 10 日为 Amazon SageMaker 实时推理端点发布了该功能。新策略会检查传入请求的开头，并持续将开头相同的请求定向至同一实例。

其底层思路很简单。许多 LLM 请求都包含一大段固定内容，以及随后较小的一段可变内容。例如，客服助手可能会在每个新的客户问题之前，接收相同的政策文档和操作指引。

检索增强生成应用也常遵循相同模式。它会将检索到的文档置于用户查询之前，因此针对同一文档的多个问题会以相同文本开头。编程助手同样会重复发送文件、导入内容、指令和最近的编辑上下文。

模型服务器已经具备利用这种重复的机制。通常称为 KV cache 的键值缓存，会保存模型处理先前令牌时计算出的注意力状态。前缀缓存则会在提示词开头一致的相关请求之间保留可复用状态。

当端点扩展至多个实例时，问题便会出现。随机路由可能将前缀相同的连续请求发送到不同机器。由于有用的缓存条目存在于别处，每台机器都必须再次处理这些共享上下文。

Amazon SageMaker 前缀感知路由试图保留这种局部性。共享同一前缀的十个请求通常应抵达同一台机器，让其模型服务器复用已缓存的计算。具有其他前缀的请求仍可分散到整个集群。

该功能并不会替代服务引擎内部的前缀缓存。容器仍须运行能够保留并复用 KV 状态的软件。AWS 使用 vLLM 测试了该策略，并表示近期 vLLM 版本默认启用前缀缓存。

此次发布为 SageMaker 实时端点新增了第三种路由选项。随机路由仍是默认选项，在不考虑请求关联性的情况下分配流量。最少未完成请求路由则优先选择可用处理容量最多的实例。

前缀感知路由押注的是另一种思路。它允许内容与实例之间存在一定亲和性，因为节省下来的提示词计算可能比让流量完全可互换更有价值。

AWS 增加了过载保护来控制这一风险。当首选实例达到设定的并发阈值时，SageMaker 会将请求发送至负载较低的实例。该请求可能错失缓存命中，但应能避免进入过载队列。

该服务还力求在集群扩缩容时保留大部分请求的分配位置。AWS 表示，增加或移除实例时只会转移部分流量。与彻底重新分配相比，这种行为可减少对缓存的扰动。

官方的路由配置确认了这种过载处理机制。其中将随机、最少未完成请求和前缀感知策略列为支持的选项。

这不只是一个便捷设置，因为它改变了谁来处理一个长期存在的系统问题。此前，团队必须创建会话亲和性、部署专用路由器，或接受较低的缓存复用率。如今，SageMaker 可在其托管端点层内提供内容感知的请求分配。

这一区别也将该功能与模型路由区分开来。它不会根据价格、质量或任务类型在不同基础模型之间做选择，而是决定同一已部署工作负载中的哪个实例应接收请求。

这一较窄的范围很重要。AWS 并未声称一个开关就能优化 LLM 服务的每个环节。它所处理的是重复的预填充工作；当应用为每个请求附加较长且反复出现的上下文时，这类工作成本会格外高。

77% 的延迟结果来自共享的长提示词

当每个请求复用 8,000 个令牌的前缀时，AWS 记录到了最大幅度的改进，这使该基准测试特别有利于缓存局部性。

该公司将前缀感知路由与 SageMaker 的默认随机策略进行了比较。测试采用 Llama 3.1 70B Instruct、七个 ml.p5.48xlarge 实例，以及启用了前缀缓存的 vLLM。

AWS 在单模型端点、推理组件端点、原生 Invoke API 和 OpenAI 兼容 API 中运行了 16 种配置。该公司报告称，所有测试均成功完成。

最强的结果来自持续一小时的长上下文工作负载。每个请求共享一个 8,000 令牌的前缀，为缓存消除重复计算创造了大块空间。

AWS 表示，在这些条件下，P50 首个令牌生成时间下降了 71% 至 77%。P50 即中位数，意味着一半测得的请求响应更快，另一半则更慢。

P90 首个令牌生成时间下降了 33% 至 37%。该百分位代表请求分布中较慢的一部分，因此通常对服务级别目标更重要。P90 改善幅度较小表明，路由无法消除尾延迟的所有来源。

AWS 报告称，KV cache 命中率从约 25% 提升至最高 82%。吞吐量提高了 15% 至 16%，表明跳过预填充工作也释放了处理容量。

这些数据构成了 Amazon SageMaker 前缀感知路由的核心论据。中位延迟的改善很引人注目，但缓存命中率的变化解释了其原因：路由器让既有的缓存计算更常能够被访问到。

在较短、长度可变的 ShareGPT 风格对话中，结果则更为温和。在 30 分钟的运行中，首个令牌生成时间中位数改善了 13% 至 16%，吞吐量仅提高 1.7% 至 2%。

在这些较短测试中，P90 延迟仍改善了 24% 至 37%。AWS 称，缓存命中率从约 30% 升至 80%。不过，由于可复用前缀较短，每次成功命中所跳过的工作也更少。

这种对比是AWS 基准测试中最有价值的细节。前缀感知分配并不是适用于所有 LLM 应用的固定倍数增益。其价值取决于有多少上下文会重复，以及处理这些上下文的成本有多高。

报告的路由开销为每请求 1.3 至 1.9 毫秒。AWS 在测试中测得模型的首个令牌生成时间为 63 至 280 毫秒。在这一范围内，路由计算占响应时间的比例相对较小。

在测试场景中，流量也保持了均衡。七个实例各自接收了 13.3% 至 15.4% 的请求。理想情况下，每个实例约应分得 14.3%。

这一结果回应了对前缀亲和性最显而易见的质疑：若某个前缀变得异常热门，将匹配请求集中处理可能会形成热点。AWS 表示，其过载阈值在该基准测试中避免了这一问题。

不过，这些数字仍需谨慎看待。AWS 自行生成并发布了测试，尚无独立机构验证其报告的收益。该公司也未展示来自无关客户的大量生产流量追踪数据。

长上下文测试有意创造了大量复用。这适合衡量该功能预期产生的效果，但并不代表每一种端点。处理彼此无关短提示词的服务，可复用的工作会少得多。

该基准测试还将新策略与随机路由进行比较。已经使用自定义缓存感知路由器、会话亲和性或分布式 KV cache 的团队，可能获得较小的增量收益。对他们而言，相关基线不一定是 SageMaker 的默认设置。

因此，最清晰的结论是有条件的：当请求共享较长前缀，且服务引擎保留其 KV 状态时，该功能可以显著降低延迟。它并未对多样化、难以利用缓存的流量作出同样承诺。

这一条件性结果也反映了关于前缀缓存的更广泛研究。一篇 2025 年的NeurIPS 论文发现，更智能的缓存保留能够提高效率，但也记录了缓存容量有限和驱逐方面的挑战。

路由解决了该系统中的一部分问题。它提高了请求抵达包含相关状态的实例的可能性，但无法保证该状态在请求到达时仍保留在内存中。

缓存感知路由给传统负载均衡器带来压力

此次发布揭示了传统请求均衡与现代 LLM 推理有状态行为之间的不匹配。

传统 Web 服务通常将可互换的副本视为理想设计。负载均衡器可以通过随机性或队列深度，将每个请求发送至任何健康服务器以分配工作。无论请求被放置在哪里，应用都应产生相同结果。

LLM 副本能够给出等效答案，但其准备成本可能截然不同。一块 GPU 可能已经保存了长合同、代码文件或对话的注意力状态；另一块 GPU 则可能需要在生成首个令牌前重建这些状态。

不感知缓存的路由忽略了这种差异。它可能选择队列最空的实例，却仍选中了需要重复执行最多预填充工作的机器。一台本地更忙的机器反而可能因已包含匹配前缀而更快响应。

这种张力并非 AWS 独有。开源推理系统也开始将请求调度和缓存位置视为相互关联的问题。其中包括基于 vLLM 的技术栈、专用 Kubernetes 网关、分布式缓存，以及预填充—解码架构。

AWS 已在 SageMaker HyperPod 中讨论过更复杂的版本。其智能路由在分层缓存的基础上，支持前缀感知、KV 感知和轮询策略。

HyperPod 设计能够跟踪已缓存的前缀，并将存储扩展到 GPU 内存之外。它将本地 CPU 内存用作一个缓存层级，并可提供分布式的第二层级。这种方法面向规模更大、由 Kubernetes 管理且拥有更深入运维控制能力的基础设施。

新的实时端点功能定位更简单。它让请求靠近可能存在缓存的位置，同时无需用户运营推理集群或分布式缓存。这使得该技术可供使用标准托管端点的团队采用。

托管环境也以一种特定方式对自定义路由项目施加压力。AWS 未必会提供这些项目支持的所有放置信号或缓存管理策略，但它降低了获得其中相当一部分收益所需的工作量。

对于平台团队而言，这可能改变自建还是采购的权衡。自定义路由器需要部署、升级、遥测、故障处理以及与自动扩缩容的协调。当其约束条件与工作负载相符时，生产级配置更容易被采用。

这种竞争压力也波及其他托管推理服务商。客户如今可以越来越多地根据 LLM 平台协调路由、缓存和扩缩容的能力进行评估，而不只是关注可用模型或加速器类型。

这之所以重要，是因为推理效率日益取决于完整的服务链路。模型量化可以降低内存使用量。连续批处理可以合并活跃请求。投机解码则可在适当条件下加速 token 生成。

缓存感知放置针对的是另一种浪费来源：避免重复处理系统已经完成的提示词处理。这些方法可以并存，因此基础设施提供商有动力将它们打包为一体化技术栈。

AWS 与解耦式推理的合作说明了这一方向。该架构将计算密集型的预填充与内存带宽密集型的解码分离，并协调工作节点之间的 KV 传输。

这种更先进的设计将推理视为分布式系统问题。路由决策会考虑队列压力、缓存位置和专用工作节点角色。通用网络负载均衡器不具备这些应用层信号。

不过，常规路由依然有合理用途。当请求彼此独立，或模型没有有效的前缀缓存时，随机放置仍然适用。当处理时间差异较大且共享上下文几乎没有局部性时，最少未完成请求策略也可能有所帮助。

因此，前缀感知路由并不是通用替代方案。它是一种面向特定工作负载的策略，将可复用上下文置于完全均匀的请求分配之上。AWS 的过载控制尝试兼顾这两个目标。

该功能应当会引起构建文档助手和内部搜索系统的团队关注。这类应用在改变问题之前，会反复提供相同的手册、政策、规范或项目记录。

构建可搜索知识库的团队应能识别这种模式。检索质量决定哪些上下文会进入提示词，而路由则影响这些上下文的处理是否能够复用。

多轮智能体是另一类很有潜力的候选场景。每一轮新对话通常都会包含先前消息、工具指令和累积的任务状态。这一不断增长的共同开头使预填充阶段成本更高，同时也创造了缓存复用机会。

编程助手同样具有明显的局部性。多个请求可能共享代码仓库指令、打开的文件、相邻符号和对话历史。最终的补全请求会变化，但其前置上下文中很大一部分仍然稳定。

这些模式解释了为何路由如今已成为一项竞争性功能。更长的上下文窗口鼓励应用在每次调用中发送更多参考材料。智能体工作流也会在多个步骤间重复大量指令和历史记录。

新的瓶颈不只是生成 token 的数量，而是在生成开始前反复准备大量熟悉的输入。这使首个 token 时间成为不同于 token 生成速度的独立产品关注点。

基准测试无法保证什么

前缀感知路由可提高缓存复用的概率，但序列化、驱逐、租户隔离和流量倾斜都可能抹去预期优势。

第一个不确定性在于工作负载是否适配。为无关联提示词提供服务的端点可能产生很少有用的前缀匹配。在这种环境中，路由器增加了少量决策成本，却无法跳过多少模型计算。

即使表面上相似的提示词也可能无法匹配。SageMaker 的原生 Invoke API 根据请求正文中的字节确定路由前缀。JSON 空白字符、字段顺序或格式的差异都可能改变这些字节。

因此，应用必须以一致方式序列化请求。如果客户端库采用不同封装方式，稳定的系统提示词并不足够。使用多项服务或多种编程语言的团队应测试等价请求是否会生成相同的路由输入。

OpenAI 兼容 API 则使用从消息文本中提取的字符。这消除了部分原始 JSON 敏感性，尽管消息序列中的变化仍会影响前缀。放在提示词前部的动态元数据可能使相关请求分散。

前缀长度带来了另一个调优问题。SageMaker 接受从 1,024 到 65,536 的配置范围。对于原生 API，该值表示字节；对于 OpenAI 兼容 API，该值表示字符。

较短的选择范围可能会将过多请求归到一个通用开头。这会增加将过量流量导向某个实例的可能性。此时并发阈值会触发溢出，为保持容量而牺牲缓存亲和性。

较长的选择范围则会带来相反的问题。选定区域内出现的细微差异，可能会将原本共享高成本上下文的请求分开。集群仍然保持均衡，但缓存命中改进会缩小。

正确的值取决于实际提示词结构。团队需要了解共享指令在何处结束、独特材料在何处开始。他们还需要足够的区分内容，避免被广泛使用的模板变成单一路由桶。

缓存驱逐仍不受路由器直接控制。GPU 内存有限，模型服务器必须在新请求到达时回收 KV 块。请求可能抵达预期实例，但相关条目已经消失。

前文引用的前缀缓存研究发现，驱逐策略会实质性影响命中率。这表明放置和保留必须一并评估。

自动扩缩容是缓存波动的另一个来源。AWS 表示，在集群变更期间大部分流量仍会保持映射，但新实例起初并没有有用的本地前缀。扩容事件可能暂时降低命中率，直至热门上下文在这些机器上完成预热。

缩容事件可能移除持有宝贵条目的机器。稳定重映射可以限制中断，但无法保留已消失实例上的缓存内容。因此，突发流量变化可能削弱稳态基准测试结果。

热门前缀也会造成根本冲突。让每个匹配请求都留在同一台机器上，可在该机器饱和前最大化局部性。分散流量可在高负载下保护延迟，但会在更多实例之间重复缓存计算。

SageMaker 的 ConcurrencyThreshold 直接暴露了这一权衡。允许值范围为 1 到 1,024 个进行中的请求。保守阈值更有利于负载分配，而更高设置可更长时间地保护亲和性。

没有一个阈值适用于所有模型。大型提示词、长输出、量化设置、张量并行和批处理行为都会影响安全并发量。运营人员必须根据自身服务级别目标调优该值。

租户隔离同样需要关注。两个组织可能使用相同的系统指令，但需要独立的运营处理。SageMaker 支持可选的前缀感知标识符，用于分离它们的路由组。

原生 API 用户可提供 X-Amzn-SageMaker-Prefix-Aware-Id，最多 64 个 ASCII 字符。OpenAI 兼容请求可使用 prompt_cache_key 字段。AWS 在选择实例时会将该标识符与前缀结合。

该功能提供路由隔离，但不应将 AWS 的公告理解为对每种服务框架内数据隔离的广泛声明。团队仍须评估容器行为、内存管理、日志记录及其完整的安全模型。

该功能至少需要两个实例才能产生有意义的路由差异。只有一个实例时，每个请求本来就会到达同一位置。因此，小规模部署无法从放置亲和性本身获得收益。

AWS 表示，端点路由层无需对模型容器进行改动。不过，服务框架仍须具备可用的前缀缓存。引擎若不兼容或配置不正确，将收到局部化流量，却无法复用底层计算。

基准测试中的 Llama 3.1 70B 与 vLLM 组合验证了一项重要配置。但它并不能证明每种架构、运行时、量化方法、适配器配置或提示词分布都能获得相同改进。

动态低秩适配适配器增加了另一层放置要求。AWS 表示，前缀感知选择在已持有所请求适配器的实例范围内运行。这一更狭窄的候选集合可能限制路由器的均衡选项。

最后，最显眼的指标并不代表完整用户体验。首个 token 时间会影响感知响应速度，尤其是在交互式产品中。它并不直接描述输出质量、总生成时间或补全可靠性。

吞吐量改进也远小于中位延迟收益。在 AWS 的测试中，长上下文吞吐量最高提高 16%，而短上下文吞吐量提高不超过 2%。容量规划应采用相关指标，而非只看醒目的延迟数据。

因此，77% 这一数字应被视为 AWS 基准测试中的上限结果。它证明局部性可能非常重要，但并非每个 SageMaker 端点的性能保证。

三个信号将表明收益能否在生产环境中持续

下一项考验是，客户能否在不产生不稳定热点或进行大量提示词工程的情况下，复现 AWS 的缓存命中收益。

第一个信号是生产环境缓存遥测。团队应使用相同的流量追踪、集群规模、服务引擎和自动扩缩容策略，对比随机路由与前缀感知路由。仅靠中位延迟无法解释结果。

KV 缓存命中率应随更低的预填充延迟一同上升。运营人员还应跟踪 P90 和 P99 首个 token 时间、队列深度、溢出频率以及实例级流量分布。

如果缓存命中率提升，同时尾部延迟保持稳定，AWS 的核心论点就更有说服力。如果中位延迟下降，但溢出或 P99 延迟恶化，那么该收益将需要更严格的部署条件。

比较还应纳入冷启动和扩缩容阶段。一小时的稳态基准测试可能掩盖部署、实例替换或突然扩容后出现的预热成本。真实服务会经常经历这些转换。

第二个信号是更广泛的运行时和模型证据。AWS 使用 vLLM 测试了一款主流开放模型，但客户运行着各种不同的架构和容器。在更小的模型、混合专家模型、量化模型以及长输出工作负载上的结果，将进一步明确该功能的适用范围。

短上下文工作负载尤其值得关注，因为 AWS 已发现其吞吐量提升较小。如果独立测试也只能复现有限改进，那么前缀感知路由的主要价值仍将集中在文档密集型和智能体应用中。

如果类似收益能在不同模型和提示词模式中出现，路由局部性将成为托管推理的标准要求。其他提供商将面临压力，需要提供类似的配置能力和可观测性。

第三个信号是从启发式前缀亲和性转向显式缓存状态路由。前缀相似度只能估计有用状态可能存在的位置。KV 感知系统则可以跟踪整个集群中的实际区块、驱逐事件或传输情况。

AWS 已通过 SageMaker HyperPod 提供更深入的缓存感知选项。其实时端点未来可能会暴露更丰富的缓存信号、分布式缓存支持或更具自适应性的策略。竞争对手和开源项目也在朝类似方向推进。

如果托管端点获得准确的缓存状态感知能力，本次发布将成为更大转型中易于采用的第一层。如果复杂性让这些功能始终局限于专用集群，前缀感知路由或许仍会是实用的折中方案。

对开发者而言，眼下应采取的行动是测量，而不是想当然地迁移。识别重复的提示词部分，规范序列化，启用引擎级前缀缓存，并测试多种前缀长度。比较延迟分布，而不只是平均值。

企业采购方应询问供应商：路由智能位于何处，以及平台公开哪些指标。一个宣传前缀缓存、却无法在副本之间保持局部性的系统，在规模化运行时可能给出令人失望的命中率。

知识工作者将间接感受到这一影响。当文档助手、编程工具和长时间运行的智能体反复使用相同上下文时，它们应能更早开始响应。这种提升应体现在首个生成 token 之前，而不一定贯穿整段回答。

Amazon SageMaker 前缀感知路由有力表明，负载均衡必须理解可复用的 LLM 上下文。AWS 的结果显示，在共享 8,000-token 前缀的情况下，忽视缓存的调度成本可能十分高昂。

悬而未决的问题是，真实流量有多常呈现这种有利形态。团队应在将这一 headline 数字视作运营预测之前，测试自身的流量追踪数据，包括扩缩容事件和繁忙前缀。

关注缓存命中率、最慢的请求，以及溢出路由的发生频率。这些指标结合起来，将揭示 SageMaker 是否在保留有用上下文，还是仅仅重新分配流量。