Mac DecodeとCUDA Prefill：Thor×4とSpark×4の勝者はまだ決まらない

Prefill/Decode分離には概念実証がある一方、Thor×4・Spark×4の巨大モデル連携は総合評価が未確定

長いプロンプトを読むPrefillはCUDAへ、1トークンずつ生成するDecodeは大容量メモリのMacへ任せる。このPrefill/Decode分離は、複数の実機による概念実証（PoC）で動作が報告されている。

発端になったXの投稿と実験記事では、M3 Ultra Mac StudioとRTX PRO 6000 Blackwell×4を10GbEで接続し、Qwen3.6-27Bの約12,500トークンで応答開始までを34.3秒から4.5秒へ短縮したと報告している。7.6倍という値は実験者による自己報告であり、この記事では独立追試していない。

では、370〜420GB級モデルのPrefillを受け持つ512GB級CUDA候補として、Jetson AGX Thor 128GB×4とDGX Spark 128GB×4のどちらを選ぶべきか。ここでいう370〜420GB級は、モデルの重みやGGUFファイルがその規模になるケースを指す。

結論

Prefill/Decode分離は複数の実機PoCで動作が報告されている。しかし、Thor×4とSpark×4のどちらが巨大モデルのMac連携で高コスパかは、まだ決着していない。

現時点の評価は、次のように分けるのが正確である。

掲載した単体Prefill測定：Sparkが高速
4台で1モデルを分割した公開証拠：Spark
輸入価格の下限試算が低い実験候補：Thor（着地費用は未確定）
370〜420GB級モデルのMacへの内部状態受け渡しを含むコスパ：未確定

訂正（2026年7月16日）：初版では、単体測定を4台構成へ外挿し「Spark×4の方が有利」と結論づけていた。しかし、対象とする370〜420GB級モデルを4台で直接比較した測定がないため、この購入結論を撤回し「勝者は未確定」に訂正した。併せて、異なるモデル・実行基盤・指標をまとめた「Spark 1.16〜2.23倍」と、処理量と逆TTFTをまとめた「Thor 0.77〜1.12倍」も撤回する。

PrefillとDecodeを分ける意味

Prefillはプロンプト全体を読み、最初の出力に必要な内部状態を作る段階である。Decodeは、その状態から1トークンずつ続きを生成する段階である。TTFTは、リクエストを送ってから最初のトークンが出るまでの時間を指す。

llama.cppのdisaggregated prefill/decode Issue #21266は、Mac Studioを高速Decode、DGX Sparkを高速Prefillへ使う構成を用途例として挙げている。専用Prefill workerを追加するPR #25675も存在するが、2026年7月16日時点では未統合であり、正式リリース機能ではない。

個人環境のPoCは複数ある。

AIサトシ氏の実験：M3 Ultra＋RTX PRO 6000 Blackwell×4、12.5K prompt、TTFT 34.3秒→4.5秒
denmrnngp-cloud氏がServeurpersoCom forkへ投稿したPoC：M2 Ultra＋DGX Spark、Qwen3.6-27B、約2,200 prompt token＋300 output tokenで20.7秒→15.6秒

後者はリクエスト全体で約1.33倍の改善であり、7.6倍とは対象Mac、GPU、プロンプト長、測定条件が違う。倍率を横並びにはできない。それでも、両報告は、CUDAで作った内部状態をMac側へ渡してDecodeを継続する経路が実機で動くと示した。

512GBは一枚の巨大GPUではない

ThorもSparkも、1台あたり128GBの統合メモリを持つ。4台の合計は512GBだが、一つの連続したCUDAメモリ空間になるわけではない。実行基盤がモデルを分割し、ノード間通信を成立させる必要がある。

420GBの重みを4台へ均等分割すると、平均105GB/台になる。単純な合計余裕は92GB、平均23GB/台にすぎない。ここからOS、過去トークンの内部状態を保持するKV cache、計算buffer、graph、分割偏りを消費する。したがって「512GBだから420GBが載る」は容量計算の入口であり、完走保証ではない。

Prefill/Decode分離では、原則として同じモデルファイルと互換性のある内部状態を両側へ用意する。速いvLLMベンチがあっても、その内部状態をMetalのllama.cppへ渡せなければ、Mac連携の購入根拠にはならない。

第三者の単体Prefill測定

llama.cpp Discussion #16578由来の結果を、JetsonHacksの比較記事がllama.cpp build b6767、commit 5acd45546の比較表としてアーカイブしている。本稿では第三者測定として引用する。

GPT-OSS-120B MXFP4のpp2048、2,048トークンのプロンプト処理測定では、Sparkが1,689.47 tok/s、Thorが937.81 tok/sだった。公開された中心値で比べると、Thorの単体Prefill性能はSparkの0.555倍である。

隣接する別条件も同じ方向を向く。

Llama 3.3 70B Q4_K_M、PP512、512トークンのプロンプト処理測定：Spark約283 tok/s、Thor約130 tok/s。Thorは0.459倍（14:21〜14:56）
Ministral-3 / Ollama prompt実機比較：Spark約2,817 tok/s、Thor約1,090 tok/s。Thorは0.387倍（7:29〜7:44）

モデル、量子化、実行基盤、プロンプト条件が違うため、0.387〜0.555倍を一つの性能幅にはしない。

Thor×4とSpark×4の単体測定を4台本体価格へ外挿した感度分析であり、重みまたはGGUFファイルが370〜420GB級の対象構成は未確定

本体価格あたり性能は一行ずつ計算する

比較するのは、初版と同じ仮定価格による「本体価格あたり性能」である。送料、保険、ネットワーク機器、電力、構築工数を含む総保有コストは扱わない。

