llama.cpp をコンパイルする Metal

#Macで使うllama.cpp：Metalがもたらすメリット

macOSでは、Appleのグラフィックスおよび計算APIであるMetalを介してGPUを利用し、llama.cppもこれを直接活用します。プロジェクトのREADMEには、Apple Siliconが主要な対応プラットフォームとして扱われ、ARM NEON、Accelerate、Metalによって最適化されていると明記されています。つまり、デフォルトの設定でコンパイルするだけで、追加オプションなしにGPUを使うエンジンが生成されます。また、ユニファイドメモリによりCPUとGPUの間でデータを転送する必要がなく、モデルはメモリ上に1つだけ保持されます。したがって、Macで制約となるのは、このメモリの容量と帯域幅です。

#前提条件

Apple Silicon搭載のMac

M1からM5までがこのガイドの対象です。Intelプロセッサ搭載のMacはほとんどメリットを得られません。

Appleのコンパイルツール

xcode-select --install で Command Line Tools をインストールしてください。

CMake と Git

Homebrew から利用可能：brew install cmake git

モデル用のメモリ

当サイトでの目安は、コンテキスト分を除いて、Q4の8Bモデルが約5GB、14Bが約9GB、32Bが19〜20GBです。

xcode-select --install
brew install cmake git

#コンパイルなしでインストール：Homebrew

特別なコンパイルオプションが必要なければ、Homebrewを使うのが最も速い方法です。llama.cppのインストールドキュメントによると、Homebrewのformulaは、プロジェクトの新しいバージョンが公開されるたびに自動更新されます。Metalに対応した同じ実行ファイルを、そのまま使える状態で入手できます。

brew install llama.cpp

リポジトリの最新版を使いたい場合、ブランチを試したい場合、またはコンパイルオプションを変更したい場合は、自分でコンパイルしてください。それ以外ならHomebrewで十分です。コンパイルにかかる時間を省け、更新はbrew upgradeで行えます。

#1. Metalを使用してコンパイル

git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp

cmake -B build
cmake --build build --config Release -j $(sysctl -n hw.ncpu)

ビルドのドキュメントには明記されています。macOSではMetalがデフォルトで有効になり、計算はGPU上で実行されます。追加するオプションはありません。Georgi Gerganovのアカウントにあった旧リポジトリ名からは、現在プロジェクトが置かれているggml-org組織へリダイレクトされます。バイナリはbuild/binに生成され、ターミナル用のllama-cliやAPI用のllama-serverなどが含まれます。

2つの便利なオプションがあります。ドキュメントによると、-DGGML_METAL=OFF を指定するとコンパイル時に Metal が無効化され、Metal でコンパイルされたバイナリは --n-gpu-layers 0 を使用して CPU での実行に強制できます。速度を比較する際に便利です。

#2. 最初のモデルを起動する

新しいエンジンはモデルを自動でダウンロードできます。-hf オプションは Hugging Face リポジトリ名を指定し、量子化はサフィックスで指定します。サフィックスがなければ、デフォルトで Q4_K_M が使用されます。既にダウンロード済みのファイルについては、-m でファイルのパスを指定してください。

./build/bin/llama-cli -hf UTILISATEUR/MODELE-GGUF:Q4_K_M

./build/bin/llama-cli -m ~/modeles/mon-modele-Q4_K_M.gguf

GPU に配置するレイヤー数は -ngl で設定します。デフォルト値は auto で、ユニファイドメモリを搭載した Mac に適しています。すべてのレイヤーを読み込むには、-ngl all と指定することもできます。Ollama のフォルダ内でモデルのパスを探さないでください。モデルファイルは内部形式で保存されており、そのまま利用できる GGUF ファイルではありません。

#llama-serverでOpenAI互換APIを提供する

llama-serverは、チャット、応答、埋め込み向けにOpenAI APIと互換性のあるルートを提供します。デフォルトでは127.0.0.1のポート8080で接続を待ち受けるため、ご自身のMacからしかアクセスできません。ネットワークからアクセスできるようにするには、--hostを明示的に指定する必要があります。その場合は、アクセスを保護することが適切です。

./build/bin/llama-server -m ~/modeles/mon-modele-Q4_K_M.gguf --port 8080

• llama.cpp とは何か、Ollama から移行すべきか？
• Ollama vs llama.cpp：どちらを選ぶべきか

#4. macOS の GPU メモリ制限

Apple Siliconでは、macOSがGPUに利用させるのはユニファイドメモリの一部だけです。その範囲を超えるモデルは、メモリの総容量が十分でも、読み込みを拒否されるか、一部の処理がCPUに回ります。エンジンは起動時に実際の値を表示します。llama-cliまたはllama-serverのログで、ggml_metal_init: recommendedMaxWorkingSetSizeという行を探してください。

