MLX vs llama.cpp：Apple Silicon でハードウェアに近いのはどちら？

System Boundary：本記事の結論の適用範囲と境界

境界のある結論は境界のない説明より信頼できる。本記事の MLX vs llama.cpp の性能と技術選定に関するすべての結論は、以下の明確な条件下でのみ成立する：

本記事の結論はNVIDIA / AMD GPUの環境には適用しない——それはCUDA vs ROCmの議論領域であり、Apple Siliconのユニファイドメモリアーキテクチャとは無関係だ。

キー用語定義：Metalディスパッチ · カーネルフュージョン · ユニファイドメモリ · GGUF vs MLXフォーマット

後続の技術的内容を読む前に、いくつかのコア概念を整理する。これらは Apple Silicon LLM推論の領域で最も混同されやすい用語だ。

Metalディスパッチ（Metal compute dispatch）

CPUがApple Silicon GPUに1つのコンピュートカーネルをサブミットする最小単位。各ディスパッチにはCPU-GPU間の同期確認が必要で、約1–3 μsのスケジューリングオーバーヘッドが発生する。ディスパッチ回数が多いほど、CPUがGPUを待つ累積オーバーヘッドが大きくなる。

カーネルフュージョン（kernel fusion）

複数の独立したオペレーター（matmul → bias add → activationなど）を一つのGPUカーネルとして実行するよう結合し、ディスパッチ回数と中間結果のグローバルメモリ読み書きを削減する。MLXはlazy evaluationによって自動的にカーネルフュージョンを行う；llama.cppは手書きのフュージョンカーネル（flash attentionなど）に依存し、カバー範囲は限られる。

ユニファイドメモリ（Unified memory、Apple Silicon）

Apple SiliconのCPUとGPUは同一の物理メモリを共有しており、独立したVRAMは存在しない。モデルの重みをロード後、CPU↔GPU間のコピーは不要——これがMac上のLLM推論のハードウェア優位性の根拠だ。MLXとllama.cppのMetalバックエンドはどちらも自動的にユニファイドメモリを活用するが、MLXのメモリアロケーターはこのモデルにより近い設計だ。

GGUF（llama.cpp量化フォーマット）

llama.cppが使用するモデル量化フォーマットで、Q2_KからQ8_0まで複数の精度をサポート。モデルファイルは .gguf 形式でHugging Faceから直接ダウンロードできる。OllamaはGGUFでモデルを管理し、MLXフォーマットとは非互換だ。

MLXフォーマット（mlx-community量化フォーマット）

MLXが使用するモデルフォーマットで、safetensors + MLX量化メタデータをベースとする。mlx_lm.convert または mlx-community から取得できる。量化カーネルはMetalシェーダーに直接バインドされており、GGUFとは完全に非互換で、同一の基盤モデルには別途変換が必要だ。

MLX vs llama.cpp アーキテクチャ概要：Apple Silicon推論フレームワーク完全比較

詳細に入る前に、まず一覧表で全体像を把握しよう。mlx vs llama.cppの根本的な分岐は設計目標にある：一方はApple専用の極限最適化、もう一方はクロスプラットフォームの移植性だ。

最後の2行が技術選定を決定する；tok/sの差異は § 性能差の真の原因 を参照、エージェントランタイムの意思決定には関与しない。

Apple Silicon LLM推論スタックモデル（2026）

上の比較表を4層の分業モデルに変換すると、本記事のすべての結論を理解するための最もシンプルなフレームワークになる：

┌─────────────────────────────────────────────────┐
│            Application Layer                    │
│   Claude Code  ·  Cursor  ·  Open WebUI         │
├─────────────────────────────────────────────────┤
│            Runtime Layer                        │
│   Ollama (llama.cpp)  │  FastAPI (MLX wrapper)  │
│   ✅ 推奨エージェントパス │  ⚠️ 自作、エンジニアリングコスト高 │
├─────────────────────────────────────────────────┤
│            Compute Layer                        │
│   ggml-metal (per-op) │  MLX (graph fusion)     │
│   クロスプラットフォーム、プリコンパイル │  Apple専用、JIT特化 │
├─────────────────────────────────────────────────┤
│            Hardware Layer                       │
│       Apple Silicon Unified Memory              │
│   CPU + GPU 共有物理メモリ · ゼロコピー · 高帯域幅  │
└─────────────────────────────────────────────────┘

