Accueil › Glossaire › llama.cpp

llama.cpp

llama.cpp est une bibliothèque open source en C/C++ qui permet d’exécuter l’inférence de LLM (Large Language Models) sur une très large gamme de matériel, du simple CPU de laptop aux GPU NVIDIA haut de gamme, en passant par les puces Apple Silicon et les accélérateurs AMD.

C’est le projet qui a démocratisé l’inférence locale de modèles de langage. Avant llama.cpp, faire tourner un LLM nécessitait un GPU puissant et un environnement Python avec PyTorch. Depuis mars 2023, date de sa création par Georgi Gerganov, llama.cpp a prouvé qu’un modèle de 7 milliards de paramètres pouvait fonctionner de manière fluide sur un MacBook, un PC gamer, voire un Raspberry Pi, grâce à une implémentation C/C++ pure sans dépendances lourdes et à des techniques de quantification agressives. Le projet cumule plus de 98 000 stars sur GitHub et constitue le moteur d’inférence sous-jacent de la plupart des outils d’IA locale comme Ollama, GPT4All et LM Studio.

Pourquoi llama.cpp est incontournable

llama.cpp occupe une position unique dans l’écosystème IA : c’est le moteur d’inférence de référence pour l’IA locale. Presque tous les outils grand public qui vous permettent de faire tourner un LLM sur votre machine l’utilisent en sous-couche. Quand vous lancez ollama run llama3, c’est llama.cpp qui fait le travail. Quand GPT4All génère une réponse, c’est llama.cpp qui calcule les tokens. Quand un développeur lance un serveur d’inférence local avec une API compatible OpenAI, c’est encore llama.cpp qui tourne derrière.

Cette position dominante s’explique par plusieurs facteurs. Le premier est la performance : l’implémentation C/C++ avec des optimisations assembleur pour chaque architecture CPU (AVX, NEON, SVE, AMX) et des backends GPU natifs (CUDA, Metal, Vulkan) offre des vitesses de génération que les frameworks Python ne peuvent pas égaler sur du matériel grand public. Le second est l’absence de dépendances : pas besoin de Python, de PyTorch, de CUDA Toolkit complet. Un binaire compilé et un fichier modèle suffisent. Le troisième est la quantification : llama.cpp a popularisé et perfectionné les techniques de quantification qui permettent de réduire la taille des modèles de 50 à 80% avec une perte de qualité minime.

Concepts clés

ggml : la bibliothèque de tenseurs

llama.cpp repose sur ggml, une bibliothèque de tenseurs écrite en C par Georgi Gerganov. ggml joue pour llama.cpp le rôle que PyTorch ou TensorFlow jouent pour l’entraînement de modèles, mais elle est optimisée exclusivement pour l’inférence. Elle fournit les opérations matricielles de base (multiplication, attention, normalisation) implémentées avec des instructions SIMD spécifiques à chaque architecture matérielle.

ggml est aussi le terrain d’expérimentation pour les nouveaux backends matériels : chaque fois qu’un nouveau type d’accélérateur doit être supporté (Hexagon de Qualcomm, Ascend de Huawei via CANN, Intel via SYCL), c’est dans ggml que l’implémentation est ajoutée.

GGUF : le format de fichier

Le format GGUF (GGML Universal File) est le format binaire utilisé par llama.cpp pour stocker les modèles. Introduit en août 2023 pour remplacer les formats antérieurs (GGML, GGJT), GGUF stocke dans un seul fichier les poids du modèle (potentiellement quantifiés), les métadonnées (architecture, taille de contexte, type de quantification) et le vocabulaire du tokenizer.

GGUF est devenu un standard de fait. Hugging Face propose des outils en ligne pour convertir et quantifier des modèles au format GGUF directement depuis le navigateur (GGUF-my-repo, GGUF-my-LoRA). La plupart des modèles open source populaires sont disponibles en GGUF pré-quantifié sur le Hub.

Quantification : de la théorie à la pratique

La quantification est ce qui rend l’inférence locale viable. Un modèle de 7 milliards de paramètres en FP16 (précision flottante 16 bits) pèse environ 14 Go et nécessite autant de RAM ou de VRAM. Quantifié en 4 bits (Q4), le même modèle descend à environ 4 Go, ce qui le rend exécutable sur un laptop standard.

llama.cpp supporte une gamme étendue de formats de quantification :

Les « K-quants » (Q4_K_M, Q5_K_M, Q6_K) sont une innovation majeure de llama.cpp. Contrairement aux quantifications uniformes (Q4_0) qui appliquent le même nombre de bits à toutes les couches, les K-quants allouent plus de bits aux couches sensibles (attention) et moins aux couches moins critiques, ce qui améliore la qualité à taille égale.

