中級 13 分Mac

Mac Mシリーズでの MLX vs llama.cpp:2026年はどちらが勝つ? ?

MシリーズのMacでLLMをローカル実行するには、Appleの公式フレームワークであるMLXか、Metalバックエンドを備えたllama.cppという2つの選択肢があります。どちらも内蔵GPUとユニファイドメモリを活用しますが、設計思想は大きく異なります。このMac向けMLX対llama.cpp比較記事では、トークン/秒、対応モデル、量子化、Pythonでの使いやすさを比較し、利用者の目的や経験に応じた明確な結論を示します。

著者 Marie L.·更新 2026-08-27·macOS 14+ でテスト済み

#2026年の両陣営

MLXはAppleの機械学習チームが開発し、2023年末にリリースしたフレームワークです。NumPyとPyTorchを融合したようなPythonフレームワークで、当初からユニファイドメモリとMetal向けに設計されています。対象分野は幅広く、LLM、画像、音声、ファインチューニングに対応します。mlx-lmパッケージは、言語モデルの推論と学習に特化しています。

llama.cppは2023年に誕生したC++プロジェクトで、プラットフォームを問わずローカルLLM推論の事実上の標準となっています。Macでは、Metalバックエンドがコンピュートシェーダーを生成し、Apple SiliconのGPUを活用します。llama.cppはOllama、LM Studio、そして一般ユーザー向けツールの大半を支えています。モデル形式:GGUF。

i
なぜそれらが共存するのか
MLXはApple環境向けに作られており、llama.cppはさまざまな環境に移植できます。前者はMetalの命令の隅々まで最適化されており、後者は同じコードをCUDA、Vulkan、ROCmでも使えます。Macでは両者が直接競合します。Mac以外では、どちらを選ぶかで迷う余地はありません。

#1. インストール

Macキット

あなたのMacでローカルAIを最大限に活用:ユニファイドメモリ、MLXとGGUFの比較、お使いのチップに合ったモデル、Apple Silicon向けに調整済みのOllamaとLM Studio。

  • 永久に利用できるオンラインスペース
  • PDF + ファイル
  • 生涯アップデート

MLXでは、すべてpip経由で行います。ランタイムのmlx-lmが、Hugging Faceからのダウンロード、変換、量子化、推論を管理します。

MLX
pip install mlx-lm

# Premier test : Qwen 3.5 4B 4-bit en une commande
mlx_lm.generate --model mlx-community/Qwen3.5-4B-Instruct-4bit \
  --prompt "Explique la mémoire unifiée Apple en 3 phrases."

llama.cpp 側では、Metal を有効にしてソースからコンパイルする、Homebrew を通す、または Ollama や LM Studio のようなラッパーを使用する、という三つの選択肢があります。公平な比較のため、コンパイル済みバイナリを使用します。

llama.cpp
brew install llama.cpp

# Inférence sur un modèle GGUF déjà téléchargé
llama-cli -m ./Qwen3.5-4B-Instruct-Q4_K_M.gguf \
  -p "Explique la mémoire unifiée Apple en 3 phrases." \
  -n 256 -ngl 99
→
ngl 99 = すべての層をGPUに載せる
Macでは、-ngl(GPUレイヤー数)フラグを常に99以上に設定してください。すべてのレイヤーがMetal経由で内蔵GPUに配置され、ユニファイドメモリのおかげで、転送による帯域幅の負担はありません。

#2. M3 MaxとM4 Proでのトークン/秒

2026年によく使われている2台のマシンでの、代表的な測定値のおおよその目安を示します。MacBook Pro M3 Max 64 GB(メモリ帯域幅400 GB/s)とMac mini M4 Pro 48 GB(273 GB/s)です。同等の量子化設定(4-bit MLXとQ4_K_M GGUF)でモデルを比較し、200トークンのプロンプトを入力して256トークンを生成しています。