重要な結論：技術選定はRuntimeレイヤーでのみ行われる。Computeレイヤー（MLX vs ggml-metal）の性能差はRuntimeレイヤーの選択に影響しない——両者は異なるレイヤーを担当しており、互いに代替するものではない。

コアの差異：Metalディスパッチ回数（480 vs 160）——Apple Silicon推論性能の源泉

本記事で最も覚えておく価値のある数字がこれだ。ディスパッチ回数の差を理解すれば、MLX vs llama.cppの性能差の根源が分かる。

7B transformerモデルの場合、1トークン生成ごとに32層のforward passを1回通る必要がある。各層にはQKV projection、attention score、softmax、output projection、FFN gate、FFN up/down、RMS Norm、RoPEなどのオペレーターが含まれる：

llama.cpp（per-op dispatch）：32層 × ~15オペレーター/層 ≈ 480回のMetalディスパッチ
MLX（lazy graph fusion後）：32層 × ~4–5 fusion block/層 ≈ 128–160回のMetalディスパッチ

各Metalディスパッチは一つのCPU-GPU同期ポイントだ：CPUは次のオペレーターのカーネル呼び出しを開始する前に、GPUがコマンドバッファをエンキューしたことを確認するまで待機しなければならない。GPUのコンピュート時間が短い（小batch推論）場合、ディスパッチオーバーヘッドがボトルネックになる。MLXのlazy evaluationは複数のオペレーターを一つのディスパッチにフュージョンし、この同期コストを直接回避する。

Token Latency分解モデル（Dispatch Cost Model）

1トークンの生成遅延を3つの定量化可能な成分に分解する：

Token latency ≈
  dispatch_count × cpu_sync_cost     ← ディスパッチオーバーヘッド（フレームワーク差の源泉）
  + gpu_compute_time                 ← GPU実際演算能力（帯域幅 / 演算能力bound）
  + memory_bandwidth_time            ← 重みの転送時間（物理的な上限）

batch=1、7Bモデル、M4 Mac Mini 16GBでの典型的な分布：

上記は近似推定値（batch=1、7B Q4_K_M、M4 16GB）。memory_bandwidth_timeが決定的な支配成分であり、これがMLXが帯域幅飽和時に優位性がほぼゼロになる理由だ。

なぜMLXが誕生したか：Apple Silicon専用推論フレームワークの設計起点

2023年末、Appleの機械学習研究チームが MLX をオープンソース化した。その設計動機は他と異なっていた——クロスプラットフォームのためではなく、一種のハードウェアを極限まで活用するためだ。

MLX登場以前、Apple Silicon上のLLM推論は以下に依存していた：

• Core ML / MPS：Appleの公式推論スタック、モデルフォーマットがクローズドで研究者には不向き
• llama.cpp + Metal：コミュニティの主力だが、ggmlはCUDAの世界向けに設計されており、クロスプラットフォームの抽象化オーバーヘッドを伴う
• PyTorch + MPSバックエンド：MPSのオペレーターカバレッジが不完全で、推論速度がApple Siliconを十分に活用できていない

Appleエンジニアの判断：ユニファイドメモリ + 高帯域幅バス + Metal GPUの組み合わせを真に活用するには、ゼロからApple Silicon向けに設計された配列計算フレームワークが必要だ。

llama.cppのアーキテクチャ：ggmlマルチプラットフォーム抽象化 + llama.cpp Metalバックエンド + GGUF量化

llama.cppはGeorgi Gerganovによって2023年3月に公開され、目標は純粋なC/C++でコンシューマーハードウェア上でLLaMAを動かすことで、移植性が第一優先事項だ。

ggml：汎用テンソルバックエンド

llama.cppのコアは ggml——バックエンドプラグインで複数のハードウェアをサポートする軽量Cテンソルライブラリだ：

