Amazon SageMaker HyperPod Inference Gateway 发布：更智能的 GPU 路由迎来严苛生产考验

Amazon 推出了 Amazon SageMaker HyperPod Inference Gateway，并提出了一项引人注目的主张：无需更改模型服务器或客户端应用，即可将首个令牌延迟最多降低 82%。

这项新的 Amazon EKS 插件以基于实时模型服务器和 GPU 状态的路由决策，取代了通用的请求分发机制。AWS 表示，在一项基准测试中，首个令牌生成时间从 4.4 秒降至 800 毫秒以内。

这一成果直指大规模语言模型服务中代价高昂的薄弱环节。轮询负载均衡器只能看到可用的网络端点，却无法感知已饱和的缓存或漫长的生成队列。它可能把新请求发送到过载的 pod，而另一块 GPU 却仍在等待。

这项发布也让 AWS 加入了围绕推理请求路径控制权的更广泛竞争。Google Cloud 已在 GKE 上提供类似的模型感知路由，而 NVIDIA Dynamo 则可在自身服务栈内做出缓存感知的调度决策。

AWS 押注于 Kubernetes 原生路由能够成为通用控制层。更严峻的考验在于：团队能否在真实工作负载中复现其延迟收益，同时不引入运维或安全问题。

Amazon SageMaker HyperPod Inference Gateway 改变了请求路径

关键变化并非又一个模型服务引擎，而是 AWS 在现有引擎之前插入了一层具备推理感知能力的决策层。

AWS 于 2026 年 9 月 18 日发布了其网关公告。根据产品发行说明，底层 EKS 插件版本于 9 月 10 日推出。

该网关运行在通过 Amazon EKS 编排的 SageMaker HyperPod 集群上。它通过一个私有端点接收请求，并为每个请求选择模型池和服务 pod。

这一选择通过两阶段本地路由路径完成。Body-Based Router 会读取 OpenAI 兼容请求中的 model 字段，随后将请求导向相应的资源池。

Endpoint Picker，即 EPP，则在该资源池内选择一个 pod。它使用传统 Kubernetes 服务路由无法理解的信息为候选项评分。

这些信号包括队列深度、正在运行的请求、键值缓存利用率、前缀缓存亲和性以及 LoRA 适配器驻留状态。键值缓存会保存先前处理过的令牌的注意力状态，从而减少重复的提示词计算。

LoRA 适配器是一组应用于共享基础模型的紧凑型微调权重。将正确的适配器加载至 GPU 内存需要时间，因此路由至已驻留的适配器可避免一次切换。

AWS 允许运营者为这些评分因素分配可配置权重。因此，对延迟敏感的聊天服务可以采用不同于面向批量生成工作负载的优先级。

这一架构将传输与调度智能分离。Envoy 负责 HTTPS 流量处理和转发，而 Endpoint Picker 则负责做出模型特定的选择。

该网关基于 Kubernetes Gateway API Inference Extension 构建，而不是以专有请求格式替代 Kubernetes 网络。团队仍可声明式定义路由资源，并使用熟悉的集群工具进行管理。

现有客户端可以继续发送标准的 OpenAI 兼容请求。支持的模型服务器包括 vLLM、SGLang 以及其他提供兼容端点的服务器。

部署仍需要基础设施工作。管理员必须安装 HyperPod Inference EKS 插件、配置权限、为模型 pod 添加标签，并创建 InferenceGatewayConfig 资源。

AWS 当前的部署文档还列出了最低服务器版本要求。其中要求 vLLM 版本为 0.9.2 或更高，SGLang 版本为 0.3.5.post1 或更高。

当 AWS 表示该网关无需修改应用时，这一区别尤为重要。客户端和服务器代码可以保持不变，但集群配置并非如此。

AWS 降低了集成边界，而非消除了运维工作。平台团队仍需负责身份、网络、指标、升级、兼容性测试和故障处理。

