llama.cpp vs vLLM vs Exllama

#Un moteur d'inférence : ce qui change vraiment entre eux

Un moteur d'inférence transforme des tokens d'entrée en tokens de sortie. Les applications que l'on installe (Ollama, LM Studio, Jan) en embarquent un ; les serveurs de production (vLLM, SGLang) en sont un. Trois différences se répercutent sur votre usage : les formats de modèles acceptés, le matériel utilisable, et la façon de gérer plusieurs requêtes en même temps.

#Le format du modèle décide du moteur possible

Avant de comparer des vitesses, vérifiez le format sous lequel le modèle que vous voulez est publié. Un fichier GGUF se charge dans llama.cpp et donc dans Ollama, LM Studio et Jan. Des poids Hugging Face en FP16, FP8 ou quantifiés en AWQ ou GPTQ se chargent dans vLLM ou SGLang. Un modèle converti pour MLX se charge avec MLX LM sur Mac, et un modèle EXL3 avec ExLlamaV3. Changer de moteur revient souvent à retélécharger le modèle dans un autre format.

#llama.cpp : le standard portable

llama.cpp est une implémentation en C/C++ sans dépendance, dont l'objectif affiché est l'inférence avec un minimum de configuration sur un large éventail de matériel. Apple Silicon y est traité en priorité (NEON, Accelerate, Metal), les CPU x86 sont pris en charge avec AVX, AVX2, AVX512 et AMX, et les GPU NVIDIA (CUDA), AMD (HIP), Vulkan et SYCL sont supportés. Il propose des quantifications de 1,5 à 8 bits et l'inférence hybride CPU et GPU, qui permet d'exécuter un modèle plus grand que la VRAM disponible.

Idée reçue à corriger : llama.cpp ne se limite pas à une requête à la fois. Son serveur annonce la génération parallèle multi-utilisateurs et le batching continu, activé par défaut, avec des emplacements (slots) réglés par le paramètre --parallel. Il sert donc correctement une petite équipe ; ce qu'il ne cherche pas à égaler, ce sont les fonctions de production à grande échelle de vLLM.

Forces

Portabilité (Mac, Linux, Windows, Android), formats GGUF omniprésents, hybride CPU et GPU, faible dépendance.

Limites

Pas de fonctions de déploiement distribué comparables à celles de vLLM ; réglages (contexte, slots, couches sur GPU) à connaître.

Écosystème

Point d'appui d'Ollama et de LM Studio, cité aussi par Jan.

Pour la compilation avec CUDA, Metal ou Vulkan, consultez les guides de compilation ; le guide complet sur llama.cpp détaille l'usage.

#vLLM : le serveur pour beaucoup d'utilisateurs

vLLM est une bibliothèque d'inférence et de service née au Sky Computing Lab de l'université de Californie à Berkeley. Elle repose sur PagedAttention, qui gère la mémoire des clés et valeurs de l'attention par pages, et sur le batching continu, complétés par le préremplissage par morceaux et le cache de préfixes. Elle annonce des formats FP8, INT4, GPTQ, AWQ et GGUF, l'API compatible OpenAI et une prise en charge des GPU NVIDIA, AMD et Intel ainsi que des CPU x86, ARM et PowerPC.

Deux idées reçues à corriger. Premièrement, vLLM n'est plus réservé à NVIDIA ni sans CPU : son dépôt indique la prise en charge de plusieurs GPU et CPU. Deuxièmement, il n'est plus sans GGUF : sa documentation le décrit comme très expérimental et peu optimisé, utilisable surtout pour réduire l'empreinte mémoire. Pour un usage GGUF quotidien, llama.cpp reste la voie normale.

Forces

Débit sous charge, mémoire du cache gérée par pages, API compatible OpenAI, parallélisme (tensor, pipeline, expert), nombreux formats.

Limites

Plus lourd à installer et à régler que llama.cpp ; pensé pour des serveurs GPU ; le GGUF n'est pas son terrain.

Écosystème

Le choix par défaut quand plusieurs personnes ou applications interrogent le même modèle en même temps.

