0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

【競うな】DGX SparkにMac Studioを買い足したので、ローカルLLMの得意分野を測った【持ち味をイカせッッ】

0
Last updated at Posted at 2026-09-27

手元ではNVIDIAのDGX SparkでローカルLLMを動かしている。
そこへ新型Mac Studio M5 Max 64GBを追加購入した。60万円!

DGX SparkとMac Studio

2台の性格はかなり違う。どの仕事をどちらに任せるべきかを、同じモデルで実測して決める。

使ったモデルはQwen3.8-27B。4bitに圧縮した版を両機で動かす。

LLMの仕事は「読む」「書く」「同時にさばく」の3つ

LLMは文章をトークンという単位で扱う。日本語ならおおむね1〜2文字で1トークンになる。「32K」と書いたら約3万2千トークンの入力のことだ。

LLMが1件の依頼をこなす流れは、「読む」と「書く」の2段階に分かれる。

LLMの3つの仕事

  • 読む:渡された文章をまとめて一気に読み込む。専門用語ではprefill。送信してから答え始めるまでの秒数で測る
  • 書く:回答を1トークンずつ順番に生成する。専門用語ではdecode。1秒あたりに出せるトークン数(tok/s)で測る
  • 同時にさばく:複数の依頼を並行して処理する。全員分の出力を、全体の所要時間で割って測る

読むと書くは単独の要素だ。同時にさばく量は、読むと書くの両方を含んだ総合成績になる。

もう1つ、モデルの形式と、それを動かすソフトが登場する。同じモデルでも配布形式が複数ある。GGUFはllama.cppというソフト向け、NVFP4はNVIDIA GPU向け、MLXはApple Silicon向けの形式だ。ソフトはllama.cppとvLLMの2つを使った。

仮説:Macは書くのが速く、DGXは読むのと同時処理が速い

Mac Studio DGX Spark
チップ Apple M5 Max(GPU 40コア) NVIDIA GB10(Blackwell世代GPU)
メモリ 64GB 128GB
メモリ帯域 614GB/s 273GB/s
メーカー公表のAI演算性能 数値は非公表。GPUの全コアに行列演算器(Neural Accelerator)を内蔵し、AI性能は前世代比で最大3.9倍 最大1 PFLOP(FP4)。4bit演算に対応したTensorコアを搭載

書くときは、1トークン出すたびにモデルの重み全体をメモリから読み出す。速さはほぼメモリ帯域で決まるので、帯域が2.25倍あるMacが有利なはずだ。

読むときは、入力をまとめて行列計算する。帯域より計算力が効く。同時処理も同じで、複数人分の計算をまとめて行うほど計算力が物を言う。さらに、同時に抱える依頼が増えるほど作業用のメモリも要る。

計算力の公表値は条件がそろっていないので、直接は比べられない。ただ、NVIDIAは4bit演算で1 PFLOP(毎秒1000兆回)という演算性能そのものを看板にしている。メモリ容量も2倍ある。読むのと同時処理はDGX向きと考えた。

ただし、この強みをどのソフトとどの形式で引き出せるかは、やってみないとわからない。

まず同じファイルで比べる

最初は小細工なしで比べた。同じGGUFファイルを、同じバージョンのllama.cppで、同じ設定で動かす。

同じファイルでの比較:読む

テスト Mac Studio DGX Spark 優位
読む 32K(秒) 65.4 46.2 DGX 1.4倍
読む 64K(秒) 180.1 101.4 DGX 1.8倍

読むのはDGXが速く、64Kでは約1.8倍の差になった。

同じファイルでの比較:書く

テスト Mac Studio DGX Spark 優位
書く(tok/s) 25.9 10.8 Mac 2.4倍

書くのはMacが2.4倍速く、帯域の比(2.25倍)とほぼ一致する。ここまでは仮説どおりだ。

次に、8Kの資料を1件だけ流した場合と、4件同時に流した場合を比べた。ここからの同時処理の図は、1本の棒が1件の依頼を表す。点線が順番待ち、薄い色が読む時間、濃い色が書く時間だ。

同じファイルで同時にさばく

同時件数 全体時間 Mac 全体時間 DGX 処理量 Mac 処理量 DGX
1件 24.0秒 36.3秒 12.5 tok/s 8.3 tok/s
4件 75.8秒 79.3秒 15.8 tok/s 15.1 tok/s

どちらも4件を少しずつずらして読み始め、書き終わりは4件ほぼ同時になる。全体の時間は1件のときの2〜3倍に延び、1秒あたりの処理量はMacが15.8、DGXが15.1 tok/sでほぼ互角だった。この構成では、同時処理でのDGXの強みはまだ見えない。

