Article
GX10でQwenとGemma 4を載せ替えてわかった、ローカルLLM専用機の現実
GX10をローカルAI専用機としてセットアップしてから、QwenとGemma 4を何度も載せ替えて試した。
最初は単純に、Mac Studioで動かしているGemma 4をGX10へ移せば、メインマシンを空けられて、しかも速くなるのではと思っていた。ところが実際には、同じGemma 4系ではMac StudioのMLXがかなり強かった。
一方で、GX10にQwenを載せると見え方は変わる。Qwen3.6のQ4はかなり速い。ただし、OpenClawやAtlasで使うには速度だけでは足りない。tool calling、画像入力、context長、runtime、実際のアプリ経路まで見ないと判断できなかった。
この日はほぼ一日、GX10上でモデルとruntimeを入れ替え続けた。
先に結論
今回の手元実験での暫定判断はこう。
速さ:
GX10 Qwen3.6 Q4 llama.cpp
> GX10 Qwen3.6 vLLM
> Mac Studio Gemma 4 MLX
> GX10 Gemma 4 vLLM
実用候補:
GX10 Qwen3.6 vLLM
安定性を見たい用途:
Gemma 4 vLLMをfallback候補に残す
まだ慎重に見るべきもの:
OpenClaw/Atlasのtool-heavyな実経路
GX10が遅い、という話ではない。むしろQwenではかなり速かった。問題は、モデル、量子化、runtime、tool calling、画像入力、context長の組み合わせで結果が大きく変わることだった。
特に大きかったのは、同じ「Qwen3.6」と言っても、GGUFをllama.cppで出すtext-only経路と、Hugging FaceモデルをvLLMで直接出すmultimodal経路では、できることが違うという点だ。
この図の数字は、手元の短い評価での平均値だ。厳密な同一条件比較ではない。むしろ、ローカルLLM専用機の評価では「runtimeと起動経路が違うだけで、別物のように振る舞う」ことを見るためのメモに近い。
最終的に置いた構成
最終的に、GX10では単一モデルだけを置くのではなく、役割ごとに分けた。
LLM / vision / tool calling:
model: Qwen/Qwen3.6-35B-A3B
runtime: vLLM
served name: gx10-qwen
endpoint: http://<gx10-tailnet-ip>:18081/v1
context: 131072
input: text + image
embedding:
model: multilingual-e5-large
endpoint: http://<gx10-tailnet-ip>:18082/v1
runtime: CPU sidecar
TTS:
model: gx10-edge-tts
endpoint: http://<gx10-tailnet-ip>:18083/v1
runtime: CPU/network sidecar
STT:
model: gx10-whisper-medium
endpoint: http://<gx10-tailnet-ip>:18084/v1
runtime: CPU faster-whisper medium int8
中心に置いたのはQwen/Qwen3.6-35B-A3Bだ。Q4のllama.cpp版はもっと速かったが、実用上はtext-onlyだった。vLLM版はQ4ほど速くない代わりに、画像入力とOpenAI互換tool callingを同じ経路で扱える。
Embedding、TTS、STTはCPU側のsidecarにした。これはQwen本体のGPUメモリを削りすぎないためだ。TTSは一度Qwen3-TTSをGPUで動かすところまで試したが、vLLM-Omniの2段構成で追加のGPUメモリをそれなりに使う。常用構成としては、Qwen本体を優先した。
STTは、TTSで作った日本語テスト音声を正しく文字起こしできた。短い音声のウォーム後は数秒台まで来ているので、自分用の軽い音声入力補助としては十分試せそうだった。
試したモデル一覧
ざっくり並べると、今回見たのはこのあたり。
| host | model | runtime | 主目的 | 結果 |
|---|---|---|---|---|
| Mac Studio | mlx-community/gemma-4-31b-it-4bit |
MLX VLM server | 既存baseline | Gemma 4比較では最速。約20.6 tok/s |
| GX10 | gemma-4-31B-it-Q4_K_M.gguf |
llama.cpp CUDA | 同系Gemma比較 | 約10.8 tok/s。Mac Studioに負けた |
| GX10 | Qwen3.6-35B-A3B-UD-Q4_K_M.gguf |
llama.cpp CUDA | OpenClaw高速backend候補 | とても速い。通常回答で約62 tok/s。ただしtext-only |
| GX10 | Qwen3.6-35B-A3B-BF16 |
llama.cpp CUDA | Qwen品質改善の確認 | 動くがQ4より遅い。小テストでは明確な品質改善なし |
| GX10 | Qwen3VL-32B-Instruct-Q4_K_M.gguf |
llama.cpp CUDA | 画像対応Qwen | 画像は読めたが、実用経路は重め |
| GX10 | Qwen/Qwen3-VL-30B-A3B-Instruct-FP8 |
SGLang | Qwen VLM構成 | 直叩きは速い。ただしOpenClaw/Atlasのtool-heavy用途で不安定 |
| GX10 | nvidia/Gemma-4-31B-IT-NVFP4 |
vLLM | 安定候補 | 遅いが、画像・tool・Atlas Chatでは扱いやすかった |
| GX10 | Qwen/Qwen3.6-35B-A3B |
vLLM | Qwen3.6のmultimodal経路 | Gemma 4 vLLMより約4から5倍速い。text/image確認済み |
この表だけ見ると「Qwenが勝ち」と言いたくなる。ただ、実際にはもう少しややこしい。
Q4のQwenは速いが、画像が必要な場面では足りない。SGLangのQwen3-VLは直APIでは面白かったが、OpenClawやAtlasのtool-heavyな実経路では崩れ方が気になった。Gemma 4 vLLMは遅いが、Atlas Chatのような根拠付きのtool利用では安定感があった。
Gemma 4: Mac Studioが強かった
最初にやったのはGemma 4同士の比較だった。
Mac Studio側は、もともと動かしていたMLX VLM server。
model: mlx-community/gemma-4-31b-it-4bit
runtime: MLX
context: 262144
GX10側は、GGUFをllama.cpp CUDAで起動した。
model: gemma-4-31B-it-Q4_K_M.gguf
runtime: llama.cpp CUDA
context: 32768
結果は意外だった。
| target | mean wall-clock completion speed |
|---|---|
| Mac Studio MLX Gemma 4 | 20.60 tok/s |
| GX10 llama.cpp CUDA Gemma 4 | 10.76 tok/s |
GX10の方が速いと思っていたが、Gemma 4同士ではMac Studioがかなり速かった。
たぶん、Mac StudioのMLX最適化とメモリ帯域が効いている。今回のMac StudioはM4 Max 64GB構成で、Appleの仕様上メモリ帯域は546GB/s。一方、GX10のGB10は273GB/s級とされている。Gemma 4 31Bくらいのdenseモデルだと、GPU演算だけでなくメモリ帯域とruntime最適化がかなり効いていそうだ。
もちろん、これは完全に同一条件ではない。MLX 4bitとGGUF Q4_K_Mで、runtimeも違う。だから「GX10が遅い」とは言えない。ただ、少なくとも「Gemma 4を移せばGX10の方が速い」は、この条件では成り立たなかった。
Qwen3.6 Q4: 速い、かなり速い
次に試したのがQwenだった。
model: Qwen3.6-35B-A3B-UD-Q4_K_M.gguf
runtime: llama.cpp CUDA
context: 65536 -> 131072 -> 262144
served model: gx10-qwen
これは速かった。
Mac Studio Gemma 4との比較では、通常回答もtool call小テストもQwenが明確に勝った。
| target | suite | mean wall tok/s |
|---|---|---|
| Mac Studio Gemma 4 | answer tasks | 19.56 |
| GX10 Qwen Q4 | answer tasks | 62.08 |
| Mac Studio Gemma 4 | tool-call tasks | 10.32 |
| GX10 Qwen Q4 | tool-call tasks | 36.63 |
小さなtool callテストでは、search_hybrid、get_file、execのようなtool callも正しく出せた。
ただし、OpenClawに組み込むとすぐに別の問題が出た。64K contextでは、実セッションがシステムプロンプトやツール定義で膨らみ、contextが足りなくなった。
request (65555 tokens) exceeds the available context size (65536 tokens)
そこで128K、最終的には262K contextまで上げた。GX10はメモリに余裕があり、モデル側も長いcontextを持っていたので、ここはGX10らしい強みが出た。
一方で、このQwen3.6は実用上text-onlyだった。OpenClawやAtlasで画像を扱いたいという要求には合わない。
Qwen3.6 BF16: 品質向上を期待したが、速度低下が大きい
Q4で速いなら、BF16なら品質が上がるのでは、ということでBF16も試した。
model: Qwen3.6-35B-A3B-BF16
runtime: llama.cpp CUDA
context: 262144
互換性は問題なかった。直接のchat completionもtool callも成功した。
ただ、同じ小さな評価タスクではQ4より明確に遅かった。
| target | suite | mean wall tok/s | tool accuracy |
|---|---|---|---|
| Qwen Q4_K_M | quality | 62.08 | - |
| Qwen BF16 | quality | 27.41 | - |
| Qwen Q4_K_M | tools | 36.63 | 4/4 |
| Qwen BF16 | tools | 17.96 | 4/4 |
BF16は動く。しかし、この範囲では遅くなった分だけの明確な品質改善は見えなかった。しかもQ4とBF16を同時に起動するとメモリ圧が強くなり、swapを使い始めた。
常用候補としては、BF16のllama.cpp経路より、別の起動方法を見た方がよさそうだった。
Qwen3-VL: 画像対応はできるが、実用経路は難しい
テキストしか扱えないのは困るので、Qwen3-VLも試した。
まずはGGUF版。
model: Qwen3VL-32B-Instruct-Q4_K_M.gguf
mmproj: mmproj-Qwen3VL-32B-Instruct-F16.gguf
runtime: llama.cpp CUDA
context: 262144
これは画像を読めた。OpenClawのlocal one-shotでも、画像の内容を読ませるところまでは成功した。
ただし、OpenClaw Gatewayのone-shot --file経由では、ファイルが入力として認識されているのに、モデル側には画像処理ログが出ないケースがあった。これはモデルそのものというより、Gatewayのファイル転送経路の問題に見えた。
その後、より理想に近い構成としてSGLang + Qwen3-VL FP8も試した。
model: Qwen/Qwen3-VL-30B-A3B-Instruct-FP8
runtime: SGLang
context: 262144
served model: gx10-qwen
input: text + image
この構成はかなり有望だった。直接APIでは、テキスト、画像、OpenAI互換tool callingが動いた。短い直接生成では約51 tok/sも出ている。
ただし、実際にOpenClawやAtlasで使うと別の問題が見えた。
- Telegramでtool call JSONの断片がそのまま出ることがあった
argumentsだけが溢れ出るような返答が見えた- Atlas Chatで、以前のQwenでは取れた情報を取れないケースがあった
- 画像は読めても、tool-heavyなエージェント用途では安定感が足りなかった
SGLang側の設定で改善できる部分はありそうだった。ただ、OpenClaw側のツールを絞って帳尻を合わせるのは、実用評価としては違う。実環境のOpenClawでそのまま使えるかを見たいので、ここは課題として残した。
Gemma 4 NVFP4 + vLLM: 遅いが、いちばん安定した時期があった
最終的に一度戻ってきたのがGemma 4だった。
ただし、最初のGGUF/llama.cppではなく、NVIDIAのNVFP4モデルをvLLMで起動した。
model: nvidia/Gemma-4-31B-IT-NVFP4
runtime: vLLM
served model: gx10-gemma4
context: 65536
tool parser: gemma4
reasoning parser: gemma4
input: text + image
この構成では、直接APIでテキスト応答、画像入力、OpenAI互換tool callを確認できた。Atlas Chatでもsearch_hybrid -> get_fileの流れで根拠付き回答ができた。
一方で、速度は厳しかった。
| runtime | context | prompt | sec | completion tokens | wall tok/s |
|---|---|---|---|---|---|
| Gemma4 NVFP4 vLLM | 256K | jp_summary | 38.38 | 256 | 6.67 |
| Gemma4 NVFP4 vLLM | 64K | jp_summary | 38.48 | 256 | 6.65 |
| Gemma4 NVFP4 vLLM | 64K | python_code | 32.87 | 218 | 6.63 |
256Kから64Kに落としても、長文生成速度はほぼ変わらなかった。つまり、この時のボトルネックはKV cache容量というより、Gemma 4 31Bのdense decodeそのもの、またはvLLM/GB10上での最適化状況だと思う。
Gemma 4 NVFP4は速くはない。しかし、当時のQwen経路よりもtool-heavyなAtlas用途では安定していた。ここは重要だった。
Qwen3.6 BF16 + vLLM: 最後に状況が変わった
ここまで試した段階では、「速いQwen」と「遅いが安定するGemma 4」という見え方だった。
ただ、後から重要な見落としがわかった。最初に使っていたQwen3.6のGGUF経路は、実用上はtext-onlyだった。しかし、Qwen/Qwen3.6-35B-A3B自体はmultimodalモデルで、Hugging FaceのモデルをvLLMで直接起動すると画像の経路も立ち上がる。
つまり、問題は「Qwen3.6が画像を読めない」ではなく、「起動方法がmultimodal経路に乗っていなかった」ことだった。
最終的に、GX10上ではこういう構成にした。
model: Qwen/Qwen3.6-35B-A3B
runtime: vLLM
served model: gx10-qwen
endpoint: http://<gx10-tailnet-ip>:18081/v1
context: 131072
max_num_batched_tokens: 8192
max_num_seqs: 4
gpu_memory_utilization: 0.75
input: text + image
tool parser: qwen3_coder
reasoning parser: qwen3
この構成では、直接APIでテキスト、画像、OpenAI互換tool callが通った。さらにOpenClaw Gateway経由でも、テキスト入力と画像入力の確認が通った。テスト画像に書いた文字列も正しく読めた。
速度も、Gemma 4 vLLMとはかなり違った。
| prompt | Qwen3.6 BF16 vLLM 64K | Gemma4 NVFP4 vLLM 64K | Qwen/Gemma |
|---|---|---|---|
| jp_short | 26.53 tok/s | 4.61 tok/s | 5.8x |
| jp_summary | 28.59 tok/s | 6.65 tok/s | 4.3x |
| python_code | 29.11 tok/s | 6.63 tok/s | 4.4x |
| mean | 28.08 tok/s | 5.96 tok/s | 4.7x |
その後、実運用向けにmax_model_lenを128Kへ広げ、max_num_seqsを4に抑えて再起動した。短い定常ベンチでは平均が28.96 tok/sで、少なくともこの範囲では速度低下は出なかった。
Atlas/OpenClawっぽい小タスクでも、かなり実用的な数字になった。
| runtime | suite | mean wall tok/s | tool accuracy |
|---|---|---|---|
| Qwen3.6 BF16 vLLM | quality | 29.41 | - |
| Qwen3.6 BF16 vLLM | tools | 21.80 | 4/4 |
| Qwen3.6 Q4_K_M llama.cpp | quality | 62.08 | - |
| Qwen3.6 Q4_K_M llama.cpp | tools | 36.63 | 4/4 |
| Qwen3.6 BF16 llama.cpp | quality | 27.41 | - |
| Qwen3.6 BF16 llama.cpp | tools | 17.96 | 4/4 |
Q4のllama.cpp経路はまだ速い。ただしtext-onlyだった。vLLM経路はQ4ほど速くはないが、画像が使えて、OpenClaw Gatewayからも呼べる。
Gemma 4 vLLMと比べると、Qwen3.6 vLLMは体感でもかなり軽い。短い会話や画像付きの確認をOpenClawから投げる用途では、Gemma 4の6 tok/s台はつらく、Qwen3.6の28から29 tok/s台は現実的に使える。
もちろん、これで全部解決ではない。OpenClawの実エージェント経路で複数toolを回し続けるところまでは、まだ慎重に見る必要がある。今回確認できたのは、Gateway経由のtext/image疎通と、直接APIでのtool call構造だ。
OpenClawから見た進歩
以前、Mac Studio上のGemma 4をOpenClawのバックエンドにしようとしたときは、うまく呼べなかった。
それに比べると、GX10ではかなり進んだ。
- OpenClawからGX10上のモデルを直接呼べる
- Tailnet経由でOpenClawホストからGX10を見られる
gx10/gx10-qwen、gx10/gx10-gemma4としてモデル登録できた- QwenではGateway model.runも通った
- Gemma 4でもOpenClaw local one-shotは通った
- Telegram上でもGX10 Gemma 4から自然な応答が返るところまで見えた
- Qwen3.6 vLLMではGateway経由のテキストと画像入力が通った
ただし、OpenClawからAtlasの中身を読む話はまだ別問題だ。
Atlas Chat APIを直接叩くと、search_hybrid -> get_fileのループで正しく答えられる。一方、OpenClawの通常エージェント経路で「Atlasを見て」と言っても、Atlas Chat APIに入らず、OpenClaw側のmemory/wiki検索に流れることがある。
つまり現在の課題はこう。
OpenClaw -> GX10 LLM
これはできた
OpenClaw -> GX10 LLM -> 画像を読む
Qwen3.6 vLLMでできた
OpenClaw -> Atlas Chat API -> GX10 LLM -> Atlas tools
ここはまだきれいにつながっていない
これはモデル性能だけの問題ではない。アプリ側のtool経路、provider設定、どのAPIをどこから呼ぶかの設計も含めた問題になる。
今日の実用判断
一日試した結果、今の実用判断はこう。
Qwen3.6 vLLMを使いたい場面
Qwenは速い。特にQwen3.6 Q4やSGLang FP8の速度は魅力的だった。
ただし、いま第一候補に見えているのはQ4のtext-only経路ではなく、Qwen3.6 BF16をvLLMで直接起動する経路だ。Q4よりは遅いが、画像が使えて、Gemma 4 vLLMよりかなり速い。
向いているのは、たぶんこういう用途だ。
- 短い対話
- 軽い分類
- 単純なtool選択
- 速度優先のOpenClaw実験
- 画像つきの軽い確認
- Gemma 4では遅すぎる日常的な問い合わせ
Gemma 4を残したい場面
Gemma 4は遅いが、回答が比較的締まっていて、Atlasのようなtool-heavy用途では安定していた。
向いているのは、たぶんこういう用途だ。
- Atlas Chat
- 根拠付き回答
- 安全寄りの判断
- Qwenがtool callを崩す場面
- Qwen3.6 vLLMでまだ実運用確認が足りない場面
まだ決めきれていない場面
AtlasのバッチAI処理は悩ましい。
Gemma 4なら動くが、大きめの文書の再要約が遅い。Qwen3.6 vLLMなら速くなる可能性が高いが、Atlasの実バッチ処理で同じ安定性が出るかはまだ別途確認したい。
今後は、Atlasの処理を分けるのが良さそうだ。
軽い分類・タグ付け:
Qwen3.6 vLLM
根拠付き回答・画像・複雑な更新:
Qwen3.6 vLLMを第一候補にしつつ、Gemma 4をfallbackに残す
最終判断や危険な操作:
より強いモデルや人間の確認に戻す
ローカルLLMは「全部を置き換えるもの」ではなく、作業の種類によって使い分ける道具に近い。
まとめ
GX10は、Gemma 4ではMac Studioより遅かった。でもQwenでは速かった。画像対応もできた。OpenClawからも呼べるようになった。Atlasにも一部つながった。
その一方で、tool callが崩れたり、OpenClawの表示経路にハマったり、Atlasのバッチ処理が重かったりした。
最後にQwen3.6 vLLMで、速度と画像対応の両方がかなり現実的になった。とはいえ、これで勝ちモデルが決まったというより、ようやく実用評価のスタートラインに立ったという感覚が近い。
ローカルAI専用機の性能は、GPUスペックだけでは決まらない。
モデル、量子化、runtime、tool calling、画像対応、context長、そして実アプリのエージェント経路まで含めて、ようやく評価できる。
今回のGX10実験で一番面白かったのは、起動経路ひとつで評価が反転するところだった。
次は、このQwen3.6をNVFP4版に差し替えて、GX10のBlackwell世代らしい4bit実行がどこまで効くのかを見る。
