llama.cpp

llama.cpp est un moteur d'inférence C/C++ pour les grands modèles de langage, créé par Georgi Gerganov et publié pour la première fois en mars 2023. Ce qui a commencé comme un hack d'une soirée pour faire tourner le modèle Llama de Meta sur un MacBook sans GPU est devenu l'infrastructure fondamentale de presque tous les outils LLM locaux existants : Ollama, LM Studio, Jan et AnythingLLM utilisent tous llama.cpp comme backend d'inférence principal. Le projet est sous licence MIT, compte plus de 108 000 étoiles sur GitHub et a publié plus de 5 000 versions. Il fonctionne sur Apple Silicon (Metal), les GPU NVIDIA (CUDA), les GPU AMD (HIP), Vulkan pour une prise en charge multi-fournisseurs des GPU, et sur CPU pur avec des optimisations pour les jeux d'instructions AVX/AVX2/AVX512.

Le moteur prend en charge plus de 50 architectures de modèles, y compris les variantes LLaMA, Mistral, Mixtral, Gemma, Phi, DeepSeek et Qwen. Il utilise le format de fichier GGUF, que Gerganov a introduit en août 2023 et qui est depuis devenu la norme universelle pour la distribution de LLM locaux. Les options de quantification vont de 1,5 bit à 8 bits, permettant à un modèle de 7 milliards de paramètres de tenir dans moins de 4 Go de RAM. Le projet intègre un serveur HTTP complet compatible OpenAI (llama-server), une interface de chat en ligne de commande (llama-cli), des outils de benchmarking et la prise en charge de l'inférence multimodale via la bibliothèque libmtmd ajoutée en avril 2025. L'empreinte d'installation est inférieure à 90 Mo. Il n'y a aucune dépendance au cloud, aucun compte n'est requis et aucune donnée ne quitte la machine qui l'exécute.

Ce que fait réellement llama.cpp en mai 2026

La version actuelle (b9012, 3 mai 2026) fournit une pile d'inférence locale complète. Le point d'entrée principal pour la plupart des développeurs est llama-server, qui lance une API compatible OpenAI sur localhost:8080 avec une seule commande. Tout client conçu pour le SDK OpenAI fonctionne sans modification, ce qui signifie que llama.cpp s'intègre directement dans les plugins VS Code, les scripts Python ou toute application utilisant /v1/chat/completions.

La quantification est la capacité technique fondamentale qui rend llama.cpp viable sur du matériel grand public. Le format GGUF regroupe le modèle quantifié, le vocabulaire et la configuration de l'architecture dans un seul fichier. La recommandation par défaut pour la plupart des cas d'usage est Q4_K_M (environ 4,5 Go pour un modèle 7B), qui offre une perte de qualité négligeable par rapport à la version en pleine précision tout en fonctionnant sur un MacBook avec 8 Go de RAM à plus de 40 tokens par seconde. Pour les appareils limités, le format Q1_0 d'avril 2026 permet de faire tenir des modèles performants dans moins de 1 Go. Pour les utilisateurs privilégiant la qualité, Q8_0 ou Q5_K_M sont disponibles.

Le déchargement matériel (hardware offloading) est géré automatiquement. Lorsqu'un modèle dépasse la VRAM disponible du GPU, llama.cpp le divise : les couches qui rentrent vont sur le GPU, et le reste est traité sur la RAM du CPU. Les performances se dégradent progressivement au lieu d'échouer. Sur Apple Silicon, l'accélération Metal est native. Sur Linux avec du matériel NVIDIA, CUDA est utilisé par défaut. Un binaire unique peut être compilé avec la prise en charge de Vulkan pour fonctionner sur AMD, Intel Arc ou tout GPU compatible Vulkan sans pilotes spécifiques au fournisseur.

Les versions d'avril 2026 ont ajouté le parallélisme de tenseurs (tensor parallelism) agnostique au backend via NCCL et RCCL, qui répartit les opérations individuelles sur plusieurs GPU simultanément plutôt que de simplement diviser les couches du modèle. Pour les configurations multi-GPU, cela produit des gains de débit de 3 à 4 fois supérieurs par rapport à l'ancienne approche de partitionnement des couches et rend llama.cpp de plus en plus viable pour les petits déploiements en production, et non plus seulement pour un usage personnel. Le même mois, la rotation du cache KV de Walsh-Hadamard a été intégrée, faisant passer les scores du benchmark de raisonnement AIME25 de 0,0 % à 21,7 % sous la quantification Q4_0, une amélioration significative pour l'inférence quantifiée sur des tâches de raisonnement à plusieurs étapes.