読み始めはずれているのに、書き終わりがそろうのには理由がある。llama.cppは、書いている依頼を1トークン進める作業と、読んでいる依頼の資料をひとかたまり読む作業を、1回の処理にまとめて行う。1回の処理時間はほとんど読む作業で決まるので、誰かが読んでいる間は、先に書き始めた依頼も数秒に1トークンしか進まない。Macでは、最初の依頼は19.5秒で書き始めたが、最後の依頼が読み終わる52.8秒までに書けたのは約8トークンだった。4件そろって本格的に書き進めるのは全員が読み終わってからなので、書き終わりもそろう。

DGXの持ち味を引き出す:NVIDIA専用形式で「読む」も「さばく」も約2倍

DGXでは、llama.cpp+GGUFのほかに、vLLM+NVFP4を試した。NVFP4はNVIDIAが自社GPU向けに用意した4bit形式で、Blackwell世代の4bit演算機能を使える。vLLMは、複数の依頼をまとめて処理することに力を入れたソフトだ。

まず読むと書くを単独で比べる。

DGXの構成比較:読む

テスト llama.cpp+GGUF vLLM+NVFP4 優位
読む 32K(秒) 46.2 21.0 vLLM 2.2倍
読む 64K(秒) 101.4 49.5 vLLM 2.0倍

vLLM+NVFP4に替えると、読み込み時間は半分以下になった。持ち味がそのまま伸びた形だ。

DGXの構成比較:書く

テスト llama.cpp+GGUF vLLM+NVFP4 優位
書く(tok/s) 10.8 11.5 vLLM 1.06倍

強みではない書く速さも、6%ほど上がった。

では、同時処理はどうか。同じファイルでの比較では、Macとの差がほとんどつかなかった種目だ。

DGXの構成比較:同時にさばく

同時件数 全体時間 llama.cpp 全体時間 vLLM 処理量 llama.cpp 処理量 vLLM
1件 36.3秒 28.2秒 8.3 tok/s 10.6 tok/s
4件 79.3秒 43.9秒 15.1 tok/s 27.3 tok/s

vLLM+NVFP4は、4件をまとめて読み、まとめて書く。全体の時間は1件のとき(28秒)の1.6倍(44秒)に延びるだけで、仕事量は4倍になる。4件同時の処理量は15.1から27.3 tok/sへ、1.8倍に伸びた。

vLLMが同時処理に強いのは、1回の処理に詰め込める量が大きいからだ。今回の設定では約3.2万トークンまで一度に扱えるので、8Kの資料4件をまるごと1回で読める。読む作業の総量は変わらず、1件なら3.4秒、4件では約16秒かかる。それでも、書く作業が読み込みに足止めされる時間はなくなる。4件そろって書き始めれば、1回の処理で4件分を1トークンずつ進められる。書くときの重みの読み出しは1件でも4件でもほぼ同じなので、300トークンを書く時間は1件で約25秒、4件で約27秒とほとんど変わらない。

読む・書く・同時にさばくの3種目すべてで上回ったので、DGXはvLLM+NVFP4を採用した。

Macの持ち味を引き出す:MTPで書く速さに全振り

Macでは3つの構成を比べた。

  • GGUF:llama.cppでそのまま動かす
  • GGUF+MTP:同じファイルで、MTPという先読み機能を有効にする
  • MLX:Apple Silicon向け形式を、Mac版vLLMで動かす

書くときは本来1トークンずつしか進めない。MTPは、この先の数トークンをまとめて予想し、本体で一度に答え合わせする。予想が当たった分だけ、1回で何トークンも進める。つまり、書く速さが大きく伸びるはずだ。Macの持ち味をさらに伸ばす候補として入れた。

Macの構成比較:読む

テスト GGUF GGUF+MTP MLX 最速
読む 32K(秒) 66.0 70.4 46.4 MLX
読む 64K(秒) 170.1 195.5 119.2 MLX

読むのはMLXが最も速く、MTPを入れるとやや遅くなる。

Macの構成比較:書く

テスト GGUF GGUF+MTP MLX 最速
書く(tok/s) 25.3 41.7 27.0 GGUF+MTP(GGUF比1.65倍)

一方、書く速さは狙いどおりMTPで1.65倍の41.7 tok/sになった。

同時処理も測った。

Macの構成比較:同時にさばく

同時件数 指標 GGUF GGUF+MTP MLX
1件 全体時間 23.8秒 23.0秒 21.2秒
1件 処理量 12.6 tok/s 13.1 tok/s 14.1 tok/s
4件 全体時間 71.9秒 93.2秒 57.3秒
4件 処理量 16.7 tok/s 12.9 tok/s 20.9 tok/s

4件同時では、GGUF+MTPの全体時間が93秒と最も長く、処理量は12.9 tok/sで最も少ない。MLXは57秒、20.9 tok/sだった。3構成とも書き終わりがそろうのは、同じファイルでの比較で説明したのと同じ理由だ。

