Cloud GPUs

解決する課題

• 機械学習の学習や推論、科学技術計算、レンダリングなど、CPU だけでは時間がかかりすぎる並列計算を高速化したい
• GPU 搭載のサーバーを自前で調達・運用したくない（高価で陳腐化が早く、調達リードタイムも長い）
• 一時的にしか GPU を使わないので、必要な時だけ確保して使い終わったら手放したい
• 既存の Compute Engine や GKE のワークフローを変えずに、GPU だけを後付けしたい

これらに応えるのが Cloud GPUs です。GPU を独立した製品として買うのではなく、Compute Engine インスタンスや GKE ノードに接続するアクセラレーターとして、必要な台数だけ確保して従量課金で使えます。AWS の EC2 アクセラレーテッドインスタンス（P/G 系） に相当する位置づけです。

主要概念と用語

• GPU（アクセラレーター）: 多数のコアで並列計算を担う演算装置。NVIDIA の各世代（例: T4、L4、A100、H100 など）が提供され、用途に応じて選ぶ
• アクセラレーター最適化マシンファミリー（A シリーズ・G シリーズ）: GPU が標準で組み込まれた専用マシンタイプ。最新世代の GPU はこの形態で提供されることが多い
• GPU の接続（アタッチ）: 汎用マシンに GPU を追加で付与する方式。N1 など対応するマシンタイプに対し、台数を指定して接続する
• NVIDIA ドライバ / CUDA: GPU を使うためのドライバとライブラリ。インスタンス起動時に自動導入する仕組みや、ドライバ導入済みイメージを利用できる
• GPU メモリ（VRAM）: GPU 上の高速メモリ。学習・推論で扱えるモデルやバッチの大きさを左右する
• Spot GPU: 中断を許容する代わりに大幅に安く GPU を使えるプロビジョニングモデル
• NVLink / 高速インターコネクト: 複数 GPU 間を高帯域で結ぶ接続。大規模分散学習で効果を発揮する

仕様・制限・クォータ

• GPU は特定のリージョン・ゾーンでのみ利用でき、GPU の種類によって提供される場所が異なる。設計時に対象ゾーンでの在庫・提供有無を確認する
• GPU は互換性のあるマシンタイプにのみ接続できる。汎用マシンに後付けする方式と、GPU が組み込まれた A／G 系を使う方式がある
• プロジェクト・リージョンごとに GPU 数のクォータがあり、初期値は小さいことが多い。本番利用前に引き上げ申請が要る場合がある
• GPU 付きインスタンスは、計画メンテナンス時にライブマイグレーション非対応な構成が多く、停止・再起動を伴うことがある。メンテナンスポリシーを確認する
• 利用には NVIDIA ドライバが必要。ドライバ導入済みイメージや起動時の自動導入を使うと運用が楽になる
• 具体的な GPU の種類・台数上限・提供ゾーン・価格は変動するため、本番設計時は公式ドキュメントと自プロジェクトの割り当てを必ず確認する

内部の仕組み

Cloud GPUs では、GPU が物理ホストに搭載され、その上で動く仮想マシンに**パススルー（直接割り当て）**される形で提供されます。利用者は GPU の種類と台数を指定してインスタンスを起動し、ホスト側の GPU を専有して計算に使います。

GPU を使うには NVIDIA ドライバと CUDA などのランタイムが必要で、ドライバ導入済みのイメージや、起動スクリプトによる自動導入の仕組みが用意されています。GKE では、ノードプールに GPU を指定するとドライバの導入やデバイスの公開がマネージドに行われ、Pod から GPU をリソースとして要求できます。

複数 GPU を使う大規模学習では、GPU 間を結ぶ NVLink などの高速インターコネクトや、ノード間の高帯域ネットワークが性能を左右します。アクセラレーター最適化マシンファミリーは、こうした GPU 間・ノード間の通信を前提に設計されています。ストレージは、学習データを Cloud Storage に置き、高速な一時領域として Local SSD を併用するといった構成が一般的です。

