AWS SageMaker HyperPod 推理网关：首 token 延迟降低82%

消除 GPU 浪费。首 token 延迟最高降低 82%。安装一个 Kubernetes 原生插件，零应用改动。

问题：朴素路由在浪费你最贵的资源

在大规模 GPU 集群上运行大语言模型（LLM）代价高昂。默认的 Kubernetes 负载均衡器反而让情况更糟。轮询（round-robin）和最少连接（least-connections）算法对 GPU 内部正在发生的一切毫无感知：哪些 pod 的 KV cache 已经饱和，哪些正在处理长上下文生成的中途，哪些已经在内存中加载好了你的请求需要的 LoRA 适配器。

结果就是：轮询路由导致请求堆积在繁忙的 pod 后面，而空闲容量却无人问津。流量高峰期间，首 token 延迟飙升至 4 秒以上。GPU 利用率变得不均匀、不可预测。你通过过度配置来弥补，这烧的是那些没有在做有效工作的 GPU 的钱。

解决方案：SageMaker HyperPod Inference Gateway

今天，我们兴奋地宣布推出 Amazon SageMaker HyperPod Inference Gateway。这是一个 Kubernetes 原生的、GPU 感知的路由系统，部署为你现有 HyperPod 基础设施上的单个 EKS 托管插件。它利用实时 GPU 信号将每个推理请求路由到最合适的 pod，在不修改模型服务器或客户端应用的情况下提供更低的延迟。

"聊天机器人用户原本要等 4.4 秒才看到第一个 token，现在不到 800 毫秒就能看到。"

工作原理：两层架构

Inference Gateway 使用完全基于 Kubernetes 原生原语构建的两层设计。

图 1：Inference Gateway 的两层架构

第一层——每集群网关（EKS 托管插件）

第一层作为 amazon-sagemaker-hyperpod-inference 插件直接安装到每个 HyperPod/EKS 集群上。它由三个核心组件构成，全部基于开源的 Gateway API Inference Extension 构建：

高性能 L7 代理，终止传入的 HTTPS 流量，并为每个集群暴露一个私有端点。

检查每个传入的 OpenAI 兼容请求体，提取 model 字段，并路由到正确的模型池。支持多模型路由：一个网关，多个模型。

智能层。EPP 消费来自每个模型服务 pod 的实时 Prometheus 指标，并使用加权评分算法来选择最合适的后端：

• KV cache 利用率——避开 key-value 内存接近满的 pod
• 队列深度——避开请求积压严重的 pod
• LoRA 适配器驻留——优先选择已经加载了请求适配器的 pod
• 前缀缓存命中率——优先选择可能从缓存的提示前缀提供服务的 pod
• 运行中的请求——在全体舰队间平衡活跃工作

每个评分器都有一个可配置的权重，因此你可以为特定工作负载调整路由行为（延迟敏感的聊天与吞吐量优化的批处理对比）。

第二层——全局推理路由器（GIR）（即将推出）

第二层增加了跨多个集群和区域的舰队级协调，具备跨集群故障转移、全局速率限制和成本感知流量整形。第二层建立在第一层之上。每个集群的每集群网关继续处理本地智能路由。

5 分钟快速上手

Inference Gateway 通过单个插件安装和一个声明式的 InferenceGatewayConfig 自定义资源进行部署。无需 sidecar，无需服务网格，无需应用代码修改。

第一步：安装插件

aws eks create-addon \
  --cluster-name my-hyperpod-cluster \
  --addon-name amazon-sagemaker-hyperpod-inference \
  --addon-version v2.0.0-eksbuild.1 \
  --configuration-values '{"inferenceGateway": {"enabled": true}, "inferenceOperator": {"enabled": true}}'

第二步：为你的模型 pod 打标签

为现有的模型服务器部署添加一个标签，以便网关能发现它们：

spec:
  template:
    metadata:
      labels:
        app: vllm-llama # The gateway matches on this

第三步：应用网关配置

创建一个定义了你的模型和路由行为的 InferenceGatewayConfig 资源：

apiVersion: inference.sagemaker.aws.amazon.com/v1alpha1
kind: InferenceGatewayConfig
metadata:
  name: my-gateway
spec:
  tls: {}
  bbr:
    enabled: true
  schedulers:
    - name: llama-70b
      modelName: "llama-3.1-70b"
      modelSelector:
        matchLabels:
          app: vllm-llama
      targetPort: 8000
      scheduler: llm-d

第四步：发送推理请求

网关暴露一个标准 OpenAI 兼容端点。你现有的客户端代码无需修改即可工作：

curl -X POST "http://<gateway-endpoint>/v1/chat/completions" \
  -H "Content-Type: application/json" \
  -d '{"model": "llama-3.1-70b", "messages": [{"role": "user", "content": "What is Kubernetes?"}], "max_tokens": 100}'

