Compiler llama.cpp avec Metal

#llama.cpp sur Mac : ce que Metal apporte

Sur macOS, le GPU s'utilise via Metal, l'API graphique et de calcul d'Apple, et llama.cpp l'exploite directement. Le README du projet précise que Apple Silicon est un citoyen de première classe, optimisé via ARM NEON, Accelerate et Metal. En pratique, cela signifie que la compilation par défaut produit déjà un moteur qui utilise le GPU, sans option à ajouter, et que la mémoire unifiée évite tout transfert entre le processeur et le GPU : le modèle vit une seule fois en mémoire. Le facteur limitant sur un Mac est donc la capacité et la bande passante de cette mémoire.

#Prérequis

Un Mac Apple Silicon

M1 à M5 : c'est la cible de ce guide. Les Mac à processeur Intel n'y gagnent presque rien.

Les outils de compilation Apple

Installez les Command Line Tools avec xcode-select --install.

CMake et Git

Disponibles via Homebrew : brew install cmake git.

De la mémoire pour le modèle

Le repère du site : un 8B en Q4 pèse environ 5 Go, un 14B environ 9 Go, un 32B 19 à 20 Go, avant le contexte.

xcode-select --install
brew install cmake git

#Installer sans compiler : Homebrew

Si vous n'avez pas besoin d'options de compilation particulières, la voie la plus rapide est Homebrew. La documentation d'installation de llama.cpp indique que la formule est mise à jour automatiquement à chaque nouvelle version du projet. Vous obtenez les mêmes exécutables, prêts à l'emploi, avec Metal.

brew install llama.cpp

Compilez vous-même quand vous voulez la dernière version du dépôt, tester une branche ou modifier une option de compilation. Sinon, Homebrew suffit : vous gagnez le temps de compilation et les mises à jour se font avec brew upgrade.

#1. Compiler avec 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)

La documentation de build est explicite : sur macOS, Metal est activé par défaut, et il fait exécuter le calcul sur le GPU. Aucune option n'est à ajouter. L'ancien nom du dépôt, sous le compte de Georgi Gerganov, redirige vers l'organisation ggml-org, où se trouve désormais le projet. Les binaires apparaissent dans build/bin, notamment llama-cli pour le terminal et llama-server pour l'API.

Deux options utiles : la documentation indique que -DGGML_METAL=OFF désactive Metal à la compilation, et qu'un binaire compilé avec Metal peut être forcé sur le processeur avec --n-gpu-layers 0, pratique pour comparer les vitesses.

#2. Lancer un premier modèle

Les moteurs récents savent télécharger le modèle eux-mêmes. L'option -hf prend le nom d'un dépôt Hugging Face, avec la quantification en suffixe ; sans suffixe, Q4_K_M est retenue par défaut. Pour un fichier déjà téléchargé, utilisez -m avec son chemin.

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

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

Le nombre de couches placées sur le GPU se règle avec -ngl ; sa valeur par défaut est auto, ce qui convient à un Mac dont la mémoire est unifiée. Vous pouvez aussi écrire -ngl all pour tout charger. Ne cherchez pas le chemin d'un modèle dans le dossier d'Ollama : ses fichiers sont stockés sous un format interne qui n'est pas un GGUF directement utilisable.

#Servir une API compatible OpenAI avec llama-server

llama-server expose des routes compatibles avec l'API OpenAI pour le chat, les réponses et les embeddings. Par défaut, il écoute sur 127.0.0.1, port 8080 : il n'est joignable que depuis votre Mac. Pour l'ouvrir au réseau, il faut passer --host explicitement, et il convient alors de protéger l'accès.

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

• llama.cpp : c'est quoi, et faut-il quitter Ollama ?
• Ollama vs llama.cpp : lequel choisir

#4. La limite de mémoire GPU de macOS

Sur Apple Silicon, macOS ne laisse au GPU qu'une part de la mémoire unifiée. Un modèle qui dépasse cette part est refusé ou déborde vers le processeur, même si la mémoire totale suffit. Le moteur affiche la valeur effective au démarrage : cherchez la ligne ggml_metal_init: recommendedMaxWorkingSetSize dans les journaux de llama-cli ou de llama-server.

