Meta の Windows 向け大規模 AI ストレージブループリント 7,8,10,11

ここ数年にわたって, モデルの機能とトレーニングデータセットのサイズは急激に増加しました. ここ1年くらいの間に, 新しいフロンティアモデルのリリース間隔が数か月から数週間に短縮されました. ストレージへの信頼性が高く高速なアクセスは、この AI イノベーションの速度と計算コストの両方にとって重要です. AIが脳だとしたら, ストレージは記憶です: 機能と速度はメモリのサイズと検索速度に大きく依存します。.

AI の計算パフォーマンスは 2 年ごとに約 3 倍になっていますが、, ストレージとインターコネクトのパフォーマンスの伸びはより緩やかになった. 結果として, ストレージのボトルネックは引き続き AI ワークロードの GPU ストールの主な原因の 1 つです, 支出と市場投入までの時間に直接影響を与える. GPU使用率とは別に, ストレージアーキテクチャは、AI 研究の反復速度にも直接影響します; GPU はますます地理的に分散され、データセットのサイズはますます巨大化しています, 研究者は地域間でのデータの取り込みと移動にかなりの時間を費やしています, したがって研究速度に影響を与える. このブログ投稿では, Meta の BLOB ストレージアーキテクチャが 2 つの主要な課題に対処するためにどのように進化したかについて説明します: GPUの使用率を最大化し、研究速度を最大化する.

ストレージアーキテクチャの概要

Meta は、Meta のすべての社外製品と社内製品にサービスを提供する数百のエクサバイト規模のストレージクラスターを運用しています。, フェイスブックを含む, インスタグラム, リアリティラボ, メタAI, 広告, データウェアハウス, および内部データベース. 当社のストレージサービスはオブジェクトストレージを公開します, ファイルシステム, およびブロックデバイス API, これらの API 抽象化は、Tectonic と呼ばれる水平方向にスケーラブルな基礎ブロック層の上に構築されます。. 構造層は地域的なものです, イレイジャーコーディング技術を活用して高い耐久性と可用性を提供するマルチテナントストレージファブリック, メディアタイプ間の階層化をサポート (例えば, HDDとフラッシュ), ホットのスマートな配置を管理します, 寒い, テナント全体で I/O を効率的に利用するためのウォームデータ. Tectonic 上で動作する BLOB ストレージ層は、グローバルな情報を公開します。, 無限に拡張可能なストレージファブリック, ユーザーが耐久性と可用性の間でトレードオフを行えるポリシーを公開します.

以前の @Scale というタイトルのトーク, 「ラマの訓練」: ストレージの観点,」 Meta が NFS のような FileSystem インターフェイスをその上に公開することで、Tectonic ブロック層上で Llama を直接トレーニングする方法について説明しました。. このアーキテクチャはメタ内で広く使用され続けていますが、, 最新のトレーニングスタックは、BLOB ストレージインターフェイス上にゆっくりと移行しています。, 業界全体に言えることですが. この移行は、BLOB ストレージレイヤーの大規模なデータレイクへの統合ストレージアクセスの必要性と、高性能の必要性によって動機付けられています。.

GPU使用率の最大化

最新の AI ワークロードは「データを大量に消費」しており、従来の Web アプリケーションとはワークロード特性が大きく異なります。: バースト的かつ持続的な高スループット, 予測可能かつ制限された pMax レイテンシ, および可変 I/O パターン. BLOB ストレージに焦点を当てる, 近年では, GPU 使用率を最大化することに大きく移行しました.

レイテンシが重要な理由

制限された低 pMax レイテンシが重要である理由を確認するには, モデルのトレーニングを考えてみましょう. その訓練中に, 数十万の GPU がストレージ内の膨大な量のデータを複数回反復処理する (つまり, 複数のエポックにわたって), GPU はデータセットをバッチでトレーニングします. 定期的に, 特定のステップ数またはバッチ数ごとに, GPU は、GPU 間で状態を同期します。. 1 つの GPU が遅い場合, このステップでは、すべての GPU とトレーニング全体の速度が低下します。.

形 1 2 つの GPU にわたるデータ読み込みパイプラインを示しています. すべての GPU ホストのデータローダーが次のデータセットバッチをプリフェッチします, GPU がコンピューティングまたは I/O オーバーラップを最大化するために現在のバッチを処理している間. GPU1の場合, ストレージフェッチのレイテンシは十分に範囲内です, そのため、GPU が I/O を待って停止することはありません. GPU2の場合, ストレージのフェッチで長いレイテンシーが発生する例が 2 つあります, GPU の停止. こうした出店の結果、, 全体的なステップ完了時間が遅れる.

