AWS 推出 SageMaker HyperPod 推理网关，实现 GPU 感知路由

Amazon Web Services 于 2026 年 9 月 18 日宣布 Amazon SageMaker HyperPod Inference Gateway，这是一种 Kubernetes 原生、GPU 感知的路由系统，用于大语言模型推理，可作为 Amazon EKS 上现有 HyperPod 基础设施的单一托管附加组件进行部署。AWS 表示，该网关可将首个 token 的延迟降低最高 82%。

网关背后的路由问题

AWS 表示，默认的 Kubernetes 负载均衡算法（如轮询和最少连接）无法感知 GPU 状态：哪些 pod 已经饱和 KV 缓存，哪些正处于长上下文生成的中间阶段，哪些已经在内存中加载了请求所需的 LoRA 适配器。公司称，请求会在繁忙的 pod 后堆积，而空闲容量未被利用，流量突发时首个 token 的延迟会超过四秒，利用率变得不均衡且不可预测，运营商因此会过度配置以补偿。AWS 描述了一个场景：聊天机器人用户原本需等待 4.4 秒才能获得首个 token，但在该系统下可在 800 毫秒以内看到它。

双层架构

该网关采用基于 Kubernetes 原生原语的双层设计。AWS 表示，它利用实时 GPU 信号将每个推理请求分配到最合适的 pod。第 1 层直接安装在每个 HyperPod 或 EKS 集群上，作为 amazon-sagemaker-hyperpod-inference 附加组件，包含三个组件，全部基于开源的 Gateway API 推理扩展构建。Envoy Gateway 作为第 7 层代理，终止传入的 HTTPS 流量，并为每个集群公开单一私有端点。基于请求体的路由器检查每个传入的兼容 OpenAI 的请求体，提取模型字段，并将请求路由到相应的模型池，从而一个网关能够服务多个模型。

Endpoint Picker 从每个模型服务 pod 获取实时 Prometheus 指标，并在覆盖 KV 缓存利用率、队列深度、LoRA 适配器驻留、前缀缓存命中率以及运行请求等评分器上应用加权评分算法。每个评分器具有可配置的权重，允许针对特定工作负载（例如对延迟敏感的聊天与对吞吐量优化的批处理）微调路由行为。

第 2 层，即全局推理路由器，标记为即将推出。AWS 表示，它将为跨多个集群和区域的整体 fleet 添加协调功能，支持跨集群故障转移、全局速率限制以及成本感知的流量整形。第 2 层基于第 1 层构建，而每个集群的本地网关仍继续处理本地路由。

部署、故障处理与可观测性

部署仅需执行一次 aws eks create-addon 命令，并创建一个声明式的 InferenceGatewayConfig 自定义资源，用于定义模型和路由行为，现有模型服务器部署可通过 pod 标签被发现。AWS 表示，安装过程不需要 sidecar、服务网格，也无需修改应用代码。该网关通过 HTTP 暴露标准的兼容 OpenAI 的端点；据 AWS 称，现有客户端代码无需更改即可使用，无需 SDK 更新，也无需对推理流量进行 SigV4 签名。

对于在共享基础模型上提供微调 LoRA 适配器的工作负载，Endpoint Picker 的 LoRA 亲和评分器会将适配器请求路由到已经在 GPU 内存 中驻留所需适配器的 pod；如果没有 pod 已加载，则请求会发送到拥有最大可用容量的 pod。AWS 表示，这消除了适配器交换的延迟。

已记录的故障行为包括 pod 故障、池耗尽、集群故障和区域故障。pod 故障时，Endpoint Picker 会排除指标过期的 pod 并路由到健康的 pod，指标恢复后自动恢复。池耗尽时，网关返回带有 Retry-After 头的 HTTP 429，同时自动扩缩容增加容量。集群故障时，全局推理路由器检测到心跳过期，并在 35 秒内重定向流量，集群重新加入后逐步恢复流量。区域故障时，跨区域路由会自动激活，AWS 表示这会导致更高的延迟，但不会影响可用性。

网关在 pod、池、集群和 fleet 级别发出指标：在 pod 级别通过 Prometheus 上报 KV 缓存利用率、队列深度、运行请求以及适配器驻留情况；在池级别通过 Prometheus 和 Grafana 上报请求总数、时长直方图和 token 计数；在集群级别通过 Amazon CloudWatch 上报平均 KV 缓存、错误率和 P99 延迟；在 fleet 级别通过 CloudWatch 上报路由决策、故障转移事件以及速率限制命中次数。

AWS 报告的基准测试结果

AWS 表示，它在配备 H100 GPU 的 p5.48xlarge 实例以及配备 A10G GPU 的 g5 实例上，对参数规模从 8B 到 235B 的四个模型进行了基准测试。所有流量均通过内部应用负载均衡器进行路由，匹配生产请求的路径，专用的客户端节点组产生受控负载，模型服务器则在独立的服务器节点组中隔离。根据 AWS 的说法，每个结果均使用网关的默认路由配置且未进行调优，并与相同模型副本上的 Kubernetes 轮询基线进行比较。

在报告的结果中，混合代际 GPU 集群将 Llama-3.1-8B 的首 token 时间（P95 和 P99）延迟分别降低了 97%，吞吐量提升了 8%；对 Qwen3-32B 则分别降低了 98% 和 97%，吞吐量提升了 50%。在突发流量下，Llama-3.1-70B 的 P95 和 P99 延迟分别下降了 94% 和 98%，吞吐量提升了 12%；而 Qwen3-235B 的 P95 延迟相当，但 P99 延迟降低了 89%。在共享提示前缀的情况下，Llama-3.1-8B 的 P95 和 P99 延迟分别下降了 26% 和 43%。

AWS 表示，在流量平稳且全为统一硬件的集群中，网关的表现与轮询调度相当，并将差异在运行间方差范围内的结果定义为可比。公司指出，改进幅度最大的是轮询最难应对的场景：硬件混杂、突发需求以及共享提示前缀。

可用性与路线图

AWS 将该网关描述为符合 Kubernetes Gateway API 及其推理扩展，通过单一自定义资源定义进行配置，并兼容任何兼容 OpenAI 的模型服务器，包括 vLLM、SGLang 和 TGI。管理通过 kubectl、GitOps、Helm 和 ArgoCD 进行，安装、升级和回滚均由 EKS 插件生命周期处理。

自 2026 年 9 月 18 日起，在提供推理插件的区域，Tier 1 每集群路由已可用。除全局推理路由器外，AWS 的公开路线图项目还包括金丝雀流量分割——通过 InferenceModelRewrite 自定义资源将一定比例的流量引导至新模型版本，以及流量控制，可将请求分类为 Critical、Standard 或 Sheddable，并对每个带宽进行准入控制。