GPU オーケストレーションのための Kubernetes：数千台規模の GPU クラスター管理
2025年12月8日更新
2025年12月アップデート： Kubernetes 1.31+ の Dynamic Resource Allocation（DRA）が GA となり、きめ細かな 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% の稼働率を維持するカスタムオペレーターを使用しています。¹ 同社のインフラストラクチャチームは、大規模な修正なしでは約 5,000 ノードでバニラ Kubernetes が機能しなくなることを発見し、階層型クラスターフェデレーション、カスタムスケジューリングアルゴリズム、および各 30,000 ドルの 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 として実行され、GPU をスケジュール可能なリソースとして kubelet に登録します。初期化時に、プラグインは NVIDIA Management Library（NVML）にクエリを実行して、利用可能な GPU、そのメモリ容量、計算能力、およびインターコネクトトポロジーを検出します。プラグインは nvidia.com/gpu リソース名を使用して Kubernetes スケジューラーに GPU をアドバタイズし、Pod が標準リソース仕様を通じて GPU をリクエストできるようにします。
デバイスプラグイン登録フロー： 1. プラグインが起動し、NVML 経由でローカル GPU を検出 2. /var/lib/kubelet/device-plugins/ の Unix ソケットを通じて kubelet に登録 3. 一意のデバイス ID を持つ利用可能な GPU をアドバタイズ 4. コンテナへの GPU 割り当てのために Allocate() RPC を実装 5. GPU ヘルスを監視し、障害を kubelet に報告 6. Pod 終了時の 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 スケジューリングは、パフォーマンスを維持しながら稼働率を最大化します：
Gang Scheduling は、分散トレーニングジョブがリクエストされたすべての GPU を同時に受け取ることを保証します。Gang スケジューリングがなければ、部分的なリソース割り当てがデッドロックを引き起こします—ジョブは決して利用可能にならない残りの GPU を永遠に待ち続けます。Volcano や Apache YuniKorn などの Kubernetes スケジューラープラグインは、PodGroups を通じて Gang スケジューリングを実装しています。⁶ ジョブは最小 GPU 要件を指定し、スケジューラーはすべてのリソースを割り当てるか、ジョブ全体をキューに入れます。Gang スケジューリングはクラスター稼働率を 10-15% 低下させますが、トレーニングジョブのスタベーションを防ぎます。
Topology-Aware Scheduling は、ハードウェアインターコネクトに基づいて GPU 配置を最適化します。NVLink で接続された GPU は、PCIe 経由の 32GB/s に対して 600GB/s の帯域幅を達成します。⁷ スケジューラーはノードトポロジーを調べて、関連する Pod を高速インターコネクトを持つ GPU に配置します。NVIDIA GPU Feature Discovery は、アフィニティルールを有効にするトポロジー情報でノードにラベルを付けます。不適切なトポロジー決定は、通信負荷の高いワークロードで 3-8 倍のパフォーマンス低下を引き起こします。トポロジー認識は、ジョブあたり 8 GPU を超えると重要になります。
Bin Packing vs Spreading：Bin packing はワークロードを少数のノードに集約し、キャッシュ局所性を改善してネットワークトラフィックを削減します。Spreading は、より良い耐障害性と熱管理のためにノード全体に作業を分散します。最適な戦略はワークロード特性に依存します—トレーニングジョブは bin packing から恩恵を受け、推論は spreading を好みます。動的戦略はクラスター稼働率とワークロードミックスに基づいて調整されます。
Priority and Preemption：本番ワークロードは開発ジョブよりも高い優先度を受けます。リソースが不足すると、スケジューラーは優先度の低い Pod をプリエンプトします。慎重な優先度設定により、研究ジョブが本番推論をブロックすることを防ぎます。プリエンプションチェックポイントにより、トレーニングの進捗が失われないことを保証します。優先度クラスはシステムクリティカル（1000000）から開発（100）まで範囲があります。
Fair Sharing and Quotas：リソースクォータは、単一チームが GPU を独占することを防ぎます。階層的クォータにより、チーム固有のサブクォータを持つ組織全体の制限が可能になります。フェアシェアスケジューリングは、時間の経過とともに公平なリソース分配を保証します。より少ないリソースを消費するユーザーは、将来のバースト容量のためのクレジットを蓄積します。Kueue などのキューシステムは、洗練されたアドミッションコントロールを持つジョブキューイングを提供します。
スケーリングの考慮事項
数千台の GPU に Kubernetes をスケーリングするには、アーキテクチャの修正が必要です：
クラスターサイズの制限：単一の Kubernetes クラスターは、etcd のパフォーマンスが低下する前に最大 5,000 ノードをサポートします。⁸ API サーバーの負荷は、watch メカニズムによりノード数に対して二次関数的に増加します。コントローラーマネージャーの調整ループは 1,000 ノードを超えると遅くなります。ネットワークポリシーは大規模になると扱いにくくなります。ほとんどの組織は、運用の安定性のために GPU ノードを 500-1,000 に制限しています。
Multi-Cluster Federation：大規模デプロイメントでは、フェデレーションを通じて管理される複数の Kubernetes クラスターを使用します。Admiralty または Virtual Kubelet により、クロスクラスタースケジューリングが可能になります。Flux や ArgoCD などの GitOps ツールは、クラスター間で設定を同期します。サービスメッシュ技術がクロスクラスターネットワーキングを提供します。フェデレーションは複雑さを追加しますが、単一クラスターの制限を超えた水平スケーリングを可能にします。
Hierarchical Resource Management：管理クラスターがワークロードクラスターを制御する階層的にクラスターを編成します。管理クラスターはコントロールプレーンコンポーネントとスケジューリングロジックを実行します。ワークロードクラスターは複雑なコントローラーなしで GPU Pod をホストします。階層的設計は障害の影響範囲を縮小します。関心の明確な分離によりトラブルシューティングが簡素化されます。
AI ワークロード用の Custom Resource Definitions（CRD）： - TrainingJob：分散トレーニング仕様を定義 - InferenceService：モデルサービングデプロイメントを管理 - GPUPool：論理的な GPU グループを表現 - Checkpoint：トレーニング状態の永続化を処理 - ModelVersion：モデルのイテレーションとリネージを追跡
スケール向けのパフォーマンス最適化： - 未使用のアドミッション Webhook を無効にして API レイテンシを削減 - 均等な分散のために Pod トポロジー拡散制約を実装 - ネットワークボトルネックを回避するためにコンテナイメージにローカル SSD を使用 - 保証された CPU 割り当てのために CPU マネージャーを有効化 - 大規模モデルのメモリ要件のために huge pages を設定
モニタリングと可観測性
包括的なモニタリングにより、数百万ドルの GPU アイドル時間を防ぎます：
NVIDIA Data Center GPU Manager（DCGM） は、標準の Kubernetes モニタリングでは利用できない GPU 固有のメトリクスを提供します。⁹ DCGM は、SM 稼働率、メモリ帯域幅、温度、消費電力、ECC エラーなど 100 以上のメトリクスをエクスポートします。Prometheus 統合により、長期的なメトリクスストレージとアラートが可能になります。Grafana ダッシュボードは、フリート全体の GPU パフォーマンスを視覚化します。カスタムアラートは、障害が発生する前に、使用率の低い GPU、サーマルスロットリング、およびハードウェアの劣化を検出します。
Kubernetes モニタリングの 主要 GPU メトリクス： - GPU Utilization：アクティブな SM の割合（目標 >90%） - Memory Utilization：割り当てられた GPU メモリと利用可能なメモリの比較 - Power Draw：実際の消費電力と TDP（スロットリングを示す） - Temperature：GPU およびメモリの温度 - PCIe Bandwidth：GPU との間のデータ転送速度 - NVLink Traffic：GPU 間通信の帯域幅 - Training Metrics：損失曲線、勾配ノルム、学習率 - Inference Metrics：1 秒あたりのリクエスト数、P99 レイテンシ、バッチサイズ
Distributed Tracing は、複数の GPU とノードにわたるリクエストを追跡します。OpenTelemetry インストルメンテーションは、トレーニングステップ時間、データロードレイテンシ、およびチェックポイント期間をキャプチャします。Jaeger または Tempo は、分散トレースのストレージと分析を提供します。トレースとメトリクス間の相関により、パフォーマンスボトルネックが特定されます。エンドツーエンドの可視性により、平均解決時間が 70% 短縮されます。
Log Aggregation は、数千の GPU Pod からのログを一元化します。Fluentd または Fluent Bit は、最小限のオーバーヘッドでコンテナログを収集します。Elasticsearch は、自動インデックス作成と保持ポリシーでログを保存します。Kibana は、クラスター全体でのログ検索と分析を可能にします。一貫したフォーマットの構造化ログにより、トラブルシューティングが簡素化されます。システム的な問題を示すエラーパターンでアラートを設定します。
Introl は、グローバルカバレッジエリア全体で GPU オーケストレーション用の Kubernetes クラスターをデプロイおよび管理しており、10,000 台以上の GPU デプロイメントへのスケーリングの専門知識を持っています。¹⁰ 当社のプラットフォームエンジニアリングチームは、最適な GPU 稼働率のためのカスタムオペレーターとスケジューリング拡張を実装しています。
本番デプロイメントパターン
Anthropic での Training Cluster Architecture： - スケール：8 つの Kubernetes クラスターにまたがる 4,000 台の GPU - トポロジー：中央スケジューラーを持つ階層的フェデレーション - ストレージ：トレーニングデータ用の分散 Lustre ファイルシステム - ネットワーキング：ノードあたり 200Gbps の RoCE v2 ファブリック - スケジューリング：トポロジー認識を持つカスタム Gang スケジューラー - モニタリング：15 秒のスクレイプ間隔での DCGM + Prometheus - 結果：94% の GPU 稼働率、トレーニング時間の 50% 削減
Uber での Inference Platform： - ワークロード：毎日 5 億件の予測 - インフラストラクチャ：20 リージョンにまたがる 2,000 台の T4 GPU - オーケストレーション：サーバーレス向け Knative を備えた Kubernetes - オートスケーリング：トラフィックパターンに基づく予測スケーリング - ロードバランシング：最小レイテンシルーティングを備えた Envoy プロキシ - 最適化：モデルキャッシングによりコールドスタートを 2 秒に短縮 - 成果：以前のアーキテクチャと比較して 65% のコスト削減
Spotify での Hybrid Training-Inference： - GPU：3,000 台の混合 V100/A100/T4 フリート - スケジューリング：開発向けのタイムスライス共有 - 分離：マルチテナントセキュリティのための Kata コンテナ - コス
[翻訳のため内容を省略]
