Kubernetes 1.34でGA（一般提供）に到達したDynamic Resource Allocation（DRA）が、AI推論基盤のGPU利用率を根本から変えようとしている。従来のDevice Pluginモデルでは「1 Pod＝1 GPU」の静的割り当てが前提であり、GPU利用率は業界平均で20-30%に留まっていた。Cast AIの2026年レポートでは平均利用率がわずか5%という数値すら報告されている。DRAは構造化パラメータによるGPUメモリ・MIGパーティション・NVLinkトポロジーの属性認識スケジューリングを実現し、KAI Schedulerのギャングスケジューリング・公平共有キューイングと組み合わせることで、利用率70-80%への3倍改善とインフラコスト50-70%削減を可能にする。本稿では、Kubernetes GPU Confidential Computing実装ガイドで解説したゼロトラスト設計の基盤となるDRAの実装詳細を、設定例・設計パターン・実測値とともに解説する。

DRA（Dynamic Resource Allocation）がDevice Pluginを置き換える技術的理由

Kubernetes におけるGPUスケジューリングは長年、Device Pluginモデルに依存してきた。Device Pluginは2017年のKubernetes 1.8で導入され、GPUを整数カウントの不透明なリソースとして扱う。スケジューラはnvidia.com/gpu: 1というリクエストを見るだけで、そのGPUのメモリ容量・アーキテクチャ・NVLink接続・MIG対応状況といった属性には一切アクセスできない。この設計上の制約が、GPU利用率を20-30%に留める根本原因だった。

DRAはKEP-4381（Structured Parameters）として再設計され、Kubernetes 1.34（2026年3月リリース）でGA到達した。安定APIバージョンはresource.k8s.io/v1であり、今後破壊的変更は行われない。DRAの核心は3つのAPIオブジェクトにある。

ResourceSlice: DRAドライバがノードごとにGPUの詳細属性を公開する。メモリサイズ（例: A100の80GB＝85,899,345,920バイト）、Compute Capability（Ampere: 8.0、Hopper: 9.0）、アーキテクチャ、MIG対応状態、NVLinkピアトポロジーなどが構造化データとして記述される。

ResourceClaim: ユーザーがワークロードに必要なGPU属性を宣言的に記述する。「40GB以上のメモリ、Compute Capability 8.0以上、NVLink接続あり」といった要件をCEL式で表現でき、スケジューラがResourceSliceのデータと直接マッチングする。Device Pluginのように外部コントローラとのネゴシエーションが不要なため、スケジューリング速度も大幅に向上する。

DeviceClass: 管理者がデバイスタイプを抽象化する。mig-gpu-1gやhigh-memory-gpuといったクラスを定義し、ユーザーはハードウェアの詳細を知らずにリソースを要求できる。

Device PluginとDRAの決定的な違いはクラスターオートスケーラとの統合にある。Device Pluginではオートスケーラがデバイスの可用性をシミュレーションできなかったが、DRAではResourceSliceの属性情報を基にノード追加前にアロケーションを事前評価できる。これにより、GPUノードのスケールアウト判断が「ノードを追加してから確認」から「追加前に確認して判断」へ変わった。

さらに、ResourceClaimはPodのライフサイクルから独立しているため、JupyterノートブックがPod再起動後もGPUを保持し続けるといったユースケースが初めて可能になった。Device Pluginモデルでは、Pod再起動のたびにGPUが再割り当てされ、GPUメモリ上のモデルがすべて失われていた。

# ResourceClaim例: 40GB以上のHopper GPUを要求
apiVersion: resource.k8s.io/v1
kind: ResourceClaim
metadata:
  name: llm-inference-gpu
spec:
  devices:
    requests:
    - name: gpu
      deviceClassName: gpu.nvidia.com
      selectors:
      - cel:
          expression: |
            device.attributes["gpu.nvidia.com"].memory >= 40Gi &&
            device.attributes["gpu.nvidia.com"].architecture == "Hopper"

NVIDIA DRA DriverのCNCF寄贈とMIG・NVLink構造化パラメータの実装

2026年3月24日、KubeCon Europe 2026（アムステルダム）において、NVIDIAはGPU用DRAドライバをKubernetesコミュニティに寄贈した。この寄贈により、ドライバはNVIDIA単独の管理からAWS、Google Cloud、Microsoft、Red Hatを含む8社によるコミュニティメンテナンスへ移行した。AMD・Intelなど他のGPUベンダーが同一インターフェースを実装する道も開かれている。

NVIDIA DRAドライバは2つの専用Kubeletプラグインで構成される。gpu-kubelet-pluginがGPUの発見・割り当て・MIGパーティション管理・ヘルスモニタリングを担い、compute-domain-kubelet-pluginがマルチノードNVLink（MNNVL）のIMEXプリミティブを自動管理する。

