このドキュメント（Google Cloud Well-Architected Framework: AI と ML の視点）では、 Google Cloudで AI ワークロードと ML ワークロードのパフォーマンスを最適化するための原則と推奨事項について説明します。このドキュメントの推奨事項は、Well-Architected Framework のパフォーマンス最適化の柱に沿っています。
AI システムと ML システムにより、組織の高度な自動化機能と意思決定機能を実現できます。これらのシステムのパフォーマンスは、収益、費用、顧客満足度などの重要なビジネス推進要因に直接影響する可能性があります。AI システムと ML システムの可能性を最大限に引き出すには、ビジネスの目標と技術要件に基づいてパフォーマンスを最適化する必要があります。パフォーマンスの最適化プロセスでは、多くの場合、トレードオフが発生します。たとえば、必要なパフォーマンスを提供する設計を選択すると、コストが増加する可能性があります。このドキュメントの推奨事項では、他の考慮事項よりもパフォーマンスを優先しています。
AI と ML のパフォーマンスを最適化するには、モデルのアーキテクチャ、パラメータ、トレーニング戦略などの要素について決定する必要があります。これらの決定を行う際は、AI システムと ML システムのライフサイクル全体とそのデプロイ環境を考慮してください。たとえば、非常に大規模な LLM は、大規模なトレーニング インフラストラクチャで高いパフォーマンスを発揮できますが、モバイル デバイスなどの容量に制約のある環境ではパフォーマンスが低下する可能性があります。
このドキュメントの推奨事項は、次の基本原則にマッピングされています。
- パフォーマンスの目標と評価方法を確立する
- 頻繁なテストを実行して追跡する
- トレーニングとサービングのインフラストラクチャを構築して自動化する
- 設計の選択をパフォーマンス要件に合わせて調整する
- パフォーマンス指標を設計と構成の選択にリンクする
パフォーマンスの目標と評価方法を確立する
ビジネス戦略と目標は、AI と ML のテクノロジーを活用するための基盤です。ビジネスの目標を測定可能な重要業績評価指標（KPI）に変換します。KPI の例としては、総収益、費用、コンバージョン率、維持率または解約率、顧客満足度、従業員満足度などがあります。
現実的な目標を定義する
サイト信頼性エンジニアリング（SRE）のベスト プラクティスによると、サービスの目標は、一般的な顧客の要件を満たすパフォーマンス レベルを反映する必要があります。つまり、サービス目標は、スケールと機能のパフォーマンスの観点から現実的である必要があります。
非現実的な目標を設定すると、リソースが無駄になり、パフォーマンスの向上は最小限に抑えられます。最高のパフォーマンスを提供するモデルが、最適なビジネス成果につながるとは限りません。このようなモデルでは、トレーニングと実行に時間と費用がかかる場合があります。
目標を定義する際は、品質目標とパフォーマンスの目標を区別して優先順位を付けます。
- 品質とは、エンティティの価値を決定する固有の特性を指します。これにより、エンティティが期待値と基準を満たしているかどうかを評価できます。
- パフォーマンスとは、エンティティがその目的をどれだけ効率的かつ効果的に果たすかを示します。
ML エンジニアは、トレーニング プロセス中にモデルのパフォーマンス指標を改善できます。Gemini Enterprise Agent Platform には、ML エンジニアが品質指標の標準化された反復可能なトラッキングを実装するために使用できる評価サービスが用意されています。モデルの予測効率は、本番環境または推論時にモデルがどの程度適切に機能するかを示します。パフォーマンスをモニタリングするには、Cloud Monitoring と Gemini Enterprise Agent Platform の Model Monitoring を使用します。適切なモデルを選択し、トレーニング方法を決定するには、ビジネスの目標を技術要件に変換して、品質とパフォーマンス指標を決定する必要があります。
現実的な目標を設定し、適切なパフォーマンス指標を特定する方法を理解するために、AI を活用した不正行為検出システムの例を考えてみましょう。
- ビジネス目標: 不正行為検出システムの場合、1 秒あたり 1, 000 億件のトランザクションのピーク トラフィックで、1 ナノ秒以内に不正なトランザクションを 100% 正確に検出するというビジネス目標は現実的ではありません。より現実的な目標は、米国の営業時間中に 1 秒あたり 100 万件のトランザクションのピーク時に、オンライン予測の 90% で 100 ミリ秒以内に 95% の精度で不正なトランザクションを検出することです。
- パフォーマンス指標: 不正行為の検出は分類問題です。不正行為検出システムの品質は、再現率、F1 スコア、精度などの指標を使用して測定できます。システムのパフォーマンスや速度を追跡するには、推論レイテンシを測定します。不正な取引の可能性を検出することは、精度よりも価値が高い場合があります。したがって、現実的な目標は、p90 レイテンシが 100 ミリ秒未満で、再現率が高いことです。
モデル ライフサイクルのすべての段階でパフォーマンスをモニタリングする
テストとトレーニング中、およびモデルのデプロイ後に、KPI をモニタリングし、ビジネスの目標からの逸脱を観察します。包括的なモニタリング戦略は、モデルの品質とリソースの使用率に関する重要な決定を下すのに役立ちます。たとえば、次のような決定です。
- トレーニング ジョブを停止するタイミングを決定する。
- 本番環境でモデルのパフォーマンスが低下しているかどうかを判断する。
- 新しいモデルの費用と製品化までの時間を改善する。
テストとトレーニング中のモニタリング
テスト段階の目的は、特定のタスクに最適な全体的なアプローチ、モデル アーキテクチャ、ハイパーパラメータを見つけることです。テストを繰り返すことで、最適なパフォーマンスを実現する構成とモデルのトレーニング方法を決定できます。モニタリングは、改善の余地がある領域を効率的に特定するのに役立ちます。
モデルの品質とトレーニング効率をモニタリングするには、ML エンジニアは次のことを行う必要があります。
- 各トライアルのモデルの品質とパフォーマンス指標を可視化する。
- 重みとバイアスのヒストグラムなど、モデルのグラフと指標を可視化する。
- トレーニング データを視覚的に表現する。
- さまざまなハードウェアでトレーニング アルゴリズムをプロファイリングする。
テストとトレーニングをモニタリングするには、次の推奨事項を検討してください。
モデルの品質: 精度などのテスト指標を可視化して追跡し、モデル アーキテクチャやトレーニング データを可視化するには、TensorBoard を使用します。TensorBoard は、次のような ML フレームワークと互換性のあるオープンソースのツールスイートです。
- XGBoost
- JAX
- Flax
- PyTorch
- Cloud TPU トレーニング用の Cloud TPU の XLA ベースのフレームワーク
- TensorFlow
テストのトラッキング: Gemini Enterprise Agent Platform のテストは、マネージド エンタープライズ グレードの Agent Platform TensorBoard インスタンスと統合され、テストのトラッキングをサポートします。この統合により、ログと指標の信頼性の高い保存と共有が可能になります。複数のチームや個人がテストを追跡できるようにするには、最小権限の原則を使用することをおすすめします。
トレーニングとテストの効率: Agent Platform は指標を Monitoring にエクスポートし、オブザーバビリティ エージェントを使用してテレメトリー データとログを収集します。指標は Google Cloud コンソールで可視化できます。または、Monitoring を使用して、これらの指標に基づいてダッシュボードまたはアラートを作成します。詳細については、Agent Platform のモニタリング指標をご覧ください。
NVIDIA GPU: Ops エージェントを使用すると、Compute Engine と Ops エージェントがサポートする他のプロダクトで GPU モニタリングを有効にできます。NVIDIA Data Center GPU Manager（DCGM）を使用することもできます。これは、クラスタ環境内の NVIDIA GPU の管理とモニタリングを行うためのツールセットです。NVIDIA GPU のモニタリングは、ディープ ラーニング モデルのトレーニングとサービングに特に役立ちます。
詳細なデバッグ: トレーニング コードや Gemini Enterprise Agent Platform マネージド トレーニング ジョブの構成に関する問題をデバッグするには、インタラクティブ シェル セッションを使用してトレーニング コンテナを検査します。
サービング中のモニタリング: ストリーミング予測
モデルをトレーニングして Gemini Enterprise Agent Platform の Model Registry にエクスポートしたら、Agent Platform エンドポイントを作成できます。このエンドポイントは、モデルの HTTP エンドポイントを提供します。
Agent Platform の Model Monitoring を使用すると、入力特徴量または出力特徴量の分布の大きな変化を特定できます。また、ベースライン分布と比較して、本番環境の特徴アトリビューションをモニタリングすることもできます。ベースライン分布は、トレーニング セットにすることも、本番環境トラフィックの過去の分布に基づくこともできます。サービング分布の変化は、トレーニングと比較して予測パフォーマンスが低下していることを示している可能性があります。
- モニタリングの目標を選択する: モデルに提供されるデータの変化に対するユースケースの感度に応じて、入力特徴ドリフト、出力ドリフト、特徴アトリビューションなど、さまざまなタイプの目標をモニタリングできます。Agent Platform v2 の Model Monitoring を使用すると、Agent Platform などのマネージド サービング プラットフォームや、Google Kubernetes Engine（GKE）などのセルフホスト型サービスにデプロイしたモデルをモニタリングできます。また、パフォーマンスを詳細にトラッキングするために、エンドポイントではなくモデルレベルでパラメータをモニタリングできます。
- 生成 AI モデルのモデル提供をモニタリングする: 特に LLM エンドポイントの安定性を確保し、レイテンシを最小限に抑えるには、堅牢なモニタリング スタックを設定します。Gemini モデルには、最初のトークンまでの時間（TTFT）などの組み込み指標が用意されています。これらの指標には、Metrics Explorer で直接アクセスできます。すべてのGoogle Cloud モデルのスループット、レイテンシ、エラー率をモニタリングするには、モデルのオブザーバビリティ ダッシュボードを使用します。
サービング中のモニタリング: バッチ予測
バッチ予測をモニタリングするには、Agent Platform 評価サービスで標準評価ジョブを実行します。Agent Platform の Model Monitoring は、バッチ推論のモニタリングをサポートしています。Batch を使用してサービング ワークロードを実行する場合は、Metrics Explorer の指標を使用してリソース消費量をモニタリングできます。
評価を自動化して再現性と標準化を実現する
モデルをプロトタイプから信頼性の高い本番環境システムに移行するには、標準化された評価プロセスが必要です。このプロセスにより、イテレーション全体の進捗状況の追跡、さまざまなモデルの比較、バイアスの検出と軽減、規制要件の遵守が可能になります。再現性とスケーラビリティを確保するには、評価プロセスを自動化する必要があります。
ML パフォーマンスの評価プロセスを標準化して自動化するには、次の手順を完了します。
- 定量的指標と定性的指標を定義する。
- 適切なデータソースと手法を選択する。
- 評価パイプラインを標準化する。
以下では、この違いについて説明します。
1. 定量的指標と定性的指標を定義する
計算ベースの指標は、数値式を使用して計算されます。トレーニング損失の指標は、ビジネス目標に関連する評価指標とは異なる場合があります。たとえば、教師あり不正行為検出に使用されるモデルでは、トレーニングにクロスエントロピー損失が使用される場合があります。ただし、推論パフォーマンスを評価するには、不正な取引の範囲を示す再現率の方が関連性の高い指標となる可能性があります。Agent Platform には、再現率、適合率、適合率-再現率曲線下面積（AuPRC）などの指標の評価サービスが用意されています。詳細については、Agent Platform でのモデル評価をご覧ください。
生成されたコンテンツの流暢さやエンターテイメント価値などの定性的な指標は、客観的に計算できません。これらの指標を評価するには、LLM-as-a-judge 戦略または Labelbox などのヒューマン ラベリング サービスを使用します。
2. 適切なデータソースと手法を選択する
評価は、さまざまなサンプルの最小量で実行されると、統計的に有意になります。評価に使用するデータセットと手法は、次のようなアプローチを使用して選択します。
- ゴールデン データセット: 本番環境のモデルの確率分布を反映した、信頼性が高く、一貫性のある正確なデータサンプルを使用します。
- LLM-as-a-judge: LLM を使用して生成モデルの出力を評価します。このアプローチは、LLM がモデルを評価できるタスクにのみ関連します。
- ユーザー フィードバック: 今後の改善に役立てるため、本番環境トラフィックの一部としてユーザーからの直接のフィードバックを収集します。
評価手法、評価データのサイズとタイプ、評価の頻度に応じて、BigQuery または Cloud Storage をデータソースとして使用できます。これには、Agent Platform 評価サービスも含まれます。
- BigQuery では、SQL コマンドを使用して、自然言語処理や機械翻訳などの推論タスクを実行できます。詳細については、タスク固有のソリューションの概要をご覧ください。
- Cloud Storage は、大規模なデータセットに費用対効果の高いストレージ ソリューションを提供します。
3. 評価パイプラインを標準化する
評価プロセスを自動化するには、次のサービスとツールを検討してください。
- Agent Platform 評価サービス: Agent Platform の ML ライフサイクルの一部としてモデルのパフォーマンスを追跡するための、すぐに使用できるプリミティブを提供します。
- Gen AI Evaluation Service: 生成モデルまたはアプリケーションを評価し、独自の判断と評価基準に基づいて評価結果のベンチマークを実施できます。このサービスは、プロンプト エンジニアリング、検索拡張生成（RAG）、AI エージェントの最適化などの専門的なタスクの実行にも役立ちます。
- Agent Platform の Automatic side-by-side（AutoSxS）ツール: ペアワイズ モデルベースの評価をサポートします。
- Kubeflow: モデル評価を実行するための特別なコンポーネントを提供します。
頻繁なテストを実行して追跡する
ML のパフォーマンスを効果的に最適化するには、テスト用の強力でインタラクティブな専用プラットフォームが必要です。プラットフォームには次の機能が必要です。
- 反復的な開発を促進し、チームがアイデアから検証済みの結果に迅速、確実、大規模に移行できるようにします。
- チームがトレーニング ジョブのトリガーに使用できる最適な構成を効率的に見つけられるようにします。
- テストの実施と追跡を行うために、関連するデータ、機能、ツールへのアクセスを制御します。
- 再現性とデータリネージのトラッキングをサポートする。
データをサービスとして扱う
次の手法を使用して、テスト用のワークロードを本番環境システムから分離し、データアセットに適切なセキュリティ管理を設定します。
| 手法 | 説明 | 利点 |
|---|---|---|
| リソース分離 | 異なる環境のリソースを
別々の Google Cloud プロジェクトに分離します。たとえば、開発環境、ステージング環境、本番環境のリソースを、ml-dev、ml-staging、ml-prod などの別々のプロジェクトにプロビジョニングします。 |
リソースを分離すると、本番環境システムに必要なリソースを試験運用版のワークロードが消費するのを防ぐことができます。たとえば、テストと本番環境に単一のプロジェクトを使用すると、テストで Agent Platform マネージド トレーニングに使用可能なすべての NVIDIA A100 GPU が消費される可能性があります。これにより、重要な本番環境モデルの再トレーニングが中断される可能性があります。 |
| ID とアクセス制御 | ゼロトラストと最小権限の原則を適用し、ワークロード固有のサービス アカウントを使用します。Agent Platform ユーザー（roles/aiplatform.user）などの事前定義された Identity and Access Management（IAM）ロールを使用してアクセス権を付与します。 |
このアプローチは、テストを破損する可能性のある偶発的または悪意のあるアクションを防ぐのに役立ちます。 |
| ネットワーク セキュリティ | Virtual Private Cloud（VPC）ネットワークを使用してネットワーク トラフィックを分離し、VPC Service Controls を使用してセキュリティ境界を適用します。 | このアプローチは、機密データを保護し、テスト トラフィックが本番環境サービスに影響を与えないようにするのに役立ちます。 |
| データの分離 | テストデータを個別の Cloud Storage バケットと BigQuery データセットに保存します。 | データ分離により、本番環境データの偶発的な変更を防ぐことができます。たとえば、データ分離がない場合、テストによって共有 BigQuery テーブルの特徴値が誤って変更され、本番環境でモデルの精度が大幅に低下する可能性があります。 |
チームに適切なツールを提供する
データ探索からモデルのトレーニングと分析まで、テストのライフサイクル全体を加速する厳選されたツールセットを確立するには、次の手法を使用します。
- インタラクティブなプロトタイピング: 迅速なデータ探索、仮説検証、コードのプロトタイピングには、Colab Enterprise または Gemini Enterprise Agent Platform Workbench のマネージド JupyterLab インスタンスを使用します。詳細については、ノートブック ソリューションを選択するをご覧ください。
- スケーラブルなモデル トレーニング: 分散トレーニングと、GPU や Cloud TPU などのスケーラブルなコンピューティング リソースをサポートするマネージド サービスでトレーニング ジョブを実行します。このアプローチにより、トレーニング時間を数日から数時間に短縮し、より多くの並列テストが可能になります。詳細については、トレーニングに専用コンポーネントを使用するをご覧ください。
- データベース内 ML: SQL を使用して BigQuery ML でモデルを直接トレーニングします。この手法により、データ移動が不要になり、アナリストや SQL 中心ユーザーのテストが加速します。
- テストの追跡: テスト実行ごとにパラメータ、指標、アーティファクトをロギングして、テストデータの検索と比較が可能な履歴を作成します。詳細については、データとモデルのリネージ システムを構築するをご覧ください。
- 生成 AI の最適化: 生成 AI アプリケーションのパフォーマンスを最適化するには、プロンプト、モデルの選択、ファインチューニングをテストする必要があります。迅速なプロンプト エンジニアリングには、Gemini Enterprise Agent Platform の Agent Studio を使用します。基盤モデル（Gemini など）を試して、ユースケースとビジネスの目標に適したモデルを見つけるには、Model Garden を使用します。
再現性と効率性を高めるために標準化する
テストでリソースを効率的に消費し、一貫性のある信頼性の高い結果を生成するには、次のアプローチを使用してテストを標準化して自動化します。
- コンテナを使用して一貫した環境を確保する: トレーニング コードと依存関係を Docker コンテナとしてパッケージ化します。Artifact Registry を使用してコンテナを管理し、提供する。このアプローチでは、同一の環境でテストを繰り返すことで、異なるマシンで問題を再現できます。Agent Platform には、サーバーレス トレーニング用のビルド済みコンテナが用意されています。
- ML ワークフローをパイプラインとして自動化する: Gemini Enterprise Agent Platform Pipelines を使用して、エンドツーエンドの ML ワークフローをコード化されたパイプラインとしてオーケストレートします。このアプローチにより、一貫性を適用し、再現性を確保して、Agent Platform ML Metadata のすべてのアーティファクトとメタデータを自動的に追跡できます。
- Infrastructure as Code（IaC）でプロビジョニングを自動化する: Terraform などの IaC ツールを使用して、標準化されたテスト環境を定義してデプロイします。すべてのプロジェクトがセキュリティ、ネットワーキング、ガバナンスの標準化された構成セットに準拠するようにするには、Terraform モジュールを使用します。
トレーニング インフラストラクチャとサービング インフラストラクチャを構築して自動化する
AI モデルをトレーニングしてサービングするには、効率的で信頼性の高い開発、デプロイ、サービングをサポートする堅牢なプラットフォームを設定します。このプラットフォームにより、チームはトレーニングとサービングの品質とパフォーマンスを長期的に効率よく向上させることができます。
トレーニングに特化したコンポーネントを使用する
信頼性の高いトレーニング プラットフォームは、パフォーマンスの向上に役立ち、データの準備からモデルの検証まで、ML ライフサイクルで繰り返し可能なタスクを自動化するための標準化されたアプローチを提供します。
データの収集と準備
効果的なモデル トレーニングを行うには、トレーニング、テスト、検証に必要なデータを収集して準備する必要があります。データはさまざまなソースから取得され、さまざまなデータ型になる可能性があります。また、トレーニング実行全体で関連するデータを再利用し、チーム間で特徴を共有する必要もあります。データ収集と準備フェーズの再現性を向上させるには、次の推奨事項を検討してください。
- Knowledge Catalog を使用してデータの検出可能性を向上させる。
- Agent Platform Feature Store で特徴量エンジニアリングを一元化する。
- Dataflow を使用してデータを前処理する。
トレーニングの実行
モデルをトレーニングするときは、データを使用してモデル オブジェクトを作成します。これを行うには、トレーニング コードに必要なインフラストラクチャと依存関係を設定する必要があります。また、トレーニング モデルを保持する方法、トレーニングの進行状況を追跡する方法、モデルを評価する方法、結果を提示する方法を決定する必要があります。トレーニングの再現性を向上させるには、次の推奨事項を検討してください。
- 再現性と標準化のために評価を自動化するのガイドラインに沿って操作します。
- 基盤となるインフラストラクチャのプロビジョニングや依存関係を管理せずに、1 つ以上のワーカーノードでトレーニング ジョブを送信するには、Agent Platform マネージド トレーニングの
CustomJobリソースを使用します。ハイパーパラメータ チューニング ジョブにCustomJobリソースを使用することもできます。 - Agent Platform Managed Training に Dynamic Workload Scheduler または予約を使用して、スケジューリングのグッドプットを最適化します。
- モデルを Model Registry に登録します。
トレーニングのオーケストレーション
Agent Platform Pipelines を使用して、トレーニング ワークロードをパイプラインのステージとしてデプロイします。このサービスは、マネージド Kubeflow サービスと TFX サービスを提供します。パイプラインの各ステップを、コンテナで実行されるコンポーネントとして定義します。各コンポーネントは関数のように機能し、入力パラメータと出力アーティファクトがパイプラインの後続のコンポーネントへの入力になります。パイプラインの効率を最適化するには、次の推奨事項を考慮してください。
- コア自動化を実装する:
- Kubeflow Pipelines コンポーネントを使用する。
- 条件付きゲートなどの高度なパイプライン設計には、制御フローを使用します。
- CI / CD フローの一部としてパイプラインのコンパイルを統合します。
- Cloud Scheduler を使用してパイプラインを実行する。
- 速度と費用対効果を向上させる:
- 堅牢性を高める:
- ガバナンスとトラッキングを実装する:
- さまざまなモデル構成やトレーニング構成を試すには、パイプライン実行をテストに追加します。
- Agent Platform Pipelines のログと指標をモニタリングする。
- モデル ライフサイクルのすべての段階でパフォーマンスをモニタリングするの推奨事項に従ってください。
予測に専用のインフラストラクチャを使用する
インフラストラクチャとモデルのデプロイを管理するトイルを軽減するには、繰り返し可能なタスクフローを自動化します。サービス指向のアプローチにより、スピードと価値創出までの時間（TTV）の短縮に集中できます。以下の推奨事項を参考にしてください。
自動デプロイを実装する
- モデルのトレーニングが完了したら、自動化を使用してモデルをデプロイします。Agent Platform Pipelines には、Agent Platform エンドポイントにモデルをデプロイするための専用コンポーネントが用意されています。自動デプロイは、Kubeflow Control Flows を使用して管理できます。
- 検証セットに対する評価に基づいてモデルをデプロイするかどうかを決定するには、パイプラインの評価コンポーネントを利用します。Agent Platform の専用のバッチ予測コンポーネントを使用して、バッチ推論のデプロイを自動化できます。
マネージド スケーリング機能を活用する
- Agent Platform には、スケーリング動作を構成できるバッチ推論機能とオンライン推論機能が用意されています。
- Cloud Run は GPU の自動スケーリングをサポートしています。
Agent Platform エンドポイントでレイテンシとスループットを最適化する
- 適切なマシンタイプを選択します。
- モデルに適したエンドポイント タイプを選択します。専用のプライベート エンドポイントを使用すると、レイテンシを短縮できる場合があります。
- Feature Store を使用する場合は、Bigtable オンライン サービングを使用して高スループットと低レイテンシで特徴値を提供し、ベクトル検索を使用してエンベディングを提供します。
リソース使用率を最適化する
- リソース使用率を最適化するには、モデルのデプロイ間でリソースを共有します。モデルごとに個別の VM を使用する（デフォルトの動作）代わりに、1 つの VM に複数のモデルをデプロイできます。
- リソースの可用性を保証または最適化するには、予約、Dynamic Workload Scheduler、または Spot VM を使用します。
モデルのデプロイを最適化する
- 互換性を破る変更を回避するには、段階的な移行を行い、同じエンドポイントに複数のモデルを自動的にデプロイして A/B テストを実施します。Agent Platform はエンドポイント レイヤをモデルから切り離すため、モデル バージョン間でトラフィックを分割できます。
- デプロイされたモデルを置き換えるには、ローリング デプロイ戦略を使用します。
パフォーマンスの追跡
本番環境でのサービング パフォーマンスを向上させるには、Agent Platform エンドポイントのログと推論指標をモニタリングします。本番環境でのモデルの動作を把握するには、品質とパフォーマンスをモニタリングするツールが必要です。Agent Platform v2 の Model Monitoring を使用すると、モデルの複数のバージョンをモニタリングし、迅速に反復処理できます。
設計の選択をパフォーマンス要件に合わせて調整する
パフォーマンスを改善するために設計上の選択を行う場合は、その選択がビジネス要件をサポートするものであるか、逆効果になるかを評価します。適切なインフラストラクチャ、モデル、構成を選択するには、パフォーマンスのボトルネックを特定し、パフォーマンス指標とどのように関連しているかを評価します。たとえば、非常に強力な GPU アクセラレータでも、トレーニング タスクでパフォーマンスのボトルネックが発生する可能性があります。これらのボトルネックは、ストレージ レイヤのデータ I/O の問題や、モデルのパフォーマンス制限によって発生する可能性があります。
ML フローの全体的なパフォーマンスに焦点を当てる
モデルサイズとクラスタサイズの観点からトレーニング要件が増加すると、障害率とインフラストラクチャ費用が増加する可能性があります。したがって、障害のコストは二次的に増加する可能性があります。モデルの FLOP 使用率（MFU）などの従来のリソース効率指標だけに頼ることはできません。MFU がトレーニング全体のパフォーマンスの十分な指標にならない理由を理解するために、一般的なトレーニング ジョブのライフサイクルを調べてみましょう。ライフサイクルは、次の循環フローで構成されます。
- クラスタの作成: ワーカーノードがプロビジョニングされます。
- 初期化: ワーカーノードでトレーニングが初期化されます。
- トレーニングの実行: リソースは、フォワード プロパゲーションまたはバックワード プロパゲーションに使用されます。
- 中断: モデルのチェックポイント処理中、またはワーカーノードのプリエンプションにより、トレーニング プロセスが中断されます。
中断のたびに、前のフローが繰り返されます。
トレーニング実行ステップは、ML ジョブのライフサイクルの一部です。したがって、トレーニング実行ステップのワーカーノードの使用率は、ジョブの全体的な効率を示すものではありません。たとえば、トレーニング実行ステップが 100% の効率で実行されていても、中断が頻繁に発生したり、中断後にトレーニングを再開するのに時間がかかったりすると、全体的な効率が低下する可能性があります。
グッドプット指標を導入して追跡する
包括的なパフォーマンスの測定と最適化を実現するには、MFU などの従来のリソース効率指標からグッドプットに焦点を移します。グッドプットは、クラスタとコンピューティング リソースの可用性と使用率を考慮し、複数のレイヤにわたるリソース効率の測定に役立ちます。
グッドプット指標の焦点は、ジョブがビジー状態に見えるかどうかではなく、ジョブの全体的な進行状況です。グッドプット指標は、トレーニング ジョブを最適化して、生産性とパフォーマンスを全体的に向上させるのに役立ちます。
グッドプットを使用すると、次の指標を通じて、効率の潜在的な損失を詳細に把握できます。
- スケジューリング グッドプットは、トレーニングまたはサービングに必要なすべてのリソースが使用可能な時間の割合です。
- ランタイム グッドプットは、特定の期間に完了した有効なトレーニング ステップの割合を表します。
- プログラム グッドプットは、トレーニング ジョブがアクセラレータから抽出できるピーク ハードウェア パフォーマンスまたは MFU です。これは、トレーニング中に基盤となるコンピューティング リソースを効率的に利用できるかどうかに左右されます。
スケジューリング グッドプットを最適化する
ワークロードのスケジューリング グッドプットを最適化するには、ワークロードの特定のインフラストラクチャ要件を特定する必要があります。たとえば、バッチ推論、ストリーミング推論、トレーニングには異なる要件があります。
- バッチ推論ワークロードでは、リソースの可用性の中断や遅延が発生する可能性があります。
- ストリーミング推論ワークロードには、ステートレスなインフラストラクチャが必要です。
- トレーニング ワークロードには、長期的なインフラストラクチャのコミットメントが必要です。
適切な入手可能モードを選択する
クラウド コンピューティングにおける「取得可能性」とは、リソースが必要なときにプロビジョニングできる能力のことです。 Google Cloud には、次の取得可能性モードが用意されています。
- オンデマンド VM: 必要なときに Compute Engine VM をプロビジョニングし、VM でワークロードを実行します。プロビジョニング リクエストは、GPU などのリソースの可用性に応じて処理されます。リクエストされたリソースタイプが十分な量で使用できない場合、リクエストは失敗します。
- Spot VM: 未使用のコンピューティング容量を使用して VM を作成します。Spot VM は、オンデマンド VM と比較して割引料金で課金されますが、Google Cloud はいつでも Spot VM をプリエンプトする可能性があります。ホスト VM がプリエンプトされたときに正常に失敗するステートレス ワークロードには、Spot VM を使用することをおすすめします。
- 予約: VM のプールとして容量を予約します。予約は、容量の確保が必要なワークロードに最適です。予約を使用して、必要なときにリソースを確実に利用できるようにすることで、スケジューリング グッドプットを最大化します。
Dynamic Workload Scheduler: このプロビジョニング メカニズムは、GPU 搭載 VM のリクエストを専用プールにキューに入れます。Dynamic Workload Scheduler を使用すると、他の取得可能性モードの制約を回避できます。
- オンデマンド モードでの在庫切れの状況。
- Spot VM のステートレス制約とプリエンプションのリスク。
- 予約の費用と可用性への影響。
次の表に、 Google Cloudサービスの取得モードの概要と、関連ドキュメントへのリンクを示します。
| プロダクト | オンデマンド VM | Spot VM | 予約 | Dynamic Workload Scheduler |
|---|---|---|---|---|
| Compute Engine | Compute Engine インスタンスを作成して起動する | Spot VM について | 予約について | GPU VM を使用する MIG を作成する |
| GKE | ノードプールを追加して管理する | GKE の Spot VM について | 予約済みゾーンリソースの使用 | Flex Start プロビジョニングでの GPU、Cloud TPU、H4D の使用量 |
| バッチ | Job を作成して実行する | Spot VM を使用したバッチジョブ | VM 予約を使用してリソースの可用性を確保する | GPU と Flex Start VM を使用する |
| Agent Platform マネージド トレーニング | サーバーレス トレーニング ジョブを作成する | トレーニング ジョブに Spot VM を使用する | トレーニング ジョブに予約を使用する | リソースの可用性に基づいてトレーニング ジョブをスケジュールする |
| Agent Platform | カスタム トレーニング済みモデルからバッチ推論とオンライン推論を取得する。 | 推論に Spot VM を使用する | オンライン推論に予約を使用する | 推論に Flex Start VM を使用する |
メンテナンス イベントを計画する
インフラストラクチャのメンテナンスとアップグレードを予測して計画することで、スケジューリングのグッドプットを改善できます。
GKE では、クラスタで自動クラスタ メンテナンスを実行するタイミングを制御できます。詳細については、メンテナンスの時間枠と除外をご覧ください。
Compute Engine には次の機能があります。
- 基盤となるハードウェアの計画メンテナンスなどのホストイベント中にインスタンスを実行し続けるために、Compute Engine は同じゾーン内の別のホストへのインスタンスのライブ マイグレーションを実行します。詳細については、メンテナンス イベント中のライブ マイグレーション プロセスをご覧ください。
- 基盤となるホストでメンテナンスが必要になった場合やエラーが発生した場合にインスタンスがどのように応答するかを制御するには、インスタンスにホスト メンテナンス ポリシーを設定します。
AI Hypercomputer の大規模なトレーニング クラスタに関連するホストイベントの計画については、コンピューティング インスタンス間でホストイベントを管理するをご覧ください。
ランタイム グッドプットを最適化する
モデルのトレーニング プロセスは、モデルのチェックポイント設定やリソースのプリエンプションなどのイベントによって頻繁に中断されます。ランタイム グッドプットを最適化するには、必要なインフラストラクチャが準備された後、および中断後に、システムがトレーニングと推論を効率的に再開できるようにする必要があります。
モデルのトレーニング中に、AI 研究者はチェックポイントを使用して進捗状況を追跡し、リソースのプリエンプションによる学習の損失を最小限に抑えます。モデルサイズが大きくなると、チェックポイントの中断時間が長くなり、全体的な効率にさらに影響します。中断後、トレーニング アプリケーションはクラスタ内のすべてのノードで再起動する必要があります。必要なアーティファクトを再読み込みする必要があるため、これらの再起動には時間がかかることがあります。
ランタイム グッドプットを最適化するには、次の手法を使用します。
| 手法 | 説明 |
|---|---|
| 自動チェックポイントを実装する。 | 頻繁にチェックポイントを作成すると、トレーニングの進行状況を詳細に追跡できます。ただし、トレーニング プロセスはチェックポイントごとに中断されるため、ランタイム グッドプットが低下します。中断を最小限に抑えるには、自動チェックポイントを設定します。これにより、ホストの SIGTERM シグナルによってチェックポイントの作成がトリガーされます。このアプローチでは、チェックポイントの中断はホストのメンテナンスが必要な場合に限定されます。ハードウェア障害によっては SIGTERM シグナルがトリガーされない場合があるため、自動チェックポイントと SIGTERM イベントの適切なバランスを見つける必要があります。 自動チェックポイントは、次の手法を使用して設定できます。
|
| 適切なコンテナ読み込み戦略を使用する。 | GKE クラスタでは、ノードがトレーニング ジョブを再開する前に、データやモデル チェックポイントなどの必要なアーティファクトの読み込みが完了するまでに時間がかかることがあります。データの再読み込みとトレーニングの再開に必要な時間を短縮するには、次の手法を使用します。
|
| コンパイル キャッシュを使用します。 | トレーニングにコンパイルベースのスタックが必要な場合は、コンパイル キャッシュを使用できるかどうかを確認します。コンパイル キャッシュを使用すると、トレーニングが中断されるたびに計算グラフが再コンパイルされることはありません。その結果、時間とコストが削減され、Cloud TPU を使用する場合に特に有益です。JAX を使用すると、コンパイル キャッシュを Cloud Storage バケットに保存し、中断が発生した場合にキャッシュに保存されたデータを使用できます。 |
プログラムのグッドプットを最適化する
プログラム グッドプットは、トレーニング中のピーク リソース使用率を表します。これは、トレーニングとサービングの効率を測定する従来の方法です。プログラムのグッドプットを改善するには、最適化された分散戦略、効率的なコンピューティングと通信のオーバーラップ、最適化されたメモリアクセス、効率的なパイプラインが必要です。
プログラムのグッドプットを最適化するには、次の戦略を使用します。
| 戦略 | 説明 |
|---|---|
| フレームワーク レベルのカスタマイズ オプションを使用する。 | Accelerated Linear Algebra（XLA）などのフレームワークやコンパイラは、プログラムのグッドプットの多くの主要コンポーネントを提供します。パフォーマンスをさらに最適化するには、計算グラフの基本コンポーネントをカスタマイズします。たとえば、Pallas は Cloud TPU と GPU のカスタム カーネルをサポートしています。 |
| メモリをホスト DRAM にオフロードする。 | アクセラレータから非常に高いメモリを必要とする大規模なトレーニングでは、メモリ使用量の一部をホスト DRAM にオフロードできます。たとえば、JAX と XLA を使用すると、アクセラレータのメモリを使用する代わりに、フォワードパスからホストメモリにモデルの活性化をオフロードできます。この戦略では、モデル容量またはバッチサイズを増やすことで、トレーニングのパフォーマンスを向上させることができます。 |
| トレーニング中に量子化を活用する。 | トレーニング中にモデルの量子化を活用することで、トレーニング効率とプログラムのグッドプットを向上させることができます。この戦略では、トレーニングの特定のステップで勾配または重みの精度が低下するため、プログラムのグッドプットが向上します。ただし、この戦略では、モデルの開発中に追加のエンジニアリング作業が必要になる場合があります。 詳しくは、次のリソースをご覧ください。 |
| 並列処理を実装する。 | 利用可能なコンピューティング リソースの使用率を高めるには、トレーニング中とデータの読み込み時にモデルレベルで並列処理戦略を使用します。 モデル並列処理の詳細については、以下をご覧ください。 データ並列処理を実現するには、次のようなツールを使用します。
|
ワークロード固有の要件に重点を置く
パフォーマンス最適化の取り組みが効果的かつ包括的になるようにするには、最適化の決定をトレーニング ワークロードと推論ワークロードの特定の要件に合わせる必要があります。適切な AI モデルを選択し、関連するプロンプト最適化戦略を使用します。ワークロードの要件に基づいて、適切なフレームワークとツールを選択します。
ワークロード固有の要件を特定する
次の領域でワークロードの要件と制約を評価します。
| 地域 | 説明 |
|---|---|
| タスクと品質の要件 | ワークロードのコアタスクとパフォーマンス ベースラインを定義します。次のような質問に回答します。
|
| サービス提供のコンテキスト | モデルをデプロイする運用環境を分析します。サービング コンテキストは、設計上の決定に大きな影響を与えることがよくあります。次の点を考慮してください。
|
| チームのスキルと経済性 | ソリューションを購入することのビジネス価値を、ソリューションの構築と維持にかかる費用と複雑さと比較して評価します。カスタムモデルの開発に必要な専門スキルがチームにあるかどうか、またはマネージド サービスによって価値実現までの時間を短縮できるかどうかを判断します。 |
適切なモデルを選択する
API またはオープンモデルが必要なパフォーマンスと品質を提供できる場合は、その API またはモデルを使用します。
光学式文字認識（OCR）、ラベル付け、コンテンツ モデレーションなどのモダリティ固有のタスクの場合は、次のような ML API を選択します。
生成 AI アプリケーションの場合は、Gemini、Imagen、Veo などの Google モデルを検討してください。
Model Garden を確認し、Google の基盤モデルとタスク固有モデルの厳選されたコレクションから選択します。Model Garden は、Gemma などのオープンモデルやサードパーティ モデルも提供しています。これらのモデルは、Agent Platform で実行することも、GKE などのランタイムにデプロイすることもできます。
ML API または生成 AI モデルを使用してタスクを完了できる場合は、タスクの複雑さを考慮してください。複雑なタスクの場合、Gemini などの大規模なモデルは、小規模なモデルよりも高いパフォーマンスを発揮する可能性があります。
プロンプトを改善して品質を向上させる
プロンプトの品質を大規模に向上させるには、Agent Platform プロンプト オプティマイザーを使用します。システム指示やプロンプトを手動で書き直す必要はありません。プロンプト オプティマイザーは、次のアプローチをサポートしています。
- ゼロショット最適化: 単一のプロンプトまたはシステム指示をリアルタイムで改善する低レイテンシのアプローチ。
- データドリブン最適化: 特定の評価指標に基づいてサンプル プロンプトに対するモデルのレスポンスを評価することで、プロンプトを改善する高度なアプローチ。
プロンプトの最適化に関するその他のガイドラインについては、プロンプト戦略の概要をご覧ください。
ML エンドポイントと生成 AI エンドポイントのパフォーマンスを向上させる
ML エンドポイントと生成 AI エンドポイントのレイテンシまたはスループット（1 秒あたりのトークン数）を改善するには、次の推奨事項を検討してください。
- Memorystore を使用して結果をキャッシュに保存する。
- 生成 AI API の場合は、次の手法を使用します。
- コンテキスト キャッシュ保存: 繰り返されるコンテンツを含むリクエストのレイテンシを短縮します。
- プロビジョンド スループット: スループット容量を予約して、Gemini エンドポイントのスループットを向上させます。
- セルフホスト型モデルの場合は、次の最適化された推論フレームワークを検討してください。
フレームワーク ノートブックとガイド Model Garden の最適化された vLLM コンテナ ビルド済みコンテナを使用してオープンモデルをデプロイする GKE での GPU ベースの推論 Cloud TPU ベースの推論
ローコード ソリューションとチューニングを使用する
事前トレーニング済みモデルが要件を満たしていない場合は、次のソリューションを使用して、特定のドメインのパフォーマンスを向上させることができます。
- AutoML は、幅広いタスクで最小限の技術的な作業で推論結果を改善するローコード ソリューションです。AutoML を使用すると、アーキテクチャ、パフォーマンス、トレーニング ステージ（チェックポイントを使用）など、複数のディメンションで最適化されたモデルを作成できます。
- チューニングを使用すると、短いプロンプトで、大量のデータを使用せずに、より高品質で安定した生成と低レイテンシを実現できます。ハイパーパラメータのデフォルト値を使用してチューニングを開始することをおすすめします。詳細については、Gemini の教師ありファインチューニングについてをご覧ください。
セルフマネージド トレーニングを最適化する
場合によっては、モデルを再トレーニングするか、ファインチューニング ジョブをフルマネージドで管理することを選択できます。このアプローチでは、使用するモデル、フレームワーク、リソースに応じて、高度なスキルと追加の時間が必要になります。
次のようなパフォーマンスが最適化されたフレームワーク オプションを活用します。
最新のソフトウェア依存関係とGoogle Cloud固有のライブラリを含むディープ ラーニング イメージまたはコンテナを使用します。
Google Cloudで Ray を使用してモデル トレーニングを実行します。
- Gemini Enterprise Agent Platform の Ray を使用すると、Ray の分散トレーニング フレームワークを Compute Engine または GKE に導入でき、フレームワークの管理オーバーヘッドを簡素化できます。
- 既存のクラスタに Ray オペレーターをデプロイすることで、KubeRay を使用して GKE 上の Ray をセルフマネージドできます。
オープンソースの Cluster Toolkit を使用してプロビジョニングしたコンピューティング クラスタにトレーニング ワークロードをデプロイします。パフォーマンスが最適化されたクラスタを効率的にプロビジョニングするには、YAML ベースのブループリントを使用します。Slurm や GKE などのスケジューラを使用してクラスタを管理します。
GPU に最適化されたレシピを使用して、標準モデル アーキテクチャをトレーニングします。
次の手法を使用して、パフォーマンスを最適化するトレーニング アーキテクチャと戦略を構築します。
- Agent Platform または前述のフレームワークに分散トレーニングを実装します。分散トレーニングでは、モデル並列処理とデータ並列処理が可能になります。これにより、トレーニング データセットのサイズとモデルサイズを増やし、トレーニング時間を短縮できます。
- 効率的なモデル トレーニングと、さまざまなパフォーマンス構成を試すには、適切な間隔でチェックポイントを実行します。詳細については、ランタイム グッドプットを最適化するをご覧ください。
セルフマネージド サービングを最適化する
セルフマネージド サービングでは、効率的な推論オペレーションと高スループット（単位時間あたりの推論数）が必要です。
推論用にモデルを最適化するには、次のアプローチを検討してください。
量子化: パラメータを精度の低い形式で表すことで、モデルサイズを縮小します。このアプローチは、メモリ消費量とレイテンシを削減するのに役立ちます。ただし、トレーニング後の量子化はモデルの品質に影響する可能性があります。たとえば、トレーニング後の量子化により、精度が低下する可能性があります。
- トレーニング後の量子化（PTQ）は、繰り返し可能なタスクです。PyTorch や TensorFlow などの主要な ML フレームワークは PTQ をサポートしています。
- Agent Platform Pipelines のパイプラインを使用して、PTQ をオーケストレートできます。
- モデルのパフォーマンスを安定させ、モデルサイズの削減によるメリットを得るには、Qwix を使用します。
テンソル並列処理: 計算の負荷を複数の GPU に分散することで、推論のスループットを向上させます。
メモリの最適化: スループットを向上させ、アテンション キャッシュ、バッチサイズ、入力サイズを最適化します。
次のような推論に最適化されたフレームワークを使用します。
- 生成モデルの場合は、MaxText、MaxDiffusion、vLLM などのオープン フレームワークを使用します。
- 予測と説明のために、Agent Platform でビルド済みコンテナ イメージを実行します。TensorFlow を選択した場合は、最適化された TensorFlow ランタイムを使用します。このランタイムを使用すると、オープンソースの TensorFlow を使用するビルド済みコンテナよりも効率的で低コストの推論が可能になります。
- Pathways を使用してマルチホスト推論を実行する。
- Agent Platform に NVIDIA Triton 推論サーバーを活用する。
- LLM に最適化された構成を使用して、GKE での推論ワークロードのデプロイを簡素化します。詳細については、GKE Inference Quickstart を使用してモデル提供のパフォーマンスと費用を分析するをご覧ください。
パフォーマンスの目標に基づいてリソース消費を最適化する
リソースの最適化は、トレーニングの高速化、効率的なイテレーション、モデルの品質向上、サービング容量の増加に役立ちます。
適切なプロセッサ タイプを選択する
コンピューティング プラットフォームの選択は、モデルのトレーニング効率に大きな影響を与える可能性があります。
- ディープ ラーニング モデルは、大量のメモリと並列行列計算を必要とするため、GPU と Cloud TPU で適切に動作します。CPU、GPU、Cloud TPU に適したワークロードの詳細については、Cloud TPU を使用するタイミングをご覧ください。
- コンピューティング最適化 VM は、HPC ワークロードに最適です。
GPU でのトレーニングとサービングを最適化する
GPU にデプロイされたトレーニング ワークロードと推論ワークロードのパフォーマンスを最適化するには、次の推奨事項を検討してください。
| 推奨事項 | 説明 |
|---|---|
| 適切なメモリ仕様を選択する。 | GPU マシンタイプを選択する場合は、次の要素に基づいてメモリ仕様を選択します。
|
| コアとメモリの帯域幅の要件を評価する。 | メモリサイズに加えて、Tensor コアの数やメモリ帯域幅などの他の要件も考慮してください。これらの要因は、チップ上のデータアクセスと計算の速度に影響します。 |
| 適切な GPU マシンタイプを選択する。 | トレーニングとサービングでは、異なる GPU マシンタイプが必要になる場合があります。
トレーニングには大規模なマシンタイプを使用し、推論には費用対効果の高い小規模なマシンタイプを使用することをおすすめします。リソース使用率の問題を検出するには、NVIDIA DCGM エージェントなどのモニタリング ツールを使用して、リソースを適切に調整します。 |
| GKE で GPU 共有を活用する。 | 1 つのコンテナに GPU 全体を割り当てることは、場合によっては非効率的なアプローチになることがあります。この非効率性を克服するために、GKE は次の GPU 共有戦略をサポートしています。
リソースの使用率を最大化するには、これらの戦略を適切に組み合わせて使用することをおすすめします。たとえば、GPU タイム シェアリングとマルチインスタンス GPU 戦略を使用して大規模な H100 GPU を仮想化すると、サービング プラットフォームはトラフィックに基づいてスケールアップとスケールダウンを行うことができます。GPU リソースは、モデルコンテナの負荷に基づいてリアルタイムで再利用されます。 |
| ルーティングとロード バランシングを最適化する。 | クラスタに複数のモデルをデプロイする場合は、GKE Inference Gateway を使用して、最適化されたルーティングとロード バランシングを行うことができます。Inference Gateway は、次の機能を使用して Kubernetes Gateway API のルーティング メカニズムを拡張します。
|
| Agent Platform エンドポイントのリソースを共有する。 | 複数の Agent Platform エンドポイントを構成して、共通のリソースプールを使用できます。この機能とその制限事項の詳細については、デプロイ間でリソースを共有するをご覧ください。 |
Cloud TPU でのトレーニングとサービングを最適化する
Cloud TPU は、ML アルゴリズムの大規模な課題を解決するのに役立つ Google チップを提供します。これらのチップは、AI トレーニングと推論ワークロードに最適なパフォーマンスを提供します。GPU と比較すると、Cloud TPU はディープ ラーニングのトレーニングとサービングの効率が向上します。Cloud TPU に適したユースケースについては、Cloud TPU を使用する場面をご覧ください。Cloud TPU は、TensorFlow、PyTorch、JAX などの ML フレームワークと互換性があります。
Cloud TPU のパフォーマンスを最適化するには、Cloud TPU パフォーマンス ガイドで説明されている次の手法を使用します。
- 各 Cloud TPU メモリユニットのバッチサイズを最大化します。
- Cloud TPU リソースがアイドル状態になっていないことを確認します。たとえば、並列データ読み取りを実装します。
- XLA コンパイラを最適化します。必要に応じてテンソルのディメンションを調整し、パディングを回避します。XLA は、融合やブロードキャストなどのツールを使用して、Graph Execution のパフォーマンスを自動的に最適化します。
Cloud TPU でのトレーニングと GPU でのサービングを最適化する
Cloud TPU は効率的なトレーニングをサポートしています。GPU は、推論ワークロードに汎用性と幅広い可用性を提供します。Cloud TPU と GPU の強みを組み合わせるには、Cloud TPU でモデルをトレーニングし、GPU でモデルをサービングします。このアプローチは、特に大規模なモデルの場合、全体的なコストの削減と開発の加速に役立ちます。Cloud TPU と GPU マシンタイプを使用できるロケーションについては、Cloud TPU のリージョンとゾーンと GPU のロケーションをご覧ください。
ストレージ レイヤを最適化する
トレーニングとサービングのインフラストラクチャのストレージ レイヤは、パフォーマンスに不可欠です。トレーニング ジョブと推論ワークロードには、次のストレージ関連のアクティビティが含まれます。
- データの読み込みと処理。
- トレーニング中にモデルのチェックポイントを作成する。
- ノードのプリエンプション後にトレーニングを再開するためにバイナリを再読み込みする。
- モデルを効率的に読み込んで、大規模な推論を処理する。
ストレージ容量、帯域幅、レイテンシの要件は、次の要因によって決まります。
- モデルの規模
- トレーニング データセットの量
- チェックポイント処理の頻度
- スケーリング パターン
トレーニング データが Cloud Storage にある場合は、Cloud Storage FUSE のファイル キャッシュを使用して、データの読み込みレイテンシを短縮できます。Cloud Storage FUSE を使用すると、ローカル SSD ディスクを持つコンピューティング ノードに Cloud Storage バケットをマウントできます。Cloud Storage FUSE のパフォーマンスを向上させる方法については、パフォーマンス調整のベスト プラクティスをご覧ください。
Cloud Storage への PyTorch コネクタは、データの読み取りと書き込みで高いパフォーマンスを実現します。このコネクタは、大規模なデータセットを使用したトレーニングや、大規模なモデルのチェックポイント処理に特に役立ちます。
Compute Engine は、さまざまな Persistent Disk タイプをサポートしています。Google Cloud Hyperdisk ML を使用すると、トレーニングのニーズに基づいて必要なスループットと IOPS をプロビジョニングできます。ディスクのパフォーマンスを最適化するには、まずディスクのサイズを変更してから、マシンタイプの変更を検討します。詳細については、Persistent Disk のパフォーマンスを最適化するをご覧ください。ストレージ レイヤで読み取り / 書き込みのパフォーマンスとレイテンシの負荷テストを行うには、Flexible I/O テスター（FIO）などのツールを使用します。
AI / ML ワークロードのストレージ サービスの選択と最適化の詳細については、AI Hypercomputer の AI / ML ワークロードのストレージ サービスの概要をご覧ください。
ネットワーク層を最適化する
AI ワークロードと ML ワークロードのパフォーマンスを最適化するには、十分な帯域幅と最大スループットを最小限のレイテンシで提供するように VPC ネットワークを構成します。以下の推奨事項を参考にしてください。
| 推奨事項 | 実装に推奨される手法 |
|---|---|
| VPC ネットワークを最適化する。 |
|
| VM を相互に近い場所に配置する。 |
|
| より高いネットワーク速度をサポートするように VM を構成します。 |
|
パフォーマンス指標を設計と構成の選択にリンクする
パフォーマンスの問題を改善、トラブルシューティング、調査するには、設計の選択とパフォーマンスの結果の間に明確な関連性を確立する必要があります。ML アセット、デプロイ、モデル出力、出力を生成した対応する構成と入力のリネージについて信頼性のある記録が必要です。
データとモデルのリネージ システムを構築する
パフォーマンスを確実に向上させるには、すべてのモデル バージョンを、モデルの作成に使用された正確なデータ、コード、構成にトレースできる必要があります。モデルをスケーリングすると、このようなトレースが困難になります。トレース プロセスを自動化し、すべてのテストでクエリ可能な明確なレコードを作成するリネージ システムが必要です。このシステムにより、チームは最適なパフォーマンスのモデルにつながる選択を効率的に特定して再現できます。
Agent Platform のワークロードのパイプライン アーティファクトのリネージを表示して分析するには、Agent Platform ML Metadata または Knowledge Catalog を使用します。どちらのオプションでも、ガバナンス要件を満たすようにイベントまたはアーティファクトを登録し、必要に応じてメタデータをクエリして情報を取得できます。このセクションでは、2 つのオプションの概要について説明します。Agent Platform ML Metadata と Knowledge Catalog の違いの詳細については、パイプライン アーティファクトのリネージを追跡するをご覧ください。
デフォルトの実装: Agent Platform ML Metadata
Agent Platform で最初のパイプライン実行またはテストを行うと、デフォルトの Agent Platform ML Metadata サービスが作成されます。パイプラインが使用および生成するパラメータとアーティファクト メタデータは、Agent Platform ML Metadata ストアに自動的に登録されます。保存されたメタデータの整理と接続に使用されるデータモデルには、次の要素が含まれています。
- コンテキスト: テストの実行を表すアーティファクトと実行のグループ。
- 実行: ワークフローのステップ（データの検証やモデルのトレーニングなど）。
- アーティファクト: ワークフローが生成して使用する入力または出力のエンティティ、オブジェクト、またはデータ。
- イベント: アーティファクトと実行の関係。
デフォルトでは、Agent Platform ML Metadata はパイプライン実行のすべての入力アーティファクトと出力アーティファクトをキャプチャして追跡します。これらのアーティファクトは、Agent Platform の Experiments、Model Registry、Agent Platform マネージド データセットと統合されます。
自動ロギングは、Agent Platform マネージド トレーニングの組み込み機能で、Agent Platform の Experiments にデータを自動的にロギングします。パフォーマンスを最適化するためにテストを効率的に追跡するには、Agent Platform のテストと、関連する Agent Platform ML Metadata サービスとの組み込みインテグレーションを使用します。
Agent Platform ML Metadata には、アーティファクト、実行、コンテキストに関するクエリを実行するためのフィルタリング構文と演算子が用意されています。必要に応じて、チームはモデルのレジストリリンクとそのデータセット、または特定のテスト実行の評価に関する情報を効率的に取得できます。このメタデータは、パフォーマンスを最適化する選択肢の発見を加速するのに役立ちます。たとえば、パイプライン実行の比較、モデルの比較、テスト実行の比較を行うことができます。クエリの例などの詳細については、メタデータを分析するをご覧ください。
代替実装: Knowledge Catalog
Knowledge Catalog は、Agent Platform アーティファクトを含む Google Cloud リソースからメタデータを検出します。カスタム データソースを統合することもできます。
Knowledge Catalog は、複数のリージョンと組織全体のストアにわたってメタデータを読み取ることができます。一方、Agent Platform ML Metadata はプロジェクト固有のリソースです。Agent Platform ML Metadata と比較すると、Knowledge Catalog の方が設定に手間がかかります。ただし、 Google Cloud のより広範なデータ ポートフォリオや組織全体のストアとの統合が必要な場合は、Knowledge Catalog が適している可能性があります。
Knowledge Catalog は、Data Lineage API が有効になっているプロジェクトのメタデータを検出して収集します。カタログ内のメタデータは、プロジェクト、エントリ グループ、エントリ、アスペクトで構成されるデータモデルを使用して整理されます。Knowledge Catalog には、アーティファクトの検出に使用できる特定の構文が用意されています。必要に応じて、メタデータ アーティファクトをマッピングして Knowledge Catalog に登録できます。
説明可能性ツールを使用する
AI モデルの動作は、モデルのトレーニングに使用されたデータに基づいています。この動作は、数学関数のパラメータとしてエンコードされます。モデルが特定の方法で動作する理由を正確に理解することは困難です。ただし、この知識はパフォーマンスの最適化に不可欠です。
たとえば、トレーニング データに赤い車の画像のみが含まれている画像分類モデルについて考えてみましょう。モデルは、オブジェクトの空間属性や形状属性ではなく、オブジェクトの色に基づいて「車」ラベルを識別することを学習する可能性があります。異なる色の車を示す画像でモデルをテストすると、モデルのパフォーマンスが低下する可能性があります。以降のセクションでは、このような問題を特定して診断するために使用できるツールについて説明します。
データバイアスを検出する
ML プロジェクトの探索的データ分析（EDA）フェーズでは、クラス不均衡なデータセットやバイアスなど、データに関する問題を特定します。
本番環境システムでは、多くの場合、モデルを再トレーニングし、異なるデータセットでテストを実行します。データを標準化し、テスト間で比較するには、次の特性を含む EDA への体系的なアプローチをおすすめします。
- 自動化: トレーニング セットのサイズが大きくなるにつれて、EDA プロセスをバックグラウンドで自動的に実行する必要があります。
- 幅広いカバレッジ: 新しい機能を追加する場合、EDA は新しい機能に関する分析情報を明らかにする必要があります。
EDA タスクの多くは、データ型とビジネス コンテキストに固有のものです。EDA プロセスを自動化するには、BigQuery または Dataflow などのマネージド データ処理サービスを使用します。詳細については、不均衡なデータの分類と Agent Platform のデータバイアス指標をご覧ください。
モデルの特性と動作を理解する
トレーニング セットと検証セットのデータの分布とそのバイアスを理解するだけでなく、予測時のモデルの特性と動作を理解する必要があります。モデルの動作を理解するには、次のツールを使用します。
| ツール | 説明 | 目的 |
|---|---|---|
| 例ベースの説明 | 例ベースの説明または最近傍探索を使用すると、トレーニング データから最も類似した例を見つけて予測を理解できます。このアプローチは、類似した入力からは類似した出力が得られるという原則に基づいています。 |
|
| 特徴ベースの説明 | 表形式データまたは画像に基づく予測の場合、特徴ベースの説明は、ベースラインと比較したときに各特徴が予測にどの程度影響するかを示します。 説明可能性手法と表形式の説明では、モデルタイプとタスクに応じて特徴アトリビューション メソッドが提供されます。通常、これらの手法はサンプリングと感度分析に依存して、入力特徴の変化に応じて出力がどの程度変化するかを測定します。 |
|
| What-If ツール | What-If ツールは、Google の People + AI Research（PAIR）イニシアチブによって開発されたもので、画像モデルと表形式モデルの動作を理解して可視化するのに役立ちます。このツールの使用例については、What-If ツールのウェブデモをご覧ください。 |
|
寄稿者
著者:
- Benjamin Sadik | AI および ML スペシャリスト カスタマー エンジニア
- Filipe Gracio, PhD | カスタマー エンジニア兼 AI / ML スペシャリスト
その他の寄稿者:
- Daniel Lees | クラウド セキュリティ アーキテクト
- Kumar Dhanagopal | クロス プロダクト ソリューション デベロッパー