Skip to main content
PromptQuorumBuilt for humans. Structured for AI.
Accueil/LLM locaux avancés
Overview & Reference

vLLM expliqué : le serveur LLM haute performance avec PagedAttention (2026)

·13 min de lecturePar Hans Kuepper · Fondateur de PromptQuorum · Moteur de découverte de l'IA open-weight et open source

vLLM est une bibliothèque gratuite et open source (Apache 2.0) pour l'inférence et le service de LLM à haut débit, née au Sky Computing Lab de l'UC Berkeley et aujourd'hui maintenue par une large communauté open source. Sa particularité technique majeure est PagedAttention, qui gère le cache KV d'attention en blocs non contigus de taille fixe — un peu comme un système d'exploitation gère la mémoire virtuelle —, permettant à un GPU de conserver l'état de bien plus de requêtes simultanées sans surallouer de mémoire pour chacune. Combiné au batching continu, cela permet à vLLM de servir de nombreux utilisateurs simultanés depuis un GPU (ou une configuration multi-GPU en parallélisme tensoriel) avec moins de mémoire gaspillée qu'une boucle de service naïve. vLLM embarque un serveur d'API compatible OpenAI (vllm serve), prend en charge des formats de quantification comme AWQ, GPTQ et FP8, et est conçu pour le service en production et multi-tenant — pas pour l'usage mono-utilisateur à cliquer que ciblent des outils comme Ollama et LM Studio.

Points clés

  • Gratuit et open source sous licence Apache 2.0, né au Sky Computing Lab de l'UC Berkeley
  • PagedAttention gère le cache KV en blocs non contigus de taille fixe pour réduire le gaspillage de mémoire GPU
  • Le batching continu traite de nombreuses requêtes simultanées au lieu d'un lot fixe à la fois
  • Embarque un serveur d'API compatible OpenAI, lancé avec la commande vllm serve
  • Prend en charge des formats de quantification comme AWQ, GPTQ et FP8
  • Prend en charge le service multi-GPU en parallélisme tensoriel et en pipeline
  • Le matériel principal et le mieux pris en charge est le GPU NVIDIA ; des backends AMD, Intel et autres existent mais avec une couverture plus étroite
  • Ce n'est pas une application de bureau mono-utilisateur — pas d'installateur graphique, et pas conçu pour le CPU seul ou Apple Silicon comme llama.cpp et Ollama

📍 En une phrase

vLLM est une bibliothèque gratuite, sous licence Apache 2.0, née au Sky Computing Lab de l'UC Berkeley, qui utilise PagedAttention et le batching continu pour servir efficacement de nombreuses requêtes LLM simultanées depuis un GPU, et embarque un serveur d'API compatible OpenAI intégré.

💬 En termes simples

Au lieu d'une application de chat de bureau, vLLM est un logiciel serveur : on le pointe vers un modèle et il expose une API que de nombreuses personnes ou applications peuvent appeler en même temps, en utilisant la mémoire GPU plus efficacement qu'une configuration simple traitant une requête à la fois.

📌Remarque: Cet article s'appuie sur le dépôt GitHub officiel de vLLM et sa documentation publique, pas sur des benchmarks indépendants. Les chiffres précis de débit ou de latence sont volontairement absents car ils n'ont pas été mesurés indépendamment pour cet article et varient fortement selon le GPU, le modèle, la taille de lot et la version de vLLM.

Lire en:
🇺🇸en🇩🇪de🇫🇷fr🇯🇵ja🇨🇳zh🇪🇸es🇧🇷pt🇸🇦ar🇰🇷ko

vLLM est une bibliothèque gratuite, sous licence Apache 2.0, pour l'inférence et le service de LLM, née au Sky Computing Lab de l'UC Berkeley et aujourd'hui maintenue par une large communauté open source. Sa contribution technique centrale est PagedAttention, une technique de gestion mémoire pour le cache d'attention clé-valeur (KV) qui permet à un GPU de servir bien plus de requêtes simultanées à partir de la même mémoire qu'avec une implémentation d'attention naïve, combinée à un batching continu qui garde le GPU occupé sur de nombreuses requêtes simultanées plutôt que de les traiter par lots fixes. vLLM embarque un serveur d'API compatible OpenAI et cible le service en production multi-utilisateurs — un outil différent des applications de bureau mono-utilisateur comme Ollama ou LM Studio.

vLLM expliqué : le serveur LLM haute performance avec PagedAttention (2026)

