推論サービング・信頼性・コスト最適化
文書基準: 2026年9月 | この文書は変化の速い領域であり、四半期ごとのレビュー対象です。
GPUインフラは構築後の運用段階でコストと安定性が分かれます。この文書は推論サービング（遅延・オートスケール）、障害復旧（チェックポイント・ノード再投入）、そしてGPU容量の確保とコスト最適化（コミット・スポット・容量予約）を扱います。特に2026年現在は、性能よりも欲しいときにGPUを実際に確保できるかが最大の制約です。
推論と学習は性格が異なります。学習が長く・大きく・一度に回す仕事だとすれば、推論はユーザーのリクエストが来るたびに素早く応答し、リクエスト量に応じて自動で増えたり減ったりする必要があります。
推論サービング
Section titled “推論サービング”推論は学習と相反する運用プロファイルを持ちます。学習が長時間・高通信・バッチ志向であるのに対し、推論は遅延に敏感・リクエスト単位・オートスケール志向です。
- 遅延 vs スループット — リアルタイムサービングは低遅延（速い応答）が、バッチ推論は高スループット（一度に多く）が目標です。動的バッチング（dynamic batching = 短い時間に入ってきたリクエストをまとめて一度に処理）で両者のバランスを取ります。
- オートスケール — リクエスト量に応じてGPUレプリカを増減します。ただしGPUは起動時にモデルの重みをメモリに載せる時間（コールドスタート）が長く、CPUより反応が遅いです。そのため最低数台は常に点けておくか、あらかじめ予熱しておきます。
- モデル並列サービング — 単一のGPUに収まらない大型モデルは、推論でもテンソル並列を使います。（並列化戦略を参照）
- トークン単位のコスト・ルーティング — ファウンデーションモデルAPIのトークンコスト・プロンプトキャッシング・モデルルーティングはLLMOpsとAIプラットフォームとモデル比較 — 推論コスト最適化で扱います。
信頼性・障害対応
Section titled “信頼性・障害対応”ノードが多いほど、学習の途中でハードウェアが故障する確率が高くなります。数百枚GPU規模では故障が例外ではなく日常です。そこで「故障は起きる」を前提に備えます。
- 故障検知 — ノードヘルスチェックとGPUエラー信号（Xidエラー = NVIDIAドライバが報告するGPUエラーコード、メモリエラー、通信リンク切れ）で異常ノードを素早く見つけて隔離します。
- チェックポイントで再開 — 最後に保存しておいた地点（チェックポイント）から再び始めます。故障したノードは交換し、残りのノードはしばらく待ってから再び合わせます。
- 遅いノード（straggler）対応 — 1ノードだけ遅くなっても（ネットワーク問題や発熱による速度低下）、全体がそのノードを待って一緒に遅くなります。こうした遅いノード（straggler）を見つけて隔離・交換します。
- マネージドクラスターの自動復旧 — マネージドGPUクラスター（例: SageMaker HyperPod）は故障検知・自動交換・チェックポイント再開を丸ごと提供し、この負担を軽くします。
2026年現在、最新世代のGPUは必要なときに即座に確保できないことが多いです。容量の確保はインフラ設計の第一級の制約です。
| 項目 | AWS | Azure | Google Cloud | OCI |
|---|---|---|---|---|
| 容量予約 | Capacity Blocks for ML、On-Demand Capacity Reservations | On-Demand Capacity Reservations | Future Reservations、Calendar mode | Capacity Reservation |
| コミット割引 | Savings Plans、Reserved Instances | Reserved VM Instances | CUD (Committed Use Discount) | Universal Credits、コミット |
| プリエンプティブル | Spot Instances | Spot VMs | Spot VMs | Preemptible Instances |
- 容量ブロック・予約キュー — 特定期間のGPU容量を事前に予約します。大規模学習は開始前の容量確保が前提です。
- リージョンの希少性 — 最新のGPUは少数のリージョンにのみあり、数量が限られます。希望するリージョン・世代の実際の可用性を事前に確認する必要があります。
- マルチリージョン・マルチクラウドフォールバック — 単一リージョンの容量不足に備え、代替リージョン・世代をフォールバックとして準備します。データの所在・イグレスコストを一緒に考慮します。
コスト最適化
Section titled “コスト最適化”GPUはクラウドで最も高価なリソースであるため、利用率と購入方式がコストを左右します。
- 購入方式の組み合わせ — 常時稼働ワークロードはコミット割引（Savings Plans/CUD/RI）で、学習・バッチはプリエンプティブル（Spot）で、予測可能な大規模学習は容量予約で配分します。
- プリエンプティブル + チェックポイント — プリエンプティブルは最大で数十%安いですが中断される可能性があるため、チェックポイントと組み合わせて中断時に再開します。
- right-sizing — ワークロードに過大なGPU世代を使いません。推論・ファインチューニングは上位世代が不要な場合が多いです。
- アイドル回収 — GPU共有（MIG/time-slicing）とアイドルノードのスケールダウンで浪費を減らします。
- GPU時間のFinOps — GPUの時間単位コスト・利用率をチーム別に配分・追跡する体系はFinOpsで、モデルライセンス・使用料はAIライセンシングで扱います。
この文書はGPUインフラシリーズの最終部（第4部）です。シリーズ全体はGPUワークロードの特性とリファレンスアーキテクチャから始まります。
- クラスターアーキテクチャ・マネージドクラスター — GPUワークロードの特性とリファレンスアーキテクチャ
- 並列化・チェックポイント — 分散学習の標準アーキテクチャ
- スケジューリング・GPU共有・可観測性 — GPU Kubernetesとスケジューリング
- コスト配分・予算 — FinOps
- トークン・プロンプトコスト — LLMOps
よくある間違い
Section titled “よくある間違い”- 容量確保を設計の最後に確認 — 希望するリージョン・世代のGPUがなく、プロジェクトのスケジュールが遅延
- 推論に学習と同じ構成を使用 — 遅延・オートスケールの要求を無視し、学習用の大規模構成をそのまま適用してコストを浪費
- プリエンプティブルをチェックポイントなしで学習に使用 — 中断時に進捗をすべて失う
- 利用率モニタリングなしの常時オンデマンド — アイドルのGPUをオンデマンドで点けっぱなしにし、コストが累積
チェックリスト
Section titled “チェックリスト”- 推論サービングに動的バッチング・オートスケール・コールドスタート緩和を適用したか
- 大規模学習に障害検知とチェックポイントベースの自動再開を構成したか
- 希望するリージョン・世代のGPU容量を事前に確認し、予約したか
- マルチリージョン/フォールバック戦略をデータの所在・イグレスと一緒に検討したか
- コミット・プリエンプティブル・容量予約をワークロード特性に合わせて組み合わせたか
- GPU利用率をチーム別に追跡し、FinOpsに連携したか