就这样。没有 SDK 改动。推理流量不需要 SigV4 签名。标准 HTTP 加 OpenAI 兼容 schema。

在同一个集群上运行多个模型？Body-Based Router 原生处理这种情况。在配置中定义多个调度器，网关会根据请求体中的 model 字段自动将每个请求路由到正确的模型池。

一个网关。多个模型。应用中零路由逻辑。

在共享基础模型上服务微调的 LoRA 适配器？Inference Gateway 将适配器请求路由到已经在 GPU 内存中加载了适配器的 pod。这消除了昂贵的适配器交换延迟。

EPP 的 LoRA Affinity Scorer 识别哪些 pod 有所请求适配器驻留，并据此路由。如果没有 pod 加载了它，请求会被发送到有最大可用容量快速加载它的 pod。

优雅降级与自愈

网关在每个层面都优雅降级：

内置可观测性

网关在每个层面发出指标，所有指标都通过你现有的监控栈暴露：

• Pod 级别——KV cache 利用率、队列深度、运行中的请求、适配器驻留（Prometheus）
• 池级别——请求总数、延迟直方图、token 计数（Prometheus/Grafana）
• 集群级别——平均 KV cache、错误率、P99 延迟（Amazon CloudWatch）
• 舰队级别——路由决策、故障转移事件、速率限制命中（CloudWatch）

默认 Kubernetes 路由你正在浪费多少性能？为了找出答案，我们对从 8B 到 235B 参数不等的四个模型进行了基准测试，部署在 p5.48xlarge（H100）和 g5（A10G）实例上。所有流量都通过内部 Application Load Balancer 路由，与生产请求经过的路径完全一致。专用客户端节点组生成受控负载，而模型服务器在独立服务器节点组上运行，确保在高并发下零资源竞争。以下所有结果都使用网关的默认路由配置，无需调优。

GPU 感知路由在轮询最难处理的场景中带来最大收益。我们针对四个模型（8B 到 235B 参数）测试了三个现实场景。

混合 GPU 代际

在生产中，GPU 舰队很少是统一的。当内存较小的实例在流量下饱和，而其更大的同伴却能轻松处理时，轮询继续向过载的 pod 发送请求。Inference Gateway 实时检测这种不平衡。

图 2：混合 GPU 代际，轮询基准与 Inference Gateway 对比

突发需求

大多数 LLM 工作负载中，突发需求是常态。单个副本在过载和空闲之间循环，造成轮询无法平滑的延迟峰值。网关通过将请求引导至有可用容量的 pod 来吸收这些突发。

图 3：突发流量，轮询基准与 Inference Gateway 对比

共享提示前缀

多轮对话和文档问答等工作负载在请求间共享一个公共提示前缀。网关的前缀缓存命中率评分器将这些请求路由到已经缓存了该前缀的 pod，避免冗余计算。

图 4：共享提示前缀，轮询基准与 Inference Gateway 对比

所有三个场景的模式是一致的：你的舰队越偏离统一配置，你获得的收益就越大。在完全统一的舰队和稳定流量下，各副本保持接近相同的利用率，网关性能与轮询相当。这使得智能路由在生产流量实际创造的条件——混合硬件、突发需求和共享提示前缀——下最有价值。你可以直接开启它，无需先手动调优任何东西。

性能改进总结

所有数字均相对于同一模型副本上的 Kubernetes 轮询基准测量，使用网关的默认路由配置。

"相当"意味着差异在运行间差异范围内。

为什么 Kubernetes 原生很重要

Inference Gateway 不是你部署在 Kubernetes 旁边的独立平台。它就是 Kubernetes：

• 符合 Gateway API 规范——基于官方 Kubernetes Gateway API 及其 Inference Extension 构建
• 声明式配置——一个 CRD（InferenceGatewayConfig）定义你的整个路由拓扑
• 无锁定——兼容任何 OpenAI 兼容的模型服务器（vLLM、SGLang、TGI 等）
• 现有工具——kubectl、GitOps、Helm、ArgoCD——都按预期工作
• EKS 插件生命周期——通过 aws eks CLI 或控制台安装、升级和回滚

SageMaker HyperPod Inference Gateway（第一层，每集群路由）已在推理插件可用的区域正式推出。

即将推出：

• 第二层：全局推理路由器（GIR）——通过集中式舰队网关、全球速率限制和成本层级感知流量整形，实现跨集群和跨区域智能路由
• 金丝雀流量拆分——使用 InferenceModelRewrite CRD 将一定比例的流量路由到新模型版本
• 流量控制和优先级频段——将请求分类为 Critical、Standard 或 Sheddable，并提供按频段的准入控制

准备好停止在朴素路由上浪费 GPU 容量了吗？安装 Inference Gateway 插件，几分钟内就能看到首 token 延迟的改善，而不是几周。