Qu'est-ce que vLLM ?

vLLM est une bibliothèque et un serveur gratuits, sous licence Apache 2.0, pour exécuter l'inférence de grands modèles de langage à grande échelle. Le projet est né comme projet de recherche au Sky Computing Lab de l'UC Berkeley et est depuis devenu l'un des moteurs de service LLM open source les plus utilisés, avec des contributions de milliers de développeurs issus du monde académique et industriel. Contrairement aux outils conçus principalement pour un utilisateur unique discutant avec un modèle sur sa propre machine, vLLM est conçu pour servir de nombreuses requêtes simultanées — de plusieurs utilisateurs ou applications — aussi efficacement que possible à partir d'une capacité GPU partagée.

  • Né au Sky Computing Lab de l'UC Berkeley, aujourd'hui un projet open source gouverné par la communauté
  • Sous licence Apache 2.0 : le code source est publiquement disponible pour utilisation, modification et redistribution selon les termes de la licence
  • Charge les modèles au format compatible Hugging Face Transformers, offrant une large couverture d'architectures — Llama, Mistral, Qwen, DeepSeek et bien d'autres familles de modèles — sans étape de conversion séparée pour la plupart des modèles
  • Conçu pour servir efficacement de nombreuses requêtes simultanées, pas seulement pour exécuter rapidement une seule conversation
  • L'un des projets de service LLM open source les plus référencés sur GitHub

Qu'est-ce que PagedAttention, et pourquoi est-ce important ?

PagedAttention est la technique de gestion mémoire pour laquelle vLLM est le plus connu. Pendant la génération, un modèle transformeur stocke un cache d'attention clé-valeur (KV) pour chaque token de chaque requête active — normalement, ce cache est alloué comme un seul grand bloc contigu par requête, dimensionné pour la longueur maximale possible de la requête, ce qui gaspille de la mémoire GPU dès qu'une requête se termine plus tôt ou est plus courte que le maximum réservé. PagedAttention découpe plutôt le cache KV en petits blocs de taille fixe (pages) pouvant être alloués de façon non contiguë et partagés entre requêtes, en empruntant une idée à la gestion de la mémoire virtuelle des systèmes d'exploitation.

  • Réduit le gaspillage de mémoire dû à la sur-réservation d'espace de cache KV pour des requêtes finalement plus courtes que leur longueur maximale
  • Permet de partager des blocs de mémoire entre requêtes ayant un préfixe commun, comme le même prompt système
  • Permet au GPU de conserver le cache KV de davantage de requêtes simultanées dans la même quantité de mémoire qu'avec une allocation contiguë naïve
  • Fonctionne avec le batching continu, qui permet à vLLM d'ajouter et de retirer des requêtes d'un lot en cours d'exécution au fur et à mesure de leur arrivée et de leur achèvement, plutôt que d'attendre la fin complète d'un lot fixe avant de démarrer le suivant

De quel matériel vLLM a-t-il besoin ?

La cible principale et la mieux prise en charge de vLLM est le GPU NVIDIA avec CUDA, et la plupart des déploiements en production tournent sur du matériel NVIDIA. Le projet documente aussi des backends supplémentaires, mais la couverture et la performance n'y sont pas égales.

GPU NVIDIA (CUDA)

Détails:
La cible principale, la plus mature. Le service en parallélisme tensoriel et en pipeline sur plusieurs GPU NVIDIA est bien documenté et largement utilisé en production.

GPU AMD (ROCm)

Détails:
Documenté comme backend pris en charge pour le matériel AMD via ROCm, avec une adoption réelle et une couverture communautaire plus étroites que le chemin CUDA.

GPU Intel et accélérateurs Gaudi

Détails:
Backends supplémentaires documentés par le projet pour le matériel Intel ; à considérer comme un chemin de déploiement plus restreint et moins éprouvé que les GPU NVIDIA.

TPU Google

Détails:
Un backend documenté pour le matériel TPU de Google Cloud, destiné aux équipes déjà sur cette infrastructure.

CPU (x86 / ARM / PowerPC)

Détails:
Un backend CPU seul existe, mais ce n'est pas l'usage ciblé par vLLM — le projet est conçu pour le service GPU, et l'exécution CPU est documentée comme nettement plus lente que les backends GPU.

Apple Silicon (Mac)

