Slide 1

Slide 1 text

HyperPodとEKSの 新機能まとめ 2024年末

Slide 2

Slide 2 text

re:Invent 2024に合わせてHyperPodと EKSに多くの新機能が発表 SageMaker HyperPod • Task governance 12/4 • Flexible Training Plans 12/4 • Recipes 12/4 EKS • Auto Mode 12/1 • Hybrid Nodes 12/1 • Node Health Monitoring and Auto-Repair 12/16 • expands catalog of upgrade insight checks 12/20 • programmatic access to Kubernetes version availability 12/27

Slide 3

Slide 3 text

HyperPod Task governance

Slide 4

Slide 4 text

HyperPod Task governance 一言で言うと 組織内の複数チームでGPUを無駄に せず互いに融通しながら使用できる 機能

Slide 5

Slide 5 text

https://zenn.dev/kiiwami/articles/d9ccac79ae386952 から引用。 • 最初の課題は、EKS上でHyperPodクラスターを稼働させる際、チームごとに静的なリソース割り当てを行わなけ ればならないということでした。 • 静的な割り当てであるため、過剰割り当てや過少割り当ての問題が発生します。 その結果、コンピュートリ ソースが遊休状態になることが多く、待機中のタスクに影響を及ぼします。 • チームは使用率の指標を適切に追跡していないため、データサイエンティストやチームは自分たちの使用率が 良いのか悪いのかさえ把握できておらず、リーダーやデータサイエンティストが使用率を監視するための標準 化された方法もありません。 • すべてのコンピューティングリソースをプールし、独自に開発したダイナミックスケジューリングアルゴリズ ムを使用することで、全プロジェクトとチームにわたって利用率を最大化できます HyperPod Task governance

Slide 6

Slide 6 text

• クラスターの健全性だけでなく、クラスターのガバナンスもリアルタイムでモニタリングおよび監査すること ができます。ガバナンスとは、チームに対する割り当ての状況を理解することです • キュー内のタスクでリソースの競合が発生した場合、タスク実行時に割り当てられた優先順位に基づいて、 Task Governanceが高優先度のタスクが低優先度のタスクよりも先にコンピュートリソースを確保できるように します。低優先度のタスクが実行中の場合は、高優先度のタスクにコンピュートリソースを確保するためにプ リエンプション(割り込み)が行われます。 HyperPod Task governance

Slide 7

Slide 7 text

HyperPod Task governance • チームにどれだけの割り当てが与えられているか、どれだけ使用しているか、待機中のタスクがあるか、長時 間実行中のタスクがあるか、あるいは大きな割り当てを受けているのにコンピュートリソースを全く使用して いないチームがあるかどうかを監視できる • 管理者として、クラスターにガバナンスポリシーを定義することができます。 これには、最優先とされるタス クを決定するタスクの優先順位付けポリシーが含まれます。 例えば、推論を最優先、トレーニングを次点、 Fine-tuningを3番目、データ処理を4番目というように指定できます。 • ここでFair Share(公平配分)の仕組みが活きてきます。1つのチームがすべてを獲得するわけでもなく、単純な 均等分割でもありません。実際には、バックグラウンドで動作する公平配分アルゴリズムに基づいて決定され ます。5つのチームがあるとして、公平配分アルゴリズムは、単純な均等分割ではなく、チームの優先度や使用 状況などの要因に基づいてアイドルコンピュートを分配します。このアプローチにより、チーム間でより動的 で公平なリソース分配が可能になります。 HyperPod Task governance

Slide 8

Slide 8 text

No content

Slide 9

Slide 9 text

HyperPod Task governance • チーム1にアイドルコンピュートが残っている状態で、チーム2が新しいタスクを送信しようとしていますが、 彼らは割り当てられたコンピュートを使い切っています。 ここでTask Governanceが機能し、このタスクの送 信にアイドルコンピュートが使用されるようになります。 • さらに状況を複雑にしてみましょう。同じチームが、コンピュートが利用できない状況で、より優先度の高い タスクT6を送信します。Task Governanceは、タスクタイプの優先順位付けに関して定義されたクラスターポリ シーに基づいて、T5を有効化された最後のチェックポイントまでCluster Queueに戻し、 その代わりにT6を送信 します。 その後、チーム1がT7を送信しようとします。自分たちのアイドルコンピュートを他のチームに貸し 出していましたが、チーム1が割り当てられていたコンピュートを必要としている状況です。ここで保証された 割り当てコンピュートに戻ることになります。 • 借用したコンピュートで実行されていたタスクはプリエンプトされます。アイドル状態のコンピュートが利用 可能になるのを待ち、チームは自身のコンピュートを取り戻してタスクを実行します。 HyperPod Task governance

