概要
NVIDIA Developer Blogによると、同社はAIフレームワークの管理を効率化する「NVIDIA Workload Map」を公開しました。
バラバラになりがちな分散AIワークロードの設定を共通化する仕組みです。
専用の解析コードを何度も書く必要をなくします。
インフラを管理するエンジニアの負担を大きく減らします。
何が発表された?
今回の発表は、NVIDIA DSX AI Factoryプラットフォームの一部として提供されます。
これはオープンソースのオープンなコンポーネントです。
Kubernetes環境で動く様々なAIフレームワークの構造を共通で定義します。
スケジューラーや管理プラットフォームから直接解釈できるようにします。
提供されている主な要素や対応する仕組みには、次のようなものがあります。
- JobSetやPyTorchJobなどの定義済みカタログ
- ライブオブジェクトを構造化して解決するGoライブラリ
- ワークロードの構造を可視化するCLI(kli)
- KAI Schedulerによるギャングスケジューリングの連携
- NVIDIA Run:aiでの統合管理
フレームワークごとのアダプターがなぜ必要だったのか?
Kubernetes上で動く実際のAIワークロードは単一のポッドではありません。
役割を持つ複数のポッドやレプリカ数を含む小さなツリー構造になっています。
ダッシュボードやコスト管理ツールなどを作る開発者は大きな課題を抱えていました。
カスタム資源(CRD)ごとに構造を解釈する専用のアダプターを個別に用意しなければなりませんでした。
そのため新しいフレームワークに対応するたびに開発のロードマップに項目の追加が必要になりました。
これがサポートが遅れる原因になっていました。
共通のワークロード定義はどう機能するのか?
Workload Mapは複数の要素で構成されています。
Kubernetesのカスタム資源(CRD)とそれを解釈するGoライブラリです。
定義ファイルには重要な情報が記述されます。
ポッドのテンプレート、レプリカ数、ステータスフィールドの場所です。
たとえばJobSetの設定ではjq式を使います。
独自の条件から「Running」や「Completed」といった共通の語彙にマッピングします。
これによりフレームワーク特有の複雑なスキーマを共通のツリー構造に解決できます。
ツール間でどう再利用されるのか?
作成した一つのワークロード定義は複数のワークフローでそのまま再利用できます。
CLIを使ったワークロードの確認では定義を読み込みます。
これでツリー表示やリソースの合計を把握できます。
またKAI SchedulerやNVIDIA Run:aiなどのプラットフォーム側でも利用できます。
追加の個別コードなしで同じ定義を直接利用して管理や可視化を行います。
日本で使える?
日本からでも今日から内容を確認して利用できます。
GitHub上のオープンソースとして公開されているリポジトリや開発者向けSlackが使えます。
今日から試すための主な手順は次のとおりです。
- macOSやLinux環境でHomebrewを使い、リポジトリからCLI(kli)をインストールする
- クラスターのコンテキストを設定し、対応するネームスペースでコマンドを実行する
- カタログから既存のフレームワーク定義を自分の環境に適用する
自分にはどう関係する?
エンジニアなら
フレームワークごとに異なる設定の仕組みを個別に実装する手間が減ります。
管理ツールの開発や運用を効率化できます。
企画・マーケティングなら
直接的な影響は大きくありませんが理解しておくと便利です。
社内のAI基盤の構築や運用コストの削減につながる基盤技術として把握しておくと役立ちます。
経営者・管理者なら
AI開発を支えるインフラの運用効率が向上します。
新しいフレームワークの導入にかかるリードタイムを短縮できる可能性があります。
まとめ
NVIDIA Workload Mapは複雑なAIフレームワークの管理負担を減らす実用的なアプローチです。
まずは提供されているカタログやリポジトリを確認してみましょう。
手元の環境での検証を進めてみましょう。