AI と ML の視点: 信頼性

Google Cloud Well-Architected Framework: AI と ML の視点のこのドキュメントでは、 Google Cloudで信頼性の高い AI システムと ML システムを設計して運用するための原則と推奨事項の概要について説明します。高度な信頼性プラクティスとオブザーバビリティをアーキテクチャ ブループリントに統合する方法について説明します。このドキュメントの推奨事項は、 Google Cloud Well-Architected Framework の信頼性の柱に沿っています。

AI と ML の状況が急速に変化する中、顧客満足度を確保し、ビジネス目標を達成するには、信頼性の高いシステムが不可欠です。予測 ML と生成 AI の両方の独自のニーズを満たすには、堅牢で信頼性が高く、適応性のある AI システムと ML システムが必要です。開発からデプロイ、継続的な改善まで、MLOps の複雑さを処理するには、信頼性を重視したアプローチを使用する必要があります。 Google Cloud は、サイト信頼性エンジニアリング（SRE）の原則に沿って構築された専用の AI インフラストラクチャを提供し、信頼性の高い AI システムと ML システムの強力な基盤を提供します。

この記事の推奨事項は、次の基本原則にマッピングされています。

• インフラストラクチャがスケーラブルで可用性が高いことを確認する
• モジュール式で疎結合のアーキテクチャを使用する
• 自動化されたエンドツーエンドの MLOps プラットフォームを構築する
• データとモデルのガバナンスを通じて信頼と制御を維持する
• 包括的なオブザーバビリティと信頼性のプラクティスを実装する

ML インフラストラクチャがスケーラブルで可用性が高いことを確認する

クラウドで信頼性の高い AI システムと ML システムを実現するには、スケーラブルで可用性の高いインフラストラクチャが必要です。これらのシステムには、動的な需要、多様なリソースのニーズ、モデルの可用性に対する重要な依存関係があります。スケーラブルなアーキテクチャは、負荷の変動やデータ量または推論リクエストの変動に適応します。高可用性（HA）は、コンポーネント、ゾーン、リージョンのレベルで障害に対する復元力を確保するのに役立ちます。

スケーラブルで可用性の高い ML インフラストラクチャを構築するには、次の推奨事項を検討してください。

自動的かつ動的なスケーリング機能を実装する

AI と ML のワークロードは動的であり、データ到着率、トレーニング頻度、推論トラフィックの量に基づいて需要が変動します。自動的かつ動的なスケーリングにより、インフラストラクチャ リソースを需要の変動にシームレスに適応させることができます。ワークロードを効果的にスケーリングすると、ダウンタイムの防止、パフォーマンスの維持、費用の最適化に役立ちます。

AI / ML ワークロードを自動スケーリングするには、 Google Cloudで次のプロダクトと機能を使用します。

• データ処理パイプライン: Dataflow でデータ パイプラインを作成します。Dataflow の水平自動スケーリング機能を使用するようにパイプラインを構成します。この機能は、CPU 使用率、パイプラインの並列処理、保留中のデータに基づいてワーカー インスタンスの数を動的に調整します。ジョブの起動時に、パイプライン オプションを使用して自動スケーリング パラメータを構成できます。
• トレーニング ジョブ: Vertex AI カスタム トレーニングを使用して、トレーニング ジョブのスケーリングを自動化します。マシンタイプ、アクセラレータのタイプと数、ワーカープールの数などのワーカープールの仕様を定義できます。中断を許容できるジョブや、トレーニング コードでチェックポイントが実装されているジョブでは、Spot VM を使用してコストを削減できます。
• オンライン推論: オンライン推論には、Vertex AI エンドポイントを使用します。自動スケーリングを有効にするには、最小レプリカ数と最大レプリカ数を構成します。HA 用に 2 つ以上のレプリカを指定します。Vertex AI は、トラフィックと構成された自動スケーリング指標（CPU 使用率やレプリカ使用率など）に基づいて、レプリカの数を自動的に調整します。
• Google Kubernetes Engine のコンテナ化されたワークロード: ノードレベルと Pod レベルで自動スケーリングを構成します。クラスタ オートスケーラーとノード自動プロビジョニングを構成して、CPU、メモリ、GPU、TPU などの保留中の Pod リソース リクエストに基づいてノード数を調整します。デプロイに HorizontalPodAutoscaler（HPA）を使用して、CPU やメモリ使用率などの指標に基づいてスケーリング ポリシーを定義します。また、GPU や TPU の使用率、1 秒あたりの予測リクエスト数など、AI と ML のカスタム指標に基づいてスケーリングすることもできます。
• サーバーレス コンテナ化サービス: Cloud Run にサービスをデプロイし、コンテナ インスタンスの最小数と最大数を指定して自動スケーリングを構成します。ベスト プラクティスを使用して、アクセラレータ タイプを指定して GPU 対応インスタンスを自動スケーリングします。Cloud Run は、構成された最小値と最大値の間で、受信リクエストに基づいてインスタンスを自動的にスケーリングします。リクエストがない場合は、インスタンス数をゼロに効率的にスケーリングします。Cloud Run の自動リクエスト駆動型スケーリングを活用して、Vertex AI エージェントをデプロイし、Ollama を使用した量子化モデル、vLLM を使用した LLM モデル推論、Huggingface Text Generation Inference（TGI）などのサードパーティ ワークロードをデプロイできます。

HA とフォールト トレランスを考慮した設計

本番環境グレードの AI ワークロードと ML ワークロードでは、継続的な運用と障害に対する復元力を確保することが重要です。HA とフォールト トレランスを実装するには、 Google Cloudのアーキテクチャに冗長性とレプリケーションを組み込む必要があります。このアプローチにより、個々のコンポーネントの障害がシステム全体の障害を引き起こさないようにすることができます。

• モデル サービングの HA と低レイテンシ（特にリアルタイム推論と生成 AI モデルの場合）を実現するには、複数のロケーションにデプロイを分散します。
• グローバルな可用性と復元力を実現するには、 Google Cloud リージョンにまたがる複数の Vertex AI エンドポイントにモデルをデプロイするか、グローバル エンドポイントを使用します。
• グローバル ロード バランシングを使用してトラフィックを転送します。
• GKE または Compute Engine MIG でトレーニングを行う場合は、Xid エラーのモニタリングを実装します。Xid エラーを特定したら、適切な是正措置を講じます。たとえば、GPU をリセットする、Compute Engine インスタンスをリセットする、gcloud CLI report faulty host コマンドを使用してハードウェア交換をトリガーするなどです。
• Google Resiliency Library を使用するレシピや、TPU ワークロード用の Pathways を使用した復元力のあるトレーニング ロジックの統合など、フォールト トレラントまたは弾力性のある復元力のあるトレーニング ソリューションをご覧ください。

Google Cloudで重要な AI コンポーネントと ML コンポーネントの冗長性を実装します。リソースの冗長性を実装できるプロダクトと機能の例を次に示します。

• 複数のゾーンに GKE リージョン クラスタをデプロイします。
• Cloud Storage のマルチリージョン バケットまたはデュアルリージョン バケットを使用して、データセットとチェックポイントのデータ冗長性を確保します。
• メタデータのグローバルに一貫性のある高可用性ストレージには、Spanner を使用します。
• 運用データベース用に Cloud SQL リードレプリカを構成します。
• 検索拡張生成（RAG）用のベクトル データベースが高可用性で、マルチゾーンまたはマルチリージョンであることを確認します。

リソースを事前に管理し、要件を予測する

