※本記事は、AWS re:Invent 2024のセッション「A close look at how Amazon built the Nova FMs using SageMaker HyperPod (AIM379)」の内容を基に作成されています。セッションでは、Amazon SageMaker HyperPodが提供する高性能計算処理、分散トレーニングのための耐障害性インフラストラクチャ、可観測性と実験ツール、コスト効率の良い推論オプションなどについて解説されています。AmazonのデータサイエンティストとMLエンジニアがAmazon Nova基盤モデルを構築し、Amazonの生成AI革新を支える方法について学ぶことができます。より詳細な情報は公式サイト（https://go.aws/reinvent ）でご覧いただけます。AWS関連のイベント情報はhttps://go.aws/3kss9CP 、その他のAWS動画はhttp://bit.ly/2O3zS75 、AWSイベント動画はhttp://bit.ly/316g9t4 でご覧いただけます。本記事の内容はセッションの一部を要約したものであり、正確な情報や文脈については、オリジナルの動画をご覧いただくことをお勧めいたします。
1. イントロダクション
1.1. プレゼンターの紹介
- Rajneesh Singh: SageMaker訓練チームのリーダーを務めています。セッションの司会進行と、SageMaker HyperPodがどのように基盤モデル開発の課題を解決するかについての説明を担当しています。
- Anand Rathi: Amazonの人工知能グループ（AGI）のエンジニアリングディレクターです。Amazonに20年以上在籍しており、現在は高性能コンピューティングインフラストラクチャとMLOpsツーリングを担当するチームをリードし、AGIの科学者たちがNOVAモデルを構築・訓練するのをサポートしています。
- Gordon McShane: Amazonの人工知能グループ（AGI）のプリンシパルエンジニアです。Anand Rathiの下でインフラストラクチャに焦点を当てて働いており、基盤モデル開発における技術的課題とその解決方法について説明を担当しています。
1.2. セッションの概要と目的
このセッションでは、Amazon Nova基盤モデル（Foundation Models）の開発過程、直面した課題、そこから得られた学びと、それらをAmazon SageMaker HyperPodにどのように実装したかについて説明します。
冒頭でRajneesh Singhは「Amazon Nova モデルの発表に大変興奮しており、今日のセッションでは、これらのモデルがどのように開発されたのか、どのような課題に直面したのか、それらの課題からどのような教訓を得たのか、そしてそれらの教訓をSageMaker HyperPodでどのように製品化したのかについてお話します」と述べています。これにより聴衆は、基盤モデルを構築または微調整する際に、これらの学びを活用できるようになります。
セッションの始めに、オーディエンスの構成についても確認が行われました。約25％の参加者が基盤モデルの構築や微調整の経験者であり、残りの参加者は基盤モデルの構築方法について知識を得ることに興味を持っていることが分かりました。このセッションは、両方のグループがそれぞれの立場で実践的な学びを得られる内容となっています。
セッションの構成としては、最初に基盤モデル開発の課題概要、次にAnand RathiによるAmazon Nova基盤モデルの概観、続いてGordon McShaneによるAGIチームが直面した課題への対応方法、最後にRajneesh SinghによるAmazon SageMaker HyperPodがこれらの課題をどのように解決するかという流れで進行します。
2. 基盤モデル開発の課題
2.1. 大規模データの調達と処理
基盤モデル開発における課題を非常に高いレベルで見てみましょう。基盤モデルを構築または微調整する場合、まず大量のデータを調達する必要があります。そのデータを調達した後、複数のチャンクに分割する必要があります。それらのチャンクを、クラスターの一部である数百または数千のアクセラレーターに読み込む必要があります。
このプロセスは複雑で大規模です。基盤モデルに必要なデータは多様性が重要で、コンテンツの多様性、言語の多様性、モダリティの多様性などが求められます。このデータが利用可能になったら、処理する必要があります。処理の過程では、無関係なコンテンツをフィルタリングし、有害なコンテンツ、バイアス、重複コンテンツなども除去します。その後、正規化とトークン化の技術を適用し、データを消費できるようにパッケージ化します。
特に大規模なモデル、例えばAmazon Premierのようなモデルでは、このプロセスはさらに大変です。このようなモデルのクラスターは数百から数万、場合によっては10万個近くのアクセラレーターに及ぶことがあります。そして、トレーニングの期間は数ヶ月に及ぶこともあります。
これらのデータを管理し、数万台のアクセラレーターに効率的に供給し続けることは、基盤モデル開発における最初の大きな課題の一つです。
2.3. ハードウェア障害への対応
基盤モデル開発では、チェックポイント戦略を策定し、ハードウェア障害に対処する必要があります。これは非常に大きな課題です。我々が直面している現実は、5万〜6万台、場合によっては7万〜8万台ものアクセラレーターを持つシステムにおいて、障害は避けられないということです。
これらのシステムは数ヶ月間、最大限の負荷で実行され続けます。休憩も休暇もなく連続運転するため、故障は必然的に発生します。この規模では、1日に10〜20回の故障が見られることが一般的です。これはAmazon内部だけでなく、多くの文献でも報告されている状況です。
そのため、障害率を減らすことではなく、障害にどう対処するかを学ぶことが重要になります。最も単純な障害はGPUやNPUが完全に停止するケースで、ドライバーがクラッシュして機能しなくなります。この場合、カーネルログメッセージで「PCIバスから切断された」や「XIDエラー」などの暗号めいたメッセージを受け取りますが、少なくとも障害が検出できます。
しかし、より厄介なのは宇宙線などの外部要因による障害です。宇宙からの粒子がRAMに衝突してビットを反転させることがあります。現代のハードウェアはECCメモリなどでこれらに対処する方法を見つけていますが、2万台のホストがある環境では、これらの宇宙線による影響も蓄積されます。
最も困ったのはハードウェアが何も告げずに仕様通りに動作しなくなるケースです。これは「サイレントデータ破損（SDC）」と呼ばれています。これはGPU上のあるプロセッサで計算が微妙に狂い、その結果としてモデルが破損する状態です。損失曲線や勾配ノルムなどが乱れ始めますが、これが発見されるまでに何時間もかかることがあります。
数万台のアクセラレーターの中から、どのホストが微妙に誤動作しているかを特定するのは、「干し草の山から針を見つける」ようなものです。我々はこれらの障害を早期に発見し、迅速に回復するための戦略を開発する必要がありました。そこで、バーンインテスト、適応モニタリング、効率的なチェックポイント作成、予備のホット・スペアなどの対策を講じています。
この種の課題に対処するため、我々はカオスに備えた設計を採用し、失敗を前提としたシステムを構築しています。障害が発生したらすぐに停止し、必要最小限の部分だけを再起動することで、障害からの回復を数秒で行えるようにしています。
3. Amazon Nova基盤モデルの概要
3.1. Nova モデルファミリーの紹介（Micro, Lite, Pro, G8, Canvas, Reel）
Amazonの創業以来、当社のミッションは顧客の生活をより良くすることであり、AIとMLシステムはそのビジョンと使命を現実のものにする上で重要な役割を果たしてきました。皆さんも経験されたことがあるでしょうが、Amazonでのパーソナライズされたレコメンデーションは、最も初期の大規模なML基盤のレコメンダーシステムの一例です。「Xを購入した顧客はこれらのアイテムにも興味がある」というものですが、これにより顧客は考えていなかった新しい製品を発見できるようになりました。
Alexaは主要なパーソナルデジタルアシスタントであり、30の異なるMLシステムが毎週数十億の顧客クエリへの応答を調整しています。これらは天気やその他の情報の問い合わせから、音楽やその他のビデオコンテンツの発見、スマートホームデバイスの制御など、様々なことが可能です。
こうした数十年の経験と専門知識を活かして、私たちはAmazon Nova基盤モデルファミリーを構築し、お客様と共有しています。昨日の発表をご覧になった方もいらっしゃるでしょうが、簡単に再確認します。
Amazon Novaファミリーの主力モデルは、Nova Micro、Nova Lite、Nova Proです。Microは高速な基盤モデルで、入力と出力の両方でテキストをサポートします。より高度なものをお求めなら、LiteやProに移行できます。これらのモデルは、入力モダリティでテキストに加えて画像と動画をサポートし、出力モダリティではテキストベースになっています。
これら3つに加えて、G8、Canvas、Reelも提供しています。これらはテキストから画像、テキストから動画を生成する基盤モデルです。お客様はシンプルなテキストベースのプロンプトで画像や動画を生成できます。また、カメラのパンニングなどの高度なコントロールも提供しているため、モデルの出力をニーズや希望に合わせて制御できます。
来年の第1四半期には、最も高度な推論能力を持つマルチモーダルモデルであるAmazon Nova Premierをリリースする予定です。これらのモデルは社内の様々なチームやビジネスでも採用が進んでいます。
3.2. Nova Premier（Q1 2025リリース予定）の特徴
2025年第1四半期にリリース予定のAmazon Nova Premierは、Novaファミリーの中で最も高度な能力を持つマルチモーダルモデルです。高度な推論能力を特徴としており、Amazon Novaファミリーの最上位に位置づけられています。
Nova Premierの開発には膨大な計算リソースが投入されています。このモデルのクラスターは、数万から場合によっては10万近くのアクセラレーターに及び、トレーニング期間は数ヶ月にわたります。このような大規模な計算資源を活用することで、より複雑な推論タスクや多様なモダリティの処理が可能になっています。
Nova Premierの正確な能力についての詳細は発表されていませんが、テキスト、画像、動画などの入力モダリティを処理し、高度な理解と推論に基づいた応答を生成できると期待されています。これは、企業内の様々なチームやビジネスがすでに採用を始めている他のNovaモデルの拡張版として位置づけられています。
プレゼンテーションでは、Nova Premierの具体的な技術仕様や性能指標については触れられていませんが、Amazonの最も高度な基盤モデルとして、社内外での様々な用途に活用される予定です。
3.3. 企業内での活用事例
Amazon Novaモデルは、すでに社内のさまざまなチームやビジネスで活用が進んでいます。以下にいくつかの具体的な活用事例を紹介します。
あらゆる規模のブランドが、シンプルな製品説明を提供するだけで、顧客と共鳴し、関心を引くための広告キャンペーン用のクリエイティブを数回のクリックで生成できるようになりました。販売している製品のシンプルな説明を提供するだけで、広告キャンペーンを開始するための素材が準備できます。
同様に、Prime Videoは、エピソードやシーズンの要約を自動生成するためにNovaモデルを使用しています。新しいシーズンを視聴し始めるときには、短い要約ビデオがありますが、その作成には手動で何週間もの労力がかかります。しかし、これらのモデルを使用すれば、ビデオを取り込み、重要なプロットポイントやストーリーアークを特定し、要約ビデオがどのようなものであるべきかの推奨事項を提供することができます。それにより、手動での作業量が週単位から日単位に削減されます。
開発者ツールは、これらのモデルを展開するための非常に肥沃な領域です。コーディングアシスタントとして機能したり、運用アシスタントとして機能したりすることができます。例えば、エンジニアが運用上の問題に対処するためにページングされた場合、ダッシュボード、デプロイメントなどからの最新のメトリクスなど、さまざまなデータを自動的に収集して提供できます。
これにより、エンジニアが問題を見始める頃には、消費しやすい素晴らしい要約が準備されており、トラブルシューティングの時間が短縮されます。それに加えて、ドキュメントの生成やユニットテストの生成など、隣接するタスクも実行できるため、開発者の生産性が大幅に向上します。
他の運用チームもこのモデルファミリーから恩恵を受けています。例えば、AWS Field Engineeringはさまざまなお客様をサポートしており、Genieというシステムを使用しています。現在、NOVAの力を借りて、Genieは顧客からの複雑なシステムやその他のアーキテクチャ図を取り込むことができます。そして、AWSのベストプラクティスやドキュメントに基づいて、最適化の機会を特定し、フィールドエンジニアがより効果的に顧客をサポートできるようになっています。
これらのモデルが一般公開されると、お客様がどのような活用方法を見つけるのか、私たちは非常に期待しています。
4. 基盤モデル構築プロセス
4.1. データ収集と処理（多様性、フィルタリング、正規化）
これらのモデルを構築するには、村以上のものが必要です。まず大量のデータを取得することから始めます。データには多様性が必要です。コンテンツ自体の多様性、言語間の多様性、モダリティ間の多様性など、さまざまな種類の多様性が求められます。
このデータが利用可能になったら、処理する必要があります。処理の過程では、関連性のないコンテンツをフィルタリングします。有害なコンテンツ、バイアス、重複コンテンツなども除去します。その後、正規化とトークン化の技術を適用し、データを消費できるようにパッケージ化します。
並行して、科学チームはさまざまなモデルアーキテクチャとハイパーパラメータのチューニングに関する実験を実行し、構築したいモデルの正しいタイプを特定します。
これらの二つのステップが完了すると、大規模なトレーニング実行を開始する準備が整います。これは事前トレーニングフェーズと事後トレーニングまたは微調整フェーズの二つの部分で構成されています。
事前トレーニングは、プロセスの中で最も計算負荷の高い部分です。モデルアーキテクチャとさまざまなハイパーパラメータを考慮し、そのトレーニングレシピを用意し、データを取り込み、大規模な計算クラスターを立ち上げます。
モデルがどのように進行しているか、正しい軌道に乗っているかどうかを確認するために、科学チームも損失曲線を綿密に監視しています。もし軌道が外れている場合は、実行を一時停止し、データミックスやいくつかのパラメータを調整してから、その時点から再開します。
十分な量のトレーニングトークンがモデルに消費されると、微調整段階に引き継がれます。事前トレーニング段階から出てくるのは、高度に一般化されたモデルです。微調整では、それをより専門化します。モデルは指示に従う方法を教えられたり、会話型AIの機能のために特殊化されたりします。
4.2. モデルアーキテクチャとハイパーパラメータの実験
データの調達・処理と並行して、科学チームはさまざまなモデルアーキテクチャとハイパーパラメータのチューニングに関する実験を実行しています。この段階では、構築したいモデルの最適なタイプを特定することが目的です。
実験プロセスでは、モデルの様々な構成要素—アテンションメカニズム、レイヤー数、隠れ層のサイズ、アクティベーション関数など—を変更して、それぞれの性能を評価します。特にトランスフォーマーモデルでは、アテンション層は計算コストが高く、モデルの二次的な性質を生み出している重要な部分です。
これらの実験は非常に計算集約的であり、大規模なインフラストラクチャを必要とします。科学チームはモデルのトレーニング中に損失曲線を綿密に監視し、モデルが正しい軌道に乗っているかどうかを常に評価します。損失曲線やその他の指標に問題が見られる場合、トレーニングを一時停止し、データミックスやハイパーパラメータを調整した上で、その時点から再開します。
ハイパーパラメータの最適化は特に重要です。学習率、バッチサイズ、エポック数、ドロップアウト率など、様々なパラメータがモデルの性能に大きく影響します。2022年まではモデルを訓練するためのトークン数の決定は経験則的なプロセスでしたが、その後の研究により、モデルパラメータ1つにつき20のトレーニングトークンが最適であることが証明されました。
この発見により、70億パラメータのChinchillaモデルが175億パラメータのGPT-3を性能で上回るという現象が説明できました。小さいながらもより効率的に訓練されたモデルが、より大きくて十分に訓練されていないモデルを上回ることができるのです。
さらに、最近のLlama論文では、モデルがこの「最適」な比率を超えてもさらに改善し続けることが示されました。現在では、モデルパラメータの40倍、60倍、時には80倍のトークン数でトレーニングすることも一般的になっています。これは、比較的小さい8Bパラメータのモデルでも、6兆から7兆トークンでトレーニングされる可能性があることを意味します（もちろん、そのためのデータと計算リソースがあれば）。
こうした実験と発見を通じて、ハイパーパラメータの最適化の重要性がますます明らかになっており、Nova FMの開発においてもこの知見が活かされています。
4.3. 事前トレーニングと微調整フェーズ
これらの二つのステップ（データ処理とモデルアーキテクチャの実験）が完了すると、大規模なトレーニング実行を開始する準備が整います。これは事前トレーニングフェーズと事後トレーニングまたは微調整フェーズの二つの部分で構成されています。
事前トレーニングは、プロセスの中で最も計算負荷の高い部分です。ここでは、モデルアーキテクチャとさまざまなハイパーパラメータ、つまりそのトレーニングレシピを用意し、データを取り込み、大規模な計算クラスターを立ち上げます。Amazon Premierのようなモデルの場合、クラスターは数百から数万、場合によっては10万個近くのアクセラレーターに及ぶことがあります。そして、期間は数ヶ月に及ぶこともあります。
このプロセスでは、異常やストラグラー（遅延ノード）、速度低下の兆候がないかシステムメトリクスを監視する必要があります。並行して、科学チームもモデルがどのように進行しているか、正しい軌道に乗っているかどうかを確認するために、損失曲線を綿密に監視しています。もし軌道が外れている場合は、実行を一時停止し、データミックスやいくつかのパラメータを調整してから、その時点から再開します。
十分な量のトレーニングトークンがモデルに消費されると、微調整段階に引き継がれます。事前トレーニング段階から出てくるのは高度に一般化されたモデルです。微調整では、それをより専門化します。モデルは指示に従う方法を教えられたり、会話型AIの機能のために特殊化されたりします。
このステップが完了すると、非常に高性能ではあるものの、実行コストの高い教師モデルが得られます。モデルの推論経済を持続可能にするために、圧縮や蒸留などの技術が適用されます。これにより、モデルは同等の能力を持ちながらも、より小型のモデルにパッケージ化されます。
そして、さまざまなベンチマーク（内部および外部の両方）に対するモデルのパフォーマンスに満足したら、BedRockなどのシステムを通じて提供される準備が整います。一つのサイズですべてに対応するわけではないので、異なるモデルサイズと能力のスイートを提供し、お客様は最適なパフォーマンスを提供できるものを選択できます。
時には最高のモデルでもニーズを満たせない場合があるため、お客様が独自のデータを持ち込み、これらのモデルをカスタム微調整して、より特殊なものにする機能も提供しています。
4.4. モデル圧縮と蒸留技術
事前トレーニングと微調整のステップが完了すると、得られるのは高度に能力の高いものの、実行コストが非常に高い教師モデルです。これらの基盤モデルの推論経済を持続可能なものにするために、次のステップとして圧縮と蒸留といった技術が適用されます。
圧縮と蒸留プロセスの目的は、大規模で高性能な教師モデルの知識を、より小型でありながらほぼ同等の能力を持つモデルに転移させることです。これにより、モデルは同等の能力を保持しながらも、より小さく効率的なサイズにパッケージ化されます。
蒸留プロセスでは、大規模な教師モデルがより小型の生徒モデルを「教育」します。教師モデルの出力を用いて生徒モデルをトレーニングすることで、より小さいモデルが大きいモデルの振る舞いを模倣できるようになります。これにより、計算リソースの要求が少ない状態でも、類似した性能を発揮できるようになります。
また、量子化や枝刈り（プルーニング）などの圧縮技術も適用されます。これらの技術により、モデルの重みを減らしたり、精度を低く表現したりすることで、モデルサイズを縮小し、推論速度を向上させることができます。
そして、内部および外部の様々なベンチマークに対するモデルのパフォーマンスに満足すると、これらのモデルはBedRockなどのシステムを通じて提供される準備が整います。ユースケースやパフォーマンス要件が異なるため、異なるモデルサイズと能力のスイートを提供しています。お客様は自分のニーズに最適なパフォーマンスを提供できるモデルを選択できます。
場合によっては、最高のモデルでもお客様の特定のニーズを満たせないことがあります。そのため、お客様が独自のデータを持ち込み、これらのモデルをカスタム微調整して、お客様の用途に特化したモデルを作成する機能も提供しています。
5. 基盤モデル開発の技術的課題
5.1. メモリの壁（Memory Wall）
AGIへの競争が激化する中で、「スケーリングの法則」により、モデルは2年ごとに約410倍のサイズになるという傾向があります。ほんの数年前には40億のパラメータが最先端と考えられていましたが、現在ではすでに兆単位のパラメータ規模に達しています。
しかし、アクセラレータ（GPUやNPUなど）を見ると、メモリ容量は単に2倍になっているだけです。そのため、私たちは「メモリの壁」に直面しています。アクセラレータは、どんどん大きくなるモデルのメモリ要求に追いつくことができないのです。
このメモリの壁について具体的に考えてみましょう。幸いなことに、この問題は線形です。モデルにパラメータを追加するたびに、必要なメモリの増加量は一定です。例えば、5年ほど前に最先端だった40億パラメータのモデルを考えてみましょう。単精度やBF16の場合、重み、活性化、オプティマイザの状態など、すべてを考慮すると、このモデルを訓練するために約72ギガバイトのメモリが必要です。
これは家庭用ラップトップでは得られない規模ですが、現代のハードウェアでは実現可能です。H100は現在80ギガバイトのRAMを搭載しており、P4DEも相当量のメモリを持っています。おそらくそこに収めることができるでしょう。Chromeのタブをいくつか閉じる必要があるかもしれませんが、何とかなります。
しかし、今日の基盤モデルのサイズはどうでしょうか？現在は4000億パラメータに到達しており、これは業界の現状を示す適当な数字です。これは40億パラメータの100倍です。つまり、72ギガバイトの18倍、7.2テラバイトのメモリが必要になります。
明らかに、これはもはや1台のH100には収まりません。実際には約100台のH100か、12台のP5が必要になります。誰もが12台のP5を持っているわけではありません。さらに、この状況は別の影響も及ぼします。モデルの重み、モデル自体、チェックポイントなどは7.2テラバイトになり、これを可能な限り頻繁に（秒単位で）保存する必要があります。そうなると、ペタバイト単位のデータをどこかに保存し、それを高速かつ効率的に行う方法を考える必要があります。
この「メモリの壁」を克服するために、私たちは様々な並列化戦略を採用しています。テンソル並列性を使ってモデルの幅を分散させ、パイプライン並列性を使ってモデルの深さを分散させるなどの方法です。しかし、これらの並列化戦略自体が新たな課題を生み出すため、総合的なアプローチが必要です。
5.2. 計算能力の制約（Compute Constraint）
計算能力の制約は、メモリの壁と比べて状況はさらに厳しいものです。パラメータ数が増加するにつれて、使用する計算量は二次関数的、あるいはそれ以上に増加します。先ほど言及した40:1の比率も増加し続けていて、モデルを最適にトレーニングするために必要な計算能力は継続的に拡大しています。
同じ思考実験をしてみましょう。40億パラメータのモデルを例に取り、1600億トークンをそこに通すとします。これには約6回の浮動小数点演算が必要で、そうすると約3,840エクサフロップの計算が必要になります。これは既に非常に大量の計算です。
先ほど、4000億パラメータのモデルを12台のP5に読み込むことができると説明しました。では、そのハードウェアで40億パラメータのモデルをトレーニングしてみましょう。すべてがうまくいけば、約1日でトレーニングが完了します。それほど悪くありません。
しかし、これを4000億パラメータにスケールアップすると、16兆のパラメータとなり、3800万エクサフロップの計算が必要になります。同じ12台のP5を使用した場合、私の子供たちが大学に入学する頃、つまり約20年かかることになります。明らかにこれは大きな問題であり課題です。
このような課題を解決するために、非常に高度な並列化戦略を導入する必要があります。まず、モデル内の計算コストの高いレイヤー、特にトランスフォーマーモデルのアテンションレイヤーに対処する必要があります。これらはモデルの二次的な性質を生み出している特殊なレイヤーです。
モデルの幅を処理するために、テンソル並列性という手法を使用します。個々のレイヤーを水平方向にスライスし、これらの計算を複数のデバイスに分散させます。計算の分散後は、結果を集約する必要があり、これによりネットワーク上で非常に会話量の多い処理が必要になります。そのため、非常に特定のネットワークリンクに依存する必要があります。Andyが言及したTRN2には「Neuron Link」と呼ばれる非常に高速な相互接続があり、NVIDIAも「NVLink」という同様の技術を持っています。このような種類の並列化を効率的に行うには、これらの数百ギガバイト毎秒のリンクを使用する場合に限られます。
次はモデルの深さです。モデルが深くなるほど、タスクをよりうまく処理できるようになる傾向があります。ここではパイプライン並列性を使用し、レイヤーのシーケンスをステージに分割します。各ステージで計算を行い、次のステージに渡し、前のステージでは次のサンプルの計算を続けるというアプローチです。これは効率的な方法ですが、明らかな非効率性もあります。例えば、上部の第3ステージがボトルネックの場合、他のすべてのステージはそれを待つことになります。これは「パイプラインバブル」と呼ばれる問題です。
これらの並列化戦略を適用しても、先の例で挙げた12台のP5で4000億パラメータのモデルをトレーニングするのに約20年かかるという問題は解決しません。そこで第3の並列化タイプであるデータ並列性を導入する必要があります。これは非常にシンプルで、ほぼ水平スケーリングに近いものです。GPUやNPUの2D行列を取り、モデルを複製します。10個、100個のモデルを一緒にトレーニングしているかのように、個々のデータシャードを渡します。そして一定期間後に、すべてのモデルの値を収集し、平均化し、これらの異なるレプリカに送り返します。同期化コストが上限に達するまで、これを無限に続けることができます。
これらの3つの並列化戦略を組み合わせることで、基盤モデルのトレーニングに必要な膨大な計算能力の問題に対処しています。しかし、この種の分散トレーニングは、データ処理のような「恥ずかしいほど単純な並列化」とは異なり、非常に複雑です。分散トレーニングは高度に状態を持ち、相互依存性が高く、双方向的であるため、これらの欠点のコストを最小化するための多くの戦略を使用する必要があります。
5.3. トレーニングトークン対モデルパラメータの関係（Chinchillaの法則）
2022年まで、モデルを訓練するために必要なトークン数を決定することは非常に経験則的なプロセスでした。しかし、その後に発表された論文では、モデルを最適に訓練するためには、モデルパラメータ1つにつき20のトレーニングトークンが必要であることが証明されました。
この閾値を下回ると、モデルは十分に訓練されていないことになります。研究者たちは非常に興味深い比較を行いました。70億パラメータのChinchillaモデルが、175億パラメータのGPT-3を性能で上回ったのです。これは、より効率的に訓練された小さなモデルが、大きくても十分に訓練されていないモデルより優れた結果を示すことを証明しています。
具体的な例を挙げると、70億パラメータのモデルを構築しようとする場合、この法則によれば1.4兆トークンが必要になります。この計算要求は、パラメータ数が増えるにつれて組み合わせ爆発的に増加します。グラフのx軸とy軸はどちらも対数スケールであることに注意してください。つまり、計算需要は指数関数的に増加するのです。
さらに、これで終わりではありません。Chinchillaの論文では、パラメータ対トークンの比率が20:1が最適とされていましたが、Llamaの論文では、モデルはその比率を超えてもさらに賢くなり続けることが証明されました。
現在のトレンドでは、モデルパラメータの40倍、60倍、80倍のトークン数でトレーニングしています。つまり、比較的小さい80億パラメータのモデルでも、データと必要な計算リソースがあれば、6兆から7兆トークンでトレーニングされる可能性があるのです。
明らかに、ハードウェアの進化を待っているだけでは対応できません。これらの問題に対処するために、大規模で強力なクラスターを展開しています。また、低精度でのトレーニングやMoE（Mixture of Experts）によるスパーシティのような科学的進歩も助けになっていますが、トレーニングクラスターは不可避です。
このChinchillaの法則とその発展的な研究は、基盤モデルのトレーニングに必要な計算リソースの規模を理解する上で非常に重要です。モデルの能力を向上させるためには、単にパラメータ数を増やすだけでなく、十分な量のトークンでトレーニングすることが不可欠であることを示しています。これは、私たちのインフラストラクチャと並列化戦略の設計に大きな影響を与えています。
6. AGIチームのインフラストラクチャ
6.1. 物理インフラの構成（EC2、EFA、FSxLuster、S3）
私たちが使用している物理インフラについて具体的にお話ししましょう。最下層には、私たちのコンピュートとストレージがあります。
明らかに、EC2アクセラレーテッドインスタンスを使用しており、非常に大きなフリートを持っています。実際には多くの異なる組み合わせを使用しています。P4DEを使用し、P5を使用し、Trainium 1とTrainium 2も使用しています。Andyはちょうどそれを発表したところなので、皆さんのためにそれをテストドライブできて嬉しく思います。
また、これらの高性能インスタンス間の相互接続としてEFA（Elastic Fabric Adapter）を使用しています。これは非常に重要です。なぜなら、現在これらの非常に強力なインスタンスはI/Oバウンドだからです。このEFAは基本的にマイクロ秒レベルのレイテンシと毎秒数百ギガビット、毎秒50ギガバイトを提供しています。
そして右側には、私たちが使用するブロックストアであるFSx Lusterがあります。これは非常に高性能なHPCクラスのネットワークアタッチドストアです。多くの用途に使用していますが、主にデータのシャッフルを行い、オンザフライで再パッケージングする必要がある場合に非常に役立ちます。これには通常、データへのランダムアクセスが大量に必要になります。
そしてもちろん、すべてをバックアップするS3もあります。これは私たちのオブジェクトストアです。安全で非常に信頼性が高いため使用しています。しかし、何年もかけて、これをほぼ無限にスケールアウトする方法を学びました。S3チームはこれに驚くほど優れており、新しいExpress Zoneでこれらの機能をさらに拡張し続けています。これによってローカルにより高性能かつ低レイテンシのキャパシティが提供されます。
チェックポイントはそこに保存し、マルチモーダルデータの多くはS3からストリーミングしています。
これら全てをまとめたのが、Amazon HyperPod製品です。このインフラストラクチャと下層のすべてを管理することは非常に時間を要します。これらのスタック層にはそれぞれ異なるドライバーがあります。使用しているCUDAバージョン、Neuronバージョン、EFAバージョン、これらすべてのコンポーネント、NickelバージョンやENCOMバージョン、これらすべてが関わってきます。そして、これらすべてを正しく、安定的、かつパフォーマンスの高い構成で揃える必要があります。
HyperPodは基本的に私たちのコントロールプレーンです。これらのクラスターを非常に簡単にデプロイし、維持し、これらのインスタンスをすべてオンザフライでアップグレードすることができます。また、それらを監視するのにも役立っています。
私がこの製品について今年本当に印象的だと感じたのは、SageMaker HyperPodチームが私たちのニーズとする機能のオプション性について本当に理解していることです。オープンソースコミュニティのスタックは非常に盛んで、テストして試す必要のある多くの異なるオプションがあります。HyperPodが行ったことの一つは、使用したい特定のスケジューラを選択できるようにしたことです。社内では、私たちはKubernetes、特にEKSに非常に依存しています。
6.2. Amazon HyperPodによる制御プレーン
Amazon HyperPodは、私たちのインフラストラクチャを管理するための制御プレーンとして機能しています。大規模な基盤モデルのトレーニングには、様々なレイヤーの技術スタックを正確に連携させる必要があり、それぞれに異なるドライバーやバージョンが必要です。使用しているCUDAバージョン、Neuronバージョン、EFAバージョン、Nickelバージョン、ENCOMバージョンなど、これらすべてのコンポーネントが関係してきます。これらすべてを正しく、安定的、かつパフォーマンスの高い構成で揃えることは、非常に時間を要する作業です。
HyperPodは、これらのクラスターを非常に簡単にデプロイし、維持し、これらのインスタンスをオンザフライでアップグレードする能力を提供しています。また、クラスターの監視にも役立っています。HyperPodチームが本当に理解しているのは、私たちが必要とする機能のオプション性です。
オープンソースコミュニティのスタックは非常に活発で、テストして試す必要のある多くの異なるオプションがあります。HyperPodの重要な特徴の一つは、使用したい特定のスケジューラを選択できるようにしていることです。社内では、私たちはKubernetes、特にEKSに非常に依存しています。
HyperPodは基盤となるハードウェアの管理だけでなく、私たちの様々なトレーニングワークフローにも対応しています。例えば、ある日は蒸留を行い、別の日は事前トレーニング、そしてまた別の日は強化学習のような事後トレーニング活動を行うなど、ワークロードの多様性と使用するホストタイプの異種性に対応するために、異なる構成間を素早く移行できる必要があります。HyperPod上のEKSは、このような全体構成を変更する敏捷性を提供しています。
HyperPodは、私たちのトレーニングインフラストラクチャの管理を大幅に簡素化し、科学者やエンジニアがモデル開発自体に集中できるようにしてくれています。これにより、インフラストラクチャの管理ではなく、モデルの品質とパフォーマンスの向上に時間を費やすことができるのです。
6.3. Kubernetesとの統合（特にEKS）
なぜKubernetesを使用しているのかについて少し説明します。使用するホストタイプすべての多様性と異種性により、異なる構成間をオンザフライで素早く移行できる必要があることがわかりました。
Anandが言ったように、ある日は蒸留を行い、次の日は事前トレーニングを行い、その次の日は強化学習のような別の事後トレーニング活動を行う必要があります。HyperPod上のEKSは、これらの全体構成を変更するための俊敏性を本当に提供してくれています。
ワークロードの多様性と使用するすべてのホストタイプの異種性により、異なる構成間を素早く移行する必要があります。これが、Kubernetesが私たちのインフラストラクチャにとって非常に重要である理由です。Kubernetesは、様々なコンピューティングリソースを抽象化し、統一されたインターフェースを提供することで、異なるワークロードタイプへの迅速な移行を可能にします。
特にEKS（Elastic Kubernetes Service）は、HyperPod上で動作することで、強力な管理機能と柔軟性を提供します。科学チームのメンバーは、トレーニングコードの多くをPythonで記述しており、ハイパーパラメータの最適化やラダートレーニングなどを定義する際にも再びPythonを活用しています。
この組み合わせにより、科学者は基盤となるインフラストラクチャの複雑さを心配することなく、自分たちの実験に集中できます。EKSはリソースの割り当て、スケジューリング、障害の処理などを管理し、科学者たちはモデル開発の科学的側面に専念できるのです。
この構成の柔軟性は、基盤モデル開発においては特に重要です。なぜなら、開発サイクルの異なる段階で大きく異なるリソース要件が必要になるからです。事前トレーニング、微調整、蒸留、評価など、各ステージは独自のコンピューティング要件を持ち、Kubernetesはこれらの多様なワークロードに対応するための理想的なオーケストレーションレイヤーを提供します。
6.4. モニタリングとメトリクス収集システム
インフラストラクチャスタックの中で、もう2つの重要な要素についてお話ししたいと思います。まず、MWAA（Managed Workflows for Apache Airflow）があります。これはAWSでのApache Airflowのマネージドバージョンです。私たちはこれをMLflowと組み合わせて使用し、実験の再現性を非常に高めています。
科学者たちは実際にAirflowの使用を好んでいます。なぜなら、トレーニングスクリプトとトレーニングコードベースの多くがPythonで書かれており、ハイパーパラメータの最適化やラダートレーニングなどを定義する際にもPythonを再び活用できるからです。そして、もう一方のMLflowはすべての構成、すべてのモデルメトリクス、さらにはいくつかのシステムメトリクスも捕捉しているため、パフォーマンスのボトルネックやモデルのパフォーマンスのボトルネックを詳細に調査することができます。
そして右端には、マネージドPrometheus、マネージドGrafana、CloudWatchというスタックがあります。私たちはこれらに膨大な量のメトリクスを投入しています。これらのクラスターを監視し、ジョブレベル、インフラレベル、クラスタースケジューリングレベルのどこでパフォーマンスが遅れているのかを理解する必要があります。
私たちは「すべてを測定する」というアプローチを取っています。モデルからホストに至るまで、スタックのすべての層から膨大な量のメトリクスを収集しています。しかし、重要なのはこのデータをすべて入手した後、それを意味のある形で可視化することです。データ量が非常に多いため、使用しているモデル、クラスター、データセンターの形に合わせた意味のあるダッシュボードに変換しないと、実用的ではありません。
AWS内の誰でも使用できるようになったMLトポロジーAPIを使用すれば、これを意味のある形で視覚化し、クラスターのこの領域に問題があるかどうかを素早く判断し、それらの問題を迅速に分離することができます。
また、これらのすべてのメトリクスをGoodPutのような高レベルのKPIに戻すことも重要です。GoodPutは、モデルを稼働させている時間のうち、実際に価値のあることを行っている時間の割合を測定するものです。つまり、これらのモデルの全体的な出力に実際に貢献している時間の割合です。チェックポイントの保存、インフラストラクチャの再起動、モデルのメモリへの再ロード、データの再ストリーミングなどはすべて、この測定にはカウントされません。
私たちは常に95%、96%、97%、98%のGoodPutを目指して努力しています。これを実現するために、いくつかの重要な戦略を採用しています。例えば、問題が見つかればすぐに迅速に失敗し、同様に迅速に回復することを重視しています。何か問題が見つかった場合、待たずにすぐにクラッシュさせますが、回復を優先し、絶対に必要なものだけを停止します。
7. 並列化戦略
7.1. テンソル並列性（Tensor Parallelism）
メモリと計算の壁という課題を解決するために、私たちはかなり高度な並列化戦略を導入する必要があります。まずは、すべてが1つのGPUやNPUに収まる幸せな状態から始めましょう。
最初に直面する問題は、モデル内の計算コストが非常に高いレイヤーに対処する必要があることです。特にトランスフォーマーモデルで聞いたことがあるかもしれない注意（アテンション）レイヤーです。これらは実際に、これらのモデルの二次的な性質を生み出している特殊なレイヤーです。これらを並列化する必要があります。
モデルの幅が実際に必要な並列性を決定します。この場合、モデルの幅は基本的にコンテキスト長に関連しています。これは、皆さんが最近これらのモデルを使用した際に、Bedrock画面で「送信」をクリックする前にどれだけのコンテキストを入力できるかということです。これが処理する必要がある幅の一部を生成しています。
ここではテンソル並列性と呼ばれるものを使用します。個々のレイヤーを水平方向にスライスし、これらの計算を分散させます。そしてこれらの計算を分散させると、行列乗算などの演算を行った後、これらの結果をすべて集約する必要があることは想像できるでしょう。
このため、ネットワーク上で非常に会話量の多い処理が必要になります。そして実際には、非常に特定のネットワークリンクに依存する必要があります。Andyが言及したTRN2には「Neuron Link」と呼ばれる非常に高速な相互接続があり、NVIDIAも「NVLink」という同様の技術を持っています。基本的には、毎秒数百ギガバイトのリンクを使用する場合にのみ、この種の並列性を効率的に行うことができます。
これらのリンクの高速性と低レイテンシーのおかげで、テンソル並列性を導入してモデルの幅を複数のアクセラレーターに分散させることができます。この手法により、単一のデバイスのメモリ制限を超えるような大規模なモデルであっても、効率的に処理することが可能になります。
特に、アテンションレイヤーでは入力の長さの二乗に比例して計算量が増加するため、テンソル並列性はこのボトルネックを解消する上で非常に重要です。モデルの幅に対処できたら、次は深さに対処する必要があります。
7.2. パイプライン並列性（Pipeline Parallelism）
モデルの幅に対処した後、次は深さに注目する必要があります。これらのモデルが深くなればなるほど、よりスマートになる傾向があります。私はそれが実際に何を意味するのかについて主張するつもりはありませんが、これらのモデルが深ければ深いほど、タスクをより適切に処理できるようになります。
そこで私たちはパイプライン並列性と呼ばれるものを使用します。これは、レイヤーのシーケンスを取り、それらをステージに分割するというものです。各ステージで計算を行い、それを次のステージに渡し、前のステージでは次のサンプルの計算を続けます。
ここで示されているように、これはかなり効率的な方法ですが、明らかな非効率性も存在します。例えば、上部にある第3ステージがボトルネックになっている場合、他のすべてのステージはその処理を待つことになります。
検索用語として皆さんに調べてほしいのは「パイプラインバブル」です。私たちは毎日これに対処していますが、これはレイヤーの待機によって発生する非効率性のことです。
パイプライン並列性によって、モデルの深さ方向（レイヤー方向）の分割が可能になり、各ステージが独立して計算を進めることができます。これにより、モデル全体を一度に1つのデバイスに収める必要がなくなります。しかし、この方法にも課題があります。
特に問題となるのが「パイプラインバブル」と呼ばれる非効率性です。これは、パイプラインの異なるステージが同期して動作しないときに発生します。例えば、あるステージが他のステージよりも計算に時間がかかる場合、他のステージは待機状態となり、全体的な効率が低下します。
この課題に対処するため、様々な最適化技術が開発されています。例えば、マイクロバッチ処理や1Fと1Bのスケジューリング戦略などです。これらは基本的にパイプラインをより効率的に使用するための方法で、バブルを最小限に抑えることを目指しています。
パイプライン並列性を導入することで、非常に深いモデルをトレーニングすることが可能になりますが、それでも計算能力の壁には対処できていません。私たちが前に言及した、12台のP5でも400億パラメータのモデルのトレーニングに約20年かかるという問題です。これに対処するために、私たちは第3の並列化タイプを導入する必要があります。
7.3. データ並列性（Data Parallelism）
これでモデルをまとめる良い位置にありますが、以前話していたポイントに達した後もまだ20年のトレーニング時間という問題が残っています。これらすべての並列化を行った後でも、400億パラメータのモデルを12台のP5でトレーニングするのに約20年かかるという状況です。
そこで第3のタイプの並列性を導入する必要があります。それがデータ並列性です。これは実際にはかなりシンプルで、ほぼ水平スケーリングに近いものです。GPUやNPUの2D行列を取り、モデルを複製します。10個、100個のモデルを一緒にトレーニングしているかのように、個々のデータシャードを渡します。そして一定期間後に、それらすべてを調整することを決定します。すべての値を収集し、平均化し、これらの異なるレプリカに送り返します。
基本的には、すべてのモデルレプリカが同じパラメータで開始し、異なるデータバッチで並列してトレーニングします。定期的に（通常はいくつかのバッチの後）、すべてのレプリカからパラメータの変更を集約し、平均化して、新しい共通の開始点を作成します。
このプロセスは、全体的な同期化コストがある種の上限に達するまで、基本的に無限に続けることができます。これにより、同じハードウェアリソースでより多くのデータを処理できるようになり、トレーニング時間を大幅に短縮できます。
この戦略は特にバッチサイズを効果的に増やす方法として重要です。大きなバッチサイズは多くの場合、学習収束を改善し、トレーニングの安定性を高めることができます。しかし、単一のデバイスで大きなバッチを処理することはメモリ制約により困難です。データ並列性を使用すると、バッチを複数のデバイスに分散させ、効果的に大きなバッチでトレーニングできます。
ただし、データ並列性にも課題があります。主なものは通信オーバーヘッドです。モデルが大きくなるほど、レプリカ間で勾配を同期する際の通信コストも大きくなります。これに対処するために、様々な最適化技術が開発されています。例えば、勾配の圧縮、通信の重複処理、あるいは同期の頻度を減らすなどの方法があります。
テンソル並列性、パイプライン並列性、データ並列性のこれら3つの戦略を組み合わせることで、私たちは基盤モデルの開発において直面する並列化課題に対処しています。
7.4. 分散トレーニングの複雑さ
では、分散トレーニングがなぜこれほど難しいのでしょうか？これらの問題の多くを解決したように見えますが、実際はそうではありません。簡単な並列性の問題を考えてみましょう。
おそらく皆さんは、過去20年ほどの間に、Googleが導入したMapReduceのようなもの、現在ではApache Sparkで形式化されているものに気づいているでしょう。人々はこの種の「恥ずかしいほど簡単な並列性」を常に行っています。これには3つの主要な特徴があります。
1つ目は、通常はステートレスであることです。プロセッサやワーカーがデータの一部を処理する際、新しいデータを計算するために過去に何をしたかを覚えておく必要はありません。
2つ目は、主に独立していることです。相互にネットワーク越しに会話する必要はなく、自分の作業を行い、パイプラインの先に渡して、作業を続けることができます。
3つ目は、一方向であることです。入力が一方から入り、出力が反対側から出てきます。
では、分散トレーニングはどうでしょうか？良くありません。全く良くありません。まず、非常にステートフルです。このグラフの各ノードは重要な情報、つまり私たちが成果物の一部として必死に捉えようとしているモデルの重みを保持しています。
そして、非常に独立していません。テンソル並列性とデータ並列性で学んだように、トレーニングの進行を実際に進めるためには、定期的に同期する必要があります。
また、トレーニング自体に詳しい方はご存知のように、通常、モデルに対して推論を行い、損失を計算する順伝播があり、その後、新しい損失を反映するためにすべての値を更新する際に、全体を通じて逆伝播を行います。
つまり、難しいのです。そして、これらの欠点のコストを最小化するために多くの戦略を使用する必要があります。
結局のところ、私たちに多くの課題をもたらすのはエントロピーです。私のレイマンの定義を使用すると、これはシステムにより多くのコンポーネントを追加すると、そのシステムに障害点が増加する現象です。そしてシステム全体が正しく動作することに依存している場合、システム全体が故障する統計的確率は上昇します。
私たちが行っているのは、数万、5万、6万、7万、8万台のアクセラレーターを取り、それらをCPU自体を持つ数万台のホストと一緒に配置することです。それらにはNIC、メモリもあります。そして、それらを3〜4ヶ月間、可能な限り最大限に実行します。休憩も休暇もありません。
本質的に、故障は現実です。実際、この規模では故障は日に10〜20回発生するという現実です。これはAmazon内部だけでなく、外部の文献でも同様のことが報告されています。
そのため、障害率を減らす方法を学ぶのではなく、障害率に対処する方法を学ぶ必要があります。
8. システム障害と対応戦略
8.1. ハードウェア障害の種類（完全な障害、宇宙線によるメモリエラー、静かなデータ破損）
これらの障害にどのように対処するかを説明する前に、私が夜も眠れなくなるような問題について説明します。実際に私たちが目にする問題です。
これらの障害が発生する最良のシナリオは、次のようなものです。幸運なことに、基本的にはGPUやNPUが「プーッ」となり、消えてしまうのです。もはやそこにはなく、ドライバーがクラッシュし、もはや存在せず、何も処理できなくなります。そしてシステムに対して、もはやデータを計算できないことを伝えます。
通常、「PCIバスから切断されている」や、NVIDIAからの「XIDエラー」のような暗号めいたメッセージを受け取ります。しかし、これは素晴らしいことです。なぜなら、「私はもう終わりだ。他の誰かにこの作業をさせてくれ」と基本的に言っているカーネルログメッセージを受け取ることができるからです。
次に、それほど良くはないが最悪でもないケースは、外部要因に対処する必要がある場合です。この場合は宇宙線です。私たちは、これらの自由な粒子が実際にRAMに衝突してビットを反転させるという課題を多く抱えています。現代のハードウェアはこれに対処するための多くの方法を見つけています。
おそらく皆さんはECCメモリのようなものを聞いたことがあるでしょう。これらは誤ったメモリ行を再マップすることを可能にします。しかし基本的に、これらに対処し、これらのホストを再起動する必要があります。そして、修理が必要な状態にある2万台のホストがあると、これらの宇宙線の影響が本当に侵食し始めます。
最後のクラス、私を本当に夜も眠れなくさせるもの、これはハードウェアが何も教えてくれない場合です。実際には仕様通りに動作していないのです。業界ではこれを「サイレントデータ破損（SDC）」または「静かなデータ破損」と呼んでいます。しかし、これは文字通り、数学が間違った計算をしている状態です。GPUのどこかのプロセッサでの乗算が微妙に間違っており、下流で微妙なモデル破損が見られます。損失曲線、勾配ノルム、これらのものがすべて乱れ始めます。
そして、これが実際に起こっていることを確認するまでに何時間もかかることがあります。そして私が呼ばれるのは基本的に、モデルトレーニングを停止して、これらのホストのどれかが微妙に間違ったことをしているのかを見つける必要がある場合です。これは2〜3〜4万台のアクセラレーターを見ている場合、干し草の山から針を見つけるようなものです。
このスライドの重要なポイントは、基本的にシステム的なエラーメッセージを持つエラーと、症状だけが分かる二次的な種類のエラーの両方に対処する方法を学ぶ必要があるということです。後者は実際には容易に診断できません。
これらの様々な障害は、大規模な分散トレーニング環境では避けられないものです。一部は明示的に検出可能で、明確なエラーメッセージが表示されます。その他は微妙で、システムの動作やトレーニングの進行に関する間接的な指標を通じてのみ検出できます。これらすべての障害タイプに効果的に対処する方法を学ぶことが、大規模なトレーニングの成功には不可欠です。
8.2. 日々10〜20回発生する障害への対応
この種のエントロピーや障害にどのように対処するかという点では、実際にカオスを受け入れ、それに対して設計する必要があると早くから学びました。私たちはいくつかのことを行っています。
まず、早期計画が重要です。私たちが行うことの一つは「バーンイン」と呼ばれるプロセスです。バーンインという用語は製造業界から借りたもので、少し不正確ですが、同じような考え方です。これらのハードウェアに対して、非常に特定の決定論的なワークロードを使用して負荷テストを実行し、すでに機能していない状態でこれらをクラスターに入れないように、初期段階でこれらのハードウェアの製造上の欠陥を見つけ出そうとします。
そして、それを行った後、これらに対して受動的適応型モニタリングを開始します。これを2つの方法で行います。前に話したようなカーネルログやドライバーログなどのもの、これらのアクセラレーターから出てくる他のメトリクスを探します。しかし、二次的な信号も探します。例えば、この特定のアクセラレーターが、今はなぜか他のアクセラレーターと非常に遅く通信しているのはなぜでしょうか？以前にこれをベースライン化したことがあり、これは10倍速くあるべきだとわかっています。これで、このアクセラレーターが故障しそうであるか、何らかの問題を抱えていることがわかります。
また、私が前に話していたように、常に保存することの重要性についても学びました。効率的かつ非同期的に保存する方法を見つけるための作業を実際に行います。そして、Amazonには少量の冗長容量を持つという贅沢があります。私たちができたことは、実際にホットスペアをブレークポイントで待機させ、トレーニングを開始する準備ができた状態で待機させることです。これにより、エラーのケースが発生したとき、即座に新しいホストをタグインする準備が整います。
また、私たちはあらゆるものを測定します。膨大な量のメトリクスを収集しており、モデルからホストまで、スタックのすべての層から収集しています。しかし、ここでのポイントは、このデータをすべて持っていても、このデータを意味のある形で視覚化する必要があるということです。すべてのデータを持っているが、それが非常に大量であるため、使用しているモデルやクラスターやデータセンターの形に合わせた意味のあるダッシュボードに変換しない限り、AWSの誰でもMLトポロジーAPIを使用してこれを行うことができますが、これを意味のある形で視覚化し、クラスターのこの領域に問題があるかどうかを非常に素早く特定し、それらの問題を分離することができます。
三つ目は、KPIを知ることです。これらのメトリクスをすべてGoodPutのような高レベルのKPIに戻します。GoodPutは、これらのモデルを稼働させて実行している時間のうち、実際に価値のあることを行っている時間の量を測定するものです。実際にこれらのモデルの全体的な出力に貢献している時間です。チェックポイントの保存、インフラストラクチャの再起動、モデルのメモリへの再ロード、データの再ストリーミングなど、これらはすべてこれにカウントされません。私たちは常に95%、96%、97%、98%のGoodPutを目指して努力しています。
最後に、私たちは迅速に失敗し、同様に迅速に回復する必要があります。待機さえしません。何らかのトラブルを見つけたら、即座にクラッシュします。しかし、回復を優先します。絶対に必要なものだけを停止します。トレーニングプロセスで4〜5万台のアクセラレーターを持っている場合、それぞれに関連する個々のプロセスがあります。それらすべてを停止し、それらのプロセスを実行しているすべてのコンテナを停止すると、それらをすべて再スキャンするのに数分、おそらく10分ほどかかるでしょう。
しかし、私たちはそうしません。個々のプロセス自体だけを再起動します。また、モデルデータインデックスのキャッシュなども行うため、クラッシュから起動までを数秒で行えます。また、前述したように、この規模でのチェックポイント頻度を最適化することが重要です。例えば1時間または2時間ごとにしかチェックポイントを取らないと、その10〜20の間隔で毎回クラッシュした場合、2時間戻る必要があります。回復に時間がかかりすぎると、実際に時間を失うことになります。
8.3. カオスに対する設計アプローチ
これらのエントロピーや障害にどのように対処するかについては、私たちは早い段階でカオスを受け入れ、それに対して設計する必要があると学びました。この方法を説明するために、シンプルな比喩を使いましょう。
車で旅行をするようなものだと考えてください。H100をたくさん持って、車の後ろに積み込み、州間高速道路を運転するとします。そこではいくつかの問題に遭遇するかもしれません。ガソリンを補給する必要があるかもしれません。ガソリンが切れるかもしれません。パンクしたタイヤを交換する必要があるかもしれません。あるいは、車をディーラーに押し込んで、油圧システムやエンジン部品などのコンポーネントを交換する必要があるかもしれません。
しかし私たちにとって、これはむしろ5万台のアクセラレーターを取って、ジャンボジェットに詰め込み、大西洋を飛行するようなものです。そこで必要なのは、画像に示されているような人たちのように、タイヤを交換したり、給油したりできることです。そして、それを飛行機を着陸させることなく行う必要があります。どこかの土地に着陸させることはしません。この飛行機を空中に維持しなければなりません。
このような状況下では、カオスを前提とした設計が必要です。まず、早期計画が重要です。私たちが行うことの一つは「バーンイン」と呼ばれるプロセスです。これは製造業界から借りた用語で、少し不正確ですが考え方は同じです。非常に特定の決定論的なワークロードを使用して負荷テストを実行し、すでに機能していない状態でハードウェアをクラスターに入れないように、初期段階で製造上の欠陥を見つけ出します。
次に、これらのシステムに対して受動的適応型モニタリングを実施します。カーネルログやドライバーログなどの直接的な信号と、アクセラレーター間の通信速度低下などの二次的な信号の両方を監視します。例えば、特定のアクセラレーターが他と比べて異常に遅く通信している場合、それは間もなく故障するか問題を抱えている可能性があります。
また、効率的かつ非同期的にチェックポイントを保存する方法を開発しました。Amazonでは少量の冗長容量を持つという利点もあり、「ホットスペア」を待機させておくことができます。これらはブレークポイントで待機し、トレーニングを開始する準備ができた状態にあります。エラーが発生した場合、すぐに新しいホストをタグインする準備が整っています。
このアプローチの重要な側面は、失敗を前提とし、迅速に回復することを優先することです。何らかのトラブルを検出したら、待たずに即座にクラッシュし、必要最小限の部分だけを再起動します。例えば、個々のプロセスだけを再起動し、すべてのコンテナを停止することは避けます。また、モデルデータインデックスのキャッシュなども行い、クラッシュから起動までの時間を数秒に短縮します。
これらの戦略を組み合わせることで、障害を避けることはできなくても、その影響を最小限に抑え、効率的に回復することができます。
8.4. 早期計画と予防措置
私たちは「すべてを測定する」というアプローチを取っています。モデルからホストまで、スタックのすべての層から膨大な量のメトリクスを収集しています。しかし、重要なのはデータをすべて入手した後、それを意味のある形で可視化することです。
データ量が非常に多いため、使用しているモデル、クラスター、データセンターの形状に合わせた意味のあるダッシュボードに変換する必要があります。現在はAWSのMLトポロジーAPIを使用して、これを意味のある形で視覚化できます。これにより、クラスターのどの領域に問題があるのかを素早く判断し、それらの問題を迅速に分離することができます。
また、これらすべてのメトリクスをGoodPutのような高レベルのKPIに戻すことも重要です。GoodPutは、モデルを稼働させている時間のうち、実際に価値のあることを行っている時間の割合を測定するものです。つまり、モデルの全体的な出力に実際に貢献している時間の割合です。
チェックポイントの保存、インフラストラクチャの再起動、モデルのメモリへの再ロード、データの再ストリーミングなどはすべて、GoodPutにはカウントされません。私たちは常に95%、96%、97%、98%のGoodPutを目指して努力しています。
最後に、私たちは「迅速に失敗し、迅速に回復する」という原則を採用しています。何らかのトラブルを見つけたら、待たずに即座にクラッシュさせますが、回復を優先し、絶対に必要なものだけを停止します。
例えば、トレーニングプロセスで4〜5万台のアクセラレーターがある場合、それぞれに関連する個々のプロセスがあります。それらすべてとそれらを実行しているコンテナをすべて停止すると、再スキャンするのに数分、場合によっては10分ほどかかります。そこで、個々のプロセス自体だけを再起動します。
また、モデルデータインデックスのキャッシュなどを行うことで、クラッシュから起動までを数秒で行えるようにしています。この規模でのチェックポイント頻度の最適化も重要です。1〜2時間ごとにしかチェックポイントを取らないと、10〜20回の障害間隔で毎回クラッシュした場合、2時間分の作業をやり直す必要があります。回復に長い時間がかかると、実際に時間を失うことになります。
これらの早期計画と予防措置の組み合わせにより、障害が発生した場合でも、トレーニングプロセス全体の中断を最小限に抑え、効率的に回復することができます。
9. SageMaker HyperPodの機能と利点
9.1. 自動障害ノード置換
Gordonが話していた課題とAGIチームがそれらにどう対処してきたかをお聞きしました。朗報は、私たちがこれらの学びをすべてSageMaker HyperPodに製品化し、皆さんが利用できるようにしたことです。つまり、これらの課題や問題に自分だけで対処する必要はありません。SageMaker HyperPodを使用して、エントロピー、メモリの壁、計算の壁に対処することができます。
SageMaker HyperPodは耐障害性のある環境です。深い健全性チェックが組み込まれた自己修復クラスターを提供します。これにより、トレーニングジョブを開始した後、チェックポイントも設定され、これらのチェックポイントが取られると、その時点でのモデルの状態やトレーニングプロセスの状態が保存されます。
ノード障害が発生すると、HyperPodは自動的にノード障害を検出し、健全なノードに置き換えます。健全なノードを置き換えた後、前回の安全なチェックポイントに戻り、トレーニングプロセスを再開します。これらすべては手動での介入なしで行うことができます。つまり、この種の障害に自分で対処するために時間を費やす必要はありません。
お客様からは、これによってトレーニング時間が大幅に短縮でき、基盤モデルのトレーニングコストも大幅に削減できると聞いています。自動障害ノード置換を上書きして手動で行いたい場合も、そのオプションは利用可能です。
この機能により、24時間365日の運用サポートなしで大規模なトレーニングジョブを実行できるようになります。障害が発生しても、システムは自動的に検出し、代替ノードをプロビジョニングし、最後の既知の良好な状態からトレーニングを再開します。これによって、エンジニアリングチームは障害対応から解放され、より価値の高い活動に集中できるようになります。
また、この自動障害ノード置換は、トレーニングプロセスの信頼性と予測可能性を大幅に向上させます。障害があっても、トレーニングは自動的に継続され、データサイエンスチームは結果が期待通りに得られることを確信できます。
9.2. アクセラレータレベルの可観測性
障害に対処した後は、この高価なインフラストラクチャの使用率を向上させる方法を検討したいと思うでしょう。それがGPUの使用率であれ、クラスター自体の使用率であれ、HyperPodはTrainiumとGPUの両方に対応したアクセラレータレベルの可観測性を提供します。
この可観測性を使用して、トレーニングスクリプトを反復的に改善し、使用率を最大化することができます。同様に、クラスター側では、多くのチームが同じクラスターを使用し、同じクラスターで複数のトレーニングジョブを実行することができ、これらのトレーニングジョブに優先順位を割り当てて分散させることで、より高い使用率を実現できます。
これらのツールは非常に便利です。Gordonが話していたように、AGIチームはこれらのツールの一部に依存していますが、HyperPodは大きな柔軟性も提供しています。
可観測性ツールを使用することで、アクセラレーターの使用状況をリアルタイムで監視し、ボトルネックを特定し、パフォーマンス最適化の機会を見つけることができます。例えば、GPUやTraniumアクセラレーターの使用率が低い場合、それはデータローディングの非効率性、バッチサイズの問題、あるいはモデル設計の最適化の余地がある可能性を示しています。
また、これらの可観測性ツールはトレーニングプロセス中の異常を早期に検出するのにも役立ちます。例えば、特定のアクセラレーターが他と比較して異常な温度や消費電力を示している場合、それは潜在的な障害の予兆かもしれません。このような早期警告により、事前に対策を講じることが可能になります。
さらに、これらのメトリクスは長期的な容量計画にも役立ちます。実際の使用パターンを分析することで、将来のモデルトレーニングに必要なリソースをより正確に見積もることができ、コスト効率の高いインフラストラクチャ計画に貢献します。
9.3. 柔軟なオーケストレーションオプション
オーケストレーションの例を取ると、HyperPodはオーケストレーターとしてAmazon EKSを提供しています。また、オーケストレーターとしてSlumも提供しています。様々なジョブ提出ツール、可観測性機能、トレーニングや調整のためのドラフトインターフェースなども提供しています。
これらに加えて、先ほど説明したように、様々なトレーニングライブラリ、PyTorch、TensorFlow、Nemo、JAXなどのフレームワークも提供しています。データ並列、テンソル並列、パイプライン並列などの分散トレーニング戦略も提供しており、これらのオープンソースの戦略は、HyperPodのために最適化されています。また、複数のMLOpsツールも提供しています。
この柔軟性により、データサイエンスチームやMLエンジニアは、自分たちの好みや要件に最も適したツールとフレームワークを選択できます。例えば、すでにKubernetesに精通しているチームはEKSを使用できますし、HPC（高性能コンピューティング）の背景を持つチームはSlumを選択できます。
さらに、この柔軟性はワークロードの多様性にも対応しています。前述のように、基盤モデル開発の異なるフェーズ（事前トレーニング、微調整、蒸留など）では、異なるツールや戦略が最適である場合があります。HyperPodは、これらの異なるフェーズ間をシームレスに移行する能力を提供し、ワークフロー全体の効率を高めます。
また、既存のMLOpsパイプラインとの統合も容易です。チームは既存のツールチェーンを継続して使用しながら、HyperPodのパワーと耐障害性を活用することができます。これにより、新しいツールへの移行に伴う学習曲線や中断を最小限に抑えることができます。
このような柔軟性とオプションの豊富さは、様々な組織のニーズに応え、基盤モデル開発の障壁を低くするという点で非常に重要です。
9.4. 事前構築されたイメージとドライバー
ソフトウェアとドライバーに関しては、使用できる事前構築されたイメージがあります。多くのデバイスドライバーやツールキットを使用することができます。
HyperPodは、基盤モデル開発に必要な複雑なソフトウェアスタックを事前に構築し、最適化したイメージを提供しています。これにより、環境のセットアップやメンテナンスに費やす時間を大幅に削減できます。事前構築されたイメージには、機械学習フレームワーク（PyTorch、TensorFlow、JAX、Nemoなど）が既にインストールされており、必要なドライバーや依存関係も含まれています。
これらのイメージは、基盤モデル開発の特定のニーズに合わせて最適化されています。例えば、CUDA、NCCL、EFAなどのドライバーは、特定のアクセラレーターハードウェアと通信プロトコルに対して正確なバージョンで構成されており、最高のパフォーマンスを発揮できるように調整されています。
また、Neuronツールキットなど、AWS独自のハードウェアアクセラレーターを最大限に活用するためのツールも含まれています。これらは、標準的な環境では手に入れることが難しい場合がありますが、HyperPodの事前構築イメージでは標準で提供されています。
これらの事前構築イメージは定期的に更新され、セキュリティパッチや新機能が組み込まれます。これにより、最新のツールとベストプラクティスを活用しながら、環境の保守に関する負担を軽減できます。
複数のソフトウェア環境を必要とするチームのために、異なる構成や要件に対応したさまざまなイメージも用意されています。これにより、異なるプロジェクトや実験に対して、最適なソフトウェア環境を簡単に選択できます。
ハードウェア構成に関しては、HyperPodは様々な選択肢を提供しています。Tranium 1またはTranium 2のインスタンス、H100またはH200を搭載したP5インスタンスを使用できます。さらに、EFAを介した複数のストレージオプションとネットワークも提供しています。これらは、ニーズに応じて選択できる様々なオプションです。
10. 最新のHyperPod機能
10.1. HyperPod Task Governance Tools
私たちは、このre:Inventで複数の最新機能をリリースしました。特に興奮している2つの機能について説明します。
1つ目はHyperPod Task Governance Toolsです。これは今朝リリースした機能で、複数のチーム間でコンピュートリソースを分散し、それらのチームが実行しているトレーニングジョブの優先順位を定義することができます。例えば、同じクラスターを推論ワークロードとトレーニングワークロードの両方に使用していて、昼間は推論トラフィックが高い場合、その時間帯により多くのコンピュートリソースを推論ワークロードに割り当てたいと考えるでしょう。
夜間になって推論のトラフィックが減少すると、そのコンピュートリソースをトレーニングジョブに割り当てたいと考えるでしょう。HyperPodはこれを自動的に行い、これらのパラメータを調整する機能を提供します。
全体として、これによりクラスター全体の使用率を向上させ、かなり大幅なコスト削減を実現することができます。この機能を使用すると、クラスターリソースの使用状況をリアルタイムで確認し、どのチームやワークロードが最も多くのリソースを使用しているかを把握できます。また、ワークロードの優先順位を簡単に調整し、ビジネス上の重要なプロジェクトが必要なリソースを確実に獲得できるようにします。
さらに、使用パターンの分析により、リソース利用の効率化のための戦略的な意思決定が可能になります。例えば、特定の時間帯に特定のワークロードタイプに対してより多くのリソースを割り当てることで、全体的なスループットを向上させることができます。
この機能は特に、複数のチームや部門が同じインフラストラクチャを共有している大規模な組織にとって価値があります。各グループのニーズに応じてリソースを動的に割り当てることにより、ハードウェア投資からより大きな価値を引き出すことができます。これは基盤モデル開発のような計算集約的なタスクでは特に重要です。
10.2. HyperPod レシピ（事前ベンチマーク済みの最適化レシピ）
次に紹介したいのはHyperPodレシピです。HyperPodレシピとは、AWS インフラストラクチャに最適化された事前ベンチマーク済みのレシピです。LLAMAやMistralなどのオープンソースモデルを使用する場合、これらのモデルは何らかのアーキテクチャに従っており、基盤モデルをトレーニングまたは微調整しようとする場合、このアーキテクチャを調整する必要があります。
そしてこの過程で、データサイエンティストは複数の週や時には数ヶ月もの間、これらのパラメータを微調整する必要があります。例としては、使用すべきバッチサイズやオプティマイザの設定があります。調整すべき様々なパラメータが存在します。
HyperPodレシピ機能の一部として、オープンソースモデル用に約30の異なるレシピを提供しており、これらをテンプレートとして直接使用することができます。これにより、最初から最高クラスのパフォーマンスを得ることができます。
これらのレシピは、様々なハードウェア構成やモデルサイズに対して幅広くテストされ、最適化されています。各レシピには、バッチサイズ、学習率、オプティマイザ設定、分散トレーニング戦略など、特定のモデルとハードウェア構成に合わせて最適化されたパラメータセットが含まれています。
例えば、P5インスタンスでLlamaモデルを微調整したい場合、対応するレシピを選択するだけで、数週間かけてパラメータを調整する必要なく、効率的なトレーニング構成をすぐに開始できます。これにより、モデル開発の試行錯誤の時間が大幅に短縮され、データサイエンティストはハイパーパラメータの調整よりもモデルの品質や特定の用途への適用に集中できます。
また、これらのレシピは教育リソースとしても役立ちます。経験の浅いチームは、これらの事前最適化されたレシピを調査することで、大規模モデルトレーニングのベストプラクティスを学ぶことができます。そこからカスタマイズを始めることで、効率的にトレーニング構成を改善する方法について貴重な洞察を得ることができます。
これらのレシピは継続的に更新されており、新しいモデルアーキテクチャや最適化技術が登場するたびに、新しいレシピが追加されます。これにより、最新の開発動向に常に対応できるようになります。
11. 事例紹介とリソース
11.1. 主要顧客事例（Luma AI、Perplexity AI、Salesforce、Thomson Reuters）
SageMaker HyperPodを使用して基盤モデルを構築している主要な顧客についてもお話ししたいと思います。Luma AIやPerplexity AIなど多くの有力スタートアップが、HyperPodを使用して基盤モデルの取り組みを拡大しています。
これらの革新的なスタートアップは、限られたリソースと時間の中で競争力を維持するために、効率的なインフラストラクチャソリューションを必要としています。HyperPodは彼らに、大手テクノロジー企業が持つような大規模なインフラストラクチャチームを持たなくても、最先端の基盤モデルを開発する能力を提供しています。
また、SalesforceやThomson Reutersなどの大企業もHyperPodを使って基盤モデルを構築しています。これらの大企業は、数百億から数兆のパラメータを持つ大規模モデルを開発し、それらを自社のビジネスエコシステム全体に統合しています。
例えば、Salesforceは顧客関係管理（CRM）とデータ分析の豊富な専門知識を活かして、営業プロセスの効率化やカスタマーエクスペリエンスの強化に特化した基盤モデルを開発しています。同様に、Thomson Reutersは法律、税務、会計などの専門分野におけるリッチなコンテンツと専門知識を活用して、これらの業界向けの特殊化されたモデルを構築しています。
これらの企業は、HyperPodの自動障害ノード置換機能や最適化されたトレーニング環境を活用して、開発時間を短縮し、モデルの品質を向上させています。また、HyperPodレシピなどの機能を使用して、モデル開発の初期段階から最高のパフォーマンスを引き出しています。
これらの成功事例は、スタートアップから大企業まで、あらゆる規模の組織がHyperPodを活用して基盤モデル開発を加速できることを示しています。
11.2. トレーニングリソースとワークショップ
このセッションを終える前に、いくつかのリソースをご紹介したいと思います。試してみることができる様々なリソースがあります。このスライドの写真を撮っておくとよいでしょう。様々な機能の発表が複数あり、セルフサービス形式で試すことができるワークショップも用意されています。
これらのワークショップでは、様々なツールや選択肢を実験することができ、何を使いたいかを決定するのに役立ちます。特に、HyperPodの主要機能を実際に体験することができるハンズオン形式のワークショップが用意されています。これらのワークショップでは、クラスターのセットアップから分散トレーニングジョブの実行、そして自動障害回復機能のテストまで、HyperPodの機能を直接試すことができます。
また、各種ドキュメント、チュートリアル、サンプルコードを含む包括的な技術リソースもあります。これらのリソースは、最初の環境セットアップから、高度な分散トレーニング戦略の実装まで、様々なレベルの詳細をカバーしています。
さらに、AWS Solution Architectsによるサポートも利用可能です。彼らは特定のユースケースや課題に対して専門的なガイダンスを提供することができます。ベストプラクティスの推奨や、特定のモデルアーキテクチャに最適なインフラストラクチャ構成のアドバイスなど、実践的な支援を受けることができます。
これらのリソースを活用することで、基盤モデル開発の旅をより効率的に進めることができます。実験と学習を通じて、自分のプロジェクトに最適なツールと構成を見つけることができるでしょう。
それでは、本日はお時間をいただきありがとうございました。残りのre:Inventが素晴らしいものになることを願っています。
12. まとめと主要なポイント
12.1. インフラ管理時間の削減
このセッションを終える前に、いくつかの重要なポイントをお伝えしたいと思います。その最初のポイントは、HyperPodがインフラストラクチャ管理に費やす時間を削減するのに役立つということです。
基盤モデル開発においては、実際のモデル開発と科学的研究に集中するよりも、インフラストラクチャの管理に多くの時間を費やすことがあります。HyperPodはこの課題に直接対応しています。事前構築されたイメージ、自動化されたクラスター管理、最適化されたドライバーとライブラリの統合により、インフラストラクチャのセットアップと維持に費やす時間を大幅に削減できます。
特に、HyperPodは複雑なハードウェアドライバー、CUDA、NCCL、EFA、Neuronなどのバージョンの互換性を管理します。適切な構成のこれらコンポーネントを手動で管理することは、非常に時間のかかる作業です。HyperPodはこれらの複雑さを抽象化し、データサイエンスチームが技術的な詳細よりもモデル開発に集中できるようにします。
また、オーケストレーション、モニタリング、ジョブ管理のための統合ツールにより、日常的な運用タスクも簡素化されます。これにより、データサイエンティストやMLエンジニアはインフラストラクチャの問題をデバッグするのではなく、モデルの品質向上に時間を費やすことができます。
AGIチームからの学びを活かし、HyperPodにこれらの機能を組み込むことで、お客様はゼロから始める必要がなく、すでに実証済みのベストプラクティスの恩恵を受けることができます。これにより、基盤モデル開発の障壁が低くなり、より多くの組織がこの技術を活用できるようになります。
12.2. 障害に対する回復力
HyperPodの2つ目の重要なポイントは、障害に対して回復力があるということです。自己修復クラスターを提供し、深い健全性チェックが組み込まれています。
セッション中に詳しく説明したように、大規模な分散トレーニング環境では障害は避けられません。5万台以上のアクセラレーターを使用する環境では、1日に10〜20回の障害が発生することが一般的です。これらの障害に効果的に対処することは、トレーニングの成功に不可欠です。
HyperPodは自動障害ノード置換機能を提供しています。ノード障害が発生すると、システムは自動的に障害を検出し、健全なノードに置き換え、最後の安全なチェックポイントからトレーニングを再開します。これにより、手動での介入なしにトレーニングを継続できます。
この自動修復機能は、単にダウンタイムを減らすだけでなく、トレーニングプロセス全体の信頼性と予測可能性を向上させます。チームは24時間365日の監視を行う必要がなく、トレーニングが完了することを確信できます。
また、HyperPodはアクセラレーターレベルの可観測性も提供しており、潜在的な問題を早期に検出し、それらが実際の障害になる前に対処することができます。アクセラレーターの異常な動作パターンを監視することで、先制的なメンテナンスが可能になり、障害の発生率を減らすことができます。
これらの回復力に関する機能は、基盤モデルトレーニングの成功にとって重要です。数週間または数ヶ月にわたるトレーニングの途中で障害が発生すると、貴重な時間とリソースが失われる可能性があります。HyperPodの自動修復機能により、そのようなリスクが大幅に軽減され、より効率的で信頼性の高いトレーニングプロセスが実現します。
12.3. ツール選択の柔軟性
HyperPodの3つ目の重要なポイントは、異なるツールの選択における柔軟性です。様々なオーケストレーションオプション、トレーニングライブラリ、フレームワーク、分散トレーニング戦略から選択できる幅広い選択肢を提供しています。
オーケストレーションの例を挙げると、HyperPodはAmazon EKSとSlumの両方をオーケストレーターとして提供しています。様々なジョブ提出ツール、可観測性機能、トレーニングや調整のためのドラフトインターフェースも提供しています。
さらに、PyTorch、TensorFlow、Nemo、JAXなどの様々なフレームワークをサポートしています。データ並列、テンソル並列、パイプライン並列などの分散トレーニング戦略も提供しており、これらのオープンソース戦略はHyperPodのために最適化されています。また、複数のMLOpsツールもサポートしています。
これらの選択肢の柔軟性により、データサイエンスチームやMLエンジニアは、既存のスキルセットや特定のプロジェクト要件に最適なツールを選択できます。例えば、PyTorchに精通したチームはそのフレームワークを継続して使用しながら、HyperPodの耐障害性やスケーラビリティの利点を享受できます。
また、ワークロードの進化に応じてツールを変更する柔軟性も提供します。例えば、事前トレーニングフェーズでは一つのフレームワークや並列化戦略を使用し、微調整フェーズでは別のものを使用するといった選択が可能です。
この柔軟性は、技術的な制約ではなくビジネスニーズや科学的目標に基づいて意思決定できるようにすることで、イノベーションを促進します。チームは特定のツールセットに縛られることなく、プロジェクトの特定のニーズに最適なものを選択できます。
12.4. コスト削減効果
HyperPodの4つ目の重要なポイントは、かなり大幅なコスト削減効果があるということです。お客様からは、HyperPodを使用することで基盤モデルのトレーニングコストを大幅に削減できたと聞いています。
コスト削減はいくつかの重要な機能から生まれています。まず、自動障害ノード置換によって、障害が発生してもトレーニングプロセスの継続性が確保されます。これにより、障害によるダウンタイムが大幅に減少し、高価なGPUやTrainiumアクセラレーターの使用効率が向上します。手動での介入なしに障害から回復できることで、24時間365日の運用サポートの必要性も減少し、人的コストも削減できます。
次に、HyperPod Task Governance Toolsのような機能は、複数のチーム間でコンピュートリソースの効率的な分配を可能にします。例えば、日中は推論ワークロードに、夜間はトレーニングワークロードにリソースを割り当てることで、クラスターの全体的な使用率を向上させることができます。これにより、必要なアクセラレーターの総数を減らし、インフラストラクチャコストを削減できます。
また、HyperPodレシピを使用することで、事前にベンチマークされた最適化設定からすぐに始めることができます。これにより、最適なパラメータを見つけるために何週間もの試行錯誤を行う必要がなくなります。この効率化により、実験にかかる時間と計算コストが削減されます。
アクセラレーターレベルの可観測性も、リソース使用率を監視し最適化する能力を提供することで、コスト削減に貢献します。これにより、ボトルネックやリソースの無駄遣いを特定し、パフォーマンスを最大化するために必要な調整を行うことができます。
これらの機能が組み合わさることで、基盤モデル開発の総所有コストが大幅に削減されます。これは、基盤モデルを構築または微調整しようとしている組織、特にリソースに制約のあるスタートアップやスモールチームにとって重要な利点です。