Le guide sur vLLM explique ce qu'est le moteur ; celui sur son déploiement en production détaille les réglages et la supervision.

#ExLlama : V2 archivé, V3 en développement

Le dépôt d'ExLlamaV2 porte une note indiquant que le projet est archivé pour le moment et que le développement continue dans ExLlamaV3. Beaucoup de comparatifs, dont l'ancienne version de cette page, présentent encore V2 comme l'option de pointe. Le dépôt d'ExLlamaV3 annonce le format de quantification EXL3, l'inférence parallèle par tenseurs et par experts, le délestage CPU pour les modèles à experts, le batching continu, le décodage spéculatif, et une API compatible OpenAI via TabbyAPI, son serveur recommandé.

ExLlamaV3 vise les GPU grand public, pas les serveurs de production ni les Mac. Si vous avez une carte NVIDIA et que vous voulez le meilleur compromis entre qualité et taille, la quantification EXL3 mérite un essai ; vérifiez d'abord que votre modèle figure dans la liste d'architectures du dépôt.

#SGLang, MLX LM et les autres

SGLang

Cadre de service décrit comme visant faible latence et fort débit, de un GPU à de grands clusters. Il annonce RadixAttention pour le cache de préfixes, le batching continu, PagedAttention et le décodage spéculatif. Il concurrence vLLM sur les serveurs ; le guide dédié le détaille.

MLX LM

Paquet Python pour générer du texte et affiner des modèles sur Apple Silicon avec MLX. Il ne fonctionne pas hors Mac. Le guide MLX contre llama.cpp compare les deux sur Mac.

TensorRT-LLM

Moteur de NVIDIA, très performant sur ses cartes mais plus contraignant à mettre en place ; à envisager seulement pour une flotte NVIDIA en production.

#Que disent les mesures publiées

Les débits dépendent du matériel, du modèle, de la quantification, de la longueur des requêtes et de la version du moteur, et évoluent chaque mois. Ce guide ne présente donc aucune mesure maison et vous invite à vous méfier des tableaux de tokens par seconde sans protocole. Une source de tiers publie toutefois un protocole complet : Red Hat, en août 2025.

À lire avec réserves : l'article est rattaché aux produits Red Hat AI, donc issu d'un acteur commercial du domaine ; les tests portent sur Ollama et non sur llama.cpp directement, avec des réglages par défaut ; ils datent de plusieurs versions. Le message robuste est qualitatif : sous forte concurrence, un moteur de service à batching agressif surpasse une application pensée pour un utilisateur. Pour un usage seul, la différence de débit n'est pas ce qui vous pénalise.

#Mémoire : ce que chaque moteur réserve

La mémoire d'un modèle se compose des poids, du cache de contexte (KV) et d'une marge. Les poids se calculent : un modèle de 8 milliards de paramètres occupe environ 16 Go en FP16 (8 milliards fois 2 octets) et environ 5 Go en Q4, repère du site. Le cache de contexte croît avec la longueur de conversation et le nombre de requêtes simultanées.

Le point à retenir : vLLM réserve la mémoire dès le départ, ce qui le rend efficace pour servir mais peu adapté à une carte partagée avec d'autres applications. Le paramètre gpu_memory_utilization se réduit si la carte sert aussi à autre chose.

#Quel moteur pour quel usage

Les moteurs peuvent cohabiter : Ollama pour le chat de tous les jours, vLLM lancé à la demande pour traiter un lot d'extractions. Il n'y a pas de raison de n'en garder qu'un si les usages diffèrent. Prévoyez seulement l'espace disque pour un même modèle stocké dans deux formats, par exemple un fichier GGUF pour le chat et des poids Hugging Face pour le serveur.

• Ollama contre llama.cpp
• vLLM : le guide complet
• SGLang comme serveur LLM local
• MLX contre llama.cpp sur Mac
• llama.cpp : le guide complet
• Ollama, LM Studio, Jan ou GPT4All

• Source : dépôt de llama.cpp
• Source : dépôt de vLLM
• Source : dépôt d'ExLlamaV2
• Source : Red Hat, Ollama contre vLLM