AWS 为 Amazon SageMaker Inference 增加了一个“前缀感知路由”（prefix-aware routing）选项，承诺为在自有基础设施上运行大语言模型 (LLMs) 的客户提供更高的缓存命中率和显著降低的延迟。这一变化意义重大，因为它能显著降低延迟并减少 GPU 计算成本。

为什么 LLM 延迟至关重要

当 LLM 接收到一个请求时，它通常会对整个提示词 (prompt) 重新计算注意力机制——这是一个随着新增 token 数量增加而变得昂贵的步骤。如果模型可以复用之前请求的注意力缓存 (attention cache)，它就只需要处理文本的新部分。那些重复发送相同系统提示词 (system prompt) 或维持对话历史的工作负载，是缓存复用的理想对象。

在默认的 SageMaker 设置中，传入的请求会被随机分配到推理实例池中。随机分配意味着一个本可以命中热缓存 (warm cache) 的请求往往会落在冷实例 (cold instance) 上，从而被迫进行完整的重新计算。其结果是更高的延迟和额外的 GPU 计算周期，这会直接转化为更高的支出。

前缀感知路由的工作原理

新的路由模式维护了一个最近请求前缀的轻量级映射表——这些前缀本质上是提示词中在多次调用中趋于保持不变的第一部分。当新请求到达时，SageMaker 会检查该映射表，并将请求转发给已经处理过相同前缀的实例。如果该实例仍保留着相关的注意力缓存，模型就可以跳过大部分工作，从而更快地生成答案。

关键点：

  • 无需更改代码 – 该功能完全存在于推理服务层。
  • 仅适用于自托管模型 – 诸如 OpenAI 的 API 或 Anthropic 的托管服务等托管产品不受影响。
  • 对应用程序透明 – 原有的 SageMaker 端点 URL 和 API 契约保持不变。

谁将从中受益

在 SageMaker 上托管 LLM 的企业出于从数据隐私到成本控制的各种原因。对于运行客服聊天机器人、销售助手或任何重复使用固定系统提示词的交互式智能体的用户来说，这种路由优化可以缩短平均响应时间。在成本方面，每次缓存命中都能让 GPU 免于重新评估提示词的共享部分。

局限性与反向观点

其收益取决于是否存在重复的前缀。高度多变的提示词——例如一次性查询或动态生成的系统消息——将无法获得同样的缓存命中优势。

由于该功能仅限于自托管部署，受限于托管式 LLM 服务的客户无法利用它。

总结： 前缀感知路由为 SageMaker 用户提供了一种简单、零代码的方式，在降低 GPU 成本的同时，降低重复性 LLM 工作负载的延迟。对于已经在该平台上托管模型的组织来说，这次升级是一项低风险的优化，可以转化为更快的用户交互和更低的账单。