従来の BLOB ストレージアーキテクチャは AI 対応ではなかった

長年にわたって, BLOB ストレージは有機的に進化しました, 真のサービス指向の方法でレイヤーの上にレイヤーを追加する. これらのレイヤーの多くはステートフルであり、独自のメタデータストアを維持していました. これらのメタデータアクセスの遅延は通常、グローバル HDD によって提供される従来のユースケースのボトルネックではありませんでした。, これらは、フラッシュ内のデータへのミリ秒アクセスを備えた AI ワークロードにとって画期的なものでした. 形 2 に、一般的なリクエストフローを示します。 getオブジェクト(「/バケット/パス」) API. リクエストがAPIサーバーに到着した後, サーバーはネームレイヤー全体で多くのメタデータ検索を実行します, ボリュームレイヤー, およびcontainerlayerのセットへのパスを解決する前に、 (ブロックID, オフセット, サイズ) タプル. これらの検索の一部はリージョンをまたぐ場合があります, 遅延が数百ミリ秒に達することも珍しくありません; いずれかの検索からの遅い応答が 1 回あれば十分でした. 検索の後, API サーバーは構造層からのデータをクライアントにプロキシします。.

このアーキテクチャは従来のワークロードにうまく対応しましたが、, 設計のトレードオフを決定する基本的な前提はその後変化しました. これらのいくつかは、:

パフォーマンスと遅延: 議論したように, 従来のワークロードのレイテンシーのニーズはそれほど高くありませんでしたが、, AI ワークロードは、pMax に至るまで、予測可能で制限されたレイテンシを要求します.
信頼性と耐久性: 従来のアーキテクチャは、耐久性と可用性が高くなるように設計されています, リージョンの停止に直面しても; データとメタデータはデフォルトでグローバルにレプリケートされました. AI ワークロードには非常に高い可用性が求められますが、, グローバルのデフォルト設計の選択はもはや有効ではありません.
コスト効率: レガシースタックは HDD 上に構築され、バイトあたりのコストが高度に最適化されています. AI ワークロードの IOPS 要求にはフラッシュが必要です, そしてさらに, ストレージの計算コストは、GPU の計算コストに比べて無視できるほどになります。.
電力効率: GPUを使用する場合, データセンターはスペースの制約よりもむしろ電力の制約がますます高まっています. ストレージに費やされる電力のすべてのキロワットは、GPU に費やされない電力です. これは AI ワークロードの新たな制約です.

要するに, トレードオフの領域は、アーキテクチャ全体を再考するのに十分なほど変化しました.

基盤の再構築

新たな基盤の構築に着手するにあたり、, 次のような主要な設計上の選択を行いました:

統合されたメタデータスキーマ: メタデータサブシステムを書き直し、さまざまなレイヤーにまたがるメタデータを、ZippyDB を基盤とする 1 つの統一されたフラットなスキーマに集約しました。. これにより、O への道が開かれます(1) ストレージアドレスへのパスを解決するための検索, これはステップ関数の改善です.
データプレーンプロキシなし: データプレーンプロキシを排除し、ストレージサーバーからクライアントに直接バイトをストリーミングできるファットクライアント SDK を構築しました。. これは電力効率の目標を達成するのに役立ち、より高いスループットとより低いレイテンシーの達成にも役立ちます。.
地域展開: BLOB ストレージスタックは無駄がなく、地域サービスまたはグローバルサービスとして展開できる柔軟性を備えています。. 現在、すべての AI リージョンに GPU と同じ場所に配置されたリージョン BLOB ストレージスタックをデプロイしています。.

形 3 の新しいリクエストフローを示します getオブジェクト(「/バケット/パス」). クライアント上の SDK がこの API 呼び出しを受信したとき, 今では getReadPlan(「/バケット/パス」) APIサーバーへのリクエスト. API サーバーは O を実行します(1) チャンクごとに新しいメタデータストアを検索してパスをマッピングします (ブロックID, オフセット, サイズ) タプル. 次に、ReadPlanResult を SDK に返します。. SDK には Tectonic BlockClient が組み込まれています, そのため、Tectonic からこれらのブロックから直接データをストリーミングできるようになりました。. こうした変化に伴い、, 私たちは基盤を再構築し、Tectonic の上にオーバーヘッドを追加しないという目標を達成しました。. データプロキシを排除することで, 消費電力も予算内に収まります.