リソースを効果的に管理することは、費用、パフォーマンス、信頼性を最適化するうえで重要です。AI と ML のワークロードは動的であり、GPU や TPU などの特殊なハードウェアに対する需要が高くなっています。そのため、事前対応型のリソース管理を適用し、リソースの可用性を確保することが重要です。

Cloud Monitoring の GPU や TPU の使用率とスループット率などの過去のモニタリング データと、Cloud Logging のログに基づいて容量を計画します。BigQuery または Looker Studio を使用してこのテレメトリー データを分析し、成長または新しいモデルに基づいて GPU の将来の需要を予測します。リソース使用パターンの分析と傾向の分析により、重要な専用アクセラレータが必要になるタイミングと場所を予測できます。

• 厳格な負荷テストを実施して、容量の見積もりを検証します。Apache JMeter や LoadView などのツールを使用して、サービングやパイプラインなどの AI サービスと ML サービスのトラフィックをシミュレートします。
• ストレス下でのシステムの動作を分析します。
  • 本番環境でワークロードの需要が増加することを予測して対応するには、リソース要件を事前に特定します。レイテンシ、スループット、エラー、リソース使用率（特に GPU と TPU の使用率）をモニタリングします。必要に応じてリソース割り当てを増やします。
  • 生成 AI サービングの場合は、同時実行負荷が高い状態でテストし、アクセラレータの可用性がパフォーマンスを制限するレベルを特定します。
• モデルクエリの継続的モニタリングを実施し、エージェントのプロアクティブなアラートを設定します。
  • モデルのオブザーバビリティ ダッシュボードを使用して、Cloud Monitoring によって収集された指標（モデルの秒間クエリ数（QPS）、トークン スループット、最初のトークン レイテンシなど）を表示します。

リソースの可用性と取得可能性を最適化する

ワークロードの要件に基づいて適切なコンピューティング リソースを戦略的に選択することで、コストを最適化し、リソースの可用性を確保します。

• 安定した 24 時間 365 日の推論や、容量要件が固定または予測可能なトレーニング ワークロードには、VM とアクセラレータに確約利用割引（CUD）を使用します。

• GKE ノードと Compute Engine VM の場合は、スポット VM と Dynamic Workload Scheduler（DWS）機能を使用します。

  • 評価や試験運用などのフォールト トレラントなタスクには、Spot VM を使用します。Spot VM はプリエンプトされる可能性がありますが、全体的なコストの削減に役立ちます。
  • 需要の高いアクセラレータのプリエンプション リスクを管理するには、DWS を使用して入手可能性を高めることができます。
    • 最大 7 日間の実行にハイエンド GPU が必要な複雑なバッチ トレーニングには、DWS Flex-Start モードを使用します。
    • 最大 3 か月間実行される長時間実行ワークロードの場合は、カレンダー モードを使用して特定の GPU（H100 と H200）と TPU（Trillium）を予約します。

• GKE で AI 推論を最適化するには、TPU と GPU を動的に使用して、容量とパフォーマンスのニーズの変動に対応する vLLM エンジンを実行します。詳細については、vLLM GPU/TPU の代替性をご覧ください。

• アクセラレータを含む複雑なリソースとトポロジのニーズがある高度なシナリオでは、ツールを使用してリソース管理を抽象化します。

  • Cluster Director を使用すると、マルチ GPU トレーニング（A3 Ultra H200 と A4 B200）のコロケーションとスケジューリングを使用してアクセラレータ グループをデプロイして管理できます。Cluster Director は GKE クラスタと Slurm クラスタをサポートしています。
  • Ray on Vertex AI は、分散コンピューティング インフラストラクチャを抽象化します。これにより、アプリケーションは VM とコンテナを直接管理することなく、トレーニングとサービングのリソースをリクエストできます。

受信トラフィックを複数のインスタンスに分散する

需要が変動する AI アプリケーションでは、効果的なロード バランシングが不可欠です。ロード バランシングは、トラフィックを分散し、リソース使用率を最適化し、HA と低レイテンシを実現して、シームレスなユーザー エクスペリエンスを確保します。

• リソースのニーズが変化する推論: モデル指標に基づいてロード バランシングを実装します。GKE Inference Gateway を使用すると、モデル対応のルーティングを使用して、ロードバランサの背後にモデルをデプロイできます。ゲートウェイは、生成 AI や LLM 推論などのコンピューティング負荷の高いタスクに対して、GPU と TPU アクセラレータを備えたインスタンスを優先します。詳細なヘルスチェックを構成して、モデルのステータスを評価します。LLM 指標には vLLM や Triton などのサービング フレームワークを使用し、Google Cloud Managed Service for Prometheus を使用して、指標を Cloud Monitoring に統合します。
• GPU または TPU を必要とする推論ワークロード: GPU と TPU の可用性が制限されている場合など、重要な AI と ML の推論ワークロードがワークロードの要件に適したマシンで一貫して実行されるようにするには、GKE カスタム コンピューティング クラスを使用します。自動スケーリングのフォールバック ポリシーを使用して、特定のコンピューティング プロファイルを定義できます。たとえば、予約済みの GPU インスタンスまたは TPU インスタンスの優先度を高めるプロファイルを定義できます。プロファイルには、予約済みリソースが一時的に使用できない場合に費用対効果の高い Spot VM を使用するフォールバックを含めることができます。
• 多様なオーケストレーション プラットフォームでの生成 AI: 一元化されたロードバランサを使用します。たとえば、費用と管理の効率性を高めるために、GPU のニーズが低いリクエストを Cloud Run に転送し、より複雑で GPU を多用するタスクを GKE に転送できます。サービス間の通信とポリシー管理には、Cloud Service Mesh を使用してサービス メッシュを実装します。Cloud Logging と Cloud Monitoring を使用して、一貫したロギングとモニタリングを確保します。
• グローバル ロード分散: レイテンシの低いグローバル ユーザーからのトラフィックをロードバランスするには、グローバル外部アプリケーション ロードバランサを使用します。最も近いリージョンに位置情報ルーティングを構成し、フェイルオーバーを実装します。Vertex AI または GKE でリージョン エンドポイントのレプリケーションを確立します。静的アセット用に Cloud CDN を構成します。Cloud Monitoring を使用して、グローバル トラフィックとレイテンシをモニタリングします。
• きめ細かいトラフィック管理: さまざまなデータ型や複雑さを持つリクエスト、長時間実行されるリクエストについては、きめ細かいトラフィック管理を実装します。
  • コンテンツ ベースのルーティングを構成して、URL パスやヘッダーなどの属性に基づいて、リクエストを専用のバックエンドに転送します。たとえば、画像モデルまたは動画モデルのリクエストを GPU 対応のバックエンドに転送し、テキストベースのモデルのリクエストを CPU 最適化バックエンドに転送します。
  • 長時間実行される生成 AI リクエストまたはバッチ ワークロードには、WebSocket または gRPC を使用します。トラフィック管理を実装して、タイムアウトとバッファリングを処理します。API Gateway または Apigee を使用して、リクエストのタイムアウトと再試行を構成し、レート制限と割り当てを実装します。

モジュール型で疎結合のアーキテクチャを使用する

モジュール式の疎結合 AI / ML アーキテクチャでは、複雑なシステムが、明確に定義されたインターフェースを介して相互作用する、より小さな自己完結型のコンポーネントに分割されます。このアーキテクチャでは、モジュールの依存関係が最小限に抑えられ、開発とテストが簡素化され、再現性が向上し、障害を封じ込めることでフォールト トレランスが向上します。モジュール式のアプローチは、複雑さを管理し、イノベーションを加速し、長期的な保守性を確保するために不可欠です。

