GGUF（llama.cpp）vs MLX Round 2：あなたのフィードバックで検証、2つのモデル、5つのランタイム。Ollamaはオーバーヘッドが追加。私の結論。ご意見は？

2週間前に、ここで MLXは私のM1 MaxではGGUFより遅かった と投稿しました。あなたがフィードバックをくれて、MLX向けにおそらく最悪のモデルを選んでいた点を指摘してくれました。壊れたプロンプトキャッシュ（mlx-lm#903）、MLXのハイブリッド注意は最適化できない、そしてbf16に対応していないチップでbf16を使っていた。

そこで、あなたからのほぼすべてのヒントと推奨をもとに検証しました。
成熟した2つのモデル（Gemma 12B QAT、Qwen3 30B-A3B）、5つのランタイム、そしてM1/M2チップ向けにu/bakawolf123 が提案してくれたbf16→fp16の修正。さらに、LM Studioがオーバーヘッドを追加していないか確認するために、llama.cppをソースからコンパイルしました。同じM1 Max 64GBです。

fp16への変換後は、ほとんどのシナリオで差は1桁台です。ですが、それでも「MLXを使うだけでOK」という結論にはなりません。

以下はQwen3 30B-A3B 実効 tok/s（高いほど良い）

Scenario	MLX (bf16)	MLX (fp16)	GGUF Q4_K_M
Creative writing	53.7	52.7	56.1
Doc classification	26.4	32.8	33.7
Ops agent (8 turns)	35.7	38.4	41.7
Prefill stress (8K ctx)	6.0	8.6	7.6

生成速度は基本的にこのモデルとほぼ同率です：GGUFは58 tok/s、MLXは55〜56。パート1の「57 vs 29」はエンジンではなく、モデル側の影響でした。

興味深い：ランタイムはエンジンより重要です。
Qwen3 ops agent（高いほど良い）

Runtime	Engine	eff tok/s
LM Studio	llama.cpp GGUF	41.7
llama.cpp (compiled)	llama.cpp GGUF	41.4
oMLX	MLX	38.0
Ollama	llama.cpp GGUF	26.0 (-37%)

LM Studioは、素のllama.cppと比べてオーバーヘッドを追加しません。Metalサポートで自分でもコンパイルして検証しました。
Ollamaは同じエンジンを動かしていますが、このモデルでは37%遅いです。
両方の記事におけるGGUFのLM Studioとの比較では、一貫して遅いです。私が行った全てのベンチマークでそうでした。Goのラッパーのどこかがコスト高に見えます。

MLX側では、oMLXはマルチターンでLM StudioのMLXより2.2倍速いです。ただしGemma 12Bでもテストしました。こちらではLM Studioのキャッシュは問題なく動作します。面白いことに、このときはoMLXとLM StudioのMLXが似た数値を出しています。つまり、oMLXはMLXの性能一般を改善するのではなく、キャッシュの問題を解決しているということです。それでも、やはりMLXの最良のランタイムではあります。
開発者の皆さんに敬意を表します。よく設計されたソフトウェアです。ただし：まだ安定性のデータがありません。そのため、時間経過で安定性がどう振る舞うかは確信できません。

M1/M2の人向け：bf16の修正：

pip install mlx-lm mlx_lm.convert --hf-path <your-model> --mlx-path <output> --dtype float16 

1分以内で品質の低下はなく、prefillペナルティを40〜70%取り戻します。M3+はネイティブでbf16に対応しているので、ここでは適用されません。

調査中に見つけたのが MLX量子化の品質面の懸念 です。MLXの4-bitとGGUFのQ4_K_Mは、どちらも「4-bit」と言っているにもかかわらず同じものではありません。ただし、この領域にはいくつか動きがあります。

GGUFのK-quantsはセンシティブな層により多くのビットを割り当て、MLXは一様な深さで適用します。llama.cppのプロジェクトでは、7Bモデルにおいて一様なQ4_0とQ4_K_Mの間で4.7倍のパープレキシティ差が測定されています。私はまだ自分でこれを検証していません。ベンチマークしたモデルで、それが実際の出力品質にも現れるのかを確認できると面白そうです。JANG-Qは、MLXに適応型量子化を取り入れる作業を進めています。

最終的に私はこう着地しました：

• LM Studio + GGUF：ほとんどの用途で。より良い量子化、回避策不要、十分な実効速度で、「そのまま動く」安定版。
• Qwen 3.5を使うならoMLX。新しいモデルにはMLXを使い、特にqwen 3.5のようなマルチモーダル（素晴らしい！）や、同じシステムプロンプトでのより長いエージェント会話。体感できる速度向上です。oMLXのキャッシュ層は本当に素晴らしいです。
• Ollamaはスキップ。オーバーヘッドが痛いです。

なお、M2とM4のデータを探しています。
AlexTzkがM3 Maxの結果を提出しました（oMLXは38〜71 eff tok/sにスケール、GPUコア数にほぼ比例）。M2とM4はまだ欠けています。

やりたいなら、ベンチマークを自分でも実施してください

https://github.com/famstack-dev/local-llm-bench 

結果はPull Requestとして貢献してください。私があなたのハードウェアを追加しますし、あなたのユースケースのテストにそれを使うこともできます。ただし貢献する必要はありません。何か動かしてみたなら、結果と発見をコメントしてくれると嬉しいです**。**
このベンチの違いは何でしょう？ 現実的なシナリオを使い、生成だけでなく実効トークン/sを測定します。カスタムシナリオの追加とテストが簡単です。

さて、ベンチマークはここまでにして、実際の問題を解決しに戻りましょう :)

この道のりについての所感？ もう少しヒントやコツは？

また、プロフィールでリンクしているチャンネルでも議論できれば嬉しいです。

全原稿（全チャートと一部の研究データ付き）: famstack.dev/guides/mlx-vs-gguf-part-2-isolating-variables