L'état des moteurs d'inférence LLM en 2026 : vLLM, llama.cpp, Aphrodite, LMDeploy

Il y a quelques années, exécuter un grand modèle de langage vous-même signifiait un script de recherche, beaucoup de mémoire GPU, et une prière. Aujourd'hui, c'est choisir parmi un petit ensemble de moteurs d'inférence matures et spécialisés — et le choix importe, car ce sont des outils véritablement différents optimisés pour des situations différentes. Avez-vous besoin de servir des milliers d'utilisateurs concurrents à débit maximal, ou d'exécuter un modèle sur votre portable sans GPU ? Avez-vous besoin de charger un modèle quantifié communautaire dans un format exotique, ou faire tenir un modèle de 70 milliards de paramètres dans une seule carte graphique grand public ? La réponse honnête à « quel est le meilleur moteur d'inférence LLM en 2026 » est qu'il n'en existe pas un seul ; il existe un portefeuille, et bien choisir signifie comprendre ce que fait chaque moteur pour.

Ce guide mappe le paysage d'inférence en 2026 par le travail que chaque moteur fait le mieux. Les projets open-source majeurs — vLLM, llama.cpp, Moteur Aphrodite, LMDeploy, SGLang, et ExLlamaV3 — ont chacun une personnalité claire, et connaître ces personnalités est comment vous évitez de forcer le mauvais outil sur votre charge de travail. En chemin, il couvre les concepts qui conduisent réellement la décision : débit versus latence, quantification, et adéquation du matériel.

Les concepts qui conduisent le choix

Avant les moteurs, trois idées expliquent la plupart des différences entre eux. La première est débit versus latence. Servir de nombreux utilisateurs à la fois est un problème de débit : vous voulez garder le GPU saturé en mettant en lot les requêtes ensemble, maximisant les tokens totaux par seconde pour tous. Exécuter un modèle pour un utilisateur est un problème de latence : vous voulez la réponse la plus rapide possible pour ce seul flux. Les moteurs optimisent pour l'un ou l'autre, et les techniques diffèrent — mise en lot continue et attention paginée pour le débit, exécution en flux unique lean pour la latence.

La deuxième est la quantification. Les poids de modèle à précision complète sont grands ; la quantification les stocke à précision inférieure (8-bit, 4-bit, ou moins) pour réduire la mémoire et accélérer l'inférence, à un certain coût de qualité. Mais la quantification n'est pas une chose — c'est un zoo de formats (GGUF, GPTQ, AWQ, EXL3, et plus), chacun avec des outils différents, des compromis qualité/taille, et le support du moteur. Quels formats un moteur peut charger est souvent le facteur décisif, car votre modèle peut seulement exister dans certains formats.

La troisième est l'adéquation du matériel. Un centre de données avec H100 a des besoins différents d'un développeur sur un MacBook ou d'un hobbyiste avec un GPU grand public. Certains moteurs ciblent le matériel serveur NVIDIA et se mettent à l'échelle sur plusieurs GPU ; d'autres s'exécutent n'importe où, y compris CPU et Apple Silicon ; d'autres font tenir les grands modèles dans une seule carte grand public. Faire correspondre le moteur à votre matériel est la moitié de la décision.

vLLM : le standard de débit

vLLM est le moteur de référence pour le service à débit élevé, et il a gagné cette position avec PagedAttention — une technique qui gère le cache KV comme mémoire virtuelle, en pages, éliminant le gaspillage qui limitait auparavant combien de requêtes pouvaient être mises en lot ensemble. Combiné avec la mise en lot continue, cela permet à vLLM de garder un GPU saturé avec de nombreuses requêtes concurrentes, livrant les tokens totaux par seconde que le service en production exige. Il expose une API compatible OpenAI, supporte le parallélisme de tenseur et de pipeline pour se mettre à l'échelle sur les GPU, et est devenu le backend par défaut sur lequel les autres outils construisent.

vLLM est le bon choix quand votre problème est le service — de nombreux utilisateurs, trafic en production, formats de modèle standard, matériel NVIDIA — et vous voulez le débit et la maturité d'écosystème qui viennent avec le moteur le plus largement adopté. Ce n'est pas l'outil pour exécuter un modèle sur votre portable, et historiquement la couverture de format de quantification de vLLM était en retard sur les formats plus exotiques de la communauté (bien qu'elle continue de s'étendre). Pour le travail principal du service des modèles standard à l'échelle, c'est la défaut puissant et sûr.

llama.cpp : local et partout

Si vLLM possède le centre de données, llama.cpp possède partout le reste. Écrit en C/C++ sans dépendances d'exécution lourd, il exécute les LLM sur presque n'importe quoi — CPUs, GPU grand public, Apple Silicon, même téléphones et Raspberry Pis — et c'est l'un des projets IA les plus starred sur GitHub pour bonne raison. Son format GGUF et son système k-quant (Q4_K_M, Q5_K_S, Q6_K, et ainsi de suite) fournissent la quantification par bloc de 8-bit à moins de 2-bit, vous permettant de composer exactement combien de qualité à échanger pour combien de mémoire, et exécuter les modèles qui ne tiendraient autrement jamais.

