なぜこの比較が注目されたのか

r/LocalLLaMAの長文ベンチマーク投稿は、超大規模open modelをlocalで動かす際に実際に何が起きるのかを非常に具体的に示した。クロール時点でこのスレッドは402ポイント、229コメントを集めていた。投稿者はSlack上の個人assistantのためにClaude APIへ月$2Kほど使っていたが、長期的にはlocal inferenceの方が有利だと考え、$10KのMac Studio M3 Ultra 512GBと、ほぼ同額のDual DGX Spark構成を両方購入したという。

比較対象のモデルはQwen3.5 397B A17Bだ。Mac Studio側ではMLX 6 bit quantizationを使い、323GBのモデルを512GB unified memoryへロードした。報告されたgeneration速度は30 to 40 tok/s。投稿者によれば、主な強みは約800 GB/sのmemory bandwidthで、巨大モデルでもsingle boxでtoken generationが滑らかになる点にある。setupも比較的簡単だった一方で、大きなsystem promptではprefillに30+秒かかり、MLX VLMがtool call処理やthinking token除去を標準で持たないため、独自のasync proxyを書く必要があったという。

Dual DGX Sparksは何を見せたか

Dual Spark側ではINT4 AutoRoundを使い、98GB per nodeを2つの128GB nodeへ分散し、vLLM TP=2で運用した。generationは27 to 28 tok/sでsteady decodeではMacより少し低いが、prefillはより速く、batch embedding性能はかなり優れていたとされる。CUDA tensor core、vLLM kernel、tensor parallelismのおかげで、推論だけでなくRAGやembedding、rerankingを並行する用途ではSpark platformの魅力が大きいという評価だ。

ただし代償は運用の複雑さだった。投稿によれば、安定して動くQSFP cableは1本だけで、Node2のIPはreboot後に消え、GPU memory ceilingは0.88付近をbinary searchで探る必要があった。model load前には両nodeでpage cacheをflushする必要があり、一部ユニットは20分以内にthermal throttlingも起こしたという。つまりSparkは柔軟性と補助workload性能を得る代わりに、かなりの調整時間を要求する。

実務的な結論

興味深いのは、投稿者がどちらか一方を勝者にしなかったことだ。最終的にはMac Studioをinference専用、Dual SparksをRAG、embedding、reranking専用として、Tailscaleで接続する構成に落ち着いた。また、$20Kのhardware costは月$2KのAPI支出に対して約10か月で損益分岐に達するとも見積もっている。

local-LLM運用者にとって、このスレッドは単なる自慢話ではない。巨大モデルのlocal deploymentが、帯域、運用コスト、補助workflowを含めて評価すべき本格的なarchitecture choiceになりつつあることを示す、具体的な比較データと言える。

出典: r/LocalLLaMAスレッド

#mac-studio

LocalLLaMA比較 Qwen3.5 397B運用でDual DGX Sparksと512GB Mac Studioが対決

LocalLLaMA比較　Qwen3.5 397B運用でDual DGX Sparksと512GB Mac Studioが対決