vLLM, TGI, llama.cpp : Choisir Ton Moteur d’Inférence

Ton moteur d’inférence détermine tout comment ton modèle serve les requêtes. Vitesse, débit, efficacité mémoire, compatibilité matérielle — tout coule de ce choix. Les trois options dominantes en 2026 sont vLLM, Text Generation Inference de Hugging Face (TGI), et llama.cpp. Chacun excelle à des choses différentes.

vLLM : Le Roi du Débit

vLLM a émergé de UC Berkeley avec une seule feature killer : PagedAttention. Cette technique gère le cache KV comme un système d’exploitation gère la mémoire virtuelle — allouant des blocs non-contigus, partageant les pages entre les requêtes, et éliminant le gaspillage de mémoire qui a plagué les moteurs d’inférence antérieurs.

L’impact pratique est massif. vLLM atteint 2-4x plus haut débit que les implémentations naïves sur le même matériel. Pour les charges de travail de production où tu serves des centaines ou des milliers de requêtes concurrentes, cela se traduit directement à un coût inférieur par token.

vLLM supporte continuous batching, ce qui signifie que les nouvelles requêtes sont ajoutées aux batches en cours d’exécution sans attendre que le batch courant se complète. Combiné avec une gestion efficace de la mémoire, cela garde l’utilisation GPU constamment haute — souvent au-dessus de 90% sur les déploiements bien configurés.

L’écosystème autour de vLLM est fort. Il supporte la plupart des architectures de modèle populaires, s’intègre avec les serveurs API compatibles OpenAI, gère le tensor parallelism pour les setups multi-GPU, et supporte les modèles quantifiés (AWQ, GPTQ, et plus récemment GGUF). Pour l’inférence côté serveur à l’échelle, vLLM est le choix par défaut pour une bonne raison.

La faiblesse est la flexibilité. vLLM est basé Python et focalisé CUDA. Il fonctionne sur les GPUs NVIDIA et c’est à peu près tout. Le support AMD existe mais traîne. Le support Apple Silicon n’existe pas. Et parce qu’il est optimisé pour le débit, la latence de requête unique n’est pas toujours la meilleure.

TGI : Le Juste Milieu Production-Ready

Text Generation Inference de Hugging Face est écrit en Rust avec les bindings Python. Cela lui donne un profil de performance différent — overhead inférieur, meilleure sécurité mémoire, et un comportement plus prévisible sous charge.

La force de TGI est d’être production-ready sortie de la boîte. Il inclut le support intégré pour les health checks, les métriques Prometheus, la file d’attente des requêtes, le streaming des tokens, et la dégradation gracieuse sous heavy load. Si tu as besoin de déployer un modèle en production avec la proper observabilité et la fiabilité, TGI requiert moins de code d’infrastructure personnalisée que vLLM.

Il supporte aussi Flash Attention 2, continuous batching, et quantization. La performance est compétitive avec vLLM pour la plupart des charges de travail, bien que vLLM dépasse généralement en avant sur les benchmarks de pur débit avec une très haute concurrence.

TGI s’intègre naturellement dans l’écosystème Hugging Face. Les modèles du Hub se déploient avec une configuration minimale. Cette intégration étroite signifie que les nouvelles architectures de modèle obtiennent le support TGI rapidement, souvent au lancement.

Le downside est que TGI est plus opinionné. Tu obtiens moins de contrôle sur les paramètres de serving bas-niveau comparé à vLLM. Les architectures de modèle personnalisées qui ne sont pas dans l’écosystème Hugging Face peuvent être plus difficiles à supporter.

llama.cpp : Le Coureur Universel

llama.cpp a pris une approche radicalement différente. Écrit en pur C/C++ sans dépendances externes, il fonctionne sur tout. GPUs NVIDIA, GPUs AMD, Apple Silicon, CPUs Intel, même Raspberry Pi. S’il a un processeur, llama.cpp probable fonctionne dessus.

Le format GGUF que llama.cpp a pioneered est devenu le standard pour la distribution de modèles quantifiés. Un fichier GGUF unique contient les poids du modèle, le tokenizer, et les métadonnées — télécharge un seul fichier et tu fais l’inférence en cours. Pas d’hell des dépendances, pas de configuration d’environnement, pas de conflits de framework.

Pour l’inférence mono-utilisateur — exécuter un modèle sur ton laptop, desktop, ou un seul serveur — llama.cpp est imbattable. Le travail d’optimisation qui y va est extraordinaire. Les vitesses d’inférence CPU qui semblaient impossibles il y a deux ans sont maintenant routine. L’architecture mémoire unifiée d’Apple Silicon obtient une attention spéciale, faisant des MacBooks des machines d’inférence étonnamment capable.

La limitation est l’scaling. llama.cpp n’a pas été conçu pour servir les milliers de requêtes concurrentes. Il manque le batching sophistiqué et la gestion mémoire de vLLM. Tu peux mettre un frontend serveur (comme le serveur intégré de llama.cpp ou quelque chose comme Ollama) devant, mais la performance haute-concurrence ne correspondra pas aux moteurs de serving purpose-built.

La Matrice de Décision

Choisis vLLM quand tu runs les GPUs NVIDIA, serves beaucoup d’utilisateurs concurrents, et optimises pour le coût-par-token à l’échelle. C’est le choix juste pour les services API de production et le high-throughput batch processing.

Choisis TGI quand tu as besoin des features de fiabilité de production built-in, veux l’intégration étroite Hugging Face, ou préfères une expérience de déploiement plus batteries-included. Excellent pour les équipes qui veulent se déplacer vite sans construire l’infrastructure de serving personnalisée.

Choisis llama.cpp quand tu fonctionne sur du matériel non-NVIDIA, as besoin de l’inférence local/edge, veux le déploiement le plus simple possible, ou serves un petit nombre d’utilisateurs. C’est aussi le meilleur choix pour le développement et l’expérimentation.

La Tendance de Convergence

Ces moteurs emprunte l’un à l’autre. vLLM a ajouté le support GGUF. llama.cpp a amélioré son batching. TGI a adopté la gestion mémoire de style PagedAttention. Les gaps se rétrécissent.

L’avenir probable détient la spécialisation supplémentaire aux extrêmes — vLLM poussant les limites de débit pour les déploiements data center, llama.cpp poussant les limites d’efficacité pour les appareils edge — tandis que TGI occupe le terrain pratique du milieu. Pour la plupart des équipes, n’importe lequel des trois te servira bien. Le choix est about matcher le moteur à ton matériel spécifique et tes contraintes d’échelle.

Reste à jour sur les développements et benchmarks des moteurs d’inférence chez Laeka Research.