GPU1枚を複数のPodで共有する仕組みが、Kubernetesの標準機能として実装されようとしている。KEP-4815（Kubernetes Enhancement Proposal 4815）は、DRA（Dynamic Resource Allocation、動的リソース割り当て）の仕組みを使って物理GPUを論理的にスライスし、複数のPodへ独立して割り当てることを可能にする提案だ[1][2]。2026年6月16日〜17日のKubernetes 1.37エンハンスメントフリーズでalphaとして収録見込みとなり、GA（一般提供）は2026年8月26日が目標とされている[1]。
AIワークロードをKubernetesで扱う組織にとって、この変更はGPU利用効率と運用アーキテクチャの両面で設計の見直しを促す。
予備知識：本記事を読む前に
本記事を理解するための前提として、3つの用語を押さえておきたい。
- Node（ノード）：Kubernetesクラスターを構成する物理・仮想マシン1台。GPUはNode単位で搭載される。
- Pod（ポッド）：Kubernetes上でアプリケーションを実行する最小単位。1つ以上のコンテナをまとめたグループ。
- Namespace（ネームスペース）：クラスター内でリソースを論理的に分離する区画。チームやテナントごとに分けて使うことが多い。
GPUは高価な計算資源であり、「1枚のGPUを複数のPod・複数のテナントでどう分け合うか」は、AI/MLワークロードを運用する組織にとって恒常的な課題になっている。DRAとKEP-4815は、この分け合い方をKubernetesの標準機能として洗練させる試みだ。
DRAとは何か：DevicePlugin の次世代
KubernetesでGPUを使う既存の仕組みは「DevicePlugin」だ。NVIDIA GPU OperatorやAMD GPU OperatorがDevicePluginとして動き、各Nodeが持つGPUの数をnvidia.com/gpu: 1というリソースとしてKubernetesに伝えてきた。このモデルの制約は3つある。
- 整数単位の割り当てしかできない：GPU 0.5枚や特定のメモリスライスの割り当てはできない
- 単一Podへの排他割り当て：1つのGPUは1つのPodしか使えない
- 拡張の限界：MIG（Multi-Instance GPU）のような特殊なパーティション分割を標準APIで表現できない
DRAはこれを根本的に再設計する。リソースをResourceClaimという独立したオブジェクトで表現し、デバイスドライバー（GPU Operatorなど）がどのように物理リソースをスライスするかをKubernetesのスケジューラーと協調して決定できるようにする[3]。
Kubernetesの運用設計を体系的に押さえておきたい場合、拡張リソース管理やGPU対応ノードの設計・運用までを一冊で扱う書籍が土台として役立つ。
KEP-4815：GPUスライスの仕組み
KEP-4815はDRAの上に構築される機能拡張で、具体的には次の3点を可能にする[2]。
1. 物理GPUの論理スライス分割：H100 80GBを例に取ると、これを8つの10GB論理スライスに分割し、8つのPodへ独立して割り当てることが可能になる。MIGとは異なり、スライスのサイズはより柔軟に設定できる見込みだ。
2. 複数Podによる同一GPU利用：異なるNamespaceのPodが同じ物理GPUのそれぞれのスライスを同時に利用でき、マルチテナントのGPUクラスターが実現する。
3. スケジューラーとの協調：DRAのResourceClaimを通じてGPUリソースを要求するため、Kubernetesの標準スケジューラーがGPU利用状況を把握してPodの配置を決定できる。
AIワークロード設計への影響
推論ワークロードのリソース効率化
LLM推論の典型的なケースでは、モデルサイズが10〜40GBの場合に80GB GPUを1枚占有しているが、残りのVRAMが使われていない。DRA＋KEP-4815でスライスが可能になれば、残余VRAMを別モデルの推論に充てることができる。
Before（現状）：
resources:
limits:
nvidia.com/gpu: 1 # GPU全体を専有
After（KEP-4815 alpha以降）：
# ResourceClaimTemplateを使って10GBスライスを要求
resourceClaims:
- name: gpu-slice
source:
resourceClaimTemplateName: gpu-slice-10gb
トレーニングワークロードとの共存
長時間の学習ジョブと短時間の推論ジョブを同一GPU Nodeで混在させることが可能になる。GPUの稼働率が上がり、クラウドのGPUインスタンスコストを下げる効果が期待できる。
マルチテナントGPUクラスター
複数のチームが1つのGPUクラスターを共有するマルチテナント構成が、VRAM境界で安全に分離された形で実現する。現状の方法（Namespace分離＋ResourceQuota）よりも物理リソースの利用効率が高い。
alpha段階での注意点
KEP-4815は2026年8月のGAを目標とするが、1.37でのalpha収録時点では運用実績が限られる。本番環境への適用は次の判断基準で検討する。
| 判断基準 | 推奨アクション |
|---|---|
| 開発・ステージング環境 | 1.37 GA後に試験導入可 |
| 新規本番クラスター | 1.38（2026年末）の安定性を確認してから |
| 既存本番クラスター | 1.39以降のStable移行後に検討 |
NVIDIA GPU Operatorの対応状況もGAのタイミングと同期するため、バージョン組み合わせの確認が必要だ。
AIワークロードのKubernetes展開パターンやリソースクォータ管理を、実運用の勘所まで含めて学びたい場合は、本番運用の実践知をまとめた書籍が参考になる。
まとめ
DRA KEP-4815は、Kubernetesの世界でGPUを「整数単位の排他リソース」から「スライス可能なマルチテナントリソース」へ変える転換点になる。AIワークロードのGPU利用効率とコスト最適化を考えているチームは、今から仕組みを理解し、1.38〜1.39でのステージング評価計画を立てておくことが先行準備として有効だ。
よくある質問（FAQ）
Q1. MIG（Multi-Instance GPU）とKEP-4815のGPUスライスは同じですか？
異なります。MIGはNVIDIA H100・A100等のハードウェアレベルの分割機能で、物理的に独立したGPUインスタンスを作ります。KEP-4815のDRAスライスはKubernetesのスケジューリングレイヤーでの抽象で、MIGを含む様々な分割方式をKubernetesのAPIで統一的に表現できるようにするものです。
Q2. DRAはKubernetes 1.37で安定版ですか？
DRA自体は1.26でalphaとして導入され、1.37時点でbeta段階に移行している部分もあります。KEP-4815（GPUスライス拡張）はK8s 1.37でのalpha収録が見込まれており、GA目標は2026-08-26のv1.38前後です。本番利用はGAまたはStable移行を待つことを推奨します。
Q3. EKS・AKS・GKEではいつからDRA GPUスライスが使えますか？
マネージドKubernetesのバージョン対応は、OSSのGAから3〜6ヶ月遅れるのが通例です。2026年8月のKubernetes GA後、2026年末〜2027年Q1にマネージドサービスでのサポートが順次追加される見込みです。各プロバイダーのリリースノートを継続的に確認してください。
Q4. ResourceClaimとは具体的に何を指しますか？
Podが必要とするデバイスリソース（GPUスライスなど）を宣言的に要求するためのKubernetes APIリソースです。ボリュームの要求を宣言するPersistentVolumeClaimと似た設計思想で、「何を」「どれだけ」要求するかをYAMLで宣言すると、スケジューラーとデバイスドライバーが協調して実際の割り当てを行います。
