AWS 推出推理网关，首字延迟最多降 82%

AWS 发布 Amazon SageMaker HyperPod Inference Gateway，这是一套面向 GPU 集群上大语言模型（LLM）服务的 Kubernetes 原生路由系统。它以单个 EKS 托管插件的形式装在已有的 HyperPod 基础设施上，依据实时 GPU 信号把每个推理请求投递到最合适的 pod。AWS 称首字延迟最多可下降 82%，其中一个例子是聊天用户的等待时间从 4,4 秒降到 800 毫秒以内。

AWS 指出的问题在于：Kubernetes 默认的负载均衡器看不到 GPU 内部状态。轮询和最少连接算法并不知道哪些 pod 的 KV 缓存已经饱和、哪些正处在长上下文生成中途、哪些已经把请求所需的 LoRA 适配器加载进显存。结果是请求堆在繁忙的 pod 后面，空闲算力却没人用；流量突增时首字延迟超过 4 秒。

两层架构，无需改代码

第一层以 amazon-sagemaker-hyperpod-inference 插件装在每个集群上，构建在开源项目 Gateway API Inference Extension 之上，包含三个组件：终结 HTTPS 流量并为每个集群暴露单一私有端点的 L7 代理；读取 OpenAI 兼容请求体中 model 字段、把请求转给对应模型池的请求体路由器；以及 EPP 智能层，它采集每个服务 pod 的 Prometheus 指标，用加权打分算法挑选后端。各打分器权重可配置，延迟敏感的对话场景与吞吐优先的批处理可以分别调优。第二层在多集群、多区域之间增加跨集群故障切换、全局限流和成本感知的流量分配。

部署只需给现有模型服务部署打一个标签，再创建一个声明式的 InferenceGatewayConfig 资源，不用 sidecar、不用服务网格、不改应用代码，客户端仍通过标准 HTTP 访问 OpenAI 兼容端点。LoRA 亲和打分器会把适配器请求送到已加载该适配器的 pod，省掉切换开销；若没有 pod 已加载，则交给可用容量最多的 pod。

AWS 在 p5.48xlarge（H100）与 g5（A10G）实例上测试了 8B 到 235B 参数的四个模型，全部流量经内部 Application Load Balancer。官方称在混合 GPU 世代、突发流量和共享提示前缀三类场景中收益最大，集群越不均匀，提升越明显。

配置细节见 AWS 官方公告。