SageMaker HyperPodにマネージドRayが登場：トレーニング、推論、障害復旧でKubeRayインターフェースを共用

AWSは、SageMaker HyperPodのEKS構成にマネージドRay機能を追加し、従来はKubernetes manifestの作成、イメージのビルド、port-forwardの設定、Prometheus／Grafanaの構成などを自前で行う必要があった作業をSageMaker Studioに統合した。ユーザーはインターフェースからRayClusterを作成し、Ray DashboardやAmazon Managed Grafanaを表示して分散ジョブを送信できるほか、ハングしたジョブの検出も設定できる。基盤では引き続きオープンソースのKubeRayがRayCluster、RayJob、RayServiceを管理するため、既存のRay Train、Ray Serve、標準ジョブ送信APIは原則として書き換える必要がない。

開発ワークフローにも実質的な変化がある。JupyterLabまたはCode Editorのスペースは、コンピューティングリソースを割り当てずに既存クラスターへworkerとして接続でき、コードから`ray.init(address="auto")`で接続する。依存関係は`runtime_env`を通じて注入できるため、パッケージを変更するたびにコンテナを再ビルドする必要が減る。リモートジョブには`toolkit-for-ray-on-sagemaker-ai`を使用し、SageMakerのクラスター名の解決とEKS IAM認証情報をRay CLIに連携させる。Dashboard URLは有効期間が短く、IAMで認証され、作成者に紐づくエンドポイントとなるため、Ray head serviceを公開したり、長期間port-forwardを維持したりする方法よりも、複数ユーザーの環境に適している。

長時間実行されるAIワークロードでは、HyperPodのノードヘルスモニタリングと自動復旧がRayの耐障害性メカニズムと連携する。トレーニングでは階層型checkpointを利用でき、高頻度で更新される状態をまずクラスターのCPUメモリへ書き込み、その後、定期的に永続化する。Ray ServeはJumpStartから重みをロードできるほか、長いコンテキストを扱う推論のKV cacheを階層型ストレージへオフロードできる。

ただし、ワンクリックで有効化できるわけではない。前提条件にはEKS HyperPod、Spaces、Observability、KubeRay、Ray Endpoint Operatorが含まれる。AWSは、セルフマネージドRayと比較した起動時間、障害復旧、単位コストのベンチマークを公開していない。エンジニアリングチームは引き続き、checkpointが占有するメインメモリ、エンドポイントの権限境界、KVオフロードがテールレイテンシーに及ぼす影響を測定する必要がある。