Détails:
Pas un chemin officiel de premier plan. Des projets maintenus par la communauté (comme un plugin de backend Metal) ajoutent un support partiel d'Apple Silicon, mais couverture et maturité restent très en retrait par rapport au support GPU NVIDIA de vLLM.

Si l'objectif est d'exécuter un modèle sur un seul Mac ou une machine CPU seule, vLLM n'est pas l'outil conçu pour cela — llama.cpp et les outils construits dessus, comme Ollama et LM Studio, ciblent directement le CPU et le matériel Apple Silicon et conviennent mieux à ce scénario.

Quels formats de quantification vLLM prend-il en charge ?

vLLM prend en charge le service de modèles à précision numérique réduite pour diminuer l'usage mémoire et, dans de nombreux cas, augmenter le débit, en utilisant plusieurs formats de quantification établis plutôt qu'un seul format propriétaire.

AWQ

Détails:
Activation-aware Weight Quantization, une méthode de quantification des poids en 4 bits largement utilisée, avec des modèles pré-quantifiés publiés par la communauté sur Hugging Face.

GPTQ

Détails:
Une méthode de quantification post-entraînement couramment distribuée sous forme de checkpoints de modèles pré-quantifiés, également typiquement en précision 4 bits.

FP8

Détails:
Précision en virgule flottante 8 bits, prise en charge sur les générations de GPU NVIDIA récentes disposant d'un support matériel FP8 — moins de précision contre un usage mémoire réduit et une exécution plus rapide que FP16/BF16.

INT8 / INT4

Détails:
Chemins de quantification entière à précision réduite documentés par le projet aux côtés d'AWQ et GPTQ pour une réduction mémoire supplémentaire.

Cet article n'inclut pas de chiffres de perte de qualité mesurés indépendamment pour chaque format — ceux-ci varient selon l'architecture du modèle et la tâche. Comparer les sorties de plusieurs formats sur vos propres prompts reste la façon la plus fiable de juger du compromis pour votre usage.

Que fournit le serveur compatible OpenAI de vLLM ?