Qwen 3.5 4B — M3 Max
MLX 4ビット:150トークン/秒 · llama.cpp Q4_K_M:135トークン/秒。MLXが約11%高速です。
Qwen 3.5 9B — M3 Max
MLX 4ビット:72トークン/秒 · llama.cpp Q4_K_M:66トークン/秒。MLXのほうが約9%高速です。
Gemma 4 12B — M3 Max
MLX 4ビット:48トークン/秒・llama.cpp Q4_K_M:44トークン/秒。MLXのほうが9%高速です。
Mistral Small 24B — M3 Max
MLX 4ビット:24トークン/秒 · llama.cpp Q4_K_M:22トークン/秒。MLXは+9%。
Qwen 3.8 27B — M3 Max
MLX 4ビット:21 tok/s · llama.cpp Q4_K_M:19 tok/s。MLX +10%。
Qwen 3.5 9B — M4 Pro
MLX 4ビット:50トークン/秒 · llama.cpp Q4_K_M:46トークン/秒。MLXは9%高速。

傾向は明確で、再現性があります。生成処理だけを比べると、MLXは8〜15%高速です。この差は、AppleがGPUスケジューラーとL1/L2キャッシュを熟知したうえで、MLXのMetalカーネルを直接実装・最適化していることから生じます。llama.cppもMetalカーネルを使いますが、こちらはより汎用的です。

!
プロンプト処理が判断を逆転させる可能性があります
最初のプロンプトの処理(プリフィル)では、Flash Attentionを有効にしたllama.cpp(-fa)がMLXに追いつくことが多く、長いコンテキストでは上回ることもあります。RAGシステムに16kトークンを入力する場合は、判断する前に2つのフェーズを別々に測定してください。

#3. Hugging Faceモデルのサポート

両者のエコシステムが実際には異なる点の一つです。MLXは独自の重みフォーマット(.safetensors および MLX コンフィグ)を持ち、llama.cpp は GGUF を使用します。

MLX — モデルの入手性
Hugging Face 上の mlx-community オーガナイゼーションは、人気モデルの多数を 4ビットおよび 8ビットのバージョンで公開しています(Qwen 3.5/3.8、Gemma 4、Mistral、Granite 4.2)。これらのモデルは、リリース週にしばしば配布されます。
MLX — あまり普及していないモデル
特殊なファインチューニング済みモデルやあまり知られていないモデルの場合は、mlx_lm.convertを使って自分で変換する必要があります。通常の変換時間は、サイズに応じて2〜10分です。
llama.cpp — 入手しやすさ
GGUF は広く出回っています。Bartowski、TheBloke(アーカイブ)、Unsloth、そして公式のモデル提供元は、多くのモデルを MLX 形式より先に GGUF 形式で公開しています。
llama.cpp — 非常に新しいモデル
新しいアーキテクチャ(新種のMoEや特殊なアテンション機構など)が登場すると、llama.cppはそれをC++で実装する必要があります。通常かかる期間は数日から2週間です。MLXはPythonとMetalで構成されているため、Appleがすでに対応を準備している場合には、より早く追随することがあります。
HFモデルをMLX 4ビットに変換
mlx_lm.convert \
  --hf-path Qwen/Qwen3.5-9B-Instruct \
  --mlx-path ./qwen3.5-9b-mlx-4bit \
  -q --q-bits 4 --q-group-size 64

#4. 利用可能な量子化

おそらく、この分野こそllama.cppが圧倒的に優位に立つ分野です。GGUFには十数種類の量子化方式(Q2_K、Q3_K_S/M/L、Q4_K_S/M、Q5_K_M、Q6_K、Q8_0、さらにI-quantsのIQ2_XXS〜IQ4_NL)があり、サイズと品質のトレードオフを細かく調整できます。

