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