オンプレLLMで社内文書を書き分ける - MLX no-thinkingモデルはllama-serverより良いのか？

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種類の文書を書き分けさせます。

1. プレスリリース用文面
2. BtoB 顧客への個別通知文
3. 社内向け是正処置報告（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 環境の設計・構築・運用のご相談も承っております。
詳細はこちらのページをご覧ください。