GPU オーケストレーションのための Kubernetes：数千台規模の GPU クラスター管理
2025年12月8日更新
2025年12月アップデート： Kubernetes 1.31+ の動的リソース割り当て（DRA）が一般提供開始され、きめ細やかな GPU パーティショニングとタイムスライシングが可能になりました。NVIDIA GPU Operator 24.6+ では Blackwell サポートと改良された MIG 管理が追加されました。Kueue（Kubernetes ネイティブジョブキューイング）が AI ワークロードでの本番成熟度に到達しています。Run:ai と CoreWeave が Kubernetes 上で 50,000+ GPU クラスターを実証しています。マルチクラスター連携ツール（Liqo、Admiralty）によるクロスクラウド GPU オーケストレーションが可能になりました。マルチテナント推論デプロイメントでの vGPU サポートが向上しています。
OpenAI は複数の Kubernetes クラスター上で 25,000 台の GPU をオーケストレーションして GPT モデルを訓練しており、GPU 障害を自動処理し、ワークロードをリアルタイムで再バランシングし、平均 2.5 時間ごとに発生するハードウェア障害にもかかわらず 97% の稼働率を維持するカスタムオペレーターを使用しています。¹ 同社のインフラチームは、バニラ Kubernetes が大幅な改良なしには約 5,000 ノードで破綻することを発見し、階層クラスター連携、カスタムスケジューリングアルゴリズム、そして 3 万ドルの H100 各台を個別追跡が必要な貴重なリソースとして扱う GPU 対応オートスケーリングの実装を余儀なくされました。大規模な GPU 管理は CPU オーケストレーションとは根本的に異なります。分散訓練中の GPU 障害は数百万ドルのコンピューティング時間を無駄にする可能性があり、NVLink で接続された GPU を分離する不適切なスケジューリングは 8 倍のパフォーマンス低下を引き起こします。Kubernetes 上で数千台の GPU を成功裏にオーケストレーションしている組織は、ベアメタル管理と比較して 35% 優れた稼働率、60% 高速なデプロイメント時間、90% の運用オーバーヘッド削減を報告しています。²
Kubernetes は 88% の市場シェアでコンテナオーケストレーションを支配していますが、GPU サポートの登場は遅く、大規模では依然として困難です。³ 2019 年にリリースされた NVIDIA GPU Operator は、ついに Kubernetes にエンタープライズグレードの GPU 管理をもたらし、動的ドライバーインストール、自動デバイスプラグインデプロイメント、GPU ヘルスモニタリングなどの機能を実現しました。Kubernetes 上で AI ワークロードを実行する組織は、デバイスプラグイン設定、ノードアフィニティルール、トポロジー対応スケジューリング、そして単一チームが GPU リソースを独占することを防ぐリソースクォータをナビゲートする必要があります。しかし、GPU オーケストレーションにおいて Kubernetes を習得した組織は、数千台の GPU を単一のプログラム可能リソースプールとして扱う能力を獲得し、従来の HPC スケジューラーでは不可能な稼働率と運用効率を達成しています。
GPU デバイスプラグインアーキテクチャ
Kubernetes デバイスプラグインフレームワークは、クラスター全体での GPU 発見、割り当て、ヘルスモニタリングを可能にします：
NVIDIA GPU Device Plugin は Kubernetes と NVIDIA GPU 間の主要インターフェースとして機能します。⁴ プラグインは各 GPU ノードで DaemonSet として実行され、kubelet に GPU をスケジュール可能リソースとして登録します。初期化時、プラグインは NVIDIA Management Library（NVML）をクエリして利用可能な GPU、そのメモリ容量、コンピューティング能力、相互接続トポロジーを発見します。プラグインは nvidia.com/gpu リソース名を使用して GPU を Kubernetes スケジューラーにアドバタイズし、ポッドが標準リソース仕様を通じて GPU を要求できるようにします。
デバイスプラグイン登録フロー： 1. プラグインが開始し、NVML 経由でローカル GPU を発見 2. /var/lib/kubelet/device-plugins/ の Unix ソケットを通じて kubelet に登録 3. 一意のデバイス ID で利用可能な GPU をアドバタイズ 4. コンテナ GPU 割り当てのための Allocate() RPC を実装 5. GPU ヘルスを監視し、障害を kubelet に報告 6. ポッド終了時の GPU クリーンアップを処理
Multi-Instance GPU（MIG）サポート により、A100 および H100 GPU を分離されたインスタンスに分割できます。⁵ 各 MIG インスタンスは Kubernetes にとって個別の GPU として表示され、きめ細やかなリソース割り当てが可能です。デバイスプラグインは MIG プロファイルを管理し、インスタンスの作成、削除、割り当てを処理します。組織は未活用 GPU を小規模ワークロード用に分割することで 7 倍優れた GPU 稼働率を達成します。MIG 設定は、分割モードがノードのドレインなしには変更できないため、慎重な計画が必要です。
代替デバイスプラグイン でベンダー多様性を提供： - AMD Device Plugin：MI250X などの ROCm 対応 GPU をサポート - Intel Device Plugin：Intel GPU と Gaudi アクセラレーターを管理 - Xilinx FPGA Device Plugin：FPGA リソースをオーケストレーション - Google TPU Device Plugin：GKE クラスター用
GPU ワークロードのスケジューリング戦略
効果的な GPU スケジューリングは、パフォーマンスを維持しながら稼働率を最大化します：
ギャングスケジューリング は、分散訓練ジョブが要求されたすべての GPU を同時に受け取ることを保証します。ギャングスケジューリングなしでは、部分的なリソース割り当てがデッドロックを引き起こします。ジョブは決して利用可能にならない残りの GPU を永遠に待ち続けます。Volcano や Apache YuniKorn などの Kubernetes スケジューラープラグインは、PodGroups を通じてギャングスケジューリングを実装します。⁶ ジョブは最小 GPU 要件を指定し、スケジューラーはすべてのリソースを割り当てるか、ジョブ全体をキューに入れます。ギャングスケジューリングはクラスター稼働率を 10-15% 削減しますが、訓練ジョブの餓死を防ぎます。
トポロジー対応スケジューリング は、ハードウェア相互接続に基づいて GPU 配置を最適化します。NVLink で接続された GPU は PCIe 経由の 32GB/s に対して 600GB/s の帯域幅を達成します。⁷ スケジューラーはノードトポロジーを検査して、高速相互接続を持つ GPU に関連ポッドを配置します。NVIDIA GPU Feature Discovery は、アフィニティルールを可能にするトポロジー情報でノードにラベルを付けます。不適切なトポロジー決定は、通信集約的ワークロードで 3-8 倍のパフォーマンス低下を引き起こします。トポロジー対応性は 8 GPU を超えるジョブで重要になります。
ビンパッキング vs 分散: ビンパッキングはワークロードをより少数のノードに統合し、キャッシュ局所性を改善し、ネットワークトラフィックを削減します。分散はノード間で作業を分散し、障害耐性と熱管理を向上させます。最適な戦略はワークロード特性に依存します。訓練ジョブはビンパッキングから利益を得て、推論は分散を好みます。動的戦略はクラスター稼働率とワークロードミックスに基づいて調整します。
優先度とプリエンプション: 本番ワークロードは開発ジョブよりも高い優先度を受けます。スケジューラーはリソースが不足した時に低優先度ポッドをプリエンプトします。慎重な優先度設定により、研究ジョブが本番推論をブロックすることを防ぎます。プリエンプションチェックポイントは訓練進捗の損失を防ぎます。優先度クラスはシステム重要（1000000）から開発（100）までの範囲です。
フェアシェアリングとクォータ: リソースクォータは単一チームの GPU 独占を防ぎます。階層クォータは組織全体の制限とチーム固有のサブクォータを可能にします。フェアシェアスケジューリングは時間経過による公平なリソース分配を保証します。リソース消費が少ないユーザーは将来のバースト容量のためのクレジットを蓄積します。Kueue などのキューシステムは高度な入場制御付きジョブキューイングを提供します。
スケーリング考慮事項
Kubernetes を数千台の GPU にスケーリングするにはアーキテクチャの変更が必要です：
クラスターサイズ制限: 単一 Kubernetes クラスターは、etcd パフォーマンスが劣化する前に最大 5,000 ノードをサポートします。⁸ API サーバー負荷は watch メカニズムによりノード数に対して二次的に増加します。コントローラーマネージャー調整ループは 1,000 ノードを超えると遅くなります。ネットワークポリシーは大規模では扱いにくくなります。ほとんどの組織は運用安定性のためクラスターを 500-1,000 GPU ノードに制限します。
マルチクラスター連携: 大規模デプロイメントは連携により管理される複数の Kubernetes クラスターを使用します。Admiralty または Virtual Kubelet はクラスター間スケジューリングを可能にします。Flux や ArgoCD などの GitOps ツールはクラスター間で設定を同期します。サービスメッシュ技術はクラスター間ネットワーキングを提供します。連携は複雑さを追加しますが、単一クラスター制限を超えた水平スケーリングを可能にします。
階層リソース管理: 管理クラスターがワークロードクラスターを制御する階層でクラスターを組織します。管理クラスターはコントロールプレーンコンポーネントとスケジューリングロジックを実行します。ワークロードクラスターは複雑なコントローラーなしで GPU ポッドをホストします。階層設計は障害の影響範囲を削減します。懸念の明確な分離によりトラブルシューティングが簡素化されます。
AI ワークロード用カスタムリソース定義（CRD）： - TrainingJob: 分散訓練仕様の定義 - InferenceService: モデル配信デプロイメントの管理 - GPUPool: 論理 GPU グループ化の表現 - Checkpoint: 訓練状態の永続化処理 - ModelVersion: モデル反復と系譜の追跡
スケール向けパフォーマンス最適化： - API レイテンシを削減する未使用入場 webhook の無効化 - 均等分散のためのポッドトポロジー分散制約の実装 - ネットワークボトルネック回避のためコンテナイメージへのローカル SSD 使用 - 保証された CPU 割り当てのための CPU マネージャー有効化 - 大規模モデルメモリ要件のためのヒュージページ設定
モニタリングと可観測性
包括的なモニタリングは数百万ドルの GPU アイドル時間を防ぎます：
NVIDIA Data Center GPU Manager（DCGM） は、標準 Kubernetes モニタリングでは利用できない GPU 固有のメトリクスを提供します。⁹ DCGM は SM 稼働率、メモリ帯域幅、温度、電力消費、ECC エラーを含む 100 以上のメトリクスをエクスポートします。Prometheus 統合により長期メトリクス保存とアラートが可能になります。Grafana ダッシュボードは全体フリート全体の GPU パフォーマンスを可視化します。カスタムアラートは、障害が発生する前に未活用 GPU、熱スロットリング、ハードウェア劣化を検出します。
Kubernetes モニタリング用主要 GPU メトリクス： - GPU 稼働率: アクティブ SM のパーセンテージ（目標 >90%） - メモリ稼働率: 割り当て済み対利用可能 GPU メモリ - 電力消費: スロットリングを示す実際対 TDP - 温度: GPU およびメモリ温度 - PCIe 帯域幅: GPU との間のデータ転送レート - NVLink トラフィック: GPU 間通信帯域幅 - 訓練メトリクス: 損失曲線、勾配ノルム、学習率 - 推論メトリクス: 秒間リクエスト数、P99 レイテンシ、バッチサイズ
分散トレーシング は複数の GPU とノード間でリクエストを追跡します。OpenTelemetry インストルメンテーションは訓練ステップ時間、データロードレイテンシ、チェックポイント持続時間をキャプチャします。Jaeger または Tempo は分散トレース保存と分析を提供します。トレースとメトリクスの相関関係がパフォーマンスボトルネックを特定します。エンドツーエンド可視性により平均解決時間が 70% 削減されます。
ログ集約 は数千の GPU ポッドからログを一元化します。Fluentd または Fluent Bit は最小のオーバーヘッドでコンテナログを収集します。Elasticsearch は自動インデックスと保持ポリシーでログを保存します。Kibana はクラスター全体でのログ検索と分析を可能にします。一貫したフォーマットでの構造化ログはトラブルシューティングを簡素化します。システム問題を示すエラーパターンでアラート。
Introl はグローバルカバレッジエリア全体で GPU オーケストレーション用 Kubernetes クラスターをデプロイし管理し、10,000+ GPU デプロイメントまでスケーリングする専門知識を持っています。¹⁰ 当社のプラットフォームエンジニアリングチームは最適な GPU 稼働率のためのカスタムオペレーターとスケジューリング拡張を実装しています。
本番デプロイメントパターン
Anthropic での訓練クラスターアーキテクチャ： - 規模: 8 つの Kubernetes クラスターに 4,000 GPU - トポロジー: 中央スケジューラーによる階層連携 - ストレージ: 訓練データ用分散 Lustre ファイルシステム - ネットワーキング: ノードあたり 200Gbps の RoCE v2 ファブリック - スケジューリング: トポロジー対応カスタムギャングスケジューラー - モニタリング: 15 秒スクレイプ間隔の DCGM + Prometheus - 結果: 94% GPU 稼働率、50% 訓練時間削減
Uber での推論プラットフォーム： - ワークロード: 日次 5 億予測 - インフラ: 20 地域に 2,000 T4 GPU - オーケストレーション: サーバーレス用 Knative 付き Kubernetes - オートスケーリング: トラフィックパターンベースの予測スケーリング - ロードバランシング: 最小レイテンシルーティング付き Envoy プロキシ - 最適化: モデルキャッシングによりコールドスタートを 2 秒に削減 - 成果: 前アーキテクチャ対比 65% コスト削減
Spotify でのハイブリッド訓練-推論： - GPU: 3,000 台の混合 V100/A100/T4 フリート - スケジューリング: 開発用タイムスライス共有 - 分離: マルチテナントセキュリティ用 Kata コンテナ - コスト