Slide 10

Slide 10 text

HyperPod Task governance • これらすべての状況は、管理者がダッシュボードでリアルタイムにモニタリングできます。 • ここで2種類のポリシーを定義します。1つ目はタスク優先順位ポリシーで、クラスを定義できます。推論の重 みを15、トレーニングを10、Fine-tuningを5というように指定できます。これは、クラスター上でリソースを 争うタスクがある場合、推論タスクに最も高い優先順位が与えられることを意味します。 • アイドルコンピュートの割り当てでは、先着順またはFair shareのいずれかを指定できます。Fair shareを選択 した場合、チームとその重み(つまりチームの優先順位)、待機中のタスク数、これまでのアイドルコン ピュートの使用状況に基づいて、アイドルコンピュートを使用することができます。 HyperPod Task governance

Slide 11

Slide 11 text

No content

Slide 12

Slide 12 text

No content

Slide 13

Slide 13 text

HyperPod Task governance • https://zenn.dev/kiiwami/articles/d9ccac79ae386952 • https://aws.amazon.com/jp/about-aws/whats-new/2024/12/task-governance- amazon-sagemaker-hyperpod/ • https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-hyperpod-eks- operate-console-ui-governance-setup.html • k8sで高機能なキューイングを実現するKueueをバックエンドで使用 • https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-hyperpod-eks- operate-console-ui-governance-cli.html HyperPod Task governance

Slide 14

Slide 14 text

HyperPod Flexible Training Plans

Slide 15

Slide 15 text

HyperPod Flexible Training Plans 一言で言うと GPUインスタンス予約機能である Capacity Blocks for MLをHyperPod でのジョブと連動してうまく使える 機能

Slide 16

Slide 16 text

HyperPod Flexible Training Plans https://zenn.dev/kiiwami/articles/47da84eb9119d7c5 より引用。 • 最新のアクセラレーターを搭載した数百台のインスタンスで非常に大規模なモデルをトレーニングしようとす る場合、需要が非常に高いため、必要な容量を常に確保することが難しい場合があります。オンデマンドの場 合、そのリスクを取ることになります - 容量が利用可能な場合もあれば、そうでない場合もあり、スケジュー ルが遅れる可能性があります。 • もう一つの選択肢は、長期の予約で容量を確保することです。これにより予測可能なスケジュールが得られま すが、トレーニングを数ヶ月間24時間365日実行しているわけではない場合、クラスターの使用率が低くなり、 十分に活用していないリソースに対して支払いが発生することになります。 • そこで私たちは、これら2つのパラダイムの長所を活かしながら、お客様がスケジュールと予算に合わせてト レーニングワークロードを計画できるよう支援する方法を考えました。 HyperPod Flexible Training Plans

Slide 17

Slide 17 text

HyperPod Flexible Training Plans • 必要なインスタンスタイプ、インスタンス数、トレーニングの所要時間、そしてトレーニングを開始できる最 も早い時期を指定することで、要件を設定します。データの収集やアルゴリズムの調整がまだ完了していない 場合は今すぐには開始できないかもしれませんが、期限に間に合わせるために来週にはトレーニングを開始す る必要があることがわかっているかもしれません。Training Planの推奨プランを確認し、前払いで予約するこ とができます。 • 例として、12月10日から14日間、ml.p5.48xlarge を10インスタンス使用したいとしましょう。モデルのトレー ニングには14日間必要だとわかっています。その容量の連続したセグメントを確保できるかもしれませんが、 12月中旬以降になる可能性もあります。HyperPodのTraining Planを使用すれば、7日間ずつの2つのセグメン トを見つけることができ、途中で中断があったとしても、より早く開始してより早くトレーニングを完了でき る可能性があります。 HyperPod Flexible Training Plans

Slide 18

Slide 18 text

HyperPod Recipes

Slide 19

Slide 19 text

HyperPod Recipes 一言で言うと Foundation Modelの学習環境の最適 化されたテンプレート

Slide 20

Slide 20 text