AI ワークロードと ML ワークロードのモジュラーで疎結合のアーキテクチャを設計するには、次の推奨事項を検討してください。

自己完結型の小さなモジュールまたはコンポーネントを実装する

エンドツーエンドの AI および ML システムを、小さく自己完結型のモジュールまたはコンポーネントに分割します。各モジュールまたはコンポーネントは、データの取り込み、特徴変換、モデル トレーニング、推論サービング、評価などの特定の機能を担当します。モジュール設計には、AI システムと ML システムの保守性の向上、スケーラビリティの向上、再利用性、柔軟性とアジリティの向上など、いくつかの重要なメリットがあります。

以降のセクションでは、AI システムと ML システムのモジュラー アーキテクチャの設計に使用できる Google Cloud プロダクト、機能、ツールについて説明します。

GKE 上のコンテナ化されたマイクロサービス

複雑な AI システムや ML システム、またはきめ細かいオーケストレーションが必要な複雑な生成 AI パイプラインの場合は、GKE を使用してオーケストレートされるマイクロサービスとしてモジュールを実装します。個別のステージを Docker コンテナ内の個々のマイクロサービスとしてパッケージ化します。これらの個別のステージには、さまざまな形式に合わせて調整されたデータ取り込み、特殊なデータ前処理または特徴エンジニアリング、大規模な基盤モデルの分散モデル トレーニングまたはファインチューニング、評価、サービングなどがあります。

コンテナ化されたマイクロサービスを GKE にデプロイし、CPU とメモリの使用率または GPU 使用率などのカスタム指標に基づく自動スケーリング、ローリング アップデート、YAML マニフェストの再現可能な構成を活用します。GKE サービス ディスカバリを使用して、マイクロサービス間の効率的な通信を確保します。非同期パターンには、Pub/Sub などのメッセージ キューを使用します。

GKE 上のマイクロサービス アプローチは、ステージを個別のサービスとして設計できる複雑な RAG アプリケーションなどのタスク向けに、スケーラブルで復元力のあるプラットフォームを構築するのに役立ちます。

サーバーレス イベント ドリブン サービス

サーバーレスの自動スケーリングのメリットを活かせるイベント ドリブン タスクには、Cloud Run または Cloud Run 関数を使用します。これらのサービスは、前処理などの非同期タスクや、小規模な推論ジョブに最適です。Cloud Storage で作成された新しいデータファイルや、Artifact Registry でのモデルの更新などのイベントで Cloud Run functions をトリガーします。コンテナ環境を必要とするウェブフック タスクまたはサービスには、Cloud Run を使用します。

Cloud Run サービスと Cloud Run functions は、迅速にスケールアップし、ゼロにスケールダウンできるため、変動するワークロードの費用対効果を確保できます。これらのサービスは、Vertex AI Agents ワークフローのモジュラー コンポーネントに適しています。コンポーネント シーケンスは、Workflows または Application Integration でオーケストレートできます。

Vertex AI マネージド サービス

Vertex AI サービスはモジュール性をサポートしており、AI システムと ML システムの開発とデプロイを簡素化できます。これらのサービスはインフラストラクチャの複雑さを抽象化するため、デベロッパーはアプリケーション ロジックに集中できます。

• モジュール式のステップから構築されたワークフローをオーケストレートするには、Vertex AI Pipelines を使用します。
• カスタム AI コードと ML コードを実行するには、Vertex AI カスタム トレーニングや Vertex AI 予測などのマネージド サービスで実行できる Docker コンテナにコードをパッケージ化します。
• モジュラー特徴量エンジニアリング パイプラインには、Vertex AI Feature Store を使用します。
• モジュール式の探索とプロトタイピングには、Vertex AI Workbench や Colab Enterprise などのノートブック環境を使用します。コードを再利用可能な関数、クラス、スクリプトに整理します。

エージェント アプリケーション

AI エージェントの場合、エージェント開発キット（ADK）は、ツールや状態などのモジュラー機能を提供します。LangChain、LangGraph、LlamaIndex、Vertex AI などのフレームワーク間の相互運用性を実現するには、ADK を Agent2Agent（A2A）プロトコルと Model Context Protocol（MCP）と組み合わせます。この相互運用性により、さまざまなコンポーネントを使用してエージェント ワークフローを作成できます。

エージェントは、スケーラブルなエージェントのデプロイ用に最適化されたマネージド ランタイムである Vertex AI Agent Engine にデプロイできます。コンテナ化されたエージェントを実行するには、Cloud Run の自動スケーリング機能を利用できます。

明確に定義されたインターフェースを設計する

堅牢で保守可能なソフトウェア システムを構築するには、システムのコンポーネントが疎結合でモジュール化されていることを確認することが重要です。このアプローチは、システムのさまざまな部分間の依存関係を最小限に抑えるため、大きなメリットがあります。モジュール間の結合度が低い場合、1 つのモジュールの変更が他のモジュールに与える影響は最小限に抑えられます。この分離により、個々のモジュールで独立した更新と開発ワークフローが可能になります。

以降のセクションでは、AI システムと ML システムのモジュール間のシームレスな通信と統合を確保するためのガイダンスを提供します。

プロトコルの選択

• ユニバーサル アクセスを実現するには、HTTP API を使用し、RESTful の原則に準拠し、言語に依存しないデータ交換に JSON を使用します。リソースに対するアクションを表すように API エンドポイントを設計します。
• マイクロサービス間の高性能な内部通信には、効率的なシリアル化と厳密な型指定のために、 Protocol Buffers（ProtoBuf）で gRPC を使用します。.proto ファイルを使用して ModelInput、PredictionResult、ADK Tool データなどのデータ構造を定義し、言語バインディングを生成します。
• パフォーマンスが重要なユースケースでは、大規模なデータセットや、ライブのテキスト読み上げや動画アプリケーションなどの継続的なフローに gRPC ストリーミングを活用します。GKE に gRPC サービスをデプロイします。

標準化された包括的なドキュメント

選択するインターフェース プロトコルに関係なく、標準化されたドキュメントが重要です。OpenAPI 仕様では、RESTful API について説明します。OpenAPI を使用して、AI API と ML API のパス、メソッド、パラメータ、JSON スキーマにリンクされたリクエストとレスポンスの形式、セキュリティを文書化します。包括的な API ドキュメントは、検出可能性とクライアント統合の向上に役立ちます。API の作成と可視化には、Swagger Editor などの UI ツールを使用します。開発を加速し、一貫性を確保するには、Gemini Code Assist などの AI を活用したコーディング ツールを使用して、クライアント SDK とサーバー スタブを生成します。OpenAPI ドキュメントを CI/CD フローに統合します。

Vertex AI などの Google Cloud マネージド サービスとのやり取り

開発の生産性を高めるために推奨される Vertex AI SDK の高い抽象化と、REST API が提供するきめ細かい制御のどちらかを選択します。

• Vertex AI SDK は、タスクと認証を簡素化します。Vertex AI とのやり取りが必要な場合は、SDK を使用します。
• REST API は、特にシステムのレイヤ間で相互運用性が必要な場合に、強力な代替手段となります。これは、SDK がない言語のツールや、きめ細かい制御が必要な場合に便利です。

API を使用してモジュールを分離し、実装の詳細を抽象化する

セキュリティ、スケーラビリティ、可視性を確保するには、AI サービスと ML サービスに堅牢な API 管理を実装することが重要です。定義したインターフェースに API 管理を実装するには、次のプロダクトを使用します。