スパイクとホットスポットへの対処

データとチェックポイントのロード中, AI ワークロードは、数百の GPU にわたって同時にデータにアクセスすることが知られています. モデルの重みなどのデータのサブセットは多くの場合「ホット」です,」と GPU の再起動などのイベントがトラフィックの急激な急増を引き起こす. これで基礎が固まったので, 次の問題は、スパイクやホットスポットに対処することでした。. 幸いなことに, BLOB ストレージ層には、長年にわたってホットスポットに対処してきた経験があります。, そこで、ここでは既存のソリューションを AI ワークロードに適応させました。. 具体的には, 私たちは2つのアプローチを採用しました:

分散データキャッシュ: GPU ホスト上の予備メモリを、頻繁に同時にアクセスされるデータの分散データキャッシュとして活用しました。. これを達成するには, のコンポーネントを再利用しました Meta の Owl サブシステム: すべてのデータアクセスがこのデータキャッシュを経由するように、Owl サブシステムのピアを BLOB ストレージクライアント SDK に直接統合しました。.
Readplan メタデータキャッシュ: Readplan は、パスからストレージアドレスへのマッピングを指します。. 頻繁にアクセスされる BLOB の読み取りプランを、memcache と同様の分散メモリストアにキャッシュするようになりました。.

実際には、平均キャッシュヒット率が観察されます。 80% 分散データキャッシュ上で, 読み取りプランキャッシュが提供するのは、 1-2 メタデータへのミリ秒アクセス. 本質的には, これらの単純なメカニズムは 3 つのことを行います:

スパイクを吸収し、ストレージからの I/O 要件を軽減します。.
メタデータのホットシャードの問題を解決する.
メモリからサービスを提供することで、p50 および p99 のレイテンシーを改善します.

プロトコルの最適化

これまで話し合った結果が得られました 80% 途中の. 残りを達成しました 20% スタック全体のボトルネックを特定して修正することにより、. 以下にいくつかの注目すべき問題があります, 決して完全なリストではありませんが、:

遅れている人: 1 つの遅いストレージノードがテールレイテンシーの原因となる. これはよく理解された問題です, これを軽減するために、クライアント側で読み取りをヘッジすることにしました。.
下りスパイク: チェックポイントイベント中, クライアントが鋭い出力スパイクを作成するのは一般的です. それによって渋滞が発生する可能性もある, タイムアウト, そして再試行します, 最終的には GPU が停止する. この問題は、クライアント SDK に動的な同時実行制御を構築し、アプリケーションレベルの輻輳信号に基づいて並列処理を自動的に調整することで解決しました。.

上記のすべてを備えた, 新しい BLOB ストレージスタックは、GPU ストールを引き起こすことなく AI ワークロードを処理できるようになりました。, 構造層の上に無視できるオーバーヘッドを追加する. 私たちの次の焦点は研究に移りました.

研究速度の最大化

GPU は不足しており、ますます地理的に分散されています; 同時に, トレーニングワークロードでは、パフォーマンス上の理由からデータを GPU と同じ場所に配置する必要があります. これは研究者にとって興味深い課題となります: 彼らは現在、リージョン間でのデータセットの取り込みと移動に追われています。.

メタで, 典型的なトレーニングジョブの送信には次のものが含まれます。:

研究者がさまざまなソースからデータを収集する, それらを強化し、BLOB ストレージに永続化します。.
研究者はジョブを実行するリージョンを選択します.
研究者がデータ取り込みジョブを送信する, GPU ホスト内からのデータ読み込み用に最適化されたファイル形式で、トレーニングデータセットのスナップショットをターゲットリージョンに作成します。.
その後、研究者は摂取が完了するのを待ちます; データセットのサイズに応じて, 何時間もかかることがある.
研究者はトレーニングジョブを送信し、その実行を監視します.
研究者は出力を分析します, データセットを調整する, そしてまた繰り返します, ステップから始まる 3.

ステップ 2 を通して 4 数時間かかる可能性があり、研究者の反復速度に直接影響を与える可能性があります. 理想的には, 私たちは研究者がモデルの調整に時間を費やすことを望んでいます, 保管を待たない. 現在, 研究者は、データを GPU と同じ場所に配置する作業を開始する前にスナップショットをコピーします。, 結果として最適なパフォーマンスが得られます. このパフォーマンスの最適化は、数週間または数か月にわたる大規模なトレーニングジョブには意味がありますが、, 大多数の仕事ははるかに小規模です; これらのジョブを担当する研究者は、反復速度と引き換えに時折生じるパフォーマンスの低下を喜んで犠牲にします。.

