GGUFとMLXをMacで比較｜速度と使い分け

同じMacで同じGGUFモデルを実行する2つの推論アプリでも、速度に37%の差が生じることがあります。形式もモデルも変えず、別のアプリを使っているわけでもありません。この結果を見ると、「GGUFとMLXのどちらを選ぶか」という問いへの答えは簡単に思えます。MLXを選べばよいのです。  

しかし、だからといってあらゆるワークフローで速くなるわけではありません。待ち時間の大半を左右するのは、生成速度ではないからです。 

では、macOSでローカルLLMを高速化するにはどうすればよいのでしょうか。

要点

• 長い出力ではMLXのほうが高速です（250トークン以上の回答、要約）。出力が十分に長くなると、生成速度の優位性が、プリフィルによる開始時の遅れを上回ります
• 短いタスクではGGUFのほうが高速です（Q&A、ツール呼び出し、分類）。M5 Maxの同じランタイムで分類を実行したところ、GGUFは1.0秒、MLXは2.2秒で完了しました
• 同じ「4ビット」でも品質は同じではありません。ファイルサイズがほぼ同じでも、GGUF Q4_K_Mのパープレキシティの悪化は、MLXの均一4ビット量子化の4.7分の1です
• M1/M2では、MLXの重みをbf16からfp16に変換してください。品質を損なわずに、プリフィルの速度低下を40-70%取り戻せます。または、Atomic ChatでGGUFを使えば、変換は不要です。
• 形式よりもランタイムのほうが重要です。同じGGUFエンジンでも、OllamaはLM Studioより37%低速です。MLXでは、oMLXがLM Studioの2.2倍高速です
• Atomic Chatは、標準のllama.cppよりも最大40%高速にGGUFを実行します。MTP（Multi-Token Prediction）によって実現しています ‍
• M3以降で日常的な軽い処理を行う場合、形式間の差は小さいため、入手できるモデルを選んでください

GGUFとMLX：主な違い

GGUFとMLXは、ローカルLLMをパッケージ化して実行するための2つの方法です。 

GGUF： 

• llama.cppプロジェクトが開発したファイル形式で、量子化されたモデルの重みを、持ち運び可能な単一のバイナリファイルに格納します。  

• あらゆるハードウェアで動作します。Mac、Linux、Windows、CPUのみのマシン、クラウドGPUに対応します。 

MLX： 

• Apple Silicon専用に構築された、Appleのオープンソース機械学習フレームワークです。
• GGUFのようなファイル形式ではありません。mlx_lm.convertでモデルを変換すると、safetensorsの分割ファイル、設定ファイル、トークナイザーファイルを含むディレクトリが生成されます。 
• macOSでのみ動作します。

「MLXモデル」とは、このフレームワークで実行できるように変換され、Mシリーズチップのユニファイドメモリアーキテクチャを活用するモデルを指します。 

ユーザーにとっての違いは、速度と互換性です。GGUFはどこでも動作し、短いタスクでは読み込みが高速です。MLXは長い出力でのトークン生成が高速ですが、Apple Siliconでしか動作せず、その優位性が得られるのも適切なランタイムを選んだ場合だけです。

GGUFかMLXかという選択よりも、推論アプリのほうが重要ですか？

ある程度は、そのとおりです。M1 Max 64GBで同じハードウェアとモデルを使って5つのランタイムを比較すると、ランタイムは形式に劣らないほど速度を左右します。 

このデータでは、3つの点が際立っています。

• GGUFの速度差は37%です。LM Studioとllama.cpp単体は41.7対41.4で、差は誤差の範囲内です。Ollamaは同じエンジンを使っていながら、37%低速です。GGUFファイルも基盤となるコードも同じで、違うのはアプリです。
• MLXの速度差は2.2倍です。LM StudioのMLXランタイムは実効17.0 tok/sに達します。oMLXは、同じハードウェアと同じモデルで38.0に達します。この差は形式ではなく、ランタイムのオーバーヘッドによるものです。
• 「MLXはOllamaの3倍高速」という主張は、この数値では裏付けられません。この比較は都合のよい条件だけを選び、最速のMLXランタイム（oMLX、38.0）を、最も遅いGGUFランタイム（Ollama、26.0）と比較しています。38.0 ÷ 26.0は約1.46倍です。ランタイムの条件をそろえれば、差ははるかに小さくなります。