Le téléchargement de modèles s'intègre directement avec Hugging Face et Docker Hub. Passer un ID de modèle Hugging Face à llama-server télécharge le fichier GGUF et démarre le serveur. Étant donné que Hugging Face indexe nativement les fichiers GGUF, cela fonctionne pour des milliers de modèles quantifiés par la communauté sans aucune étape de conversion.

"J'ai géré le dataset 13B sur un simple Pi4 8Go... la réalité actuelle des LLM reproductibles à la maison sur tout ce que vous avez sous la main" - cameron_b, Hacker News, septembre 2023

Où se situe llama.cpp par rapport à vLLM et MLX

llama.cpp vs vLLM : Ces deux outils servent des extrémités différentes du spectre de déploiement et sont rarement en concurrence pour le même cas d'usage. vLLM est un framework d'inférence basé sur Python et axé sur les serveurs GPU, construit autour du traitement par lots continu (continuous batching) et de PagedAttention, un mécanisme de gestion de la mémoire cache KV au niveau de la page. Sur un NVIDIA H200 à charge maximale, vLLM offre 35 fois le débit de requêtes et 44 fois la production de tokens par seconde par rapport à llama.cpp, mais cette comparaison ne tient qu'à partir de 10 utilisateurs simultanés sur du matériel d'entreprise. Pour les charges de travail à utilisateur unique ou à faible concurrence, la latence inter-token de llama.cpp est considérablement plus faible car il ne traite pas les requêtes par lots. vLLM nécessite CUDA et ne fonctionne pas de manière significative sur du matériel grand public, des ordinateurs de bureau Windows ou Apple Silicon. llama.cpp fonctionne partout. Comparez avec vLLM si vous déployez une API de production sur un serveur GPU dédié avec plus de 5 utilisateurs simultanés ; llama.cpp est le bon choix pour tout le reste.

llama.cpp vs MLX : MLX est le propre framework d'apprentissage automatique d'Apple, optimisé pour l'architecture de mémoire unifiée des puces Apple Silicon. Étant donné que le CPU et le GPU partagent la même mémoire physique sur Apple Silicon, MLX réalise des opérations de tenseurs sans copie (zero-copy), éliminant ainsi la surcharge de transfert de données que subit llama.cpp lors du déplacement des données entre les shaders Metal. Sur un M2 Pro exécutant Llama 3.1 8B en Q4_K_M, MLX atteint environ 45 à 58 tokens par seconde contre 38 à 48 pour llama.cpp. Pour les flux de développement exclusivement sur Mac, cet écart compte. MLX prend également en charge le fine-tuning natif LoRA et QLoRA, ce que llama.cpp ne fait pas. La limite critique : MLX est exclusif à Apple Silicon. Il ne fonctionne pas sur Windows, Linux ou Android. Il nécessite également une conversion de modèle à partir du format GGUF, et les modèles de la communauté apparaissent souvent d'abord en GGUF, les conversions MLX accusant un retard de quelques heures ou jours. llama.cpp prend en charge dès le premier jour les nouvelles versions de la communauté et fonctionne sur n'importe quel matériel.

"Je viens de passer d'Ollama et la vitesse de génération de tokens ainsi que le gain d'efficacité ont été exceptionnels." - avis d'utilisateur, itsfoss.com, 2025

À quoi ressemble le flux de travail d'inférence quotidien

Le chemin minimal vers un modèle fonctionnel se fait en trois étapes : téléchargez un fichier GGUF depuis Hugging Face, exécutez llama-server -m model.gguf et interrogez localhost:8080/v1/chat/completions. Le serveur démarre en moins de cinq secondes sur un stockage rapide. L'arrêt et le redémarrage avec un modèle différent prennent le même temps. Pas de gestion de démon, pas de registre de modèles, pas de service en arrière-plan consommant des ressources lorsqu'il est inactif.

Pour une utilisation interactive, llama-cli -m model.gguf --interactive ouvre une session de chat dans le terminal. Les contraintes de grammaire vous permettent de forcer une sortie JSON ou de restreindre les réponses à un schéma défini, ce qui est utile pour les pipelines d'extraction de données structurées. La longueur de la fenêtre de contexte est configurable via un indicateur de ligne de commande, limitée par la RAM disponible.

L'interface web, introduite en 2024, fournit une interface de chat basée sur le navigateur et hébergée par llama-server. Elle prend en charge les conversations à plusieurs tours, la configuration du prompt système et l'ajustement des paramètres sans toucher à la ligne de commande. Elle n'est pas aussi aboutie que l'interface de LM Studio, mais elle fonctionne dans n'importe quel navigateur et ne nécessite aucune installation au-delà du binaire du serveur.

