技術 約6分で読めます

OllamaがMLXバックエンドに移行、Apple Siliconでのローカル推論が劇的に高速化

Ollama MLX Apple Silicon LLM ローカルLLM 推論最適化

OllamaがApple Silicon環境のバックエンドをllama.cppからMLXに切り替えた。Ollama 0.19のプレビューリリースとして2026年3月30日に公開されている。

これまでOllamaはCPU/GPU推論にllama.cpp（GGML）を使っていた。Apple Siliconの統合メモリアーキテクチャを最大限に活かすには、Apple純正のMLXフレームワークを使うのが理にかなっている。長らくGitHub上でもMLXバックエンドのリクエストが出ていたが、ようやく実現した形だ。

ベンチマーク

テストはQwen3.5-35B-A3B（MoEモデル、アクティブパラメータ約30億）で実施された。

指標Ollama 0.19（MLX, NVFP4）Ollama 0.18（llama.cpp, Q4_K_M）向上率
プリフィル1810 トークン/秒1154 トークン/秒+57%
デコード112 トークン/秒58 トークン/秒+93%

int4量子化ではさらに高い数値が出ており、プリフィル1851トークン/秒、デコード134トークン/秒に達する。

デコード速度がほぼ倍になっているのが目を引く。デコードはメモリ帯域律速なので、MLXが統合メモリ上でのデータ配置をGGMLより効率的に扱えていることを意味する。プリフィルは演算律速だが、ここでも57%の向上が出ている。

MLXとは何か

MLX（Machine Learning eXploration）はAppleが2023年末にオープンソース公開した配列計算フレームワークだ。NumPyライクなAPIを持ちつつ、Apple Siliconの統合メモリアーキテクチャに最適化されている。CPUとGPUの間でデータコピーが不要な点が最大の特徴で、PyTorchのMPSバックエンドとは設計思想が根本的に違う。

PyTorchのMPSバックエンドはCUDA向けに書かれたコードをMetalに「翻訳」するアプローチで、ComfyUIのMPS非連続テンソル問題やBF16のパフォーマンス低下など、Apple Silicon固有の問題を踏みがちだった。MLXはそもそもApple Silicon専用に設計されているので、こうした翻訳コストがない。

MLXのエコシステムにはPython（mlx）、Swift（mlx-swift）、C/C++ APIがあり、LLM推論用のmlx-lmパッケージも用意されている。Ollama 0.19はこのMLXの上に構築された。

M5チップのNeural Accelerator対応

M5、M5 Pro、M5 Maxチップでは、GPUに内蔵されたNeural Accelerator（ニューラルアクセラレータ）をMLX経由で活用できる。Appleの研究チームが公開したベンチマークによると、M5のNeural AcceleratorはMetal 4で導入されたTensor Operations（TensorOps）を通じて行列積演算を専用ハードウェアで処理する。

同ベンチマークではMacBook Pro M5（24GB）とM4の比較が行われている。

モデルM4 TTFTM5 TTFT速度向上
Qwen 1.7B (BF16)0.33秒0.15秒2.2倍
Qwen 8B (BF16)3.02秒0.96秒3.1倍
Qwen 14B (4bit)12.63秒4.24秒3.0倍
Qwen 30B MoE (4bit)5.24秒2.70秒1.9倍

TTFT（Time to First Token）は演算律速のフェーズなので、Neural Acceleratorの効果がダイレクトに出る。一方、トークン生成速度はメモリ帯域律速のため、向上率は19〜27%程度とのこと。それでもM4比で着実に速くなっている。

Ollamaの公式ベンチマークがM5環境で測定されていることを考えると、M4以前のチップではここまでの数値は出ないが、MLXバックエンド自体の恩恵は全Apple Silicon世代で受けられる。

NVFP4量子化のサポート

Ollama 0.19はNVIDIAのNVFP4（4ビット浮動小数点）フォーマットをサポートする。NVFPはNVIDIAが開発した低精度推論向けのデータフォーマットで、INT4やFP4と比較して精度の劣化が少ないとされる。

