详细内容或原文请订阅后点击阅览
使用 InstantStart 运行代理驱动的 Amazon SageMaker HyperPod 操作
HyperPod InstantStart 是一个开源控制平面，它将 Amazon EKS 编排与 Amazon SageMaker HyperPod 的托管功能组合在一起。它通过 Web 界面和 AI 代理驱动相同的受保护操作，将集群引导、容量、训练、推理和存储转变为可靠的代理驱动的基础设施。
来源:亚马逊云科技 _机器学习如果您在 Amazon SageMaker HyperPod 上运行基础模型 (FM) 工作负载，您就会知道这项工作很少是单一任务。它是一个依赖链。基础设施团队创建网络和控制平面，附加加速器容量，并按正确的顺序安装集群依赖项。它还准备存储和身份，通过硬件故障保持分布式作业的活动，部署模型服务器，并监视所有这些。每个步骤都有自己的 API、自己的失败模式和自己的等待期。大多数运营难题都来自于他们之间的交接。
Amazon SageMaker HyperPod 消除了大部分负担。它提供托管、弹性计算和 Amazon EKS 集成功能，用于运行状况监控、节点自动扩展、训练恢复和推理。Amazon Elastic Kubernetes Service (Amazon EKS) 保留了用户管理的编排界面。这使您的团队可以直接访问 Kubernetes。它还使您的团队负责将 AWS 资源、附加组件、工作负载和第二天的操作组合成一个连贯的整体。
HyperPod InstantStart 是一个围绕该组合问题构建的开源控制平面。它为您提供了两种驱动同一控制平面的方法。在 Web 界面中，创建安装了依赖项、打开自动节点恢复并安装了存储的集群是一个表单、一个进度面板和一个刷新按钮。在终端中，它是一个句子。
[hypd-inst-agent] > 帮我创建一个新的 HyperPod 集群
然后，AI 代理会规划多阶段工作流程、启动每个阶段，并轮询异步 AWS 操作是否完成。仅当您真正做出决定时，它才会暂停，例如可用区、实例类型和容量类型。然后它交还一个安装了存储的正在运行的集群。两个接口都调用相同的后端 API，通过相同的验证，并读取相同的持久操作状态。两者都没有对方所缺乏的私人逻辑。
在这篇文章中，我们将介绍这两个界面下的系统。我们展示了它如何将集群引导、容量、训练、推理和存储转变为受保护的、可重试的操作。我们介绍了哪些部分是 HyperPod 托管功能以及项目添加了哪些部分。我们还解释了为什么将操作规则编码到控制平面 API 中，而不是向代理提供原始 CLI，才使得代理驱动的基础设施变得可靠。
解决方案概述
HyperPod InstantStart 在您的 AWS 账户中作为单个带外管理容器运行。它调用AWS服务API和Kubernetes API。它不位于训练作业或推理请求的数据路径中。它创建的所有内容都是标准的 AWS 或 Kubernetes 资源。您可以使用 AWS 命令行界面 (AWS CLI) 和 kubectl 检查它。
下图说明了解决方案架构以及责任易手的位置。
从左到右阅读图表。您的基础架构团队推动一个切入点。 AI 代理使用的 Web UI、REST API 和模型上下文协议 (MCP) 工具是同一容器的三个面，因此两个界面都通过一扇门进入。它们背后是本文其余部分描述的分阶段配置和幂等协调逻辑。控制平面从那里调用两个 API 表面。
InstantStart 将此环境组织为四层。
一项设计原则将两个界面联系在一起。 MCP 工具包装后端自己的 REST API、浏览器调用的确切代码路径，而不是 AWS CLI 或 SDK，因此添加一次验证即可保护两者。我们回到为什么这对代理商很重要。首先，让我们看看控制平面如何完成其主要工作。
Kubernetes 端是 Amazon EKS，它由用户管理。它包含 Kubernetes API、作为 EKS 附加组件安装的 HyperPod 训练和推理运算符，以及它们协调到训练和推理 Pod 中的 HyperPodPyTorchJob 和 InferenceEndpointConfig 资源。 AWS 端是 Amazon SageMaker HyperPod，由 AWS 管理。其功能分为四组。基础设施涵盖健康监控、深度健康检查、节点自动恢复等。容量涵盖持续配置和托管的 Karpenter 自动缩放。培训涵盖流程级恢复和托管分层检查点。推理涵盖智能路由和分层键值 (KV) 缓存。
这两部分在 HyperPod 实例组处相交。 Kubernetes 将 Pod 调度到它们上，由 HyperPod 管理它们。这是当某些事情需要关注时需要了解的最有用的信息，因为它告诉您哪一半 AWS 在您不参与的情况下运行和修复。 AWS 集成围绕该路径进行，该图显示了存储和可观测性集成。Amazon Simple Storage Service (Amazon S3)、Amazon FSx for Lustre 和 Amazon Elastic Container Registry (Amazon ECR) 承载图像、数据和检查点。 Amazon Managed Service for Prometheus 和 Amazon Managed Grafana 获得运行状况和利用率。 Amazon SageMaker AI 上的托管 MLflow 还接收指标和工件。
先决条件
使用最低权限 IAM 角色进行部署和持续操作。遵循有关 CloudFormation 访问控制和 SageMaker HyperPod IAM 的 AWS 指南，并限制 Amazon S3 对指定项目存储桶的访问。两项容量项目需要 AWS 周转时间，因此请尽早启动。请求增加您打算运行的每种实例类型上的集群使用率的 Amazon SageMaker 服务配额，对于高端加速器类型，请购买 Amazon SageMaker 灵活培训计划以预留容量。还要检查您的 Virtual Private Cloud (VPC) 配额，因为分阶段配置路径默认为每个集群创建一个 VPC。
创建集群：对话和控制台
从空帐户迁移到可用的 HyperPod 容量需要几个长期运行的、依赖于订单的阶段。 InstantStart 特意将它们分为 EKS 控制平面创建、活动集群选择、依赖关系协调、HyperPod 集群创建和存储设置。将它们分开意味着后期阶段的失败不会回滚已经成功的早期阶段。 EKS 控制平面创建大约在 8-12 分钟内完成。每个后续阶段都会记录自己的状态并且可以独立重试。
本记录中的三个行为来自项目代理技能中编码的工作流程规则，而不是即兴创作。
两种服务模型
通过Web界面，这是集群管理页面。您输入集群标签，创建并观察分阶段进度指示器。通过代理，整个管道就是一个对话。以下是与 hypd-inst-agent 的真实会话的精简记录，hypd-inst-agent 是 Kiro CLI 的代理配置，用于加载项目的 MCP 服务器和技能。
1.创建EKS集群（大约8-12分钟）
2.切换到新集群并验证
3.安装依赖
4.创建HyperPod集群5.配置S3存储6. 最终验证我先检查一下现有的集群情况：运行工具 cluster_list_all （来自 mcp 服务器：hypd-inst）> 目前有 2 个现有集群。您想为新集群指定一个标签名称，还是我应该自动生成一个标签名称？[hypd-inst-agent] > 继续运行工具 cluster_create_eks {"clusterTag": "hypd-0304b"}> EKS 集群创建已开始。我会每 2 分钟检查一次进度。运行工具 wait_seconds {"seconds": 120}运行工具 cluster_get_eks_creation_status> 仍在创作（大约 4 分钟过去了）。继续等待……...> 第 1 步完成！ EKS 集群 hypd-0304b 已成功创建。...> 第 3 步完成！所有依赖项均已成功安装。现在我需要您提供以下信息来创建 HyperPod：可用区、GPU 实例类型、实例计数和容量类型（按需或培训计划）？[hypd-inst-agent] > us-west-2c，一台 g6.4xl运行工具 hyperpod_create {"AcceleratedInstanceType": "ml.g6.4xlarge", "AcceleratedInstanceCount": 1, "availabilityZone": "us-west-2c", ...}...> HyperPod 集群创建完全完成！摘要：| EKS集群| eks-cluster-hypd-0304b | eks-cluster-hypd-0304b| HyperPod 集群 | hp-cluster-hypd-0304b | hp-cluster-hypd-0304b|节点| 1x ml.g6.4xlarge（按需）||节点状态 |准备好/可安排|| S3 存储 | s3-claim 安装 |代理轮询完成。每个长时间运行的操作后面都会跟着 wait_seconds 和状态工具，直到达到最终状态。代理人不允许提前停车并告诉您稍后再回来查看。对话以经过验证的集群结束，而不是提交的请求。代理仅询问决策级问题。集群标签、可用区、实例类型和容量类型由您决定。子网 CIDR、路由表、安全组和安装顺序则不然。它们是控制平面的工作。代理在创建之前进行检查。它首先列出现有集群。它在提供选择之前查询有效的可用区和实例类型，因此您看到的选项是该账户和区域实际可以满足的选项。对话中未提及的网络显示了控制平面的编码内容。 AWS CloudFormation 路径可以创建或重用 VPC。它将 EKS 控制平面子网与 HyperPod 计算子网分开，因为它们的地址空间需求存在一个数量级的差异。计算子网的大小为 /20，可容纳大型加速器组。每条容量路径都通过一个具有固定优先级的函数 ensureComputeSubnet()。它使用显式指定的子网，或重用兼容的每可用区子网，或创建一个包含路由表和 S3 网关端点关联的完整子网。集群的创建和后来的扩容都是这个逻辑，所以网络布局就只有一个地方可以对也可以错。容量选择，默认为弹性下面的屏幕截图显示了“添加实例组”表单，其中这些选择成为一个创建时步骤。
控制平面存在后，容量管理就成为经常性的操作。您可以为新工作负载添加实例组，选择支付方式，并信任控制平面使其保持正常运行。
网络接口模式。具有多个网卡的实例类型可以请求仅 EFA 接口，从而节省 VPC IP 地址。此设置在创建组后固定。 InstantStart 将其显示为创建时字段，而不是让您从被拒绝的更新中发现不变性。
子网放置。默认情况下，组共享每个可用区的计算子网。大型组可以请求专用子网以避免 IP 耗尽，并且该子网故意比该组寿命更长，以便后继者可以重用它。
图 2：添加实例组表单，其中容量选择成为创建时的一个步骤
一些实例组字段是不可变的，而其他字段很容易丢失。因此控制平面不会手动组装更新请求。每当它重新提交实例组时，它都会通过显式字段白名单对该组进行规范化。 OnStartDeepHealthChecks 和 NetworkInterface 等设置会继承，因此不相关的扩展操作无法静默重置组的运行状况检查或 EFA 配置。无论请求来自 Web 界面还是 MCP 工具调用，都会运行相同的规范化。
托管 Karpenter：无需运行 Karpenter 即可自动缩放
静态实例组设置您拥有的容量。HyperPod 托管的基于 Karpenter 的节点自动缩放决定其在任何时刻运行的数量。 AWS 本身运行 Karpenter 控制器，节点从从零开始扩展的 HyperPod 实例组启动，而不是从原始 Amazon EC2 启动。因此，自动缩放容量继承了前面描述的运行状况监控和自动节点恢复，而不是作为非托管实例到达。调度仍然是绑定到 HyperpodNodeClass 的标准 Karpenter NodePool，InstantStart 提供了工作默认值，包括将空闲组缩小到零的整合。由于控制平面已经默认为连续配置和自动恢复，因此启用托管 Karpenter 是一种经过验证的切换，而不是操作手册。一项范围说明：HyperPod 托管 Karpenter 管理 HyperPod 实例组，而不是通用 Amazon EC2 容量。
将托管功能作为协调状态，而不是 Runbook
以下屏幕截图显示了“高级功能”面板，其中每个切换都映射到一个后端操作。
通过代理，整个面板就是一个交换。
可观察性
HyperPod 提供了多种托管功能，并且每种功能都有记录的多步骤设置。其中包括训练运算符、推理运算符、托管分层检查点和托管自动缩放。 InstantStart 将它们显示在一个“高级功能”面板中。该值不是复选框。每个复选框都映射到一个依赖项感知的后端操作。
图 3：高级功能面板，其中每个切换都映射到依赖项感知后端操作
例如，启用托管分层检查点不仅仅是翻转集群设置。托管分层检查点使用多个存储层，包括集群 CPU 内存。持久检查点需要身份链、Kubernetes 服务帐户、IAM 角色和策略、OpenID Connect (OIDC) 信任关系以及将它们绑定在一起的注释。切换开关规定端到端的链接，禁用它会删除相同的链接。服务账户 (IRSA) 的半配置 IAM 角色是 EKS 上调试起来最不愉快的事情之一，因此该操作在两个方向上都是闭环的。
小组还给项目上了一堂关于幂等性的课。早期的实现将每个表单值提交为所需的状态，这产生了一个真正的错误。当 cert-manager 不存在时，启用推理运算符会将 cert-manager 作为依赖项安装。该表单的 cert-manager 字段仍然具有陈旧的值。后来的一个不相关的提交则删除了刚刚安装的依赖项。解决方案是一个显式差异合同。界面仅提交用户实际触摸的字段。后端检查字段存在，读取实际集群状态，并在实际状态和请求状态已经匹配时执行无操作。该合同以相同的方式应用于 UI 请求和 MCP 请求，这正是可以信任代理调用同一端点的原因。
[hypd-inst-agent] > 帮我安装分层存储和训练算子
运行工具 hyperpod_get_advanced_features
> 目前两者均未启用。我会让他们一起。
运行工具 hyperpod_update_advanced_features {"tieredStorage": {"enabled": true, "configMode": "default"}, "trainingOperator": {"enabled": true}}
> 两项功能均已成功启用。
代理首先读取当前状态并仅发送请求的两个功能。后端独立地协调每个。网络表单遵循同样的三部分规则。训练：两个提交路径和一个配方层训练表面将两个决策分开。如何提交作业并使其保持活力就是其中之一。作业运行哪个框架是另一个问题。控制平面在底部为您提供了两个任务提交路径，在顶部提供了一个配方层。采用新的培训框架并不意味着采用新的运营模式。训练和服务共享同一个集群，控制平面为它们各自提供两条路径。下图说明了所有四个、它们上方的配方层以及它们所在的基材。突出显示的框标记了 HyperPod 托管功能的应用位置，下面的部分将依次介绍每个路径。图 4：两个训练路径和两个推理路径、它们上方的配方层以及共享的 HyperPod 基底任务层：通过训练算子或者KubeRay可恢复提交运行策略：作业最大重试次数：5重启策略：完整作业重启前的重启次数：3evalPeriod秒：21600最大完整作业重新启动次数：1cleanPodPolicy：全部配方层：框架作为配置下面的屏幕截图显示了托管推理表单，其中 KV 缓存和智能路由在端点旁边声明。
第一条路径是 Amazon SageMaker HyperPod 训练操作员。它添加了进程级故障恢复、通过日志模式监控进行的挂起作业检测以及分布式训练的异常值检测。单个失败的进程不再需要重新启动整个多节点作业。 InstantStart 将其作为 EKS 插件安装，并将工作作为 HyperPodPyTorchJob 资源提交，恢复策略在工作负载规范中可见，而不是隐藏在默认值中。
将其视为恢复预算。在六小时的评估窗口内最多重新启动三个就地流程，然后操作员升级为单个完整作业重新启动。容器通过 hyperpodrun 而不是 torchrun 启动，并且操作员注入拓扑值，例如 NNODES 和 NPROC_PER_NODE。这消除了分布式启动错误配置的最常见来源，同时保持合约的精简。您携带自己的映像和 shell 入口点。它还极大地简化了您需要手动组装的 PyTorch 分布式配置。
第二条路径是标准 KubeRay，InstantStart 根据前面描述的高级功能面板的请求进行安装。一些工作负载在设计上是 Ray-native 的，最显着的是强化学习，其中头节点协调部署和培训工作人员。对于这些人来说，强迫他们通过 PyTorch 作业抽象将是错误的形式。 Ray 集群和作业作为一流工作负载提交到相同的 HyperPod 节点上，具有相同的存储安装和相同的监控视图。选择路径是关于工作负载编排模型的声明，而不是控制平面中的分支。
在任务层之上，该项目提供了集成广泛使用的培训框架的配方。切换框架改变的是形式，而不是你的操作。
配方提供了简单的 PyTorch 脚本、LLaMA-Factory、MS-Swift 和 VERL 强化学习，这是 KubeRay 路径上的最后一个。每个都需要一个入口脚本或一个框架配置文件，并且存储库记录每个框架的字段。
配方共享一个数据契约。相同的 S3 存储桶安装在开发环境中的 ~/workspace/s3 和 pod 内的 at/s3。您可以在本地编辑训练脚本或数据集定义，下一个作业会选择它，而无需重建图像。通过训练操作符运行的配方会继承其恢复行为，而无需针对每个框架进行工作。这就是分离两层的回报。
培训还连接到第二天的工作流程。作业日志通过 WebSocket 流式传输到浏览器。每个配方都可以选择报告指标，例如 Amazon SageMaker AI 上托管 MLflow 的训练吞吐量。 InstantStart 自动执行训练 Pod 用于写入运行的服务账户 IAM 路径，并且 UI 读取运行历史记录以进行显示，包括在细粒度 IAM 权限下的跨账户实验共享。一份准确性说明。托管 MLflow 是一项 Amazon SageMaker AI 功能，稍后描述的 CSI 驱动程序是 Amazon EKS 功能。 InstantStart 的贡献是将它们连接到工作流程中，而不是重新实现它们。
为了推理，控制平面提供了两条具有真正不同所有权模型的路径。保留两者是一个深思熟虑的选择，而不是一个过渡。
托管路径将生命周期交给 HyperPod 推理运算符。您以声明方式描述终端节点，包括 Amazon S3 中的模型位置、工作线程映像、调用端口、GPU 资源和副本。操作员将其协调为模型工作人员、负载平衡和 TLS。两个托管功能是选择此路径的主要原因，并且两者都与端点一起声明。
是什么让控制平面代理就绪
kvCacheSpec：
启用L1Cache：true
启用L2Cache：true
l2Cache规格：
l2CacheBackend：分层存储
智能路由规格：
启用：真
路由策略：前缀感知
托管分层 KV 缓存在 CPU 内存中保留 L1 缓存，并由 Redis 或 Amazon SageMaker 托管分层存储支持的 L2 层。智能路由提供前缀感知、KV 感知、会话和循环策略。 InstantStart 的工作是验证和生成。它呈现配置，检查必须彼此一致的部分，并将协调留给操作员。
图 5：托管推理形式，在端点旁边声明了 KV 缓存和智能路由
自我管理路径部署您选择的服务容器，例如 vLLM、SGLang 或您自己的容器，作为标准 Kubernetes 部署。它提供三种服务形态：外部负载均衡器、集群内部服务或模型池。该池使标记为“业务=未分配”的 GPU 工作线程保持温暖。将一个重新分配给服务会更改标签，而不是重新创建 Pod 并重新加载权重。缩减拒绝删除仍然绑定到服务的工人。对于多副本 SGLang 服务，控制平面还可以部署具有缓存感知路由的 SGLang 路由器，并通过 Kubernetes 事件驱动的自动扩展 (KEDA) 驱动自动扩展。扩展目标是模型工作人员，而不是提供指标的路由器。
通过代理部署显示了工具合约中的护栏。该项目的部署技能禁止从张量并行标志推断 GPU 计数，因此代理确认了这一点。[hypd-inst-agent] > 帮我部署： vllmserve Qwen/Qwen3-0.6B --max-model-len 1280 --tensor-parallel-size 1> 部署之前我需要确认：此部署需要多少个 GPU？ （--tensor-parallel-size 是模型并行参数；我需要您确认实际的 GPU 分配。）运行工具cluster_get_status> 集群当前有 1 ml.g6.4xlarge 节点和 1 个可用 GPU。[hypd-inst-代理] > 1运行工具 inference_deploy_container {"deploymentCommand": "vllmserve Qwen/Qwen3-0.6B --max-model-len 1280 --tensor-parallel-size 1", "gpuCount": 1, "serviceType": "clusterip", ...}> 部署已创建。让我测试一下：运行工具 inference_call_model {"service_name": "vllm-model-260304-100458-service", "prompt": "您好！您能简单介绍一下自己吗？"}> 模型测试成功。回应：“你好！我是一个语言模型，旨在协助完成诸如回答问题之类的任务......”对话按照操作应有的方式结束。部署的模型响应请求。没有资源 ID，也没有假设。模型和存储支撑这两条路径。控制平面通过 Amazon S3 CSI 驱动程序的 Mountpoint 挂载 Amazon S3 以获取主要读取的模型工件，并通过 Amazon FSx for Lustre 挂载 Amazon S3 以获取高吞吐量读/写训练数据和检查点。从 Hugging Face 下载模型作为仅 CPU 的 Kubernetes 作业运行，因此在字节移动时没有 GPU 闲置。该作业将文件暂存在实例 NVMe 上，然后将其复制到对象存储挂载。该数据传输实践在作业模板中编码一次，并由两个接口重用。下图说明了代理控制路径。图 6：座席控制路径，从座席技能通过 MCP 工具到共享后端 API内置最佳实践。这些工具包装了项目的后端 API，因此配置遵循控制平面的编码规则，而不是随着代理的即兴创作而漂移。每个操作都需要一次工具调用，而不是占用上下文窗口空间的一长串 CLI 调用。注意事项
到目前为止所描述的一切都证明 InstantStart 作为自助服务 Web 解决方案是合理的。代理界面，该项目称之为代理驱动的人工智能基础设施，是那些相同的设计选择再次获得回报的地方。启动代理并说明结果。经过几次决策级交互后，你会得到以下三件事之一。协调了依赖关系、启用了自动节点恢复并安装了存储的集群。响应请求的模型部署。或者端到端协调的托管运营商配置。实现分为三层。
按设计进行工作流编排。技能定义多步骤业务流程，因此代理不会重新规划每个会话的执行路径。工作流程在运行和模型版本之间保持可重复性。
零本地设置。后端和 MCP 服务器装在同一个容器中，因此代理环境除了代理本身之外不需要本地安装的工具链。
网络界面所需的可靠性合同也正是代理所需要的。操作在轮询开始之前保持其阶段，因此状态查询不会与拥有状态转换的进程竞争。浏览器刷新不会重播突变，代理也不会重试。 API 响应是成功或失败的唯一权威，因此代理（如 UI）不需要协调冲突信号。显式差异功能契约意味着启用一种功能的代理不会对其他功能携带任何隐藏意图。
操作并不完整，仅仅因为 API 接受了它，并且两个接口都不会这样对待它。 “监控”页面显示节点运行状况、GPU 总数和可用性，以及 Pod、服务、部署、InferenceEndpointConfig 和 HyperPodPyTorchJob 资源的实时视图，并且代理通过状态工具读取相同的状态。对于车队级指标，HyperPod 通过 HyperPod 可观测性插件将仪表板发布到 Amazon Managed Service for Prometheus，并在 Amazon Managed Grafana 中提供仪表板。
下面的屏幕截图显示了监控页面，左侧是集群状态，右侧是实时工作负载状态。
结论
也有明确的界限。在与您确认相关参数后，配置工作流程可能会更改状态。捆绑的诊断技能改编自针对 NCCL、节点运行状况和集群创建故障的 AWS agent-plugins/sagemaker-ai 集合，遵循更严格的策略。他们自己进行只读调查，提出状态更改命令作为建议，然后等待批准。他们按照调查、重新启动、然后更换的顺序升级。在这两种策略之下，IAM、Kubernetes 授权、网络控制和后端验证仍然是实际的安全边界。代理扩大了对控制平面的访问。它并没有扩大其特权。
图 7：监控页面，显示集群状态以及实时工作负载状态
同样重要的是，控制平面不会成为状态存在的唯一地方。生成的自定义资源、部署、节点标签和 AWS 资源可以通过 kubectl 和 AWS CLI 进行检查，这对于信任和故障排除都很重要。
成本和配额涉及服务。Amazon EKS、HyperPod 实例、存储、负载均衡、托管可观察性和托管 MLflow 都出现在账单上。 Amazon SageMaker HyperPod 集群使用配额以及高端 GPU 类型的训练计划预留需要在第一个集群之前安排。
在本文中，我们介绍了 HyperPod InstantStart，这是一个开源控制平面，它将 Amazon EKS 编排与 Amazon SageMaker HyperPod 的托管功能组合在一起。这些功能包括自动节点恢复、托管的 Karpenter 自动缩放、训练算子的进程级重启、推理算子的 KV 缓存和智能路由，以及托管的分层检查点。它将它们整合到一个具有两个界面的有状态的自助服务解决方案中。
Web 界面和 AI 代理具有同等功能，因为它们共享一个后端。两者都驱动相同的受保护的 API，并且该项目已将其网络规则、现场保存不变量、依赖项协调和完成标准编码到这些 API 中。如果您正在为自己的基础设施构建代理驱动的操作，那么可重用的决策就是工作顺序：首先投资控制平面合约，然后代理继承您编码的每个保证。
要开始在 Amazon EKS 上使用 HyperPod，请参阅 SageMaker HyperPod 中的 Amazon EKS 支持。有关涵盖集群管理和 FM 培训的端到端教程，请访问 Amazon SageMaker HyperPod Workshop 中的 Amazon EKS 支持。要通过任一界面部署本文中描述的解决方案，请参阅 HyperPod-InstantStart 存储库及其启动指南。
关于作者
郑浩
侯瑛博士
阿努普·萨哈
hao 是 Amazon Web Services (AWS) 的 AI/ML 专家解决方案架构师。他专注于基础模型训练、推理基础设施和优化，以及构建解决方案并推动整个 AWS AI/ML 技术堆栈的性能改进。在加入 AWS 之前，他在大型科技公司从事计算广告和大规模排名算法工作多年。
Ying 是 Amazon Web Services 的高级专家解决方案架构师，专注于生成式 AI 基础设施和框架。她居住在伦敦，与客户合作使用 AWS 基础设施对大型语言模型进行预训练、后训练和托管，以进行推理，并在 Amazon SageMaker HyperPod 方面拥有深厚的专业知识。 Ying 帮助组织大规模设计和优化其 ML 训练和推理工作负载，帮助他们充分利用 AWS 上的 GPU 集群、分布式训练和高效模型服务。
Anoop 是 Amazon Web Services (AWS) 的高级 GTM 专家，专注于生成式 AI 模型训练和推理。他与顶级前沿模型构建者、战略客户和 AWS 服务团队合作，在 AWS 上实现大规模分布式训练和推理，并领导联合 GTM 动议。在 AWS 之前，Anoop 在初创公司和大型公司担任过多个领导职务，主要关注人工智能基础设施的芯片和系统架构。