編集部より

NVIDIA DGX Spark を1〜4台接続したクラスタで LLM を動かした評価レポート、本記事はその最終回です。

第1回で推論速度、第2回でノード間帯域の実測と学習速度を扱いました。今回は、検証の過程で発生した QSFP スイッチ利用時の通信速度低下問題の原因調査、実務上の補足事項、そしてワークロード別の推奨構成をお届けします。
複数台構成を実際に運用される方には、第3回の内容が最も実用的な内容となっております。

• 第1回：概要／背景と目的／評価環境／vLLM と評価指標／推論速度評価
• 第2回：ノード間帯域の実測（NCCL Test）／学習速度評価
• 第3回（本記事）：QSFP スイッチ利用時の通信速度低下問題／補足事項／まとめと今後の予定

8. QSFP スイッチ利用時の通信速度低下問題

8.1 現象

QSFP スイッチ導入直後の NCCL Test では，2 台・4 台ともに約 2.8 GB/s と，直結時（21.8 GB/s）の 1/8 程度しか帯域が出なかった。調査の結果，以下の再現条件を特定した。

• DGX Spark 起動直後は，スイッチ接続・直結のいずれでも高速（20〜22 GB/s）。
• 稼働中に QSFP ケーブルの接続形態を切り替える（直結 → スイッチ，またはスイッチ → 直結）と，低速（2.8〜3.2 GB/s）に固定される。
• 接続形態を元に戻しても回復せず，DGX Spark を再起動すると回復する。

「QSFP スイッチの設定」「NCCL のバージョン」「DGX Spark の電力不足」を疑って調査したが，いずれも原因ではなかった（NVIDIA 推奨の NCCL バージョンでも再現）。

8.2 仮説①：RDMA から TCP ソケット通信への切替 → 否定

低速時の帯域（2.8〜3.2 GB/s）は RJ45 の理論値（1.25 GB/s）を上回るため，RJ45 へのフォールバックではない。CPU を経由しない RDMA（GPU メモリ → NIC → 相手 NIC）から，CPU がメモリコピーを行う TCP ソケット通信に切り替わり，CPU 処理がボトルネックになっているという仮説を立てた。しかし NCCL ログには高速時・低速時ともに

NCCL INFO NET/IB : Using [0]rocep1s0f0:1/RoCE ... speed=200000
NCCL INFO Using network IB

と出力されており（TCP ならば Using network Socket と表示される），通信方式は RoCE/RDMA のまま変わっていない。よってこの仮説は誤りであった。

8.3 仮説②：RDMA が性能を発揮できない状態への固定 → dmesg による観察

再起動後の高速状態で dmesg -w によるカーネルログ監視を開始し，ケーブルをスイッチ経由から直結に差し替えた際のログを時系列で確認した。

AER（Advanced Error Reporting）は PCIe 上のエラー報告機構であり，CPU と ConnectX-7 NIC を結ぶ PCIe リンクで回復不能エラーが発生している。これが通信速度低下と関連している可能性が高いが，「no details found」のためエラーの具体的内容は不明であり，因果関係は確定できていない。

8.4 当面の運用方針と追加調査の提案

• 接続形態を QSFP スイッチで固定し，稼働中のケーブル差し替えを行わない。変更が必要な場合は差し替え後に必ず再起動する。
• 追加調査として，低速化前後で lspci -vvv により NIC の PCIe リンク速度／幅（LnkSta）を比較することを提案する。差し替え後に Gen5 x8 などから低速・狭幅のリンクにダウントレーニングしていれば，2.8〜3.2 GB/s という値（おおよそ PCIe Gen3 x4〜Gen4 x2 相当）と整合する。あわせて ibstat／mlxlink によるポート状態，nvidia-smi topo -m の確認，および NIC ファームウェア・DGX OS の更新履歴の確認が有効である。

9. 補足事項

9.1 vLLM マルチノード推論に関する補足