Installation

Installation rapide

llama.cpp peut être installé de plusieurs façons. La méthode la plus rapide dépend de votre OS :

Pour les binaires pré-compilés, la page Releases du dépôt GitHub propose des builds pour chaque plateforme et backend (CUDA 12.4, CUDA 13.1, ROCm 7.2, OpenVINO, macOS ARM/x64, etc.). Le dernier build au moment de la rédaction est le b8429 (19 mars 2026).

Compilation avec accélération GPU

Pour activer un backend GPU lors de la compilation depuis les sources, passez le flag correspondant à CMake :

Utilisation : les outils principaux

llama-cli : le chat en ligne de commande

llama-cli est l’outil en ligne de commande pour interagir avec un modèle en mode conversationnel. L’utilisation la plus simple :

Le flag -cnv active le mode conversation. Les modèles qui embarquent un chat template dans leurs métadonnées l’utilisent automatiquement. Pour les autres, vous pouvez spécifier un template via --chat-template.

llama-server : le serveur API

C’est probablement l’outil le plus utilisé en production. llama-server lance un serveur HTTP qui expose des endpoints compatibles avec l’API OpenAI (/v1/chat/completions, /v1/completions, /v1/embeddings). Tout outil ou SDK conçu pour l’API OpenAI peut donc se connecter à llama-server en changeant simplement l’URL de base.

llama-server inclut aussi une interface web minimaliste accessible via le navigateur à l’adresse du serveur. Elle permet de tester le modèle sans aucun client externe.

llama-quantize : convertir et quantifier

Si vous avez un modèle en FP16 ou F32 au format GGUF et que vous souhaitez le quantifier, llama-quantize fait le travail :

Pour convertir un modèle depuis le format PyTorch/Safetensors (Hugging Face) vers GGUF, utilisez les scripts Python fournis dans le dépôt (convert_hf_to_gguf.py). Hugging Face propose aussi l’outil en ligne GGUF-my-repo qui fait cette conversion directement dans le navigateur.

Backends matériels : le panorama complet

L’un des atouts majeurs de llama.cpp est le nombre de backends supportés. Voici un panorama complet :

La possibilité d’offloader partiellement les couches du modèle est une fonctionnalité précieuse. Si votre GPU n’a pas assez de VRAM pour charger le modèle entier, vous pouvez spécifier le nombre de couches à envoyer sur le GPU avec -ngl. Les couches restantes sont calculées sur CPU. Par exemple, avec un modèle de 32 couches et un GPU de 6 Go de VRAM, vous pourriez offloader 20 couches sur GPU et garder 12 sur CPU. C’est plus lent qu’un offload complet, mais nettement plus rapide qu’une inférence 100% CPU.

Fonctionnalités avancées

Décodage spéculatif

Le décodage spéculatif est une technique d’accélération qui utilise un petit modèle « draft » (par exemple 1-3B paramètres) pour générer rapidement des tokens candidats, puis le gros modèle valide ou rejette ces tokens en une seule passe. Quand le taux d’acceptation est élevé (typiquement 60-80% pour des modèles de la même famille), le gain de vitesse peut atteindre 2 à 3×.

Flash Attention

Depuis avril 2024, llama.cpp intègre Flash Attention, une implémentation optimisée du mécanisme d’attention qui réduit significativement la consommation mémoire et accélère le traitement des longs contextes. Flash Attention est activé par défaut sur les backends qui le supportent (CUDA, Metal).

Quantification du KV-cache

Le KV-cache (key-value cache) stocke les résultats intermédiaires de l’attention pour éviter de les recalculer à chaque token. Sur les longs contextes, ce cache peut consommer plusieurs Go de mémoire. llama.cpp permet de quantifier le KV-cache à la volée (en Q8_0 ou Q4_0), ce qui réduit sa taille de 50 à 75% avec un impact minimal sur la qualité.

Grammaires et structured output

llama.cpp supporte les grammaires GBNF (Grammar-Based Notation Format) pour contraindre la sortie du modèle. Vous pouvez forcer le modèle à produire exclusivement du JSON valide, du XML, ou tout autre format structuré. C’est indispensable pour les applications qui intègrent un LLM dans un pipeline de traitement automatisé.

Support multimodal

Depuis l’introduction de la bibliothèque libmtmd en avril 2025, llama.cpp supporte les modèles multimodaux (texte + images). Les modèles vision comme LLaVA, Qwen-VL, ou MiniCPM-V peuvent être exécutés localement, permettant de décrire des images ou de répondre à des questions visuelles.