• API Gateway: 外部に公開され、管理されている API の場合、API Gateway は一元化された安全なエントリ ポイントを提供します。予測、トレーニング、データ API などのサーバーレス バックエンド サービスへのアクセスが簡素化されます。API Gateway は、アクセス ポイントの統合、API コントラクトの適用、API キーや OAuth 2.0 などのセキュリティ機能の管理に役立ちます。バックエンドを過負荷から保護し、信頼性を確保するには、API Gateway でレート制限と使用割り当てを実装します。
• Cloud Endpoints: GKE と Cloud Run での API の開発とデプロイを効率化するには、Cloud Endpoints を使用します。Cloud Endpoints は、API キーを生成するための開発者向けのソリューションを提供します。また、API 呼び出しの統合モニタリングとトレースも提供し、OpenAPI 仕様の生成を自動化することで、ドキュメントとクライアント統合を簡素化します。Cloud Endpoints を使用すると、内部または制御された AI API や ML API へのアクセスを管理できます。たとえば、トレーニングをトリガーしたり、特徴ストアを管理したりできます。
• Apigee: エンタープライズ規模の AI と ML（特に高度な生成 AI API）の場合、Apigee は高度で包括的な API 管理を提供します。Apigee は、脅威保護や OAuth 2.0 などの高度なセキュリティ、キャッシュ保存、割り当て、メディエーションなどのトラフィック管理、分析に使用します。Apigee は、生成 AI API の使用状況を把握するうえで重要な、API の使用パターン、パフォーマンス、エンゲージメントに関する詳細な分析情報を取得するのに役立ちます。

グレースフル デグラデーションを計画する

本番環境の AI システムと ML システムでは、他のシステムと同様に、コンポーネントの障害は避けられません。グレースフル デグラデーションにより、パフォーマンスが低下する可能性はありますが、重要な機能は引き続き動作します。このアプローチにより、完全な停止を防ぎ、全体的な可用性を向上させることができます。グレースフル デグラデーションは、レイテンシの影響を受けやすい推論、分散トレーニング、生成 AI に不可欠です。

以降のセクションでは、グレースフル デグラデーションを計画して実装するために使用する手法について説明します。

障害の分離

• 分散アーキテクチャで障害のあるコンポーネントを分離するには、Java の Resilience4j や Python の CircuitBreaker などの復元ライブラリを使用して、サーキット ブレーカー パターンを実装します。
• 障害の連鎖を防ぐには、エラー率やレイテンシなどの AI と ML のワークロード指標に基づいてしきい値を構成し、よりシンプルなモデルやキャッシュに保存されたデータなどのフォールバックを定義します。

コンポーネントの冗長性

重要なコンポーネントについては、冗長性と自動フェイルオーバーを実装します。たとえば、GKE マルチゾーン クラスタまたはリージョン クラスタを使用して、Cloud Run サービスを複数のリージョンに冗長的にデプロイします。異常なインスタンスが検出されたときに正常なインスタンスにトラフィックを転送するには、Cloud Load Balancing を使用します。

Cloud Storage マルチリージョン バケットを使用して、データの冗長性を確保します。分散トレーニングでは、非同期チェックポイントを実装して、障害後に再開します。復元力と伸縮性のあるトレーニングには、Pathways を使用します。Pathways

プロアクティブなモニタリング

グレースフル デグラデーションは障害発生時のシステムの可用性を確保するのに役立ちますが、継続的なヘルスチェックと包括的なモニタリングのための事前対応策も実装する必要があります。レイテンシ、スループット、GPU 使用率など、AI と ML に固有の指標を収集します。また、Cloud Monitoring と Vertex AI Model Monitoring を使用して、モデルとデータのドリフトなどのモデル パフォーマンスの低下指標を収集します。

ヘルスチェックにより、障害のあるノードの交換、容量の追加デプロイ、更新されたデータを使用するパイプラインの継続的再トレーニングまたはファインチューニングの自動トリガーが必要になることがあります。この予防的なアプローチは、精度に基づく劣化とシステムレベルのグレースフル デグラデーションの両方を防ぎ、全体的な信頼性を高めるのに役立ちます。

SRE プラクティス

システムの健全性をモニタリングするには、SRE プラクティスを採用してサービスレベル目標（SLO）を実装することを検討してください。エラー バジェットの損失とバーンレートに関するアラートは、システムの信頼性の問題の早期の兆候となる可能性があります。SRE プラクティスの詳細については、Google SRE ブックをご覧ください。

自動化されたエンドツーエンドの MLOps プラットフォームを構築する

Google Cloudの堅牢でスケーラブルかつ信頼性の高い AI / ML システムには、モデル開発ライフサイクルの自動化されたエンドツーエンドの MLOps プラットフォームが必要です。開発ライフサイクルには、初期のデータ処理、継続的なモデルのトレーニング、デプロイ、本番環境でのモニタリングが含まれます。 Google Cloudでこれらのステージを自動化すると、再現可能なプロセスが確立され、手作業による負担が軽減され、エラーが最小限に抑えられ、イノベーションのペースが加速します。

自動化された MLOps プラットフォームは、アプリケーションの信頼性を本番環境レベルで確立するために不可欠です。自動化は、モデルの品質を確保し、再現性を保証し、AI と ML のアーティファクトの継続的インテグレーションとデリバリーを可能にするのに役立ちます。

自動化されたエンドツーエンドの MLOps プラットフォームを構築するには、次の推奨事項を検討してください。

モデル開発ライフサイクルを自動化する

自動化された MLOps プラットフォームの重要な要素は、AI と ML のワークフロー全体を、データ準備と検証からモデルのトレーニング、評価、デプロイ、モニタリングまで、一連の接続された自動化されたステップとしてオーケストレートすることです。

• Vertex AI Pipelines を中央オーケストレーターとして使用します。
  • データ処理、トレーニング、評価、デプロイ用のモジュラー コンポーネントを使用して、エンドツーエンドのワークフローを定義します。
  • スケジュールや、新しいデータやコードの変更などのトリガーを使用して、パイプラインの実行を自動化します。
  • 各パイプライン実行の自動パラメータ化とバージョン管理を実装し、バージョン履歴を作成します。
  • 組み込みのロギングとトレースを使用してパイプラインの進行状況とリソース使用率をモニタリングし、Cloud Monitoring アラートと統合します。
• Kubeflow Pipelines（KFP）SDK または TensorFlow Extended SDK を使用して、ML パイプラインをプログラムで定義します。詳細については、Vertex AI Pipelines のインターフェースをご覧ください。
• Dataflow、Vertex AI カスタム トレーニング、Vertex AI Model Registry、Vertex AI エンドポイントなどの Google Cloud サービスを使用してオペレーションをオーケストレートします。
• 生成 AI ワークフローでは、プロンプト管理、バッチ推論、人間参加型（HITL）評価、ADK コンポーネントの調整の手順をオーケストレートします。

Infrastructure as Code の管理

Infrastructure as Code（IaC）は、AI システムと ML システムのインフラストラクチャを管理し、再現可能でスケーラブルで保守可能なデプロイを実現するために不可欠です。AI システムと ML システムのインフラストラクチャのニーズは動的で複雑です。多くの場合、システムには GPU や TPU などの特殊なハードウェアが必要です。IaC は、一貫性を確保し、ロールバックを可能にし、デプロイを再現可能にすることで、手動のインフラストラクチャ管理のリスクを軽減します。

インフラストラクチャ リソースをコードとして効果的に管理するには、次の手法を使用します。

リソースのプロビジョニングを自動化する

