llama.cpp et la quantification GGUF

llama.cpp et la quantification GGUF : faire tourner des LLM capables sur du matériel modeste

Ollama, vLLM ou LM Studio reposent tous, directement ou indirectement, sur le même moteur d’inférence : llama.cpp. Comprendre ce moteur et son format de poids GGUF, c’est sortir de la boîte noire et reprendre le contrôle sur le couple précision/coût. C’est aussi la clé pour héberger un modèle de qualité sur un serveur sans GPU dédié, ou sur une carte grand public.

Le problème : un LLM en pleine précision ne tient pas sur votre machine

Un modèle de 8 milliards de paramètres en précision native (FP16) pèse environ 16 Go, et un modèle de 70 milliards plus de 140 Go. Impossible à charger sur la majorité des serveurs auto-hébergés. La quantification répond à ce problème : elle réduit le nombre de bits utilisés pour stocker chaque poids du réseau, en acceptant une perte de précision contrôlée. On passe par exemple de 16 bits à 4 bits par poids, soit une division par quatre de l’empreinte mémoire.

GGUF : le format de poids qui a tout simplifié

GGUF (GGML Universal Format) est le format de fichier unique introduit par le projet llama.cpp. Un fichier .gguf contient tout ce qu’il faut pour charger et exécuter le modèle : les poids quantifiés, le vocabulaire du tokenizer, le gabarit de prompt (chat template) et les métadonnées. Ses avantages concrets sont les suivants :

Un seul fichier à télécharger et à déplacer, sans arborescence complexe.
Chargement mémoire-mappé (mmap) : le modèle n’est pas copié entièrement en RAM au démarrage, ce qui accélère le lancement.
Exécution mixte CPU/GPU : on peut décharger une partie des couches sur le GPU et laisser le reste sur le CPU, utile quand la VRAM est limitée.
Portabilité totale : le même fichier fonctionne sur Linux, macOS (Metal), Windows, ARM et x86.

Choisir le bon niveau de quantification

C’est la décision la plus importante. Les quantifications dites « K-quants » (suffixe _K) sont aujourd’hui la référence : elles répartissent intelligemment la précision entre les couches sensibles et les couches tolérantes. Voici un repère pratique :

Quantification	Bits / poids	Usage recommandé
`Q8_0`	8 bits	Qualité quasi identique au FP16, si la mémoire le permet
`Q6_K`	~6,5 bits	Excellent compromis, perte négligeable
`Q5_K_M`	~5,5 bits	Très bon équilibre qualité/taille
`Q4_K_M`	~4,5 bits	Le choix par défaut conseillé : meilleur rapport qualité/mémoire
`Q3_K_M / Q2_K`	2 à 3 bits	Dernier recours quand la mémoire est très contrainte, qualité dégradée

Règle simple : on descend en précision uniquement quand le modèle ne tient pas dans la mémoire disponible. En pratique, un Q4_K_M est le point de départ raisonnable pour la plupart des usages.

La matrice d’importance (imatrix), pour aller plus loin

Les quantifications les plus récentes peuvent être calibrées avec une matrice d’importance (imatrix) : on fait passer un échantillon de texte représentatif dans le modèle pour mesurer quels poids comptent le plus, puis on protège ces poids lors de la quantification. À taille de fichier égale, un modèle quantifié avec imatrix conserve nettement mieux ses capacités, en particulier aux basses précisions (2 à 3 bits). De nombreux modèles sont déjà publiés en versions IQ calibrées sur Hugging Face.

Lancer un serveur compatible OpenAI en quelques minutes

llama.cpp embarque un serveur HTTP qui expose une API compatible avec celle d’OpenAI. Il s’intègre donc directement avec LiteLLM, Open WebUI, LangGraph ou n’importe quel client existant :

# Récupérer et compiler avec accélération GPU (CUDA)
git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp
cmake -B build -DGGML_CUDA=ON
cmake --build build --config Release

# Lancer le serveur, en déchargeant 35 couches sur le GPU
./build/bin/llama-server \
  -m modele-Q4_K_M.gguf \
  --n-gpu-layers 35 \
  --ctx-size 8192 \
  --host 0.0.0.0 --port 8080

Le paramètre --n-gpu-layers est le levier central : il fixe combien de couches du réseau sont calculées sur le GPU. Le reste tourne sur le CPU. On l’ajuste jusqu’à saturer la VRAM disponible sans la dépasser, pour obtenir le meilleur débit possible.

Où placer llama.cpp dans une stack open source

llama.cpp est le socle bas niveau de l’inférence. Pour un poste de travail ou un petit serveur polyvalent, on l’utilise via Ollama, qui en simplifie la gestion. Pour un service à fort débit avec batching et beaucoup d’utilisateurs simultanés, on lui préfère vLLM ou SGLang, conçus pour le GPU. llama.cpp garde un avantage décisif dans deux cas : l’exécution sur CPU ou matériel hétérogène, et le déploiement sur des machines aux ressources très limitées (Raspberry Pi, mini-PC, serveurs sans GPU).

À retenir

La quantification GGUF n’est pas un compromis subi, c’est un réglage maîtrisable. En choisissant la bonne précision pour votre budget mémoire, vous faites tourner un modèle réellement utile là où la pleine précision serait hors de portée. Le couple llama.cpp et GGUF reste, en 2026, la voie la plus robuste et la plus portable pour l’inférence LLM auto-hébergée et souveraine.