DGX Spark を 2 台つないで大規模モデルの分散推論を試してみた

はじめに

こんにちは、クラスメソッド製造ビジネステクノロジー部の森茂です。

前回の記事までの検証で、DGX Spark は 1 台でも Qwen3-235B クラスの大規模 MoE モデルが動き、コード補完環境も構築できました。

ただ、ずっと気になっていたのが「2 台つないだら、もっと大きなモデルが動くのか？ もっと速くなるのか？」という点です。NVIDIA 公式の Connect Two Sparks Playbook でも、200Gb/s の QSFP 直結で 2 台をクラスタ化する手順が公開されています。

結論から言うと、2 台にしても速くはなりませんでした。ただし 1 台に収まらない 143GB や 168GB のモデルが実用的な速度で動くので、より大きなモデルを動かせること が 2 台構成の一番のメリットですね。

この記事では、QSFP ケーブルでの物理接続から分散推論の実測データまで、2 台構成にしてみたらどうなのか？をお伝えします。

検証環境

ハードウェア構成

2 台の DGX Spark を QSFP112 DAC ケーブルで直結する構成です。

2 台合わせてメモリは 256GB。ただし物理的に統合されるわけではなく、llama.cpp の RPC プロトコルでモデルを 2 台に分割配置します。

ソフトウェアスタック

今回は Ollama ではなく llama.cpp を直接使います。Ollama は現時点で RPC 分散推論に対応していないため、llama-bench で生のスループットを計測する構成です。

テストしたモデル

検証対象は Dense と MoE の両方を含む 5 モデル。1 台で動くものから 2 台必須のものまで段階的に選びました。

GGUF ファイルはすべて unsloth 版を使用しています。

環境構築

QSFP ケーブルの接続

DGX Spark の背面には ConnectX-7 Smart NIC のポートがあり、QSFP112 DAC ケーブルを差し込むだけで物理接続は完了します。ホットプラグ対応なので、電源を落とさずに作業できました。

ネットワーク設定

ケーブルを接続したら、netplan で IP アドレスを割り当てます。自分の環境ではインターフェース名が enp1s0f0np0 でした。

network:
  version: 2
  ethernets:
    enp1s0f0np0:
      addresses:
        - 192.168.100.10/24  # Node A
      mtu: 1500

Node B 側は 192.168.100.11/24 を設定します。

# 設定を適用
sudo netplan apply

# 疎通確認
ping -c 3 192.168.100.11

llama.cpp のビルド

両方のノードで、CUDA と RPC を有効にしてビルドします。

git clone https://github.com/ggml-org/llama.cpp.git
cd llama.cpp
mkdir build && cd build
cmake .. -DGGML_CUDA=ON -DGGML_RPC=ON -DCMAKE_BUILD_TYPE=Release
cmake --build . --parallel $(nproc)

ビルド自体は ARM 環境でも特にトラブルなく完了しました。

RPC の起動と動作確認

分散推論の流れは以下のとおりです。Node B で RPC サーバーを起動し、Node A から RPC 経由でモデルを 2 台に分散して実行します。

# Node B: RPC サーバー起動
CUDA_VISIBLE_DEVICES=0 ./build/bin/rpc-server \
  --host 192.168.100.11 -p 50052

# Node A: ローカル RPC サーバー起動
CUDA_VISIBLE_DEVICES=0 ./build/bin/rpc-server -p 50052 &

# Node A: ベンチマーク実行（2 台構成）
./build/bin/llama-bench \
  -m ~/models/Devstral-2-123B-Q4_K_M/Q4_K_M/Devstral-2-123B-Instruct-2512-Q4_K_M-00001-of-00002.gguf \
  --rpc 192.168.100.11:50052,127.0.0.1:50052 \
  -ngl 99 -fa 1 \
  -p 128 -n 256 -r 5
# -ngl 99: 全レイヤーを GPU にオフロード
# -fa 1: Flash Attention 有効
# -p 128 -n 256: プロンプト 128 トークン、生成 256 トークン
# -r 5: 5 回実行して平均を取る

モデルファイルは Node A に配置しておけば、RPC サーバーにストリーミングで転送されます。ロードに少し時間がかかりますが、一度ロードされればあとは自動的に分散して推論が走ります。

ネットワーク帯域の実測