メリットは一つのコードですべてのプラットフォームで動くこと；デメリットは各バックエンドが汎用的な適応であり、特定のハードウェアへの深い最適化ができず、抽象化レイヤーによるディスパッチオーバーヘッドが発生することだ。

Metalバックエンド（ggml-metal）とプリコンパイルカーネル

Apple Silicon上では、llama.cppは ggml-metal.metal——プリコンパイル済みのMetalシェーダーファイルを有効化する。これには以下が含まれる：

• 行列乗算：Q4_K、Q8_0などのGGUF量化フォーマットに対してそれぞれ専用カーネルを実装
• Softmax、RoPE、RMS Norm：各オペレーター独立カーネル
• KV cacheオペレーション：メモリビューの再利用でコピーを回避

重要な制限：カーネルはプリコンパイル固定で、実行時にテンソル形状に合わせて再最適化されない。シーケンス長やbatch sizeが変わっても、カーネルのパラメーターはMetalバッファ経由で渡されるが、カーネル自体は変わらない——これがMLXの実行時特化が有利に立てる箇所だ。

GGUF量化フォーマット

llama.cppは GGUF を使用し、量化精度はQ2_K（極圧縮）からQ8_0（fp16に近い）まで様々だ。各量化フォーマットはMetalカーネルに対応する実装を持っており、Apple Silicon上でのパフォーマンスが悪くない理由だ——ただしこれは量化フォーマットが増えるたびにカーネルのメンテナンスが必要になることも意味する。

MLXのアーキテクチャ：lazy evaluation + runtime JIT kernel + Apple Siliconユニファイドメモリ

MLXとllama.cppの根本的な差異は抽象化レイヤーの位置にある：llama.cppのMetalは「プラグインバックエンド」だが、MLXの計算グラフ全体は設計当初からMetalのセマンティクスの上に存在している。

Lazy Evaluation + 計算グラフフュージョン

1. PythonコードがMLXのオペレーターを呼び出すとき、即座には実行されず、計算グラフノードを記録するだけだ
2. mx.eval() を呼び出した時点で、フレームワークがグラフ全体を解析する
3. 隣接するフュージョン可能なオペレーター（matmul + bias + activationなど）が一回のMetalディスパッチにマージされる
4. 生成されたMetal compute shaderは実行時にコンパイルされてキャッシュされ、その後再利用される

ユニファイドメモリの深い活用

• すべてのテンソルはユニファイドメモリプールに割り当てられ、CPUとGPUが同一の物理アドレスを共有
• 「VRAM」の概念が存在せず、モデルの重みをロード後GPUが直接読み取り、cudaMemcpy相当の操作が不要
• Metal bufferとMLX配列の底層は同じポインターを持ち、ゼロコピーで引数を渡す

llama.cppのMetalバックエンドも同様にユニファイドメモリを活用する（これはApple Siliconのハードウェア特性で、すべてのMetalプログラムが自動的に得る）が、ggmlのメモリアロケーターはこのために設計されておらず、余分なアライメントと割り当てロジックが存在する。

GGUF vs MLX量化フォーマット：非互換の二つのエコシステム

MLXは safetensors + MLX量化メタデータを使用し、GGUFとは完全に非互換だ。同一の基盤モデルには別途変換が必要だ：

• llama.cpp用：HuggingFaceからダウンロード → convert.pyでGGUFに変換してから量化
• MLX用：mlx_lm.convertで変換、または mlx-community から変換済みバージョンを直接取得

量化ビット幅は4ビット、8ビット、混合精度をサポートし、オペレーターの実装はMetalシェーダーと深く連携している——これがMLXの量化デコードパスがGGUFより短い根本的な理由だ。

MLX vs llama.cpp 性能差の真の原因：ディスパッチ回数 vs メモリ帯域幅

これは mlxベンチマークで最も誤解されやすい部分だ。MLXの速度優位性はより優れた行列乗算アルゴリズムからではなく、3つの定量化可能なエンジニアリング要因から来ている：

1. ディスパッチフュージョン：CPU-GPU同期を3分の1に削減

