GPU基盤は「クラウド」「オンプレ」「マネージドML」の3択で、稼働率70%を境に費用対効果が逆転するのが経験則です。間欠的な学習・PoC段階ならクラウド従量課金、常時稼働する本番推論で規模が見えていればオンプレ、高速に成果を出したい場合はマネージドMLが合理的です。どれを選んでも、スポットインスタンス・混合精度学習・オートスケーリングの三種の神器を入れないと、請求書を見たときに膝から崩れ落ちる確率が飛躍的に上がります。
GPU基盤が必要なユースケース
GPUはCPUに比べて並列計算に圧倒的に強く、行列演算が主体の機械学習ワークロードでは不可欠な存在です。ただし、ユースケースによって求められるGPUのスペックと台数は大きく異なります。大規模言語モデルの学習には数十〜数千枚のGPUクラスタが必要で、A100やH100クラスの最上位GPUが主流です。一方、画像分類モデルの学習なら1台のA10Gで足りることもあります。
推論ワークロードはさらに幅広く、SLMなら単一のT4で十分な場合もあれば、70B級のLLMを高スループットで動かすにはA100の80GB版×複数枚が必要になります。ファインチューニングは学習と推論の中間で、LoRAのようなパラメータ効率的手法を使えば、比較的小規模なGPUでも実用レベルに到達できます。まずは自社ワークロードがどのカテゴリに属するかを明確にしてから、基盤の選定に入るのが鉄則です。
【GPU基盤の選定フローチャート】
Q1. GPU利用は常時稼働ですか?
├── Yes → Q2. 月間稼働率は70%以上?
│ ├── Yes → オンプレ / 予約インスタンス推奨
│ └── No → クラウド従量課金 + 予約割引
└── No → Q3. スポット中断を許容できる?
├── Yes → スポットインスタンス最優先
└── No → マネージドML サービス
Q4. データ主権・コンプライアンス制約は?
├── 厳しい → オンプレ or 国内クラウドの専用リージョン
└── 通常 → グローバルクラウドで柔軟に選択
MLOpsの基本を押さえたうえで、GPU基盤選定は中長期のコスト構造を決定づける重要な判断です。
クラウドGPUサービスの比較
主要クラウドプロバイダーはそれぞれ個性のあるGPUラインナップを提供しています。AWSはEC2 P5(H100×8)やG6(L4)、GCPはA3(H100)やG2(L4)、AzureはND H100 v5を中核としています。一方、Lambda CloudやCoreWeaveといった専業クラウドは、大手よりも柔軟な予約条件と価格で存在感を増しています。
価格比較を行う際は、オンデマンド単価だけでなく、スポット料金、予約割引、データ転送費用、ストレージコストまで含めたトータルで見積もるのが正解です。オンデマンド単価が安くても、ネットワーク転送費で逆転するケースは珍しくありません。また、GPUの世代が異なると見かけの単価が同じでも実効スループットが大きく異なるため、単価だけの比較は無意味です。
| プロバイダ | 代表GPU | 時間単価(目安) | スポット対応 | マルチGPU | 予約割引 |
|---|---|---|---|---|---|
| AWS P5 | H100×8 | 約98 USD | 〇 | 最大400 GPU | 最大60% |
| AWS G6 | L4 | 約1.3 USD | 〇 | 8 GPU | 最大60% |
| GCP A3 | H100×8 | 約90 USD | 〇 | 最大1,024 GPU | 最大57% |
| Azure ND H100 v5 | H100×8 | 約98 USD | 〇 | 最大400 GPU | 最大65% |
| Lambda Cloud | H100×8 | 約26 USD | 限定的 | 8 GPU | 長期契約のみ |
| CoreWeave | H100×8 | 約50 USD | 〇 | 数千 GPU | 柔軟な長期契約 |
数値は執筆時点の公表価格帯の目安であり、為替や契約条件で変動します。実際の発注前には必ず最新の公式ページと個別見積もりを確認してください。LLMコスト構造の記事も参考に、トータルコストの見極めをおすすめします。
オンプレミスGPU導入の判断基準
オンプレGPU導入は、初期投資が数千万円〜数億円規模になるため、経営判断レベルの話です。判断基準は主に3つ、TCO(総所有コスト)、データ主権、利用率です。TCOはハードウェア購入費、電力費(H100×8台の1ラックで月数十万円)、冷却費、保守契約費、データセンター利用料、人件費の合計で評価します。3〜5年の減価償却期間で平均すると、稼働率が常時70%を超える場合にクラウドを下回る傾向があります。
データ主権やコンプライアンス要求が厳しい業界(金融、医療、官公庁)では、データを国外や他社管理インフラに出せないケースが多く、オンプレ選択が前提となります。ハイブリッドという選択肢も有力で、学習はクラウドの大規模GPUクラスタで一時利用し、推論は自社データセンターで行うことで、双方の長所を取る構成も増えています。
| 項目 | クラウド | オンプレ | ハイブリッド |
|---|---|---|---|
| 初期投資 | ほぼ0 | 数千万円〜 | 中規模 |
| 月額運用費 | 利用量比例 | 固定・減価償却 | 固定+変動 |
| スケール | 即時拡張 | 購入追加が必要 | ピーク時のみ拡張 |
| データ主権 | プロバイダ依存 | 完全に自社管理 | 用途別に振り分け |
| 運用負荷 | 低 | 高(専門人材必要) | 中 |
| 向いている状況 | 間欠利用・PoC | 常時高稼働 | 学習クラウド+推論オンプレ |
オンプレ導入時の落とし穴として、GPUの世代交代速度があります。H100を購入した翌年にBlackwell(B200)が主流になる世界で、3年後の価値を見積もるのは簡単ではありません。AI/ML基盤のコスト管理も併せてご覧ください。
マネージドMLサービスの活用
SageMaker(AWS)、Vertex AI(GCP)、Azure MLといったマネージドMLサービスは、学習ジョブのスケジューリング、スケーリング、モデルホスティング、実験管理までを統合的に提供します。生のEC2やGCEでGPUを借りるより若干割高ですが、インフラ管理コストを大幅に削減できるため、少人数チームには特に恩恵があります。
SageMakerでは、数行のコードでジョブを起動し、完了後に自動でインスタンスを停止できます。手動でEC2を起動して学習し、停止し忘れて週末に大量請求を受けるといった事故がほぼ発生しません。下記は最小構成のSageMaker学習ジョブ起動例です。
import sagemaker
from sagemaker.pytorch import PyTorch
session = sagemaker.Session()
role = "arn:aws:iam::123456789012:role/SageMakerRole"
estimator = PyTorch(
entry_point="train.py",
source_dir="src",
role=role,
instance_type="ml.p4d.24xlarge", # A100 x 8
instance_count=1,
framework_version="2.1",
py_version="py310",
use_spot_instances=True,
max_run=3600,
max_wait=7200,
hyperparameters={"epochs": 10, "batch_size": 128},
)
estimator.fit({"train": "s3://mybucket/train"})
上記では`use_spot_instances=True`でスポットインスタンスを指定しており、中断時には`max_wait`の範囲で再試行が自動的に行われます。Vertex AIやAzure MLも同様の概念を提供しており、Python SDKで統一的にジョブを記述できます。
GPU最適化のベストプラクティス
GPU基盤を選ぶだけでは、コストは最適化されません。実行時の工夫で50%以上のコスト削減が可能です。スポットインスタンスは最有力候補で、チェックポイントを定期保存する仕組みさえあれば、中断リスクは管理可能です。混合精度学習(FP16/BF16)は、学習速度を2倍近く上げつつメモリ使用量を半減させるため、現代のMLでは標準装備です。GPU共有(MIG、Fractional GPU)は、単一GPUを複数ワークロードで分割利用する技術で、推論の多重化に効果的です。
# PyTorch Lightning でスポット + 混合精度 + チェックポイント
import lightning as L
from lightning.pytorch.callbacks import ModelCheckpoint
checkpoint_cb = ModelCheckpoint(
dirpath="s3://mybucket/ckpt",
every_n_train_steps=100,
save_top_k=3,
monitor="val_loss",
)
trainer = L.Trainer(
accelerator="gpu",
devices=8,
strategy="ddp",
precision="bf16-mixed", # 混合精度
callbacks=[checkpoint_cb],
max_epochs=50,
)
trainer.fit(model, datamodule=dm, ckpt_path="last")
`ckpt_path=”last”`を指定することで、スポット中断後の再起動時に最後のチェックポイントから自動で再開します。LLM推論コスト削減とファインチューニング実践の記事も併せると、実運用での最適化ポイントが見えてきます。LLM推論基盤構築では、推論側の最適化を詳しく扱っています。
まとめ
GPU基盤は「いつ・どれくらい・何に使うか」で最適解が変わります。常時稼働するならオンプレ、間欠利用ならクラウド、高速に成果を出したいならマネージドML。どの選択肢でも、スポット、混合精度、オートスケーリングの併用は必須です。費用対効果を定量的に試算せず「とりあえずクラウド」で走り出すと、3ヶ月後に経営層から詰められる可能性が極めて高いと申し添えておきます。
よくある質問
Q. AI開発にGPUは必ず必要ですか?
A. LLMの学習やファインチューニングには基本的に必須です。推論のみであればCPUで可能な場合もありますが、レイテンシとスループットの要件によっては現実的ではありません。外部API利用に徹するのであればGPU不要です。
Q. クラウドGPUとオンプレGPUのどちらが安いですか?
A. GPU稼働率が70%以上を常時超える場合、オンプレの方がTCOが低くなる傾向があります。間欠的な利用であればクラウドの従量課金が有利です。自社の利用パターンを実測してから判断することを推奨します。
Q. スポットインスタンスでGPU学習は可能ですか?
A. チェックポイント保存と自動再開の仕組みを実装すれば可能です。コストを50〜70%削減できますが、中断リスクへの対策(処理の冪等性、状態保存、再開ロジック)が前提です。