AWS推出SageMaker HyperPod推理网关：GPU感知路由，首Token延迟最高降82%
AWS发布Kubernetes原生推理路由插件，以单次EKS托管附加组件安装，支持多模型与LoRA适配器路由；官方称不修改模型服务器或客户端代码即可将首Token延迟从4.4秒降至800毫秒以下。
AI解读：AWS为SageMaker HyperPod推出了一款叫Inference Gateway的推理路由插件，它装在现有EKS集群上，靠读取GPU的实时指标来决定每个请求发往哪个模型实例，而不是像默认Kubernetes负载均衡那样盲目轮询。官方给出的最大卖点是首Token延迟最高降低82%，且不需要改模型服务器或客户端代码。
这件事针对的是一个很实际的问题：GPU是LLM服务里最贵的资源，但轮询和最少连接算法看不见Pod内部的KV缓存是否快满、队列有多长、请求需要的LoRA适配器是否已在显存里。结果是请求堆在忙碌的Pod后面，空闲的Pod却在摸鱼，忙时首Token延迟会冲到4秒以上，于是团队只能多买GPU来兜底。
真正受影响的是已经用HyperPod或EKS跑vLLM、SGLang、TGI这类OpenAI兼容模型服务器、并且集群里硬件型号不统一或流量有峰谷的团队。按AWS给出的测试，混合GPU代际和突发流量场景收益最大，吞吐还能涨8%到50%；但如果你的集群硬件完全一致、流量又平稳，这套网关的表现和轮询基本持平。
需要留意的是，目前可用的是第一层的单集群网关，跨集群和跨区域的第二层Global Inference Router还标着coming soon。官方也没有给出所有场景的完整数字，部分工况标注为‘comparable’，即差异在运行间波动范围内。
AWS在机器学习博客上宣布推出Amazon SageMaker HyperPod Inference Gateway，一个Kubernetes原生的GPU感知推理路由系统，以单个EKS托管附加组件（amazon-sagemaker-hyperpod-inference）形式部署在已有HyperPod基础设施上。官方称它利用实时GPU信号将每个推理请求分配到最合适的Pod，降低延迟，且无需改动模型服务器或客户端应用。
AWS将问题归因于默认Kubernetes负载均衡器：轮询和最少连接算法看不到GPU内部状态，包括哪些Pod的KV缓存接近饱和、哪些正在处理长上下文生成、哪些内存里已加载请求所需的LoRA适配器。其结果是请求堆积在忙碌Pod后、空闲容量闲置，流量突发时首Token延迟飙升至4秒以上，GPU利用率变得不均衡且不可预测，用户被迫超额配置。
官方给出的对比数字是：等待首Token 4.4秒的聊天机器人用户，现在不到800毫秒即可看到首个Token。该数据来自AWS博文，未附独立第三方验证。
两层架构：单集群网关已可用，全局路由器尚未上线
Inference Gateway采用两层设计，全部构建在Kubernetes原生原语之上。第一层是每集群网关，作为EKS托管附加组件安装，由三个核心组件构成，均基于开源Gateway API Inference Extension：Envoy Gateway负责终结HTTPS流量并暴露每个集群一个私有端点；Body-Based Router（BBR）检查每个OpenAI兼容请求体，提取model字段并路由到对应模型池，支持单网关多模型；Endpoint Picker（EPP）是智能层，消费来自每个模型服务Pod的实时Prometheus指标，用加权评分算法选择最佳后端。
EPP的评分维度包括：KV缓存利用率，避免键值内存将满的Pod；队列深度，避免请求积压深的Pod；LoRA适配器驻留，优先已加载所需适配器的Pod；前缀缓存命中率，优先可能从缓存提示前缀提供服务的Pod；运行中请求数，在机群中平衡活跃工作。每个评分器有可配置权重，可按工作负载调节，例如延迟敏感的聊天对吞吐优化的批处理。
第二层Global Inference Router（GIR）标注为即将推出，将在多个集群和区域之间做全局协调，提供跨集群故障转移、全局限流和成本感知的流量整形。GIR建立在第一层之上，各集群的网关继续处理本地智能路由。
- 第一层可用：每集群路由，基于EKS托管附加组件amazon-sagemaker-hyperpod-inference
- 第二层未上线：Global Inference Router，跨集群、跨区域，含故障转移、全局限流
- 路由能力：多模型路由、LoRA适配器路由，均通过配置定义
安装与使用：一个附加组件、一个自定义资源、不改代码
AWS描述部署方式为单个附加组件安装加一个声明式InferenceGatewayConfig自定义资源，无sidecar、无服务网格、无应用代码改动。第一步安装附加组件，使用aws eks create-addon命令，指定集群名、附加组件名amazon-sagemaker-hyperpod-inference、版本v2.0.0-eksbuild.1，并通过配置值启用inferenceGateway和inferenceOperator。第二步给现有模型服务部署打标签，例如app: vllm-llama，网关据此发现它们。第三步创建InferenceGatewayConfig资源，定义模型和路由行为，示例中配置了llama-3.1-70b、匹配标签app: vllm-llama、目标端口8000、调度器llm-d。
第四步发送推理请求：网关暴露标准OpenAI兼容端点，现有客户端代码不变，用curl POST到/v1/chat/completions即可，无需SDK改动，推理流量也无需SigV4签名，使用标准HTTP和OpenAI兼容schema。
在多模型场景中，BBR根据请求体中的model字段自动路由到正确的模型池。在LoRA场景中，EPP的LoRA Affinity Scorer识别哪些Pod已驻留所需适配器并据此路由，消除适配器换入换出的延迟；若没有Pod加载该适配器，请求会发往可用容量最大的Pod以尽快加载。
- 安装命令：aws eks create-addon，附加组件版本v2.0.0-eksbuild.1
- 配置方式：一个InferenceGatewayConfig CRD定义整个路由拓扑
- 客户端兼容：OpenAI兼容端点，不改代码、无需SigV4签名
- 支持模型服务器：vLLM、SGLang、TGI等OpenAI兼容实现
故障处理与可观测性
网关在多个层面做优雅降级。Pod故障时，EPP排除指标过期的Pod并路由到健康Pod，指标恢复后自动恢复；池耗尽时返回HTTP 429并带Retry-After头，由自动扩缩容增加容量；集群故障时，GIR检测到心跳过期，在35秒内重定向流量，重新引入时逐步爬坡；区域故障时跨区域路由自动激活，代价是更高延迟，但不影响可用性。这些是AWS描述的机制，其中GIR相关能力对应尚未上线的第二层。
可观测性方面，网关在每一层发出指标并接入现有监控栈：Pod级别包括KV缓存利用率、队列深度、运行中请求数、适配器驻留情况，通过Prometheus；池级别包括请求总数、耗时直方图、Token计数，通过Prometheus/Grafana；集群级别包括平均KV缓存、错误率、P99延迟，通过Amazon CloudWatch；机群级别包括路由决策、故障转移事件、限流触发，通过CloudWatch。
- Pod故障：EPP排除老旧指标Pod，自动恢复
- 池耗尽：返回429并带Retry-After，靠自动扩缩容补容量
- 集群故障：GIR在35秒内重定向流量（GIR未上线）
- 区域故障：跨区域路由自动激活，延迟升高但可用性不受影响
基准测试：对比轮询，官方称首Token延迟最高降98%
AWS用四个模型做了基准测试，参数规模从8B到235B，部署在p5.48xlarge（H100）和g5（A10G）实例上。所有流量经过内部Application Load Balancer，匹配生产请求路径；专用客户端节点组生成受控负载，模型服务器在单独的服务节点组隔离运行，以在高并发下确保零资源争用。所有结果使用网关默认路由配置，无需调优。
在混合GPU代际场景中，当小内存实例在较大实例能轻松处理的流量下饱和时，轮询仍持续把请求发给过载Pod，网关实时检测到这种失衡。在突发流量场景中，单个副本在过载和空闲之间循环，轮询无法平滑延迟尖峰，网关把请求转向有空闲容量的Pod。在共享提示前缀场景中，多轮对话和文档问答等负载跨请求共享公共提示前缀，EPP的前缀缓存命中率评分器把请求路由到已缓存该前缀的Pod，避免重复计算。
官方总结的规律是：机群越偏离均匀，收益越大；在完全均匀的机群和稳定流量下，副本利用率接近一致，网关表现与轮询相当。完整对比表中，混合GPU代际Llama-3.1-8B的TTFT P95和P99均降97%，吞吐加8%；混合GPU代际Qwen3-32B的P95降98%、P99降97%，吞吐加50%；突发流量Llama-3.1-70B的P95降94%、P99降98%，吞吐加12%；突发流量Qwen3-235B的P95为comparable、P99降89%、吞吐为comparable；共享提示前缀Llama-3.1-8B的P95降26%、P99降43%、吞吐comparable；均匀机群稳定流量Qwen3-235B三项均为comparable。
上述数字均为AWS在相同模型副本上对比Kubernetes轮询基线的测量结果，AWS把comparable定义为差异落在运行间波动范围内。
- 测试模型：8B到235B参数，覆盖p5.48xlarge（H100）和g5（A10G）
- 混合GPU代际Qwen3-32B：P95降98%，吞吐加50%
- 突发流量Llama-3.1-70B：P95降94%，P99降98%，吞吐加12%
- 共享提示前缀Llama-3.1-8B：P95降26%，P99降43%
- 均匀机群稳定流量：三项均为comparable
为什么强调Kubernetes原生，以及后续计划
AWS称该网关不是与Kubernetes并行的独立平台，而就是Kubernetes：符合Gateway API规范，构建在官方Kubernetes Gateway API及其Inference Extension上；声明式配置，一个InferenceGatewayConfig CRD定义整个路由拓扑；不锁定，适用于任何OpenAI兼容模型服务器，包括vLLM、SGLang、TGI；现有工具链kubectl、GitOps、Helm、ArgoCD照常使用；通过EKS附加组件生命周期，用aws eks CLI或控制台安装、升级和回滚。
可用性方面，SageMaker HyperPod Inference Gateway（第一层，每集群路由）从发布之日起在提供推理附加组件的区域可用。后续计划包括：第二层Global Inference Router，跨集群和跨区域的集中式机群网关、全局限流和成本分层流量整形；金丝雀流量拆分，通过InferenceModelRewrite CRD把一定比例流量路由到新模型版本；流控和优先级带，把请求分类为Critical、Standard或Sheddable，并做每带的准入控制。
上述‘可用区域’和‘后续计划’均为AWS博文披露内容，具体区域列表未在博文中逐一列出。
- 规范与可移植：Gateway API规范、OpenAI兼容服务器、现有GitOps工具链
- 生命周期：通过AWS CLI或控制台安装升级回滚
- 后续：GIR跨集群路由、金丝雀流量拆分、Critical/Standard/Sheddable优先级带