§ コアの差異で述べたように、MLXは1トークンあたりのMetalディスパッチを約480回から160回に削減する。これはbatch=1、短いシーケンスで最も効果が大きい——GPUのコンピュート時間が短く、CPUのスケジューリングオーバーヘッドの割合が高い。

2. 実行時カーネル特化：特定のテンソル形状に最適化

MLXは特定の形状の計算を初回実行時にMetalシェーダーをコンパイルし、具体的な行列次元に合わせてtile sizeとworkgroupサイズを調整できる。llama.cppのプリコンパイルカーネルは保守的な汎用パラメーターを使用し、非標準のシーケンス長への適応性が低い。

3. 量化デコードパスが短い

llama.cppはマルチプラットフォームをサポートするため、量化デコード（dequant）にはCPUフォールバックパスとの互換性が必要だ；MLXの量化カーネルはMetalを唯一のターゲットとして直接設計されており、デコード + 行列乗算を同一のシェーダー内で完結できるため、グローバルメモリの読み書きが削減される。

実測区間参考

以下のデータはMacstripe Lab、Llama-3.1-8B / Q4_K_M、batch=1、2026年6月計測。傾向の参考として提示し、購入や技術選定の根拠としない。

傾向：メモリが充裕なほど、モデルが大きいほど、MLXの優位性が顕著になる。大きなモデルのforward pass GPUコンピュート時間が長くなり、ディスパッチフュージョンの絶対的な効果が大きくなるためだ；16GBで7Bを実行する場合、帯域幅がすでにボトルネックとなり、フュージョンの効果が希薄になる。

Performance Convergence Model（性能収束図）

上の表の傾向を可視化する：MLXの性能優位性がメモリ容量とともにどのように増加し、帯域幅飽和点でどのようにゼロになるか：

  MLX advantage
  (tok/s delta)
  │
  +12% │                                        ● 48GB (14B)
       │                                   ·
   +8% │                              ·
       │                         ·
   +5% │                    ● 24GB (7B–14B)
       │               ·
   +3% │          ● 16GB (7B)
       │
    0% │━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━  ← memory bandwidth ceiling
       │   (swap)  (swap)
  -∞% │     ↓ スワップ発生時は両者同時に崩壊
       │
       └────────────────────────────────────────────
              16GB       24GB       48GB       メモリ容量

図の重要な意味：メモリ容量が曲線のどこに位置するかを決定する。16GB → 24GBへのアップグレードによる効果（フレームワーク変更では得られない）は、MLX vs llama.cppの3%–12%の差をはるかに上回る。

なぜほとんどの場面でmlxベンチマークの差が≈0なのか：メモリ帯域幅こそが天井

すべての場面でMLXの優位性が見られるわけではない。これは本記事で最も重要な「反直感的な価値ポイント」だ：

メモリ帯域幅の飽和：フレームワークの差が物理的な制限で平坦化される

batch=1推論の性能上限は重みの転送帯域幅であり、GPUの演算能力ではない。1トークン生成ごとにすべての層の重みを一度読み取る必要がある（7B Q4 ≈ 4GBのデータ移動）。M4のメモリ帯域幅は約120GB/s（16GB版）で、この物理的な上限がtok/sの上界を決定する。MLXもllama.cppもこれを突破できない——帯域幅飽和時には両者が収束する。

長いコンテキストのprefill：GPUの演算能力がボトルネックになり、ディスパッチオーバーヘッドの割合はゼロに近づく

prefill（長いプロンプトの処理）は計算集約的な操作で、GPUの使用率はほぼ100%に達する。2048トークンのプロンプトのprefill時間は、両者の差は通常5%未満だ。

小さなモデル（≤3B）：絶対的なコンピュート時間が短すぎる

3B Q4の重みは約2GBしかなく、1回のforward pass GPUの時間は約5–10msだ。ディスパッチフュージョンで節約できる0.3–1 msの割合は上がるが、絶対値が小さすぎてユーザーには気付かれない。

高精度量化（Q8_0 / fp16）：帯域幅がより早く飽和する

精度が高いほど重みが大きく、帯域幅がより早くボトルネックになる。Q8モデルは16GBのマシンではほぼ確実にスワップが発生し、その場合にフレームワークの差を論じても意味がない。