設計パターン / ベストプラクティス

• 用途に GPU を合わせて選ぶ。推論や軽量な学習は低コストの GPU（例: T4／L4 系）、大規模学習は高性能 GPU（例: A100／H100 系）といった使い分けをする
• 中断を許容できる学習・バッチは Spot GPU を主に使い、チェックポイントを定期保存して中断から再開できるようにする
• データは Cloud Storage に集約し、GPU インスタンスはステートレスに保つ（再作成や中断でデータが消えても再実行できる設計）
• 大規模分散学習では、GPU 間・ノード間の通信帯域がボトルネックになりやすいため、高速インターコネクトを備えた構成や近接配置を選ぶ
• Kubernetes 前提なら GKE の GPU ノードプールを使い、推論サービスは負荷に応じてスケールさせる
• GPU は高価なので、アイドル時間を作らない。使い終わったらインスタンスを停止・削除し、無駄な課金を避ける

運用・監視

• GPU の使用率・メモリ使用量・温度などは Cloud Monitoring のメトリクスで把握し、過剰スペックや使用率の低さを検知する
• 学習・推論のログは Cloud Logging に集約し、エラーや GPU 認識失敗（ドライバ未導入など）を追跡する
• 起動時に GPU が認識されない場合は、まずドライバの導入状況とマシンタイプと GPU の互換性、対象ゾーンでの提供有無を切り分ける
• Spot GPU を使う場合は中断イベントを監視し、チェックポイントからの自動再開を組み込む
• クォータ不足や容量逼迫で確保に失敗することがあるため、別ゾーンへのフォールバックや引き上げ申請を運用に組み込む

コスト

GPU は接続している時間に対して課金され、本体インスタンスやディスク・ネットワークの料金とは別に加算されます。単価は GPU の種類で大きく異なるため、用途に対して過剰な GPU を選ばないことがコスト最適化の起点になります。

セキュリティ

• GPU インスタンスには専用のサービスアカウントを割り当て、必要な API と Cloud Storage バケットだけに限定する（鍵のハードコードを避ける）
• インスタンスは特定の VPC・サブネットに配置し、外部 IP を付けないなどネットワーク到達範囲を最小化する
• 学習データやモデルなどの機密情報は Cloud Storage に保管し、アクセスを IAM で絞る。資格情報は Secret Manager から取得する
• ディスクは既定で暗号化され、要件に応じて CMEK で自前鍵も使える
• 誰がどの GPU インスタンスを作成・操作できるかを IAM で最小権限に制御する

関連サービス・比較

汎用的な GPU 資産（CUDA ベースのコードや既存ライブラリ）をそのまま使いたいなら Cloud GPUs、Google 自社開発の ML 特化アクセラレーターで大規模学習を効率よく回したいなら Cloud TPU、という棲み分けになります。Kubernetes 前提のワークロードは GKE の GPU ノードプール、単発の大規模バッチは Google Cloud Batch に GPU を組み合わせる構成も選べます。

ハンズオン / CLI例

# N1 マシンに NVIDIA T4 GPU を1枚接続してインスタンスを作成
# （--maintenance-policy=TERMINATE は GPU 構成で必要になる場合がある）
gcloud compute instances create gpu-vm \
  --zone=asia-northeast1-a \
  --machine-type=n1-standard-4 \
  --accelerator=type=nvidia-tesla-t4,count=1 \
  --maintenance-policy=TERMINATE \
  --image-family=debian-12 \
  --image-project=debian-cloud

# 指定ゾーンで利用できるアクセラレーター（GPU）の種類を一覧表示
gcloud compute accelerator-types list \
  --filter="zone:asia-northeast1-a"

# 不要になったら削除してアイドル課金を止める
gcloud compute instances delete gpu-vm \
  --zone=asia-northeast1-a