AI ワークロードを改善するための 5 つのヒントとコツ
Maciej Strzelczyk
Developer Programs Engineer
Sean Derrington
Group Product Manager, Storage
※この投稿は米国時間 2025 年 3 月 19 日に、Google Cloud blog に投稿されたものの抄訳です。
Google は最近、個人向け AI コーディング アシスタントの無料バージョンである Gemini Code Assist を発表しました。以前は大企業しか利用できなかったテクノロジーが、今ではスタートアップや個人の開発者にも手の届くものとなっています。同じ状況が、高性能な GPU、専用の TPU、非常に効率的なストレージ ソリューションなどの AI / ML 関連のインフラストラクチャにも当てはまります。
ただ、アクセシビリティは向上しているものの、こういったリソースは依然として非常に高価であるため、企業は大規模な AI ワークロードを最適化する方法を必要としています。費用を削減するには、ワークロードを最適化する方法を常に模索することが重要です。この記事では、Google Cloud Platform でのワークフローを最適化するための 5 つのヒントをご紹介します。
免責条項: すべてのアイデアがすべてのユースケースに適合するわけではありません。これらは公式の推奨事項ではありません。
1. トレーニング / 推論を実行するさまざまなプラットフォームを調査する
数年前までは、AI モデルをトレーニング、チューニング、使用するには、GPU または TPU を搭載したマシンのクラスタを手動でセットアップし、トレーニング パイプライン全体をオーケストレートして、このプロセスで消費されるすべてのリソースを慎重に管理する必要がありました。Kubernetes を使用することで少しは楽になりますが、それ以外に AI の作業を楽にしてくれる広く利用可能なサービスはありませんでした。そのため、使用したハードウェアの費用だけでなく、このインフラストラクチャ全体を管理するために費やした時間にも余計に費用が発生していました。
幸い、今ではその必要はありません。Google Cloud は、フルマネージドからフルカスタマイズまで、ジョブの実行に役立つ幅広いソリューションを提供しており、必要に応じて選択できます。以下にその概要をまとめます。
-
Vertex AI は、フルマネージド型の統合 AI 開発プラットフォームです。トレーニング、チューニング、推論など、すべてをシンプルなウェブ インターフェースで実行できます。ワークロードに必要なインフラストラクチャの管理をすべて Google に任せることで、多くの労力と悩みを軽減できます。また、使用した分に対してのみ料金が発生するため、次のタスクを待機するアイドル状態の GPU によって費用が発生することはありません。
-
Cloud Run では、GPU 搭載マシンでコンテナを実行するオプションが利用可能になりました。これは、新しいプラットフォームを学習する必要なく、スケーラブルなフルマネージド推論サービスを設定できる優れた方法です。
-
Cloud Batch は GPU へのアクセスも提供しています。これは、AI モデルのトレーニングやチューニングなどの長時間実行されるタスクに最適なオプションです。Cloud Batch は必要なすべてのインフラストラクチャのプロビジョニング、エラーが発生したジョブの再試行、ジョブ完了後の使用済みリソースの解放をすべて処理します。自動再試行機能とスポット インスタンスを組み合わせることで、ワークロードの費用を大幅に削減できます。
-
Google Kubernetes Engine（GKE）では、インフラストラクチャを制御しながら、プロビジョニング、設定、管理をすべて処理できます。すでに Kubernetes を使用しており、Kubernetes が提供する制御機能のメリットを最大限に活用するために必要な経験を有している組織にとって、最適なソリューションです。
-
Google Compute Engine（GCE）は、「人による操作が不要なスケール」という側面を持つ Vertex AI とは対照的なプロダクトです。GPU または TPU を搭載した仮想マシンに直接アクセスすることで、ワークフローのあらゆる側面を完全に制御できます。
2. 推論コンテナの起動時間を短縮する
GKE または Cloud Run を使用する場合は、モデルをコンテナに直接保存しないでください。コンテナを軽量に保ち、Cloud Storage（FUSE を使用）、Filestore、読み取り専用永続ディスクの共有などのオプションを使用してモデルを外部に保存します。
その理由は、モデルが埋め込まれた重たいコンテナはスケールアップに時間がかかるためです。ノードは、実行を開始する前に、これらの巨大なイメージをダウンロードする必要があります。さらに、高スループット用に最適化されていないノード ストレージに負荷がかかります。モデルを外部にマウントすることでコンテナから分離でき、すべてがより高速かつスムーズになります。コンテナの起動が早くなるとスケーリングが簡単になり、ノードのボトルネックも回避できます。
注意: コンテナは一時的かつ軽快なもので、必須要素だけを保持することを目的としています。モデルはサイズが大きく、長期間の保存が必要です。そのため、コンテナとモデルは別々に管理し、外部ストレージを使用して高速かつ効率的な自動スケーリングのデプロイを構築しましょう。
作業中のコンテナを変更できない場合、GKE ではセカンダリ ブートディスクを使用して新しいノードの起動プロセスを高速化するオプションがあります。セカンダリ ブートディスクを持つノードは、コンテナ イメージの一部がすでにプリロードされている追加ディスクを使用して起動します。起動時間についての話題になったので、GKE のイメージ ストリーミング機能についても確認することをおすすめします。この機能では、AI 関連のワークロードだけでなく、すべてのワークロードの起動を高速化できます。
3. ストレージは見た目ほど単純なものではない
ML では通常、有用な結果を生成するために数百 TB から PB 単位の大量のデータを必要とします。特に、テキスト以外のデータやマルチモーダル モデルを扱う場合はその傾向が顕著になります。トレーニング、チェックポイント、サービング中の GPU / TPU の使用率（グッドプット）を最大化することは非常に重要であり、多くの場合、簡単な作業ではありません。少数のノードと数 TB のデータを使用する小規模な AI ワークロード要件の場合、Filestore が「シンプル」な NFS ソリューションとして適しています。
オブジェクト ストレージを使用するように AI ワークロードを記述している企業にとって、Cloud Storage はあらゆる規模の AI / ML ワークロードに適したフルマネージド オブジェクト ストレージ サービスです。しかし、多くの企業の AI ワークロードではファイル システム インターフェースが必要です。Cloud Storage FUSE を使用すると、Cloud Storage バケットをファイル システムとしてマウントできます。Cloud Storage FUSE は Portable Operating System Interface（POSIX）に完全に準拠しているわけではないため、その制限事項と従来のファイル システムとの違いを理解することが重要です。Cloud Storage FUSE を使用することで、Cloud Storage のスケール、手頃な価格、パフォーマンスを活かしてトレーニング データ、モデル、チェックポイントにアクセスできます。
低レイテンシが求められ、小規模なファイルで作業するワークロードには、Google Cloud のフルマネージド スクラッチ並列ファイル システムである Parallelstore が最適です。このシステムは、高スループットと高い IOPS（1 秒あたりの入出力オペレーション）、かつ低レイテンシ（ミリ秒未満）のアクセスを必要とする AI および ML ワークロードに適しています。Parallestore のリファレンス アーキテクチャはこちらをご覧ください。
サービング ニーズよっては、Hyperdisk ML は高性能ストレージ ソリューションとして特にサービング タスクに適しており、最大 2,500 台の仮想マシンで非常に高い合計スループット（～1 TB/秒）を同時に提供できます。
4. DWS や将来の予約を使用してリソースを入手する
大規模なジョブを実行するためのハードウェアの調達には費用がかかります。すべてのデータをそろえて作業を開始しようとしたところ、利用可能な GPU が足りないことがわかりました。この予期せぬ事態は明確な形で費用を発生させるわけではありませんが、スケジュールを調整して必要なリソースを「探す」必要が生じることで、作業に遅れが生じます。時は金なりです。Dynamic Workload Scheduler と将来の予約を使用すると、このような問題を軽減できます。
将来の予約は、その名のとおりの働きをします。つまり、将来使用する予定の Cloud リソースを予約できます。予約がシステムに承認されると、必要な GPU の可用性について心配する必要がなくなります。時期が来ると、システムはプロジェクトのハードウェアに対してリクエストされた予約を提供します。提供が開始されるとその予約を自由に使用できるようになります。予約が存在する限り、そのリソースは対象のお客様のみが利用できます。これらのリソースには、利用しているかどうかに関係なく料金が発生することにご注意ください。
Dynamic Workload Scheduler（DWS）は、人気の高いハードウェアの入手を容易にするために複数の Google Cloud プロダクトで使用されているバックエンド プラットフォームです。Flex モードと Calendar モードを使用すると、他の Cloud ユーザーが GPU を解放した際に、それを 1 つずつ取得しようとして時間と費用を浪費してしまうことがなくなります。こちらの動画では、DWS の詳細と、さまざまなプロダクトでどのように活用されているかについてご紹介しています。
5. カスタム ディスク イメージを使用して設定を高速化する
仮想マシンで AI ワークロードを実行するには、多くの設定が必要です。最新のオペレーティング システムへの更新、GPU ドライバのインストール、AI フレームワーク（JAX、Pytorch、Tensorflow など）のインストールと構成が必要になります。このようなシステムの完全なセットアップは、クリーンなオペレーティング システム イメージから開始する場合、OS イメージの最新性や選択したソフトウェアによっては 1 時間かかることもあります。このような設定は一度だけ行えばいい、というのが理にかなっていると思いませんか？
このような場面では、カスタム ディスク イメージが真価を発揮します。VM を一度構成し、必要なソフトウェアをすべてインストールしてシャットダウンします。構成された VM のディスクに基づいてディスク イメージを作成すれば、あとはニーズに合わせて完全に構成された新しいワーカーを数秒で起動できるようになります。さらに簡単にするには、イメージ ファミリーとマネージド インスタンス グループを利用して、Google Cloud に設定のローリング アップデートを自動的に処理させるようにします。
始める
Google Cloud におけるすべての最新情報を入手するには、次の方法をぜひご検討ください。
-デベロッパー プログラム エンジニア Maciej Strzelczyk
-ストレージ担当グループ プロダクト マネージャー Sean Derrington
