AI/ML基盤におけるGPU運用の律速は、GPU総量の不足だけではない。より本質的な問題は、Kubernetesの従来方式がCPU/メモリ中心に設計されており、GPUを「整数個の不可分な外部デバイス」としてしか扱えなかった点にある。例えば、1Podが実際には16GB程度しか使わない推論ワークロードであっても、40GB GPUをまるごと専有させれば、実効利用率は40%で頭打ちになる。

この構造的な非効率を崩す仕組みが Dynamic Resource Allocation（DRA）である。Kubernetesでは2025年4月23日にv1.33でDRAがベータへ昇格し、同年9月1日のv1.34でGAとなった。DRAは「16GB以上のGPU」「特定アーキテクチャ」「同一NUMA／PCIe近傍」といった属性ベースの要求をスケジューラが理解できるようにし、Device Plugin時代の固定割り当てを、属性認識・再配置可能な資源割り当てへ置き換える。

本稿では、ResourceClaim・DeviceClass・ResourceSliceの役割、NVIDIA DRA DriverによるGPU/MIGの実装モデル、locality-aware schedulingの設計ポイント、そしてAmazon EKSおよびAzure AKSでの実装現実を整理する。なお、ユーザー向けに流布している「71%→100%」の改善幅は、現時点では公開ベンチマークとしての一次情報確認が難しい。そのため本稿では、公式仕様から導ける実装上の改善余地と、単純化した詰め込みモデルに基づく推論として扱う。

なぜDevice PluginではAI基盤のGPU効率が40%台で止まりやすいのか

KubernetesのDevice Pluginは、GPUをlimitsで要求させるシンプルな仕組みである。これは「GPUが1枚必要かどうか」を表現するには十分であった一方、「必要なのは40GB GPUそのものではなく、16GB以上のVRAMとAda世代、できれば同一トポロジ近傍」というAI基盤特有の条件を表現できなかった。結果として、Podは整数個のGPUを占有するが、GPU内部のメモリ帯域、SM、NVLink接続、MIG断片は遊休化しやすい。

AWSのEKSベストプラクティス文書も、従来のDevice Pluginが「1 Podにつき1 GPU」前提で、GPU共有や細粒度要求を表現できないために利用率を押し下げると整理している。特に推論系ワークロードでは、GPUメモリ使用量がピークでも1枚を使い切らないケースが多く、利用率40%前後でコストだけが100%発生する構造が生まれやすい。

ここで重要なのは、40%という数値がKubernetes全体の固定ベンチマークではなく、「40GB GPUを16GB要求のPodに専有させる」ような典型例から導ける上限だという点である。DRAがもたらす価値は、GPU共有それ自体よりも、スケジューラが要求属性を理解し、分割可能なデバイスを適切に束ね直せるようになることにある。

割り当て方式1Podの必要量1Podあたりの占有実効利用率の目安
Device Plugin16GB VRAM40GB GPUを1枚専有40%
DRA + Partitionable Device16GB VRAM16GB相当の割当理論上100%まで接近可能

上表の「40%→100%」は、DRAで必ず実現する実測値ではなく、分割と属性整合が完全に機能した場合の単純モデルである。実運用ではワークロードの到着分布、MIGプロファイルの断片化、障害ドメイン制約があるため、常時100%は難しい。ただし、整数GPU専有から属性ベース割り当てへ移行するだけで、GPUクラスタの利用率天井が大きく変わることは仕様上明確である。

DRAの中核: ResourceClaim・DeviceClass・ResourceSliceは何を分担するのか

DRAの設計は、要求記述、資源カタログ、割当状態を明確に分離している。DeviceClassは「どういう種類のデバイスを対象にするか」を定義し、ResourceClaimは「個々のワークロードが何を必要とするか」を宣言し、ResourceSliceは「そのノード上に今どのデバイス／属性が存在するか」をドライバ側から公開する。これにより、スケジューラはPod投入前に、要求と供給の属性一致を評価できる。

Device Plugin時代の問題は、GPUの存在有無は見えても、細かな属性がスケジューラの判断材料にならなかった点にある。DRAでは、例えば「memory >= 16Gi」「architecture = hopper」「fabric = nvlink」のような条件を構造化パラメータとして扱える。Kubernetes v1.33のベータ昇格では、このstructured parametersとpartitionable deviceサポートが重要な前進として位置付けられた。