MIG（Multi-Instance GPU）の動的パーティション管理は、DRAドライバの最も実用的な機能の一つだ。A100やH100では、1つの物理GPUを最大7つの独立インスタンスに分割できる。DRAドライバはMIGパーティションの動的な作成・削除をサポートし、同一ノード上のGPUごとに異なるMIGプロファイルを設定できる。たとえば、GPU 0を7g（フルGPU）のまま大規模モデル推論に使い、GPU 1を1g×7に分割して軽量推論ワークロードを多重化するといった構成が、無停止で実現可能になった。

# DeviceClass例: MIG 1gパーティションを定義
apiVersion: resource.k8s.io/v1
kind: DeviceClass
metadata:
  name: mig-1g-10gb
spec:
  selectors:
  - cel:
      expression: |
        device.attributes["gpu.nvidia.com"].migEnabled == true &&
        device.attributes["gpu.nvidia.com"].migProfile == "1g.10gb"

NVLinkトポロジーの発見と活用も重要な進化だ。DRAドライバはGPU間のNVLinkポートを列挙し、NVLinkドメイン（高帯域幅インターコネクトを共有するGPU群）のマップを構築する。NVIDIA Grace Blackwell（GB200）では最大72GPUが1つのNVLinkドメインを構成できる。ドライバはComputeDomain抽象を提供し、分散学習ジョブのPod間でマルチノードNVLink到達性を保証する。

AWSのP6e-GB200 UltraServerでは、72基のGB200 GPU（FP8で360ペタフロップス、HBM3eメモリ13.4TB）をDRA経由で管理し、EFAv4ネットワーキング（28.8Tbps）と組み合わせてトリリオンパラメータモデルの分散学習を効率化している。従来の静的割り当てでは30-40%だったGPU利用率が、DRA最適化により80-90%に改善された。

筆者の経験では、大規模システムにおいて「止められない」という制約が技術的判断のすべてを支配する。GPU基盤もまた同様で、MIGパーティションの再構成を無停止で行えるDRAの設計は、実運用における最大のペインポイントを解消している。Device Plugin時代は、MIG構成を変更するためにノード全体をドレインし、ワークロードを退避させ、GPU構成を変更し、再スケジュールするという手順が必要だった。

KAI Schedulerによるギャングスケジューリングと公平共有キューイングの実装

GPUの物理的な効率化だけでは、マルチテナント環境での利用率最大化は実現できない。NVIDIAが2025年4月にApache 2.0ライセンスでオープンソース化したKAI Scheduler（旧Run:ai Scheduler）は、GPUクラスタのスケジューリング層で利用率を押し上げる。KAI SchedulerはCNCFサンドボックスプロジェクトとして採択され、数千ノード規模の環境向けに設計されている。

ギャングスケジューリングはKAI Schedulerの中核機能だ。分散学習ジョブが8つのGPU Podを必要とする場合、Device Pluginモデルでは5つのPodだけが先にスケジュールされ、残り3つがリソース待ちになる「部分スケジューリング」が頻発していた。5つのPodは3つを待つ間GPUを占有しつつ実際には何も計算しない——これがGPU利用率を20-30%に留める主要因の一つだった。

KAI SchedulerのPodGroup機能は、ジョブを構成する全Podを原子的なスケジューリング単位として扱う。全Podが同時にスケジュールされるか、1つもスケジュールされないかの二択であり、部分スケジューリングによるGPU浪費が構造的に排除される。階層的PodGroupもサポートしており、分散学習とディスアグリゲーテッドサービング（KVキャッシュ分離）のような多層ワークロードにも対応する。

公平共有キューイングは、チーム間のGPUリソース配分を動的に最適化する。各チームにGPUクォータ（ベースライン割り当て）が設定され、未使用リソースはOver-Quota Weightに基づいて他チームに再配分される。KAI Schedulerは公平共有値をリアルタイムで再計算し、クォータ超過のジョブを退避（Reclaim）させることで公平性を維持する。

# KAI Scheduler キュー設定例
apiVersion: scheduling.run.ai/v2
kind: Queue
metadata:
  name: ml-team-alpha
spec:
  resources:
    gpu:
      quota: 16          # ベースライン16 GPU
      overQuotaWeight: 2  # 余剰リソースの重み
      limit: 32           # 最大32 GPUまで
  parentQueue: department-ai

V2.24以降ではTime-Based Fairshareが導入され、過去のリソース使用量を時間減衰付きで追跡し、長期的な公平性を確保する。月曜に大量のGPUを使ったチームは、火曜には他チームにリソースが優先配分されるといった動的バランシングが自動化された。

