Mac Studio M1 MaxでMLX no-thinkingモデルを再検証した：llama-serverより良いのか？
はじめに
前回までの記事では、Mac Studio M1 Max 64GB 上で
llama.cpp/
llama-serverを使い、
社内RAGの文書生成タスクを検証しました。
今回はその続編として、
llama-serverではなく
mlx_lm.serverを使い、
MLX形式のモデルを同じ社内RAGタスクで試しました。
今回知りたかったことは単純です。
Apple Silicon向けのMLXモデルを使うと、llama-serverより良くなるのか。
結論から言うと、今回の社内RAG用途では、
MLXがllama-serverを全面的に置き換えるほど良い、という結果ではありませんでした。
しかし、MLXがだめという話でもありません。
gemma-4-26B-A4B-it-4bitと
qwen3-30b-a3b-instruct-2507-4bit-no-thinkは
かなり実用的で、特にメモリ効率は魅力があります。
自分の中での結論は次の通りです。
既に
llama-server+ GGUF で安定運用できているなら、
主力はまだllama-serverの方がよい。
ただし、MLXのMoE 4bitモデルは低メモリな代替候補・比較候補として十分使える。
本記事のデータ測定に関して、弊社の 澤口 が全面的に実施しております。
本記事は、筆者が所属するクイックイタレート株式会社で検証・運用している社内向けオンプレLLM環境をベースにした事例紹介です。
弊社ではオンプレ LLM 環境の設計・構築・運用のご相談も承っております。
詳細はこちらのページをご覧ください。
測定条件
タスクは前回までと同じです。
DOCUMENT BOX に登録した品質不具合報告書
test1.pdfをRAGで参照し、
次の3種類の文書を書き分けさせます。
- プレスリリース用文面
- BtoB 顧客への個別通知文
- 社内向け是正処置報告（ISO 9001 / 8D / CAPA 風）
主な測定条件は次の通りです。
| 項目 | 値 |
|---|---|
| 実行環境 | Mac Studio M1 Max 64GB |
| runtime | mlx_lm.server |
| API形式 | OpenAI互換API |
| 参照文書 | test1.pdf |
| run数 | 3 |
| 集計 | 3回実行の中央値 |
| context size | 8192 |
| max tokens | 3072 |
| temperature | 0.2 |
| top_k | 10 |
| min_score | 0.45 |
| thinking | enable_thinking=false |
今回のMLX計測では、
llama.cppのような内部
timingsではなく、OpenAI互換APIを叩いた wall time から相当指標を計算しています。
そのため、表中の
prompt tok/s相当や
decode tok/s相当は、
llama-serverの内部
prompt_eval_tok_s/
decode_tok_sと厳密に同じものではありません。
ここは大事な注意点です。
ただ、社内ユーザーにとって重要なのは「画面でどれくらい待つか」「Mac Studio 64GBで他プロセスと同居できるか」です。
その意味では、wall time由来の指標は実運用の体感に近い比較として使えます。
比較したモデル
今回比較したMLXモデルは次の4つです。
| モデル | 構造 | 形式 | 位置づけ |
|---|---|---|---|
Qwen3.6-27B-OptiQ-4bit |
Dense系 | MLX OptiQ 4bit | Qwen3.6系のDense比較 |
gemma-4-26B-a4b-it-4bit |
MoE / A4B系 | MLX 4bit | 速度と低メモリの本命候補 |
gemma-4-31B-it-OptiQ-4bit |
Dense系 | MLX OptiQ 4bit | gemma系の品質確認枠 |
qwen3-30b-a3b-instruct-2507-4bit |
MoE / A3B系 | MLX 4bit | Qwen系の高速MoE候補 |
モデル名だけを見ると、27B、30B、31Bと近いサイズに見えます。しかし実際の速度は、総パラメータ数よりもDenseかMoEか、active parameterがどれくらいかに強く影響されます。
MLX の結果
3回実行の中央値は次の通りです。
| モデル | input [tokens] | output [tokens] | 初回 wall[秒] | 2回目 wall[秒] | prompt [tok/s相当] | decode [tok/s相当] | Peak Mem [GB] | GPU [avg %] |
|---|---|---|---|---|---|---|---|---|
| Qwen3.6-27B-OptiQ-4bit | 1,482 | 1,658 | 132.92 | 114.54 | 11.15 | 12.47 | 15.95 | 89.50 |
| gemma-4-26B-A4B-it-4bit | 1,402 | 1,463 | 37.51 | 34.25 | 37.38 | 39.11 | 13.94 | 94.91 |
| gemma-4-31B-it-OptiQ-4bit | 1,402 | 1,434 | 156.35 | 136.76 | 8.97 | 9.18 | 21.78 | 91.99 |
| Qwen3-30B-A3B-Instruct-2507-4bit | 1,726 | 1,468 | 37.71 | 34.06 | 45.77 | 38.70 | 16.32 | 94.00 |
最も実用的に見えるのは、
gemma-4-26B-A4B-it-4bitと
Qwen3-30B-A3B-Instruct-2507-4bitです。
どちらも初回wall timeが約38秒、decode tok/s相当が約39 tok/sです。社内RAGで1,400から1,500 tokens程度の回答を作るなら、待てる範囲に入っています。
特に
gemma-4-26B-A4B-it-4bitは Peak Mem が 13.94GB と低く、今回の4モデル中で最もメモリ効率が良い結果でした。
一方、Dense系の
Qwen3.6-27B-OptiQ-4bitと
gemma-4-31B-it-OptiQ-4bitはかなり重いです。OptiQでメモリは抑えられていますが、Dense計算そのものが軽くなるわけではありません。
モデル別の所感
gemma-4-26B-A4B-it-4bit
今回のMLX勢では、最もバランスが良いモデルでした。
初回 wall秒: 37.51 秒 decode tok/s相当: 39.11 tok/s Peak Mem: 13.94 GB
速度、メモリ、出力のまとまりのバランスが良いです。プレスリリース、BtoB通知、社内向けCAPAの切り分けも自然で、通常の社内RAGの常用候補にできます。
出力品質だけで見ると、さらに大きいDenseモデルに期待したくなります。しかし、実際の待ち時間とメモリ使用量まで含めると、このモデルはかなり扱いやすいです。
Qwen3-30B-A3B-Instruct-2507-4bit
Qwen3-30B-A3B-Instruct-2507-4bitもかなり速いです。
初回 wall秒: 37.71 秒 decode tok/s相当: 38.70 tok/s Peak Mem: 16.32 GB
input tokens が 1,726 と他モデルより多い状態でも、初回wall timeは
gemma-4-26B-A4Bとほぼ同じです。prompt tok/s相当も 45.77 と高く、全体効率は良く見えます。
ただし、出力はやや短めです。社内向けの一次ドラフトや要約なら使いやすいですが、顧客通知や監査向け文書では、プロンプト側で「必要項目を落とさない」指定を少し強めた方がよさそうです。
Qwen3.6-27B-OptiQ-4bit
Qwen3.6-27B-OptiQ-4bitは、no-thinkingにすると正常に完走しました。
初回 wall秒: 132.92 秒 decode tok/s相当: 12.47 tok/s Peak Mem: 15.95 GB
メモリだけを見ると悪くありません。Peak Mem は 15.95GB で、
Qwen3-30B-A3Bと近いです。
しかし、速度は大きく違います。Dense系なので、OptiQで量子化しても計算量の重さが残ります。画面上で対話的に使う社内RAGの第一候補にはしにくいです。
出力は落ち着いていますが、日常運用では待ち時間が目立ちます。使うなら、品質比較用、バッチ処理、夜間生成向けです。
gemma-4-31B-it-OptiQ-4bit
gemma-4-31B-it-OptiQ-4bitも正常に完走しましたが、今回の4モデル中では最も重い結果でした。
初回 wall秒: 156.35 秒 decode tok/s相当: 9.18 tok/s Peak Mem: 21.78 GB
出力の構成は整います。BtoB通知やCAPA風の社内報告として読みやすい形になりやすいです。
ただし、常用するには待ち時間が長いです。役割としては、品質上限の確認、他モデル出力の比較、重要文書のレビュー用が合っています。
llama-serverと比べるとどうか
ここが今回の本題です。
前回の
llama-server/ GGUF 計測では、たとえば次のような結果でした。
| runtime | モデル | 指標の種類 | 初回秒 | decode tok/s | Peak Mem GB | コメント |
|---|---|---|---|---|---|---|
| llama-server | Qwen3.6-35B-A3B-Q4_K_M | llama.cpp内部timings | prompt 1.92秒 | 51.23 | 20.80 | 速度・メモリのバランスが強い |
| llama-server | Qwen3.6-35B-A3B-Q5_K_M | llama.cpp内部timings | prompt 2.12秒 | 46.15 | 24.13 | 品質寄りの実務候補 |
| llama-server | Qwen3-30B-A3B-Q5_K_M | llama.cpp内部timings | prompt 2.44秒 | 53.82 | 21.85 | 速度は非常に速いが出力は薄め |
| MLX | gemma-4-26B-A4B-it-4bit | wall-clock相当 | 初回全体 37.51秒 | 39.11 | 13.94 | MLX勢のバランス型 |
| MLX | Qwen3-30B-A3B-Instruct-2507-4bit | wall-clock相当 | 初回全体 37.71秒 | 38.70 | 16.32 | MLX勢の高速候補 |
この表では、
llama-serverの初回秒とMLXの初回秒の意味が違います。
llama-serverは内部timingsの
prompt eval秒です。
一方、MLXはOpenAI互換APIリクエスト全体のwall timeです。
したがって、初回秒をそのまま横並びでランキングしてはいけません。
一方で、
decode tok/sは、出力tokensあたりの生成速度を見るうえで参考になります。
この観点では、今回のMLX最速組は約39 tok/sで、前回の
llama-serverのQwen3.6 MoE系は46から51 tok/s台でした。
つまり、今回の社内RAGタスクでは、生成速度の上限はまだ
llama-server/ GGUF の方が高く見えます。
MLXが良かった点
MLXの良い点もはっきりあります。
| 観点 | MLXの良かった点 |
|---|---|
| メモリ効率 |
gemma-4-26B-A4Bが Peak Mem 13.94GB で動いた |
| Apple Silicon親和性 | MLX形式のモデルをそのまま扱える |
| OpenAI互換API |
mlx_lm.server経由で既存アプリに組み込みやすい |
| MoE 4bitの実用性 | A4B / A3B系は約39 tok/s相当で現実的 |
| 比較用モデル | GGUFとは別系統の出力確認に使える |
特に Peak Mem 13.94GB の
gemma-4-26B-A4Bは魅力的です。Mac Studio 64GBで、RAG、embedding、Qdrant、Webアプリを同居させる構成では、メモリの余裕はそのまま運用の安心感になります。
MLXがまだ弱かった点
一方で、
llama-serverと比べると弱い点もあります。
| 観点 | MLXで気になった点 |
|---|---|
| 最高速 | 今回のMLX最速組は約39 tok/s相当で、前回のllama-server MoE系より低い |
| 計測の見通し |
llama.cppのような詳細timingsが取りづらい |
| cache評価 | prompt cacheの効き方を llama-serverほど明確に分けて見られない |
| Denseモデル | OptiQでもDense系はかなり重く、常用候補にしづらい |
特に、運用上は計測の見通しが大きいです。
llama-serverでは、
prompt eval、
decode、prompt cache後の処理時間を細かく見られます。RAGのボトルネックが検索側なのか、prompt evalなのか、decodeなのかを切り分けやすいです。
MLXでも実用上のwall timeは測れますが、内部timingsまで含めたチューニングのしやすさでは
llama-serverの方がまだ扱いやすいと感じました。
用途別の選び方
今回の結果を運用に落とすなら、次のように使い分けるのがよさそうです。
| 用途 | 候補 | 理由 |
|---|---|---|
| 既存の社内RAG主力 | llama-server + Qwen3.6-35B-A3B-Q4/Q5 | 速度、cache、timingsの見通しが良い |
| MLXで常用する第一候補 | gemma-4-26B-A4B-it-4bit | 13.94GBで速く、文書のまとまりも良い |
| MLXで速度重視 | Qwen3-30B-A3B-Instruct-2507-4bit | 初回wall約38秒、prompt処理も軽い |
| 品質比較用 | gemma-4-31B-it-OptiQ-4bit | 重いが、出力構成の確認に使える |
| Qwen3.6 Dense比較 | Qwen3.6-27B-OptiQ-4bit | no-thinkingなら正常完走。ただし常用には重い |
「とにかく1本に決める」なら、現時点では
llama-server+ GGUF のQwen3.6 MoE系を主力にします。
一方で、「MLXも手元に置いて比較したい」「メモリを抑えて別モデルを動かしたい」という用途なら、
gemma-4-26B-A4B-it-4bitはかなり良い候補です。
注意点
今回の結果は、PDF全文を丸ごとLLMに投げたものではありません。
PDFを登録し、embeddingとQdrantで関連チャンクを検索し、そのRAG文脈をLLMに渡した結果です。
したがって、数値や品質は次の条件に依存します。
- PDFの分割方法
- embeddingモデル
top_k
min_score
- 検索で採用されたチャンク
- promptの長さ
context_size
max_tokens
-
mlx_lm.server
のバージョン - chat template設定
- モデルの変換元と量子化形式
また、今回のMLX指標は
wall_clock_equivalentです。
llama.cppの内部timingsと完全に同じ意味ではありません。
対外文書、顧客通知、品質不具合、補償、リコール、法務表現を含む文書では、
どのモデルであっても人間レビューは必須です。
まとめ
Mac Studio M1 Max 64GB 上で、MLX形式の4モデルを社内RAG文書生成タスクで比較しました。
結果は次の通りです。
-
gemma-4-26B-A4B-it-4bit
は Peak Mem 13.94GB、decode 39.11 tok/s相当で、MLX勢では最もバランスが良い -
Qwen3-30B-A3B-Instruct-2507-4bit
は初回wall約38秒で、速度重視のMLX候補 -
Qwen3.6-27B-OptiQ-4bit
は no-thinkingでは正常完走するが、Dense系として重い -
gemma-4-31B-it-OptiQ-4bit
は品質確認用にはよいが、常用には待ち時間が長い
そして、
この記事の問いである「MLXはllama-serverより良いのか」に対する答えはこうです。
総合では、今回の社内RAG用途ではまだ llama-server の方が良いです。
理由は、生成速度の上限、prompt cache、内部timingsの見通し、既存運用での安定感です。
ただし、MLXは悪くありません。
特に
gemma-4-26B-A4B-it-4bitのようなMoE 4bitモデルは、低メモリで十分速く、
Mac Studio上の社内RAGに組み込む価値があります。
関連記事
本記事は、筆者が所属するクイックイタレート株式会社で検証・運用している社内向けオンプレLLM環境をベースにした事例紹介です。
弊社ではオンプレ LLM 環境の設計・構築・運用のご相談も承っております。
詳細はこちらのページをご覧ください。