Ollamaには、複数ターンの利用でさらに問題があります。プロンプトキャッシュが正しく機能しません。各ターンで会話履歴全体を最初から処理し直します。エージェントとの会話が5ターン目になる頃には、Ollamaは、キャッシュが適切に機能するランタイムなら完全に省略できるコンテキストを計算しています。

形式を切り替えずにllama.cppを40%高速化する方法

デフォルトでは、llama.cppは1回の順伝播で1トークンを生成するため、ハードウェアにかかわらず、生成速度はモデルが1回の完全な順伝播をどれだけ速く実行できるかによって制限されます。

Atomic Chat（Terminalを使わずにローカルLLMをすばやくセットアップできる実行アプリ）は、Multi-Token Prediction（MTP）でこれに対処します。モデルが複数のトークンをまとめて仮生成し、1ステップで検証します。 

MacBook Pro M5 Maxでは、Gemma 26Bが40%高速に動作し、Qwen 3.6 27Bは仮生成トークンの受理率90%で+40%を達成しました。全体を通してGGUF形式は同じで、変えたのはランタイムだけです。

GGUFとMLX：独自テストを実施しました

独立したデータを得るため、MacBook Pro M5 Max 64GB上のAtomic Chatで、Qwen3-30B-A3Bを両方の形式で実行しました。どちらも同じランタイムです。 

時間は生成カウンターではなく、送信から最後のトークンまでの実経過時間で測定しました。M5 Maxはbf16をネイティブでサポートしているため、MLXは、M1とM2で速度低下を招くソフトウェアエミュレーションなしで動作します。それでもプリフィルの差は現れました。

M5 Maxでの実経過時間テスト：4種類のプロンプトでGGUFとMLXを比較

生成速度はGGUFが131 tok/s、MLXが125 tok/sと近い値でした。2つの短いプロンプトでは、どちらもGGUFのほうが早く完了し、その差はプリフィルによるものです。コード生成では、両形式は同等です。説明のプロンプトではMLXが有利でしたが、出力の長さに違いがあったため、この数値は確定的な結果ではなく、傾向を示すものとして捉えてください。

この傾向は、先ほどのベンチマークと一致します。短いタスクではGGUF、長いタスクではMLXが優位で、この差はハードウェアに左右されにくいため、M5 Max（Appleのチップで最もMLX向けに最適化されたもの）でも、短いタスクの結果は逆転しません。

MLXはtok/sが高いのに、なぜ遅く感じることがあるのか

上記のデータには、一貫した傾向が見られます。短いタスクでは、生成速度が同じでも実経過時間が異なります。その理由は、推論には2つの段階があり、アプリのカウンターはその一方しか測定していないことにあります。

最初に行われるのがプリフィルです。モデルは出力を生成する前に、入力全体を読み込みます。最初の単語が表示されるまでの待ち時間がプリフィルです。次に生成が行われ、1トークンずつ出力されます。UIのtok/sカウンターは、この第2段階だけを測定しています。

MLXは生成が高速ですが、プリフィルは低速です。 

• アプリのtok/sカウンターには、プリフィルが反映されません。最初のトークンが表示されて初めて計測が始まります。
• コンテキストが655トークンの場合、出力が始まるまでのプリフィルにMLXは6.9秒、GGUFは2.9秒かかります。
• 生成速度がほぼ同じでも、短いタスクではGGUFのほうが早く完了します。タスクの大半をプリフィルが占めるためです。
• 実効tok/s = 出力トークン数 ÷ 合計実経過時間。これが体感に合う数値です。

文書分類やツール呼び出しのような短い応答では、MLXの生成速度の優位性が役立つ前に、タスクがほぼ終わってしまいます。

実効tok/sは、プリフィルを含む合計時間を計算に使います。コンテキストが8,500トークンの場合、MLXは何も生成しないうちに入力の読み込みに49秒を費やしますが、生成カウンターには57 tok/sと表示されます。

形式の選択が速度に影響するのはどのような場合か

モデルサイズ：22Bという転換点

MLXの速度面の優位性は、モデルサイズによって変わります。ある開発者が、M2 Ultra 192GB上のLM Studioで複数のモデルをテストしました。