不过，这一转变确实改变了重要优化能够发生的位置。此前，团队会将路由逻辑嵌入应用、服务网格或专用服务框架中。

HyperPod Inference Gateway 将这一决策迁移到托管 EKS 插件中。这使高级路由成为可能，而无需每个应用团队自行构建调度器。

为什么 GPU 感知路由比轮询更重要

生成式 AI 请求并非可互换的工作单元，因此平均分配请求数量很少能实现计算负载的均匀分配。

传统轮询策略会按固定顺序将请求发送至后端。最少连接数路由通过考量活跃连接，能做出略为更好的估算。

但这两种策略都不了解提示词长度、缓存状态、适配器可用性或剩余生成工作量。因此，两个表面上相同的连接可能代表截然不同的 GPU 资源承诺。

设想一个客户支持助手收到多个带有相同系统提示词和产品文档的请求。某个 pod 若在缓存中保留了该共享前缀，就可以跳过部分提示词处理阶段。

另一个 pod 则必须重新计算完整前缀。在该 pod 尚未过载的前提下，将请求发送至已缓存的 pod 可以缩短首个令牌生成时间。

仅靠缓存亲和性还不够。始终优先选择前缀匹配度最高的路由器，可能会制造热点，并让其他加速器利用不足。

Endpoint Picker 则会将缓存信息与活跃负载信号结合起来。其目标是在复用既有计算成果与避免 pod 过载之间取得平衡。

长上下文请求让这一平衡更加重要。模型产生第一个可见令牌之前，通常被称为预填充的提示词处理阶段就可能占用大量加速器容量。

这种延迟会以首个令牌生成时间的形式呈现在用户面前。在聊天、检索增强生成、编程助手和文档分析系统中，这一点尤其明显。

AWS 表示，在其示例中，简单路由在流量突发期间产生了超过四秒的延迟。其优化路由将所述的 4.4 秒等待时间缩短至 800 毫秒以内。

这正是“最多 82%”这一标题数字的依据。它仍是 AWS 报告的结果，而非覆盖不同模型、硬件、流量模式和提示词分布的独立性能保证。

即便如此，其机制是可信的，并且正日益成为行业中的常见做法。模型服务会产生通用网络负载均衡器无法评估的内部状态。

潜在的经济影响不止于更快的聊天响应。队列不均衡会促使运营者增加冗余副本，因为他们无法可靠地利用现有容量。

更优的调度可以缩小这一安全余量。它还可以通过将流量导向真正可用的容量来延后自动扩缩容事件。

不过，路由与自动扩缩容解决的是不同的问题。路由决定下一个请求应发送给哪些可用 pod 中的哪一个。自动扩缩容则决定何时应增加 pod 或节点。

HyperPod 已通过 CloudWatch、Amazon Managed Prometheus 和 Kubernetes Event-driven Autoscaling 支持推理自动扩缩容。该网关则在更广泛的容量系统中增加了更快速、请求级别的决策能力。

这种分层方法在短时流量突发期间尤为重要。启动一个新的 GPU 支持副本，可能比选择一个已运行该模型且负载较低的 pod 耗时更长。

网关可以在自动扩缩容器对持续需求作出反应时改善即时调度。但当所有符合条件的后端均已满载时，它无法凭空创造容量。

AWS 表示，当资源池耗尽时，系统会返回带有 Retry-After 标头的 HTTP 429。应用仍需要重试策略、准入控制以及合理的超时行为。

因此，GPU 感知路由最强的适用场景是状态不均衡的多副本服务。当一个端点仅有一个符合条件的后端时，其说服力则较弱。

AWS 正加入 Kubernetes 路由竞争

Amazon 并非在一片空白市场中引入模型感知路由，而是在 HyperPod 运营体系周围封装一种新兴的 Kubernetes 模式。

Google Cloud 的 GKE Inference Gateway同样使用队列深度、缓存利用率、前缀状态和 LoRA 亲和性。它由开源 llm-d 路由器驱动。