分散推論の性能はネットワーク帯域に大きく依存します。ベンチマーク前に iperf3 で実測しました。

MTU は 1500 のままでこの数値です。200Gb/s リンクの理論値に対して約 53% の利用率ですが、llama.cpp の RPC はレイヤー単位でテンソルを送受信する程度なので、帯域がボトルネックになることはなさそうです。

ベンチマーク結果

ここからが本題です。llama-bench で prefill（プロンプト処理）と decode（トークン生成）を分離計測しました。各テスト 5 回実行の平均値と標準偏差を載せています。

llama.cpp の RPC ではモデルの分割方式を 2 種類から選べます。layer split はレイヤー単位で前半・後半に分けるパイプライン並列、row split はテンソルを行方向に分割するテンソル並列です。以降の表では、1 台構成を S1、2 台の layer split を D2-layer、row split を D2-row と表記します。

Devstral 2 123B で Dense モデルの基準線を見る

まずは Dense モデルの Devstral 2 から。75GB なので 1 台でも余裕で動きます。2 台にして速くなるかどうか、基準線として計測しました。

単位は tok/s。pp = prefill、tg = decode（トークン生成）。

decode は 1 台と 2 台でまったく同じ 2.64 tok/s。Dense 123B のトークン生成はメモリ帯域幅が律速になっており、2 台に分散しても RPC の通信オーバーヘッドで帯域幅の恩恵が相殺されてしまうようです。

唯一差が出たのは長いプロンプト（pp2048）の prefill で +25%。これは計算量が増えて GPU の演算能力が活きるフェーズなので、2 台分の計算リソースが効いている形です。

ただし decode 2.64 tok/s は正直かなり遅く、対話的に使うのは厳しいですね。Dense 123B を DGX Spark で動かすなら、速度面では 1 台で十分という結論です。

Qwen3-235B で MoE モデルの分散効果を確認する

次は MoE モデルの Qwen3-235B。105GB なので 1 台でもギリギリ動きます。1 台と 2 台で速度差が出るのか、個人的には一番気になっていたテストです。

decode は 2 台の方がわずかに遅くなっています。

MoE（Active 22B）は 1 台でも 15.5 tok/s 出ており、これは十分に実用的な速度です。2 台にすると RPC のレイテンシが乗る分だけ微減してしまいました。prefill は長いプロンプト（pp2048）で +17% の改善が見られますが、decode で恩恵がないのは少し意外でした。

MoE はトークン生成時に Active パラメータ（22B）分しかメモリを読み出さないので、もともと 1 台のメモリ帯域幅で足りているんですよね。分散させてもボトルネックが変わらず、通信オーバーヘッドだけが増えるという結果です。

2 台でしか動かないモデルたち

ここからが 2 台構成の本領発揮です。128GB に収まらないモデルは、そもそも 1 台では動きません。

Llama 4 Maverick（143GB）

Meta の MoE モデルで、128 experts という構成が特徴的です。

ここで面白い発見がありました。decode で row split が layer split を +19% 上回っています。Maverick は 128 experts の MoE で、テンソルを行方向に分割する row split だと、各 expert のテンソルが 2 台に均等に分散されて decode フェーズの効率が上がるようです。

Qwen3-235B では逆に layer split の方が良かったので、expert 数やモデルサイズによって最適な分割方式が変わるということですね。

decode 13.16 tok/s は対話的な利用にも耐えるレベルで、143GB のモデルがこの速度で動くのは 2 台構成ならではの価値だと思います。

Qwen3-Coder-480B（168GB）

コーディング特化の 480B MoE モデルです。

decode 9.86 tok/s。Active パラメータ 35B の分だけ Maverick（17B active）より遅くなりますが、480B パラメータのモデルがデスクトップ 2 台で動いてほぼ 10 tok/s 出ています。

168GB を 2 台の 256GB に載せると、Node A 側のメモリ使用量が 116/119GB まで達しました。実用上の上限は 170GB 前後と見ておいた方がよさそうです。

DeepSeek-V3-0324（204GB）は OOM で断念

最も期待していた DeepSeek-V3-0324（204GB）はロードすらできませんでした。KV キャッシュの量子化（q8_0）を付けても Node A が固まる事態に。。。現時点では 170GB 前後が実用上限になりそうです。

