GGUFとMLX、Macで動かすならどっちを選ぶべきか──「ファイル形式」と「フレームワーク」を混同しないための整理

「MacでローカルLLMを動かすならGGUFかMLXか」という比較は、ローカルAIコミュニティでよく交わされる話題だが、実は問いの立て方に注意が必要だ。GGUFとMLXは、どちらもAppleシリコン上でLLMを動かす文脈で語られるものの、扱っている抽象化レベルが違う。一次資料を確認しながら、その違いを整理する。

GGUFは「ファイル形式」、MLXは「フレームワーク」

まず押さえておきたいのは、この2つが同じ種類のものではない、という点だ。

GGUFの公式仕様書（ggml-org/ggmlリポジトリのdocs/gguf.md）は、GGUFを次のように定義している。

"GGUF is a file format for storing models for inference with GGML and executors based on GGML. GGUF is a binary format that is designed for fast loading and saving of models, and for ease of reading."

GGUFは、GGML、およびGGMLをベースにした実行エンジン（代表例がllama.cpp）で推論するためにモデルを保存する、バイナリのファイル形式だ。速い読み込み・保存と、読みやすさのために設計されている。GGML・GGMF・GGJTという過去の形式の後継であり、モデルを読み込むために必要な情報をすべて単一ファイルに含む点、互換性を壊さずに新しい情報を追加できる拡張性を持つ点が特徴とされている。

一方MLXは、AppleのMLX公式GitHubリポジトリのREADMEによれば「Apple silicon向けの機械学習用配列（array）フレームワーク」であり、Appleの機械学習研究チームが提供している。NumPyに似たPython APIに加え、C++・C・Swiftの各APIも持つ。

つまりGGUFは「モデルの重みをどうファイルに保存するか」の規格、MLXは「そのモデルをどう計算・実行するか」を担うフレームワークだ。実務上の対比としては、GGUFの対抗馬は「MLXが使う独自の重みフォーマット（.safetensorsをMLX用に変換したもの）」であり、MLXの対抗馬は「GGUFファイルを読み込んで動かすllama.cpp（推論エンジン）」という組み合わせで捉えるのがより正確になる。

GGUFの設計思想

GGUF公式仕様書は、この形式が満たすべき特徴として次を挙げている。

• 単一ファイルでのデプロイ：追加の外部ファイルなしに配布・読み込みができる
• 拡張性：GGMLベースの実行エンジンや、GGUFモデルに新機能・新情報を追加しても、既存モデルとの互換性を壊さない
• mmap互換性：mmap（メモリマップドファイル）を使った高速な読み込み・保存ができる
• 使いやすさ：外部ライブラリなしで、少量のコードでモデルを読み込み・保存できる。言語を問わない
• 完全な情報：モデルを読み込むために必要な情報はすべてファイル内に含まれ、ユーザーが追加情報を提供する必要はない

GGJT（前身の形式）との最大の違いは、ハイパーパラメータ（現在は「メタデータ」と呼ばれる）を、型のないリストではなくキーバリュー構造で持つようになった点だ。これにより、既存モデルとの互換性を壊さずに新しいメタデータを追加でき、推論やモデル識別に役立つ追加情報をモデルに付与できる。

GGUFのファイル命名規則

GGUF仕様書には、ファイル名の命名規則も定義されている。基本形は次の通り。

[<Sidecar>]<BaseName><SizeLabel><FineTune><Version><Encoding><Type><Shard>.gguf

各コンポーネントは-で区切られる。たとえばMixtral-8x7B-v0.1-KQ2.ggufというファイル名は、モデル名「Mixtral」・エキスパート数8×パラメータ数7B・バージョンv0.1・重みエンコーディング方式KQ2、と読み解ける。この命名規則は「人間が一目でモデルの重要な詳細を把握できるようにする」ことが目的で、フィールドすべてを機械的に漏れなくパースできることは意図されていない、と仕様書は明記している。

MLXの設計思想：ユニファイドメモリという最大の特徴

MLX公式READMEが挙げる主な特徴は次の通り。

• 馴染みのあるAPI：NumPyに近いPython API、PyTorchに近いmlx.nn・mlx.optimizers
• 組み合わせ可能な関数変換：自動微分、自動ベクトル化、計算グラフ最適化に対応
• 遅延計算：配列は必要になるまで実体化されない
• 動的なグラフ構築：引数の形状が変わっても遅いコンパイルが発生しない
• マルチデバイス：現在サポートされているCPU・GPUのどちらでも演算を実行できる

そして、READMEが「MLXと他のフレームワークとの顕著な違い」として明記しているのが「ユニファイドメモリモデル」だ。

"Unified memory: A notable difference from MLX and other frameworks is the unified memory model. Arrays in MLX live in shared memory. Operations on MLX arrays can be performed on any of the supported device types without transferring data."

MLXの配列は共有メモリ上に存在し、対応するどのデバイスタイプでもデータ転送なしに演算を実行できる。これはApple Siliconのユニファイドメモリアーキテクチャ（CPU・GPU・Neural Engineが物理的に同じメモリプールを共有する設計）を前提にした最適化であり、GPU・CPU間でデータをコピーする従来型フレームワークのオーバーヘッドを避けられる。

MLX側で実際にLLMを動かすのは「MLX LM」というパッケージ

