GPU は『調達』と『稼働率』で勝負が決まる
LLM/画像生成/レコメンド等で GPU 需要は爆増、調達難・コスト管理が運用の主課題になりました。本記事では編集部の視点で、GPU インフラ運用を公開情報をもとに整理します。PyTorch 実践 もご参考に。
GPU 調達の選択肢
(1) AWS EC2 (p4/p5/g5/g6)：オンデマンド / リザーブド / スポット。(2) Google Cloud A2/A3：スポット相当の SpotVM が割安。(3) Azure NC/ND：エンタープライズ親和性。(4) 専門クラウド：CoreWeave / Lambda Labs / Modal。(5) オンプレ：自社所有で長期コスト最適化。NVIDIA H100/A100/L40S 等のチップ選定も実利用に合わせる必要があります。最新は各公式情報を。
スポット/プリエンプティブの活用
(1) 大幅割引：オンデマンドの50〜90%引き(公開情報をもとに)。(2) 中断対応：チェックポイント保存が前提。(3) マルチAZ/リージョン：在庫切れリスク分散。(4) 学習向き：推論本番は不向き。(5) 料金履歴を週次でチェック。
キュー/ジョブ管理
(1) SLURM / Ray / Kubeflow：ジョブスケジューラ。(2) Kubernetes + NVIDIA Device Plugin：コンテナ実行。(3) キュー設計：実験/本番/緊急の優先度。(4) マルチテナント：チーム別の予算管理。(5) ノード故障時の自動リトライ。Kubernetes 本番運用 も合わせて。
監視とトラブルシュート
(1) GPU 使用率：nvidia-smi / DCGM。(2) VRAM 使用量：OOM 前兆を検知。(3) 温度・電力：故障の早期発見。(4) 分散学習の通信量：NCCL の効率。(5) ECC エラー：ハードウェア故障の兆候。Observability 実践 も合わせて。
コスト最適化
(1) 稼働率を上げる：50% 以下なら設計見直し。(2) 動的スケール：夜間/週末は縮退。(3) 右サイジング：A100 必要か L40S で足りるか。(4) 推論の量子化：FP16/INT8/INT4 で枚数削減。(5) キャッシュ：プロンプト/結果キャッシュで API 呼出削減。
失敗しがちなパターン
(1) 稼働率10%でリザーブド購入：固定費の浪費。(2) スポット中断で学習やり直し。(3) VRAM 不足で OOM 連発。(4) NCCL の通信ボトルネック：低速ネットで分散学習が遅い。(5) 監視なし：故障に気付かない。対策は、(1)使用量分析→契約見直し、(2)チェックポイント自動化、(3)バッチサイズ調整、(4)RDMA/InfiniBand、(5)DCGM必須、です。