ResourceClaimはPodから参照されるため、GPU要求がPod specの外に切り出される。これにより、ジョブ投入前にクレームを確保し、複数Podで共有する、あるいは先にトポロジ要件だけ確保してからコンテナを起動する、といった制御が可能になる。AI基盤では、モデルサーバと前処理Pod、あるいは複数レプリカ推論Podが同一クレーム設計の下で動くため、この分離が運用設計の自由度を大きく上げる。

apiVersion: resource.k8s.io/v1
kind: DeviceClass
metadata:
  name: gpu-16g-hopper
spec:
  selectors:
    - cel:
        expression: device.attributes["vendor"] == "nvidia" &&
          device.attributes["architecture"] == "hopper" &&
          quantity(device.capacity["memory"]) >= quantity("16Gi")
---
apiVersion: resource.k8s.io/v1
kind: ResourceClaimTemplate
metadata:
  name: infer-gpu
spec:
  spec:
    devices:
      requests:
        - name: accel
          deviceClassName: gpu-16g-hopper
---
apiVersion: v1
kind: Pod
metadata:
  name: llm-inference
spec:
  resourceClaims:
    - name: gpu
      resourceClaimTemplateName: infer-gpu
  containers:
    - name: server
      image: vllm/vllm-openai:latest
      resources:
        claims:
          - name: gpu

上記は概念を掴むための簡略例である。実際にはベンダードライバが公開する属性名や、共有可能性、管理者アクセスの要否に応じて記述を調整する必要がある。ただし本質は変わらない。GPUを「枚数」ではなく「属性集合」として扱うことが、DRAの設計転換点である。

NVIDIA DRA DriverはGPU共有とMIG動的割り当てをどう実現するか

NVIDIAはGPU OperatorにDRA Driver for GPUsを組み込み、Kubernetes上でGPUおよびMIGデバイスをDRA経由で扱う実装を提供している。NVIDIAの文書では、このドライバはKubernetes 1.34以降とNVIDIA GPU Operator 25.3.0以降で利用でき、フルGPU、MIG、タイムスライシング、vGPUをDRAの枠組みで割り当てられるとしている。

実装上の要点は、MIGを「事前に切って固定的に見せる」運用から、「要求属性に応じてクレーム時に整合させる」運用へ近づけられる点にある。例えば7つの1g.10gbインスタンスを常設しておくと、3g.40gb要求が来たときに断片化が発生する。DRA Driverは、ノード上の公開可能な割当単位をResourceSliceとして見せ、クレームに応じて利用可能なデバイス候補を返すことで、固定MIG設計より柔軟な再利用を可能にする。

ここでの改善幅は、ワークロードの組み合わせに依存する。例えば、16GB級推論Podが多数で、かつGPUが40GB級であれば、Device Pluginでは1PodごとにGPUを丸ごと消費し利用率40%に張り付く。一方、DRA + MIGで16GB前後の単位へ分割できれば、空き断片を別Podで埋められるため、単純モデル上は100%近い詰め込みも起こり得る。冒頭の「71%→100%」は、この種の混在負荷で断片が減るときの説明としては合理的であるが、公開実測値としては扱うべきでない。

apiVersion: resource.nvidia.com/v1beta1
kind: GpuConfig
metadata:
  name: mig-mixed
spec:
  sharing:
    strategy: mixed
  mig:
    enabled: true
    profiles:
      - profile: "1g.10gb"
        count: 4
      - profile: "3g.40gb"
        count: 1

実際のCRD名やフィールドはGPU Operatorのバージョンで差異があるため、適用時はそのクラスターのドキュメントを確認すべきである。ただし、運用設計としては「固定MIGレイアウトを先に決める」のではなく、「必要なプロファイルと共有戦略をクレーム側で宣言し、ドライバがそれを満たせるようにする」方が、AI基盤の需要変動には適している。

locality-aware schedulingはレイテンシと東西トラフィックをどう削るか

AI推論や分散学習では、GPUの有無だけでなく、どのGPUがどのCPUソケット、NUMAノード、PCIeスイッチ、NVLinkドメインに近いかが性能へ直結する。KubernetesのDRAは、単にデバイスを発見する仕組みではなく、ResourceSliceに公開されたトポロジ属性をスケジューラ判断へ接続することで、locality-aware schedulingの土台を提供する。

典型例は、前処理コンテナがCPUメモリを大量に使い、推論コンテナがGPUメモリとGPU間通信に依存するケースである。NUMAをまたいだメモリアクセスや、NVLinkで直結されていないGPU組み合わせを引くと、レイテンシは安定しない。DRAでは「同一近傍のGPU」「特定ファブリックを共有するGPU群」といった要求を表現できるため、単純なbin packingより、性能維持を前提にしたpackingが可能になる。