Pour les utilisateurs créant des applications par-dessus llama.cpp, des plugins VS Code et Vim/Neovim sont fournis avec le projet, acheminant les requêtes de complétion de code via le point de terminaison local llama-server. La couche de compatibilité OpenAI signifie que tout outil acceptant une URL de base personnalisée, tel que AnythingLLM ou Continue.dev, se connecte sans modification de configuration.

À qui s'adresse llama.cpp

llama.cpp cible les développeurs et les utilisateurs techniques qui souhaitent un contrôle total sur leur pile d'inférence et sont prêts à passer 30 à 60 minutes sur la configuration initiale pour éviter la dépendance au cloud, les coûts par token ou les couches d'abstraction ajoutées par les outils de plus haut niveau. Les utilisateurs soucieux de la confidentialité qui ne peuvent ou ne veulent pas envoyer de données à des API externes s'appuient dessus. Les chercheurs menant des expériences sur du matériel grand public l'utilisent pour accéder aux mêmes poids de modèles que ceux servis par les fournisseurs cloud, avec un coût marginal nul par requête. Les développeurs de systèmes embarqués et d'edge computing le compilent pour Raspberry Pi, Android (accélération native via Qualcomm Hexagon depuis avril 2026) et les appareils ChromeOS.

L'importance de l'écosystème est difficile à surestimer : même les utilisateurs qui ne touchent jamais directement à llama.cpp l'exécutent probablement s'ils utilisent un outil frontend LLM local. Comprendre ce qu'est llama.cpp aide les utilisateurs à comprendre où leur inférence se produit réellement, pourquoi certains niveaux de quantification GGUF fonctionnent mieux sur leur matériel, et comment déboguer les problèmes de performances que leur interface graphique ne révèle pas.

Les utilisateurs qui associent directement llama.cpp aux modèles Llama de Meta bénéficient de la compatibilité la plus complète, car le projet a été initialement conçu pour Llama et les deux restent étroitement alignés sur la prise en charge de nouvelles architectures. L'écosystème de modèles communautaires sur Hugging Face, où des milliers de quantifications GGUF existent pour chaque version majeure à poids ouverts, fait de llama.cpp la rampe d'accès pour tout nouveau modèle dans les heures suivant sa sortie.

Ce que llama.cpp n'est pas

llama.cpp n'est pas une application graphique. Les utilisateurs s'attendant à une gestion de modèles par pointer-cliquer trouveront la CLI peu familière. LM Studio et Jan existent précisément pour ajouter cette couche d'interface graphique par-dessus le moteur d'inférence de llama.cpp.

Ce n'est pas un serveur d'inférence multi-utilisateurs à grande échelle. Le moteur traite les requêtes de manière séquentielle. À partir de cinq utilisateurs simultanés, la latence de la file d'attente croît de manière exponentielle. Pour servir une API en production avec de réels besoins de concurrence, vLLM ou un point de terminaison hébergé est plus approprié.

Ce n'est pas un outil de fine-tuning. Il n'y a pas de boucle d'entraînement, pas d'implémentation LoRA et pas de pipeline de dataset. Si vous avez besoin d'affiner un modèle, ce travail s'effectue dans un framework Python (PyTorch, MLX, Axolotl) et les poids résultants sont ensuite convertis en GGUF pour l'inférence.

Ce n'est pas un hub de modèles ou un outil de découverte. llama.cpp ne sélectionne ni ne recommande de modèles. Les utilisateurs trouvent des modèles sur Hugging Face ou via des ressources communautaires comme r/LocalLLaMA, puis téléchargent directement les fichiers GGUF.

Il convient également d'être clair sur l'attribution dans l'écosystème. De nombreux utilisateurs d'Ollama ou de LM Studio ne réalisent pas que ces outils dépendent de llama.cpp pour leur inférence. Une frustration persistante de la communauté, apparue dans l'issue GitHub #3185 et discutée à plusieurs reprises sur Hacker News, est qu'Ollama ne crédite pas clairement llama.cpp dans sa documentation ou son interface utilisateur. Cela a de l'importance car les problèmes de performances, le comportement de quantification et les architectures de modèles prises en charge sont tous des propriétés de llama.cpp, et non de l'outil wrapper. Savoir que llama.cpp est le véritable moteur donne aux utilisateurs un vocabulaire pertinent pour le débogage et l'optimisation.

L'implication pratique : si vous choisissez entre Ollama et llama.cpp directement, vous ne choisissez pas entre différents moteurs d'inférence. Vous choisissez entre différents niveaux d'abstraction sur le même moteur d'inférence. Pour la plupart des utilisateurs, la simplicité d'Ollama l'emporte. Pour les développeurs qui ont besoin d'ajuster des paramètres, de créer des pipelines personnalisés ou d'exécuter des modèles que le registre d'Ollama ne propose pas, l'accès direct à llama.cpp est la bonne couche sur laquelle travailler.