Google Cloudで IaC を効果的に管理するには、Terraform を使用して AI と ML のインフラストラクチャ リソースを定義してプロビジョニングします。インフラストラクチャには、次のようなリソースが含まれる場合があります。

• ノードプールで構成された GKE クラスタ。ノードプールは、ワークロードの要件に基づいて最適化できます。たとえば、トレーニングに A100、H100、H200、B200 GPU を使用し、推論に L4 GPU を使用できます。
• モデル サービング用に構成され、マシンタイプとスケーリング ポリシーが定義されている Vertex AI エンドポイント。
• データとアーティファクト用の Cloud Storage バケット。

構成テンプレートを使用する

Terraform 構成をモジュラー テンプレートとして整理します。AI リソースと ML リソースのプロビジョニングを高速化するには、Cluster Toolkit を使用します。このツールキットには、ブループリントの例が用意されています。これは、Slurm または GKE で HPC、AI、ML のすぐに使用できるクラスタをデプロイするために使用できる、Google が厳選した Terraform テンプレートです。Terraform コードをカスタマイズして、バージョン管理システムで管理できます。リソースのプロビジョニングと更新のワークフローを自動化するには、Cloud Build を使用して、コードを CI/CD パイプラインに統合します。

構成変更を自動化する

インフラストラクチャをプロビジョニングしたら、継続的な構成変更を宣言的に管理します。

• Kubernetes 中心の環境では、Config Connector を使用して Google Cloudリソースを Kubernetes オブジェクトとして管理します。
• YAML マニフェストを使用して、データセット、モデル、エンドポイントなどの Vertex AI リソース、Cloud SQL インスタンス、Pub/Sub トピック、Cloud Storage バケットを定義して管理します。
• マニフェストを GKE クラスタにデプロイして、アプリケーションとインフラストラクチャの構成を統合します。
• CI/CD パイプラインを使用して構成の更新を自動化し、テンプレートを使用して環境の違いを処理します。
• IaC を使用して、Identity and Access Management（IAM）ポリシーとサービス アカウントの構成を実装します。

CI/CD と統合する

• Cloud Build や Infrastructure Manager などのツールを使用して IaC を CI/CD パイプラインに統合し、 Google Cloud インフラストラクチャ リソースのライフサイクルを自動化します。
• コード commit の自動更新のトリガーを定義します。
• パイプライン内に自動テストと検証を実装します。たとえば、Terraform の validate コマンドと plan コマンドを自動的に実行するスクリプトを作成できます。
• 構成をアーティファクトとして保存し、バージョニングを有効にします。
• バージョン管理で個別の構成を使用して、開発、ステージング、本番環境などの個別の環境を定義し、環境の昇格を自動化します。

モデルの動作を検証する

モデルの精度と関連性を維持するには、MLOps プラットフォーム内でトレーニングと評価のプロセスを自動化します。この自動化と厳格な検証により、モデルが本番環境にデプロイされる前に、関連データで想定どおりに動作することが保証されます。

• 新しいデータや、データドリフトなどのモニタリング シグナルによってトリガーされるか、スケジュールで実行される継続的トレーニング パイプラインを設定します。
  • ハイパーパラメータ チューニング トライアルや、大規模モデルの分散トレーニング構成などの自動トレーニング ジョブを管理するには、Vertex AI カスタム トレーニングを使用します。
  • 基盤モデルをファインチューニングする場合は、ファインチューニング プロセスを自動化し、ジョブをパイプラインに統合します。
• 自動モデル バージョニングを実装し、トレーニングが正常に実行されるたびに、トレーニング済みモデル アーティファクトを安全に保存します。アーティファクトは Cloud Storage に保存するか、モデル登録に登録できます。
• 評価指標を定義し、最小精度、最大エラー率、最小 F1 スコアなどの明確なしきい値を設定します。
  • モデルが評価に自動的に合格し、デプロイの対象となるしきい値を満たしていることを確認します。
  • Vertex AI のモデル評価などのサービスを使用して、評価を自動化します。
  • 評価には、生成された出力の品質、事実の正確性、安全性の属性、指定されたスタイルや形式への準拠に固有の指標が含まれていることを確認します。
• 各トレーニングと評価の実行のパラメータ、コード バージョン、データセット バージョン、結果を自動的にロギングして追跡するには、Vertex AI Experiments を使用します。このアプローチでは、比較、デバッグ、再現性に役立つ履歴が提供されます。
• ハイパーパラメータ チューニングを最適化し、定義した目標に基づいて最適なモデル構成の検索を自動化するには、Vertex AI Vizier を使用します。
• トレーニング指標を可視化し、開発中にデバッグするには、Vertex AI TensorBoard を使用します。

AI パイプラインと ML パイプラインの入出力を検証する

AI システムと ML システムの信頼性と完全性を確保するには、システムにデータが入力され、パイプラインを通過するときにデータを検証する必要があります。コンポーネント境界で入力と出力も検証する必要があります。すべての入力と出力（未加工データ、処理済みデータ、構成、引数、ファイル）の堅牢な検証は、予期しない動作を防ぎ、MLOps ライフサイクル全体でモデルの品質を維持するのに役立ちます。このプロアクティブなアプローチを MLOps プラットフォームに統合すると、エラーがシステム全体に伝播する前に検出できるため、時間とリソースを節約できます。

AI パイプラインと ML パイプラインの入出力を効果的に検証するには、次の手法を使用します。

データ検証を自動化する

• TensorFlow Data Validation（TFDV）を使用して、データ取り込みパイプラインと前処理パイプラインで自動データ検証を実装します。
  • 大規模な SQL ベースのデータ品質チェックには、BigQuery などのスケーラブルな処理サービスを活用します。
  • ストリーミング データまたはバッチデータに対して複雑なプログラムによる検証を行う場合は、Dataflow を使用します。
• TFDV の機能を使用して、データ分布を長期にわたってモニタリングします。
  • Cloud Monitoring と統合されたツールを使用して傾向を可視化し、データドリフトを検出します。データ パターンが大幅に変更されたときに、モデルの再トレーニング パイプラインを自動的にトリガーできます。
• 検証結果と指標を BigQuery に保存して分析と履歴トラッキングを行い、検証アーティファクトを Cloud Storage にアーカイブします。

パイプライン構成と入力データを検証する

設定の誤りによるパイプラインの失敗や予期しない動作を防ぐには、すべてのパイプライン構成とコマンドライン引数に対して厳密な検証を実装します。

• Python 用の jsonschema などのスキーマ検証ライブラリを使用して、YAML や JSON などの構成ファイルの明確なスキーマを定義します。パイプラインの実行が開始される前とコンポーネントが実行される前に、これらのスキーマに対して構成オブジェクトを検証します。
• argparse などの引数解析ライブラリを使用して、すべてのコマンドライン引数とパイプライン パラメータの入力検証を実装します。検証では、正しいデータ型、有効な値、必須の引数を確認する必要があります。
• Vertex AI Pipelines 内で、組み込みのコンポーネント入力検証機能を使用して、コンポーネント パラメータの想定される型とプロパティを定義します。
• パイプライン実行の再現性を確保し、監査証跡を維持するには、検証済みのバージョン管理された構成ファイルを Cloud Storage または Artifact Registry に保存します。

入力ファイルと出力ファイルを検証する

データセット、モデル アーティファクト、評価レポートなどの入力ファイルと出力ファイルの整合性と形式の正しさを検証します。