La commande sysctl iogpu.wired_limit_mb permet de relever ce plafond. Elle attend une valeur en mégaoctets : 61 440 pour 60 Go, par exemple. Un contributeur du dépôt de llama.cpp rappelle qu'elle est à refaire à chaque démarrage, car elle n'est pas persistante, et déconseille d'aller jusqu'à 100 % : le système a besoin de mémoire pour tout ce qui n'est pas verrouillé par le GPU, et les choses tournent mal si on ne lui en laisse pas assez.

# 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

#Quel modèle pour quelle mémoire unifiée

La mémoire unifiée est partagée entre macOS, vos applications et le modèle, et le GPU n'en reçoit qu'une part. Le repère du site place les poids d'un 8B en Q4 autour de 5 Go, d'un 14B autour de 9 Go et d'un 32B autour de 19 à 20 Go. Le cache du contexte s'y ajoute. Le tableau donne un ordre de grandeur de prudence ; la valeur qui fait foi est recommendedMaxWorkingSetSize, affichée par le moteur.

Ces ordres de grandeur sont des prudences, pas des mesures : un long contexte, un second modèle ou une application gourmande suffisent à changer la donne. Le guide dédié à la mémoire donne la méthode de calcul complète.

• VRAM et mémoire : combien en faut-il pour l'IA
• Quel LLM sur MacBook Pro M4

#5. Les options qui comptent

Flash Attention est en mode automatique par défaut : inutile de l'activer à la main dans la plupart des cas. Le cache KV se quantifie avec -ctk et -ctv, à condition que Flash Attention soit active ; il divise à peu près par deux la mémoire du cache en q8_0 par rapport à f16, au prix d'une légère perte de précision qu'il vaut mieux vérifier sur vos usages. Le guide dédié détaille le compromis.

• Quantifier le KV cache pour gagner de la VRAM
• Flash Attention dans llama.cpp

#6. Performances par puce : ce que mesurent les benchmarks publics

QuelLLM ne mesure pas ces machines. La référence est la discussion « Performance of llama.cpp on Apple Silicon M-series » du dépôt de llama.cpp, où chaque contributeur exécute le même test sur un LLaMA 7B en Q4_0. Le tableau ci-dessous en retient quelques lignes, avec les versions de llama.cpp de chaque mesure : celles des puces M1 à M4 datent de la même version, celle des M5 est plus récente.

Le plafond théorique est la bande passante divisée par le poids du modèle (3,56 Gio, soit 3,82 Go). Les puces Pro atteignent 71 à 82 % de ce plafond, la puce Max seulement 58 % : à partir d'un certain niveau, la mémoire n'est plus le seul frein, et payer plus de bande passante rapporte moins que ce que la fiche technique laisse croire.

Trois enseignements. La génération suit la bande passante : le M3 Pro, à 150 Go/s, est moins rapide que le M2 Pro à 200 Go/s, malgré une génération de puce plus récente. Les puces Max, à bande passante bien plus haute, dominent. Enfin, la lecture du prompt a fait un bond avec les M5 : 1 620,64 tokens/s pour un M5 Pro, contre 439,78 pour un M4 Pro de même nombre de cœurs GPU, soit 3,7 fois plus. Cet écart compte pour les longs documents et le RAG, beaucoup moins pour le chat.

Une bonne habitude avant de conclure qu'un Mac est lent : relancer le même modèle avec -ngl 0, puis avec la valeur par défaut, et comparer. L'écart entre les deux montre ce que le GPU apporte réellement sur votre machine, et confirme que le calcul passe bien par Metal. Notez aussi la version de llama.cpp utilisée : les optimisations Metal évoluent vite, et un binaire ancien peut être nettement moins rapide qu'une version récente.

#Dépannage : les erreurs courantes

• MLX vs llama.cpp sur Mac : qui gagne en 2026 ?
• Compiler llama.cpp avec CUDA
• Quels modèles pour 32 Go de mémoire

• Source : dépôt officiel de llama.cpp
• Source : documentation de compilation de llama.cpp
• Source : benchmark public sur Apple Silicon
• Source : discussion sur la limite de mémoire GPU des Mac