与 AWS 一样，Google 在 Kubernetes 网关后部署 Endpoint Picker。该选择器结合模型服务器信号，为每个传入请求对可用 pod 进行排序。

NVIDIA Dynamo 提供了另一种路径。其KV 感知路由可以通过 Dynamo 前端运行，也可以与 Gateway API Inference Extension 集成。

其中的区别涉及请求路径的控制权归属。平台团队可能更倾向于 Kubernetes Gateway API，以实现集中的入口、身份验证、速率限制和遥测。

模型服务团队则可能更偏好直接控制路由的框架专属前端。NVIDIA 同时记录了两种模式，因为没有一种适合所有运营模式。

AWS 选择了由平台控制的路径。HyperPod Inference Gateway 为集群提供一个共享入口，而模型服务器则继续在其后执行推理。

这一设计有助于在一个集群上运行多个模型的组织。Body-Based Router 会读取请求的模型，并将其映射至已配置的调度器和资源池。

应用不再需要为每个已部署模型分别编写路由逻辑。一个网关可以暴露多个资源池，同时保留每个资源池内部 pod 级别的调度决策。

这也是“无锁定”说法需要加以限定的地方。AWS 表示，该网关可与任何 OpenAI 兼容模型服务器配合使用，包括 vLLM、SGLang 和 TGI。

数据平面接口具备可移植性，且该架构依赖 Kubernetes 资源。不过，托管插件、配置资源、IAM 集成和运维生命周期仍与 AWS 服务绑定。

这对于托管云组件而言并不罕见。它意味着可移植性更多存在于服务接口层面，而不是完整的运营层面。

Google 在 GKE 上也面临相同的张力。NVIDIA 提供更多框架级控制，但采用其服务图会引入另一组依赖关系。

因此，真正的竞争不只是 AWS 对阵 Google 或 NVIDIA，而是平台托管路由与模型服务栈内部拥有的路由之间的竞争。

平台托管路由为多个引擎提供一个控制点。它可以将流量策略与集群团队现有的 Kubernetes 实践相协调。

框架自有路由可以更快地暴露更深层的引擎状态和专门的服务功能。它也可能减少请求与工作节点之间的组件数量。

AWS 对开放 Kubernetes 接口的采用缩小了这两种方法之间的架构差距，但并未消除运维选择。

组织必须决定由谁来调整评分权重、诊断不佳的调度结果，并在路由信号过时时作出响应。这些职责可能横跨平台团队和机器学习团队。

此次发布促使云服务商和推理服务供应商让路由智能更易于使用。队列感知调度正从定制优化变为预期中的基础能力。

竞争优势很可能将转向集成质量、可观测性和可衡量的性能表现。每家供应商都可以列出类似的路由信号。

但能够证明这些信号在故障、快速扩容、混合模型和不断变化的提示词分布下仍保持准确的供应商并不多。生产环境证据将比功能对等性更重要。

82% 的延迟声明需要工作负载级别的验证

AWS 的结果确立了一个有参考价值的上限，但并未说明运营团队自身流量能带来多大改善。

“最高可达 82%”描述的是特定测试条件下报告的最佳结果。AWS 并未将其表述为适用于所有 HyperPod 部署的普遍降幅。

该结果取决于基线路由策略是否反复选择繁忙或缓存未预热的 Pod。对于请求均匀、服务本身已较为平衡的场景，改善空间会更小。

提示词重复度同样重要。当大量请求共享较长的初始 Token 序列时，前缀感知路由能创造更高价值。

检索应用常会将不同文档插入原本相似的提示词中。这种模式可能带来部分前缀重叠，但其价值取决于提示词的构建方式。

同样，LoRA 感知路由只有在团队通过共享副本动态提供适配器时才有帮助。仅运行一个固定模型的服务无法从适配器亲和性中获益。

流量强度会改变结果。在低负载下，无论如何调度，多个 Pod 都可能快速响应。在严重过载时，任何路由算法都无法弥补容量不足。