• ライブラリを使用して、CSV、Parquet、画像タイプなどのファイル形式を検証します。
• 大きなファイルや重要なアーティファクトの場合は、Cloud Storage のデータ検証と変更検出を使用して、ファイルサイズとチェックサムを検証し、破損や転送の不完全性を検出します。
• Cloud Run functions（ファイル アップロード イベントに基づくなど）または Dataflow パイプライン内でファイル検証を行います。
• 検証結果を BigQuery に保存すると、取得と分析が容易になります。

デプロイを自動化し、継続的なモニタリングを実装する

本番環境のモデルの自動デプロイと継続的なモニタリングにより、信頼性を確保し、迅速な更新を実行し、問題を迅速に検出できます。これには、次のセクションで説明するように、モデル バージョンの管理、制御されたデプロイ、CI/CD を使用した自動デプロイ、包括的なモニタリングが含まれます。

モデル バージョンを管理する

バージョン管理ツールを使用して、モデルのイテレーションと関連するアーティファクトを管理します。

• モデルのバージョンとメタデータを追跡し、基盤となるモデル アーティファクトにリンクするには、Model Registry を使用します。
• 明確なバージョニング スキーム（セマンティック バージョニングなど）を実装します。モデル バージョンごとに、トレーニング パラメータ、検証パイプラインの評価指標、データセット バージョンなどの包括的なメタデータを関連付けます。
• モデルファイル、事前トレーニング済みの重み、サービング コンテナ イメージなどのモデル アーティファクトを Artifact Registry に保存し、そのバージョン管理機能とタグ付け機能を使用します。
• セキュリティとガバナンスの要件を満たすには、Model Registry と Artifact Registry に厳格なアクセス制御ポリシーを定義します。
• バージョンをプログラムで登録して管理し、バージョンを自動化された CI/CD パイプラインに統合するには、Vertex AI SDK または API を使用します。

制御されたデプロイを実行する

サービング プラットフォームのトラフィック管理機能を使用して、モデル バージョンのエンドポイントへのデプロイを制御します。

• Vertex AI エンドポイントのトラフィック分割機能を使用して、ローリング デプロイを実装します。
• モデルを GKE にデプロイする場合は、カナリア デプロイなどの高度なトラフィック管理手法を使用します。
  1. 本番環境トラフィックの小さなサブセットを新しいモデル バージョンにルーティングします。
  2. 指標を使用して、パフォーマンスとエラー率を継続的にモニタリングします。
  3. モデルが信頼できることを確認します。
  4. すべてのトラフィックにバージョンをロールアウトします。
• AI エージェントの A/B テストを実施します。
  1. 2 つの異なるモデル エージェント バージョンまたはまったく異なるモデルを同じエンドポイントにデプロイします。
  2. デプロイ間でトラフィックを分割します。
  3. ビジネス目標に照らして結果を分析します。
• モニタリング アラートがトリガーされた場合や、パフォーマンスのしきい値を超えた場合に、エンドポイント トラフィックを以前の安定したモデル バージョンにすばやく戻すことができる自動ロールバック メカニズムを実装します。
• Vertex AI SDK または API を使用して、トラフィック分割とデプロイ設定をプログラムで構成します。
• Cloud Monitoring を使用して、バージョン間のパフォーマンスとトラフィックを追跡します。
• CI/CD パイプラインを使用してデプロイを自動化します。Cloud Build を使用して、コンテナのビルド、アーティファクトのバージョン管理、Vertex AI エンドポイントへのデプロイのトリガーを行うことができます。
• CI/CD パイプラインがバージョンを管理し、Artifact Registry から pull するようにします。
• トラフィックを移行する前に、予測の正確性、レイテンシ、スループット、API 関数について自動エンドポイント テストを実施します。
• すべての構成をバージョン管理に保存します。

継続的にモニタリングする

• モデル モニタリングを使用して、パフォーマンスの低下、データドリフト（トレーニングと比較した入力分布の変化）、予測ドリフト（モデル出力の変化）を自動的に検出します。
  • しきい値とアラートを使用してドリフト検出ジョブを構成します。
  • リアルタイムのパフォーマンス（予測レイテンシ、スループット、エラー率）をモニタリングします。
• ビジネス KPI の Cloud Monitoring でカスタム指標を定義します。
• アラートとダッシュボード用に、モデル モニタリングの結果とカスタム指標を Cloud Monitoring と統合します。
• メール、Slack、PagerDuty などの通知チャネルを構成し、自動修復を構成します。
• 予測ログをデバッグするには、Cloud Logging を使用します。
• モニタリングをインシデント管理と統合します。

生成 AI エンドポイントの場合は、毒性や一貫性などの出力特性をモニタリングします。

• ドリフトのサービング特徴をモニタリングします。
• きめ細かい予測検証を実装する: カスタム ロジックを使用して、出力が想定される範囲と形式に準拠していることを検証します。
• 予測分布の変化をモニタリングします。
• 出力スキーマを検証します。
• 予期しない出力とシフトに対するアラートを構成します。
• Pub/Sub を使用して、リアルタイムの検証イベントを追跡し、対応します。

包括的なモニタリングの出力が継続的なトレーニングにフィードバックされるようにします。

データとモデルのガバナンスを通じて信頼と制御を維持する

AI と ML の信頼性は、技術的な稼働時間だけではありません。これには、信頼性と堅牢なデータとモデルのガバナンスが含まれます。AI の出力は、不正確、偏っている、古い可能性があります。このような問題は信頼を損ない、危害を及ぼす可能性があります。包括的なトレーサビリティ、強力なアクセス制御、自動検証、透明性の高いプラクティスにより、AI の出力が信頼性が高く、信頼でき、倫理基準を満たしていることを確認できます。

データとモデルのガバナンスを通じて信頼と制御を維持するには、次の推奨事項を検討してください。

トレーサビリティのためにデータカタログとモデルカタログを確立する

包括的な追跡、監査、AI アセットと ML アセットのリネージの把握を容易にするため、ライフサイクル全体にわたってデータとモデルのバージョンの堅牢な一元化された記録を維持します。信頼性の高いデータとモデルのカタログは、AI パイプラインと ML パイプラインで使用および生成されるすべてのアーティファクト（未加工のデータソースや処理済みのデータセットから、トレーニング済みのモデル バージョンやデプロイされたエンドポイントまで）の信頼できる唯一の情報源として機能します。

次のプロダクト、ツール、手法を使用して、データアセットのカタログを作成して維持します。

• Dataplex Universal Catalog を使用して、データアセットの全社的なカタログを構築します。データアセットのインベントリを自動的に検出して作成するには、Dataplex Universal Catalog を BigQuery、Cloud Storage、Pub/Sub などのストレージ システムと統合します。
• Cloud Storage のマルチリージョン バケットまたはデュアルリージョン バケットにデータを保存して、データの高可用性と耐久性を確保します。これらのバケットにアップロードするデータは、少なくとも 2 つの地理的に離れた場所に冗長的に保存されます。この冗長性により、リージョン単位での停止に対する組み込みの復元力が提供され、データの整合性を確保できます。
• 関連するビジネス メタデータ、所有権情報、機密レベル、リネージの詳細を使用して、データセットにタグ付けとアノテーションを行います。たとえば、処理済みのデータセットをその未加工のソースと、データセットを作成したパイプラインにリンクします。
• Model Registry を使用して、モデル バージョンの中央リポジトリを作成します。トレーニング済みモデルの各バージョンを登録し、関連するメタデータにリンクします。メタデータには次のものが含まれます。
  • トレーニング パラメータ。
  • 検証パイプラインの評価指標。
  • トレーニングに使用されたデータセットのバージョン。リネージは関連する Dataplex Universal Catalog エントリまで追跡されます。
  • データセットを生成したコードのバージョン。
  • 使用されたフレームワークまたは基盤モデルの詳細。