ここまでのMLX公式README（ml-explore/mlx）は、あくまで配列演算の基盤フレームワークの説明であり、GGUF＋llama.cppに相当する「LLMをロードしてテキスト生成する」役割を担うのは、別リポジトリのmlx-lm（MLX LM）というPythonパッケージだ。そのREADMEをcurlで取得すると、次のような特徴が確認できる。

• Hugging Face Hubと統合されており、1コマンドで数千種類のLLMを利用できる
• モデルの量子化と、Hugging Face Hubへのアップロード機能を持つ（mlx_lm.convert --model <repo> -q）
• 量子化済みモデルを含むLoRA・フルモデルのファインチューニングに対応
• mx.distributedによる分散推論・分散ファインチューニングに対応
• 長いプロンプト・生成に対応するための「ローテーションKVキャッシュ」「プロンプトキャッシュ」「可変のprefillステップサイズ」を持つ

コマンドラインの既定モデルはmlx-community/Llama-3.2-3B-Instruct-4bitで、量子化済みモデルの多くはHugging Face上の「MLX Community」組織で配布されている——ここは、GGUF量子化モデルが集まるTheBlokeやbartowskiなどのHugging Face配布元に相当する、MLXエコシステム側の集積地といえる。

実務上とくに参考になるのが「Large Models」の節だ。READMEには次の注記がある。

"Models which are large relative to the total RAM available on the machine can be slow. mlx-lm will attempt to make them faster by wiring the memory occupied by the model and cache. This requires macOS 15 or higher to work."

（訳）「マシンの総RAM量に対して大きすぎるモデルは遅くなることがある。mlx-lmはモデルとキャッシュが占有するメモリを『ワイヤリング（固定）』することで高速化を試みるが、これにはmacOS 15以上が必要」

搭載RAMに対してモデルが大きい場合に警告メッセージが出ることがあり、その際はsudo sysctl iogpu.wired_limit_mb=NでmacOS側のGPU用ワイヤードメモリの上限を引き上げることで改善する場合がある、とREADMEには明記されている（Nはモデルサイズ〔MB〕より大きく、搭載メモリ量より小さい値）。これはMLX側に固有の実務上のチューニングポイントで、GGUF＋llama.cpp側の仕様書には対応する記述がない。

両者を1枚の表で比較する

ここまで確認した一次資料の記載を、項目別に並べ直すと次のようになる。

（表は本文中で引用したGGUF公式仕様書・MLX公式READMEの記載を項目別に並べ替えたもの。速度・メモリ消費量の実測比較は含まない。）

実務上、何が違ってくるのか

一次資料からは「速度が何%違う」といった定量的な比較は確認できなかった（そうした数値はコミュニティのベンチマーク記事によるもので、GGUF公式仕様書・MLX公式READMEのいずれにも含まれていない）。一次資料から確認できる、構造上の違いは次の通りだ。

• 対応環境：GGUF＋llama.cppはMac・Windows・Linux・スマートフォンまで幅広い環境をカバーする設計。MLXはApple Silicon向けに設計されたフレームワークだが、公式READMEにはLinux向けのCUDAバックエンド（pip install mlx[cuda]）とCPU専用パッケージ（pip install mlx[cpu]）も記載されており、Apple Silicon専用というわけではない
• メモリの扱い方：MLXはユニファイドメモリを前提にした設計を明示しているのに対し、GGUFの仕様書はメモリアーキテクチャに依存しない「ファイル形式」の設計に集中している
• エコシステム：LM StudioはGGUF系のllama.cppエンジンとMLXエンジンの両方を選択できるようになっている（詳しくはLM StudioがMLXエンジンを統一した意味を参照）

どちらを選ぶべきか

一次資料だけからは「どちらが優れているか」の結論は出せない。GGUF＋llama.cppは対応モデル・対応環境の広さ、MLXはApple Silicon向けに最適化されたユニファイドメモリの活用という、それぞれ異なる強みを持つ設計思想にもとづいている。Macユーザーが実際にどちらを選ぶべきかは、使うツール（LM Studio・Ollamaなど）が対応しているモデルの範囲や、自分のワークロード（テキスト生成中心か、マルチモーダルか）によって変わる。ローカルLLMを動かすための基礎知識全般はローカルLLMとは何か、具体的なおすすめモデルの選び方はローカルLLMおすすめモデル10選を参照してほしい。

実機での速度・メモリ比較データは含んでいない

• 本記事はGGUF公式仕様書とMLX公式READMEという一次資料を中心に、両者の「設計思想・仕様」レベルの違いを整理したもので、実機での速度・メモリ消費量の比較データは含んでいない。ネット上でよく見かける「MLXの方が10〜30%速い」といった数値は、コミュニティによるベンチマークであり、開発元自身が公表した数値ではない点に注意してほしい。
• GGUFの仕様書には量子化方式（Q4_K_M等）の詳細な一覧も含まれるが、本記事では紙幅の都合上、ファイル形式の設計思想と命名規則に絞って紹介した。
• MLXの対応デバイスはREADME記載時点で「CPUとGPU」に限られており、Apple Neural Engine（ANE）への直接対応は明記されていない。この点の最新状況は、MLX公式ドキュメントで別途確認が必要。
• 両者のエコシステム（対応モデル数、コミュニティの活発さ）についての定量的な比較は、本記事のソースからは確認できていない。