KAI Schedulerの4フェーズスケジューリングサイクルは以下の順序で実行される。(1) Cluster Snapshot: ノード・PodGroup・キューの現状を取得。(2) Resource Division: Deserved-QuotaとOver-Quotaアルゴリズムで公平共有を計算。(3) Scheduling Actions: Allocate（割り当て）→ Consolidate（断片化解消）→ Reclaim（超過回収）→ Preempt（優先度制御）の順に実行。(4) Status Updates: 変更を反映しサイクルを再開。

このスケジューリングサイクルにはConsolidate（統合）アクションが含まれている点が重要だ。これはPodをノード間で再配置し、GPU断片化を最小化する。たとえば、4ノードにそれぞれ1GPUずつ空きがある状態で4GPU要求のジョブが来た場合、Consolidateが既存Podを再配置して1ノードに4GPU分の空きを作り出す。Claude Code vs Cursor並列エージェント実装の設計思想差分で解説した並列処理設計と同様に、リソース効率を最大化するアーキテクチャ設計がシステム全体の経済性を決定する。

GPU利用率20-30%から70-80%への改善を実現する統合設計パターン

DRAとKAI Schedulerを組み合わせた統合設計により、GPU利用率を段階的に改善できる。以下に、実運用で検証された段階的アプローチを示す。

Stage 1: DRA基本導入（利用率30-40%達成）。Device PluginからDRAへの移行だけで、属性認識スケジューリングが有効になる。GPUのメモリサイズ・アーキテクチャによるマッチングが可能になり、「A100 80GBに小型モデル（7Bパラメータ）を割り当てて70GB遊ばせる」といった非効率が解消される。Azure AKS上のNDm_A100_v4 VMでのDRA導入事例では、ResourceClaimTemplateによるデバイス要件指定とGPU Operator（--gpu-driver noneオプション）の組み合わせにより、即座に利用率改善が確認された。

Stage 2: MIG＋タイムスライシング導入（利用率50-60%達成）。MIGパーティションで1つのGPUを複数ワークロードに分割する。タイムスライシング単体で20%のコスト削減、モデル統合で追加30-40%の削減が実現する。実例として、Ke Holdingsは13%だったGPU利用率を37%に改善し（約3倍）、SF Technologyは57%のインフラコスト削減を達成した。

Stage 3: KAI Scheduler統合（利用率70-80%達成）。ギャングスケジューリングで部分スケジューリングによるGPU浪費を排除し、公平共有キューイングでチーム間の遊休リソースを動的に再配分する。DaoCloudの実装事例では80%以上のGPU利用率が報告されている。

Kubernetes 1.35の新機能も利用率向上に寄与する。Partitionable Devices（KEP-4815、Alpha）は、ベンダーがオーバーラップするパーティションをオンデマンドで作成可能にし、DRA標準のMIG管理をさらに柔軟化する。Consumable Capacity（KEP-5075、Alpha）は、無関係なPodからの複数ResourceClaimが同一物理デバイスを共有できるようにし、管理者が共有ポリシーを定義する。

コスト削減の全体像を整理する。タイムスライシングで20%、モデル統合で30-40%、さらにCPU/メモリの同時最適化を加えることで、総インフラコスト70%以上の削減が達成可能だ。100基のH100 GPU（1基あたり約,000）を運用する環境では、利用率を30%から80%に改善することで、同一ワークロードを約38基で処理可能になり、GPU調達費用だけで約190万ドルの削減に相当する。

実際のプロジェクトで筆者が経験したのは、2000人同時接続のリアルタイムシステム構築における教訓だが、「個別の最適化では壁を越えられない」という原則はGPU基盤にも当てはまる。DRA単体、MIG単体、KAI Scheduler単体ではそれぞれ部分的な改善に留まるが、3つを統合した設計パターンが70-80%という利用率を初めて実現可能にしている。

エンタープライズ導入ロードマップと実測ROI

DRA導入は既存クラスタへの段階的移行が推奨される。以下に、クラウドベンダーの実装状況と推奨ロードマップを示す。

AWS EKS: P6e-GB200 UltraServer（最大72 GB200 GPU、FP8 360ペタフロップス）でDRAを本格サポート。IMEXチャネルによるクロスノードGPU通信とトポロジー認識スケジューリングを統合。Dallas Local ZoneのEC2 Capacity Blocks for MLで利用可能。

Azure AKS: 2026年3月からMIG＋DRAの統合サポートを提供。「アクセラレータがエラスティックかつ共有可能で、コントロールプレーンのファーストクラスリソースとなるモデル」を実現。vLLM（LLMサービングフレームワーク）のH100上での複数AIモデル同時実行を公式にサポートしている。

