Mac DecodeとCUDA Prefill：512GB級はThor×4かSpark×4か

Macで巨大モデルを動かすとき、Decodeは速いのにPrefillだけが詰まると感じることがある。

きっかけは、MacとDGX Sparkで役割を分けるという話題だった。DecodeをMac、PrefillをCUDAへ寄せる。いわゆるPrefill/Decode分離である。

そこで次の問いが立つ。

CUDA側で512GB級の容量を確保するとき、いま最もコスパが良い選択は何か。

候補は大きく二つある。

Jetson AGX Thor 128GB × 4
DGX Spark 128GB × 4

結論から書く。

結論

Mac Decode + CUDA PrefillでTTFTを短縮したいなら、現時点ではSpark×4の方が有利である。

Thor×4は、価格と公称FP4では魅力的だ。一方で、現在のGGUF/llama.cpp実測では単体PrefillがSparkより遅く、均質なThor×4で巨大モデルを分割実行した公開事例も見つかっていない。

用途	推奨	理由
Prefill性能と運用実績	Spark×4	実測Prefill、ConnectX、TCPでの4台分割事例
安価な512GB実験	Thor×4	容量単価は有利。ただし性能保証は弱い
仕様上の上限シナリオ	Thor×4	2.07 PFLOPS×4をそのまま信じた場合のみ

コスパは「安いこと」ではない。ここでは次で測る。

コスパ = (タスク性能 / 総コスト) の相対比

タスク性能は、今回の用途ではPrefill速度または逆TTFTである。Decode速度ではない。

なぜ分離するのか

巨大モデルでは、PrefillとDecodeのボトルネックが違う。

Prefillは長いプロンプトを一気に処理する段階で、演算量と帯域を食う。
Decodeはトークンを1個ずつ生成する段階で、メモリ帯域と遅延に敏感になる。

Mac StudioはDecode側が強い。
CUDA側は、大きなモデルや長いプロンプトのPrefillを受け持つ。

ただし分離は、同じモデルを両側に載せる前提を伴う。
KVや状態の受け渡しが成立しなければ、別runtimeのPrefillベンチをそのままMac Decodeへ接続できない。

今回の比較は、その前提を置いたうえでのCUDA側512GB候補の話である。

候補の骨格

両方とも、1台あたり約128GBのunified memoryを持つ。
4台なら集約容量は約512GBになる。

ここで最初に切っておく。

512GBは、一つの連続したCUDAアドレス空間ではない。

4台はノード間通信でモデルを分割して使う。
容量が増えることと、1リクエストが4倍速くなることは別である。

価格と公称スペックだけ見るとThorが強い

調査時点の調達シナリオでは、おおよそ次の帯だった。

Thor×4：約250万〜300万円
Spark×4：約348万〜388万円

公称の疎行列FP4性能は、

Thor：2.07 PFLOPS
Spark：1 PFLOP

である。

4台に単純に掛けると、Thorの仕様上の演算密度はSparkを大きく上回る。
価格も安い。
したがって「公称値 × 安さ」だけで見ると、Thor×4は2倍以上のコスパに見えてしまう。

この見方は誤りではない。
ただし、それは上限シナリオである。

実測PrefillではSparkが速い

同一条件のllama.cpp比較（build b6767、commit 5acd45546）では、GPT-OSS-120B MXFP4のpp2048が次だった。

Spark：1,689.47 tok/s
Thor：937.81 tok/s
ThorはSparkの0.555倍

隣接する測定も同じ方向を向いている。

Llama 3.3 70B Q4_K_M PP512：Spark 約283、Thor 約130
Ministral-3 Ollama prompt：Spark 約2,817、Thor 約1,090

単体比をそのまま4台へ外挿し、調査時点の価格帯を入れると、Prefillコスパは概ね次になる。

GGUF中心：Sparkが1.16〜2.23倍有利
言い換えると、ThorはSparkの0.45〜0.86倍

公称値から期待した「Thor圧勝」は、少なくとも現行GGUF経路では成立していない。

電力は低さだけでは決まらない

Thorの4台TDP合計は520W、Sparkは560Wである。
モジュール予算だけ見ればThorがわずかに低い。

しかし、ここで比較レイヤを崩してはいけない。

Thor 130W：モジュールTDP
Spark 240W：電源定格

この二つを並べて「Thorは半分の電力」と言うのは誤りである。

外付けACメーターの同一レビュー動画では、Ministral-3実行時に概ね次だった。

Thor：約90W、Prompt 約1,090 tok/s
Spark：約141W、Prompt 約2,817 tok/s

Prefillの性能/Wは、

Thor：約12.1 tok/s/W
Spark：約20.0 tok/s/W
Sparkが約1.65倍

消費電力自体はThorが低い。
それでもPrefill速度差の方が大きいため、Prefill効率ではSparkが上になる。

GenerationのW効率はThorが有利だった。
今回の構成ではGenerationをMacへ寄せる前提なので、購入判断ではPrefill側を優先する。

単体で公称が強いのに、なぜ実効で負けるのか