sysctl iogpu.wired_limit_mbコマンドで、この上限を引き上げられます。値はメガバイト単位で指定します。たとえば60 GBなら61 440です。llama.cppリポジトリの貢献者は、この設定は永続化されないため、起動のたびにコマンドを実行し直す必要があると注意を促しています。また、100％まで引き上げることは勧めていません。システムにはGPUが確保している領域以外にもメモリが必要で、十分に残しておかないと正常に動作しなくなるためです。

# 56 Go pour le GPU sur un Mac de 64 Go (56 x 1024 = 57344)
sudo sysctl iogpu.wired_limit_mb=57344

# Relancez ensuite le modèle et relisez recommendedMaxWorkingSetSize

#統合メモリに応じたモデルの選定

ユニファイドメモリはmacOS、使用中のアプリ、モデルの間で共有され、GPUに割り当てられるのはその一部だけです。当サイトの目安では、Q4の8Bモデルの重みは約5 GB、14Bは約9 GB、32Bは約19〜20 GBです。これにコンテキストキャッシュの容量が加わります。表は余裕を見込んだ概算です。基準となるのは、エンジンが表示する recommendedMaxWorkingSetSize の値です。

これらは安全側に見積もった概算であり、実測値ではありません。長いコンテキスト、追加のモデル、リソースを多く消費するアプリケーションのいずれかがあるだけで、状況は変わります。メモリ専用のガイドで、計算方法を詳しく説明しています。

• VRAMおよびメモリ：AIに必要な量は？
• MacBook Pro M4で利用可能なLLMは？

#5. 重要となるオプション

Flash Attentionはデフォルトで自動モードになっているため、ほとんどの場合、手動で有効にする必要はありません。Flash Attentionが有効であれば、-ctkと-ctvでKVキャッシュを量子化できます。q8_0ではf16と比べてキャッシュのメモリ使用量がほぼ半分になりますが、その代わりに精度がわずかに低下するため、ご自身の用途で確認することをお勧めします。専用ガイドでこのトレードオフを詳しく説明しています。

• KVキャッシュを量子化してVRAMを節約する
• llama.cppにおけるFlash Attention

#6. チップ別の性能：公開ベンチマークが測定していること

QuelLLMはこれらのマシンの性能を測定していません。参考となるのは、llama.cppリポジトリ内の「Performance of llama.cpp on Apple Silicon M-series」のディスカッションです。ここで各貢献者はLLaMA 7B Q4_0を同じテストで実行しています。以下の表はその一部を示しており、各測定のllama.cppバージョンも記載されています。M1からM4までのデータは同じバージョンで、M5のデータはそれより新しいバージョンです。

理論上限は、帯域幅をモデルのデータサイズ（3.56GiB、つまり3.82GB）で割った値です。Proチップはこの上限の71〜82％に達しますが、Maxチップはわずか58％にとどまります。ある水準を超えると、メモリだけが制約ではなくなり、より高い帯域幅にお金を払っても、仕様表から期待するほどの効果は得られません。

ここから3つのことが分かります。生成速度はメモリ帯域幅に左右されます。M3 Proはチップの世代が新しいにもかかわらず、帯域幅が150 GB/sのため、200 GB/sのM2 Proより遅くなります。帯域幅がはるかに大きいMaxチップが優位です。また、プロンプトの読み取り速度はM5で飛躍的に向上しました。GPUコア数が同じM4 Proの439.78トークン/秒に対し、M5 Proは1,620.64トークン/秒で、3.7倍です。この差は長い文書やRAGでは重要ですが、チャットでは影響がずっと小さくなります。

Macが遅いと結論づける前に、同じモデルをまず-ngl 0で、次にデフォルト値で実行し直して比較する習慣を付けるとよいでしょう。両者の差から、そのマシンでGPUが実際にどれだけ寄与しているかが分かり、計算が確かにMetal経由で行われていることも確認できます。使用したllama.cppのバージョンも記録してください。Metalの最適化は急速に進んでおり、古いバイナリは最近のバージョンより大幅に遅い場合があります。

#トラブルシューティング：よくあるエラー

• MacでのMLX vs llama.cpp：2026年はどちらが優れる？
• CUDA対応でllama.cppをコンパイルする
• 32GBのメモリに対応するモデルは？

• 出典：llama.cppの公式リポジトリ
• 出典：llama.cppのコンパイルドキュメント
• 出典：Apple Siliconにおける公開ベンチマーク
• 出典：MacのGPUメモリ制限に関するディスカッション