在 SageMaker HyperPod 上用托管 Ray 运行弹性分布式训练

预计阅读时间：8 分钟

Amazon SageMaker HyperPod 现在可以在 Amazon EKS 上提供托管 Ray 支持。开发者可以从 SageMaker Studio 创建和监控 Ray 集群，把 JupyterLab 或 Code Editor 连接到正在运行的集群，并使用开源 KubeRay 与标准 Ray API 执行分布式训练和加速推理。

这项能力的价值不只是“再提供一个 Ray 集群”。它把集群生命周期、开发环境、可观测性和训练任务放进同一条工作流，减少了团队在 Kubernetes、Ray 和 Notebook 之间反复切换的运维成本。

从 Notebook 到 Ray 集群

典型流程可以拆成四步：

在 SageMaker HyperPod 上创建或选择一个由 Amazon EKS 承载的 Ray 集群。
通过 SageMaker Studio 的 JupyterLab 或 Code Editor 连接到这个在线集群。
使用标准 Ray API 提交任务、分配 GPU 或 CPU 资源，并观察任务状态。
通过内置的可观测性能力检查节点、任务和训练过程。

连接到远程集群后，Notebook 代码不必改变成某种专有 SDK。可以继续使用 Ray 原生的 ray.init()、远程任务和 Actor 模型。这一点很重要：团队已有的 Ray 代码更容易迁移，开发人员也能在熟悉的交互式环境中调试分布式程序。

KubeRay 和标准 Ray API 如何配合

HyperPod 的托管 Ray 支持建立在开源 KubeRay 之上。KubeRay 负责把 Ray 集群表示为 Kubernetes 资源，并处理 Head 节点与 Worker 节点的编排；Ray 本身负责任务调度、Actor 生命周期和分布式执行。

这种分层带来两个实际好处：

Kubernetes 团队可以继续使用熟悉的集群资源和工作负载管理方式。
Ray 用户可以继续使用 Ray 的编程模型，而不需要为每个训练任务设计一套新的分布式接口。

例如，下面这个最小 Ray 程序可以保存为 ray_demo.py，然后在已经连接到 Ray 集群的 Notebook 或 Code Editor 中运行。它使用两个远程任务验证 Worker 是否能够并行执行：

import ray

ray.init()

@ray.remote
def square(value: int) -> int:
    return value * value

results = ray.get([square.remote(i) for i in range(8)])
print(results)

ray.shutdown()

运行前需要确认当前 Python 环境安装了与集群兼容的 Ray 版本，并且 Notebook 已经连接到目标集群。这个例子只验证连接和基本调度；实际训练中还应明确声明 CPU、GPU、内存等资源需求。

在可以访问 Kubernetes API 的环境中，也可以用 KubeRay 的 RayCluster 资源表达集群。下面是一个可改造的示例，具体镜像、版本、实例规格和认证配置需要替换为团队环境中的值：

apiVersion: ray.io/v1
kind: RayCluster
metadata:
  name: training-ray
spec:
  rayVersion: "2.9.0"
  headGroupSpec:
    rayStartParams:
      dashboard-host: "0.0.0.0"
    template:
      spec:
        containers:
          - name: ray-head
            image: <your-ray-image>
            resources:
              requests:
                cpu: "2"
                memory: 4Gi
  workerGroupSpecs:
    - groupName: gpu-workers
      replicas: 2
      rayStartParams: {}
      template:
        spec:
          containers:
            - name: ray-worker
              image: <your-ray-image>
              resources:
                requests:
                  cpu: "4"
                  memory: 16Gi
                  nvidia.com/gpu: "1"
                limits:
                  nvidia.com/gpu: "1"

这段 YAML 是通用 KubeRay 资源示例，不代表 HyperPod 环境中所有集群都需要手动提交同样的配置。使用 SageMaker Studio 的托管流程时，应优先遵循环境提供的创建、连接和权限配置入口。

分布式训练、推理与可观测性

Ray 的编程模型适合把大任务拆成许多可调度的远程工作单元。分布式训练可以把数据分片、训练迭代或超参数试验分配给不同 Worker；推理服务则可以利用 Ray 的任务和 Actor 模型，在多个节点或 GPU 上扩展并发处理。HyperPod 提供的弹性和韧性能力，使这类工作负载更适合长时间运行的生产环境。

可观测性同样是托管方案的关键部分。分布式程序出问题时，单看 Notebook 的输出通常不够：需要知道是 Head 节点调度变慢、Worker 资源不足、GPU 未被使用，还是某个任务反复失败。开箱即用的监控能力可以帮助团队从集群、节点和任务层面定位问题，减少手工拼接日志与指标系统的工作。

不过，托管能力不会自动消除分布式系统的边界。任务仍然需要设计幂等行为，训练检查点仍然需要写入可靠的持久化存储，依赖和容器版本也必须在 Head 与 Worker 之间保持一致。

落地时的检查清单

建议先用一个小型、可重复的 Ray 任务验证完整链路，再迁移大型训练作业：

确认 SageMaker Studio 用户拥有创建、连接和观察 Ray 集群所需的权限。
固定 Ray、Python、CUDA 和训练框架版本，避免 Notebook 与 Worker 环境漂移。
为训练任务配置检查点和重试策略，测试 Worker 发生故障时能否恢复。
用明确的资源声明区分 CPU、GPU、内存和并发需求。
在真实数据规模下检查任务耗时、GPU 利用率、网络通信和存储吞吐。
为集群闲置、扩缩容和任务失败建立成本与告警边界。

总体来看，SageMaker HyperPod 上的托管 Ray 适合已经采用 Ray、又希望把 Kubernetes 运维、交互式开发和生产训练统一起来的团队。最稳妥的采用路径是保留标准 Ray API，先验证连接、资源调度和故障恢复，再逐步把分布式训练与加速推理迁移到托管集群。

在 SageMaker HyperPod 上用托管 Ray 运行弹性分布式训练

从 Notebook 到 Ray 集群

KubeRay 和标准 Ray API 如何配合

分布式训练、推理与可观测性

落地时的检查清单

相关推荐

建议反馈