Ollama vs MLX 技術選定：エージェントランタイムがtok/sを気にしない理由

MLXがハードウェアに近いなら、なぜClaude Codeの推奨スタックはOllama（llama.cpp）なのか？それは二つの異なる次元の問題だからだ。

HTTPサーバーこそが決定変数

Ollamaはllama.cppの上に完全な推論サービスエンジニアリングを提供する：

• すぐに使えるHTTP推論サービス（:11434、OpenAI互換API）——Claude Codeが直接接続、ゼロ設定
• モデルライフサイクル管理（ollama pull / rm、未使用のモデルを自動アンロード）
• 複数リクエストの並列スケジューリング（複数のClaude Codeウィンドウが同一モデルインスタンスを共有、重複ロードなし）
• チームLAN共有（ollama serve --host 0.0.0.0、全員が同一の:11434に接続）

MLXにはこれらがない。MLXでClaude Codeに接続するには：FastAPIゲートウェイの自作 → モデルロード/アンロードロジックの実装 → 並列リクエストキューの処理 → OpenAI API互換レイヤーのメンテナンスが必要だ。これは完全な推論サービスエンジニアリングであり、コマンド一つで済む話ではない。

エージェントのツールループでtok/sの差は総遅延の5%未満

エージェントのツールループでは、Claude Codeの各呼び出しにはpromptの組み立て → HTTPリクエスト → レスポンスの待機 → ツール呼び出しの解析 → ツールの実行 → 次のラウンド、が含まれる。遅延の分布：

エージェント体験の決定変数はメモリ容量とモデルサイズだ。フレームワークの差はHTTPレイヤーとツール実行時間によって完全に埋没する。

Ollama vs MLXのエンジニアリング境界

それぞれのエンジニアリング境界を明確にすれば、混同することはなくなる：

• Ollama（llama.cpp）：HTTPランタイムレイヤー、「どうやって接続するか」の問題を解決
• MLX：コンピュートレイヤーのツール、「Pythonでどう速く動かすか」の問題を解決
• 両者は排他的ではない：同一のMacでMLXでベンチマークを行いながら、同時にOllamaがClaude Codeにサービスを提供できる

→ Ollama vs MLX 技術選定の完全なロジック：Ollama vs MLX：Claude Codeのローカルモデルはどちらを選ぶ？
→ M4 Pro上でのMLXデプロイ実践：Apple Silicon M4 Pro ローカルLLM運用ガイド：実測とMLXデプロイ

MLXとllama.cppのどちらを選ぶべきか？（30秒意思決定ガイド）

実際のユースケースに基づいて選択する。「どちらが絶対的に優れている」という答えは存在しない：

Apple Silicon LLM推論結論モデル：引用可能な3つのルール（mac m4 llm inference speed）

本記事のすべての結論を再利用・引用可能な判断フレームワークに圧縮する：

フレームワークの最適化で改善できるのは5%–15%、メモリ容量が85%を決定する。
MLX vs llama.cppに関するすべての議論は、最終的にこの一文に帰結する。

関連質問：Apple Silicon推論の技術選定でよく検索されること

MLXとllama.cpp、どちらがローカルデプロイに適しているか？

「デプロイ」の意味次第だ。推論サービスのデプロイ（Claude Code / Cursor / 自作APIに使用）なら、llama.cpp + Ollamaが適している——すぐに使えるHTTPサーバー、モデル管理が充実している。研究環境のデプロイ（新モデルのテスト、ベンチマーク、Pythonスクリプトの作成）なら、MLXが適している——ハードウェアに近く、PythonインターフェースがフレキシブルＤ。

Apple Silicon上でLLM推論にCUDAを使わないのはなぜか？

Apple SiliconにはNVIDIA GPUがなく、CUDAをサポートしていない。AppleのGPUは Metal APIで呼び出し、ユニファイドメモリアーキテクチャによりCPUとGPUが同一の物理メモリプールを共有する——NVIDIAの独立VRAMモデルとは完全に異なる。MLXとllama.cppはどちらもMetalをベースとし、VRAMではなくユニファイドメモリを活用している。