MLX
4ビット、6ビット、8ビットの量子化。主なパラメータはgroup-size(32、64、128)です。混合精度のK-quantsに直接相当するものはありません(Q4_K_Mでは一部のレイヤーでより高い精度を保持します)。
llama.cpp
GGUF Q4_K_M(推奨)、Q5_K_M、Q6_K、Q8_0、FP16に加え、さらに低ビットで量子化できるI-quantsもあります。imatrixによるキャリブレーションも可能です。
観察された品質
同等のサイズでは、GGUF Q4_K_M と MLX 4 ビットのパープレキシティは非常に近い値になります(差は 1%未満)。限られた RAM に大きなモデルを収める場合(16 GB で Qwen 3.8 27B を使う場合など)、llama.cpp の I-quants は今も、よりきめ細かな量子化が可能です。
i
Q4_K_Mは依然として基準です
ほとんどの用途では、llama.cppのQ4_K_MとMLXの4ビット量子化(グループサイズ64)は、実用上同じ結果になります。違いが見えるのは、MMLUやパープレキシティを精密に測定してベンチマークを行う場合だけです。

#5. ユニファイドメモリ:最もうまく活用するのはどちら?

MシリーズのMacでは、CPUとGPUが同じRAMを共有します。コピーもPCIe経由の転送も不要で、同じメモリプールを使います。これはLLM推論におけるApple製チップの構造的な利点であり、両方のフレームワークがその恩恵を受けます。ただし、その活用の仕方は異なります。

MLX
ユニファイドメモリ向けに最初から設計されています。テンソルは、CPUとGPUのどちらからも同じようにアクセスできる空間に置かれます。NumPyとMLX間の変換はゼロコピーです。これはAppleのアーキテクチャ上の大きな強みです。
llama.cpp Metal
共有MTLBufferを割り当てます。動作しますが、抽象化の層が1つ加わります。デフォルトで割り当てられるVRAMに収まらないモデルでは、sudo sysctl iogpu.wired_limit_mbで上限を手動調整する必要がある場合があります。
64GBメモリで動かす大規模モデル
2026年には、汎用の最上位モデルであるQwen 3.8 27Bでさえ、4ビットでは約18GBにすぎません。64GBのユニファイドメモリがあれば、Qwen 3.6 35B-A3B(約23GB)のような大型MoEモデルや、品質を最大限に高めるための同じモデルのQ8版を読み込むにも十分な余裕があります。128GB(最上位構成のM3 MaxまたはM2 Ultra)なら、妥協することなく複数のモデルを同時に読み込めます。
→
macOSのVRAM上限を引き上げる
デフォルトでは、macOS は GPU に約 75%の RAM を割り当てます。64GB のマシンでは約 48GB が使用可能になります。56GB まで増やしたい場合、以下のコマンドを実行してください:sudo sysctl iogpu.wired_limit_mb=57344 — これは、高精度量子化(Q5_K_M または 6-bit MLX)で大きな MoE 35B モデルを読み込む場合や、複数のモデルを同時にロードする際に役立ちます。

#6. Python統合

あなたがエージェントをコード化する、RAGパイプラインを構築する、あるいはLangChain / LlamaIndex / 自作コードでLLMをインストルメントする場合、Pythonでの経験はトーク/秒の性能と同等に重要です。

MLX — ストリーミング推論
from mlx_lm import load, stream_generate

model, tokenizer = load("mlx-community/Qwen3.5-9B-Instruct-4bit")

prompt = tokenizer.apply_chat_template(
    [{"role": "user", "content": "Résume MLX en 3 phrases."}],
    tokenize=False, add_generation_prompt=True,
)

for chunk in stream_generate(model, tokenizer, prompt, max_tokens=256):
    print(chunk.text, end="", flush=True)

llama.cppでは、Pythonとの統合にllama-cpp-python(公式バインディング)を使います。APIはC++に近く、記述量が多くなりますが、サーバーを起動すればOpenAI互換APIとして利用できます。

llama-cpp-python
from llama_cpp import Llama

llm = Llama(
    model_path="./Qwen3.5-9B-Instruct-Q4_K_M.gguf",
    n_gpu_layers=-1,   # tout sur Metal
    n_ctx=8192,
    flash_attn=True,
)

for chunk in llm.create_chat_completion(
    messages=[{"role": "user", "content": "Résume llama.cpp en 3 phrases."}],
    stream=True,
):
    delta = chunk["choices"][0]["delta"].get("content", "")
    print(delta, end="", flush=True)