Support Android et ChromeOS

Depuis décembre 2025, llama.cpp propose une accélération complète sur Android et ChromeOS via des bindings GUI natifs. Cela va au-delà de l’ancienne méthode qui consistait à cross-compiler et exécuter le CLI via ADB, en permettant le développement d’applications mobiles natives intégrant l’inférence LLM.

L’écosystème llama.cpp

llama.cpp a engendré un écosystème riche d’outils et de bindings :

Le fait que llama.cpp soit sous licence MIT et que ggml ait rejoint Hugging Face garantit la pérennité du projet et son intégration profonde dans l’écosystème open source. Hugging Face Inference Endpoints supporte désormais GGUF nativement.

Bindings Python : llama-cpp-python

Pour les développeurs Python, le package llama-cpp-python offre une interface haut niveau avec un serveur API compatible OpenAI intégré :

Le package supporte aussi le chargement direct depuis Hugging Face via Llama.from_pretrained(), les fichiers GGUF shardés, le streaming de tokens, les embeddings, et la quantification du KV-cache.

Performance et benchmarks

Vitesse de génération typique

Les performances varient énormément selon le matériel, le modèle et le format de quantification. Voici des ordres de grandeur pour un modèle 7B en Q4_K_M :

NVIDIA a annoncé au CES 2026 des optimisations pour llama.cpp permettant des gains allant jusqu’à 35% sur la vitesse de génération grâce au support NVFP4, à l’échantillonnage GPU des tokens, et à des améliorations de gestion de la mémoire.

Architectures de modèles supportées

llama.cpp ne se limite plus aux modèles LLaMA. Le projet supporte la quasi-totalité des architectures populaires de LLM :

Parmi les architectures supportées, on trouve LLaMA (toutes versions Meta), Mistral et Mixtral (dense et MoE), Phi (Microsoft, versions 2/3/4), Gemma (Google), Qwen (Alibaba, y compris les variantes MoE comme Qwen3.5MoE), Command-R (Cohere), StarCoder (BigCode), Falcon, GPT-NeoX, StableLM, InternLM, DeepSeek (y compris les distillations R1), Granite (IBM), OLMoE, et bien d’autres. Le fichier HOWTO-add-model.md du dépôt documente la procédure pour ajouter le support d’une nouvelle architecture.

Historique du projet

Georgi Gerganov a créé llama.cpp le 10 mars 2023, quelques semaines après la publication des modèles LLaMA par Meta. L’objectif initial était de faire tourner LLaMA 7B sur un MacBook en quantification 4-bit, sans GPU dédié. Le projet a rapidement explosé, attirant des centaines de contributeurs.

Les étapes clés du projet incluent l’introduction du format GGUF en août 2023, le support Vulkan en septembre 2023 (ouvrant l’accélération GPU aux cartes AMD), l’arrivée de Flash Attention en avril 2024, le support multimodal via libmtmd en avril 2025, et l’accélération native Android/ChromeOS en décembre 2025.

En février 2025, Georgi Gerganov a annoncé que ggml.ai rejoignait Hugging Face. Le projet est depuis maintenu sous l’organisation ggml-org sur GitHub, avec une mission déclarée de rendre l’IA locale facile et efficace pour tous. Le dépôt compte plus de 1 000 contributeurs et les builds sont publiés quasi-quotidiennement (le build b8429 date du 19 mars 2026).

Limites et points d’attention

Malgré sa domination, llama.cpp a des limites à connaître. La première est la complexité de configuration : contrairement à Ollama qui abstrait tout, llama.cpp expose de nombreux paramètres (nombre de couches GPU, taille de batch, type de KV-cache, threads CPU) qui nécessitent un réglage pour obtenir des performances optimales. La courbe d’apprentissage est non négligeable pour un débutant.

La deuxième est la compatibilité Vulkan : le backend Vulkan, bien qu’universel, ne supporte pas les K-quants ni les I-quants, ce qui limite les options pour les utilisateurs AMD qui ne veulent pas installer ROCm (plus lourd à configurer).

La troisième est la gestion mémoire : sur des machines avec peu de RAM, il est facile de provoquer un crash en chargeant un modèle trop gros ou en configurant un contexte trop large. Le contexte par défaut a été réduit à 4096 tokens pour les builds CPU-only afin d’éviter ces situations.

La quatrième est le rythme de développement : avec des builds quasi-quotidiens et des changements fréquents de l’API interne, les projets qui dépendent directement de llama.cpp (et non d’une couche d’abstraction comme Ollama) doivent suivre de près les mises à jour et gérer les breaking changes occasionnels.