このドキュメントでは、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 とともに Cloud Storage FUSE と Anywhere Cache を使用します。
- トレーニング データが 50 MB 以上の大きなファイルで構成されている。
- 数十ミリ秒という高いストレージ レイテンシを許容できる。
- ストレージ パフォーマンスよりもデータの耐久性と高可用性を優先する。
費用を最適化するには、モデル トレーニングのすべてのステージで同じストレージ サービスを使用することをおすすめします。
サービング
ML ワークフローのサービング ステージでは、次のことを行います。
- モデルを保存します。
- 起動時にマシン アクセラレータを実行するインスタンスにモデルを読み込みます。
- モデル推論の結果（生成された画像など）を保存します。
- 必要に応じて、モデル推論に使用するデータセットを保存して読み込みます。
サービング ステージには、次のストレージ オプションをおすすめします。
- ワークロードに次の特性がある場合は、Managed Lustre を使用します。
- トレーニングとチェックポイント処理のワークロードで Managed Lustre を使用している。
- 10～100 個の推論ノードが必要。
- モデルを頻繁に更新する。
- ワークロードに次の特性がある場合は、Cloud Storage とともに Cloud Storage FUSE と Anywhere Cache を使用します。
- 推論ノードの数が変化する動的環境で費用対効果の高いソリューションが必要。
- モデルの更新頻度が低い。
- リージョンで中断が発生した場合でも、モデルの高可用性と耐久性を優先する。
- ワークロードに次の特性がある場合は、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）または Tensor Processing Unit（TPU）の最大数はいくつか。
このような項目への回答は、このドキュメントの後半で適切なストレージを選択する際に使用します。
ストレージ オプションを確認する
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 を維持できます。
Managed 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 つの重要な側面があります。1 つは、トレーニング データにアクセスするための効率的なデータ読み込み、もう 1 つはモデルの進行状況を保存するための信頼性の高いチェックポイント処理です。以降のセクションでは、データ読み込みとチェックポイント処理に最適なストレージ オプションを選択するための推奨事項と考慮すべき要素について説明します。
データの読み込み
データの読み込み中、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 のデータを使用して PersistentVolumesClaims にデータを設定します。トレーニングが完了した後、データを低コストの 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 を使用している場合は、モデルのサービングに費用対効果の高い高性能なオプションを使用できます。Managed 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 回、読み取りはまれ」です。このステージの目標は、さまざまなトレーニング データセットと、生成されたさまざまなバージョンのモデルを保存することです。これらの増分バージョンのデータとモデルはバックアップと障害復旧に使用できます。また、これらのアイテムは耐久性のある場所に長期間にわたって保管する必要があります。データとモデルに頻繁にアクセスする必要はありませんが、必要なときに利用できるようにする必要があります。
Google Cloud でオブジェクト データを長期保存するには Cloud Storage が最適です。このストレージは耐久性、拡張性、コスト効率に優れています。Cloud Storage では、データセット、モデル、バックアップ ファイルにアクセスする頻度に応じて、さまざまなストレージ クラスを使用して費用を最適化できます。アーカイブされたデータへのアクセス頻度に基づいて、ストレージ クラスを選択できます。
- データへのアクセス頻度が高い: Standard Storage
- 月ごとのデータアクセス: Nearline Storage
- 四半期に 1 回のデータアクセス: Coldline Storage
- 年 1 回のデータアクセス: 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 | ストレージ担当グループ プロダクト マネージャー