GGUFとMLX量化フォーマットの違いは？

両者は非互換で、それぞれ独立した量化エコシステムだ。GGUF（llama.cpp）はQ2_KからQ8_0まで複数の精度をサポートし、ggml-metalカーネルに専用の実装がある；MLXはsafetensors + MLX量化メタデータを使用し、量化カーネルはMetalシェーダーに直接バインドされている。同一の基盤モデルは両フレームワークで使用するために別途変換が必要だ。

Mac上でLLMにOllamaがよく使われる理由は？

Ollamaは「LLMをどうやって使い始めるか」というエンジニアリングの問題を解決している：コマンド一つでHTTPサーバーを起動、OpenAI互換API、Claude Code / Cursor / Open WebUIなどのツールが直接接続できる。底層はllama.cppで、Apple Silicon上ではMetalで高速化されており、パフォーマンスは十分で、PythonやサービスのセットアップなしにローカルLLMを実行できる。

FAQ

MLX vs llama.cpp どちらが速い？性能差はどのくらいか？

ほとんどのベンチマーク環境でMLXが 3%–12% 速く、主にカーネルフュージョン（ディスパッチ回数約480 vs 160）と実行時Metalカーネル特化から来ている。ただしbatch=1で帯域幅飽和時、メモリスワップ、または長いprefill時は差がほぼゼロになる。メモリが大きい（48GBノード）ほど、モデルが大きい（14B+）ほどMLXの優位性が顕著になる；16GBで7Bを実行する場合、差は3%–7%にとどまる。

llama.cppのMetalバックエンドとMLXの本質的な違いは？

llama.cppはggmlでマルチプラットフォームを抽象化しており、Metalはその多くのバックエンドの一つで、カーネルはプリコンパイル済み、各オペレーターは独立してディスパッチされる；MLXは設計当初からApple Siliconのみを対象とし、lazy evaluationが実行時にオペレーターをフュージョンし、ディスパッチ回数が3分の1、量化パスが短く、ユニファイドメモリの整合がより深い。

GGUFとMLX量化フォーマットは相互変換できるか？

直接変換はできず、二つのフォーマットは完全に独立している。GGUFはllama.cppの convert.py で元の重みから生成；MLXフォーマットは mlx_lm.convert で変換、またはmlx-communityから直接取得する。同一の基盤モデルには別途変換が必要だ。

Claude CodeがMLXではなくOllamaを選ぶ理由は？

OllamaはすぐにHTTPサービスを提供する（:11434、OpenAI互換）、ゲートウェイの自作は不要だ。エージェントのツールループでは、フレームワーク間のtok/sの差は総遅延の5%未満で、ツール実行時間とHTTPレイヤーがボトルネックだ。MLXには内蔵HTTPサーバーがなく、Claude Codeへの接続には完全な自作推論サービスのスタックが必要で、そのエンジニアリングコストがすべての速度優位性を消してしまう。

スワップ時にどちらのフレームワークが耐性が高いか？

どちらも大幅に劣化し、差は消える。メモリ帯域幅が120GB/sから3–5GB/s（NVMeの上限）に落ちると、どのフレームワークもSSDのボトルネックを最適化できない。メモリのアップグレード（24GBまたは48GBノード）が唯一の解決策だ。

MLXとOllamaを同時にインストールできるか？

できる、完全に競合しない。推奨構成：Ollamaをバックグラウンドで常駐してClaude Codeにサービスを提供し、MLXはオンデマンドでPython環境上でベンチマークやファインチューニングスクリプトを実行する。両者は同じユニファイドメモリを共有するが、モデルフォーマットが異なるため、それぞれ別途管理が必要だ。

関連記事

• Ollama vs MLX：Claude Codeのローカルモデルはどちらを選ぶ？（技術選定の意思決定レイヤー）
• Apple Silicon M4 Pro ローカルLLM運用ガイド：実測とMLXデプロイ
• M4 Mac Mini ローカルLLM実測（Hub）
• ユニファイドメモリがApple Silicon上のLLM推論のゲームチェンジャーである理由
• Claude Code + Ollama ローカルAIエージェント実測