Article
Mac StudioのGemma 4 31BとGX10のGemma 4 31Bを比べたら、Mac Studioの方が速かった
ASUS Ascent GX10のセットアップが終わったので、まずは手元のMac Studioで動かしているGemma 4と比べてみた。
正直、最初はGX10の方が速いと思っていた。NVIDIA GB10を積んだDGX Spark互換機で、128GBのユニファイドメモリもある。ローカルLLM専用機として買った以上、31BクラスのモデルでもMac Studioより気持ちよく回ってほしい、という期待があった。
ところが、最初の実測では逆だった。
比較したもの
Mac Studio側は、普段使っているMLXサーバをそのまま使った。
Machine: Mac Studio
Chip: Apple M4 Max
Memory: 64 GB unified memory
Runtime: mlx_vlm.server
Endpoint: http://127.0.0.1:11434
Model: mlx-community/gemma-4-31b-it-4bit
Reported context size: 262144
GX10側は、同じGemma 4 31B系のGGUFを llama.cpp CUDAで動かした。
Machine: ASUS Ascent GX10 / DGX Spark-compatible system
GPU: NVIDIA GB10
Memory: 128 GB LPDDR5x unified system memory
Runtime: llama.cpp CUDA
Model: gemma-4-31B-it-Q4_K_M.gguf
Model source: unsloth/gemma-4-31B-it-GGUF
Model size on disk: 18 GB
GX10側の起動は、公開用にパスとホスト名を伏せるとだいたい次の形になる。
llama-server \
-m <model-path>/gemma-4-31B-it-Q4_K_M.gguf \
--host 127.0.0.1 \
--port 18080 \
-ngl 999 \
-c 32768 \
--jinja \
--reasoning off \
-fa on \
--parallel 1
MacからはSSHトンネルでGX10の 18080 を転送した。
ssh -N -L 18080:localhost:18080 <hostname>
ベンチマークは、自分の検証用に用意した小さなスクリプトから、OpenAI互換APIに同じプロンプトを投げる方式にした。測定対象は短い日本語応答、日本語要約、Pythonコード生成の3種類。今回はまず様子を見るため、各プロンプト1回ずつの実行だ。
結果
結果はこうだった。
| target | prompt | sec | completion tokens | wall tok/s | server tok/s | finish |
|---|---|---|---|---|---|---|
| mac-mlx | jp_short | 1.30 | 20 | 15.37 | - | stop |
| gx10-llamacpp | jp_short | 1.31 | 13 | 9.95 | 12.12 | stop |
| mac-mlx | jp_summary | 10.88 | 256 | 23.54 | - | stop |
| gx10-llamacpp | jp_summary | 22.91 | 256 | 11.17 | 11.32 | length |
| mac-mlx | python_code | 9.83 | 225 | 22.90 | - | stop |
| gx10-llamacpp | python_code | 20.36 | 227 | 11.15 | 11.32 | stop |
平均すると、Mac Studio MLXが 20.60 tok/s、GX10 llama.cpp CUDAが 10.76 tok/s。短い応答では差が見えにくいが、256 tokens前後まで生成させると、Mac Studio側がだいたい倍近く速かった。
この結果はかなり意外だった。ローカルAI専用機を買った直後の初回ベンチで、メイン作業機のMac Studioに負けるとは思っていなかった。
たぶんメモリ帯域とruntimeが効いている
まだ断定はできない。ただ、今回の結果は「31Bクラスの4bitモデルをbatch size 1で生成する用途では、ピーク演算性能だけではなくメモリ帯域とruntime最適化がかなり効く」と見ると説明しやすい。
今回のMac StudioはM4 Max構成で、公称メモリ帯域は 546 GB/s。一方、DGX Spark / GB10側の128GB LPDDR5x unified memoryは 273 GB/s とされている。単純な公称値だけ見ると、Mac Studio側はGX10の約2倍のメモリ帯域を持っている。
今回の平均生成速度も、おおむねその比率に近い。
もちろん、LLM推論はメモリ帯域だけで決まるわけではない。runtime、量子化形式、カーネル、KV cache、プロンプト長、サンプリング設定などが絡む。それでも「モデルがメモリに収まる」ことと「単発チャットで速く生成できる」ことは別問題だ、というのは実感として残った。
31B Q4は入る。でも生成は軽くない
今回のGX10側GGUFは18GB程度だった。GX10の128GBメモリには余裕で入るし、Mac Studioの64GBにも入る。容量という意味では、31B Q4はもう特別に怖いサイズではない。
ただ、autoregressive decodingでは1 token生成するたびにモデル重みやKV cacheを何度も読みに行く。1人でチャットしているような小さいbatchでは、演算器をどれだけ積んでいるかより、重みをどれだけ速く読み出せるかが効きやすい場面がある。
このあたりは、ローカルLLM専用機を評価するときに見落としやすい。大容量メモリがあると「大きいモデルを載せられる」ようにはなる。でも、それがそのまま「小さいリクエストが速い」にはならない。
これはGX10の限界ではない
ここは強く書いておきたい。
今回の比較は、厳密な同一条件比較ではない。
| 項目 | Mac Studio | GX10 |
|---|---|---|
| モデル系統 | Gemma 4 31B | Gemma 4 31B |
| 量子化 | MLX 4-bit | GGUF Q4_K_M |
| runtime | MLX VLM server | llama.cpp CUDA |
| API | OpenAI互換 | OpenAI互換 |
| 測定回数 | 各プロンプト1回 | 各プロンプト1回 |
同じGemma 4 31B系ではあるが、量子化形式もruntimeも違う。GX10向けに最適化されたvLLM、TensorRT-LLM、NIMのような経路を使った比較でもない。測定回数も少ない。
だから、この記事で言えるのは「GX10はMac Studioより遅い」ではない。
言えるのは、もっと限定された話だ。
Gemma 4 31Bを、Mac Studio上のMLXと、GX10上のllama.cpp CUDAでそのまま比べると、今回の条件ではMac Studioの方が速かった。
この限定つきの結果でも、自分には十分大きな発見だった。
次に試すこと
このあと考えたのは、GX10でGemma 4を無理に速くするより、OpenClawやAtlasのバックエンド候補としてQwen系を試す方が実用に近いのでは、ということだった。
試したいことは次のあたり。
- Qwen 3.x系をGX10で動かす
- OpenAI互換APIとしてOpenClawから叩く
- llama.cppだけでなく、vLLMやSGLangも見る
- 1ユーザーのtok/sだけでなく、tool callingや画像入力も見る
- 直APIの成功と、OpenClaw / Telegram経由の成功を分けて評価する
実際、このあとGX10上のQwenを試すと、見え方はかなり変わった。Gemma同士ではMac Studioが速かったが、GX10に別のモデルとruntimeを載せると話は単純ではなくなる。
暫定結論
今回の結果は、ローカルLLM専用機への期待を少し冷静にしてくれた。
GX10は「大きいモデルをローカルに載せる」ための余裕がある。一方で、31Bクラスの4bitモデルを単発チャットで生成するだけなら、Apple Siliconの高いユニファイドメモリ帯域とMLX最適化はかなり強い。
少なくともこの条件では、Mac Studioはまだ相当に強いローカルLLMマシンだった。
ただし、これはGX10の評価の終わりではない。むしろここからが本番で、モデル、runtime、量子化、tool calling、画像入力、実アプリへの経路を含めて見ないと、ローカルAI専用機としての価値は判断できない。
