NVIDIA、オープンソースのWorkload Mapを紹介：Kubernetesワークロードを共通定義で記述し、検査、ギャングスケジューリング、プラットフォーム表示に利用
NVIDIA開発者ブログは2026年11月2日、オープンソースのNVIDIA Workload Mapを紹介しました。JobSet、RayCluster、KServeなどのKubernetesワークロードの構造と状態を、書いてレビューできる定義で記述します。例では、JobSetがkubectlでは3つのJobに見え、Run:aiでも登録前は3つの独立したワークロードですが、同じカタログの定義を登録すると12GPUを使う1つのワークロードになります。節約時間やエラー率の測定値はなく、定義自体もマニフェストと同様にレビューとテストが必要です。
2026年11月2日、NVIDIAの開発者ブログはKubernetesのワークロードを記述するオープンソースの層、NVIDIA Workload Mapを紹介した。狙う問題は、AIクラスタ向けのスケジューラ、コントローラ、ダッシュボード、コストツールを作る人には馴染みがある。実際のジョブがPod一つで済むことはまれだ。分散学習やマルチノード推論サーバーは小さなリソースの木であり、JobSetやLeaderWorkerSetなどフレームワークごとに、役割、レプリカ数、Podテンプレート、状態が別々のカスタムリソースに入っている。そのため、ツールはフレームワークごとにアダプタを必要とする。
Workload Mapは、フレームワークごとのコードの多くをデータに置き換える。Kubernetesのカスタムリソース定義とGoライブラリとして提供され、各定義は一つのワークロード種別についてPodテンプレート、レプリカ数、状態フィールドの場所を示す。記事によれば、リソースのkindは旧名のKartaのままである。定義があれば、利用側はPodテンプレート、レプリカ数、状態、メタデータを取り出し、すべてのインスタンスでPod仕様、ラベル、アノテーションを更新し、JobSetの複製Jobとそのポッドのような階層も把握できる。状態マッピングは、ネイティブの条件を共通の語彙に変換する。JobSetには単純な「実行中」条件がないため、定義は複製Jobの状態に対する式から導き、ネイティブの完了と失敗の条件はそのまま対応づける。
例として使われるのは、リーダーJobが1つ、ワーカーJobが2つのJobSetで、各Podが4基のGPUを要求する。kubectlで一覧すると、JobSet1つ、Job3つ、Pod3つで、合計は出ない。定義を登録する前のNVIDIA Run:aiでは、3つのJobが4GPUずつの独立した3つのワークロードとして表示される。同じカタログの定義を1回のAPI呼び出しで登録すると、Run:aiは12GPUを使う1つのワークロードとして表示し、リーダーとワーカーの構造ビューも出す。Workload Mapのコマンドラインツールは、稼働中のオブジェクトを同じ木に解決する。kubeconfigを使い、組み込みの定義を含み、記事によればWorkload Mapをクラスタにインストールする必要はない。出力にはリーダーとワーカーの役割と、12GPUの合計が表示される。
二つ目の用途はスケジューリングである。定義には、任意でギャングスケジューリングの指示を含められる。記事は役割分担を丁寧に述べている。定義が与えるのはグループ化の情報で、ギャング単位の受け入れと配置の判断はKAI Schedulerが行う。KAI Schedulerは、ネイティブなプラグインがないワークロード種別のために、Podグルーパーの代替手段としてWorkload Mapを使い、ネイティブなプラグインが優先される。この点は重要で、Workload Mapは既存の連携を上書きせず、空白を埋める役割だと分かる。
プロジェクトには、テスト済みの定義を集めたカタログが付属し、JobSet、PyTorchJob、RayCluster、RayJob、RayService、KServe、Knative、MPIJob、NVIDIA NIM、LeaderWorkerSet、Milvus、Grove PodCliqueSet、NVIDIA Dynamoに対応する。ほかの種別はYAMLの定義を書いて追加できる。NVIDIAは、ソフトウェアがApache 2.0ライセンスで、NVIDIA Run:ai内で本番利用されており、ElotlのNovaが分散ワークロードのクラスタ選択時に構造とリソース要件を解釈するために使っていると述べる。リポジトリ自身は、あらゆるKubernetesフレームワークのカスタムリソースを標準化された汎用構造に写す変換層だと説明している。
記事が示していないのは、測定された効果である。節約できた時間、スケジューラの負荷、エラー率、状態式の精度の数字はなく、採用の話はNVIDIAとパートナー企業の説明にとどまる。また、定義はデータの姿をしたコードでもある。状態式やPodテンプレートへのパスを間違えると、プラットフォームが状態を誤報したり、ジョブを誤って配置したりしかねないので、他のマニフェストと同様にレビューとテストが要る。チームにとって妥当な試し方は、すでに使っているフレームワークを一つ選び、カタログの定義を適用し、コマンドラインツールが示す木とGPU合計をkubectlの結果と比べ、問題なければスケジューラやプラットフォームに登録することだ。プロジェクトが部品名を改めている最中なので、入れるCRDとライブラリのバージョンにも注意したい。
プラットフォームチームにとって、このような記述層の本当の価値は、新しいフレームワークへの対応に必要なコストをリリースサイクルから切り離せる点にある。新しいカスタムリソースが現れても、これまではスケジューラやプラットフォームの次のバージョンを待つしかなかった。定義がマニフェストのように書かれ、レビューされ、適用できるなら、チームは自分で対応を補える。代償として、定義を保守し、上流のフレームワークが状態フィールドを変えたときに更新し続ける必要がある。さもないと、マッピングは気づかないうちに壊れる。
Sources
FAQ
Workload Mapはどんな問題を解決しますか？
Kubernetes上の実際のジョブは複数リソースの木であることが多く、フレームワークごとに役割、レプリカ数、Podテンプレート、状態が別のカスタムリソースに入るため、ツールごとにアダプタが要ります。Workload Mapはその構造を書いてレビューできる定義で表し、スケジューラとプラットフォームが同じ解釈を共有できるようにします。
KAI SchedulerとWorkload Mapの役割分担は？
定義が与えるのはグループ化の情報だけで、ギャング単位の受け入れと配置の判断はKAI Schedulerが行います。ネイティブなプラグインがないワークロード種別ではKAI SchedulerがWorkload Mapを代替として使い、ネイティブなプラグインが優先されるため、既存の連携を上書きせず空白を埋める位置づけです。
チームは定義をどう安全に試せますか？
すでに使っているフレームワークを一つ選び、カタログの定義を適用して、コマンドラインツールの木とGPU合計をkubectlの結果と比べます。状態式やパスは他のマニフェストと同様にレビューし、確認後にスケジューラやプラットフォームへ登録します。部品名の変更中なので、CRDとライブラリのバージョンも確認してください。