など, 研究者が一度データを取り込めば、地域の境界を気にせずにどこからでもデータにアクセスできるシステムが必要でした。. 研究者が数時間ではなく数分で反復できるワークフローが必要でした. 振り出しに戻ったとき, ライトワンス, これらのデータセットの読み取り多の特性がベルを鳴らしました. ストレージを地球規模のコンピューターのディスクとして考え、オペレーティングシステムの世界からアイデアを借用したらどうなるでしょうか。? CPU コア上で実行されている Linux プロセスがディスクからファイルを読み取ろうとするとき, オペレーティングシステムは、メモリ内のページキャッシュ、L2 および L1 CPU キャッシュなど、キャッシュのさまざまな層にわたってオンデマンドでデータを透過的にハイドレートします。. この直感が、図のアーキテクチャの進化につながりました。 4:

中心となるアイデアは、さまざまなオンホストおよびオフホストのストレージリソースを、究極の真実のソースとして HDD に裏打ちされたグローバル BLOB ストレージファブリックを備えた階層型キャッシュとして活用することです。. 具体的には, GPU ホスト上のメモリとフラッシュを L1 キャッシュと L2 キャッシュとして利用します。. また、L3 キャッシュデータローダーが使い慣れた BLOB ストレージ SDK を介してストレージにアクセスし続けるため、フラッシュに支えられたリージョン BLOB ストレージファブリックを活用します。. レイテンシーを効果的に隠し、データのライフサイクルを簡素化するため, 私たちは以下に依存します:

データローダーのプリフェッチ: データローダーは、現在のバッチを処理しながら、データセットの次のバッチをメモリにプリフェッチします。. このプリフェッチは次のように表示されます。読む BLOB ストレージ SDK レベルでの操作.
ディーププリフェッチ: 明示的なプリフェッチを公開します() BLOB ストレージ SDK の一部としての API. データローダーは、プリフェッチを呼び出して、次の数分間に必要なデータの明示的なプリフェッチをトリガーします。() バックグラウンドでの API. この API は、リモートストレージからローカルリージョンの L3 キャッシュへのデータのハイドレーションをトリガーし、メタデータキャッシュを事前にウォームアップします。.
自動データライフサイクル: L3 リージョンの細分化されたフラッシュ層のデータは、通常、トレーニングサイクルのエポック間で再利用できるように、設定された期間保持されます。. カスタムの立ち退きポリシーをサポートします, TTL および LRU ポリシーを含む. 立ち退きポリシーもキャパシティ/クォータを意識します.

運用展開が開始されるとすぐに、この新しいデータ読み込みパラダイムが急速に採用されることがわかりました。, 現在も実稼働環境で両方のデータ読み込みパラダイムをサポートし続けています。. 影響を数字で説明するには, 形 5 すべてのワークロードにおけるロールアウト前後のおおよその取り込み時間を示します。:

新しいフロンティアモデルが数週間以内にリリースされる世界では, データ読み込みパラダイムのこの変化は、さらに高速に進むために切望されている変化です.

重要なポイント

最新の AI ワークロードはデータを大量に消費します, ストレージは計算コストとイノベーションの速度の両方において重要な役割を果たします. ストレージのボトルネックは GPU の使用率と計算コストに直接影響します, そして地理的に分散された GPU を備えた世界では, リージョンを越えたデータの取り込みに費やされる時間は、研究の反復速度に直接影響します。. Meta の BLOB ストレージアーキテクチャは、Meta のアプリファミリにサービスを提供するために構築されました, AI ワークロードに対応するには、パフォーマンスのステップ関数の改善が必要でした. これにより、アーキテクチャ全体を再考することになりました. メタデータサブシステムを再構築し、プリフェッチ/オンデマンドハイドレーションを備えた階層型キャッシュアーキテクチャを採用することによって, 今日のワークロードのニーズに効果的に対応できます.

今後の取り組み

ハードウェアの進化とワークロードの需要に対応するために、Meta ではストレージを継続的に進化させています。. この分野における今後の取り組みには、以下が含まれる予定です。:

ネットワークの制限に合わせてストレージを拡張する.
さらに大規模な GPU を停止させることなくチェックポイントをサポート.
推論ワークロードに対する新たな課題, 私たちが取り組み始めていること.