Trois runtimes, trois intentions
On compare souvent ces trois projets comme s’ils visaient le même but. Ils ne le font pas. vLLM est né dans un labo pour maximiser le débit d’un service multi-utilisateurs. llama.cpp est né pour faire tourner un LLM sur un ordinateur portable, sans dépendances. TensorRT-LLM est l’outil de NVIDIA pour extraire le dernier pourcent de performance de son propre matériel.
Choisir, c’est d’abord identifier laquelle de ces trois intentions est la vôtre.
vLLM : le débit serveur
vLLM a rendu populaires deux idées aujourd’hui standard. PagedAttention, qu’il a introduite, gère le KV cache comme la mémoire virtuelle d’un OS : par pages, sans exiger un bloc contigu par requête, ce qui élimine la fragmentation et permet de servir bien plus de requêtes concurrentes. Le batching continu — l’ordonnancement à l’itération, formalisé auparavant par Orca (OSDI 2022) — ajoute et retire des requêtes du batch à chaque pas, au lieu d’attendre qu’un batch entier se termine ; vLLM l’a porté à grande échelle.
Le revers : vLLM cible le GPU datacenter. Le faire tourner sur du matériel modeste ou hétérogène n’est pas son terrain.
llama.cpp : le local et le portable
llama.cpp prend le problème par l’autre bout. Pas de runtime lourd, pas de dépendance Python obligatoire : un binaire C++ qui charge un fichier GGUF et tourne sur à peu près tout — CPU x86, Apple Silicon, GPU via Metal, CUDA ou Vulkan, et même en hybride CPU/GPU quand le modèle dépasse la VRAM.
C’est le runtime du poste de travail, du prototype, de l’edge et de tout ce qui doit rester simple à déployer. Sa quantification GGUF très fine permet de faire tenir des modèles étonnamment gros sur du matériel grand public.
Son angle mort : la concurrence. llama.cpp excelle sur une ou quelques requêtes ; il n’est pas pensé pour servir des centaines d’utilisateurs simultanés.
TensorRT-LLM : la performance verrouillée NVIDIA
TensorRT-LLM compile le modèle en un engine optimisé pour une architecture GPU précise : fusion de kernels, sélection des noyaux les plus rapides, exploitation des formats FP8/FP4. Sur le matériel visé, c’est généralement le plus rapide des trois, en débit comme en latence.
Le prix à payer est réel : l’engine est lié à la version du GPU et de la pile logicielle, le cycle de build est lourd, et l’ensemble vous arrime fermement à l’écosystème NVIDIA. C’est un excellent choix quand le matériel est figé et que chaque pourcent compte.
Comparatif : débit, latence, ergonomie
La leçon du graphe : en requête unique, les trois sont proches. C’est sous concurrence que vLLM et TensorRT-LLM décollent — parce qu’ils sont conçus pour ça. Le débit n’a de sens qu’au regard du scénario d’usage.
| Critère | vLLM | llama.cpp | TensorRT-LLM |
|---|---|---|---|
| Cible | Serveur multi-requêtes | Local / edge / proto | Production NVIDIA figée |
| Matériel | GPU datacenter | CPU, Apple, GPU varié | GPU NVIDIA spécifique |
| Mise en route | Rapide | Très rapide | Lente (build engine) |
| Débit concurrent | Excellent | Faible | Excellent |
| Portabilité | Moyenne | Excellente | Faible |
Comment choisir
Posez-vous trois questions. Combien de requêtes simultanées ? Au-delà de quelques-unes, vLLM ou TensorRT-LLM. Le matériel est-il figé et exclusivement NVIDIA ? Si oui, TensorRT-LLM mérite son cycle de build. Faut-il que ça tourne partout, simplement ? Alors llama.cpp, sans hésiter.
Beaucoup d’équipes finissent avec deux runtimes : llama.cpp pour le développement local et l’edge, vLLM pour le service en production.
Conclusion
Il n’y a pas de « meilleur runtime » dans l’absolu. Il y a un runtime adapté à un scénario : débit serveur, portabilité, ou performance maximale verrouillée. Identifiez d’abord votre contrainte dominante — le reste de la décision en découle. Pour les déploiements contraints, la suite logique est Jetson Orin et edge AI.
Sources et méthode
Cet article s’appuie sur la documentation et les dépôts officiels des trois projets, et sur les articles de recherche fondateurs.
- vLLM — documentation officielle et conception de PagedAttention
- llama.cpp — dépôt et README officiels (backends, quantification, inférence hybride CPU/GPU)
- TensorRT-LLM — documentation NVIDIA et workflow de build de l’engine
- PagedAttention — W. Kwon et al., Efficient Memory Management for Large Language Model Serving with PagedAttention, SOSP ‘23 (arxiv.org/abs/2309.06180)
- Batching continu — G.-I. Yu et al., Orca: A Distributed Serving System for Transformer-Based Generative Models, OSDI ‘22 (usenix.org)
Méthode — les profils de débit du graphe sont indicatifs : ils n’ont pas été mesurés sur un banc publié ici et dépendent fortement du modèle, du GPU, de la quantification et de la configuration. Ils illustrent un ordre de grandeur et une dynamique relative — les trois runtimes proches en requête unique, vLLM et TensorRT-LLM qui décollent sous concurrence —, pas un classement absolu. Toute décision de production doit reposer sur un benchmark sur le matériel cible.