この点は学習系ワークロードでも重要である。データ並列やテンソル並列では、1枚だけ異なるトポロジに配置されるだけで同期時間が延び、クラスタ全体のstep timeを悪化させる。locality-aware schedulingは、GPU使用率を上げるだけでなく、性能のばらつきを抑えてSLO違反を減らすための機構と捉えるべきである。

観点Device Plugin中心DRA中心
要求表現GPU枚数メモリ、アーキテクチャ、共有可否、トポロジ
共有実装依存で限定的MIGや共有戦略をドライバと連携して表現可能
スケジューリング属性理解が弱い属性一致と近接性を前提に判断可能
性能安定性当たり外れが出やすい局所性制約を含めて設計しやすい

Amazon EKS・Azure AKSでの実装現実: 2026年時点でどこまで使えるか

2026年3月2日時点で確認できる一次情報ベースでは、Amazon EKSはDRAをAI/MLベストプラクティスとして明確に扱い、ResourceClaimとDRA Driverを用いたGPU割り当て手順を公開している。したがって、EKS上でDRAを前提にしたGPU運用へ進む実務的障壁は大きく下がっている。一方で、AWSが「DRAをAmazon EKSの個別機能として2026年にGA化した」と明記した公式発表は本稿調査時点では確認できなかった。

Azure側では、AKSの公式ドキュメントがNVIDIA GPU OperatorとDRA Driver for GPUsの組み合わせを案内しており、少なくともAKS上でDRAベースGPU管理を実装する道筋は公開されている。ただし、こちらもAKSコントロールプレーン機能としての「DRA GA」表現は一次情報で確認できていない。したがって、現実的な整理は「EKS/AKSともに、2026年にはDRAを前提にしたGPU運用が実装フェーズへ入った」である。

実務では、まず次の3段階で導入するのが妥当である。第1に、既存のDevice Plugin運用を残したまま小規模ノードプールでDRA Driverを有効化する。第2に、16GB級・24GB級など要求の揃った推論ワークロードからResourceClaimTemplateへ移行する。第3に、MIGプロファイルとlocality属性を取り入れ、学習系ジョブや高密度推論へ拡張する。いきなり全GPUプールをDRAへ寄せるのではなく、断片化がひどいワークロードから先に移す方が効果を測りやすい。

要するに、DRAの意義は「GPUを共有できるようになった」ことではなく、「GPUを属性付きの可変資源としてKubernetesスケジューラに認識させた」ことにある。AI基盤の競争力はGPU調達量だけで決まらない。どれだけ細かく、トポロジを壊さず、需要変動に合わせて割り当て直せるかで決まる。その意味で、DRAはKubernetesのAI基盤化を一段進める転換点である。

FAQ

DRAはKubernetes 1.33で何が変わったのか。

2025年4月23日のKubernetes v1.33でDRAはベータへ昇格し、structured parametersやpartitionable devicesなど、AI/アクセラレータ用途に必要な表現力が大きく強化された。その後、2025年9月1日のv1.34でGAとなっている。

DRAがあればGPU利用率は必ず100%になるのか。

ならない。100%は、40GB GPUを16GB要求のPodに細粒度で詰め込めるような単純モデルの理論値である。実効利用率は到着分布、MIG断片化、障害ドメイン、ピーク余裕率に左右される。ただし、整数GPU専有より利用率上限が高くなることは確かである。

ResourceClaimとDevice Pluginは排他的なのか。

完全な排他ではない。移行期には、従来のDevice Plugin運用を残しつつ、一部ノードプールや一部ワークロードだけDRAへ移す構成が現実的である。EKSやAKSでも、この段階的導入が実務上は取りやすい。

MIGを使えばDRAなしでも十分ではないか。

MIGだけでも一定の共有は可能であるが、固定プロファイル運用では断片化が起きやすい。DRAはMIGをスケジューラ理解可能な資源へ持ち上げ、要求属性や近接性を考慮した割り当てに接続できる点が本質的に異なる。

locality-aware schedulingは推論でも重要か。

重要である。前処理、埋め込み生成、モデルサーブが分かれる推論基盤では、NUMAやPCIe距離がレイテンシ分布へ影響する。単にGPUが空いているノードへ詰めるより、近接性を保った方がP95/P99を安定させやすい。

参考文献