因此，团队应在多个并发级别下进行基准测试。他们应衡量中位延迟和尾部延迟，而不仅是最快或平均响应。

首 Token 时间也只是用户体验的一部分。Token 间延迟衡量的是首个 Token 出现后生成的速度。

偏向已缓存预填充工作的路由决策，可能改善首 Token 时间，却将解码工作放到繁忙的 Pod 上。运营团队必须同时关注两个阶段。

吞吐量、故障率、排队时间和 GPU 利用率也应纳入同一评估。优化一个指标可能掩盖其他指标的退化。

评分系统还引入了另一个变量。AWS 允许团队调整队列深度、缓存状态、活跃请求数和适配器驻留状态的相对权重。

这种灵活性很有价值，但也带来了调优负担。为短聊天提示词设计的一套权重，在处理长文档请求时可能表现不佳。

指标质量同样关键。Endpoint Picker 依赖来自模型服务 Pod 的最新 Prometheus 数据。

延迟、缺失或不一致的指标可能让智能路由器依据过时的状态作出判断。AWS 表示，指标过时的 Pod 会被排除在外，直至恢复上报。

排除故障后端比明知存在问题仍向其路由更安全，但这会减少可用容量。因此，监控中断也可能演变为流量管理问题。

在上线前也需要测试兼容性。当前 AWS 文档规定了 vLLM 和 SGLang 的最低版本要求，这可能迫使团队在采用网关的同时升级推理引擎。

版本变更可能影响指标、缓存行为、内存消耗或模型输出性能。团队应在评估期间区分网关效应与引擎升级效应。

最安全的上线方式是先使用镜像测量或有限流量切片。运营团队可以在相同模型和硬件条件下，将常规负载均衡与 Endpoint Picker 进行比较。

他们应记录缓存命中率、队列深度、选择决策和被拒绝的请求。这些测量能够说明延迟为何发生变化，而不只是是否发生变化。

将此次发布理解为一种具有前景供应商基准结果的路由机制最为恰当。它并非能自动让每种延迟特征降低 82% 的方案。

这种审慎表述并不会削弱产品的价值主张。它为基础设施团队提供了可测试的假设和一组明确的审查变量。

Kubernetes 原生并不意味着无需关注安全

最具影响力的部署细节并不在延迟标题中：除非运营团队自行配置，否则网关端点缺少请求级别的授权。

AWS 文档指出，新建端点默认不具备请求级别的身份验证或授权功能。网络访问仍通过 VPC 及相关控制措施受到限制。

AWS 强烈建议为每个网关启用 JSON Web Token 身份验证。JWT 携带已签名的身份声明，网关可在转发请求前对其进行验证。

这一默认设置值得关注，因为网关会成为昂贵模型容量的共享入口。即使无法访问管理 API，未经授权的调用者仍可能消耗 GPU 时间。

私有网络可以降低暴露风险，但无法替代工作负载身份。内部失误、服务被攻破以及范围过宽的网络访问仍会带来风险。

组织应将身份验证视为初始部署的一部分，而不是后续的加固步骤。还应在模型和租户之间定义授权边界。

共享端点能够提升效率，但也可能模糊责任归属。如果两个应用竞争相同的资源池或集群资源，其中一个应用的突发流量可能影响另一个应用。

因此，限流和配额应与智能调度并行部署。本地网关可以选择最健康的 Pod，但仍需规则来约束哪些主体可以发送工作负载。

传输层安全性也需要审慎配置。AWS 文档说明可通过网关终止 TLS，并将证书集成到部署设置中。

团队必须正确管理证书签发、轮换和信任关系。Kubernetes 原生配置使这些设置具备声明式特征，但并不会使其自动得到验证。

可观测性也有类似要求。运营团队需要追踪或日志，将每个外部请求与其所选模型、资源池和 Pod 关联起来。

没有这些记录，延迟尖峰可能看起来像是引擎故障，而真正原因可能是路由评分或过时指标。