llama.cpp est le choix pour l'inférence locale, hors ligne, ou edge : exécuter un modèle sur votre propre machine, hors ligne, sans GPU requis, ou intégrer l'inférence LLM dans une application qui doit s'exécuter sur du matériel modeste. C'est ce qui alimente une grande part de l'écosystème LLM local, incluant les outils comme Ollama qui l'enveloppent dans une interface plus conviviale. Quand la portabilité et l'exécution n'importe où importent plus que le débit brut multi-utilisateur, llama.cpp est sans égal — et son format GGUF est devenu une lingua franca des modèles quantifiés partagés par la communauté.

Aphrodite : l'omnivore de quantification

Moteur Aphrodite est un dérivé de vLLM qui garde l'architecture de débit de vLLM mais ajoute deux choses : la couverture de format de quantification la plus large de tout moteur, et les samplers avancés. Où vLLM supporte un ensemble en croissance mais organisé de formats, Aphrodite charge presque tout ce que la communauté produit — GGUF, GPTQ, AWQ, ExLlamaV3, AQLM, BitNet, Marlin, et plus, plus le cache KV quantifié. Du côté de l'échantillonnage, il livre DRY (anti-répétition), XTC (créativité), et Mirostat, qui importent pour le chat et les applications créatives.

Aphrodite est le choix quand vous avez besoin de servir un modèle (donc vous voulez le débit de classe vLLM) mais le modèle existe dans un format que vLLM ne peut pas charger, ou quand vous voulez ces samplers avancés comme fonctionnalités de première classe. Il a émergé de la communauté et de l'écosystème de roleplay, et ce patrimoine se montre dans ses priorités : exécuter n'importe quelle quantification que la communauté a produite, avec un fin contrôle du sampler. Si vous avez jamais trouvé un modèle quantifié parfait seulement pour découvrir que votre moteur ne peut pas charger son format, Aphrodite est la réponse.

LMDeploy : compression plus service, et VLM

LMDeploy, de l'écosystème InternLM/OpenMMLab, associe un moteur de service à débit élevé (TurboMind) avec une boîte à outils de compression intégrée. Il livre un bon débit via la mise en lot persistante et le cache KV bloqué, offre la quantification de poids AWQ 4-bit et la quantification de cache KV de façon directe, et a un support particulièrement fort pour les modèles vision-langage (VLM) comme InternVL et Qwen-VL. Son point de vente est l'intégration : quantifier un modèle et le servir avec une boîte à outils, plutôt que assembler des outils séparés.

LMDeploy est le choix quand vous voulez un chemin tout-en-un à partir d'un modèle pleine précision à un endpoint quantifié efficacement servi, surtout si vous servez les modèles multimodaux ou travaillez dans l'écosystème InternLM. C'est moins à propos de charger chaque format communautaire (la niche d'Aphrodite) et plus à propos d'un pipeline propre et haute performance de compression et service avec le support VLM de première classe.

SGLang et ExLlamaV3 : deux spécialistes de plus

Deux moteurs de plus arrondissent le paysage pour les besoins spécifiques. SGLang se concentre sur le service haute performance avec une force particulière dans la génération structurée et les programmes LLM complexes multi-étapes — son RadixAttention optimise la mise en cache du préfixe, qui brille quand de nombreuses requêtes partagent des préfixes d'invite (courant dans les charges de travail agents et few-shot). C'est un moteur de débit fort avec un bord pour les modèles de génération structurée et programmatique.

ExLlamaV3 attaque un problème plus étroit mais précieux : qualité maximale par VRAM sur GPU NVIDIA grand public. Son format EXL3 offre la quantification de bitrate variable — vous ciblez un nombre moyen de bits par poids avec précision — vous permettant de faire tenir un grand modèle sur une seule carte 24GB à la meilleure qualité que cette mémoire permet. Pour l'enthousiaste local exécutant les grands modèles sur un GPU grand public, ExLlamaV3 extrait souvent plus de qualité utilisable de la même VRAM que les alternatives à format fixe, et il s'insère dans les serveurs comme TabbyAPI pour un endpoint compatible OpenAI.

Comprendre les compromis de quantification

Parce que la quantification est le levier qui décide le plus souvent quel moteur vous pouvez utiliser, il vaut la peine de comprendre ce que vous échangez quand vous la mettez. La quantification réduit la précision numérique des poids d'un modèle — de floats 16-bit vers 8, 4, ou encore moins de bits — et l'effet est à peu près linéaire sur la mémoire : une quantification 4-bit d'un modèle est environ un quart la taille de son original 16-bit, ce qui est ce qui permet à un modèle de 70 milliards de paramètres qui aurait besoin de 140GB pleine précision de tenir dans une seule carte grand public 24GB. Le bénéfice de vitesse suit, car moins de trafic mémoire et des poids plus petits signifient une inférence plus rapide, surtout quand la bande passante mémoire est le goulet.

