DGX Spark 1台でも、単一ノードの推論ホストとして十分に強力です。ConnectX-7で2台のSparkを接続する構成は、1つの128 GBコヒーレントメモリープールに収まらないモデルやエージェントワークロード、あるいはノードをまたぐテンソル並列サービングが必要なワークロードへ拡張するために、NVIDIAが想定している経路です。
この記事は、NVIDIAが公式に示すクラスタリングの全体像と、connect-two-sparksプレイブックに沿って説明します。実際にケーブルを接続する当日は、必ず最新の公式ドキュメントを確認してください。この記事はその代わりにはなりません。
主な情報源（まずここから）：
- ConnectX-7ネットワークとクラスタリング（DGX Sparkユーザーガイド）
- connect-two-sparksプレイブック
- NVIDIA Sync（Cluster Assistant）
- 製品情報：DGX Spark · DGX Sparkとは何か · ローカル推論の実情
ネットワークの再設定は、ノードを孤立させたり、管理アクセスを失わせたりする可能性があります。ConnectX-7のnetplanを変更する前に、10 GbE／管理インターフェース上の、確実につながると分かっているSSH経路から作業してください。承認済みのQSFPケーブルを使い、向きの合わないコネクタをポートへ無理に押し込まないでください。NVIDIAは、無理な挿入がポートを損傷する可能性があると文書に記載しています。
構築するもの
全体の流れは次のとおりです。
- QSFPケーブルで2台のConnectX-7ポート同士を物理的に接続します（200 Gbps級の経路。ケーブルは最低200 Gb/sに対応している必要があります）。
- そのポートに対応して現れるLinuxのEthernetインターフェースへIPアドレスを割り当てます（各QSFPポートは2つの論理インターフェースに対応します）。
- 両方のシステムで同じユーザー名を使います。
- ノード間でパスワードレスSSHを確立します。
- 高速経路上で分散ワークロードを実行します（マルチノードの推論または学習レシピが使うNCCL／RoCE系のトラフィック）。
NVIDIAのプレイブックには、所要時間とリスクについてNVIDIA自身の見積もりが記載されています。これはベンダーによる計画上の目安であり、自分の環境で成り立つ約束として扱ってはいけません。インターフェースに関する指示や前提条件は変わる可能性があるため、変更作業の前に最新のREADMEを読み直してください。
前提条件
公式プレイブックの要件は次のとおりです。
| 要件 | 理由 |
|---|---|
| DGX Spark 2台 | 当然の前提ですが、どちらも最新のDGX OSで動作していること |
| QSFPケーブル1本（直結200GbE） | NVIDIAは1本のケーブルでのフル帯域を文書化している。2本目のケーブルによるスループット向上は文書化されていない |
| 両方でのSSHアクセスとsudo | 設定作業と鍵の配布に必要 |
| 両方のシステムで同じユーザー名 | プレイブックと探索スクリプトはユーザー名の一致を前提とする |
必須ではありませんが、管理用SSHセッションを見守るもう1人の担当者と、変更前のip addr／ibdev2netdevの出力の控えがあると役立ちます。
経路A：NVIDIA Sync Cluster Assistant
netplanの手作業を減らしたい場合のガイド付きの経路として、NVIDIAはNVIDIA Sync Cluster Assistantを文書化しています。
- サポート対象のトポロジーに対する自動検出とネットワークの自動作成。
- ConnectX-7の設定を適用し、リンク性能を確認して、ノード間のSSHを設定します。
- ケーブルで直結するSparkは最大3台、スイッチを使う場合は最大4台まで対応します（NVIDIA Sync／クラスタリング文書に基づく）。
ノートPCにSyncをインストールしてSparkを追加し、トポロジーがサポート対象であれば、YAMLを手で編集する代わりにCluster Assistantを使ってください。物理的なケーブル配線の規則、左右のポートの向き、インターフェース命名の背景については、引き続きConnectX-7ネットワークとクラスタリングを読んでください。Cluster Assistantが減らすのは入力の手間です。正しいケーブルとロールバック計画の必要性はなくなりません。
経路B：手動プレイブック（connect-two-sparks）
1. 同じユーザー名
whoami
ユーザー名が異なる場合は、両方のシステムに同じ名前のユーザー（プレイブックの例ではnvidia）を作成し、sudo権限を与え、そのユーザーとして作業を続けます。分散処理のレシピとSSH鍵のスクリプトは、ユーザー名の一致を前提としています。
2. QSFPの物理接続
- 2台のSparkの間にQSFPケーブルを1本接続します。
- NCCLを使うプレイブックに従う場合は、各デバイスで同じ位置の物理ポートを使うことを推奨します（NVIDIAは、テスト時の問題を避けるためにポートをそろえるよう言及しています）。
- プルタブを上に向け、力を入れずに奥まで挿入します。
ibdev2netdevでリンク状態を確認します。該当するインターフェースがUpと表示されるはずです。
1つの物理QSFPポートは、2つのLinux Ethernetインターフェース（および対応するRoCEデバイス）として現れます。NVIDIAのプレイブックの例では、同じ物理ポートにenp1s0f1np1とenP2p1s0f1np1のような名前が付いています。実機での名前は異なる場合があるため、手元のユニットでibdev2netdevが示す結果を信頼してください。
NVIDIAのクラスタリング文書では、Spark上のQSFPポートはEthernetとして設定されています。NVIDIAが200 Gb/s以上に適合するとして掲載しているケーブルを使ってください。より高速なケーブルを使っても、ポートの上限である200 Gb/sは上がりません。
3. IPアドレスの設定
プレイブックには次の2つの方法があります。
- オプション1 — netplan（
/etc/netplan/40-cx7.yaml）：再起動後も設定が維持されます。chmod 600を設定し、sudo netplan applyを実行します。 - オプション2 —
ip addr add：手早く試せますが、IPアドレスは再起動後に消えます。
プレイブックに記載されたアドレス設定パターンの例です（インターフェース名は、実際にUpになっているインターフェースに合わせて調整してください）。
| ノード | インターフェースA | インターフェースB |
|---|---|---|
| Node 1 | 192.168.100.10/24 | 192.168.101.10/24 |
| Node 2 | 192.168.100.11/24 | 192.168.101.11/24 |
上記の2つのアドレスは、いずれも同じケーブル接続済みポートが持つ2つの論理インターフェースに属します。つまり、ケーブル1本の接続でもすでに2つのサブネットを使用しています。NVIDIAのプレイブックは、QSFPケーブル1本でフル帯域を実現できると述べており、同社の2台構成Sparkのベンチマークガイドはケーブル1本でRoCE帯域を測定し、そのポートが持つ2つのリンクの合計を約190 Gb/s——200 Gb/sのポート上限——と算出しています。2本目のケーブルについてプレイブックが述べているのは構成上の要件だけです。すなわち、2本のケーブルを接続する場合は、その構成で本来の帯域を得るために4つのインターフェースすべてにIPアドレスを割り当てる必要がある、という点です（2本目が帯域を上乗せするという意味ではありません）。NVIDIAは、同じ2台のシステム間に2本目のケーブルを追加することをスループットの増加としては文書化していません。したがって2本目のケーブルは、同じ2台に対する追加帯域としてではなく、3台目のノードやスイッチドファブリックといったトポロジーとして計画してください。
SSHのデバッグを始める前に、両方のノードでip addr show <iface>を実行して確認してください。
4. パスワードレスSSH
自動： いずれかのノードでプレイブックのdiscover-sparksスクリプトを実行すると、ピアを検出して鍵を配布します（最初の1回はパスワードの入力を求められる場合があります）。
手動： 共有ユーザー名を使い、ssh-copy-idで自分の公開鍵を両ノードのConnectX-7のIPへ登録します。
次のコマンドで確認します。
ssh <node1-cx7-ip> hostname
ssh <node2-cx7-ip> hostname
5. 分散ワークロードとRoCE
パスワードレスSSHとL3の到達性が土台です。そのうえで、マルチノードの推論や学習のレシピは、集合通信（NCCLなど）をConnectX-7／RoCE経路に依存します。Wi-Fi 7や10 GbEのRJ-45ポートがこのファブリックを担えると期待してはいけません。
接続が確立した後の手順は、通常は別のプレイブック（vLLMのマルチノード構成、NCCLテスト、特定モデルのレシピ）に記載されています。モデルサーバーを疑う前に、使用中のソフトウェアバージョンに対応する、NVIDIAが文書化したNCCL／クラスタリングのチェックで集合通信を検証してください。
インターフェース命名の落とし穴（YAMLを書く前に読む）
NVIDIAのクラスタリングガイドは、「NIC 1枚＝eth0が1つ」に慣れた人がSparkのConnectX-7構成に混乱する理由を説明しています。
- 各QSFPポートは、SoCへの2つのPCIe経路を持ちます。
- そのためLinuxは、物理ポート1つに対して2つのEthernetインターフェースと、対応するRoCEデバイスを公開します。
- プレイブックの例（
enp1s0f1np1、enP2p1s0f1np1など）はあくまで例示です。ケーブルを接続したら、必ず自分の2台でibdev2netdevの出力から対応関係を確認してください。
netplanがDown状態のインターフェースを参照し、Up状態のペアが無視されていると、「ケーブルの不良ではないか」という当てのない推測を1時間追いかけることになります。最初の立ち上げでは、クラスタリング文書にある対応表を印刷して端末の横に置いてください。
CX7サブネットに関するセキュリティの注意
ConnectX-7のリンクは、ゲスト用Wi-Fiではなく信頼済みのファブリックとして扱ってください。
- 社内のユーザー向けVLANへ安易にブリッジしないでください。
- これらのIP上でRPC／NCCL／推論用ポートにバインドできるプロセスを制限してください。
- ノード間のパスワードレスSSHは、どちらかの筐体が侵害された場合に強力な横展開の手段になることを忘れないでください。物理アクセスとOSアカウントをそれに見合う水準で保護します。
- CX7での設定ミスが完全なロックアウトに直結しないよう、管理作業と「人が使うSSH」は、文書化された管理経路で行う習慣を保ってください。
リスク、検証、ロールバック
| リスク | 重要な理由 | 対策 |
|---|---|---|
| netplanに誤ったインターフェース名を書く | リンクが確立しない、またはルーティングが壊れる | 編集前にibdev2netdevの出力を記録する。不安があれば片側ずつ変更する |
| 管理アクセスのロックアウト | CX7だけを設定して10 GbEのSSHを失う | ノートPCのSync／管理経路を開いたままにする |
| ユーザー名の不一致 | SSHとスクリプトが原因の分かりにくい失敗をする | まず同じユーザー名をそろえる |
| RoCE検証の省略 | 誤ったNIC経由で推論が「動く」ものの遅い | トラフィックがCX7を通ることを確認し、NCCL／リンクのチェックを実行する |
| ロールバックメモがない | 障害対応が長引く | 変更前のYAMLとip addrの出力を保管する |
ロールバックの設計（NVIDIAのプレイブックを対象ホストに合わせて調整してください）：
- 編集する前に、
/etc/netplan/40-cx7.yamlがすでに存在するか、また他のnetplanファイルが同じインターフェースを設定していないかを確認してください。該当するファイルをバックアップし、ハッシュ、所有者、パーミッションを記録します。 - 既存のファイルを安易に削除しないでください。変更前のファイルをそのまま復元して
sudo netplan generateを実行し、生成結果を確認したうえで、正常に機能すると分かっている管理経路から適用してください。 - 一時的なアドレスについては、今回の変更で明示的に追加したアドレスだけを削除し、削除後のルートとリンク状態を確認してください。
- 両方のノードがロールバック後のSSHとルーティングの確認に合格するまで、コンソールまたは独立した管理アクセスを確保しておいてください。
ロールバックはクラスタのネットワーク設定をリセットします。マルチノードのエンドポイントに依存している利用者がいる場合は、変更作業の時間枠として予定してください。設定を削除する前に、管理用SSHがまだ機能することを確認してください。
トラブルシューティング早見表
NVIDIAのプレイブックに記載された症状に基づきます。
| 症状 | 考えられる原因 | 対処の方向性 |
|---|---|---|
| Network unreachable | インターフェースが未設定、またはnetplanが未適用 | YAML、インターフェース名、netplan applyを再確認する |
| SSH認証の失敗 | 鍵が配布されていない | discover-sparksの再実行、または手動でssh-copy-idを実行する |
| ピアが見えない | ケーブル、ポート、またはIPの不一致 | QSFPを挿し直し、Upのインターフェースとサブネットを確認する |
| NCCL／分散処理のハング | 誤ったNIC、ファイアウォール、またはSSH／MPIの設定 | レシピがCX7のIPを使っているかを確認し、RoCEデバイスを確認する |
現時点では避けること
- SSHとリンクのチェックに合格する前に、本番用のテンソル並列モデルを起動しない。
- 再起動をまたいで、場当たり的なIP設定と放置されたnetplanファイルを混在させない。
- CX7サブネットを信頼できないネットワークへ公開しない。
- QSFPコネクタを無理に押し込んだり、ユーザーガイドの速度・互換性の注記を確認せずに手近なDACケーブルを使ったりしない。
最小限の受け入れテスト
エージェントをマルチノードのエンドポイントへ接続する前に、次を確認します。
- 両方のノードがCX7サブネット上でpingに応答する。
- 共有ユーザーとして、双方向でパスワードレスSSHが機能する。
- 文書化されたNCCLまたはプレイブックのリンクチェックが合格している。
- サービングレシピのノードリストが、Wi-FiのIPではなくCX7のアドレスを使っている。
- 正確なバックアップと復元の手順を、管理経路を失うことなくメンテナンス時間枠内でテスト済みである。
2台のSparkと承認済みのQSFP経路による構成は、NVIDIAが文書化しているパターンです。この記事に記載した立ち上げとロールバックのコマンドはベンダー文書に従ったものであり、個々のハードウェア、ケーブル、ソフトウェアバージョンで検証済みの結果ではありません。新しいファブリックの立ち上げは、変更管理の対象となるネットワーク切り替え作業として扱い、受け入れの証拠を自分で記録してください。ローカル推論の実情で述べた制約を検討するのは、ファブリックがこれらのテストに合格してからです。