• モデルを Model Registry にインポートする前に、モデルファイルや事前トレーニング済みの重みなどのモデル アーティファクトを Cloud Storage などのサービスに保存します。サービングまたはカスタム トレーニング ジョブ用のカスタム コンテナ イメージは、Artifact Registry などの安全なリポジトリに保存します。
• データアセットとモデルアセットが作成または変更されたときに、それぞれのカタログに自動的に登録され、更新されるようにするには、MLOps パイプライン内に自動化されたプロセスを実装します。この包括的なカタログにより、元データから予測までのエンドツーエンドのトレーサビリティが実現し、特定のモデル バージョンや予測につながった入力とプロセスを監査できます。監査機能は、予期しない動作のデバッグ、データ使用ポリシーの遵守の確保、データやモデルの変更が時間の経過とともに与える影響の把握に不可欠です。
• 生成 AI と基盤モデルの場合、カタログでは、使用される特定の基盤モデル、ファインチューニング パラメータ、生成された出力の品質と安全性に固有の評価結果に関する詳細も追跡する必要があります。

堅牢なアクセス制御と監査証跡を実装する

AI システムと ML システムの信頼性と制御を維持するには、機密データとモデルを不正アクセスから保護し、すべての変更に対する説明責任を確保することが不可欠です。

• Google Cloudで、AI システムと ML システムのすべてのコンポーネントに厳格なアクセス制御を実装し、詳細な監査証跡を維持します。
• AI リソースと ML リソースを操作するユーザー、グループ、サービス アカウントに対して、IAM できめ細かい権限を定義します。
• 最小権限の原則を厳守します。
• 特定のタスクに必要な最小限の権限のみを付与します。たとえば、トレーニング サービス アカウントにはトレーニング データに対する読み取りアクセス権とモデル アーティファクトに対する書き込みアクセス権が必要ですが、本番環境のサービング エンドポイントに対する書き込みアクセス権は必要ない場合があります。

AI システムと ML システムの関連するすべてのアセットとリソースに、次のものを含め、IAM ポリシーを一貫して適用します。

• 機密データまたはモデル アーティファクトを含む Cloud Storage バケット。
• BigQuery データセット。
• モデル リポジトリ、エンドポイント、パイプライン、Feature Store リソースなどの Vertex AI リソース。
• GKE クラスタや Cloud Run サービスなどのコンピューティング リソース。

監査とログを使用して、アクセス アクティビティをキャプチャ、モニタリング、分析します。

• AI システムと ML システムで使用されるすべての Google Cloud サービスで Cloud Audit Logs を有効にします。
• 監査ログを構成して、API 呼び出し、データアクセス イベント、リソースに対する構成変更に関する詳細情報をキャプチャします。ログをモニタリングして、不審なアクティビティ、不正なアクセス試行、重要なデータやモデルアセットに対する予期しない変更がないか確認します。
• リアルタイムの分析、アラート、可視化を行うには、監査ログを Cloud Logging にストリーミングします。
• 費用対効果の高い長期保存、遡及的なセキュリティ分析、コンプライアンス監査を行うには、ログを BigQuery にエクスポートします。
• 一元化されたセキュリティ モニタリングを行うには、監査ログをセキュリティ情報およびイベント管理（SIEM）システムと統合します。アクセス ポリシーと監査証跡を定期的に見直して、ガバナンス要件に沿っていることを確認し、ポリシー違反の可能性を検出します。
• トレーニングや推論用の個人情報（PII）などの機密データを処理するアプリケーションの場合は、パイプライン内またはデータ ストレージで Sensitive Data Protection チェックを使用します。
• 生成 AI ソリューションとエージェント ソリューションでは、監査証跡を使用して、特定のモデルやツールにアクセスしたユーザー、ファインチューニングやプロンプトに使用されたデータ、本番環境エンドポイントに送信されたクエリを追跡します。監査証跡は説明責任を確保するのに役立ち、データの不正使用やポリシー違反を調査するための重要なデータを提供します。

バイアス、透明性、説明可能性に対処する

信頼できる AI / ML システムを構築するには、データとモデルに固有の潜在的なバイアスに対処し、システム動作の透明性を高め、モデル出力の説明可能性を提供する必要があります。信頼できるシステムを構築することは、機密性の高いドメインや、通常生成 AI アプリケーションで使用されるような複雑なモデルを使用する場合に特に重要です。

• MLOps ライフサイクル全体でバイアスを特定して軽減するための事前対応型プラクティスを実装します。
• さまざまなユーザー グループや機密属性にわたる特徴分布のスキューを検出するツールを使用して、トレーニング データのバイアスを分析します。
• モデルの全体的なパフォーマンスと、事前定義されたデータ スライス全体のパフォーマンスを評価します。このような評価は、特定のサブグループに影響するパフォーマンスやバイアスの不均衡を特定するのに役立ちます。

モデルの透明性と説明可能性については、ユーザーとデベロッパーがモデルが特定の予測を行った理由や特定の出力を生成した理由を理解するのに役立つツールを使用します。

• Vertex AI エンドポイントにデプロイされた表形式モデルの場合は、Vertex Explainable AI を使用して特徴アトリビューションを生成します。特徴アトリビューションは、予測に最も貢献した入力特徴を示します。
• TensorBoard と統合された What-If ツールなどのモデルに依存しないツールを使用して、モデルの動作とデータセットの潜在的なバイアスをインタラクティブに探索します。
• 説明可能性をモニタリング ダッシュボードに統合します。モデルの推論を理解することが信頼や意思決定に重要な状況では、アプリケーション インターフェースを通じてエンドユーザーに説明可能性データを直接提供します。
• 生成 AI モデルで使用される LLM などの複雑なモデルの場合は、トレースログなどを使用して、エージェントが実行したプロセスを説明します。このようなモデルでは説明可能性を確保するのは比較的困難ですが、それでも重要です。
• RAG アプリケーションでは、取得した情報の引用を提供します。プロンプト エンジニアリングなどの手法を使用して、モデルが説明を提供したり、推論手順を表示したりするように誘導することもできます。
• 本番環境で継続的なモニタリングを実装して、バイアスや不公平さの出現を示す可能性があるモデルの動作や出力の変化を検出します。モデル レジストリのモデルのメタデータの一部として、モデルの制限事項、想定されるユースケース、既知の潜在的なバイアスを文書化します。

AI と ML のオブザーバビリティと信頼性の包括的なプラクティスを実装する

本番環境で複雑な AI システムと ML システムを管理するには、包括的なオブザーバビリティが不可欠です。また、複雑な AI システムや ML システム（特に生成 AI）の信頼性を測定するうえでも不可欠です。生成 AI は複雑でリソースを大量に消費し、予測不可能な出力を生成する可能性があるためです。包括的なオブザーバビリティでは、インフラストラクチャ、アプリケーション コード、データ、モデルの動作を観察して、問題の事前検出、診断、対応に関する分析情報を取得します。このオブザーバビリティは、最終的に高パフォーマンスで信頼性の高いシステムにつながります。包括的なオブザーバビリティを実現するには、次の操作を行う必要があります。

• SRE の原則を採用します。
• 明確な信頼性の目標を定義します。
• システム レイヤ全体の指標を追跡します。
• 可観測性から得られた分析情報を、継続的な改善とプロアクティブな管理に活用します。

Google Cloudで AI ワークロードと ML ワークロードの包括的なオブザーバビリティと信頼性のプラクティスを実装するには、次の推奨事項を検討してください。

信頼性の目標とビジネス指標を確立する

