7月31日、NVIDIAが「NVIDIA Exemplar Cloud: Lessons for Unlocking Full Performance on AI Infrastructure」と題した記事を公開した。この記事では、同一ハードウェア構成のAIクラスターで生じる8〜12%（最大53%）の性能差を引き起こす設定要因と、その診断・解消手法について詳しく紹介されている。

同じH100でなぜ性能差が出るのか

NVIDIA H100、GB200 NVL72、GB300 NVL72といった同一システムから構築された2つのAIクラスターが、同じワークロード・同じモデル・同じバッチサイズで8〜12%の学習スループット差を生じさせることがある。この差の多くは、単一の明確な障害ではなく、カーネル・ハイパーバイザー・BIOS・NCCL（NVIDIA Collective Communications Library）の設定が積み重なった結果だ。それぞれ数パーセントの損失が複合し、NVIDIA Exemplar Cloudの検証に必要な95%閾値を下回る事態につながる。

NVIDIAはこの問題に対応するため、実際のパートナークラスターで行った4件のデバッグ調査を公開した。診断に使うツールはperf、NVIDIA Nsight Systems、nccl-testsだ。

なお、本記事では元記事のCase番号と紹介順序が異なる。損失規模が最大のCase 4を最初に取り上げ、以降をCase 1、2、3の順に紹介している。元記事と照合する際はCase番号に注意していただきたい。

最も見つけにくい穴：コンテナ内にトポロジファイルが届いていない（元記事 Case 4）

4件の中で最も見落としやすく、損失が最大のケースから紹介する。

仮想化されたB200環境で、ホスト上のnccl-testsは期待通りの性能を示していたにもかかわらず、学習スループットが参照値比で13〜53%低下していた。enrootコンテナ内でのAllGatherとReduceScatterが2〜4倍遅いという異常が起点となり、調査が進んだ。

原因はシンプルだった。

Host (VM)                              Container (enroot)
─────────                              ─────────
NCCL_TOPO_FILE=/etc/nccl/topo.xml  →  NCCL_TOPO_FILE（未伝播）
/etc/nccl/topo.xml 存在            →  /etc/nccl/topo.xml（未マウント）
                                                ↓
                                   NCCLが自動検出にフォールバック
                                     → 参照値比13〜53%低下

VMには正しいトポロジファイルが設定されていたが、環境変数もファイルもenrootコンテナに渡されていなかった。NCCLはエラーを出さずにサイレントで自動検出にフォールバックするため、原因が極めて見えにくい。

修正はバインドマウント1行だ：

--mount type=bind,source=/etc/nccl/topo.xml,target=/etc/nccl/topo.xml

最速の確認方法は、実際にジョブを動かすコンテナの内側から以下を実行することである：

echo $NCCL_TOPO_FILE && cat $NCCL_TOPO_FILE

ホストから確認しても意味がない。ベンチマークと同じコンテナ・ランチャー・Slurm割り当ての内側から確認することが鉄則だ。

Case 1：GB200 NVL72のVM環境でSMMUが24%のCPUサイクルを食っていた

GB200 NVL72上でDeepSeek-V3 MoE（Mixture-of-Experts）のFP8事前学習をVM内で実行したところ、ベアメタルの参照値より12〜14%長いイテレーション時間が観測された。Llama 3 70BのようなDenseモデルは3%以内に収まっており、多数の小カーネルを発行するMoEだけが外れ値となっていた。

perf record -a -g（30秒）の結果をperf reportで確認すると、トップフレームに**arm_smmu_cmdq_issue_cmdlistが全CPUサイクルの24%**を占めていた。

arm_smmu_cmdq_issue_cmdlistは、Arm SMMU（System Memory Management Unit）のコマンドキューに無効化命令を投入する関数だ。仮想化環境では、ゲストのmap/unmapごとにホストへのVMエグジットが発生し、単一のコマンドキューでシリアライズされるため、スピンロック競合が生じる。

修正は、ホストカーネルでCMDQV/VCMDQ（Command Queue Virtualization）を有効化し、ゲストに公開することだ。tegra241-cmdqvドライバー入りのカーネルビルドと、最新のQEMU/libvirtのcmdqv IOMMU属性が必要になる。この変更後、arm_smmu_cmdq_issue_cmdlistはトップフレームから消え、MoEのイテレーション時間差は12%からRA許容範囲内まで縮小した。

Case 2：H100クラスターでCPUが3.0 GHzに張り付き、NUMAバインドも外れていた

H100 SXM5クラスターでLlama 3 70Bの事前学習が参照値より12%遅いという事象。問題は2点同時に存在していた。

• CPUクロック固着：turbostat -i 1の結果、ターボ定格3.8 GHzのSKUで全コアが3.0 GHz張り付き。BIOSのC-stateがC1止まりになっており、アイドルコアが電力を消費し続けていたため、GPUへカーネルを供給するビジーコアがターボに必要なパッケージ電力を確保できない状態だった。C6への移行を許可することで約4%回復。

• **NUMAリモートアクセス18%**：numastat -p <python_pid>で、学習プロセスのメモリアクセスの約18%がリモートNUMAノードに向いていることが判明。ハイパーバイザーのハウスキーピングスレッドが学習プロセスのデータローダーワーカーと同じ物理コアに配置されており、VMからは散発的な50〜100msのPythonスレッドストールとして現れ、ステップタイムのロングテールを引き起こしていた。cpusetでコア0〜7と56〜63をハイパーバイザー用、残りを学習用に分離することで解消。

結果として12%の差は3%まで縮小。残り3%は次のCase 3のNCCL問題に起因していた。

Case 3：GB300 NVL72の1.6 Tbpsファブリックでキューペア数が足りなかった

GB300 NVL72 + ConnectX-8 SuperNIC（1.6 Tbps/ノード）の環境でNemotron-4 15Bの事前学習を512 GPUスケールで実行したところ、31%の性能差が出た。シングルノードは問題なく、プロファイルではAllGatherとReduceScatterの時間が露出していた。

調査の結果、解決に直結した変更は**NCCL_IB_QPS_PER_CONNECTIONをデフォルトの1から4に増やす**ことだった。

参照クラスターでの計測：

表中の「AllGather帯域幅 約28 GB/s（QPS=1）vs 約61 GB/s（QPS=4）」という数値は、元記事が512 GPU構成でのnccl-tests計測で得たものであり、1.6 Tbps/ノードという高帯域ファブリック上でQPS=1では単一キューペアがボトルネックとなり、帯域が飽和しきれないことを示している。

ただし記事は「QPS=4をどこでも上げれば良い」という結論を否定している。QPS設定はファブリックとワークロード依存であり、別のファブリックや異なるメッセージサイズではCPUオーバーヘッドが増えるだけの場合もある。実際のメッセージサイズでコレクティブをテストし、対象ファブリックでスイープして確認する必要がある。

4ケースのまとめ

記事全体を通じて共通するのは、「性能差はたいてい単一の原因ではなく、各レイヤーの小さな設定ミスの積み重ねである」という点だ。そして診断は必ず、実際にワークロードを動かすコンテナ・ランチャー・Slurm割り当ての内側から行うべきである。

詳細はNVIDIA Exemplar Cloud: Lessons for Unlocking Full Performance on AI Infrastructureを参照していただきたい。