HyperPod Recipes https://zenn.dev/kiiwami/articles/47da84eb9119d7c5 より引用。 • Llama 3.1(4億または5億パラメータバージョンを含む)、Llama 3.2、Mistral Mixなど、一般に公開されてい る人気のFoundation ModelのPre-trainingとFine-tuning用の厳選された使用準備の整ったSageMaker Recipes を提供しています。 • これらのRecipesは、学習ワークロードのための効率的なリソース利用と、結果としてのコスト最適化を提供し ます。私たちは、自動モデルチェックポイント技術を含むSageMaker最適化モデルのエンドツーエンドの学習 ループの実装を担当します。先ほど述べたように、チェックポイントは非常に重要なタスクであり、これらの モデルに対して追加のコード変更なしで自動的に実行しています。チェックポイントを行うためにコードを1行 も変更する必要はなく、高頻度で進行中のモデル結果を保存し、障害から迅速に回復できるようになっていま す。 HyperPod Recipes

Slide 21

Slide 21 text

HyperPod Recipes • まず最初に、Pre-trainingやFine-tuningに使用したいRecipeを選択します。Recipeは、すべてのリストが公開 されているGitHubリポジトリで入手できます。Recipeを選択したら、前提条件をセットアップします。インフ ラが稼働していて、HyperPodクラスターがトレーニングを実行できる状態であることを確認する必要がありま す。クラスターをスピンアップするために必要な制限や設定をすべて行います。最後に、HyperPodクラスター 上でRecipeを実行します。なお、一時的なトレーニングジョブに慣れている方であれば、Amazon SageMaker training jobsでもRecipeを実行することができます。 • Recipeは公開GitHubリポジトリに格納されており、Launcherスクリプトとレシピコレクションが含まれていま す。このリポジトリには、実際のLauncher、トレーニングを実行するコードの実装、設定の階層構造が含まれ ています。このフレームワークで始められるRecipeは30以上あります。このLauncherを使用することで、 SageMaker GPU最適化モデル、Trainiumインフラで実行するNeuron最適化モデル、さらにはネイティブの NeMoモデルやカスタムモデルでのPre-trainingやFine-tuningを実行できます。カスタムRecipeやモデルを持 ち込める拡張可能なフレームワークとなっています。 HyperPod Recipes

Slide 22

Slide 22 text

EKS Auto Mode

Slide 23

Slide 23 text

EKS Auto Mode 一言で言うと ノードグループの構成・管理をユー ザーがしなくても必要に応じてEKSが いい感じにやってくれる機能

Slide 24

Slide 24 text

EKS Auto Mode https://speakerdeck.com/kashinoki38/eks-auto-mode?slide=12 より引用 EKS Auto Mode

Slide 25

Slide 25 text

EKS Hybrid Node

Slide 26

Slide 26 text

EKS Hybrid Node 一言で言うと EKSのノードとしてオンプレミスのイ ンフラ環境を使用できる機能

Slide 27

Slide 27 text

EKS Hybrid Node ↓AWS ↓オンプレ https://docs.aws.amazon.com/eks/latest/userguide/hybrid-nodes-prereqs.html より引用 EKS Hybrid Node

Slide 28

Slide 28 text

Node Health Monitoring and Auto-Repair for Amazon EKS

Slide 29

Slide 29 text

Node Health Monitoring and Auto- Repair for Amazon EKS 一言で言うと ノード(EC2インスタンス)の障害を 検知してクラスターを自動修復して くれる機能

Slide 30

Slide 30 text

Amazon EKS expands catalog of upgrade insight checks

Slide 31

Slide 31 text

Amazon EKS expands catalog of upgrade insight checks 一言で言うと EKSクラスターを新しい Kubernetes バージョンに正常にアップグレード できるかどうかをチェックする機能

Slide 32

Slide 32 text

Amazon EKS expands catalog of upgrade insight checks https://dev.classmethod.jp/articles/eks-upgrade-insights-various-check/ より引用 Amazon EKS expands catalog of upgrade insight checks

Slide 33

Slide 33 text

programmatic access to Kubernetes version availability

Slide 34

Slide 34 text

programmatic access to Kubernetes version availability 一言で言うと AWS CLIでEKSで使えるKubernetes バージョンの詳細情報が取得できる 機能

Slide 35

Slide 35 text

programmatic access to Kubernetes version availability % aws eks describe-cluster-versions { "clusterVersions": [ { "clusterVersion": "1.31", "clusterType": "eks", "defaultPlatformVersion": "eks.16", "defaultVersion": true, "releaseDate": "2024-09-26T09:00:00+09:00", "endOfStandardSupportDate": "2025-11-26T09:00:00+09:00", "endOfExtendedSupportDate": "2026-11-26T09:00:00+09:00", "status": "STANDARD_SUPPORT", "kubernetesPatchVersion": "1.31.4" }, { "clusterVersion": "1.30", "clusterType": "eks", .....