Exécuter vllm serve démarre un serveur HTTP qui implémente le protocole de l'API OpenAI, si bien que les applications et SDK déjà construits sur l'API OpenAI peuvent souvent pointer vers une instance vLLM auto-hébergée en ne changeant que l'URL de base et le nom du modèle.

  • Points de terminaison compatibles OpenAI pour les chat completions et completions, utilisables comme remplacement direct de code client basé sur l'API OpenAI
  • Hôte et port configurables (le serveur écoute par défaut sur http://localhost:8000)
  • Options moteur pour la taille du parallélisme tensoriel, la cible d'utilisation mémoire GPU et le format de quantification, définies au démarrage du serveur
  • Prise en charge du service de plusieurs adaptateurs LoRA sur un même modèle de base chargé
  • Prise en charge des sorties structurées et de l'appel de fonctions/outils pour les formats de requête compatibles

Comment installer et exécuter vLLM ?

vLLM est distribué comme paquet Python et s'installe généralement avec pip dans un environnement Python disposant d'un GPU NVIDIA et de pilotes CUDA compatibles.

  1. 1
    Vérifier que vous disposez d'un GPU NVIDIA pris en charge avec des pilotes CUDA à jour (ou consulter la documentation du projet pour des instructions d'installation spécifiques AMD/Intel/TPU si vous ciblez l'un de ces backends).
  2. 2
    Créer un environnement virtuel Python, puis installer vLLM : pip install vllm.
  3. 3
    Démarrer le serveur compatible OpenAI avec un modèle de Hugging Face, par exemple : vllm serve meta-llama/Llama-3.1-8B-Instruct.
  4. 4
    Pour un modèle pré-quantifié, passer l'option correspondante, par exemple : vllm serve TheBloke/Llama-2-13B-AWQ --quantization awq.
  5. 5
    Pour un service multi-GPU, ajouter une option de parallélisme tensoriel, par exemple : vllm serve <model> --tensor-parallel-size 2 pour répartir le modèle sur deux GPU.
  6. 6
    Par défaut, le serveur écoute sur http://localhost:8000 ; envoyer une requête à son point de terminaison /v1/chat/completions avec n'importe quelle bibliothèque cliente compatible OpenAI, ou curl.
  7. 7
    Pointer le code client OpenAI existant vers votre serveur auto-hébergé en ne changeant que l'URL de base et le nom du modèle.

Ai-je besoin d'un GPU pour exécuter vLLM ?

Pour tout usage au-delà d'un simple test, oui — la cible principale et la mieux prise en charge de vLLM est le GPU NVIDIA. Un backend CPU seul existe mais est documenté comme nettement plus lent et n'est pas le focus du projet.

Puis-je exécuter vLLM avec un modèle quantifié ?

Oui — vLLM prend en charge des formats comme AWQ, GPTQ et FP8, et de nombreux modèles pré-quantifiés dans ces formats sont publiés sur Hugging Face et peuvent être servis avec l'option --quantization correspondante.

Comment vLLM se compare-t-il à Ollama et LM Studio ?

Ollama et LM Studio ciblent un problème différent de celui de vLLM : donner rapidement et simplement à une personne un modèle avec lequel discuter sur sa propre machine. vLLM vise à servir de nombreux utilisateurs ou applications simultanés aussi efficacement que possible à partir d'une capacité GPU partagée. Ces deux catégories d'outils ne sont pas des alternatives proches l'une de l'autre pour la plupart des usages.

  • Ollama et LM Studio s'appuient généralement sur llama.cpp ou des moteurs similaires et le format de modèle GGUF, optimisés pour un usage mono-utilisateur sur du matériel grand public, y compris les machines CPU seul et Apple Silicon
  • vLLM s'appuie sur PagedAttention et le batching continu, optimisé pour un service GPU à forte concurrence plutôt que pour la réactivité mono-utilisateur sur du matériel modeste
  • Ollama s'installe en une commande sans GPU requis ; vLLM attend un environnement Python, un GPU NVIDIA dans la plupart des déploiements, et une configuration en ligne de commande
  • LM Studio ajoute une interface de chat graphique de bureau ; vLLM n'a pas d'interface graphique — on y accède via son API compatible OpenAI ou des options en ligne de commande
  • vLLM et les outils basés sur llama.cpp peuvent tous deux exposer une API compatible OpenAI, si bien que des outils front-end construits pour cette API fonctionnent souvent avec l'un ou l'autre

Comment vLLM se compare-t-il à TGI et TensorRT-LLM ?

vLLM, Text Generation Inference (TGI) de Hugging Face, et TensorRT-LLM de NVIDIA visent tous la même mission large — le service LLM en production à grande échelle — mais avec des conceptions et des compromis différents.

vLLM

Détails:
Sous licence Apache 2.0, basé sur Python, construit autour de PagedAttention et du batching continu. Charge directement les modèles compatibles Hugging Face Transformers, avec une large couverture d'architectures et un support GPU multi-fournisseurs (NVIDIA en premier ; AMD, Intel, TPU documentés).
Articles sur vLLM (9)

+84 autres non affichés

TGI

Détails:
Le moteur de service propre de Hugging Face, sous licence Apache 2.0, prenant aussi en charge le batching continu et plusieurs formats de quantification. Étroitement intégré au Hugging Face Hub et à son écosystème.

TensorRT-LLM

Détails:
Le moteur de NVIDIA, conçu spécifiquement pour les GPU NVIDIA. Les modèles sont compilés à l'avance en un moteur TensorRT optimisé pour le GPU cible, ce qui peut offrir de très bonnes performances sur ce matériel précis, au prix d'une étape de compilation et d'une flexibilité multi-matériel moindre que vLLM ou TGI.
Articles sur TensorRT-LLM (6)

Également mentionné dans :

+1 autres non affichés

Cet article n'a pas benchmarké ces trois moteurs les uns contre les autres de façon indépendante et ne prétend pas que l'un est universellement plus rapide — le débit dépend fortement du modèle, du matériel, des caractéristiques des lots et de la version de chaque moteur. Voir le guide des serveurs d'inférence en entreprise pour une comparaison plus détaillée du déploiement et des licences des trois.

À qui vLLM convient-il ?

vLLM convient aux équipes qui servent un modèle à de nombreux utilisateurs ou applications simultanés sur une infrastructure GPU, pas aux personnes cherchant le moyen le plus rapide de discuter avec un modèle sur leur propre ordinateur.

Utilisez vLLM si

  • Vous déployez un LLM derrière une API que de nombreux utilisateurs ou services en aval appelleront simultanément
  • Vous avez accès à un ou plusieurs GPU NVIDIA (ou un déploiement AMD/Intel/TPU pris en charge) et voulez maximiser le débit et la capacité de requêtes simultanées de ce matériel
  • Vous voulez un serveur d'API compatible OpenAI auto-hébergé plutôt que de dépendre d'un fournisseur d'API tiers
  • Vous avez besoin d'un service multi-GPU en parallélisme tensoriel pour un modèle trop grand pour tenir sur un seul GPU
  • Vous êtes à l'aise avec un environnement Python, une configuration en ligne de commande et une installation GPU/CUDA

Évitez vLLM si

  • Vous voulez exécuter un modèle sur votre propre ordinateur portable ou de bureau pour un chat personnel mono-utilisateur — Ollama ou LM Studio conviennent bien mieux
  • Vous n'avez pas de GPU pris en charge — le backend CPU de vLLM n'est pas son focus, et il n'a pas de support significatif d'Apple Silicon comme llama.cpp ou Ollama
  • Vous voulez une interface graphique à cliquer plutôt qu'un serveur d'API et des options en ligne de commande
  • Vous n'êtes pas à l'aise pour dépanner des pilotes CUDA, des conflits de dépendances Python ou une configuration de mémoire GPU

vLLM face aux alternatives, en un coup d'œil

Ces outils se situent à différents points du spectre entre usage mono-utilisateur et service en production.

vLLM

Interface & installation:
Paquet Python installé via pip ; serveur d'API compatible OpenAI lancé avec vllm serve. Nécessite un GPU NVIDIA et CUDA dans la plupart des déploiements.
Idéal pour:
Service GPU à haut débit et multi-utilisateurs en production.
Articles sur vLLM (9)

+84 autres non affichés

Ollama

Interface & installation:
CLI et API REST, couramment rapporté comme tournant sur llama.cpp comme backend sur la plupart des plateformes. Une commande l'installe ; une commande télécharge et lance un modèle.
Idéal pour:
Le chemin le plus rapide vers un modèle local fonctionnel pour un seul utilisateur, sans étape de build ni GPU requis.
Articles sur Ollama (10)

+310 autres non affichés

LM Studio

Interface & installation:
Application graphique de bureau pour Mac, Windows et Linux. Télécharger, installer, puis parcourir et télécharger un modèle depuis l'application.
Idéal pour:
Les utilisateurs non techniques qui veulent une application de chat locale à cliquer.
Articles sur LM Studio (10)

+146 autres non affichés

llama.cpp

Interface & installation:
CLI, interface web intégrée et API compatible OpenAI via llama-server. Compiler depuis les sources ou utiliser un binaire précompilé ; tourne sur CPU ou GPU.
Idéal pour:
Un contrôle direct au niveau moteur, le déploiement embarqué/edge, et le matériel CPU ou Apple Silicon.
Articles sur llama.cpp (10)

+167 autres non affichés

Cet article n'a pas benchmarké de façon indépendante la vitesse ou la qualité des sorties de ces outils et ne prétend pas que l'un est techniquement supérieur — la comparaison ci-dessus ne couvre que des faits documentés d'architecture, d'installation et de modèle d'accès. Pour des chiffres de débit par matériel, voir la comparaison llama.cpp vs. Ollama vs. vLLM et le guide des serveurs d'inférence en entreprise.

Comparer dans l'annuaire

Que ne couvre pas cet article ?

Ceci est un article explicatif construit à partir de la documentation publique et du dépôt de vLLM, pas un rapport de benchmark pratique.

  • Aucun chiffre de débit, de latence ou de requêtes par seconde mesuré indépendamment — ceux-ci dépendent fortement du GPU, du modèle, de la composition des lots et de la version de vLLM
  • Aucun pourcentage de perte de qualité vérifié indépendamment pour des formats de quantification spécifiques — ceux-ci varient selon l'architecture du modèle et la tâche
  • Aucun audit de sécurité ligne par ligne du code de vLLM — il est open source et sous licence Apache 2.0, donc le code lui-même est disponible pour révision
  • Aucune couverture exhaustive de chaque backend matériel pris en charge, option moteur, ou option d'orchestration de déploiement (Kubernetes, configurations spécifiques au cloud) — cet article se concentre sur les concepts et options que la plupart des équipes évaluent en premier
  • Aucune couverture des accords de support commercial ou des offres d'hébergement géré de vLLM, car vLLM lui-même est un projet open source communautaire, pas un produit d'éditeur avec un contrat de support

Erreurs courantes en essayant vLLM

La plupart des frictions avec vLLM viennent du fait de le traiter comme un outil de bureau mono-utilisateur plutôt que comme un logiciel serveur de production.

Erreur 1 : essayer de le faire tourner sur un ordinateur portable sans GPU dédié

Le backend CPU de vLLM existe mais n'est pas son focus, et il n'a pas de support significatif d'Apple Silicon comme llama.cpp ou Ollama. Essayer de le faire tourner sur un ordinateur portable CPU seul ou un Mac Apple Silicon mène généralement à de mauvaises performances ou à des frictions d'installation qu'un outil local conçu pour cet usage éviterait entièrement.

Erreur 2 : s'attendre à un installateur graphique ou une fenêtre de chat

vLLM n'a pas d'installateur à cliquer et pas d'interface de chat intégrée. Il s'installe avec pip et s'utilise via son API compatible OpenAI — un front-end séparé (construit soi-même, ou une interface de chat tierce parlant l'API OpenAI) est nécessaire pour obtenir une fenêtre de chat.

