公開：2026年10月28日, 最終更新：2026年10月28日
NVIDIAは2026年10月27日、公式テクニカルブログにて、オープンソースのKubernetesオペレーター「GPU Fractioning Operator」とKAI Scheduler v0.18.0を組み合わせることで、CUDA 13.4が提供するGPUメモリ境界の強制適用機能をKubernetes環境で活用する方法を解説した。
30秒サマリー
- CUDA 13.4の新機能を活用し、KubernetesのPodごとにGPUメモリ上限を強制適用できるオープンソース構成が公開された
- GPU Fractioning OperatorがMPSの管理とメモリ/コンピュート設定を担い、KAI Scheduler v0.18.0がGPU割り当てアノテーションを付与する
- タイムスライシングとSMシェアリングの2つのコンピュートモードをコンテナ単位で選択でき、バースト上限付きメモリ予約も対応
GPU Fractioning OperatorとKAI Schedulerの連携による実装内容
NVIDIAテクニカルブログは2026年10月27日付で、CUDA 13.4が導入したGPUメモリ境界の強制適用機能をKubernetes上で利用するための構成を詳説した。記事の核心は、新たなオープンソースKubernetesオペレーター「gpu-fractioning（GPU Fractioning Operator）」の紹介であり、GitHubのKAI Schedulerオーガニゼーション配下でホストされている。
GPU Fractioning Operatorは、NVIDIA GPU Operatorと並走して動作し、（1）全GPUノードでのMulti-Process Service（MPS）の起動と監視、（2）各ワークロードへのメモリ上限およびコンピュートモードの適用、（3）GPU全体ではなくフラクション単位でのメモリ・コンピュート使用量の計測、という3つの役割を担う。CUDA 13.4は、アプリケーションに透過的なメモリ境界強制を提供し、保証された最小量とバースト可能な最大量の範囲指定、タイムスライシングとSMシェアリングの選択が可能になったと説明されている。
KAI Schedulerはv0.18.0から「NvFractions」というGPU共有モードを搭載し、GPU Fractioning Operatorと統合された初めてのスケジューラーとなる。KAI SchedulerがどのGPUのどのスライスをどのワークロードに割り当てるかを決定し、Podのコンテナ単位アノテーション（メモリのrequest/limit、コンピュートモード、デバイス割り当て）を書き込む。GPU Fractioning Operatorがそのアノテーションを読み取り、ノード上での設定を実行する仕組みだ。Helmフラグ「–set global.nvFractions.set=true」を指定してKAI Schedulerをインストールすることで、GPU Fractioning Operatorが依存関係として同時にインストールされる。
コンピュートモードはコンテナ単位で明示できる。タイムスライシングはワークロードが順番にGPU全体を使用する直列方式でエラー分離が保たれ、SMシェアリングはストリーミングマルチプロセッサを並列分割して同時実行する方式で単一エラードメインを共有する。KAI Schedulerは同一GPU上に両モードを混在させないよう管理し、1ノード上でGPUごとに異なるモードを使うことは許容される。なお、アノテーションが書ける任意のKubernetesスケジューラーからもこの機能を利用できると記事は説明している。
GPU Fractioning OperatorとKAI Schedulerの連携の主な仕様・数値
- 対応CUDA バージョン：CUDA 13.4
- KAI Scheduler 対応バージョン：v0.18.0以降
- GPU共有モード（新機能）：NvFractions
- コンピュートモード選択肢：time-slicing（デフォルト）またはsm-sharing
- メモリ指定方法：絶対サイズ（例: 40Gi）またはGPU割合（例: 0.5）
- バースト上限：オプション指定可能（portion指定の場合はgpu-fractionより大きく1未満）
- マルチGPU対応：gpu-fraction-num-devicesで複数GPU（例: 4台）へのリクエスト分散が可能
- KubeCon登壇予定：KubeCon + CloudNativeCon NA 2026、Salt Lake City、Utah、11月9〜12日
出典: NVIDIA Technical Blog（公式ブログ）
なぜ重要か（編集部の分析）
編集部の見方として、CUDA 13.4とGPU Fractioning Operatorの組み合わせは、これまでKubernetes上でGPU共有の「実施」がスケジューラー任せで保証できなかった課題を、ノードレベルの強制実行によって解消する点で実用上の意義は大きい。GPUメモリのオーバーコミットなしに複数ワークロードを安全に同居させられる構成が、OSSとして具体的なコード・手順とともに公開されたことで、AI基盤の稼働率向上とコスト削減を実装レベルで検討できる段階に進んだと言える。
日本企業への示唆（編集部の分析）
編集部の分析として、推論サービスや開発用ノートブック、小規模ファインチューニングなど用途ごとにGPUメモリ割当を細分化し、高価なGPUリソースを有効活用したいと考える日本企業にとって、この構成はKubernetesの既存インフラに乗せてOSSのみで導入できる現実的な選択肢となる。SMシェアリングでスループット優先の推論ワークロードを束ね、タイムスライシングで開発・バッチ処理を安全に分離するといった運用設計が具体的に検討可能になった。一方、SMシェアリングはエラー分離が解除される点を踏まえ、本番ワークロードの信頼性要件と照らし合わせた設計判断が必要だ。
背景・経緯
NVIDIA GPUはMIG（ハードウェア分離）、タイムスライシング（メモリ制限なし）、MPS（アドレス空間分離・並列実行）という複数の共有方式をすでにサポートしていた。しかしKubernetes環境ではコンテナ単位のメモリ上限強制の仕組みが不足しており、GPUの過少利用が課題だった。CUDA 13.4でメモリ境界の強制適用が透過的に実現され、それをKubernetesから操作するレイヤーとしてGPU Fractioning Operatorが開発された経緯が原文に示されている。
GPU Fractioning OperatorとKAI Schedulerの連携についてよくある質問
Q. GPU Fractioning Operatorを使うには何が必要か？
A. NVIDIA GPU Operatorが稼働しているKubernetes環境に加え、KAI Scheduler v0.18.0以降をHelmでインストールする際に「–set global.nvFractions.set=true」を指定することでGPU Fractioning Operatorが依存関係として自動インストールされる。GPUノードはCUDA 13.4に対応している必要がある。
Q. GPU Fractioning Operatorでタイムスライシングとsmシェアリングを同一ノードで混在させられるか？
A. 同一GPU上での混在はKAI Schedulerが防止するが、1ノード内で異なるGPUにそれぞれ異なるモードを割り当てることは可能と原文に明記されている。
Q. GPU Fractioning Operatorは特定のスケジューラー専用か？
A. 原文によると、指定のPodアノテーションを書き込める任意のKubernetesスケジューラーからも利用可能であり、現時点でKAI Schedulerが統合された最初のスケジューラーとして紹介されている。
