このドキュメントでは、AI / ML ワークロード用のGoogle Cloud ストレージ サービスを選択して統合する方法についての設計ガイダンスを提供します。ML ライフサイクルの各ステージには、異なるストレージ要件があります。たとえば、トレーニング データセットをアップロードするときに、トレーニングのストレージ容量を優先し、大規模なデータセットの高スループットを優先する場合があります。同様に、トレーニング、チューニング、サービング、アーカイブの各ステージには異なる要件があります。ほとんどの AI / ML ワークロードでは、ストレージ ソリューションとして Google Cloud Managed Lustre を使用することをおすすめします。Managed Lustre は、高いパフォーマンスとスケーラビリティを提供するため、トレーニング、チェックポイント処理、サービングに最適です。サービングとアーカイブの各ステージには、それぞれ異なる要件があります。
このドキュメントは、容量、レイテンシ、スループットの要件を評価し、適切なストレージ ソリューションを決定するための情報に基づいた選択を行うのに役立ちます。このドキュメントでは、ワークロードの要件を満たすコンピューティング プラットフォームを選択していることを前提としています。AI ワークロードと ML ワークロードには、Compute Engine または Google Kubernetes Engine（GKE）を使用することをおすすめします。コンピューティング プラットフォームの選択の詳細については、 Google Cloudでのアプリケーションのホスティングをご覧ください。
次のタブに、ML ワークフローの各ステージで推奨されるストレージの概要を示します。詳細については、適切なストレージを選択するをご覧ください。
準備
ML ワークフローの準備段階では、次のことを行います。
- データをアップロードして取り込みます。
- モデルをトレーニングする前に、データを正しい形式に変換します。
複数のストレージ クラスを使用してストレージ費用を最適化するには、Cloud Storage の Autoclass 機能またはオブジェクトのライフサイクル管理を使用することをおすすめします。
トレーニング
ML ワークフローのトレーニング ステージでは、次のことを行います。
- モデル開発: ノートブックを使用して試行錯誤を繰り返し、モデルを開発します。
- モデルのトレーニング:
- 小規模から大規模な数のマシン アクセラレータを使用して、トレーニング データセットを繰り返し読み取ります。
- モデルの開発とトレーニングに反復プロセスを適用します。
- チェックポイントの作成と再起動:
- チェックポイントを作成して、モデルのトレーニング中に状態を定期的に保存し、ノードの障害後にトレーニングを再開できるようにします。
- チェックポイントの選択は、I/O パターンと、チェックポイントに保存するデータの量に基づいて行います。
トレーニング ステージには、次のストレージ オプションをおすすめします。
- ワークロードに次の特性がある場合は、Managed Lustre を使用します。
- 最小トレーニング容量要件は 18 TiB です。
- 低レイテンシ機能を活用するために、50 MB 未満の小さなファイルで構成されるトレーニング データ。
- ランダム I/O とメタデータ アクセスのストレージ要件を満たすため、1 ミリ秒未満のレイテンシ要件。
- 頻繁に高パフォーマンスのチェックポイントを作成する必要がある。
- データを表示して管理するために、POSIX を完全にサポートするデスクトップのようなエクスペリエンスが必要。
- ワークロードに次の特性がある場合は、Cloud Storage FUSE と Anywhere Cache で Cloud Storage を使用します。
- 50 MB 以上の大きなファイルで構成されるトレーニング データ。
- 数十ミリ秒という高いストレージ レイテンシを許容できる。
- ストレージ パフォーマンスよりもデータの耐久性と高可用性を優先する。
費用を最適化するには、モデル トレーニングのすべてのステージで同じストレージ サービスを使用することをおすすめします。
サービング
ML ワークフローのサービング ステージでは、次のことを行います。
- モデルを保存します。
- 起動時にマシン アクセラレータを実行するインスタンスにモデルを読み込みます。
- モデル推論の結果（生成された画像など）を保存します。
- 必要に応じて、モデル推論に使用するデータセットを保存して読み込みます。
サービング ステージには、次のストレージ オプションをおすすめします。
- ワークロードに次の特性がある場合は、Managed Lustre を使用します。
- トレーニングとチェックポイントのワークロードでマネージド Lustre を使用している。
- 10 ～ 100 個の推論ノードの要件。
- モデルの頻繁な更新。
- ワークロードに次の特性がある場合は、Cloud Storage FUSE と Anywhere Cache を使用した Cloud Storage:
- 推論ノードの数が変化する動的環境向けの費用対効果の高いソリューションの要件。
- モデルの更新頻度が低い。
- リージョンで中断が発生した場合でも、モデルの高可用性と耐久性を優先します。
- ワークロードに次の特性がある場合は、Google Cloud Hyperdisk ML を使用します。
- 100 個を超える推論ノードが必要。
- モデルの更新頻度が低い。
- ワークロードがサポートされている仮想マシン（VM）タイプを使用している。
- パイプラインは、モデルを保存する読み取り専用ボリュームを管理できます。
アーカイブ
ML ワークロードのアーカイブ ステージでは、トレーニング データとモデルを長期間保持します。
複数のストレージ クラスでストレージ費用を最適化するには、Cloud Storage の Autoclass またはオブジェクトのライフサイクル管理を使用することをおすすめします。
設計プロセスの概要
Google Cloudで AI / ML ワークロードに適したストレージ オプションを決定するには、次の操作を行います。
- ワークロードの特性、パフォーマンスの期待値、費用の目標を考慮します。
- Google Cloudで推奨されるストレージ サービスと機能を確認します。
- 要件と使用可能なオプションに基づいて、ML ワークフローの各ステージ（準備、トレーニング、サービング、アーカイブ）に必要なストレージ サービスと機能を選択します。
このドキュメントでは、ストレージ オプションの慎重な検討が最も重要な ML ワークフローのステージに焦点を当てていますが、ML のライフサイクル、プロセス、機能の全体を網羅しているわけではありません。
以下に、AI / ML ワークロードのストレージを選択するための 3 フェーズの設計プロセスの概要を示します。
- 要件を定義する:
- ワークロードの特性
- セキュリティの制約
- 復元性の要件
- パフォーマンスの想定値
- 費用目標
- ストレージ オプションを確認する:
- Managed Lustre
- Cloud Storage
- Hyperdisk ML
- 適切なストレージを選択する: ML ワークフローの各ステージで、ワークロードの特性に基づいてストレージ サービス、機能、設計オプションを選択します。
要件を定義する
Google Cloudで AI / ML ワークロードのストレージ オプションを選択する前に、ワークロードのストレージ要件を定義する必要があります。ストレージ要件を定義するには、コンピューティング プラットフォーム、容量、スループット、レイテンシの要件などの要素を考慮する必要があります。
AI / ML ワークロードのストレージ オプションを選択する際は、ワークロードの特性を考慮してください。
- I/O リクエスト サイズとファイルサイズは、小（KB）、中、大（MB または GB）のどれですか？
- ワークロードは主にシーケンシャル ファイル アクセス パターンとランダム ファイル アクセス パターンのどちらを示しますか？
- AI / ML ワークロードは、I/O レイテンシと Time To First Byte（TTFB）の影響を受けやすいか
- 単一のクライアント、集約クライアント、またはその両方に高い読み取り / 書き込みスループットが必要か
- 最も大きい単一の AI / ML トレーニング ワークロードに必要な GPU（グラフィック プロセッシング ユニット）または TPU（Tensor Processing Unit）の最大数はいくつか
これらの質問への回答は、このドキュメントの後半で適切なストレージを選択するために使用します。
ストレージ オプションを確認する
Google Cloud は、すべての主要なストレージ形式（ブロック、ファイル、並列ファイル システム、オブジェクト）のストレージ サービスを提供します。次の表に、Google Cloudでの AI / ML ワークロードで検討できるオプションを示します。この表には、このドキュメントで AI / ML ワークロードの対象とする 3 つの Google マネージド ストレージ オプションが含まれています。ただし、これらのサービスで対応できない特定の要件がある場合は、Google Cloud Marketplace で利用可能なパートナー管理のストレージ ソリューションをご検討ください。
各ストレージ形式で使用できるサービスの機能、設計オプション、相対的な利点を確認して評価します。
| ストレージ サービス | ストレージの種類 | 機能 |
|---|---|---|
| Managed Lustre | 並列ファイル システム |
|
| Cloud Storage | オブジェクト |
|
| Hyperdisk ML | ブロック |
|
Managed Lustre
Managed Lustre は、 Google Cloudのフルマネージド ファイル システムです。Managed Lustre は、DDN EXAScaler Lustre ファイル システム上に構築された永続的なゾーン インスタンスを提供します。Managed Lustre は、高スループットと高い入出力オペレーション数（IOPS）で 1 ミリ秒未満の低レイテンシ アクセスを提供する必要がある AI/ML ワークロードに最適です。Managed Lustre は、数台の VM でも数千台の VM でも、高スループットと高 IOPS を維持できます。
マネージド Lustre には次のような利点があります。
- POSIX 準拠: POSIX 標準をサポートし、既存の多くのアプリケーションやツールとの互換性を確保します。
- トレーニングの TCO を削減: コンピューティング ノードにデータを効率的に配信することで、トレーニング時間を短縮します。この高速化により、AI モデルと ML モデルのトレーニングの TCO を削減できます。
- サービングの TCO を削減する: Cloud Storage と比較して、モデルの読み込みを高速化し、推論サービングを最適化します。これらの機能は、コンピューティング費用を削減し、リソース使用率の向上に役立ちます。
- 効率的なリソース使用率: チェックポイントとトレーニングを 1 つのインスタンス内で組み合わせます。このリソース使用率により、単一の高パフォーマンス ストレージ システムで読み取り / 書き込みスループットを効率的に使用できます。
Cloud Storage
Cloud Storage は、あらゆる規模の AI / ML ワークロードに適したフルマネージド オブジェクト ストレージ サービスです。Cloud Storage は、AI / ML ワークフローのすべてのフェーズで非構造化データを処理するのに優れています。
Cloud Storage には次の利点があります。
- 優れたスケーラビリティ: グローバルでエクサバイトまで拡張可能な無制限のストレージ容量を利用できます。
- 高スループット: 必要な計画を立てることで、最大 1 TB/秒までスケールアップできます。
- 柔軟なロケーション オプション: AI / ML ワークロード用のリージョン、マルチリージョン、デュアルリージョン ストレージ オプションから選択します。
- 費用対効果: データアクセス パターンに基づいて費用を最適化するように設計された、さまざまなストレージ クラスを利用できます。
Cloud Storage はスケーラビリティと費用対効果に優れていますが、レイテンシと I/O の特性を考慮することが重要です。レイテンシは数十ミリ秒と、他のストレージ オプションよりも高くなります。スループットを最大化するには、数百または数千のスレッド、大きなファイル、大きな I/O リクエストを使用する必要があります。Cloud Storage は、さまざまなプログラミング言語のクライアント ライブラリを提供し、Cloud Storage FUSE と Anywhere Cache を提供します。
Cloud Storage FUSE は、Google がサポートするオープンソースの FUSE アダプタです。Cloud Storage FUSE を使用すると、Cloud Storage バケットをローカル ドライブとしてマウントできます。Cloud Storage FUSE は POSIX に完全に準拠していません。そのため、Cloud Storage FUSE の制限事項と従来のファイル システムとの違いを理解することが重要です。Cloud Storage FUSE を使用すると、Cloud Storage のスケール、手頃な価格、パフォーマンスを活かしてトレーニング データ、モデル、チェックポイントにアクセスできます。
Cloud Storage FUSE キャッシュには、次のようなメリットがあります。
- ポータビリティ: 標準のファイル システム セマンティクスを使用して Cloud Storage バケットをマウントしてアクセスできるため、アプリケーションのポータビリティが向上します。
- 互換性: クラウド固有の API を使用するためにアプリケーションをリファクタリングする必要がなくなり、時間とリソースを節約できます。
- アイドル時間の短縮: Cloud Storage のデータに直接アクセスしてトレーニング ジョブをすばやく開始し、GPU と TPU のアイドル時間を最小限に抑えます。
- 高スループット: GPU または TPU を使用した読み取り負荷の高い ML ワークロード用に最適化された Cloud Storage の組み込みのスケーラビリティとパフォーマンスを活用します。
- クライアント ローカル ファイル キャッシュ: 繰り返しファイルを読み取る速度を上げるクライアント ローカル キャッシュを使用して、トレーニングを高速化します。この高速化は、A3 マシンタイプにバンドルされている 6 TiB のローカル SSD と組み合わせて使用すると、さらに強化できます。
Anywhere Cache は、Cloud Storage バケットに最大 1 PiB の SSD ベースのゾーン読み取りキャッシュを提供する Cloud Storage の機能です。Anywhere Cache は、特定のゾーン内で頻繁に読み取られるデータにローカルの高速アクセス レイヤを提供することで、データ量の多いアプリケーションを高速化するように設計されています。
Anywhere Cache には次の利点があります。
- 高速スループット: キャッシュ容量と帯域幅を自動的にスケーリングして、リージョン帯域幅割り当てを超えた高いスループットを、一貫性のある予測可能なレイテンシで実現します。
- コストの削減: キャッシュに保存されたデータに対して、データ転送の下り（外向き）料金やストレージ クラスの取得料金が発生しません。Anywhere Cache は、ワークロードのニーズに合わせてキャッシュと使用可能な帯域幅のサイズを自動的に調整します。
Hyperdisk ML
Hyperdisk ML は、大規模なデータセットへの読み取り専用アクセスを必要とする AI ワークロードと ML ワークロードを高速化するように設計された、高パフォーマンスのブロック ストレージ ソリューションです。Hyperdisk ML は、Colossus のスケーラビリティと可用性を活用して、基盤となるファイル システム全体のパフォーマンスのバランスを取ります。Hyperdisk ML は、 Google Cloud の他のストレージ サービスと比較して、サービング タスクに特に適しています。これは、多くの VM に同時に非常に高い合計スループットを提供できるためです。
Hyperdisk ML には次の利点があります。
- モデルのサービングとスケーラビリティの高速化: 同時実行ノードを数千にスケールアップし、高い集約スループットを実現します。これにより、Kubernetes
ReadOnlyManyモードの推論ワークロードの読み込み時間とリソース使用率が最適化されます。 - 高パフォーマンス密度:Google Cloud で利用可能な最高のスループットと、大規模な共有データセットに対する高速読み取りオペレーションを実現します。
- 総所有コスト（TCO）の改善: GPU のアイドル時間の短縮、マルチアタッチ機能、パフォーマンス プーリングにより、コストを削減します。
- 同時読み取り専用アクセス: VM 間でディスクを共有することで、同じデータを含む複数のディスクを使用するよりも費用対効果が高く、コストを削減できます。複数の VM から静的データにアクセスするには、同じディスクを読み取り専用モードで何百もの VM にアタッチする必要があります。ボリュームを更新するには、1 つを除くすべての VM からディスクを切断する必要があります。
パートナーのストレージ ソリューション
上記のストレージ サービスで満たせないワークロード要件については、Cloud Marketplace で利用可能な次のパートナー ソリューションを使用できます。
これらのパートナー ソリューションは Google によって管理されていません。インフラストラクチャ内で最適な統合とパフォーマンスを確保するには、デプロイと運用タスクを管理する必要があります。
比較分析
次の表に、Google Cloudのストレージ サービスの主な機能を示します。
| Managed Lustre | Cloud Storage | Hyperdisk ML | |
|---|---|---|---|
| 容量 | 18 TiB ～ 8 PiB | 下限値、上限値はありません。 | 4 GiB ～ 64 TiB |
| スケーリング | スケーラビリティなし | 使用状況に応じて自動的にスケーリングされます。 | スケールアップ |
| 共有 | 複数の Compute Engine VM と GKE クラスタにマウント可能。 |
|
サポート対象 |
| 暗号鍵のオプション | Google-owned and Google-managed encryption keys |
|
|
| 永続性 | Managed Lustre インスタンスの存続期間。 | バケットの存続時間 | ディスクの存続期間 |
| 対象 | ゾーン |
|
ゾーン |
| パフォーマンス | プロビジョニングされた容量による線形スケーリング | 自動スケーリングの読み取り / 書き込みレート、動的な負荷の再分散 | 動的スケーリング永続ストレージ |
| 管理 | フルマネージド、POSIX 準拠 | フルマネージド | 手動でのフォーマットとマウント |
データ転送ツール
このセクションでは、Google Cloudのストレージ サービス間でデータを移動する方法について説明します。AI / ML タスクを実行する際に、ロケーション間でデータを移動しなければならない場合があります。たとえば、データが Cloud Storage にある場合は、モデルのトレーニングのために別の場所に移動し、チェックポイント スナップショットまたはトレーニング済みモデルを Cloud Storage にコピーします。
次の方法で Google Cloudにデータを転送できます。
- Storage Transfer Service を使用してオンラインでデータを転送: Cloud Storage、Amazon S3、Azure ストレージ サービス、オンプレミスのデータソースなどのオブジェクトおよびファイル ストレージ システム間の大量のデータの転送を自動化します。Storage Transfer Service を使用すると、ソースのロケーションからターゲット ロケーションにデータを安全にコピーできるだけでなく、変更されたデータの定期的な転送も行うことができます。また、データの整合性検証、自動再試行、ロード バランシングも行います。
- Transfer Appliance を使用してオフラインでデータを転送: ネットワーク接続と帯域幅が使用できない場合、制限されている場合、または高コストな場合に、大量のデータをオフラインで Google Cloud に転送して読み込みます。
- Cloud Storage にデータをアップロードする: Google Cloud コンソール、gcloud CLI、Cloud Storage API、またはクライアント ライブラリを使用して、Cloud Storage バケットにオンラインでデータをアップロードします。
データ転送方法を選択する際は、データサイズ、時間の制約、帯域幅の可用性、費用目標、セキュリティおよびコンプライアンス要件などの要素を考慮してください。 Google Cloudへのデータ転送の計画と実装については、 Google Cloudへの移行: 大規模なデータセットの転送をご覧ください。
適切なストレージを選択する
AI ワークロードと ML ワークロードは通常、準備、トレーニング、サービング、アーカイブの 4 つの主要なステージで構成されます。これらの各ステージには固有のストレージ要件があり、適切なソリューションを選択することで、パフォーマンス、費用、運用効率に大きな影響を与える可能性があります。ハイブリッド アプローチまたはローカル最適化アプローチを使用すると、AI / ML ワークロードの各ステージの特定の要件に合わせてストレージの選択を調整できます。ただし、優先順位が統合管理と運用の容易さである場合は、すべてのステージで一貫したソリューションを使用するグローバルに簡素化されたアプローチが、あらゆる規模のワークロードにメリットをもたらす可能性があります。どのストレージを選択するのが効果的かは、データセットのプロパティ、必要なコンピューティング リソースとストレージ リソースの規模、レイテンシ、以前に定義したワークロード要件によって異なります。
次のセクションでは、AI / ML ワークロードの主なステージと、ストレージの選択に影響する可能性のある要因について詳しく説明します。
準備
準備ステージでは、AI アプリケーションと ML アプリケーションの基盤を設定します。これには、さまざまなソースからクラウド環境に生データをアップロードし、AI モデルと ML モデルのトレーニングに使用できる形式にデータを変換することが含まれます。このプロセスには、選択した AI および ML フレームワークとの互換性を確保するために、データ型のクリーンアップ、処理、変換などのタスクが含まれます。
Cloud Storage は、スケーラビリティ、耐久性、費用対効果に優れているため、準備ステージに適しています。特に、AI で一般的な大規模なデータセットに適しています。Cloud Storage は、他のGoogle Cloud サービスとシームレスに統合されているため、データ集約型のトレーニングに最適な最適化を活用できます。
データ準備フェーズでは、データを大きなチャンクに再編成してアクセス効率を高め、ランダムな読み取りリクエストを回避できます。ストレージ システムの I/O パフォーマンス要件をさらに削減するには、パイプライン化やトレーニングの最適化を使用して I/O スレッドの数を増やします。
トレーニング
トレーニング ステージはモデル開発の中核であり、AI モデルと ML モデルが提供されたデータから学習します。このステージには、トレーニング データにアクセスするための効率的なデータ読み込みと、モデルの進行状況を保存するための信頼性の高いチェックポイントという、要件が異なる 2 つの重要な側面があります。以降のセクションでは、データ読み込みとチェックポイント処理に適したストレージ オプションを選択するための推奨事項と考慮すべき要素について説明します。
データ読み込み
データの読み込み中、GPU または TPU はモデルをトレーニングするためにデータのバッチを繰り返しインポートします。このフェーズでは、バッチのサイズとリクエストの順序に応じて、キャッシュを使用してデータ読み込みタスクを最適化できます。データ読み込みの目標は、費用を最小限に抑えながら最大限の効率でモデルをトレーニングすることです。
トレーニング データのサイズがペタバイト規模にスケーリングすると、データの読み取りが複数回必要になる可能性があります。このようなスケールでは、GPU または TPU アクセラレータによる集中的な処理が必要です。ただし、GPU と TPU がアイドル状態ではなく、データを積極的に処理するようにする必要があります。そうしないと、ある場所から別の場所にデータをコピーしている間に、高額なアイドル アクセラレータの料金が発生します。
データ読み込みのパフォーマンスとコストを最適化するには、次の要素を考慮してください。
- データセットのサイズ: トレーニング データ コーパス全体のサイズと、各トレーニング データセットのサイズ。
- アクセス パターン: トレーニング ワークロードの I/O アクセス パターンを最もよく分類する次のオプションのいずれかを選択します。
- 並列アクセスと順次アクセス: ファイルは単一のノードに割り当てられ、順次読み取られます。
- 並列ランダム アクセス: ファイルが単一のノードに割り当てられ、ランダムに読み取られてサンプル バッチが作成されます。
- 完全なランダム アクセス: ノードは任意のファイルから任意の範囲を読み取ってバッチを作成できます。
- ファイルサイズ: 一般的な読み取りリクエストのサイズ。
データ読み込み用の Managed Lustre
次のいずれかの条件に該当する場合は、データの読み込みに Managed Lustre を選択する必要があります。
- トレーニングの最小容量要件は 18 TiB です。
- トレーニング データは、低レイテンシ機能を活用するために 50 MB 未満の小さなファイルで構成されています。
- ランダム I/O とメタデータ アクセスのストレージ要件を満たすため、1 ミリ秒未満のレイテンシ要件がある。
- ユーザーのデータを表示して管理するために、POSIX を完全にサポートするデスクトップのようなエクスペリエンスが必要。
Managed Lustre を Cloud Storage の上に高性能キャッシュとして使用すると、フルマネージドの並列ファイル システムで、極めて高いスループットと低レイテンシの I/O オペレーションを必要とする AI ワークロードと ML ワークロードを高速化できます。トレーニング中のレイテンシを最小限に抑えるには、Cloud Storage から Managed Lustre にデータをインポートします。GKE をコンピューティング プラットフォームとして使用する場合は、
GKE Managed Lustre CSI ドライバを使用して、Cloud Storage のデータで PersistentVolumeClaim を事前入力します。トレーニングが完了したら、データを低コストの Cloud Storage クラスにエクスポートして、長期保存の費用を最小限に抑えることができます。
データ読み込み用の Cloud Storage
一般に、次のいずれかの条件に該当する場合は、Cloud Storage を選択してデータを読み込む必要があります。
- トレーニング容量の要件が 100 TiB 以上である。
- トレーニング データは 50 MB 以上の大きなファイルで構成されています。
- ストレージ パフォーマンスよりもデータの耐久性と高可用性を優先する。
Cloud Storage は、大規模なデータセットを保存するためのスケーラブルで費用対効果の高いソリューションを提供します。また、Cloud Storage FUSE を使用すると、ローカル ファイル システムとしてデータにアクセスできます。Cloud Storage FUSE は、トレーニング データをマシン アクセラレータの近くに保持することで、トレーニング中のデータアクセスを高速化し、スループットを向上させます。
1 TB/秒を超えるスループットを必要とするワークロードの場合、Anywhere Cache はデータをキャッシュに保存し、リージョン帯域幅割り当てを超えてスケーリングすることで、読み取り速度を高速化します。Anywhere Cache がワークロードに適しているかどうかを評価するには、Anywhere Cache Recommender を使用してデータ使用量とストレージを分析します。
チェックポイントの作成と復元
チェックポイントの作成と復元の場合、トレーニング ジョブは、インスタンスの障害から迅速に復旧できるように、状態を定期的に保存する必要があります。障害が発生した場合、ジョブを再起動して最新のチェックポイントを取り込み、トレーニングを再開する必要があります。チェックポイントの作成と取り込みに使用される正確なメカニズムは、通常、フレームワークに固有のものです。TensorFlow Core のチェックポイントと最適化手法については、トレーニング チェックポイントをご覧ください。PyTorch のチェックポイントと最適化手法については、モデルの保存と読み込みをご覧ください。
どの時点でも、保存する必要があるチェックポイントは数個だけです。チェックポイントのワークロードは、通常、主に書き込みと複数回の削除で構成されます。理想的には、障害発生時のまれな読み取りで構成されます。
チェックポイントと復元のパフォーマンスを最適化するには、次の要素を考慮してください。
- モデルサイズ: AI モデルと ML モデルに含まれるパラメータの数。モデルのサイズは、チェックポイント ファイルのサイズに直接影響します。チェックポイント ファイルのサイズは GiB から TiB の範囲になります。
- チェックポイントの頻度: モデルがチェックポイントを保存する頻度。保存頻度を高くすると耐障害性が向上しますが、ストレージ費用が増加し、トレーニング速度に影響する可能性があります。
- チェックポイントの復元時間: チェックポイントの読み込みとトレーニングの再開に必要な復元時間。復元時間を最小限に抑えるには、チェックポイント サイズ、ストレージ パフォーマンス、ネットワーク帯域幅などの要因を考慮します。
チェックポイント用の Managed Lustre
次のいずれかの条件に該当する場合は、チェックポイントに Managed Lustre を選択する必要があります。
- トレーニング ワークロードですでに Managed Lustre を使用してデータを読み込んでいる。
- 高パフォーマンスのチェックポイントを頻繁に実行する必要がある。
リソース使用率を最大化し、アクセラレータのアイドル時間を最小限に抑えるには、トレーニングとチェックポイントに Managed Lustre を使用します。Managed Lustre は、VM あたりの高いスループットを実現する高速チェックポイント書き込みを実現できます。チェックポイントは永続的な Managed Lustre インスタンスに保持できます。また、チェックポイントを Cloud Storage に定期的にエクスポートして、費用を最適化することもできます。
チェックポイント用の Cloud Storage
次のいずれかの条件に該当する場合は、チェックポイントに Cloud Storage を選択する必要があります。
- トレーニング ワークロードで Cloud Storage FUSE を使用する。
- ストレージ パフォーマンスよりもデータの耐久性と高可用性を優先する。
チェックポイント作成のパフォーマンスを向上させるには、階層名前空間が有効になっている Cloud Storage FUSE を使用して、高速なアトミック名前変更オペレーションを利用し、チェックポイントを非同期で保存します。サービング中にトレーニング データセットから機密情報が誤って公開されるのを防ぐには、チェックポイントを別の Cloud Storage バケットに保存する必要があります。アップロードが停止した場合のテールエンドの書き込みレイテンシを短縮するため、Cloud Storage FUSE は 10 秒後に再試行します。
サービング
モデルを提供する（推論とも呼ばれます）場合、主な I/O パターンは、モデルを GPU または TPU メモリに読み込む読み取り専用のパターンです。サービング ステージの目標は、本番環境でモデルを実行することです。このモデルはトレーニング データよりもはるかに小さいため、複数のインスタンス間でモデルを複製してスケーリングできます。データをサービングする場合は、高可用性とゾーン障害やリージョン障害に対する保護が重要です。そのため、さまざまな障害シナリオでもモデルが利用できるようにする必要があります。
多くの生成 AI と ML のユースケースでは、モデルへの入力データが非常に小さく、データを永続的に保存する必要がない場合があります。また、モデルに対して大量のデータを実行しなければならない場合もあります（科学データセットなど）。大量のデータを実行するには、データセットの分析中に GPU または TPU のアイドル時間を最小限に抑えることができるストレージ オプションを選択し、推論結果を保存する永続的な場所を使用します。
モデルの読み込み時間はアクセラレータのアイドル時間に直接影響し、多額の費用が発生します。ノードあたりのモデル読み込み時間の増加は、多くのノードで増幅されるため、費用が大幅に増加する可能性があります。したがって、サービング インフラストラクチャの費用対効果を高めるには、モデルの高速読み込みを最適化することが重要です。
サービングのパフォーマンスと費用を最適化するには、次の要素を考慮してください。
- モデルサイズ: モデルのサイズ（GiB または TiB）。モデルが大きいほど、必要な計算リソースとメモリが増え、レイテンシが増加する可能性があります。
- モデルの読み込み頻度: モデルを更新する頻度。頻繁な読み込みと読み込み解除は、コンピューティング リソースを消費し、レイテンシを増加させます。
- サービング ノードの数: モデルにサービスを提供するノードの数。一般的に、ノードを増やすとレイテンシが減少し、スループットが向上しますが、インフラストラクチャの費用も増加します。
サービング用の Managed Lustre
次のいずれかの条件に該当する場合は、モデルのサービングに Managed Lustre を選択する必要があります。
- トレーニングとチェックポインティングのワークロードで Managed Lustre を使用している。
- ワークロードで 10 ～ 100 個の推論ノードを使用している。
- モデルを頻繁に更新する。
トレーニングとチェックポイントに Managed Lustre をすでに使用している場合は、モデルのサービングに費用対効果が高く、高性能なオプションを使用できます。マネージド Lustre は、VM あたりの高いスループットとクラスタの合計スループットを提供し、モデルの読み込み時間を短縮します。Managed Lustre は、任意の数のサービング VM で使用できます。
Cloud Storage: サービング用
次のいずれかの条件に該当する場合は、モデルのサービングに Cloud Storage を選択する必要があります。
- 推論ノードの数を変更できる動的環境向けの費用対効果の高いソリューションが必要です。
- モデルの更新頻度が低い。
- リージョンで中断が発生した場合でも、モデルの高可用性と耐久性を優先します。
マルチリージョンまたはデュアルリージョン アーキテクチャを使用すると、Cloud Storage は高可用性を提供し、ゾーン障害やリージョン障害からワークロードを保護します。モデルの読み込みを高速化するには、並列ダウンロードを有効にして Cloud Storage FUSE を使用し、モデルの一部を並列で取得します。
1 TB/秒を超えるスループットでモデル サービングを実現する場合や、100 個を超えるサービング ノードをデプロイする場合は、マルチリージョン バケットで Anywhere Cache を使用します。この組み合わせにより、リージョン間の高パフォーマンスで冗長なストレージと柔軟性が実現します。また、Anywhere Cache では、キャッシュに保存されたデータに対するデータ下り（外向き）料金とストレージ クラスの取得料金が不要になります。
サービング用の Hyperdisk ML
次のいずれかの条件に該当する場合は、モデルのサービングに Hyperdisk ML を選択する必要があります。
- 100 個を超える推論ノードが必要である。
- モデルの更新頻度が低い。
- ワークロードでサポートされている VM タイプを使用している。
- パイプラインは、モデルを保存する読み取り専用ボリュームを管理できます。
Cloud Storage データのキャッシュとして Hyperdisk ML を使用して、サービングのパフォーマンスを最適化します。Hyperdisk ML は、共有パフォーマンス プーリングと、複数の VM 間で動的にプロビジョニングされたスループットを使用して、あらゆる規模の読み取り専用モデル サービングを効率的に処理します。
アーカイブ
アーカイブ ステージの I/O パターンは「書き込みは 1 回、読み取りはまれ」です。このステージの目標は、さまざまなトレーニング データセットと、生成されたさまざまなバージョンのモデルを保存することです。これらの増分バージョンのデータとモデルは、バックアップと障害復旧に使用できます。また、これらのアイテムは耐久性のある場所に長期間にわたって保管する必要があります。データとモデルに頻繁にアクセスする必要はありませんが、必要なときに利用できるようにする必要があります。
オブジェクト データを長期保存するには Cloud Storage が最適です。このストレージは耐久性、拡張性、コスト効率に優れています。Google Cloud Cloud Storage では、データセット、モデル、バックアップ ファイルにアクセスする頻度に応じて、さまざまなストレージ クラスを使用して費用を最適化できます。アーカイブされたデータへのアクセス頻度に基づいて、ストレージ クラスを選択できます。
- 頻繁なデータアクセス: Standard Storage
- 月ごとのデータアクセス: Nearline Storage
- 四半期に 1 回のデータアクセス: Coldline Storage
- 年間のデータ アクセス: Archive Storage
オブジェクトのライフサイクル管理を使用して、データを長期保存ストレージ クラスに自動的に移動するポリシーや、特定の条件でデータを削除するポリシーを作成できます。データにアクセスする頻度が不明な場合は、Autoclass 機能を使用して、アクセス パターンに基づいてストレージ クラス間でデータを自動的に移動できます。
次のステップ
ストレージ オプションと AI / ML ワークロードの詳細については、次のリソースをご覧ください。
- Managed Lustre で AI と ML のワークロードを最適化する方法について学習する。
- Cloud Storage FUSE を使用して AI / ML ワークロードを最適化する方法について学習する。
- Google Cloud Well-Architected Framework の AI と ML の視点について学習する。
- Cloud アーキテクチャ センターで、リファレンス アーキテクチャ、図、ベスト プラクティスを確認する。
寄稿者
著者: Samantha He | テクニカル ライター
その他の寄稿者:
- David Stiver | グループ プロダクト マネージャー
- Dean Hildebrand | CTO オフィス テクニカル ディレクター
- Kumar Dhanagopal | クロス プロダクト ソリューション デベロッパー
- Sean Derrington | グループ アウトバウンド プロダクト マネージャー、ストレージ