深入理解 SageMaker HyperPod 的异构 GPU 调度：从 Whisper 部署看 EKS 集群架构设计

本文以 Whisper 语音识别模型为例，深入分析 SageMaker HyperPod Cluster 的架构原理，包括异构 GPU 节点调度、TensorRT-LLM 编译优化、Triton 推理服务部署，以及基于 AMP/Grafana 的可观测性体系搭建。

为什么要聊这个

我最近在做一个语音识别服务的部署。模型是 Whisper，跑在亚马逊云科技上。

这个项目有个特殊需求：需要同时用 g5（NVIDIA A10G）和 g6e（NVIDIA L40S）两种实例。原因很简单，单一机型的容量不够。

这就引出了一个架构问题：如何在一个统一的服务入口下，调度不同 GPU 架构的推理节点？

用 SageMaker 托管 Endpoint 做不到——它不支持异构 GPU。用裸 EKS 可以，但管理成本高。SageMaker HyperPod Cluster 是个折中方案：SageMaker 帮你管 EKS 集群的生命周期，你只需要关注工作负载。

这篇文章我会从架构原理的角度，把整个方案拆解清楚。

架构分层

整个方案可以拆成四层：

┌─────────────────────────────────────┐
│          NLB（统一入口）              │
├─────────────────────────────────────┤
│    Triton Inference Server Pods     │
│  ┌─────────────┐ ┌───────────────┐  │
│  │  g5 节点组   │ │  g6e 节点组   │  │
│  │   (A10G)    │ │    (L40S)     │  │
│  └─────────────┘ └───────────────┘  │
├─────────────────────────────────────┤
│     HyperPod 托管 EKS 集群          │
├─────────────────────────────────────┤
│   S3 (模型存储)  │  ECR (镜像)      │
└─────────────────────────────────────┘

模型层：TensorRT-LLM 编译

Whisper 的推理链路包含两部分：音频编码器（Encoder）和文本解码器（Decoder）。TensorRT-LLM 会分别对两部分做计算图优化和内核融合。

关键点：编译产物和 GPU 架构强绑定。

A10G（Ampere 架构）和 L40S（Ada Lovelace 架构）的 CUDA Compute Capability 不同。TensorRT-LLM 编译时会生成针对特定架构的优化内核。这意味着必须为每种 GPU 分别编译模型。

这不是小事。我第一次部署时忽略了这个，只编译了 g5 的版本，部署到 g6e 后 Triton 直接报模型加载失败。排查了两个多小时才搞清楚根因。

服务层：Triton Inference Server

Triton 承担模型加载和推理请求处理。它的优势在于：

• 多模型 pipeline 支持：Whisper 的 Encoder + Decoder 可以作为一个 pipeline 部署
• 动态 batching：自动对并发请求做批处理，提升 GPU 利用率
• 兼容 TensorRT-LLM 后端：直接加载编译产物

模型文件通过 S3 CSI Driver 挂载到 Pod 里。这里有个细节——挂载时的 subPath 参数必须和 S3 里的实际路径完全匹配。

集群层：HyperPod EKS

HyperPod 创建的 EKS 集群和普通 EKS 没有本质区别，但它帮你做了几件事：

1. 集群生命周期管理（创建、升级、健康检查）
2. 节点组管理（支持异构 GPU）
3. 基础组件安装（可选的 operator、CSI driver 等）

创建集群时有几个需要注意的参数：

git clone https://github.com/aws-samples/finetune-and-deploy-whisper-models.git
cd finetune-and-deploy-whisper-models/deployment/sagemaker_triton_tensorrt_llm/hyperpod_hybrid

Instance group 配置要点：

• g5.2xlarge 和 g6e.2xlarge 各建一个节点组
• Threads per core 设为 2（默认值 1 会禁用超线程）

Threads per core 的默认值让我踩了个坑。设为 1 时，物理核心的超线程被关闭，CPU 有效核数减半。对于 Triton 这种需要 CPU 做预处理（音频解码、base64 解码等）的场景，影响很明显——Pod 启动变慢，请求处理延迟也会增加。

网络层：NLB 负载均衡

NLB 的作用是把外部请求路由到后端的 Triton Pod。NLB 工作在 TCP 层（L4），延迟低、吞吐高。

