NVIDIA Workload Map、Kubernetes上のAIワークロード解析を統一

NVIDIAは、Kubernetesツールが分散AIワークロードを解釈する方法を標準化するために設計されたオープンソースコンポーネント「Workload Map」をリリースしました。2026年11月にNVIDIA DSX AI Factory Platformの一部として公開されたこのプロジェクトは、異なるAIフレームワーク間で生じるカスタムリソース定義（CRD）の断片化を解消することを目的としています。

何が起きたか

Kubernetes上でAIインフラストラクチャを運用する場合、マルチノードのトレーニングジョブや推論サーバーなど、複雑な分散タスクの管理が必要になることがよくあります。これらのワークロードは単一のPodであることはめったになく、特定の役割、レプリカ数、ステータス指標を持つリソースの木構造で構成されます。しかし、各AIフレームワークはこの情報を異なる方法でエンコードします。例えば、JobSet、LeaderWorkerSet、RayClusterはすべて、その構造を記述するために異なるカスタムリソース定義（CRD）を使用しています。

この多様性は、スケジューラー、コントローラー、ダッシュボード、コスト管理ツールを開発するチームにとって大きな負担となります。開発者はサポートしたい新しいフレームワークごとに個別のアダプターコードを作成する必要があります。アダプターの開発は一度限りのエンジニアリングコストではなく、繰り返されるロードマップ項目となり、特定のソフトウェアリリースが準備できるまで新しいワークロードタイプへのサポートが遅れる原因となることが多いです。

この問題に対処するため、NVIDIAはKubernetesワークロード構造の共通記述を提供するWorkload Mapを導入しました。本プロジェクトには、JobSet、PyTorchJob、RayCluster、RayJob、RayService、KServe、Knative、MPIJob、NVIDIA NIM、LeaderWorkerSet、Milvus、Grove PodCliqueSet、NVIDIA Dynamoなどの人気フレームワーク向けの事前構築済み定義カタログが含まれています。ワークロードに関する知識をコンパイル済みのアダプターから宣言的なデータへ移行することで、プラットフォームは各ワークロードタイプに対して個別のパースロジックを維持することなく、サポートされているワークロードタイプを解釈できるようになります。

仕組み

Workload Mapは、以前Kartaと呼ばれていたKubernetes CRDとして機能し、これらのワークロード定義を解釈するためのGoライブラリが付属しています。各定義では、指定されたワークロードタイプにおいてPodテンプレート、レプリカ数、ステータスフィールドをどこに探すかを正確に示します。Goライブラリはライブオブジェクトを一貫した構造的ビューに解決し、消費者が一貫してメタデータを抽出し、Pod仕様を更新し、ワークロード階層を理解できるようにします。

重要な特徴の一つは、ステータスマッピングのための翻訳レイヤーです。異なるフレームワークはステータスを異なる方法で報告するため、Workload Mapの定義ではネイティブの条件を共有ボキャブラリーにマッピングします。例えば、JobSetは単純な「Running」条件を報告しません。代わりに、定義ではjq式を使用して、いずれかのジョブが準備完了かつアクティブであり、失敗しているジョブがないかどうかを確認することでこの状態を導き出します。これにより、RayJobやLeaderWorkerSetも独自のステータス指標を、監視ツールで使用される同じ標準カテゴリにマッピングできます。

システムは複数の消費パターンをサポートしています。Workload Map CLIを使用すると、CRDをインストールせずにクラスターから直接ワークロードを検査し、役割とリソース要求ツリーのビューを表示できます。スケジューリングにおいては、KAI Schedulerがこれらの定義を使用してギャングスケジューリングを強制し、グループ内のすべてのPodが一緒にスケジュールされることを保証します。NVIDIA Run:aiのようなプラットフォームは同じ定義を使用して可視性を管理し、分散ジョブをバラバラのPodの集合体ではなく、単一の統合エンティティとして提示します。

主要な詳細

• Workload Mapは、JobSet、RayCluster、PyTorchJobなど、10以上の主要なAIフレームワーク向けの事前構築済み定義を提供します。
• プロジェクトはApache 2.0ライセンスの下で利用可能であり、NVIDIA DSX AI Factory Platformの一部です。
• GoライブラリとCLIにより、ツールはカスタムパーサーなしでライブオブジェクトを一貫した構造的ビューに解決できます。
• ステータスマッピングでは、jq式を使用してフレームワーク固有の条件を、Running、Completed、Failedなどの標準状態に変換します。
• ElotlのNovaスケジューラーは、マルチクラスタースケジューリング決定のためにワークロード構造を解釈するのにWorkload Mapを使用しています。
• CLIはkubeconfigのみを使用してワークロードを検査でき、クラスター内でのWorkload Map CRDのインストールは不要です。

なぜ重要なのか

AIインフラストラクチャを構築するソフトウェアエンジニアにとって、Workload Mapは新しいフレームワークをサポートする際のメンテナンスオーバーヘッドを軽減します。すべてのCRDに対して新しいアダプターコードを書いてテストする代わりに、開発者は標準化されたインターフェースに頼ることができます。これにより、既存のプラットフォームへの新しいAIツールの統合が加速し、スケジューラーやモニターが初日からワークロード要件を正確に解釈できるようになります。

また、標準化は運用上の可視性も向上させます。共有された記述がない場合、オペレーターは総リソース使用量（複数のPodにわたるGPU要求の集計など）を理解するために、手動でワークロード構造を再構築する必要があります。Workload Mapはこの集計を自動化し、分散ジョブの階層とリソース消費に関する明確な洞察を提供します。この明確さは、大規模なAIファクトリーにおける効果的なコスト管理と容量計画に不可欠です。

さらに、ワークロード解釈を特定のプラットフォームコードから切り離すことは、よりモジュール性の高いエコシステムを促進します。KAI SchedulerやNVIDIA Run:aiなどのツールは同じ定義を共有でき、作業の重複を減らします。サポートされるフレームワークのカタログが拡大するにつれ、Kubernetes上の新しいAIワークロードへの参入障壁は低下し、管理可能性を損なうことなく新興技術の迅速な採用が可能になります。

やれること

• NVIDIA DSX AI Factory GitHubリポジトリのワークロードカタログを探索し、現在使用中のフレームワーク向けの定義を見つけてください。
• Homebrewを使用してWorkload Map CLIをインストールし、既存のKubernetesワークロードを検査してその構造を可視化してください。
• JobSet定義の例を確認し、YAML内でステータスマッピングとPodテンプレートがどのように宣言されているかを理解してください。
• KAI Schedulerを使用している場合は、サポートされていないワークロードタイプに対するPodグルーピングのフォールバックとしてWorkload Mapを使用するように設定してください。
• NVIDIA DSX AI Factory Slackワークスペースに参加し、統合について議論したり、ワークロード定義に関するフィードバックを共有したりしてください。
• 事前構築済みカタログに含まれていないニッチなフレームワークを運用している場合は、カスタムYAML定義の作成を検討してください。