この上限がどの程度の制約になるか、最新モデルで確かめてみましょう。記事執筆時点で話題の GLM-5 は 744B パラメータ、40B active の MoE で、unsloth の Dynamic 1-bit 量子化でも 176GB、2-bit だと 241GB です。1-bit でも Qwen3-Coder-480B（168GB）より 8GB 大きく、2 台構成の実用上限をわずかに超えてしまいます。

https://unsloth.ai/docs/models/glm-5

Active 40B から推定される decode 速度は 8〜9 tok/s 程度で、仮に動いたとしても Qwen3-Coder と同等です。最新の大規模 MoE を手元で試したい気持ちはあるものの、現状の DGX Spark 2 台 + llama.cpp RPC では一歩届きませんでした。

全モデルの decode 性能を並べてみる

ここまでの結果を decode（tg256）で横並びにしてみましょう。

decode 速度は Active パラメータの大きさにほぼ比例しています。Dense 123B の Devstral 2 が 2.64 tok/s なのに対して、MoE 22B active の Qwen3-235B は 15.5 tok/s と約 6 倍。メモリ帯域幅 273 GB/s がボトルネックになる DGX Spark では、Active パラメータが小さい MoE モデルとの相性が良いことがわかります。

Split mode の選び方

ベンチマーク結果の冒頭で触れた layer split と row split について、今回の結果をまとめると以下のような傾向でした。

Maverick で decode に限り row が大きく勝ったのは、128 experts という多数の expert テンソルを行分割することで、各ノードが担当する演算量が均等になりやすいためだと考えています。Qwen3-235B は 16 experts なので、テンソル分割の恩恵が小さいのでしょう。

万能な分割方式はないので、大きな MoE モデルでは両方試してみるのが無難かなと思います。

$7,998 の正直な評価

DGX Spark 2 台で $7,998。この投資に見合うかどうか、用途別に整理してみます。

2 台にする価値があるケース

1 台に収まらないモデルを動かしたい場合、これが最大かつほぼ唯一のユースケースです。Maverick（143GB）で decode 13 tok/s、Qwen3-Coder-480B（168GB）で decode 10 tok/s は対話的に使えるレベルで、クラウド API を使わずに手元で大規模モデルを試せるのは研究や検証に便利そうです。

2 台にしなくていいケース

105GB 以下のモデルなら 1 台で十分です。Qwen3-235B は 1 台で 15.5 tok/s 出ていますし、2 台にしても速くなりません。$3,999 を追加投資するなら、そのぶんクラウド API の利用料に回した方がコスパは良いでしょう。

上限の壁

llama.cpp RPC の現状では、モデルサイズの実用上限は約 170GB です。DeepSeek-V3（204GB）がロードできなかったように、「2 台合わせて 256GB」がそのまま使えるわけではありません。DeepSeek-V3 クラスのモデルを動かしたいなら、現状では M3 Ultra Mac Studio（最大 512GB）か、クラウドの A100/H100 を検討した方が現実的です。

まとめ

DGX Spark 2 台構成で 5 つのモデルを検証した結果、2 台目を買う判断基準は「128GB に収まらないモデルをどうしても手元で動かしたいか」に尽きるかなと思っています。Maverick（143GB）で decode 13 tok/s、Qwen3-Coder-480B（168GB）で decode 10 tok/s と、対話的にも使えるレベルで動いたのは素直にうれしい結果でした。一方、1 台で動くモデルを速くする用途には向きません。そうでなければ、1 台 + クラウド API のハイブリッド構成の方が柔軟性は高そうです。

今回は llama.cpp + RPC での検証でしたが、DGX Spark には NVIDIA 純正の TensorRT-LLM + NVFP4 量子化という別の選択肢もあります。NCCL ベースのテンソル並列で 2 台構成の結果がどう変わるのか、気になるところです。また、EXO Labs が DGX Spark + Apple Silicon の異種混合クラスタで 2.8 倍の改善を報告しており、DGX Spark の計算力と Mac の帯域幅を組み合わせた構成も試してみたいですね。

参考リンク

• DGX Spark Playbooks — Connect Two Sparks
• llama.cpp RPC ドキュメント
• Intuition Labs DGX Spark レビュー
• EXO Labs — NVIDIA DGX Spark + Apple Mac Studio = 4x Faster LLM Inference with EXO 1.0