NVIDIA Topograph公開、クラスターのネットワークトポロジーを自動発見し最適配置

NVIDIA Topograph公開、クラスターのネットワークトポロジーを自動発見し最適配置

基本情報

項目 内容
公開元 NVIDIA Developer
公開日 2026-09-23
出典の種類 公開元の一次情報(NVIDIA公式開発者ブログが一次情報)

収集・肉付けの時点で当サイトのコードが確定させた値です。日付はJST。

概要

NVIDIAは、クラスターのネットワークトポロジーを自動的に発見・正規化し、スケジューラーがトポロジーを認識した配置を行えるようにするオープンソースのツールキット「NVIDIA Topograph」を発表しました。このツールは、クラウドAPIやオンプレミスのファブリックシステムから情報を取得し、KubernetesのノードラベルやSlurmの設定ファイルとして出力することで、AIワークロードを最も効率的な通信ドメインに配置することを可能にします。

発表の内容

NVIDIA Topographは、「プロバイダー（Provider）」と「エンジン（Engine）」という2つの主要な概念で構成されています。プロバイダーは、クラウドAPIやオンプレミスのシステムからクラスターのトポロジーを検出して共通のモデルに正規化する役割を担い、エンジンはそのモデルを各ワークロードマネージャーが解釈可能な形式に変換します。

具体的には、以下のような環境および出力形式に対応しています。

  • 対応クラウドプロバイダー: Google Cloud、Lambda、Nebius、Nscale、Oracle Cloud Infrastructure (OCI) などが統合されており、さらなるプロバイダーの開発も進められています。
  • オンプレミス環境: InfiniBand（ibnetdiscoverを使用）、Spectrum-X、またはMulti-Node NVLink (MNNVL) ドメインをサポートしています。
  • 出力形式（エンジン）:
    • Kubernetes用のノードラベル、Node Feature Discovery (NFD) リソース – Slurm用のトポロジー設定（tree、block、またはSlurm 25.05以降のパーティション別YAML形式） – Slinky用のConfigMap – インスタンス指向のトポロジーJSON

また、Topographはクラスターの変化を継続的に監視し、トポロジーのビューを自動的に再生成するため、手動でのメンテナンスなしにスケジューラーを最新の状態に保つことができます。Kubernetes環境ではHelmを使用してデプロイでき、Slurm環境ではDebianやRPMのネイティブパッケージとして提供されます。さらに、本番環境のハードウェアがない場合でも、kwok-nodesなどのユーティリティを用いたシミュレーションによるテストが可能です。

背景

AIファクトリーは、電力供給に制限があるシステムであり、その価値を最大限に引き出すためには高度な最適化が不可欠です。その中でも、GPUワークロードの配置は極めて重要な最適化項目となります。

ワークロードの配置が不適切であると、トポロジードメインが断片化され、共有リンクを介した通信が増加します。その結果、スループットの低下やジョブコストの上昇を招くだけでなく、データ待ちの状態にあるGPUが、ワークロードを進展させることなくプロビジョニングされた電力を消費し続けるという非効率な状況が発生します。

トレーニングや推論のプロセスにおいて、GPUは継続的にデータを交換するため、通信の局所性（locality）が重要となります。NVIDIA NVLinkやNVLink Switchは、ラックスケールでの高帯域な全対全（all-to-all）接続を提供し、NVIDIA Spectrum-X Ethernetは、システムやラックを跨ぐ予測可能で低遅延なネットワーキングを提供します。スケジューラーがこれらのGPUとファブリックの関係を正確かつ最新の状態で把握できているかどうかが、効率的な配置を実現するための鍵となります。

ローカルLLMの利用者への影響

オープンウェイトのモデルを大規模なクラスターで運用する技術者にとって、Topographの導入は、計算リソースの利用効率、コストパフォーマンス、および「tokens per watt（ワットあたりのトークン数）」の向上に直結します。

具体的なラベルを用いた配置制御

Topographは、物理的なネットワーク構成をKubernetesのノードラベルとして公開します。これにより、既存のスケジューラーを用いて、通信負荷の高いワークロードを物理的に近いリソースに集約することが可能になります。具体的には、以下のようなラベルが利用可能です。

  • fabric.topograph.run/tier-<N>: ノードに最も近いスイッチをtier-0とし、外側に向かって階層を示すラベル
  • accelerator.topograph.run/domain: アクセラレータのドメイン
  • accelerator.topograph.run/sub-domain: オプションのネストされたサブドメイン

例えば、Kubernetesの podAffinity において、topologyKey にこれらのラベルを指定することで、特定の通信ドメイン内にPodを優先的に配置する制御が行えます。

エコシステムとの連携による高度なスケジューリング

Topographは、既存のオーケストレーションツールと連携して、より高度な配置を実現します。

  • KAI Schedulerとの連携: CNCF SandboxプロジェクトであるKAI Schedulerを使用する場合、Topographが提供するラベルを階層構造（例：zone -> tier-1 -> tier-0 -> hostname）として整理して利用できます。これにより、トポロジーを考慮した「ギャングスケジューリング（gang scheduling）」が可能になり、大規模な分散学習における効率が向上します。
  • KueueおよびNFDの利用: KubernetesのKueueや、Node Feature Discovery (NFD) とも連携可能です。NFDエンジンを使用する場合、トポロジー情報をNodeFeatureGroupとして公開できます。
  • Slinkyとの連携: NVIDIAが2025年12月に買収したSchedMD社のSlinkyを利用している環境では、TopographのSlinkyエンジンを通じて、KubernetesノードをSlurmのslurmd Podにマッピングし、SlurmのトポロジーデータをConfigMapとして書き出すことができます。

運用の柔軟性と検証環境

本ツールはオープンソースとして提供されており、プロバイダーのインターフェースも公開されています。そのため、独自の環境向けのプロバイダーを開発してアップストリームに貢献することも可能です。また、クラスターの変化を継続的に監視してトポロジービューを自動更新するため、手動でのメンテナンスによる設定の乖離を防げます。

さらに、本番環境のハードウェアを必要とせずに、kwok-nodes などのユーティリティを用いたシミュレーションによって、仮想的なKubernetesノード上でトポロジー認識スケジューリングのテストを行うことも可能です。

関連記事

出典

更新履歴

  • 2026-09-23: 記事の組み立てを更新しました: GGUF量子化版のビルド重複合算バグを修正(必要メモリ・VRAM早見表)
  • 2026-09-23: 記事の組み立てを更新しました: 投機的デコード用draft head(mtp-)ファイルを本体と誤認していたバグを修正(必要メモリ・VRAM早見表)

企業・資金調達InfiniBand,Kubernetes,NVIDIA,NVIDIA Developer,Slurm,Topograph,確認済み