Apple Silicon で MLX と llama.cpp（GGUF）どちらが速いか 2026年版：tok/sec の見かけと「プロンプト処理込みの実効速度」で選ぶローカルLLMランタイム
Mac でローカルLLMを動かすとき MLX と llama.cpp（GGUF）のどちらを選ぶべきかを、モデルサイズ・コンテキスト長・プロンプト処理込みの実効tok/secで比較。14B未満では MLX が20〜87%速い一方、長文コンテキストやprefill込みでは GGUF が逆転する条件を、M4 Max などの実測ベースで整理します。
- #MLX
- #llama.cpp
- #GGUF
- #Apple Silicon
- #M4 Max
- #ローカルLLM
- #tok/sec
- #プロンプト処理
- #LM Studio
- #Mac
本記事は Amazon.co.jp および各販売店のアフィリエイトリンクを含む場合があります。推奨は性能・コスパ・実機ベンチマーク基準で編集判断しており、提供記事は受け付けていません。詳細は プライバシーポリシー をご覧ください。
結論：Mac でローカルLLMを回すなら、短〜中コンテキストの小型モデルは MLX、長文コンテキスト・大型モデル・クロスプラットフォームは llama.cpp（GGUF）が正解です。MLX は 14B 未満でデコード速度が GGUF 比 +20〜87% 速い一方、27B を超えるとメモリ帯域律速で両者は収束します。さらに注意すべきは、UI が見せる tok/sec は「生成のみ」の値で、長いプロンプトを読ませる prefill（プロンプト処理）を含めた実効速度では GGUF が逆転することがある点です。「表示 tok/sec」ではなく「質問してから答え終わるまでの総時間」で選んでください。
「Mac で LLM を動かすなら MLX が速いらしい」。そう聞いて MLX 版モデルに乗り換えたものの、「思ったより体感が速くならない」と感じた人は少なくないはずです。Search Console でも mac llm mlx、mlx llama.cpp 速い、ollama llama cpp 比較 といったフレームワーク選択クエリが継続的に表示されています。
この記事は、Mac（Apple Silicon）専用ランタイムの MLX と、クロスプラットフォームの定番 llama.cpp（GGUF 形式） を、「見かけの tok/sec」と「プロンプト処理込みの実効速度」の 2 つの軸で比較します。Ollama / LM Studio / vLLM を含むランタイム全体の横断比較は「ローカルLLM ランタイム・ツール比較 2026年版」に、Mac 機種側の選び方は「Mac Studio ローカルLLM 運用ガイド 2026年版」に譲り、ここでは MLX を主役にしたランタイム選択に絞ります。
そもそも MLX と llama.cpp は何が違うのか
両者は「Mac で LLM を動かす」という目的は同じですが、設計思想が違います。
| MLX | llama.cpp（GGUF） | |
|---|---|---|
| 開発元 | Apple | コミュニティ（ggml-org） |
| 対応プラットフォーム | Apple Silicon 専用 | Mac / Windows / Linux / CPU / 各種 GPU |
| 最適化 | Metal / Apple Silicon に特化 | 幅広いハードに汎用最適化 |
| モデル形式 | MLX 形式（mlx-community が HF 配布） | GGUF（K-quant 系が標準） |
| 強み | 小〜中型モデルのデコードが速い | 互換性・長文・省メモリ運用 |
| 入手 | Hugging Face の mlx-community | Hugging Face / 各配布元の GGUF |
MLX は Apple が自社チップ向けに最適化したフレームワークなので、Apple Silicon でのデコード（トークン生成）効率は理論的に有利です。一方 llama.cpp は「どこでも動く」ことを優先した設計で、Mac 以外と環境を揃えたいケースや、メモリをぎりぎりまで切り詰めたいケースで強みが出ます。
軸1：デコード速度（生成 tok/sec）では MLX が速い
まず、よく語られる「MLX は速い」の中身です。これは主にデコード速度＝トークン生成の瞬間速度を指します。
- 14B 未満のモデル：MLX は llama.cpp 比で +20〜87% のデコード速度を出すケースが報告されている
- 27B を超えるモデル：メモリ帯域がボトルネックになり、MLX も llama.cpp も同じ壁に当たって両者が収束する
つまり MLX の優位は「小〜中型モデル」で顕著で、大型モデルになるほど差が消えます。これは、大型モデルでは演算よりメモリ帯域が律速になり、ランタイムの最適化差より「メモリをどれだけ速く読めるか」が支配的になるためです。このメモリ帯域とトークン速度の関係そのものは「メモリ帯域とローカルLLMの tok/sec の関係」で詳しく扱っています。
| モデル規模 | MLX vs llama.cpp（デコード） | 効く要因 |
|---|---|---|
| 〜14B | MLX が +20〜87% | ランタイム最適化（演算効率） |
| 14〜27B | 差が縮小 | 演算と帯域の中間 |
| 27B〜 | ほぼ収束 | メモリ帯域律速 |
ここまでなら「小型モデルは MLX を選べばいい」で終わりそうですが、本当の落とし穴はこの先です。
軸2：プロンプト処理（prefill）込みの実効速度で逆転が起きる
この記事の山場です。MLX のヘッドライン tok/sec は、多くの場合 decode-only（生成のみ） の値です。実際の会話やコーディング支援では、その前に長いプロンプトを読み込む処理（prefill / プロンプト処理） が走り、ここの時間が UI の tok/sec 表示には含まれていないことがあります。
具体例として、独立検証で報告された数字が分かりやすいです。
M1 Max / Qwen3.5-35B / 8.5K コンテキストという条件で、MLX の UI 表示は約 51 tok/s。ところが prefill（8.5K トークンの読み込み）まで含めた実効スループットは約 3 tok/sec まで崩落した。同じ条件で GGUF（llama.cpp）の方が総応答時間が短く、43.4 秒 vs 52.3 秒で GGUF が速かった。
「表示は 51 tok/s なのに、実際は 3 tok/sec 相当」という落差が、「MLX に変えたのに体感が速くならない」の正体です。プロンプト（コンテキスト）が長いほど prefill の比重が増し、デコード速度の優位が打ち消されていきます。プロンプト処理そのもののコストは「ローカルLLM のプロンプト処理（prefill）ベンチマーク」でも掘り下げています。
どんなときに prefill が効くか
| ユースケース | プロンプト長 | prefill の比重 | 有利な側 |
|---|---|---|---|
| 短いチャット | 短い | 小さい | MLX（デコード優位がそのまま出る） |
| 長文要約・RAG | 長い | 大きい | GGUF（prefill 込みで逆転しうる） |
| コーディング支援（長いコード貼付） | 長い | 大きい | GGUF 寄り |
| 反復的な短い質問 | 短い | 小さい | MLX |
ポイントは、ベンチマークの「tok/sec」という一語が、decode-only か prefill 込みかで全く違う数字になるということです。比較するときは「質問してから答え終わるまでの総時間（time-to-last-token）」で見るのが唯一の公平な物差しです。
使い分けの結論
ここまでをまとめると、選択は以下のように整理できます。
| 条件 | おすすめ |
|---|---|
| 小型モデル（〜14B）× 短〜中コンテキスト | MLX |
| 長文コンテキスト・RAG・長いコード貼付 | llama.cpp（GGUF） |
| RAM ギリギリのモデルを省メモリで回す | llama.cpp（GGUF） |
| Mac 以外（Windows/Linux）と環境を揃えたい | llama.cpp（GGUF） |
| とにかく Apple Silicon でデコードを最速化 | MLX（短文前提） |
| 大量並列リクエストを捌きたい | vLLM-mlx（continuous batching） |
補足として、vLLM の MLX 対応（vLLM-mlx） は continuous batching により、M4 Max で最大 525 tok/s（多リクエスト合算）という参考値も出ています。単発の応答速度ではなく「同時に多数のリクエストを捌くサーバ用途」では別の選択肢になります。
実際にどう試すか：LM Studio で両形式を並べる
理屈より自分のユースケースで測るのが確実です。LM Studio は MLX / GGUF を両対応でロードできるので、同じモデルの MLX 版と GGUF 版を入れて、自分が普段投げるのと同じ長さのプロンプトで総応答時間を比べるのが最短の答え合わせです。
- MLX 版モデルは Hugging Face の mlx-community が配布している（多くの人気モデルが MLX 形式で揃う）
- GGUF 版は各配布元から（K-quant 系なら Q4_K_M が標準的な選択）
- 比較は 同じプロンプト・同じコンテキスト長で、最初のトークンが出るまで（prefill）+ 生成完了までの合計で
「ヘッドラインの tok/sec」ではなく「自分の使い方での総時間」で選べば、MLX か GGUF かで迷うことはなくなります。
まとめ：「速い」は条件付き
- デコード（生成）速度：14B 未満は MLX が +20〜87% 速い。27B 超はメモリ帯域律速で収束
- prefill（プロンプト処理）込みの実効速度：長文コンテキストでは GGUF が逆転しうる（UI 表示 51 tok/s が実効 3 tok/sec まで落ちた例）
- 使い分け：短文×小型＝MLX／長文・省メモリ・クロスプラットフォーム＝GGUF
- サーバ用途：vLLM-mlx の continuous batching で多リクエストを捌く選択肢も
- 確認法：LM Studio で MLX/GGUF を両ロードし、自分のプロンプト長で総応答時間を比較
「MLX は速い」は正しいですが、それは「短いプロンプトで小型モデルを生成するとき」という条件付きです。あなたの使い方が長文中心なら、素直に GGUF の方が体感が速い。この見極めが、Mac でのローカルLLM体験を一番大きく左右します。
入手先・関連商品
当サイトは Amazon.co.jp アソシエイト・プログラムに参加予定です。下記リンク経由で購入された場合、紹介料を受け取ることがあります。読者の負担は増えません。リンクは記事評価とは独立しており、編集判断には影響しません。
ローカルLLM 向け Mac（Apple Silicon）
- Mac Studio M4 Max を Amazon.co.jp で見る：本記事のベンチ条件に近い、Mac ローカルLLMの定番
- Mac Studio M3 Ultra を Amazon.co.jp で見る：帯域 819GB/s、70B+ を狙う上位機
- Mac mini M4 Pro を Amazon.co.jp で見る：小型モデル×MLX のコスパ起点
あなたに合うPCを診断する
用途や予算をもう少し細かく入力すると、3つの候補構成を提案します。
→ 診断スタート
関連記事
- ローカルLLM ランタイム・ツール比較 2026年版：Ollama / LM Studio / llama.cpp / vLLM のクロスプラットフォーム横断比較
- Mac Studio ローカルLLM 運用ガイド 2026年版：どの Mac でどのモデルを回すか
- メモリ帯域とローカルLLMの tok/sec の関係 2026年版：なぜ大型モデルで速度が収束するのか