Mac StudioのGemma 4とGX10のQwenを比べたら、Qwenは速く、Gemmaは慎重だった

前回、Mac Studio上のGemma 4 31Bと、GX10上のGemma 4 31B系GGUFを比べたところ、意外にもMac Studioの方が速かった。

ただし、GX10で本当に試したかったのはGemmaだけではない。OpenClawやAtlasのバックエンド候補としては、Qwen系モデルもかなり気になっていた。

そこで今度は、Mac Studio上のGemma 4と、GX10上のQwenを同じようなタスクで直接比較してみた。

結論から言うと、GX10上のQwenはかなり速い。一方で、Gemma 4の方が少し慎重で、答え方が締まっているという印象だった。

比較したもの

今回の比較対象は次の2つ。

target	runtime	model
Mac Studio Gemma 4	MLX VLM server	mlx-community/gemma-4-31b-it-4bit
GX10 Qwen	llama.cpp CUDA	gx10-qwen

GX10側のQwenは、OpenAI互換APIとして起動しているQwen系モデルを使った。Mac Studio側もGX10側も、比較スクリプトからOpenAI互換APIとして叩いている。

ここで大事なのは、今回の比較はOpenClawやTelegramを経由していないことだ。あくまで、Mac StudioのGemma 4とGX10のQwenを、同じようなAtlas/OpenClaw系タスクで直接比較したものになる。

つまり、この記事で言えるのは「QwenがOpenClawバックエンドとして完成した」ではない。言えるのはもっと狭くて、直APIの比較ではGX10 Qwenがかなり速かったという話だ。

ベンチマーク方法

検証には、自分のプロジェクト内に置いている比較スクリプトを使った。やっていることは単純で、2つのローカルAPIに同じプロンプトを投げ、wall time、completion token数、tool callの有無を見る。

タスクは大きく2種類に分けた。

• 通常回答タスク
• OpenAI互換tool callを出せるかを見るタスク

通常回答タスクは、OpenClawの表示問題の診断、Atlas検索結果に基づく回答、破壊的操作に対する安全な返答、embedding移行計画のような、実際に自分が使いそうな小さなタスクにした。

tool callタスクでは、search_hybrid、get_file、exec のような架空のtool定義を渡し、モデルが期待したtool callを出すかだけを見ている。ここではtoolの実行まではしていない。

この切り分けはかなり重要だ。tool callを出せることと、OpenClawの中で実際にtoolを呼び、TelegramやAtlasの実経路で正しく使えることは別問題だからだ。

速度はQwenがはっきり速かった

まず通常回答タスクの平均はこうだった。

target	mean wall time	mean completion tok/s	completion tokens
Mac Studio Gemma 4	12.88 s	19.56 tok/s	1096
GX10 Qwen	5.42 s	62.08 tok/s	1393

tool callタスクでも同じ傾向だった。

target	mean wall time	mean completion tok/s	completion tokens
Mac Studio Gemma 4	1.84 s	10.32 tok/s	77
GX10 Qwen	0.70 s	36.63 tok/s	105

通常回答ではwall timeで約2.4倍、tool callタスクでは約2.6倍。token throughputで見ると、ざっくり3倍前後の差が出ている。

前回のGemma同士の比較ではMac Studioが勝った。ところが、GX10にQwenを載せると話は一気に変わる。

この結果だけを見ると、GX10が遅いわけではない。モデル、量子化、runtime、タスクの組み合わせで、体感はかなり変わる。

tool callの小テストは引き分け

OpenClawやAtlasで使うなら、速いだけでは足りない。必要な場面でtool callを出せるかも重要になる。

今回の小さなテストでは、Gemma 4もQwenも期待したtool callを出せた。

task	expected	Mac Studio Gemma 4	GX10 Qwen
no tool needed	none	no tool call	no tool call
search needed	search_hybrid	correct	correct
get file needed	get_file	correct	correct
exec needed	exec	correct	correct

この範囲ではtool callの正確性は引き分け。差が出たのは速度だった。

ただし、これはかなり小さいテストだ。tool callのJSONを出せるかを見るだけで、tool結果を読んで次の行動を決めるところまでは見ていない。実際のOpenClawでは、toolの実行結果、会話履歴、表示ルール、Telegram配送が絡むので、ここで合格したからといって実運用まで安心できるわけではない。

品質はGemmaの方が少し締まっていた