Le coût est la qualité, mais la relation n'est pas linéaire et c'est l'aperçu clé. Aller de 16-bit à 8-bit est quasi lossless pour la plupart des modèles — la différence de qualité est imperceptible en pratique. Aller à 4-bit introduit une petite dégradation, généralement acceptable, c'est pourquoi les formats 4-bit comme Q4_K_M et AWQ 4-bit sont les chevaux de bataille de l'inférence locale. En dessous de 4-bit, la qualité baisse plus radicalement, et à 2-bit la dégradation est significative, bien que les méthodes modernes comme l'approche de bitrate variable d'EXL3 et AQLM poussent cette frontière plus loin que les anciennes techniques le pouvaient. La guidance pratique est d'utiliser le bitrate le plus élevé que votre mémoire permet : si un modèle tient à 5 ou 6 bits, il y a rarement une raison d'aller plus bas, et s'il tient seulement à 3 bits, attendez vous à le sentir.

C'est aussi pourquoi le format de quantification — pas seulement le bitrate — importe pour le choix du moteur. Les formats différents utilisent les algorithmes différents pour décider comment arrondir les poids, et ils ne sont pas interchangeables : un modèle GGUF a besoin d'un moteur qui lit GGUF, un modèle EXL3 a besoin d'ExLlamaV3 ou d'un serveur compatible, un modèle AWQ a besoin du support AWQ. La communauté produit les modèles dans quelque format que ses outils préférés utilisent, donc le format dans lequel votre modèle cible existe contraint quels moteurs peuvent le servir. C'est précisément la contrainte qui rend la largeur de format d'Aphrodite précieuse et qui force occasionnellement une équipe sur un moteur spécifique non pour sa performance mais simplement parce qu'il est le seul qui peut charger le modèle qu'ils veulent. Comprendre la courbe bitrate/qualité et le paysage de format, et les parties du choix du moteur conduites par la quantification arrêtent d'être mystérieuses.

Choisir un moteur

La décision se réduit à faire correspondre le moteur à votre travail et matériel. Pour le service en production à l'échelle sur le matériel NVIDIA avec les formats de modèle standard, utilisez vLLM — c'est le standard de débit avec l'écosystème le plus profond. Pour l'inférence locale, hors ligne, ou edge, ou exécuter sur CPU/Apple Silicon/matériel modeste, utilisez llama.cpp — rien ne correspond à sa portabilité, et son format GGUF est le standard communautaire. Pour servir les modèles quantifiés communautaires dans les formats exotiques, ou voulant les samplers avancés, utilisez Moteur Aphrodite — c'est l'omnivore de quantification. Pour un pipeline tout-en-un compression-et-service, surtout avec les modèles vision-langage, utilisez LMDeploy. Pour la génération structurée/agents à débit, considérez SGLang. Et pour qualité maximale par VRAM sur un seul GPU grand public, utilisez ExLlamaV3.

Le point méta est que ces moteurs partagent de plus en plus les fondations — plusieurs construisent sur ou dérivés de vLLM, plusieurs parlent l'API compatible OpenAI, et les modèles quantifiés se déplacent entre eux — donc le choix est moins à propos du verrouillage et plus à propos de quelle personnalité correspond à votre charge de travail aujourd'hui. Une équipe pourrait même en utiliser deux : llama.cpp pour le développement local et vLLM pour le service en production, ou LMDeploy quantifier un modèle qu'Aphrodite sert alors. Diagnostiquez votre contrainte dominante — débit, portabilité, amplitude de quantification, ou qualité par VRAM — et le moteur correct suit.

Le résumé

Il n'existe pas un seul meilleur moteur d'inférence LLM en 2026, et en chaser un est le mauvais objectif. Il existe un portefeuille mature, chaque moteur avec un travail clair : vLLM pour le service de débit à l'échelle, llama.cpp pour local et partout, Aphrodite pour la couverture de quantification la plus large, LMDeploy pour compresser-et-servir et VLM, SGLang pour la génération structurée, et ExLlamaV3 pour la qualité par VRAM sur GPU grand public. Comprenez les trois leviers qui conduisent le choix — débit versus latence, format de quantification, et adéquation du matériel — faites correspondre le moteur à votre contrainte dominante, et vous exécuterez vos modèles plus rapide, moins cher, et sur le matériel que vous avez réellement.

Références et ressources

Moteurs

Fond et analyse

Fiches techniques 1337skills connexes

vLLM, llama.cpp, Moteur Aphrodite, LMDeploy
SGLang, ExLlamaV3, Ollama, TensorRT-LLM