• 並列方式の選択：本実験は Tensor Parallel（TP）を採用した。TP はレイヤーごとに all-reduce が必要で通信頻度が高く，帯域の影響を最も受けやすい。代替として Pipeline Parallel（PP）は隣接ステージ間の活性化転送のみで通信量が少なく，低帯域環境ではノード間を PP，ノード内を TP とする構成が一般的である。DGX Spark は 1 台 1 GPU のため，4 台構成では「TP=2 × PP=2」（QSFP ペア内で TP，ペア間で PP）が今回の QSFP+RJ45 トポロジに整合し，RJ45 リンクの負荷を下げられる可能性がある。ただし PP はバブルにより低負荷時の TPOT が悪化しうる。
• MoE と Expert Parallel：GPT-OSS-120B は MoE モデルであり，vLLM の Expert Parallel（EP）を用いるとエキスパートをノード間で分割でき，TP と異なる通信パターン（all-to-all）となる。DGX Spark クラスタでの TP vs EP 比較は今後の検討課題として有用である。
• マルチノード起動：vLLM のマルチノード実行は Ray クラスタ上で行う。NCCL が意図したインタフェースを使うよう NCCL_SOCKET_IFNAME，NCCL_IB_HCA，GLOO_SOCKET_IFNAME を明示し，NCCL_DEBUG=INFO で RoCE/RDMA が選択されていることをログで確認することが，第 8 章のような問題の早期検出に有効である。
• 性能に影響する設定：--gpu-memory-utilization（KV キャッシュ容量），--max-num-seqs（同時処理数），--enable-chunked-prefill（長い Prefill の分割で TTFT と TPOT のバランス改善），--enable-prefix-caching（共通プレフィックスの再利用）などが結果を左右する。比較実験では全構成で同一設定にし，レポートに明記することが望ましい。
• Speculative Decoding：メモリ帯域律速のデコードを高速化する手法として，小型ドラフトモデルによる投機的デコードが有効である。DGX Spark 単体の TPOT 改善策として検討の余地がある。
•  

9.2 測定上の注意点

• 各条件は単一試行と見られる。ウォームアップ後に複数回計測し，平均と標準偏差（または中央値と分位点）を示すことで，TTFT の np=1 で見られる十数 ms の差が有意かどうかを判断できる。
• vllm bench serve では request-rate（同時実行の到着率）が結果に大きく影響する。無限（一斉送信）か固定レートかを明記する。あわせて P50/P99 レイテンシも報告すると，Continuous Batching 下でのテールレイテンシが評価できる。
• num-prompts = 100 の推論結果は資料の図から一部欠落しており，本レポートでは推定値を用いた。元データ（JSON 出力）から再集計して差し替えることを推奨する。
• RJ45 リンク速度（1 Gbps／10 Gbps）の記載が資料間で異なる（3.1 節注記参照）。
• 学習の throughput/elapsed の一部は旧資料（2node-QSFP 直結：elapsed 4,935 s）と新資料（QSFP スイッチ：5,496.6 s）で値が異なる。接続形態や設定の違いによるものか確認が必要である。
•  

9.3 DGX Spark を複数台使う際の指針（本検討から得られた知見）

10. まとめと今後の予定

DGX Spark を複数台接続した LLM 推論では，「GPU メモリ帯域の分散による利得」と「ノード間通信のコスト」のバランスで性能が決まる。RJ45 接続では 2 台までは同等〜改善するが 4 台では低下し，QSFP（200 Gbps，実測約 22 GB/s）に変更することで 2 台構成の全指標が改善し，4 台構成でも高負荷時に大きな利得が得られた。学習では LoRA は帯域非依存で線形にスケールする一方，フルファインチューニングは QSFP でも DDP の同期コストが大きく 1 台が最速であった。QSFP スイッチ利用時のケーブル差し替えに伴う速度低下は再起動で回避できるが，根本原因（PCIe AER Fatal エラーとの関連）は継続調査中である。

全3回にわたる評価レポートの掲載は以上です。

• 第1回：概要／背景と目的／評価環境／vLLM と評価指標／推論速度評価
• 第2回：ノード間帯域の実測（NCCL Test）／学習速度評価

NVIDIA DGX Spark の詳細・お見積りは以下をご覧ください。複数台構成や QSFP スイッチを含めた構成のご相談も承っております。

• NVIDIA DGX Spark 製品ページ
• お問い合わせ