それでもGGUF+MTPを採用した。同時処理はDGXに任せ、Macには同時処理をさせない。1人分の回答をひたすら速く書くことに特化させる。読むのもさばくのもMLXが上だが、どちらもDGXが持っている強みで、Macがそこで勝負する必要はない。

持ち味どうしの対決

ここからは、Macの採用構成(GGUF+MTP)とDGXの採用構成(vLLM+NVFP4)を比べる。

読む:DGXが3.4〜4.0倍速い

読むの対決

テスト Mac Studio DGX Spark 優位
読む 8K(秒) 13.1 3.4 DGX 3.9倍
読む 32K(秒) 70.4 21.0 DGX 3.4倍
読む 64K(秒) 195.5 49.5 DGX 4.0倍

64Kの資料なら、DGXは50秒で答え始める。Macは3分以上かかる。

書く:Macが3.6倍速い

書くの対決

テスト Mac Studio DGX Spark 優位
書く(tok/s) 41.7 11.5 Mac 3.6倍

長い回答やコード生成を1人で待つ場面では、この差がそのまま待ち時間の差になる。

同時にさばく:4件ならDGXが約2倍多く処理する

同時にさばくの対決

同時件数 Mac Studio(tok/s) DGX Spark(tok/s) 優位
1件 13.1 10.6 Mac 1.2倍
2件 13.2 18.2 DGX 1.4倍
4件 12.9 27.3 DGX 2.1倍

1件ならMacが上回る。件数を増やしてもMacの総処理量は横ばいで、DGXは4件で2.6倍に伸びた。

中で何が起きているかを、1件ずつの棒に分解して見る。

同時にさばくの中身

同時件数 全体時間 Mac 全体時間 DGX
1件 23.0秒 28.2秒
4件 93.2秒 43.9秒

DGXは4件をまとめて読み、まとめて書く。全体の時間は1件のときの1.6倍に延びるだけで、仕事量は4倍になる。

Macは4件を少しずつずらして読み、その間はほかの依頼の書く作業も遅れる。全体の時間は1件のときの4倍に延び、仕事量も4倍なので、1秒あたりの処理量は変わらない。

おまけ:1人で長い会話を続けると、どちらが速いか

ここまでの「同時にさばく」は、複数の人が同時に依頼する場面だった。最後は、1人が長い会話を続ける場面を見る。依頼は1件ずつだ。

約3.2万トークンの会話の続きに、新しい資料を貼って質問する。横軸は待ち時間で、貼った量ごとに比べた。薄い部分が読む時間、濃い部分が書く時間だ。

1人で長い会話を続ける

追加した量 Mac Studio(秒) DGX Spark(秒) 優位
1千トークン 16.1 28.7 Mac 1.8倍
5千トークン 27.9 31.6 Mac 1.1倍
1万トークン 44.6 35.3 DGX 1.3倍

貼る量が少なければ、書く速さの差でMacが先に終わる。1万トークン貼ると、読む時間の差でDGXが逆転する。合成データでの結果で、実際の作業でどれくらいの量を貼るかまでは測っていない。

まとめ

仕事 任せる先 構成
1人で長い回答を書かせる Mac Studio llama.cpp+GGUF+MTP
大きな資料を読ませる DGX Spark vLLM+NVFP4
複数の依頼を同時に流す DGX Spark vLLM+NVFP4

2台に同じ仕事で競わせても意味がない。Macは書く、DGXは読んでさばく。それぞれの持ち味に合わせて仕事を振り分ければいい。


測定条件と限界

  • モデル:Qwen3.8-27B(4bit系)。GGUFはQ4_K_M、DGXはNVIDIA配布のNVFP4、MacのMLXは4bit版
  • ソフト:llama.cpp(d775b8967)、vLLM 0.30.0(DGXはCUDA版、MacはvLLM-Metal)
  • 条件:thinking OFF、temperature 0。各項目は準備運転1回のあと本測定3回を行い、中央値を採用
  • 「書く」は55トークンの短い質問に300トークンで答えさせ、答え始めてからの速度を測った
  • 「同時にさばく」は、8Kの資料で各件300トークンを回答させた。1件ごとの読む時間は、llama.cppはサーバーが返す読み込み速度から、vLLMはサーバーの処理記録(OpenTelemetryのトレース)から求めた
  • DGXのvLLM+NVFP4の同時処理は、トレースを取るために測り直した。2回目の値(本記事で使用)は1回目より5〜7%高かった
  • llama.cppで2件同時に流すと、回によって書く速さが2通りに分かれた(MacもDGXも同じ傾向)。本記事は3回の中央値を使っている
0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?