DGX Spark は一台か二台か — スケールするタイミングとセットアップ方法

​

簡単な結論

​

When 1 Spark is enough

• Your model fits at a reasonable quantization. Dense models up to 70B at NVFP4 (~35 GB) or MoE models up to 120B at NVFP4 (~60 GB) load on a single node with room for KV cache.
• You serve 1-5 concurrent users. Single-Spark inference handles small team workloads at 35B MoE. For 70B dense, plan for 5-10 users maximum.
• モデルサイズよりもレイテンシーが重要であること。 単体Spark構成ならテンサー並列処理に伴うノード間通信のオーバーヘッドが発生しません。35B規模のMoEモデルでは単一ノードでの処理で47から50トークン/秒の速度が得られ、リアルタイムなコーディングエージェントやチャット用途に十分な速さです。
• シンプルな操作を求めているのです。 1 マシン、1 ランタイム、そして 1 障害発生箇所。ネットワーク設定も分散デプロイもNCCLのデバッグも一切不要です。

​

When you need 2 Sparks

• 量子化後のモデルサイズが128ギガバイトを超えるが、ランタイムやKVキャッシュ用の余裕を含めても256ギガバイト未満で収まる場合。 DeepSeek-V4-Flash-0731は公開されている162–167 GBという重み下限値を持つモデルの一例です。
• 分散処理向けに検証済みのモデルにおいて、KVキャッシュ容量や同時接続数を増やしたい場合。 テンサー並列処理によりメモリ負荷を分散できますが、スループットが比例して向上するとは限りません。
• ネットワーク接続されたランタイムのベンチマーク準備は整いました。 通信オーバーヘッドとモデル構造が結果を左右します。

​

200 Gbps対応のQSFPリンク設定

ip link show

ethtool <qsfp-interface> | grep Speed

sudo ip addr add 10.0.0.1/24 dev <qsfp-interface>

sudo ip addr add 10.0.0.2/24 dev <qsfp-interface>

ping 10.0.0.2   # from Spark A
ping 10.0.0.1   # from Spark B

export NCCL_SOCKET_IFNAME=<qsfp-interface>
export NCCL_IB_DISABLE=0
export NCCL_NET_GDR_LEVEL=2

​

Tensor parallelism across 2 Sparks

​

分散型モデルを起動する

vllm serve <your-distributed-model> \
  --tensor-parallel-size 2 \
  --quantization fp8 \
  --gpu-memory-utilization 0.85 \
  --max-model-len 8192 \
  --distributed-executor-backend ray

​

Model examples for 2 Sparks

​

パイプライン並列化の適用タイミング

• モデル構造がテンサー並列化に対応していない場合
• You are chaining more than 2 Sparks and want to reduce communication overhead per hop.

vllm serve <model> \
  --pipeline-parallel-size 2 \
  --tensor-parallel-size 1

​

複数のスパーク間で必要となるネットワーク要件

​

コスト対効果の分析

​

二番目のスパークが効果を発揮する時

• 測定済みの重み情報およびKVキャッシュ計画を持つ分散型モデルが必要です。 例えば、DeepSeek-V4-Flash-0731では 2ノードが必要で、コミュニティで検証済みの構成として利用可能です。
• You serve a team on a model whose distributed runtime increases your measured throughput or concurrency enough to justify the second unit.
• You run latency-sensitive workloads on 120B models. The extra KV cache headroom from two Sparks lets you use longer context or serve more users without hitting the memory wall.

​

そうでないケース

• Your model is ≤70B and your team is small. One Spark at 47-50 tok/s on a 35B MoE model is already faster than most people type. A second Spark adds cost and complexity for no user-visible improvement.
• You run MoE models that already fit. GLM-4.5-Air, Qwen3.5-122B, and Nemotron-3-Super-120B all fit on one Spark at NVFP4. Splitting them across two nodes introduces communication overhead that may not recover the parallelism gain.

​

Set up a 2-Spark cluster

pip install vllm

pip install ray

ray start --head --port=6379

ray start --address=10.0.0.1:6379

ray status

export NCCL_SOCKET_IFNAME=<qsfp-interface>
export NCCL_IB_DISABLE=0
export NCCL_NET_GDR_LEVEL=2

vllm serve <your-model> \
  --tensor-parallel-size 2 \
  --quantization fp8 \
  --gpu-memory-utilization 0.85 \
  --max-model-len 8192 \
  --distributed-executor-backend ray

curl http://127.0.0.1:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "<your-model>",
    "messages": [{"role": "user", "content": "Hello from two Sparks"}],
    "max_tokens": 64
  }'

​

Tokiosを通じて両方のSparkにサービスを提供する

# On Spark A (the vLLM head node)
curl -fsSL https://tokios.com/downloads/install/linux | sh -s -- --code TKS-XXXX-XXXX