Erreur 3 : dimensionner la mémoire GPU seulement pour le modèle, pas pour les requêtes simultanées

Un GPU disposant de juste assez de mémoire pour charger une copie d'un modèle laisse peu de marge pour le cache KV de plusieurs requêtes simultanées. Dimensionner en fonction de la charge simultanée attendue — pas seulement pour que les poids du modèle tiennent en VRAM — évite les erreurs de mémoire insuffisante sous trafic réel.

Questions fréquentes

Qu'est-ce que vLLM ?

vLLM est une bibliothèque et un serveur gratuits, sous licence Apache 2.0, pour l'inférence LLM à haut débit, nés au Sky Computing Lab de l'UC Berkeley. Il utilise PagedAttention et le batching continu pour servir efficacement de nombreuses requêtes simultanées depuis un GPU.

vLLM est-il gratuit ?

Oui. vLLM est un logiciel gratuit et open source publié sous licence Apache 2.0, sans abonnement ni compte requis pour l'exécuter soi-même.

Qu'est-ce que PagedAttention ?

PagedAttention est la technique de vLLM pour gérer le cache KV d'attention en petits blocs non contigus de taille fixe plutôt qu'en une seule grande allocation contiguë par requête, ce qui réduit le gaspillage de mémoire GPU et permet de partager la mémoire entre requêtes ayant un préfixe commun.