Cの本体価格あたり性能 / Bの本体価格あたり性能 = (Cの性能 / Bの性能) × (Bの本体購入費 / Cの本体購入費)

訂正前後を比較するため、以下の全5行は初版の仮定価格、Thor×4が250万〜300万円、Spark×4が347.6万〜388万円を再利用する。4端点の全組合せによる感度分析であり、統計的な不確実性幅や現在価格のレンジではない。いずれも単体性能比が4台でも維持されると仮定し、4台分の本体購入費へ外挿した試算である。

GPT-OSS / llama.cpp pp2048：SparkはThorの1.16〜1.55倍
Llama 3.3 / llama.cpp PP512：SparkはThorの1.40〜1.88倍
Ministral-3 / Ollama prompt：SparkはThorの1.67〜2.23倍

全5行とも、ノード間ネットワークとクラスタ化の損失を無視した外挿である。

NVIDIA ForumのvLLM nightly報告にあるQwen3.6-35B-A3B-NVFP4、16並列Prompt-heavyでは差が縮む。元報告の合計処理量はSpark 1,544.75 tok/s、Thor 1,118.09 tok/s、平均TTFTはSpark 42.23575秒、Thor 63.24967秒だった。

合計処理量基準：ThorはSparkの本体価格あたり性能0.84〜1.12倍
平均TTFTの逆数基準：ThorはSparkの本体価格あたり性能0.77〜1.04倍

処理量と応答開始時間は別の指標なので、個別に評価する。なお、このvLLMの内部状態をMac/Metalへ渡せる証拠はない。

現在価格は調達確度を揃えられない

2026年7月16日に再確認した国内DGX Spark価格は、GDEPが1台863,500円、ELSA ONLINEが1台1,155,000円（税込）だった。4台の単純算術は345.4万〜462万円だが、4台同時在庫を確認した数字ではない。

ThorはNVIDIA公式発表の1台3,499ドルが基準になる。4台13,996ドルを、為替を1ドル162円と仮定して感度換算すると約226.7万円、消費税10%だけを加えると約249.4万円である。ただし国際送料、保険、VAT処理、関税区分、4台在庫を閉じた日本向け見積もりではない。

国内税込の販売価格と輸入前提の下限試算は同じ確度ではない。現在価格を入れれば順位は動くため、4台の確定見積もりが揃うまで総合評価は固定できない。

Thorの2.07 PFLOPSがそのまま勝ちにならない理由

Thorの公称2.07 PFLOPSとSparkの公称1 PFLOPは、対応するFP4・疎行列条件でのメーカー公称ピーク値である。DGX Spark公式仕様も1 PFLOPを“up to”としている。

LLM Prefillには、行列積だけでなくdequantization、attention、normalization、MoE routing、KV書込み、CPU dispatch、転送が混ざる。高いピーク値は、現在のGGUFカーネルがその命令を十分使えることを保証しない。

llama.cppのPR #17906はBlackwell向けnative MXFP4カーネルを追加し、2025年12月に取り込まれた。この追加と後続benchmarkの変化は、実効性能がカーネル経路へ依存することを示す。ただし、PR単独でDGX Sparkの改善量を証明するものではない。Thor側にも最適化余地はあるため、現在の差を永久的な物理限界と断定するのも早い。

4台化すると、ここへ通信と同期が加わる。layer/pipeline分割は主に容量を増やす。十分なmicrobatchや同時リクエストがなければ、1リクエストの各段階は依存関係に沿って進むため、4台で4倍速くなるわけではない。

4台構成の公開証拠

Spark×4には、llama.cpp Issue #24813という公開実例がある。4台のDGX Sparkへ約343GBのGLM-5.2 GGUFを分割し、TCPでは同じモデル分割が動くと報告されている。一方、RoCEv2 RDMAはモデル読込み途中で停止しており、Issueは未解決である。これは1モデル分割の証拠であって、TTFT測定やMacへの内部状態受け渡しの証拠ではない。

Thorについては、NVIDIA Forumの25GbE検証で複数ポートのリンクとiperfが確認され、調整後に1ポート約17Gbps、4ポート合計約68Gbpsまで上がったと報告されている。これはネットワーク単体の証拠であり、Thor×4で1モデルが完走した証拠ではない。

本記事で列挙した公開資料では、均質Thor×4で1モデルを分割し、実際のプロンプト、TTFT、Prefillを示した例を確認できなかった。公開例が存在しないとは断定せず、確認した資料内では未確認と扱う。

購入判断

現状でSparkを選ぶ理由は、掲載した単体Prefill測定が速く、4台で1モデルをTCP分割した公開証拠があることだ。ただし、370〜420GB級モデルをSpark×4でPrefillし、その内部状態をMacへ渡す一連の構成は未実証である。

Thorを選ぶ理由は、輸入前提の初期費用の下限試算が低く、公称演算の上限が高いことだ。ただし、均質Thor×4のモデル分割、同一モデルTTFT、Macへの内部状態受け渡しを自分でPoCする前提になる。

したがって、購入前の合格条件は次の6点である。

確定した4台見積もりと在庫
4台のノード間ネットワーク処理量と遅延
370〜420GB級モデルファイルの読込み完了
初回プロンプトとprefix cache利用時のTTFT
Macへの内部状態受け渡しとDecode継続
同一処理でコンセント側から測った消費電力量

この6点が揃うまでは、Spark×4を相対的に実証の多い候補、Thor×4を輸入価格の下限試算が低い実験候補と呼ぶ。対象構成の総合評価は未確定である。

2001Y@Y20010920T