ollama run qwen3.5:35b-a3b-coding-nvfp4

NVIDIAの名前がついているが、NVFP4自体はハードウェア依存ではなくデータフォーマットの仕様だ。処理する演算カーネルさえあればどのハードウェアでも動く。MLXは最近のリリースでNVFP4とMXFP8の量子化演算をMetalでネイティブサポートしている。

NVFP4を使う実益は、クラウドのNVIDIA GPU環境と同じ量子化フォーマットでローカル推論できることだ。NVIDIAのModel Optimizerで最適化されたモデルをそのまま持ってこられるので、サーバーとローカルで出力が一致する。これはClaude CodeやOpenClawのようなコーディングエージェントを使う場合に地味に効いてくる。

キャッシュの改善

Ollama 0.19ではKVキャッシュの管理も大幅に改善された。

会話間でのキャッシュ再利用。 従来は会話ごとにキャッシュが破棄されていたが、共有システムプロンプトを使う場合にキャッシュを再利用するようになった。Claude Codeのようなツールは毎回同じシステムプロンプトを送るので、2回目以降のプリフィルが大幅に短縮される。

インテリジェントチェックポイント。 プロンプト内の適切な位置でキャッシュのスナップショットを保存する。分岐の多いエージェント的な使い方で、途中から再計算を始められる。

スマートなエビクション。 共有プレフィックスは、古い分岐が破棄されても長く生き残るようになった。

KVキャッシュの最適化についてはHypuraのNVMeストリーミングとTurboQuantの記事で掘り下げたが、あちらはモデル自体をメモリに収めきれない場合のストリーミング手法だった。Ollama 0.19のキャッシュ改善は、モデルがメモリに載っている前提でのプロンプト処理効率の話なので、レイヤーが違う。両方が噛み合えば、Apple Silicon環境でのローカルLLM体験はかなり快適になるはずだ。

llama.cppからの移行で変わること

graph TD
    A[Ollama 0.18以前] --> B[llama.cpp / GGML]
    B --> C[Metal経由でGPU実行]
    C --> D[Q4_K_M等のGGUF量子化]

    E[Ollama 0.19] --> F[MLX]
    F --> G[統合メモリ直接アクセス]
    G --> H[NVFP4 / int4量子化]
    F --> I[M5 Neural Accelerator対応]

    style A fill:#f5f5f5,stroke:#999
    style E fill:#f5f5f5,stroke:#999
    style F fill:#e8f5e9,stroke:#4caf50
    style I fill:#e3f2fd,stroke:#2196f3

現時点でサポートされているモデルは限定的だ。プレビュー段階ではQwen3.5-35B-A3Bが対象で、今後アーキテクチャの対応範囲を広げていくとしている。カスタムモデルのインポート機能も計画中とのこと。

これはFlash-MoEの記事で紹介した、手書きMetalシェーダーで397Bモデルを48GBマシンに無理やり載せるアプローチとは対照的だ。Flash-MoEはSSDストリーミングで「載せきれないモデルを動かす」ことに特化していたが、OllamaのMLX移行は「載るモデルをもっと速く動かす」方向の最適化になる。

セットアップ

32GB以上の統合メモリを搭載したMacが必要。

# Claude Codeで使う場合
ollama launch claude --model qwen3.5:35b-a3b-coding-nvfp4

# OpenClawで使う場合
ollama launch openclaw --model qwen3.5:35b-a3b-coding-nvfp4

# チャットで使う場合
ollama run qwen3.5:35b-a3b-coding-nvfp4

ollama launchは指定したアプリケーションにモデルを接続するコマンドで、裏でOllamaサーバーが起動してモデルをロードし、対象アプリにエンドポイントを渡す。Ollamaを使ったRAGシステム構築のような既存のセットアップでも、Ollama自体のアップデートだけでMLXの恩恵を受けられるはずだ（対応モデルが拡大すれば）。

Apple SiliconでのローカルLLM推論は、llama.cppのMetalバックエンド、PyTorchのMPSバックエンド、MLXネイティブと選択肢が増えてきた。