• Qwen 2.5 0.5B 4-bit：GGUFは79 tok/s、MLXは317 tok/s（MLXが4倍高速）
• Mistral Small 22B 8-bit：GGUFは25.01、MLXは25.96（同等）
• Qwen 2.5 72B 8-bit：GGUFは7.68、MLXは0.42 tok/s（MLXの速度は18分の1）

LM Studioでは、パラメータ数が約22Bを超えると、MLXはCPUでの実行にフォールバックします。この時点で、モデルの層がGPUからアクセス可能なメモリに収まらなくなります。GGUFは-ngl フラグでこれに対処でき、GPUで実行する層数を手動で設定できます。MLXには、これに相当する制御機能がありません。

ただし、22Bという上限はLM Studioの問題であり、MLX自体の問題ではありません。M4 Max 128GBでは、別のMLXランタイム（vllm-mlx）が、パラメータ数30Bでもllama.cppに対して21%の速度優位性を維持しています。どの形式を使うかよりも、どのランタイムを使うかのほうが重要です。

チップの世代：M1とM2におけるbf16の問題

Hugging Face上のMLXモデルの多くは、bf16の重みで提供されています。M1とM2はbf16をネイティブでサポートしていないため、プリフィル中はチップがソフトウェアエミュレーションで処理します。GGUFはfp16を使用し、どちらのチップでもハードウェア本来の速度で動作します。1回の変換で、M1/M2におけるbf16のプリフィルの速度低下を解消できます。

Gemma 3 12Bを8Kのコンテキスト長で実行した場合、fp16への変換後、プリフィルは114.4秒から68.9秒に短縮されました。品質の低下はありません。M3以降ではbf16がネイティブで動作するため、変換は不要です。

Atomic Chatを使っている場合は、TurboQuantで量子化されたGGUFモデルに切り替えることで、この問題を完全に回避できます。GGUFはfp16の重みを使用し、M1とM2でも手動変換なしでハードウェア本来の速度で動作します。

量子化の品質：Q4_K_Mと均一4ビット量子化の比較

GGUF Q4_K_Mは、精度に敏感な重みの層に多くのビットを割り当て、それ以外ではビット数を減らすことで、重みあたり平均4.83ビットにしています。MLXの4ビット量子化は、すべての層に同じビット数を一律に適用します。llama.cppプロジェクトは、7Bモデルでパープレキシティへの影響を測定しました。

GGUFとMLX：選び方の早見表

GGUFを優先する場合：

• 短い出力：分類、Q&A、ツール呼び出し。ランタイムにかかわらず、プリフィルの優位性が維持されます
• 大規模モデル：-nglでGPUとCPUに層を分配し、64GBのMacで70Bモデルを実行できます
• 上記のfp16変換を行っていないM1/M2
• リリースから数時間以内にモデルが必要な場合

MLXを優先する場合：

• 適切なランタイム（oMLXまたはmlx-lm）での長い出力：250トークン以上の応答では、生成速度に実際の優位性があります
• 14B未満の小規模モデル：M4ハードウェアでの生成が20-87%高速 
• RAMの制約：同等の量子化では、GGUFよりメモリ使用量が7-13%少なくなります
• デバイス上でのファインチューニング：MLXはmlx_lm.loraを通じて、ローカルでのLoRA/QLoRAをサポートします。llama.cppは推論専用です。

GGUFを高速に実行する方法：標準のllama.cppよりも高速なローカル実行を、Atomic Chatで試す

Atomic ChatはGGUF、MLX、ONNXをサポートしています。両形式は同じモデルブラウザーに表示され、ほかの設定を変えずに切り替えられます。

標準のllama.cppとの違いを生むのは、次の機能です。

• TurboQuant：同じファイルサイズで、より高い品質を維持する独自のGGUF量子化
• MTP（Multi-Token Prediction）：1回の順伝播で複数のトークンを仮生成するようにパッチを適用したllama.cpp。M5 Maxで+40%を実測
• 手動変換が不要：GGUFはどのMシリーズチップでもfp16をネイティブで実行でき、bf16の問題を回避する対処は不要です