部署流程：

# 部署 S3 CSI Driver
./create_s3_csi_driver.sh \-c <EKS集群名称> \-r <region> \-b <模型bucket># 部署 LB Controller
./create_lb_controller.sh \-v <VPC ID> \-c <EKS集群名称># 上传脚本 & 部署服务
./upload_scripts_to_s3.sh
./deploy_pv_scripts.sh

部署完成后：

kubectl get svc

NAME                          TYPE           CLUSTER-IP      EXTERNAL-IP                                                 PORT(S)
whisper-triton-unified-nlb    LoadBalancer   172.20.243.41   k8s-default-whispert-xxxxx.elb.us-east-1.amazonaws.com      8080:30807/TCP,10086:31511/TCP

NLB 地址拿到后，就可以测试了：

curl -X POST http://<NLB地址>:8080/invocations \-H "Content-Type: application/json" \-d "{\"audio_data\": \"$(base64 -i test.wav)\", \"whisper_prompt\": \"\"}" | jq .

{"code": 0,"message": "Success","transcribe_text": " I want to play Søya."
}

可观测性：AMP Scraper + Grafana

生产环境的推理服务必须有监控。这个方案用的是 Amazon Managed Prometheus（AMP）的托管 Scraper 功能。

Scraper 是一个无代理采集器。它直接从 EKS 集群内部拉取 Prometheus 格式的 metrics，不需要你在集群里部署 Prometheus server。

配置步骤

先开启 EKS Private Access：

aws eks update-cluster-config \--name <集群名称> \--region <region> \--resources-vpc-config endpointPrivateAccess=true,endpointPublicAccess=true

然后在 EKS 控制台添加 Scraper，上传配置文件。

验证采集：

pip3 install awscurlWORKSPACE_ID="<AMP Workspace ID>"
REGION="us-east-1"
ENDPOINT="https://aps-workspaces.${REGION}.amazonaws.com/workspaces/${WORKSPACE_ID}"awscurl --service aps --region $REGION \"${ENDPOINT}/api/v1/query?query=nv_inference_request_success" | python3 -m json.tool

Grafana 指标体系

在 Amazon Managed Grafana 里导入仪表板后，能看到的核心指标：

推理性能类：

• Inference Request Rate — 成功/失败请求速率
• Average Request Latency — 总延迟 / 队列延迟 / 计算延迟
• Compute Time Breakdown — Input / Infer / Output 耗时分解
• Inference Throughput / Execution Throughput

资源利用类：

• GPU Utilization — 利用率（可设阈值告警）
• GPU Memory Usage — 显存使用
• GPU Power Usage — 功耗

负载类：

• Pending Requests — 待处理请求数
• Queue Time — 队列等待时间
• Load Ratio — 总时间/计算时间的比值

Load Ratio 这个指标值得关注。如果它远大于 1，说明大量时间花在排队而不是计算上，可能需要扩容。

踩坑全记录

层级	问题	根因分析	解决方案
模型层	g6e 加载失败	TensorRT-LLM 编译产物和 GPU 架构绑定	分别为 A10G / L40S 编译
集群层	Pod 启动慢	Threads per core=1，超线程被禁用	改为 2
存储层	Triton CrashLoop	subPath 错误导致挂载目录为空	核对 S3 路径
权限层	节点组创建失败	GPU 实例 Quota 不足	Service Quotas 提额

HyperPod vs 托管 Endpoint：架构选型对比

维度	托管 Endpoint	HyperPod Cluster
异构 GPU	不支持，需多 Endpoint	支持，一个集群多节点组
负载均衡	需客户端自行路由	NLB 统一入口
弹性伸缩	SageMaker 内置	K8s 生态（Karpenter 等）
可观测性	CloudWatch	AMP + Grafana
运维复杂度	低（但灵活性低）	中（灵活性高）

选型建议：单一机型、简单场景用托管 Endpoint。多机型混合部署、需要精细运维的场景用 HyperPod。

小结

这篇文章从架构设计的角度剖析了 SageMaker HyperPod 部署 Whisper 模型的方案。核心是理解四层架构——模型编译、推理服务、集群调度、网络暴露——每一层都有需要关注的细节。

相关资源：

• Amazon SageMaker
• GitHub 部署仓库
• Amazon EKS