このページは Cloud Translation API によって翻訳されました。

ベストプラクティス: GPU を使用した Cloud Run ワーカープール

このページでは、Cloud Run ワーカープールを使用して、大規模言語モデル（LLM）のトレーニング、ファインチューニング、LLM でのバッチ推論やオフライン推論などの AI ワークロードを実行する際のパフォーマンスを最適化するためのベストプラクティスについて説明します。コンピューティング負荷の高いタスクやバッチ処理をリアルタイムで実行できる Cloud Run ワーカープールを作成するには、次の操作を行います。

読み込みが高速で、GPU に対応する構造への変換が最小限で済むモデルを使用し、その読み込み方法を最適化します。
同時実行を効率的で最大限に活用できる構成を使用し、コストを抑えながら、1 秒あたりのターゲットリクエストの処理に必要な GPU の数を減らします。

Cloud Run に大規模な ML モデルを読み込む際のおすすめの方法

ML モデルは、コンテナイメージ内に保存するか、Cloud Storage からの読み込みを最適化することをおすすめします。

ML モデルの保存と読み込みのトレードオフ

比較する項目は次のとおりです。

モデルの位置	デプロイ時間	開発環境	コンテナの起動時間	ストレージ費用
コンテナイメージ	低速。規模の大きいモデルを含むイメージを Cloud Run にインポートするには、より長い時間が必要になります。	コンテナイメージを変更すると再デプロイが必要になります。大規模なイメージの場合、再デプロイに時間がかかることがあります。	モデルのサイズによって変わります。非常に大きなモデルの場合、Cloud Storage を使用すると予測可能なパフォーマンスを実現できますが、パフォーマンスは低下します。	Artifact Registry に複数のコピーが存在する可能性があります。
Cloud Storage FUSE ボリュームマウントを使用して読み込まれる Cloud Storage	高速。モデルはコンテナの起動時にダウンロードされます。	設定が難しくなく、Docker イメージの変更も必要ありません。	ネットワークの最適化を使用すると高速になります。ダウンロードを並列処理しません。	Cloud Storage に 1 つのコピー。
Cloud Storage。transfer manager の同時ダウンロードのコードサンプルに示すように、Google Cloud CLI コマンド `gcloud storage cp` または Cloud Storage API を使用して同時にダウンロードされます。	高速。モデルはコンテナの起動時にダウンロードされます。	イメージに Google Cloud CLI をインストールするか、Cloud Storage API を使用するようにコードを更新する必要があります。設定が少し難しくなります。	ネットワークの最適化を使用すると高速になります。Google Cloud CLI はモデルファイルを並列でダウンロードするため、FUSE マウントよりも高速です。	Cloud Storage に 1 つのコピー。
インターネット	高速。モデルはコンテナの起動時にダウンロードされます。	通常はシンプルです（多くのフレームワークでは中央リポジトリからモデルがダウンロードされます）。	通常は不安定で予測不能です。フレームワークが初期化中にモデル変換を適用する場合があります（これはビルド時に行う必要があります）。モデルホストとモデルのダウンロード用のライブラリが効率的でない場合があります。インターネットからのダウンロードには、信頼性に関するリスクがあります。ダウンロードターゲットが停止している場合、ワーカープールが開始されない可能性があります。また、ダウンロードされた基盤となるモデルが変更され、品質が低下する可能性があります。独自の Cloud Storage バケットにホストすることをおすすめします。	モデルホスティングプロバイダによって異なります。

コンテナイメージにモデルを保存する

ML モデルをコンテナイメージに保存すると、モデルを読み込む際に、Cloud Run の最適化されたコンテナストリーミングインフラストラクチャのメリットを活用できます。ただし、ML モデルを含むコンテナイメージのビルドはリソースを大量に消費するプロセスであり、とりわけ大規模なモデルを扱う場合に当てはまります。特にビルドプロセスは、ネットワークスループットのボトルネックになる可能性があります。Cloud Build を使用する場合は、コンピューティングとネットワーキングのパフォーマンスが高い、高性能なビルドマシンを使用することをおすすめします。これを行うには、次の手順でビルド構成ファイルを使用して、イメージをビルドします。

steps:
- name: 'gcr.io/cloud-builders/docker'
  args: ['build', '-t', 'IMAGE', '.']
- name: 'gcr.io/cloud-builders/docker'
  args: ['push', 'IMAGE']
images:
- IMAGE
options:
 machineType: 'E2_HIGHCPU_32'
 diskSizeGb: '500'

モデルを含むレイヤがイメージ間で異なる場合（ハッシュが異なる場合）は、イメージごとに 1 つのモデルコピーを作成できます。モデルレイヤが各イメージで固有の場合、イメージごとにモデルのコピーが 1 つ存在する可能性があるため、Artifact Registry の費用が増加する可能性があります。

Cloud Storage にモデルを保存する

Cloud Storage から ML モデルを読み込む際に ML モデルの読み込みを最適化するには、Cloud Storage ボリュームのマウントを使用するか、Cloud Storage API またはコマンドラインを直接使用して、下り（外向き）設定が all-traffic に設定されたダイレクト VPC とプライベート Google アクセスを使用する必要があります。

インターネットからモデルを読み込む

インターネットからの ML モデルの読み込みを最適化するには、下り（外向き）設定値を all-traffic に設定してすべてのトラフィックを VPC ネットワーク経由でルーティングし、高帯域幅で公共のインターネットに到達するように Cloud NAT を設定します。

ビルド、デプロイ、ランタイム、システム設計に関する考慮事項

以降のセクションでは、ビルド、デプロイ、ランタイム、システム設計に関する考慮事項について説明します。

ビルド時

ビルドを計画する際に考慮すべき事項は次のとおりです。

適切なベースイメージを選択します。まず、使用する ML フレームワークの Deep Learning Containers または NVIDIA コンテナレジストリのイメージから始めます。これらのイメージには、パフォーマンス関連の最新のパッケージがインストールされています。カスタムイメージの作成はおすすめしません。
結果の品質に影響することを証明できる場合を除き、4 ビットの量子化モデルを選択して同時実行を最大化します。量子化により、より小さい高速なモデルが生成され、モデルのサービングに必要な GPU メモリの量が削減されます。また、実行時の並列処理を増やすこともできます。理想的には、モデルはターゲットビット深度に量子化されるのではなく、ターゲットビット深度でトレーニングする必要があります。
コンテナの起動時間を最短にするために、読み込み時間が短いモデル形式（GGUF など）を選択します。これらの形式はターゲット量子化タイプをより正確に反映し、GPU への読み込みの際に必要な変換が少なくなります。セキュリティ上の理由から、pickle 形式のチェックポイントは使用しないでください。
ビルド時に LLM キャッシュを作成してウォームアップします。Docker イメージをビルドするときに、ビルドマシンで LLM を開始します。プロンプトキャッシュを有効にして、一般的なプロンプトやサンプルプロンプトをフィードし、実際に使用できるようにキャッシュをウォームアップします。生成された出力を保存して、実行時に読み込みます。
ビルド時に生成した独自の推論モデルを保存します。効率の悪いモデルを読み込み、コンテナ起動時に量子化などの変換を適用する場合と比べると、大幅に時間を節約できます。

デプロイ時