ここが一番誤解されやすい。

答えは「4台にした瞬間に壊れる」ではない。

単体の段階で、すでにGGUF PrefillがSparkより遅い。
その差の上に、4台化の通信コストが載る。

理由は三つある。

1. 2.07 PFLOPSは狭いピーク

この数字は、FP4、疎行列条件、対応する行列形状、対応するTensor Core命令、十分なbatch、データ供給が追いつく条件が揃ったときの行列ピークに近い。

LLM Prefillは行列積だけではない。

dequant
activation変換
attention
normalization
MoE routing
KV書込み
CPU dispatch
ノード間転送

が混ざる。
ピークFLOPSが高いことは、そのピークを実際に踏めることと同義ではない。

2. アーキテクチャとカーネル経路が違う

Thorはsm_110a、Sparkはsm_121aである。
コミュニティの分析では、Thorは狭い行列演算で強い一方、汎用vector処理ではSparkより弱いとされる。

さらにllama.cppのnative MXFP4対応は、Spark側のsm_120/121経路を強化した。
Thorのtcgen05 MMAを同等に使い切る経路ではない。

実際、MXFP4 native後のSparkはGPT-OSS-120B PP2048で約1,937から約2,438 tok/sへ、約26%上がっている。

3. 4台化は容量scale-outが本体

層やpipelineで分割すると、1リクエストは依存関係のある段階を直列に進む。
同時リクエストやmicrobatchが十分でなければ、総throughputも伸びにくい。

Tensor Parallelなら層内並列はできるが、同期通信が増える。
Thorは25GbE中心でRDMAがなく、実測でも1ポート約17Gbps程度が限界として語られている。
SparkはConnectX系の高速fabricを持つ。

したがってThorは、

単体Prefillで既に遅い
4台化しても主に容量が増える
通信条件も不利

となり、逆転しにくい。

最適化runtimeでは差が縮む

完全にソフトウェアの敗北だけでもない。
vLLM nightlyでQwen3.6-35B-A3B-NVFP4を同一コマンド比較した報告では、16並列のPrompt-heavyで次だった。

Spark：総合1,544.75 tok/s、平均TTFT 42.24秒
Thor：総合1,118.09 tok/s、平均TTFT 63.25秒

ThorはthroughputでSparkの0.724倍、逆TTFTで0.668倍。
価格を入れるとコスパはおおよそ0.77〜1.12倍で、ほぼ互角帯まで戻る。

ここから言えるのは次である。

GGUF/llama.cppではSpark優勢
最適化されたNVFP4経路ではThorの不利が縮む
それでも公称2倍の圧勝にはなっていない
しかもそのvLLM状態を、そのままMac/Metal Decodeへ持ち込めるとは限らない

Mac連携可能なruntimeで同じ速度が出せないなら、購入判断では使えない。

分散の公開証拠

証拠は「事例がある」で終わらせず、段階で見る。

複数台所有
リンク確立
iperf/collective
各ノード単独serving
1モデルを複数台へ分割
同一モデルのTTFT測定
Mac handoffまで通し

Spark×4

llama.cpp Issue #24813では、4台のDGX Sparkで約343GBのGLM-5.2 GGUFを分割し、TCPで実行した報告がある。
RDMAは未安定でも、TCPでのレベル5は達している。

Thor

2台以上の所有と25GbE調整：ある
Thor×2 + Spark×2でのPP=4：ある（成功responseやTTFTは未公開）
Thor×1を含む異種4ノード：ある
均質Thor×4で巨大モデルを分割完走した公開事例：未確認

「ありそう」という直感は自然だ。
ただし公開証拠としては、まだ実験候補のままである。

採否

Prefill性能と運用を優先するなら Spark×4

実測Prefillが強い
Prefillコスパが現状有利
4台TCPでの分割実績がある
fabricが強い

容量単価で実験するなら Thor×4

安い
公称演算は高い
消費電力も低く見えやすい

ただし買うなら、次をゲートにする。

4台が安定して見える
fabric実測
1モデルが4台へ載る
同一モデルのcold/cached Prefillが測れる
意図するMac handoffが通る
同じworkloadの壁コンセント電力を測る

これが揃う前に「高コスパ」と呼ぶのは早い。

この調査でやらなかったこと

Mac側Decodeの再ベンチ
370〜420GB級の巨大GGUFを両クラスタで実際に回すこと
日本の小売在庫を毎日更新すること
X全量の網羅検索

価格は調査時点のシナリオであり、常時の最安値ではない。

まとめ

MacとCUDAで役割を分ける話は正しい方向にある。

ただしCUDA側の512GBを「公称FP4が高い方」で選ぶと誤る。

現行の証拠では、

性能と運用実績：Spark×4
安価な容量実験：Thor×4
仕様上の上限シナリオ：Thor×4

である。

単体でスペックが高く見えるThorが、組み合わせで負けるように見えるのは、4台が壊れるからではない。
ピーク演算と、実際のPrefill経路と、容量scale-outを混同しているからである。