AI システムと ML システムが直接影響する重要業績評価指標（KPI）を特定します。KPI には、AI の推奨事項の影響を受けた収益、AI システムが予測または軽減した顧客の離反、生成 AI 機能によって促進されたユーザー エンゲージメントとコンバージョン率などが含まれます。

KPI ごとに、KPI に影響する対応する技術的な信頼性指標を定義します。たとえば、KPI が「会話型 AI アシスタントに対する顧客満足度」の場合、対応する信頼性指標には次のものがあります。

• ユーザー リクエストの成功率。
• レスポンスのレイテンシ: LLM の最初のトークンまでの時間（TTFT）とトークン ストリーミング。
• 不適切な回答や有害な回答の割合。
• エージェントがタスクを正常に完了した割合。

AI と ML のトレーニングの場合、信頼性指標には、モデルの FLOPS 使用率（MFU）、1 秒あたりのイテレーション数、1 秒あたりのトークン数、デバイスあたりのトークン数などがあります。

AI と ML の信頼性を効果的に測定して改善するには、まず、包括的なビジネス目標に沿った明確な信頼性目標を設定します。ユーザーの視点から AI サービスと ML サービスの許容可能な信頼性とパフォーマンスのレベルを定量化する SLO を定義して、SRE アプローチを採用します。これらの技術的な信頼性指標を特定の SLO 目標で定量化します。

SLO ターゲットの例を次に示します。

• API 呼び出しの 99.9% は成功レスポンスを返す必要があります。
• 95 パーセンタイルの推論レイテンシは 300 ミリ秒未満である必要があります。
• リクエストの 99% で TTFT が 500 ミリ秒未満であること。
• 有害な出力の割合は 0.1% 未満である必要があります。

SLO をビジネスニーズに直接合わせることで、信頼性の取り組みが、ユーザーとビジネスに影響する最も重要なシステム動作に集中します。このアプローチにより、信頼性を測定可能で実用的なエンジニアリング プロパティに変換できます。

インフラストラクチャとアプリケーションのパフォーマンスをモニタリングする

AI システムと ML システムで使用されるすべてのリソースのインフラストラクチャ指標を追跡します。指標には、プロセッサ使用率（CPU、GPU、TPU）、メモリ使用率、ネットワーク スループットとレイテンシ、ディスク I/O が含まれます。Vertex AI Training や Vertex AI Serving などのマネージド環境と、GKE ノードや Cloud Run インスタンスなどのセルフマネージド リソースの指標を追跡します。

AI アプリケーションと ML アプリケーションの4 つのゴールデン シグナルをモニタリングします。

• レイテンシ: リクエストに応答するまでの時間。
• トラフィック: リクエストまたはワークロードの量。
• エラー率: 失敗したリクエストまたはオペレーションの割合。
• 飽和度: CPU、メモリ、GPU、TPU アクセラレータなどの重要なリソースの使用率。システムが容量の上限にどのくらい近づいているかを示します。

次の手法を使用してモニタリングを行います。

• Cloud Monitoring を使用して、インフラストラクチャとアプリケーションの指標を収集、保存、可視化します。 Google Cloud サービス用の事前構築済みダッシュボードを使用し、ワークロードの特定のパフォーマンス指標とインフラストラクチャの健全性に基づいてカスタマイズされたカスタム ダッシュボードを作成できます。
  • Google Cloud Managed Service for Prometheus を使用して、vLLM や NVIDIA Triton Inference Server などの専用サービング フレームワークから指標を収集して Cloud Monitoring に統合します。
  • カスタム トレーニング、エンドポイント、パフォーマンスに関連する指標と、Vertex AI が Cloud Monitoring にエクスポートする指標のダッシュボードを作成し、アラートを構成します。
• Cloud Logging を使用して、AI アプリケーションと ML アプリケーション、および基盤となるインフラストラクチャから詳細なログを収集します。これらのログは、トラブルシューティングとパフォーマンス分析に不可欠です。イベントとエラーに関するコンテキストを提供します。
• Cloud Trace を使用して、レイテンシの問題を特定し、分散 AI と ML マイクロサービス全体のリクエスト フローを把握します。この機能は、複雑な Vertex AI エージェントのインタラクションやマルチコンポーネントの推論パイプラインをデバッグするうえで重要です。
• Cloud Profiler を使用して、アプリケーション コードの関数ブロック内のパフォーマンスのボトルネックを特定します。パフォーマンスのボトルネックを特定すると、リソース使用量と実行時間を最適化できます。
• NVIDIA Data Center GPU Manager（DCGM）などのツールを使用して、プロセスごとの GPU 使用率、プロセスごとのメモリ使用量、温度などのアクセラレータ関連の特定の指標を収集します。

データとモデルのオブザーバビリティを実装する

信頼性の高い生成 AI システムには、堅牢なデータとモデルのオブザーバビリティが必要です。これは、エンドツーエンドのパイプライン モニタリングから始まります。

• Dataflow などのサービスを使用して、データ取り込み率、処理量、変換レイテンシを追跡します。
• Vertex AI Pipelines で管理されているパイプラインなど、MLOps パイプライン内のジョブの成功率と失敗率をモニタリングします。

データ品質の継続的な評価は非常に重要です。

• Dataplex Universal Catalog を使用してデータを管理、統制する:
  • グラウンド トゥルースに対する検証や外れ値検出率の追跡によって精度を評価します。
  • データの経過時間と更新頻度を SLA と比較して、更新頻度をモニタリングします。
  • null 値の割合と必須フィールドの入力率を追跡して、完全性を評価します。
  • スキーマ準拠と重複のチェックにより、有効性と一貫性を確保します。
• Cloud Monitoring アラートを使用して異常をプロアクティブに検出し、明確なデータ リネージを通じてトレーサビリティを確保します。
• RAG システムの場合は、取得したコンテキストの関連性と、回答のグラウンディング（ソースへの帰属）を調べます。
• ベクトル データベース クエリのスループットをモニタリングします。

モデルのオブザーバビリティの主要な指標には、入出力トークン数や、ハルシネーションやクエリ解決の失敗などのモデル固有のエラー率が含まれます。これらの指標を追跡するには、モデル モニタリングを使用します。

• 出力の有害性スコアとユーザー フィードバックの評価を継続的にモニタリングします。
• Gen AI Evaluation Service を使用して、定義された基準に対するモデル出力の評価を自動化します。
• 包括的なエラー率指標を使用して、データとコンセプトのドリフトを体系的にモニタリングすることで、パフォーマンスを維持します。

モデル指標を追跡するには、TensorBoard または MLflow を使用します。パフォーマンスの問題をトラブルシューティングするための詳細な分析とプロファイリングには、PyTorch XLA プロファイリングまたは NVIDIA Nsight を使用できます。

寄稿者

著者:

• Rick（Rugui）Chen | AI インフラストラクチャ フィールド ソリューション アーキテクト
• Stef Ruinard | 生成 AI フィールド ソリューション アーキテクト

その他の寄稿者:

• Filipe Gracio 博士 | カスタマー エンジニア、AI/ML スペシャリスト
• Hossein Sarshar | AI インフラストラクチャ フィールド ソリューション アーキテクト
• Jose Andrade | カスタマー エンジニア、SRE スペシャリスト
• Kumar Dhanagopal | クロス プロダクト ソリューション デベロッパー
• Laura Hyatt | カスタマー エンジニア、FSI
• AI インフラストラクチャ担当フィールド ソリューション アーキテクト | Olivier Martin
• Radhika Kanakam | プログラム リード、Google Cloud Well-Architected Framework