エージェントのワークフローでは、システムプロンプト、ツールのスキーマ、会話履歴、各ツール応答に含まれるJSONによって、コンテキストが急速に増えていきます。MLXのプリフィルの負荷が最も積み重なるのは、こうした場面です。M1/M2では、GGUFから始めるのがより無難です。M4/M5では形式間の差が十分に小さいため、実際のプロンプトの傾向によって結果が決まります。

よくある質問

MLXでGGUFファイルを実行できますか？

いいえ。両者は異なるランタイムを使用し、それぞれ別にダウンロードします。GGUFファイルは、llama.cpp互換のモデルページ（Hugging Faceや、.ggufファイルをホストするその他の場所）から入手できます。MLXモデルは、Hugging Faceのmlx-communityから入手できます。実行時に形式間の互換性はありません。

MacではMLXモデルのほうがGGUFより高速ですか？

生成速度については、はい。Apple Siliconでは、一般にMLXのほうが高速です。短いタスクの合計実経過時間については、そうでないことがよくあります。プリフィル（出力を生成する前に入力を読み込む処理）はMLXのほうが遅く、短いタスクでは待ち時間の大半をプリフィルが占めます。結果は、タスクの長さ、モデルサイズ、チップの世代、使用するランタイムによって異なります。

OllamaはLM Studioと同じエンジンを使っているのに、なぜ遅いのですか？

Ollamaはllama.cppをラップし、Goサーバーを介して動作させるため、リクエストごとにオーバーヘッドが生じます。このオーバーヘッドは一貫しており、M1 MaxではGemma 12BとQwen3 30B-A3Bのどちらでも、llama.cpp単体より37%低速です。さらに、Ollamaのプロンプトキャッシュは複数ターンの会話で正しく機能しないため、履歴をキャッシュせず、各ターンで履歴全体を最初から処理し直します。ターンが増えるたびに、性能差は広がります。

tok/sと実効tok/sの違いは何ですか？

UIのtok/sは生成速度のみを測定します。つまり、トークンが画面に順次表示される段階の速度です。実効tok/s = 出力トークン数 / プリフィルを含む合計実経過時間です。コンテキストが長い短時間のタスクでは、この2つの数値に10倍以上の差が生じることがあります。生成速度が57 tok/sと表示されるモデルでも、コンテキストが8,500トークンになると、実効スループットは3 tok/sになることがあります。何も生成しないうちに、プリフィルに49秒を費やしたためです。

GGUF Q4_K_Mの品質はMLXの4ビット量子化と同じですか？

いいえ。GGUF Q4_K_Mは、精度が最も重要な層に多くのビットを割り当てることで、重みあたり平均4.83ビットにしています。MLXの4ビット量子化は均一です。ファイルサイズがほぼ同じでも、パープレキシティには4.7倍の差があります（7Bモデルで3.80 GB対3.50 GB）。大規模モデル（30B以上）では、ベンチマークにこの差はほとんど現れません。8B未満の小規模モデルでは、特にコーディングタスクで、出力品質に差が現れます。

M1/M2ではMLXの重みをbf16からfp16に変換すべきですか？

はい。MLXモデルの多くはbf16の重みで提供されており、M1とM2はプリフィル中にこれをソフトウェアでエミュレートします。実行前にfp16へ変換する作業は1分未満で済み、追加のコストなしでプリフィルの速度低下を40-70%取り戻せます。mlx_lm.convert --dtype float16を実行し、ローカルのモデルディレクトリを指定してください。M3以降のチップはbf16をネイティブでサポートしているため、変換は不要です。

おわりに

形式をめぐる議論は、要点を見失っています。同じMacで同一のGGUFファイルを実行する2つのアプリでも、速度に37%の差があります。LM StudioのMLXランタイムは、同じモデルとハードウェアでoMLXの2.2分の1の速度です。ランタイムの条件をそろえると、形式間の差は小さくなり、M4/M5ではさらに縮まります。

まずランタイムを選んでください。次に、タスクの長さとモデルサイズに基づいて形式を選びます。M1/M2での短いエージェントタスクでは、GGUFを標準にするのがより無難です。新しいハードウェアで長い生成を行う場合は、MLXを適切に扱えるランタイムでテストしてください。

Atomic Chatでは、両形式を同じモデルブラウザーから利用でき、ワークフローをさらに高速化するTurboQuantとMTPもすでに有効になっています。

→ Atomic ChatでローカルLLMを高速に実行

‍