一方で、回答品質では少し見え方が変わった。

5点満点で、Atlas/OpenClaw用途として手元評価した結果はこうだった。

task	Mac Studio Gemma 4	GX10 Qwen	winner
OpenClaw visibility diagnosis	3	3	tie
Atlas grounded answer	5	3	Gemma
destructive-operation safety	4	4	tie
embedding migration plan	4	3	Gemma

Qwenは速く、内容も十分使える。ただし、やや説明が長くなりがちで、4つの品質タスクのうち3つで finish_reason=length になった。

これはOpenClawやAtlasでは無視できない。長すぎる回答は、後続のtool loopを遅らせる。会話コンテキストも余計に消費する。特にエージェント用途では、「よくしゃべる」ことは必ずしも良いことではない。

Gemma 4はQwenほど速くないが、回答は少し締まっていた。Atlas検索結果に基づく回答では、与えられた断片から実用的な答えを組み立てるところもGemmaの方がよかった。

このあたりは、単純なtok/sだけでは見えない。

速いモデルをそのままデフォルトにする怖さ

今回の結果だけ見ると、GX10 Qwenをすぐデフォルトにしたくなる。実際、軽い対話やシンプルなtool選択では、かなり有望だと思う。

ただ、エージェントのデフォルトモデルは「速い」だけでは決められない。

たとえば、Qwenは今回の品質タスクで有用な内容を出していたが、止まり方が少し弱かった。max tokenまで走りやすいなら、system promptやdecoding設定で短く止める調整が必要になる。

また、今回の比較は直APIだけだ。OpenClaw側では、モデルが普通のassistant本文を返すのか、message toolを使うのか、表示設定がどうなっているのかで、Telegram上の見え方が変わる。直APIで速く返ることと、実際のグループ会話で期待どおりに返ることは別の問題だった。

なので、今回の自分の受け止め方はこうだ。

GX10 Qwen:
  速い対話、軽いtool選択、反復検証に向いていそう。

Mac Studio Gemma 4:
  少し遅いが、慎重な回答や根拠付き回答ではまだ強い。

前回の結果と合わせて見えること

前回は、同じGemma 4 31B系をMac Studio MLXとGX10 llama.cpp CUDAで比べた。その範囲では、Mac Studioの方が速かった。

今回は、Mac Studio Gemma 4とGX10 Qwenを比べた。その範囲では、GX10 Qwenがかなり速かった。

ここから言えるのは、「Mac Studioが常に速い」でも「GX10が常に速い」でもない。

ローカルLLM専用機の評価は、かなり組み合わせ依存だ。

• モデル
• 量子化
• runtime
• context長
• tool callの扱い
• 実アプリへの接続経路
• 1人で使うのか、複数リクエストをさばくのか

このあたりをまとめて見ないと、どちらが良いとは言えない。

少なくとも自分の手元では、GX10は「買えば何でもMac Studioより速くなる箱」ではなかった。ただ、Qwenのように相性の良い構成を載せると、一気に実用候補になる。

実用上の結論

現時点では、次の使い分けがよさそうだと思っている。

用途	向いていそうな候補
軽い対話	GX10 Qwen
シンプルなtool選択	GX10 Qwen
反復的な実験	GX10 Qwen
根拠付きの慎重な回答	Gemma 4、またはさらに強いモデル
破壊的操作の最終判断	Codex/GPT-5.5など、より強いモデル

GX10 Qwenは、OpenClawのバックエンド候補としてかなり面白い。少なくとも、速度面では十分に試す価値がある。

一方で、TelegramやOpenClaw runtimeに実際に組み込むところでは、まだ別の問題にハマっている。APIを直接叩いて速いことと、OpenClawの実用バックエンドとして完成することは別問題だった。

次は、そのOpenClaw統合でハマった話を書く。

注意点

最後に、この比較の注意点をまとめておく。

• これはGemma 4とQwenという、別モデル同士の比較。
• Mac StudioはMLX、GX10はllama.cpp CUDAなのでruntimeも違う。
• Telegram配送やOpenClaw実セッションは通していない。
• tool callテストでは、toolを実際に実行していない。
• 品質評価は小さな手元タスクでの初回評価。

それでも、GX10上のQwenがかなり速いことは見えた。前回のGemma同士の比較で少し冷静になったあとだったので、この結果はかなり面白かった。