正直、驚きました。DGX Spark を 2 台クラスター接続して DeepSeek-V4-Flash を動かしたところ、Mac Studio M3 Ultra に対してトータルの生成時間＝実所要時間で 1.78 倍速 （約半分の時間で処理できた）という結果が出てしまったのです。しかもDGX Sparkはモデルを量子化していない公式 FP8 のままで、です。
このベンチを取りながら、僕が以前から繰り返し主張してきたことが改めて数字で裏付けられたな、と感じています。それは
LLM の性能は、単なるメモリ帯域による decode スピード（トークン毎秒、TPS）だけでは語れない
ということです。GPU の処理能力、ノード間通信、メモリ階層、量子化品質、context 長、並列処理、などなど。これら全部の「バランス」こそが実用上の体感を決めます。そして DGX Spark はそのバランスよかったということ。
使ったベンチマーク：shi3z さんのコーディングベンチ
計測には shi3z さんの Japanese LLM Benchmark の coding ベンチを使いました。「React で動くチャットアプリを 1 回の生成で完成させろ」というタスクで、生成されたコードを実際に Docker で起動・Playwright でログイン/フレンド/DM/リアルタイム更新まで自動テストし、機能スコアを 80 点満点で採点します。
同じベンチを Mac Studio M3 Ultra で antirez 氏の ds4 推論エンジン経由で DeepSeek-V4-Flash Q4（4bit 量子化）を動かした結果が、shi3z さんのリポジトリに掲載されています。それと、今回の DGX Spark 2 台クラスター + 公式 FP8 の結果を並べたのが下の表です。
ベンチマーク結果
なぜ「tok/s で負けて実所要時間で勝つ」のか
表をぱっと見て「あれ、tok/s では Mac の方が速いじゃないか」と思った方は正しいです。1 トークンを吐き出す瞬間速度（decode TPS）だけ見れば、Mac Studio M3 Ultra の方が 1.58 倍速い。これは Apple Silicon の巨大なメモリ帯域が効いているからです。
しかし、ここに落とし穴があります。同じ「満点 80/80」のチャットアプリを完成させるのに、Mac は 8,036 トークンを使って書き、DGX Sparkは 2,866 トークンで書いたのです。約 2.8 倍の差です。
両方とも公式品質劣化なしの DeepSeek-V4-Flash ですが、Q4 に量子化した Mac 側の出力は冗長になり、フル品質の FP8 で動いた Spark 側は簡潔にまとめた、という解釈が自然です。量子化が出力分布に与える影響は decode 速度には現れないが、生成戦略に静かに効いている、というよくある現象です。
その結果、計算式はこうなります：
実用の壁時計 = (出力トークン数) ÷ (tok/s)
Mac: 8,036 ÷ 26.2 = 307 秒 我々: 2,866 ÷ 16.6 = 172 秒
tok/s で負けても壁時計で勝つ、というのは「同じ正解までを短い手数で書ききった」結果です。実用において人間が体感するのは「タスクが終わるまでの時間」であって、瞬間 tok/s ではありません。
使った構成
- ハードウェア：DGX Spark × 2（NVIDIA GB10、Blackwell 系、それぞれ 128 GB unified memory）
- ノード間接続：ConnectX-7 200 Gbps の RoCE で直結（Tensor Parallel = 2、PyTorch distributed バックエンド）
- 推論エンジン：vLLM 0.21.1dev に b12x という GB10 専用 CuTe DSL カーネル群を統合した Aiden 氏のレシピ をそのまま採用
- モデル：DeepSeek-V4-Flash 公式 FP8（154 GB、attention は FP8、MoE は MXFP4——これは DeepSeek 自身が出している正規フォーマット）
- コンテキスト：524,288 トークン（512K）、util 0.82、KV cache 19.85 GiB、concurrency 3.89×
- Multi-Token Prediction (MTP)：受容率約 62 % の speculative decoding（出力品質はそのままで速度だけ稼ぐ仕組み）
性能をもう少し細かく
本ベンチの数字以外にも、純粋な decode 速度や prefill 速度を別途計測しました：
- 純 decode 速度（短文、TTFT 除外）：約 39 tok/s で安定
- prefill 速度（大コンテキスト）：1,277 tok/s（これは b12x カーネルを使わない旧構成の 196 tok/s に対して約 6.5 倍）
- 長コンテキストでの decode：8K → 64K → 128K → 256K → 512K → 768K と上げても decode は激減せず、むしろ加速（768K で 106 tok/s）。これは DeepSeek のスパース attention（DSA）が b12x カーネルでネイティブ実装されているおかげで、attention 計算が context 長にほぼ依存しないため
これは「量子化なしフル品質」での結果
もうひとつ強調しておきたいのは、今回の DGX Spark 側はモデルを一切追加量子化していないということです。HuggingFace で配布されている公式の 154 GB をそのままロードし、DeepSeek 自身が設計した FP8 attention + MXFP4 MoE という正規の量子化フォーマットで動かしています。
ローカル LLM の世界では「巨大モデルを動かすために IQ2（2bit）や Q4 まで圧縮する」のがほぼ常識化していますが、これらは品質を確実に削ります。実際、過去に DeepSeek-V4-Flash の IQ2XXS 版（2bit）を試して、同じベンチで 55/80 + agent 動作崩壊という結果を見ています。量子化は無料ランチではありません。
DGX Spark 2 台で 256 GB の unified memory を確保できる構成は、「巨大モデルをフル品質で動かす」という選択肢を初めて現実的にしてくれます。これは数字以上に意味のある進歩だと思います。
Spark の「バランスの良さ」が効いた理由
今回の結果を支えた要素を技術的に分解すると、こうなります：
- b12x カーネル群：GB10 / SM12.x 専用に CuTe DSL で書き下ろされた NVFP4 fused MoE GEMM、NVFP4 dense GEMM、FP8 paged attention、sparse MLA attention の 4 種類。汎用 vLLM の MARLIN 経路と違って、量子化を解凍せずそのまま fused で計算します
- 200 Gbps RoCE 直結：TP=2 のノード間 allreduce が層ごとに 2 回入りますが、200 Gbps の直結で実効レイテンシが薄く、ここが decode の律速になりません
- 128 GB unified memory × 2：HBM と DDR を分けない Grace Blackwell の利点で、154 GB の公式 FP8 モデルを 2 台に分割してそのまま乗せ、さらに 512K context の KV cache を 19.85 GiB 確保できる余裕
- DeepSeek Sparse Attention（DSA）のネイティブ実装：long context でも attention 計算量が context 長に依存しない設計を、b12x が GB10 ネイティブの sparse 演算で正しく扱う。これが「コンテキスト長で decode 激減しない」結果を生みました
つまり、メモリ帯域、計算能力、ノード間通信、長 context 最適化、量子化品質、これらの「どれか一つ」だけが突出していても今回の結果は出ません。Spark はこの全要素が、同価格帯のどの単機構成より高い水準で揃っている。これが「バランスの良さ」の正体です。
実用面で何が変わるか
抽象論で終わらせると面白くないので、具体的な利点をもう一段：
- 巨大ドキュメントの要約・コード解析が現実的に：512K context で、しかも prefill が 1,277 tok/s 出るので、本一冊（〜30 万トークン）を 4 分前後で読み込ませて要約できます
- agent ループが詰まらない：concurrency 3.89× なので、Hermes Agentなどでチャットと長文要約を同時に走らせても decode が崩壊しません。
- 量子化破綻による「agent が口だけ」問題が起きない：これは IQ2 系で何度も踏んだ罠で、フル品質ならそもそも起きません
- Mac との比較で消費電力的にも勝負になる：GB10 × 2 で稼働中の総消費電力は推論時 100W〜140W 程度で、Mac Studio M3 Ultra のフルブースト時に近い水準。性能 1.78 倍を考えると電力効率も悪くない
まとめ：TPS だけで LLM 性能を語る時代は終わった
1 トークンを吐き出す瞬間速度——decode TPS——は確かに大事な指標です。しかしそれは、「100m 走の最高速度」のようなものです。実用において必要なのは、「同じ正解にたどり着くまでの時間」「正解の品質」「同時に何個走らせられるか」「どれだけ長いコンテキストを扱えるか」「agent ループが回るか」、こうした総合点です。
今回の結果が示したのは、まさにこの総合点で DGX Spark が現時点で頭ひとつ抜けつつある、ということです。量子化していない公式品質の巨大モデルを、長コンテキストで、agent 互換性を保ったまま、Mac Studio の壁時計 1.78 倍速で動かす、これが 2 台クラスター接続するだけで実現できる時代になりました。
「LLM はメモリ帯域だ」「decode TPS が全てだ」と言われてきた数年でしたが、Spark を実際に動かしてみて、「バランスの良さこそが実用性能」というこちらの主張がようやく数字で裏付けられた、と感じています。
RTX Sparkも発表され、思った以上に盛り上がってる（値段がでたら一気に冷めそうですが、、、）雰囲気もあるので、この勢いでコミュニティーが増えるとより最適化や農泊が蓄積されるので期待しかないです！！
しかし革ジャンすごいなぁ。。。まだまだ天下は続くのでしょうか。
**
**
**
**
**
おまけ
鋭い人ならきっとこういうツッコミがあるかと
「じゃあ Mac Studio でも素の公式 FP8 を動かせば同条件じゃない？」
「比較条件が不公平では？ Mac Studio は Q4 で量子化しているから冗長になっただけで、Mac Studio でも素の公式 FP8 をそのまま動かせば、品質面では同じ土俵に立てるのでは？」と。もっともな疑問です。
結論から言うと、現時点で Mac Studio で『素の公式 FP8 + MXFP4 MoE』をそのまま実用速度で動かす手段は存在しません。
- そもそも対応する推論エンジンが無い
DeepSeek-V4-Flash の公式フォーマット（FP8 attention + MXFP4 MoE + Lightning Indexer + DSA Sparse Attention）を Apple Silicon でフルにサポートしているエンジンは、今のところなさそうです（Claude Code調べ）。
- MLX（Apple 公式の Apple Silicon LLM フレームワーク）：MXFP4 の MoE fused GEMM ネイティブ実装なし、FP8 paged attention なし、DeepSeek の DSA Sparse Attention の MLX 実装なし。仮に動かそうとすると bf16 にアップキャストする必要がある
- llama.cpp：MXFP4 をそのままロードできないので GGUF への再量子化が必要 = 結局 Q4 / Q5 / IQ2 などに変換することになり、「素の公式」ではなくなります
- vLLM：そもそも Apple Silicon サポートが限定的で、b12x のような GB10 専用カーネルは Mac では動きません
- antirez/ds4：そもそも DeepSeek V4 Flash 専用に MLX ベースで Q4 前提に書き起こされた特化エンジンで、これが Mac Studio で動かす現状の最適解。「素の FP8」を扱う作りにはなっていません
antirez 氏が DeepSeek V4 Flash 専用エンジンを Q4 で書き起こしたこと自体が、「Apple Silicon で公式品質をそのまま動かす実用パスが今のところ無い」という現実を物語っているとも言えます。
- 仮に bf16 アップキャストで動かしたとしても、帯域がほぼ食い尽くされる
百歩譲って、誰かが MLX で公式重みを bf16 にアップキャストしてロードする実装を作ったとします。すると何が起きるか、ざっくりした帯域計算で見積もれます。
- DeepSeek-V4-Flash は MoE 構成で、active params は約 30B
- Q4（4bit）で持つと active params で約 15 GB、ds4 はこれで 26.2 tok/s（実測）
- 同じモデルを FP8（8bit）で持つと active params で約 30 GB ＝ 帯域要求が 2 倍 ＝ 同じエンジンなら理論上 ~13 tok/s
- さらに MLX で bf16 にアップキャストすると active params で約 60 GB ＝ 帯域要求が 4 倍 ＝ 理論上 ~6.5 tok/s
- Mac Studio M3 Ultra の実効メモリ帯域は約 800 GB/s なので、bf16 で 60 GB を毎トークン読むと帯域だけで限界に張り付き
つまり「素の品質を取る」という選択は、Apple Silicon では「速度を倍以上犠牲にする」と引き換えになるのが現状です。ds4 + Q4 で 26.2 tok/s 出している方が、フル品質 bf16 で 6 tok/s しか出ないより、実用的には正解だったのです。
- ここで Spark の構造的優位が効いてくる
一方、今回の DGX Spark 構成では「素の公式 FP8 + MXFP4 MoE をネイティブで」動かしています。これを支えているのが：
- b12x という GB10 専用カーネル群が、NVFP4 fused MoE GEMM と FP8 paged attention を「dequant を挟まずに」そのまま走らせる実装を持っている
- これは Apple Silicon 用には今のところ書かれていない
- 結果として、Spark は「公式品質をそのまま」かつ「実用速度で」動かせる唯一の現実解になっている
整理すると、ハードの帯域だけ見れば Mac Studio の方が単機の絶対値は近い水準ですが、「公式量子化フォーマットをネイティブに走らせるカーネル実装」の有無が決定的な差を生んでいる、ということです。Spark の優位はチップだけでなく、b12x のような GB10 特化ソフトウェアスタックとの組み合わせ全体から来ています。
もし将来、誰かが MLX で MXFP4 fused MoE GEMM と FP8 paged attention と DSA Sparse Attention を Apple Silicon 向けに書き下ろせば、この前提は崩れます。コミュニティの実装次第で景色は変わります。今のところは、Spark の方が一歩先に「公式品質 × 実用速度」の組み合わせを実現している、というのが事実です。
以上がClaude Codeで考察してもらった結果です。
