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

#llama.cpp en bref

Le projet a été lancé en mars 2023 par Georgi Gerganov, avec un objectif simple : faire tourner le modèle LLaMA de Meta sur un MacBook, sans Python ni dépendance lourde. Il est publié sous licence MIT. Trois ans plus tard, le dépôt (passé sous l'organisation ggml-org) prend en charge des centaines d'architectures, et le format de fichier qu'il a défini en août 2023, le GGUF, est devenu le standard de fait pour distribuer un modèle quantifié.

Deux choix techniques expliquent ce succès. Le premier est la quantification : llama.cpp sait exécuter des poids compressés de 2 à 8 bits, ce qui fait tenir un modèle de 8 milliards de paramètres dans 5 Go au lieu de 16. Le second est le partage entre processeur et carte graphique : quand un modèle ne rentre pas entièrement en VRAM, une partie des couches reste en RAM et le reste part sur le GPU. C'est plus lent qu'un chargement complet, mais cela fonctionne, et peu de moteurs le proposent.

#Ce qu'il y a dans la boîte

llama-cli

Le chat en ligne de commande. Utile pour tester un modèle ou un réglage en quelques secondes.

llama-server

Un serveur HTTP avec une API compatible OpenAI et une interface web intégrée, sur le port 8080. C'est la pièce que la plupart des utilisateurs avancés font tourner en permanence.

llama-bench

L'outil de mesure. Il donne séparément la vitesse de lecture du prompt et la vitesse de génération, ce qui permet de comparer deux réglages sans se raconter d'histoires.

llama-quantize

Convertit un GGUF en précision complète vers une quantification plus légère (Q4_K_M, Q5_K_M, Q8_0).

• llama-server : monter une API OpenAI locale, pas à pas
• GGUF et safetensors : comprendre les formats de modèles

#Ce que les surcouches ajoutent, et cachent

Ollama, LM Studio et KoboldCpp apportent ce que llama.cpp ne fait pas : un catalogue de modèles, le téléchargement en une commande, une interface, le chargement et le déchargement automatiques. En échange, ils fixent des valeurs par défaut. Le tableau ci-dessous ne compare pas des performances, il indique qui décide de quoi.

La dernière ligne compte plus qu'il n'y paraît. Quand une nouvelle architecture de modèle sort, elle est d'abord prise en charge dans llama.cpp, puis dans les surcouches quelques jours ou semaines plus tard. Si vous voulez tester un modèle la semaine de sa publication, c'est souvent le seul chemin.

#Les quatre réglages qui changent tout

-ngl (n-gpu-layers)

Le nombre de couches du modèle placées en VRAM. La valeur 99 signifie « tout ce qui rentre ». Si le modèle dépasse votre VRAM, baissez ce nombre jusqu'à ce que le chargement passe : chaque couche laissée au CPU ralentit la génération, mais un modèle qui tourne à 8 tokens par seconde vaut mieux qu'un modèle qui ne démarre pas.

-c (ctx-size)

La fenêtre de contexte allouée. Le cache KV grandit avec elle : sur un modèle 8B, passer de 8 000 à 32 000 tokens coûte plusieurs Go de VRAM. Allouez ce dont vous avez besoin, pas le maximum annoncé par le modèle.

-fa (flash-attn)

Active Flash Attention, qui réduit la mémoire et accélère la lecture des longs prompts. C'est aussi un prérequis pour quantifier le cache KV.

--n-cpu-moe

Pour les modèles MoE, garde les experts d'un certain nombre de couches en RAM et laisse le reste sur le GPU. C'est ce qui permet de faire tourner un MoE de 30 ou 120 milliards de paramètres sur une carte de 16 Go à une vitesse utilisable.

• Flash Attention : l'activer dans llama.cpp, Ollama et vLLM
• Quantifier le cache KV pour gagner de la VRAM
• Répartir un modèle sur plusieurs GPU avec tensor-split

#Quel backend pour votre carte

llama.cpp se compile, ou se télécharge, pour un backend de calcul donné. Le bon choix dépend uniquement de votre matériel. Le tableau reprend les familles de notre base de 90 configurations.

• Compiler llama.cpp avec CUDA
• Compiler llama.cpp avec Metal sur Mac
• llama.cpp avec Vulkan, le backend universel

#Nos mesures avec llama.cpp

llama.cpp est le moteur de référence de notre banc de test, précisément parce qu'il tourne à l'identique sur toutes les plateformes. Voici les vitesses de génération relevées sur Llama 3.1 8B en Q4, contexte de 2 048 tokens, une seule requête, Flash Attention activée.

Deux lectures. D'abord, l'écart entre une RTX 3060 et un processeur seul est d'un facteur cinq à six : même une carte d'entrée de gamme change l'expérience. Ensuite, ces chiffres seraient pratiquement les mêmes dans Ollama ou LM Studio sur les mêmes machines, puisque le moteur de calcul est le même.

• Tous nos relevés : six machines, six modèles
• Notre méthode de mesure

#Rester sur Ollama ou passer à llama.cpp

• Ollama vs llama.cpp : le comparatif complet
• Sur Mac : MLX ou llama.cpp ?

#Démarrer en dix minutes

Nul besoin de compiler pour essayer. Des binaires précompilés sont publiés pour Windows, macOS et Linux à chaque version, et les gestionnaires de paquets font le reste. La commande ci-dessous télécharge un petit modèle depuis Hugging Face et ouvre l'interface web sur http://localhost:8080.

# macOS et Linux (Homebrew)
brew install llama.cpp

# Windows
winget install llama.cpp

# Télécharger un modèle et ouvrir l'interface web
llama-server -hf ggml-org/gemma-3-4b-it-GGUF -ngl 99 -c 8192

Pour un modèle du catalogue plus ambitieux, récupérez le fichier GGUF de votre choix et pointez dessus avec l'option -m. La compilation depuis les sources ne devient utile que pour activer un backend précis ou suivre le développement au jour le jour.

• Le dépôt officiel de llama.cpp sur GitHub
• Choisir un modèle dans le catalogue QuelLLM

#FAQ