MLX — 使いやすさ
すっきりしたAPI、NumPy風の構文、HF Hubとのネイティブ統合。データサイエンティストなら、すぐに使い始められます。
MLX — 限界
公式のOpenAI互換エンドポイントは、まだ組み込まれていません。複数のクライアントからモデルを利用できるようにするには、FastAPIを使って独自のラッパーを構築する必要があります。
llama.cpp — 使いやすさ
Python APIもまずまずですが、実際の本番運用では、OpenAI互換の/v1/chat/completionsを標準で提供するllama-server(バイナリ)を使います。
llama.cpp — 制限
llama-cpp-pythonのwheelは、適切なMetalフラグを指定して再コンパイルする必要があります(CMAKE_ARGS="-DGGML_METAL=on" pip install llama-cpp-python --force-reinstall --no-cache-dir)。これが導入時の手間になります。

#7. エコシステムとツール

実際に何ができるかを決めるのは、ランタイムそのものだけでなく、エコシステムです。

Ollama
llama.cppをベースとしています。MacでLLMを動かし、localhost:11434でOpenAI互換APIを利用できるようにする最も簡単な方法です。
LM Studio
2025年以降、両方のエンジンをサポートしています:デフォルトは llama.cpp、対応モデルには MLX をオプションとして利用可能。1クリックで切り替えられます。
LoRAによるファインチューニング
MLXには、洗練されたネイティブ機能mlx_lm.loraがあり、特別な工夫をしなくても内蔵GPUで動作します。llama.cppにはファインチューニング機能がないため、UnslothまたはMLXを使う必要があります。
モデルを提供する
llama-serverを備えたllama.cppが、文句なしに優位です。複数クライアント、バッチ処理、スロットに対応し、OpenAI APIとの互換性もあります。MLXには2025年からmlx_lm.serverがありますが、機能はまだ基本的なものにとどまります。
視覚と音声
MLXには、十分にメンテナンスされている拡張機能(mlx-vlm、mlx-whisper)があります。llama.cppはLLaVA / Qwen-VLモデルを通じて視覚処理に対応していますが、対応状況はビルドによって異なります。

#ユースケース別評価

ローカルチャットで、毎秒の生成トークン数を最大にしたい場合
MLXです。追加費用なしで速度が10%向上し、大きなモデルでは差がさらに広がります。特に4ビットでは顕著です。
複数のクライアント(チーム、アプリ)にエンドポイントを提供したい
llama.cpp(llama-serverまたはOllama)。マルチスロット、バッチ処理、OpenAI互換に対応し、長年にわたって安定しています。
週に約10個の異なるモデルをテストしています
llama.cpp。GGUFエコシステムは、量子化モデルの対応範囲の広さと新しい量子化モデルが提供される速さで他の追随を許しません。
Python プロジェクト(エージェント、RAG、パイプライン)を構築します
すべてローカルで動かし、Mac のみを対象にするなら MLX。Linux と Mac の両方で使えるコードにしたいなら、llama-cpp-python または Ollama クライアントを選びます。
Mac で 7-13B のモデルをファインチューニングしたい
MLX。mlx_lm.loraはM3 Max/M4 Pro(32GB以上)で非常に良好に動作します。
初心者で、単に動作するLLMを求める場合
Ollama(つまりllama.cpp)。コマンド1つで完了です。
i
本当の答え:両方を使いましょう
Mac では、日常的な用途(Open WebUI、Continue.dev、ローカル API)には Ollama をデーモンとして動かし、研究やベンチマークには Python の venv 内で MLX を使うことができます。両者は互いに干渉せず、それぞれの得意分野で力を発揮します。

#さらに詳しく

このテーマをさらに掘り下げるための関連資料をいくつかご紹介します。

このガイドは役に立ちましたか?

ご意見、誤りのご指摘、補足はありますか?ぜひお知らせください。皆さんにとってより良いガイドにするために役立ちます。