re:Invent 2025: SageMaker HyperPodとUltra ServersによるAI高速化
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
re:Invent 2025 の書き起こし記事については、こちらの Spreadsheet に情報をまとめています。合わせてご確認ください
📖 re:Invent 2025: AWS re:Invent 2025 - Accelerate AI workloads with UltraServers on Amazon SageMaker HyperPod (AIM362)
この動画では、Amazon SageMaker HyperPodとEC2 Ultra Serversによる生成AI開発の課題解決について解説しています。コンピュート容量の確保、チーム間のリソース配分、分散トレーニングの複雑さ、ハードウェア障害への対応といった課題に対し、HyperPodは柔軟なトレーニングプラン、タスクガバナンス、training recipes、自動復旧機能で対処します。Ultra Serversは専用ネットワークで最大72個のGPUを相互接続し、Elastic Fabric AdapterとScalable Reliable Datagramプロトコルにより高速通信を実現します。デモではトレーニングプランの購入、クラスター作成、タスクガバナンスの設定、チーム間の容量貸借、障害時の自動復旧が実演され、Mixture of Expertsのような高度なユースケースでのネットワーク最適化の重要性が示されました。Perplexityは開発を40%高速化し、最大68%のコスト削減を実現しています。
※ こちらは既存の講演の内容を最大限維持しつつ自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますのでご留意下さい。
本編
生成AI開発の課題とSageMaker HyperPod、EC2 Ultra serversの紹介
今日は、Amazon SageMaker HyperPod と EC2 Ultra サーバーの世界に飛び込んでいきます。私は Amazon SageMaker のシニアマネージャーの Rekha Seshadrinathan です。本日は、AWS でお客様がファウンデーションモデルを構築するのをサポートしている Principal Specialist Solutions Architect の Paulo 同僚と一緒にステージに立っています。Paulo です。皆さん、本日はお越しいただきありがとうございます。
始める前に、少し歴史についてお話ししたいと思います。ここにいる皆さんの中で、この橋を認識している人はいますか？ そうです、これはマンハッタンとブルックリンの自治区を結ぶ象徴的なブルックリン橋です。さて、1800年代半ばにさかのぼると、イースト川を横切る橋を建設するという考え自体が馬鹿げていると考えられていました。川は深く、流れは激しく、これまで試みられたことのないスパンは不可能に思えました。
しかし、一人の男、John Roebling がビジョンを持っていました。彼は世界がこれまで見たことのないような吊り橋のビジョンを持っていました。毎日何千人もの人々を輸送し、何トンもの貨物を運ぶことができる橋です。新聞社がそれをファンタジーと呼んでいた一方で、そのアイデアは根強く残り、John Roebling が設計した鋼線の発明につながりました。 これは 6-19 デザインと呼ばれるものです。これは基本的に 6 本の束で、それぞれが中心の周りに 19 本の線を持っています。この独特の六角形のデザインは非常に強力でありながら柔軟な線を作り出し、彼はこれを使って橋を建設しました。
橋の建設自体には14年以上の歳月がかかり、ついに完成した時には、初めての鋼製ワイヤーサスペンション橋であり、当時最長のサスペンション橋でした。そして今、私たちは歴史の中で似たような瞬間に立っています。何十年もの間、私たちは多くの形態の知能、推論、創造性、言語は人間にのみ固有の領域だと信じていました。数十億のパラメータを超えてモデルをスケーリングすることは、私たちの計算能力の範囲を超えていると信じていたのです。
しかし、ブレークスルーが訪れました。Transformer、Foundation Model、RAG、そして強化学習です。そして今、不可能に思えたことが必然のように見えています。実は、70パーセント以上のエンタープライズが既に少なくとも1つの機能でAIを使用しています。もはやチャットボットだけではありません。推論システムとエージェンティックワークフローが新しい効率性と成長を生み出しています。皆さんのような組織は、AIに数百万ドルを投資しています。しかし、Brooklyn Bridgeが新しい鋼のアーキテクチャを必要としたように、AIの課題とこれらのAIブレークスルーは、生成AIの独自の課題を解決するために設計された新しいコンピュートアーキテクチャと新しいソフトウェアシステムを求めています。
ここAWSでは、生成AIのトレーニングと推論のための最高の場所を構築することが私たちのミッションです。つまり、これらの独自の課題を解決するための最高のコンピュートインフラストラクチャとソフトウェアシステムを構築することです。だからこそ、今日は皆さんに SageMaker HyperPod と EC2 Ultra サーバーについてお話しできることに興奮しています。本セッションでは、まず生成AIの開発、トレーニング、推論に関するいくつかの課題についてお話しします。その後、SageMaker HyperPod を紹介し、それがこれらの課題をどのようにユニークに解決するかについてお伝えします。
その後、EC2 Ultra servers についてお話しします。そして Paulo がアーキテクチャについて詳しく掘り下げていきます。さらに、これらのツールをすべて自分で使う方法についての包括的なデモンストレーションも行います。そして最後に、いくつかの高度なユースケースを紹介して、皆さんが使用できるリソースを提供します。
AIワークフローにおける典型的な課題：コンピュート確保からハードウェア障害まで
では始めましょう。モデルをトレーニングしてホストしているお客様にとって、典型的な AI ジャーニーがどのようなものかを一緒に見ていきましょう。 お客様が最初に取る必要があるステップは、必要なコンピュートへのアクセスを確保することです。 これらのアクセラレーテッドインスタンスは需要が高いため、常にオンデマンドで利用できるわけではありません。トレーニング用にこれらのインスタンスを取得しようとしても、必要な時点では利用できないかもしれません。
別の選択肢としては、長期的な予約を検討することです。つまり、1 年から 3 年の間、事前にコミットメントを行うということです。ただし、これがすべての組織にとって実行可能とは限りません。また、予約期間全体でこれらのリソースを使用できない可能性があるため、リソースの過小利用につながる可能性もあります。本質的に、これらの AI ワークフローは多くの実験を伴うスパイク状の特性を持っています。では、このコンピュートを確保したとしましょう。次に、組織が取るステップは、このコンピュートを組織内の複数のチーム全体にどのように配分するかを決定することです。
モデルをファインチューニングしたり、トレーニングしたり、ホストしたり、アプリケーションを構築したりするさまざまなチームがあり、これらすべてのユースケースにリソースが必要です。通常、管理者は異なるチームを回ってコンピュートのニーズを聞き、その後、組織全体にコンピュートを静的に配分します。しかし、これは非効率につながる可能性があります。組織内に 2 つのチームがある例を説明させてください。
ここに最初のチームが見えます。彼らには 2 つのインスタンスが割り当てられており、キューに入っている複数のジョブがあります。最初の 2 つのジョブは優先度が低く、これら 2 つのインスタンスを占有しています。その後、優先度がより高い 3 番目のジョブが来ます。しかし、これらのジョブが完了するのを待ってキューに並んでいます。 理想的には、優先度の高いジョブがこれらのコンピュートリソースにアクセスでき、その後、優先度の低いジョブを後で処理したいのです。
では、チーム2を見てみましょう。ここでは、3つのインスタンスを持っています。優先度が異なる2つのジョブが、そのうちの2つのインスタンスを使用しています。しかし、3番目のインスタンスがアイドル状態で放置されており、理想的には、そのインスタンスをチーム1のバックログにあるジョブの1つに使用できるはずです。このようにコンピュートを静的に割り当てると、リソースの利用率が低下し、組織内の最優先度のワークロードを常に優先することができなくなります。
コンピュートを調達し、リソースをさまざまなチーム間に割り当てました。次のステップは、モデルをトレーニングまたはファインチューニングしている場合、このハードウェアを効果的に使用する方法を見つけることです。最新のモデルでは、Foundation Model は毎年ますます大きくなっています。今では相当古い GPT-3 を見ても、それは1750億パラメータのモデルでした。
モデルをロードしようとする場合、これらのパラメータを保存するためにメモリが必要です。FP16精度を使用している場合、パラメータあたり約2バイト必要であり、モデルの重みだけを保存するのに350ギガバイト必要です。これにアクティベーションとグラディエントを加えると、必要なメモリはそれをはるかに上回ります。しかし、単一の H100 GPU のメモリは80ギガバイトしかありません。では、どうするのでしょうか?
通常、チームは Model Parallelism を使用するか、そのモデルを複数の GPU に分割します。しかし、これには分散トレーニングの専門知識が必要であり、使用している特定のハードウェアタイプと、トレーニングしようとしている特定のモデルファミリーに対して、正しい設定を得るまでに数週間から数ヶ月の反復が必要です。
ここまでのすべてを完了し、モデルトレーニングを開始した場合、次に直面する課題はハードウェア障害です。これらのアクセラレーテッドインスタンスは多くのコンピュートとメモリの能力を提供しますが、障害が発生する傾向があります。分散トレーニングは多くの内部通信を伴う非常に同期的なプロセスであるため、単一の GPU 障害があなたのファインチューニングまたはトレーニングワークロード全体を停止させる可能性があります。
そういった状況が発生すると、組織内のデータサイエンティストやエンジニアが問題を特定し、障害をデバッグして、問題を解決し、最後の安全なチェックポイントから学習を再開する必要があります。これらすべてが何時間もの苦労とダウンタイムをもたらす可能性があります。これらの障害はいつでも発生する可能性があるため、真夜中に発生した場合、その問題が解決されるまでクラスタ全体がアイドル状態になる可能性があり、大幅なダウンタイムにつながります。クラスタやモデルのサイズが大きくなるにつれて、ハードウェア障害の確率は増加するだけです。
実は、業界ではこれを goodput という用語で表現しています。Goodput は基本的に、実際に前進している時間の割合、つまりデバッグなどのこれらすべての活動をしていない代わりに、実際に生産的である時間の割合を意味します。私たちが話した多くのお客様は、これらのモデルの学習を開始する際に、クラスタの低い利用率と低い goodput に悩まされていました。生成 AI 開発には多くの課題があり、それらはすべて技術的なものではありません。 メモリのボトルネックと通信のボトルネックがありますが、運用上の課題とビジネス上の課題もあります。
SageMaker HyperPodによる包括的ソリューション：柔軟なトレーニングプランとレジリエンシー機能
これらの問題はすべて相互に関連しているため、それらを個別に解決しても、通常、組織にとって良い結果にはなりません。これらすべての問題に対処する、より包括的なソリューションが必要です。だからこそ、私たちは SageMaker HyperPod を構築し、2年前のここ re:Invent で立ち上げました。 SageMaker HyperPod は生成 AI 開発のために特別に設計されており、私たちが議論した独特の課題に対処するために必要なツールを提供します。障害を迅速にデバッグして特定するのに役立つ独特の復元力機能が付属しており、クラスタの利用率を最大化するのに役立ち、これらのリソースを効果的に使用していることを確認するために必要な可視性ツールを提供します。
SageMaker HyperPod を使用して、その AI の旅を改めて見てみましょう。最初に話した課題は、コンピュートへのアクセスでした。 SageMaker HyperPod は柔軟なトレーニングプランをサポートしています。1～3年間の容量を予約する代わりに、1日から6ヶ月間、最大8週間前に容量をリクエストできるようになりました。SageMaker コンソールにアクセスして、必要なインスタンス数と期間を指定すると、ニーズを満たす一連のプランを確認できます。
気に入ったプランが見つかったら、そのプランを購入して、HyperPod クラスタを作成する際にそのトレーニングプランを参照できます。 後ほど Paulo がこれらすべてがどのように機能するかのデモを見せてくれます。HyperPod はそのトレーニングプランがアクティブになるとクラスタをスケールアップし、プランが期限切れになるとクラスタをスケールダウンします。クラスタをセットアップしたら、ファインチューニングと学習のワークロードをクラスタに送信し始めて、クラスタの使用を開始できます。
次の課題は、これらのリソースを複数のチーム間で適切に使用することと、それがどのように課題になるかについてでした。SageMaker HyperPod には、タスクガバナンスと呼ばれる機能が備わっています。
タスクガバナンスは、これらのコンピュートリソースをチーム間で効率的に配分するのに役立ちます。これの仕組みは、管理者が異なるチームのコンピュート配分を指定することができ、その配分に加えて、異なるタスクの優先度を指定し、プリエンプションルールを設定することができます。これが設定されると、HyperPod は自動的に入ってくる最優先度のタスクを優先します。すべてのチームが保証されたコンピュート配分を得ながら、アイドルリソースがある場合、別のチームはそのアイドルコンピュート上で機会的にタスクを実行することができ、これにより利用率を最大化しながら、すべてのチームがリソースの公正な配分を確実に得られるようにします。
次の課題は、これらのモデルを大規模クラスタ全体に配布することでした。HyperPod には training recipes も付属しています。これらを分散トレーニングのプレイブックと考えてください。異なるモデルアーキテクチャとインスタンスファミリーの recipes を事前にベンチマークしています。これらの recipes のいずれかを使用してジョブを送信し、ファインチューニングまたはトレーニングワークロードをすぐに開始できます。最後の課題は、ハードウェア障害と、トレーニングを開始した後にハードウェア障害またはネットワークの問題が発生する可能性があることについてでした。HyperPod には、これに役立つ多くのレジリエンシー機能が備わっています。
まず、ハードウェア障害またはネットワークの問題がないかクラスタを積極的に監視するヘルスモニタリングエージェントが付属しています。問題が検出されると、HyperPod はトレーニングを一時停止し、エラーの種類に応じてノードをリブートまたは置き換え、その後、以前に保存されたチェックポイントからトレーニングを再開します。これはすべて手動操作なしに行われます。これはバックグラウンドで発生し、貴重なデータサイエンティストまたは ML エンジニアリングリソースを使用する必要がありません。さらに、クラスタで有効にできるディープヘルスチェックもあります。クラスタを作成するときに、これらのディープヘルスチェックを設定でき、これらは包括的なチェックで、ワークロードが実際に実行を開始した後の障害の確率を減らすために実行されます。
HyperPod には、本日リリースされたばかりの興味深い新機能もあります。これにより、耐久性のあるストレージまたは以前に保存されたチェックポイントに行く必要なく、ピアノードからモデル状態をロードしてトレーニングを再開できるようになり、さらに多くの時間を節約できます。本日、elastic training と呼ばれる新機能も立ち上げました。これにより、利用可能なリソースに応じてトレーニングをその場で再構成できます。これらもぜひチェックしてみてください。これらすべての機能があるからこそ、トップ AI 企業は HyperPod を使用してモデルをトレーニングおよびデプロイしています。今週初めに Ryder の CEO のキーノートをご覧になった場合、彼らは HyperPod で最新モデルをトレーニングし、トレーニングを 3 倍以上高速化できたことについて話していました。
EC2 Ultra serversのアーキテクチャ：TrainiumとGB200による高速相互接続
では、HyperPod についての紹介をしたので、ここから Paulo に交代して EC2 Ultra servers についてお話しし、これらがどのように機能するかのデモをしてもらいます。Rekha、ありがとうございました。では、これらのクラスターを作成し、コンピュートを割り当てる方法についてお話ししましたが、ここからは高度な Ultra server コンピュートについてお話しします。 まず、Ultra servers というのは、ハードウェアを組み合わせて、モデルトレーニングとワークロードのパフォーマンスを向上させ、より良く機能させるための定義です。 当初、私たちが発表した last re:Invent の Ultra servers は AWS トレーニングチップに基づいていました。これらのチップは AWS と Annapurna Labs（Amazon の子会社の一つ）によって設計・開発されました。この企業グループは、当初はトレーニングに焦点を当てたチップを開発し、そのため Trainium という名前が付けられました。しかし、現在のチップの設計方法では、トレーニングと推論の両方を行うことができます。モデルを開発し、トレーニングデバイスでそのモデルを使用するために、非常にシンプルな方法があります。AWS Neuron SDK があり、これは市場に存在するほとんどの機械学習フレームワークと統合されています。
例えば PyTorch のようなフレームワークでは、モデルトレーニング中にデバイスを定義することができます。NVIDIA GPU を活用する CUDA としてデバイスを定義する代わりに、デバイスを Neuron として定義します。そうすることで、PyTorch と Neuron でサポートされているフレームワークは、グラフをコンパイルし、トレーニングデバイス上でそのモデルトレーニングを実行します。トレーニングを高速化するために、私たちは Trainium に基づいた UltraServer を開発しました。これは 4 つのインスタンスを組み合わせたもので、これらのインスタンスは非常に高速なネットワークで相互接続されています。これは従来のネットワークではなく、NVIDIA が NV Switch という点で持っているものに似ています。これは専用の独自ネットワークです。私たちは Neuron デバイス用に独自のネットワークを開発し、それらが相互に通信でき、4 つのサーバーを最大 64 デバイスまでバンドルできるようにしました。各サーバーには 16 個のデバイスがあります。
GB200 と最近発表された GB300 サーバーでも同じことが言えます。ここでは NVIDIA GPU をバンドルしています。異なるサーバー間でそれらを一緒に配置し、各サーバーは異なる数の GPU を持っていますが、それらを最大 72 個の GPU までバンドルできます。単一のサーバーで少数の GPU でモデルをトレーニングすることと、72 個の GPU を備えた UltraServer でトレーニングすることの違いを理解することができます。しかし、これについて議論する前に、これらのサーバーがどのように相互接続されているか、そしてこのイノベーションがどのように開発されたかを理解しましょう。
UltraServers について話すとき、その名前は 1 つのサーバーを意味していますが、実際には異なるインスタンスがあります。Trainium に基づいた UltraServer の場合、4 つのインスタンスがあり、各インスタンスに 16 個のデバイスがあると述べました。NVIDIA GPU を搭載した UltraServers の場合、最大 18 個のインスタンスがあり、各インスタンスに 4 個のデバイスがあります。これらのインスタンスは NV Switch で相互接続されています。これは NV Link で、外部スイッチ上の独自の相互接続です。先週 NVIDIA の CEO である Jensen Huang が話しているのを聞いたことがあれば、これはそれらのサーバーの外側にある独自の接続という点でのイノベーションであり、最大 18 個のサーバーを相互接続しています。これは Ethernet ではありません。InfiniBand ネットワークでもありません。また、複数のサーバーにワークロードを拡張する必要がある場合に備えて、セカンダリネットワークも取得します。
では、UltraServer は唯一のイノベーションでしょうか？それを NV Switch 上に配置することは、唯一のイノベーションでしょうか？答えは「いいえ」です。NVIDIA が行った別のことは、チップ、つまり CPU を開発することでした。GPU に大きく依存していた企業が CPU を作成することを決定しました。なぜでしょうか？それは、顧客を支援するために、ARM ベースで x86 ではない CPU が、非常に高速なネットワークでも GPU に接続される必要があることを理解したからです。そこで彼らは GPU と CPU を一緒にした superchip を開発しました。この superchip により、例えば興味深いユースケースが可能になります。モデルをトレーニングしており、108 ギガバイトのメモリを持つ GPU が CPU 上のメモリマッピングにアクセスする必要がある場合、現在は単一の coherent メモリマッピング上でそれを行うことができます。これは非常に興味深いイノベーションです。特に、アクティベーションをオフロードすることについて話しているときは、つまりモデルがトレーニングして重みを学習していますが、ある時点で、使用されていないそれらの重みは GPU から CPU メモリにオフロードされます。これで GPU 上で利用可能なメモリができ、より多くのデータをロードできます。
もちろん、モデルをトレーニングしていて、多くのデバイスを使用している場合、データをコンピュートにできるだけ近い場所に置きたいですよね。そのために、Amazon SageMaker HyperPod には Topology Aware Scheduling という機能があります。これにより、多くの異なるサーバーでモデルをデプロイする際に、データとコンピュートが近い場所になるようにモデルをデプロイする方法を理解しています。
UltraServer の例では、コンテナ定義に配置する必要がある UltraServer ID アノテーションがあります。デモンストレーション中に、Kubernetes の専門家でなくても、それを使用できる方法を見ていきます。なぜなら、その重い作業を軽減するのに役立つツールがあるからです。では、デモに進んで、これらすべての機能をどのように組み合わせることができるかを理解しましょう。デモンストレーション中に、事前に録画したビデオを見ていきます。インターネット接続に問題がないようにするためですが、ビデオに問題がある可能性もあります。よくできました。完璧です。
デモンストレーション：トレーニングプランの購入からノード障害の自動復旧まで
では、コンピュート容量の取得から始めましょう。ここに SageMaker AI コンソールがあり、すでにトレーニング計画がありますが、トレーニング計画の作成を見ていきましょう。 トレーニング計画は SageMaker HyperPod クラスター またはトレーニングジョブ、さらには推論エンドポイント用に定義できます。インスタンスを選択し、トレーニング計画に必要なインスタンスの数を選択し、 開始日を選択します。 開始日は将来の日付にすることができます。事前に容量を計画して取得することができます。その後、トレーニング計画を見つけをクリックすると、 いくつかのオプションが表示されます。これらのオプションは、最初の 2 つのオプションのようにすぐに利用可能な場合もあれば、今日の開始日が必要であっても、将来利用可能なオプションもあります。
その後、どのトレーニング計画を選択するかを決めることができます。重要なのは、 コンピュート容量が割り当てられているアベイラビリティーゾーンを理解することです。繰り返しになりますが、コンピュート容量がデータとコンピュートにできるだけ近い場所にあることを望んでいるからです。アベイラビリティーゾーンを確認してから、それが正しいトレーニング計画であると判断します。そのトレーニング計画に名前を付ける必要があります。どのような名前でも構いません。 そのトレーニング計画にタグを追加できます。そして、このサマリー、このレビューがあります。アベイラビリティーゾーンを再度確認し、 トレーニング計画にいくら支払うかを確認します。そして、トレーニング計画に支払う場合、それは前払いコストであることを忘れないでください。また、インスタンスあたりの価格も確認できます。 すべての詳細を確認し、もちろんそのトレーニング計画を購入したいことを確認する必要があります。
そのボタンをクリックすると、コンソールに表示されるようになり、保留中として表示され、必要なインスタンスの数が表示されます。トレーニング計画が実際にアクティブになるまでに数分かかるからです。 そのトレーニング計画がアクティブになった後、SageMaker HyperPod クラスターに移動して、 そのトレーニング計画を特定のインスタンスグループに割り当てることができます。インスタンスグループは、特定のインスタンスの論理的な定義、そのグループの名前、トレーニング計画です。その後、ジョブを送信する際に、ジョブを送信でき、持っているインスタンスグループに基づいて、そのジョブが実行されます。たとえば、GPU で実行されるジョブが必要な場合、GPU を備えたインスタンスグループを用意します。 または、CPU を使用したジョブが必要な場合、そのインスタンスグループは CPU を使用することもできます。
そのインスタンスグループの定義の一部として、インスタンスタイプ、トレーニングプランを定義しますが、同時に IAM ロールも指定する必要があります。このロールにより、SLA または ECS のいずれかのオーケストレーターがそのインスタンスグループを使用するための権限が与えられます。また、ライフサイクルスクリプトを置く S3 バケットも指定します。インスタンスグループを用意した後、ご覧のように複数の異なるグループがありますが、ここから SageMaker HyperPod の他の機能を使用できます。覚えておいてください、これらのインスタンスが起動するまでには時間がかかる可能性があります。なぜなら、私たちが多くのソフトウェアをインストールし、ネットワークを設定し、いくつかのベンチマークを実行して、すべてが正しく実行されていることを確認しているからです。インスタンスが割り当てられた後、トレーニングプランコンソールに戻って、購入したインスタンスのうち、割り当てられているものとアイドル状態のものがいくつあるかを確認できます。
完璧です。クラスターに戻って、実際にタスクガバナンス機能を有効化しましょう。この機能を有効化するのは、ワンクリックと同じくらい簡単です。ボタンをクリックすると、バックグラウンドでソフトウェアがインストールされます。タスクガバナンスが設定され、使用準備ができたら、あとはポリシーを定義するだけです。
ポリシーは、キューの異なる優先度になります。例えば、私は 4 つの異なる優先度を定義しており、推論が最も高い優先度で、ファインチューニングが最も低い優先度です。また、実験とトレーニングの優先度もあります。これらのポリシーを定義した後、今度は実際に異なるチームにコンピュートを割り当てる必要があります。異なるチームを作成し、フレキシブルトレーニングプランを通じて購入したキャパシティを取得し、それをチームに割り当てることができます。今、Team A を作成しています。これを「my awesome team A」と呼ぶことにして、このチームは実際にいくつかのキャパシティが割り当てられます。そのキャパシティを割り当てるときに定義できることの 1 つは、他のチームに対して寛容になるかどうかです。キャパシティを貸すことも、他のチームからキャパシティを借りることもできます。これは私が決める必要がある決定です。キャパシティの貸し借りをどのようにするかを決めた後、他のチームから貸し出すキャパシティのインスタンス数も定義できます。その特定のパネルの最後の機能は、プリエンプションを有効化することです。覚えていますか、キューで実行されている異なる優先度のジョブについて話しました。低優先度のジョブが実行されていて、その後高優先度のジョブが来ます。その高優先度のジョブが低優先度のジョブをプリエンプトしてほしいですよね。チームのコンピュートノードの割り当てを定義するときに、チームに対してこれを有効化します。
異なるインスタンスグループを選択することができるので、すべてのインスタンスグループから選択する必要はありません。1 つの完全な、1 つの全体のインスタンスをその特定のチームに割り当てることを選択することもできますし、いくつかの GPU、いくつかの vCPU、そしていくつかのメモリをそのチームに割り当てることを定義することもできます。したがって、コンピュートリソースの割り当ては、そのチームが持つコンピュートのベースラインです。これはチームがより多くのコンピュートを持つことができないという意味ではありません。借りることができます。ですから、それを試してみるために、私は 2 番目のチーム、Team B を定義しています。両方のチームは 1 つのリソースを持つことになり、私が示す例はジョブを送信することです。これで、私たちが設定したすべてをまとめてバンドルしている方法を見ることができます。まず、これは私のクラスターです。私のクラスターは 2 つのインスタンスグループを持っています。1 つはコントローラーで、もう 1 つはトレーニングインスタンスグループです。コントローラーは GPU を持たず、トレーニングインスタンスグループはいくつかの GPU を持っています。それを確認した後、基本的なトレーニングジョブを送信します。優先度を付けていません。ここで優先度付けのためのタグを定義していません。ただ送信しています。この SageMaker HyperPod クラスターは Kubernetes によってオーケストレートされていますが、HyperPod CLI を使用しており、これにより Kubernetes の知識がなくてもジョブを送信できます。hyp create hyp-pytorch-job とジョブ名、コンテナイメージ、プールポリシー、必要なノード数の定義を使用して、ここで 3 つのノードを定義しているのが見えます。送信しています。バックグラウンドで、HyperPod CLI が行っていることは、コンテナ定義を作成し、そのコンテナ定義を Amazon EKS クラスターに送信することです。そのジョブが送信されました。3 つのレプリカがあります。つまり、3 つのポッド、3 つのサーバーを使用しています。ポッドが実行されており、ワークロードが実行されています。これらのポッドが実行されているのを見てみましょう。単純な Kubernetes 管理者として、kubectl get pods を実行できます。このようなポッドが見えます。そして、ポッドがトレーニングしているかどうか見てみましょう。はい、ポッドがトレーニングを開始したのが見えます。トレーニング分割があるので、データセットをトレーニングと検証に分割しています。そして、Hugging Face から直接ファイルをダウンロード、取得しています。完璧です。トレーニングジョブを送信するのは簡単ですよね。でも、これらのノードの 1 つが失敗したらどうなるでしょうか。通常、大規模な分散トレーニング中に、これらのノードは失敗します。今、このデモで私がやっていることは、ノードをスケジュール不可として注釈を付けることで失敗をシミュレートしています。理由は再起動待機中です。それをしたときに何が起こるか見てみましょう。
このコマンドを SageMaker HyperPod に送信します。管理コンソールに行くことができ、ノードスパニングが見えます。もしそれがより深刻な障害だった場合、SageMaker HyperPod が行うことは、そのノードを失敗として注釈を付け、クラスターからそのノードを削除し、現在完璧に実行されている新しいノードを持ってきて、そのノードをクラスターに戻すことです。最初は、ノードが不明な準備完了状態で見えます。しかし、SageMaker HyperPod がそのノードを置き換えた後、数分で、そのノードがオンラインに戻るのが見えます。ノードがないので、ポッドの 1 つが実行を停止し、保留中になっています。ノードがオンラインに戻ったので、その特定のポッドが再び実行されています。そして、すべてのそれをSageMaker HyperPod 管理コンソールで見ることができます。
タスクガバナンスの実践：チーム間のコンピュート容量の貸し借りと優先度制御
では、コンピュート容量を借りることについて話しましょう。 同じことをしています。トレーニングジョブを開始しているのですが、ここでの違いは何でしょうか？ 違いは、トレーニングジョブに優先度をアノテーションしているということです。これはトレーニング優先度で、そのトレーニングジョブに namespace を付与しています。この namespace はチームを作成したときに定義されたものです。 チームを作成するときに、namespace 定義を取得するので、同じ EKS クラスター上で実行するときに異なるチーム間の分離が可能になります。
ジョブを送信します。ジョブは正常に送信され、ポッドは正常に実行されており、HyperPod CLI が 自動的にそのジョブをアノテーションしてくれたことが確認できます。これら 2 つの異なるチームのキューを確認すると、Team A には 1 つの実行中のジョブがあり、Team B にはジョブがまったくありません。 完璧ですが、Team A が単一ノードしか持っていないのに、複数ノード用のジョブを送信した場合、どのようにして実行されているのでしょうか？ ここを見ると、ノード数は 2 です。何が起こったのか見てみましょう。
起こったことは、Team A が実際に Team B から容量を借りたということです。そしてその借りた容量はデータロケーションを通じて確認できます。48 vCPU しかなかったのに、さらに 40 を借りて、今は 88 vCPU を持っています。4 GPU しかなかったのに、さらに 4 を借りて、合計 8 GPU を持っています。これがコンピュート容量を借りるということです。 では戻って、Team B がジョブを送信したらどうなるのか聞いてみましょう。私は Team B から容量を借りています。そのジョブは実行されるでしょうか？
何が起こるのか見てみましょう。これまでと同じ方法で HyperPod CLI を使ってジョブを送信しています。異なるチームで同じ優先度です。そうすると、ジョブが実行されます。ジョブがアノテーションされたことが確認できます。 キューを確認して、今何が起こっているのか見てみましょう。Team A で実行されていたジョブが一時停止されて保留中になっています。 Team B のジョブが実行されています。Team A は一時停止されて保留中です。なぜなら、もう借りた容量がないからです。Team B がそれを取り戻して回収しました。HyperPod CLI の観点からジョブを見ると、namespace Team A には一時停止されたジョブがあり、namespace Team B には実行中のジョブがあります。
では、より低い優先度のタスクをプリエンプトしてみましょう。 現在、training は experimentation より低い優先度です。そこで、Team B に experimentation 優先度で新しいジョブを送信します。 experimentation の重みが 80 で、training の重みが 70 であることを確認できます。ジョブを送信すると、ジョブは正常に送信され、ジョブが実行されます。これで Team B には 1 つの実行中のジョブ（experimentation のもの）があり、そのトレーニングジョブは一時停止されています。なぜなら、より低い優先度だからです。 アロケーションを確認すると、Team A は容量を借りていません。だから Team A のジョブはまだ保留中です。Team B は実際に Team A から容量を借りています。その experimentation ジョブは追加の容量が必要です。Team A から借りて、そこにすべての機能を組み合わせています。
Ultra clustersとMixture of Experts：ネットワーク最適化と大規模分散トレーニング
では、デモはここまでです。ここから、スライドに戻って、HyperPod と Ultra サーバーを使った高度なユースケースをお見せしたいと思います。 Mixture of Experts について詳しく掘り下げ、Ultra サーバーをどう活用するかを説明する前に、ここまでカバーしてきた内容をまとめておきましょう。生成 AI の急速な進化がもたらす課題があり、SageMaker HyperPod がそうした課題を克服し、goodput を向上させるのに役立つということを見てきました。 一つの例として、Perplexity は SageMaker HyperPod を使用して開発を 40% 高速化しています。もう一つのメリットは、柔軟なトレーニングプランを使用することで GPU に簡単にアクセスできるということです。トレーニングプランを使用する利点の一つは、オンデマンド価格と比較して最大 68% の割引が得られることです。つまり、柔軟なトレーニングプランを通じてキャパシティを予約し、そのキャパシティを計画し、さらに割引も得られるということです。タスクガバナンスとトポロジー対応スケジューリングを組み合わせることで、送信するすべてのジョブが、データに近い適切なコンピュートに配置され、利用可能な最速のネットワークを使用することが保証されます。 これらすべてを組み合わせ、実際のユースケースと大量のコンピュートパワーが必要な高度なユースケースについて考えると、複数のサーバーをどのように活用できるかについて詳しく掘り下げる必要があります。 トレーニングデモ中に送信したこれらのジョブはすべて複数のインスタンスを使用していました。そして、それらがどのように接続されているかということです。一つのインスタンスをデータセンターに、もう一つのインスタンスを別のデータセンターに配置したくはありません。同じネットワークスパイン内に相互接続されていないインスタンスを配置することさえ望みません。だからこそ AWS は Ultra clusters を開発しました。これは、多くの異なるサーバーが単一スパインと呼ぶものに相互接続された組み合わせです。つまり、可能な限り最も低いレイテンシー、可能な限り最も高いスループット、そして単一ルート内の最小限のネットワークデバイスで相互接続されているということです。 それだけではなく、Ultra clusters はストレージもまとめています。なぜなら、コンピュートをデータに近づけたいからです。データセットを GPU に近づけ、コンピュートを GPU に近づけたいのは、チェックポイントをできるだけ速く保存する必要があるからです。Ultra clusters は Amazon FSX for Lustre もその単一スパイン上に接続するため、すべてのパフォーマンスが得られます。 ネットワークについてずっと話してきましたが、本当に重要なのでしょうか？単に特定の AWS 製品について話しているだけなのでしょうか？ Nemotron 15 billion parameters をプロファイルしました。Nemotron 15 billion parameters のトレーニング実行をプロファイルしている間に、そのトレーニング時間の 60% がネットワークに費やされていることが判明しました。それは、私たちが呼ぶもの、または市場が呼ぶもの、communication collectives に費やされていました。つまり、GPU がモデルをトレーニングしているとき、重みを学習していますが、ある時点で勾配、つまりそれらの重みを同期し、いくつかの計算を行い、損失関数を適用する必要があります。そしてそれを始めると、今はネットワークを大量に使用しています。これらの collective communications は Message Passing Interface API と呼ばれるライブラリに基づいており、ネットワークを大量に使用しています。 では、AWS はどのようにしてこれらのモデルトレーニングを非常に高速に実行するのに役立つネットワークを開発したのでしょうか？従来のネットワークは Equal-Cost Multi-Path routing、つまり ECMP をフロー ベースのルーティングで使用しています。 つまり、データの転送を開始するとき、単一のチャネルを開き、そのチャネル上で必要なすべてのデータを転送します。単一のチャネルを開き、2 番目のデータペアの転送を開始することもできますが、これら 2 つのチャネルは同じルート内の特定のネットワークデバイスを使用する可能性があり、そのネットワークデバイスはボトルネックまたは単一障害点になる可能性があります。 つまり、AWS が顧客を支援するために行ったことは、Scalable Reliable Datagram、つまり SRD を使用する Elastic Fabric Adapter を開発したということです。 これは AWS によって開発されたプロトコルで、当社のネットワークで使用しています。SRD は、通信用のチャネルを開くと、実際にデータをシャード化し、そのデータを複数の異なるチャネルに分散させ、それらをすべて一緒に使用します。
異なるチャネルが一緒に使用されるため、インスタンス A からインスタンス B へのデータ転送は、利用可能なすべてのチャネルと利用可能なすべてのネットワークデバイスを同時に使用します。 これは、単一のネットワークデバイスが故障しても、大きな影響を受けないということを意味します。市場で公開されているベンチマークを実行しており、インスタンス A と B 間の接続を示しています。SRD がない場合、ネットワークデバイスが故障すると接続は一時的に停止しますが、SRD と EFA を使用すると停止しません。
パフォーマンスの観点からは小さなヒッチが発生します。100% から 80% に低下し、その後すぐに 100% に戻る可能性があります。これは、パケットを複数のデバイスに分散させているからです。すべてをまとめると、 NVIDIA の SuperChip、Grace Blackwell GPU、そしてこれらの EFA デバイスが、ネットワークデバイスが GPU に直接接続されている一つのインスタンスの簡単な図を作成します。GPU はその高速ネットワークにアクセスでき、CPU はその GPU に接続されています。
これが Mixture of Experts とどのようにつながっているかというと、これは高度なユースケースなのですが、Transformer モデルがどのように機能するかを理解することが関わってきます。 Transformer モデルはエンコーディング、エンベディング、データ変換を実行し、新しいデータを生成して相関させます。翻訳や画像生成のようにモデルを特化させるといった高度なユースケースの場合、すべての GPU がすべてのことをやりたがるため、あなたのトレーニング実行に時間がかかっていて、モデルが異なるドメインで良い特化を得られていませんでした。
Mixture of Experts を使うと、異なる GPU がエキスパートになり、ルーターという関数またはロジックがあって、それがそれらのエキスパート全体でデータを管理する方法を理解し、エキスパートが正しいデータを得られるようにします。良い例としては、異なる先生がいる教室が考えられます。数学の先生と英語の先生がいるかもしれません。英語の先生はそのような非常に複雑な代数方程式を受け取りたくありません。その英語の先生はシェイクスピアの本と文学を受け取りたいのに対し、数学の先生は数字を受け取ります。その負荷を分配する誰かが必要で、それがルーターです。
Mixture of Experts には多くのネットワーク通信が必要です。 そのような特定のユースケースでそれらのネットワークがどのように発生するかは、いくつかのステップを含みます。まず、リーダーである rank 0 があり、それがそのプロセスを開始します。 通信を開始し、それらの異なるエキスパートを定義する方法を理解します。その後、あなたのニューラルネットワークの一部である、それらのテンソルがそれらのエキスパートにマップされます。実際にそれらのエキスパートでトレーニングするあなたのニューラルネットワークの部分がそこに移動されます。
それらのエキスパートの定義ができたら、データが交換され、ルーターは特定のインスタンスに座ってデータを別のインスタンスに送信するかもしれません。そのスライドの下部では、2 つの GPU を持つインスタンスであるノード 0 と、同じく 2 つの GPU を持つ別のインスタンスであるノード 1 を持つ画像が見えますが、1 つの GPU があります。ノード 0 とノード 1 にデータを送信するルーターの 1 つが中央にあるルーターであることが見えます。
UltraClusters を使用している場合、72 個の GPU が相互に接続されているため、NVLink スイッチに焦点を当てたネットワークを活用することなく、それらの 72 個の GPU で異なるエキスパートを実行できます。しかし、UltraServer で 72 個以上の GPU を使用している場合、または GPU が少ない他のインスタンスを使用している場合は、そのルーター通信のためにネットワークが必要です。あなたのトレーニングの終わりに、それらのすべての勾配を収集し、最後にもう一度そのモデル状態を保存する必要があります。そうすれば、後で推論のためにそれを使用できます。それが UltraServers にどのようにマップされるか、そしてそれがそれらの UltraCluster にどのようにマップされるか。
これらはすべてを相互に接続するものです。 UltraServers上で、モデルを作成してMixture of Expertsを有効にする場合、expert parallelismを18に定義することができます。つまり、UltraServer上のすべてのサーバーを単一のexpertとして定義し、各expertは4つのGPUにアクセスできるということです。こうすることで、その特定のexpertの通信を単一のサーバー上に隔離でき、そのインスタンスの外で計算を行う必要がなくなります。そして、tensor parallelismを4に定義します。つまり、ニューラルネットワークを4つの異なるGPUに分割し、4つのGPUそれぞれがニューラルネットワークの4分の1を実行してモデルをデプロイするということです。
しかし、72 GPUからさらに離れて144個以上に拡張する場合は、UltraClusterに移行します。UltraServersはNVLink switchで接続され、最大72サーバー、最大72 GPUまで対応します。その後、これらのUltraServersをAlaska PE adapterでScalable Reliable Datagramプロトコルの上に相互接続することで、25,000個以上のGPUを相互接続し、単一のシステムとして動作させることができます。
実践に向けたリソースとベストプラクティス
このセッションを終える前に、ぜひ理解していただきたいいくつかのアクションアイテムがあります。まず1つ目は、これらのUltraServersを実行するための多くのベストプラクティスがあるということです。SageMaker HyperPodの機能を使用して容量を取得し、タスクガバナンスと優先度を設定するだけではなく、特定のバージョンの特定のライブラリをセットアップする必要があります。そしてそのすべてはSageMaker HyperPodのドキュメントとAmazon UltraServerのドキュメントに詳しく記載されています。複数のインスタンスグループについて聞いたことがあるかもしれません。これは最近発表した機能で、例えば1つのGPUを取得して、そのGPUを2つの異なる仮想GPUに分割することができるというものです。ただし、これは現在UltraServersではサポートされていません。
このセッションを終える前にお伝えしたいもう1つのことは、皆さんのスマートフォンを取り出してこれらのQRコードをスキャンできるということです。1つ目のAI on SageMaker HyperPodは、これらのすべての機能を簡単かつ迅速に組み合わせる方法に関する多くの指示を含むリポジトリです。これにより、AWSアカウント上でこれらのクラスターのデプロイメントを高速化できます。今日のこのデモで見たほとんどのことは、そこで説明されており、皆さん自身のアカウントで複製する方法が記載されています。
2つ目のリポジトリであるAwesome Distributed Trainingリポジトリには、例えばDeepSeekの微調整を開始したり、Llamaでのトレーニング、Llama 4やLlama 3でのトレーニング、またはクラスターをテストしてトラブルシューティングしたい場合のマイクロベンチマークなどの例が含まれています。これらのアセットはすべてカスタマーエンゲージメントから生まれたもので、ドキュメントを研究したり、これらすべてをどのように組み合わせるかを理解したりする必要がないように、皆さんが活用できるものであることを理解しています。
では、セッションを終了させていただきます。本当にありがとうございました。re:Invent に来ていただいて、このセッションに参加してくださり、私と Rekha の話を聞いてくださったこと、心から感謝しています。Rekha、ステージをシェアしてくれてありがとうございます。そして、アンケートの記入をお忘れなく。AWS と Amazon のようなデータドリブンな組織として、私たちはそのアンケートが本当に必要なんです。なぜなら、皆さんのコメントを読んでいるからです。皆さんがそこに書いてくださったことは何でも、次のセッションに向けた教訓として活用させていただきます。そして、今日よりもずっと楽しんでいただけることを願っています。本当にありがとうございました。
※ こちらの記事は Amazon Bedrock を利用し、元動画の情報をできる限り維持しつつ自動で作成しています。
Discussion