Google GKE: StandardモードとAutopilotモードの両方でB200・H200・H100・A100をサポート。Managed DRANETによる高度なオーケストレーションと、GKE Inference Gatewayによるプライベートモデルサービングを提供。Autopilotモードでは、ワークロードマニフェストにGPUリソースを指定するだけで自動的にキャパシティ管理が行われる。

推奨導入ロードマップ:

  1. Phase 1: 小規模ノードプールでDRAを有効化し、既存Device Pluginと並行運用。ResourceClaimによるGPU要求を標準推論ワークロードから開始
  2. Phase 2: GPU OperatorとMIGを導入。DeviceClassでMIGプロファイルを定義し、軽量推論ワークロードの多重化を開始
  3. Phase 3: Gateway API Inference Extension（v1.3.1 GA、2026年2月）を導入し、モデル名ベースルーティングとKVキャッシュ認識スケジューリングを有効化
  4. Phase 4: KAI Schedulerを導入し、ギャングスケジューリングと公平共有キューイングでマルチテナントGPU管理を統合
  5. Phase 5: Cilium eBPFネットワークを導入（分散学習レイテンシ40%削減）し、AI Runway等の推論デプロイプラットフォームと統合

OpenAIのKubernetes導入事例は規模の参考になる。2,500ノード以上（5,000ノード以上を計画）のGPUクラスタをAzure上で運用し、Kubernetes導入前は数百GPUへのスケールに1-2ヶ月要していたのが、導入後は2-3日で起動、1-2週間でスケールアウト可能になった。CNCFの2025年年次調査では、調査対象組織の82%がAI本番環境でKubernetesを使用していると回答しており、DRAのGA到達によりこの比率はさらに上昇すると見込まれる。

AI開発の技術的負債加速で分析したように、AI基盤への投資はコード生成の効率化だけでなく、そのコードを実行するインフラの経済性にも直結する。DRA＋MIG＋KAI Schedulerの統合設計は、AI推論基盤のTCO（総保有コスト）を構造的に改善する数少ない手段だ。

FAQ

DRA（Dynamic Resource Allocation）はKubernetesのどのバージョンから使えますか？

DRAはKubernetes 1.26でAlpha導入され、1.34（2026年3月リリース）でGA（一般提供）に到達しました。GA版のAPIはresource.k8s.io/v1で、デフォルトで有効化されています。安定APIのため、今後破壊的変更は行われません。1.33以前のバージョンではフィーチャーゲートの明示的な有効化が必要です。

Device PluginからDRAへの移行は既存ワークロードに影響しますか？

DRAとDevice Pluginは並行運用可能です。推奨される移行戦略は、小規模ノードプールでDRAを有効化し、新規ワークロードからResourceClaimベースのGPU要求に切り替えることです。既存のDevice Plugin設定はそのまま動作するため、段階的な移行が可能です。

MIG（Multi-Instance GPU）はどのGPUで使えますか？

MIGはNVIDIA A100、A30、H100、H200、GB200で利用可能です。A100では最大7インスタンス、H100ではより柔軟なパーティション構成が可能です。DRAドライバにより、同一ノード上のGPUごとに異なるMIGプロファイルを無停止で設定・変更できます。

KAI Schedulerは標準のkube-schedulerと共存できますか？

はい。KAI Schedulerは追加のスケジューラとして導入可能で、GPUワークロード専用のスケジューリングポリシーを適用できます。Kubeflow、Ray、Argoなどの分散学習フレームワークとの組み込みPodGrouper統合も提供されており、フレームワーク側の設定変更は最小限です。

GPU利用率70-80%は本当に達成可能ですか？

DRA＋MIG＋KAI Schedulerの統合構成で、DaoCloudが80%以上、AWSのP6e-GB200環境で80-90%の利用率が報告されています。ただし達成にはワークロード特性に応じたMIGプロファイル設計、キュー構成、トポロジー最適化の段階的チューニングが必要です。単一技術の導入だけでは50-60%が現実的な上限です。

DRAはオンプレミスGPUクラスタでも使えますか？

はい。DRAはKubernetesのコア機能であり、クラウド・オンプレミスを問わず利用可能です。NVIDIA DRAドライバはCNCFコミュニティに寄贈されており、GPU Confidential Computingと組み合わせたオンプレミスのセキュアAI推論基盤構築にも適用できます。

Kubernetes 1.35で追加されるDRA関連の新機能は何ですか？

1.35ではDevice Binding Conditions（Beta）とPartitionable Devices（KEP-4815、Alpha）、Consumable Capacity（KEP-5075、Alpha）が追加されます。Partitionable Devicesはオーバーラップするパーティションのオンデマンド作成を、Consumable Capacityは複数Podによるデバイス共有を実現します。

参考文献