vLLM a-t-il besoin d'un GPU ?

Pour toute charge réelle, oui — la cible principale et la mieux prise en charge de vLLM est le GPU NVIDIA. Un backend CPU seul existe mais est documenté comme nettement plus lent et n'est pas le focus du projet, et le support Apple Silicon se limite à des ajouts maintenus par la communauté plutôt qu'à un chemin de premier plan.

Quels formats de quantification vLLM prend-il en charge ?

vLLM prend en charge plusieurs formats dont AWQ, GPTQ, FP8 et INT8/INT4, avec de nombreux modèles pré-quantifiés dans ces formats publiés sur Hugging Face.

vLLM est-il meilleur qu'Ollama ?

« Meilleur » dépend de l'usage : vLLM est conçu pour un service GPU de production à forte concurrence, tandis qu'Ollama est conçu pour le chemin le plus rapide vers un modèle local mono-utilisateur sans GPU requis. Pour la plupart des usages, ce ne sont pas des alternatives proches — voir le tableau comparatif ci-dessus.

vLLM peut-il servir des modèles sur plusieurs GPU ?

Oui. vLLM prend en charge le service en parallélisme tensoriel et en pipeline sur plusieurs GPU, configurable avec des options comme --tensor-parallel-size au démarrage du serveur.

vLLM a-t-il une API compatible OpenAI ?

Oui. Exécuter vllm serve démarre un serveur implémentant le protocole de l'API OpenAI, si bien que de nombreuses applications construites pour l'API OpenAI peuvent pointer vers une instance vLLM auto-hébergée en ne changeant que l'URL de base et le nom du modèle.

En quoi vLLM diffère-t-il de TensorRT-LLM ?

TensorRT-LLM est le moteur de NVIDIA, qui compile les modèles à l'avance en un moteur optimisé pour un GPU NVIDIA spécifique. vLLM charge directement les modèles compatibles Hugging Face Transformers sans étape de compilation préalable, et documente un support de backends au-delà des seuls GPU NVIDIA, au prix d'une optimisation matérielle spécifique moindre mais avec plus de flexibilité et une itération plus rapide.

Sources

← Retour aux LLM locaux avancés

MCP