共享路由也扩大了配置错误的影响范围。错误的模型映射可能通过一个端点影响多个客户端。

声明式资源使回滚更容易，尤其是在团队使用 GitOps 时。但它们也会让错误变更在各环境中一致地传播。

平台团队应在准入前验证配置。策略可以检查身份验证设置、模型选择器、命名空间以及允许的网关暴露范围。

网关的标准 HTTP 接口降低了客户端的迁移成本。这种便利不应让团队跳过对新请求路径的威胁建模。

AWS 还计划推出用于跨集群和跨区域协调的 Global Inference Router。根据公告，这一第二层能力仍将在后续推出。

该规划中的层级包括故障转移、全局限流和成本感知流量整形。这些功能将引入更广泛的策略和数据路由问题。

跨区域路由可以提升可用性，但也可能将提示词移出原有的司法管辖区或组织边界。未来部署将需要明确的地域性控制。

成本感知路由还会带来另一种权衡。将工作负载发送至更低成本的容量，可能增加网络距离或用户延迟。

当前版本避免了部分复杂性，因为 Tier 1 在每个集群内部运行。即使在本地，团队也必须在生产流量到来前验证身份、隔离和遥测能力。

三个信号将表明网关是否兑现承诺

下一阶段不是又一次功能公告，而是证明该路由层在多样化生产条件下仍然有用的证据。

第一个信号是独立基准数据。团队需要覆盖模型规模、上下文长度、并发级别、硬件类型和缓存复用模式的结果。

一项有价值的比较应包括轮询、最少连接和 GPU 感知路由，并保持推理引擎版本和副本数量不变。

基准测试应报告首 Token 时间的中位数和尾部表现，还应包括 Token 间延迟、吞吐量、错误情况和加速器利用率。

如果独立测试在真实突发流量下接近 AWS 所宣称的提升幅度，推理感知路由的价值主张将显著增强。若收益较小或不一致，其目标市场将更为有限。

第二个信号是模型服务器层面的运营采用情况。AWS 目前记录了 vLLM 和 SGLang 的兼容性要求，同时推广更广泛的 OpenAI 兼容接口。

生产报告应显示指标能否在不同引擎之间保持可靠，也应揭示每种工作负载需要多少定制调优。

若能够在多个服务器上实现低接触式部署，将支持 AWS 的抽象层主张。若需要针对引擎进行排障，则表明通用网关仍会泄露后端复杂性。

发布成熟度在此同样重要。附加组件发布说明将版本 2.0.0-eksbuild.2 标识为该网关的引入版本。

团队应关注后续版本中的兼容性修复、指标修正、身份验证改进和配置变化。早期维护模式往往能揭示真实的运营负担。

第三个信号是计划中的 Global Inference Router 能否交付。Tier 1 改善了集群内的调度，但大型服务通常跨越多个集群和区域。

全局层必须根据健康状况、容量、成本和地域性作出路由决策，同时不能将区域问题演变为全局故障。

金丝雀流量拆分和基于优先级的流量控制也在 AWS 的路线图中。这些功能将使网关从 Pod 选择走向更广泛的推理流量管理。

成功交付将强化 AWS 的平台托管方案。反复延迟则会让客户不得不在其他地方自行组合全局路由、配额和发布控制能力。

因此，Amazon SageMaker HyperPod Inference Gateway 的推出不仅仅是更快的负载均衡器。这是 AWS 试图让模型感知路由成为托管 Kubernetes 基础设施一部分的举措。

该机制解决了通用负载均衡与有状态语言模型服务之间真实存在的不匹配。其价值将取决于可衡量的收益、可信的信号以及严谨的安全配置。

评估该网关的基础设施团队应从一个具有代表性的模型和可回放的流量特征开始。比较路由策略，检查每个选择信号，并在扩大访问范围前测试身份验证。

随后提出关键问题：在最严重的突发流量期间，网关能否在保持尾部延迟的同时降低整体容量压力？这个答案比最亮眼的基准数字更重要。