DGX Spark 2〜4台実例｜DeepSeek V4・GLM-5.2
DGX Sparkを2〜4台接続し、DeepSeek-V4-Flash、GLM-5.2、MiniMax M3を動かした公開実例を調査。量子化、文脈長、tokens/s、構成、再現上の注意点を比較します。
先に結論：公開実例はあるが、構成ごとに成熟度が違う
- DeepSeek-V4-Flash: 2台で公式チェックポイントを200K文脈・約44 tok/s、DSpark版を1M文脈・コード生成60〜67 tok/sで動かした報告がある
- DeepSeek-V4-Flashを4台: 384K文脈・単一ストリーム49〜54 tok/s、8並列で約180 tok/sの公開レシピがある
- GLM-5.2を2台: 1bit級GGUFなら256K文脈・約8 tok/sで起動したが、長い入力の処理は遅く、実験用途という評価
- GLM-5.2を4台: 量子化方式により、128K文脈・約24 tok/sから800K文脈・約20 tok/sまで複数の実例がある
- 3台構成: MiniMax M3のTP=3実例はあるが、DeepSeek V4やGLM-5.2で「3台だから最適」といえる公開実例は確認できない
2026年7月20日時点では、2台ならDeepSeek-V4-Flash、4台ならGLM-5.2が再現情報の多い大型ローカルLLMです。ただし、いずれもコミュニティによる実機報告で、NVIDIAが性能や長期安定性を保証した構成ではありません。
情報監査日: 2026年7月20日
調査対象: NVIDIA公式ドキュメント、モデル開発元のモデルカード、NVIDIA Developer Forums上の実機所有者による手順・ログ、リンクされた公開リポジトリ
実測値の扱い: 当サイトで同じハードウェアを再測定した値ではなく、各投稿者の自己申告です。モデル、コミット、コンテナ、文脈長、並列数が違う数値を単純比較しないでください。
複数DGX Sparkで動いた大型モデルの実例一覧
| モデル | 台数 | 形式・エンジン | 公開された結果 | 評価 |
|---|---|---|---|---|
| DeepSeek-V4-Flash | 2台 | 公式Mixed精度 vLLM TP=2 | 200K、約44 tok/s 短い入力のTTFT約2秒 | 再現候補 |
| DeepSeek-V4-Flash-DSpark | 2台 | FP4＋FP8＋投機的デコード vLLM TP=2 | 1M、コード60〜67 tok/s 混在タスク約40 tok/s | 高速・実験的 |
| DeepSeek-V4-Flash | 4台 | 公式チェックポイント vLLM TP=4＋EP＋MTP | 384K、49〜54 tok/s 8並列で約180 tok/s | 高スループット |
| GLM-5.2 | 2台 | UD-IQ1_S GGUF llama.cpp RPC | 256K、7.7 tok/s 入力処理213 tok/s（depth 0） | 学術的実験 |
| GLM-5.2 | 4台 | 15% expert-pruned AWQ INT4 vLLM TP=4 | 256K、20〜22 tok/s 入力処理476〜535 tok/s | 品質検証が必要 |
| GLM-5.2 | 4台 | NVFP4、expert非削減 vLLM TP=4＋DCP=4＋MTP | 128K、23.7〜24.2 tok/s 入力処理約475 tok/s | 品質重視候補 |
| GLM-5.2 | 4台 | NF3ハイブリッド、expert非削減 vLLM TP=4＋DCP=4 | 最大800K、単一約19.9 tok/s 4並列44.1 tok/s | 長文脈候補 |
| GLM-5.2 | 4台 | IQ4_XS GGUF llama.cpp RPC | 1M、6.28 tok/s 1M needle retrieval成功 | 簡素だが低速 |
| MiniMax M3 | 3台 | NVFP4 vLLM TP=3 | tool calling・reasoning動作 1GbE経由で約6 tok/s | TP=3の実証 |
tok/sは原則として出力トークン生成速度です。並列時は全リクエストを合計したaggregate値を明記しました。長文を最初に読み込むprefill速度、最初の応答までのTTFT、生成速度は別の指標です。たとえば200K文脈で44 tok/s出ても、128Kトークンを新規に投入する処理には数分かかる例があります。
なぜ今の大型モデルは複数台で動くのか
DeepSeek-V4-Flash公式モデルカードでは、総284B、1トークン当たり13Bを活性化するMoE、最大1Mコンテキストとされています。配布チェックポイントはMoE expertをFP4、その他の多くをFP8にしたMixed精度で、2台のDGX Sparkへ分割できるサイズです。
GLM-5.2公式モデルはHugging Face API上で753Bです。公式FP8は4台の合計512GBを超えるため、4台の実例ではAWQ INT4、NVFP4、NF3ハイブリッド、GGUF IQ4などの量子化を使っています。NVIDIAのGLM-5.2-NVFP4も公開されていますが、公式モデルカードの検証機はB200 / B300であり、DGX Sparkでの動作保証を意味しません。
MoEは総パラメータをすべてメモリへ置く必要がある一方、各トークンで使うexpertは一部です。重みを低ビット化し、Tensor Parallel（TP）で各ノードへ分け、Expert Parallel（EP）やDecode Context Parallel（DCP）、MTP / DSparkの投機的デコードを組み合わせることで、128GB×複数台の構成でも実用に近い速度が出始めています。
実例1：DeepSeek-V4-Flashを2台で動かす
公式チェックポイント、200K文脈で約44 tok/s
2026年5月16日の2台実機レポートは、DGX Spark 2台をConnectX-7の200Gケーブルで直結し、vLLMのTP=2、FP8 KV cache、MTP 2トークン、最大200K文脈で起動しています。温まった単一ストリームは約44 tok/s、2並列の合計は約45 tok/s、短い入力のTTFTは約2秒、コンテナ起動から配信開始までは約6分でした。
一方、同じ報告では32K入力のTTFTが約53秒、128K入力は約250秒です。生成自体は人が読むより速くても、大きなコードベースを初回投入する時間は無視できません。後続の別ユーザーによる256K設定では、浅い条件で生成35〜39 tok/s、入力処理770〜890 tok/s前後、短いtool-call評価15件はすべて通過したと報告されています。
DSpark版は1M文脈と60〜67 tok/sを報告
DeepSeek-V4-Flash-DSparkは別の基盤モデルではなく、同じチェックポイントへ投機的デコード用モジュールを追加したものです。2台のDSpark実機レポートでは、NVFP4 KV cacheにより約2MトークンのKV poolを確保し、最大1M文脈、コード生成60〜67 tok/s、内容が多様な生成で約40 tok/sとしています。1M設定・最大6系列では合計約182 tok/s、200K・16系列では約315 tok/sという報告もあります。
ただし、同じスレッドにはCUDA illegal memory access、文字化け、長い文脈での速度低下も報告されています。最大文脈長は1リクエストの上限、最大系列数は同時処理の上限で、6本すべてが同時に1Mを占有できる意味ではありません。速度は魅力的ですが、固定バージョンでの長時間テストを通してから常設運用する構成です。
1M対応の別レシピではUCXのメモリ増加に注意
別の再現レシピは、1M設定で単一約37 tok/s・合計約100 tok/s、256K設定で単一約40 tok/s・合計約150 tok/sを報告しています。投稿者はUCXのRDMAメモリ登録キャッシュがリクエストごとに増え、統合メモリを使い切る問題をA/Bテストし、次の設定で増加が止まったとしています。
UCX_MEM_MMAP_HOOK_MODE=none
UCX_RCACHE_MAX_UNRELEASED=1024この修正後に256K、512K、1Mの起動と配信は確認されていますが、投稿時点で12時間を超える飽和テストは未完了です。1Mで起動したことと、本番負荷で安定することを分けて評価する必要があります。
実例2：DeepSeek-V4-Flashを4台で動かす
4台の公開レシピは、各128GBのDGX SparkをMikroTik 200GbEスイッチへ接続し、公式DeepSeek-V4-Flash、vLLMのTP=4、EP、MTP 2トークン、FP8 KV cache、最大384K文脈で実行しています。
| 測定 | 結果 | 意味 |
|---|---|---|
| 単一ストリーム | 49.4〜54.4 tok/s | 温まった複数のコード・推論プロンプト |
| 4並列 | 合計70.8 tok/s | 合計1,142トークン生成 |
| 8並列 | 合計179.9 tok/s | ピーク生成207 tok/s |
| コールド状態 | 33.5 tok/s | 推論中にJITコンパイルを含む |
4台に増やしても単一ストリームが2台の2倍になるわけではありません。TPの同期通信が増えるためです。効果が大きいのは、384K文脈の余裕と複数エージェントを同時に流した場合の総処理量です。
この構成では、SM121対応のvLLM forkとパッチに加え、NCCL 2.30.4の固定が重要でした。古い2.28.9では長い生成中に停止したと報告されています。単に最新イメージを取るのではなく、動作報告のコミット、NCCL、CUDA、モデルrevisionを一式で固定する必要があります。
実例3：GLM-5.2を2台で動かす
2台でのGLM-5.2実験は、201.82GiBのUD-IQ1_S GGUFをllama.cpp RPCで52:48に分割し、256K文脈、Q8_0 KV cacheで動かしています。depth 0・単一リクエストでは入力処理213 tok/s、生成7.7 tok/sでした。
コンテキストが32Kまで伸びた測定では、入力処理76 tok/s、生成4.1 tok/sまで下がっています。投稿者自身も「デプロイには現実的でないtoy experiment」と評価しています。後にvLLM TP=2へ移植して約12 tok/sまで改善したものの、コンテキストは約40Kに縮小しました。
2台でGLM-5.2は起動できますが、量子化の強さ、入力処理、文脈長のいずれかを大きく妥協します。GLM-5.2を日常のコーディングエージェントとして選ぶなら、現状は4台実例の方が参考になります。
実例4：GLM-5.2を4台で動かす
256K・20〜22 tok/s：15% expert-pruned AWQ INT4
最初期の4台vLLM実例は、AWQ INT4からrouted expertを15%削減し、約12GiB / nodeの余白を作っています。100Gスイッチ経由、TP=4、MTP、CUDA Graphを使い、depth 0〜32Kで生成20.2〜21.9 tok/s、入力処理476〜535 tok/sでした。
速度は実用圏に近い一方、データを使わないexpert削減であり、投稿者も実際のSWE性能は未評価としています。「動作した」と「元モデルの品質を維持した」は別です。
128K・約24 tok/s：expert非削減のNVFP4
4台・NVFP4の追試は、expertを削減しない約410GBのチェックポイントを使い、DCP=4で128K文脈を確保しています。MTPのDCP設定がdraft側へ伝わらない不具合を修正した結果、MTP4で23.7〜24.2 tok/s、入力処理約475 tok/s、3並列の生成は約48 tok/sになりました。
元のexpertを残せるため品質面では有力ですが、修正版vLLMと複数のパッチが前提です。MTP3を保守的な既定、MTP4を最高速設定とするなど、構成はまだ動いています。
800K・約20 tok/s：expert非削減のNF3ハイブリッド
327GBのNF3ハイブリッド量子化を使った4台実例は、全256 expertを残し、KV pool 877,056トークン、最大800Kで起動しています。DCP=4の単一生成は19.9 tok/s、2並列32.5 tok/s、4並列44.1 tok/sです。DCP=1の200K速度優先設定では単一24〜29 tok/s、6並列67.4 tok/sでした。
clean boot、整合した出力、tool callingは確認されていますが、700Kまで実際に埋めたdepth sweepは未実施です。また、起動に必要なpatched warmupファイルが公開リポジトリへ含まれていないという注意もあり、完全な第三者再現には追加確認が必要です。
1M・6.28 tok/s：IQ4_XS GGUF＋llama.cpp RPC
llama.cpp RPCの4台実例は、約365GBのIQ4_XS GGUFをTCP/IPで4台へ分割し、1M文脈、DSA有効で動かしています。単一生成6.28 tok/s、4並列の合計9.07 tok/s、読み込みは約24分でした。1M-context needle retrieval、コード生成、計算のsmoke testも通過しています。
vLLM版より構成は理解しやすいものの、MTPがGLM DSA経路へ接続されておらず、RPCの直列化が上限です。1ユーザーの研究モデルとしては成立しても、複数エージェントを高速配信するサーバーには向きません。
3台構成はMiniMax M3で実例がある
NVIDIAは3台を200GbEのリングで接続する構成を公式に案内しています。しかし、モデルのattention head数などが3で割り切れず、TP=3をそのまま使えない場合があります。
MiniMax M3の3台実例では、約243GBのNVFP4を、仮想shardingでattention headをTP=3へ合わせて起動しました。tool callingとreasoningは動作しましたが、公開時点ではNCCLが1GbE管理ポートを通り、約120回 / tokenのall-reduceが発生して単一生成は約6 tok/sでした。200GbEのRoCEリング対応は作業中でした。
この例が示すのは、3台リングの物理接続が可能でも、モデル側のTP=3対応とRoCE経路がそろわなければ速くならないことです。DeepSeek-V4-Flashは2台または4台、GLM-5.2は4台の方が公開済みレシピを選びやすい状況です。
再現するときの構成を整理
| 項目 | 2台 | 3台 | 4台 |
|---|---|---|---|
| 物理接続 | CX-7を200GbEで直結 | 200GbEケーブル3本のリング | 200GbEスイッチへ各1本 |
| 有力モデル | DeepSeek-V4-Flash | MiniMax M3の実験 | GLM-5.2 / DeepSeek-V4-Flash |
| 高速配信 | vLLM TP=2 | vLLM TP=3対応が必要 | vLLM TP=4＋EP / DCP |
| GGUF | llama.cpp RPC | RPCは可能だが要検証 | RPCは簡素だが低速 |
| 主な注意 | UMAとUCX、長文prefill | TPの割り切れ、RoCE経路 | スイッチ、NCCL、forkとpatch |
NVIDIAのSpark Stackingガイドは、CX-7 / QSFPを使うクラスタ、MPI、NCCLを案内しています。2台・3台・4台の配線、ケーブル、スイッチ候補、確認コマンドはDGX Spark 1〜4台の接続方法にまとめています。
失敗しにくい検証手順
- 全台をそろえる: DGX OS、firmware、driver、CUDA、ユーザー名を一致させる
- 200GbEを先に検証: link speed、相互ping、SSH、NCCL all-reduceをモデル起動前に確認する
- モデルを各台のローカルSSDへ置く: NFS由来の読み込み差を避け、revisionとhashを記録する
- 動作報告の版を固定: vLLM fork、commit、NCCL、CUDA、patch、Docker imageをセットで固定する
- 小さく起動: 32K以下、単一系列、低めのmemory utilizationから開始する
- 段階的に負荷を上げる: 256K、512K、1Mの順に、prefill、生成、並列、tool callingを測る
- 長時間運転: 空きUMA、UCX、Ray、NCCL error、出力破損、host freezeを監視する
「APIが起動した」だけでは合格にしません。最低でも次の4段階を別々に記録します。
- Load: 全rankが重みを読み込み、KV poolを確保できた
- Correctness: reasoning、tool calling、長文検索で整合した出力が出た
- Performance: depth別のprefill、TTFT、単一・並列の生成速度を測った
- Stability: 実利用に近い連続負荷でメモリ増加と停止がない
どの台数を選ぶべきか
2台：DeepSeek-V4-Flashを日常利用したい
現在もっとも情報が多い組み合わせです。公式Mixed精度で安定性を優先する構成、DSparkで速度と1M文脈を狙う構成を選べます。まず200K〜256Kで長時間テストし、必要な場合だけ512K〜1Mへ広げるのが現実的です。
3台：特定モデルのTP=3対応を確認できる場合だけ
合計384GBは魅力的ですが、容量が収まることとTP=3対応は別です。MiniMax M3のような専用shardingが必要になることがあります。DeepSeek V4やGLM-5.2を目的に3台を新規購入するより、2台または4台の公開レシピを基準にした方が再現しやすいです。
4台：GLM-5.2を品質と文脈長で選びたい
expertを残したNVFP4やNF3ハイブリッドが候補になり、128Kで約24 tok/s、800K上限で約20 tok/sの実例があります。DeepSeek-V4-Flashでも複数エージェントの総処理量を増やせます。ただし、200GbEスイッチ、ケーブル4本、forkとpatchの保守まで含めた小規模クラスタ運用です。
よくある質問
DeepSeek-V4-Flashは2台と4台でどちらが速いですか？
単一ストリームだけなら、公開値は2台の公式版で約44 tok/s、DSparkのコード生成で60〜67 tok/s、4台の公式版で49〜54 tok/sです。条件が違うため単純な台数比較はできません。4台の利点は長い文脈の余裕と並列スループットです。
GLM-5.2は2台でも実用になりますか？
UD-IQ1_Sを2台で動かした例はありますが、生成約8 tok/s、長文入力はさらに待ち時間が増え、投稿者も実験用途と評価しています。日常利用は4台の量子化vLLM構成が有力です。
1M contextと書かれていれば1Mを快適に使えますか？
いいえ。最大長で起動できても、実際に数十万トークンを投入したときのprefill、TTFT、生成速度、KV使用量は別です。最大設定だけでなく、depth 32K、128K、256K以上の測定を確認してください。
公式のNVIDIA量子化ならDGX Sparkで保証されますか？
保証されません。たとえばNVIDIAのGLM-5.2-NVFP4モデルカードはB200 / B300をテスト機としており、GB10ではありません。DGX Spark用の実機レシピ、SM121対応、Arm64コンテナを別に確認します。
llama.cpp RPCとvLLMのどちらを使いますか？
GGUFを柔軟に分割して起動確認するならllama.cpp RPC、高いprefillと並列スループットを狙うならvLLMが有力です。llama.cpp RPCは開発元がproof-of-conceptと位置づけているため、隔離したCX-7ネットワークだけで使い、外部公開しないでください。
まとめ
DGX Sparkを複数台つないだ最新大型モデルは、すでに「容量上は動く」という段階を超えています。DeepSeek-V4-Flashは2台で200K〜1M、約40〜67 tok/s、4台で384K・49〜54 tok/sの実例があります。GLM-5.2は4台で、品質を優先したexpert非削減NVFP4の約24 tok/s、800Kを狙うNF3ハイブリッドの約20 tok/sが公開されています。
一方で、stock vLLMだけで再現できる構成はまだ少なく、SM121対応fork、NCCL固定、DCP / MTP修正、UCXのUMA対策が必要です。購入判断では最大パラメータ数より、同じ台数・同じモデル・同じ量子化で公開されたレシピと長時間ログがあるかを優先してください。
参照資料
- NVIDIA：Spark Stacking（2026年7月14日更新、7月20日確認）
- DeepSeek：DeepSeek-V4-Flash公式モデルカード（2026年4月22日公開リポジトリ、7月20日確認）
- DeepSeek：DeepSeek-V4-Flash-DSpark（2026年6月、7月20日確認）
- Z.ai：GLM-5.2公式モデルカード（2026年6月16日公開、7月20日確認）
- NVIDIA：GLM-5.2-NVFP4（2026年6月、7月20日確認）
- NVIDIA Forums：DeepSeek-V4-Flashを2台、200Kで動かした実例（2026年5月16日）
- NVIDIA Forums：DeepSeek-V4-Flash 2台、最大1Mの再現レシピ（2026年6月27日、6月30日追記）
- NVIDIA Forums：DeepSeek-V4-Flash-DSpark 2台の実例（2026年6月29日）
- NVIDIA Forums：DeepSeek-V4-Flash 4台の実例（2026年6月18日）
- NVIDIA Forums：GLM-5.2を2台で動かした1bit級GGUF実験（2026年6月25日）
- NVIDIA Forums：GLM-5.2を4台、256Kで動かした実例（2026年6月22日）
- NVIDIA Forums：GLM-5.2 NVFP4を4台、128Kで動かした追試（2026年7月3日）
- NVIDIA Forums：GLM-5.2 NF3ハイブリッドを4台、最大800Kで動かした実例（2026年7月7日）
- NVIDIA Forums：GLM-5.2 IQ4_XSを4台、1Mで動かした実例（2026年6月20日）
- NVIDIA Forums：MiniMax M3を3台、TP=3で動かした実例（2026年6月15日）
- llama.cpp：RPC backend README（2026年7月20日確認）
