Déploiement de vLLM en production : construire une architecture de service d'inférence à haut débit

Mis à jour le 11 décembre 2025

Mise à jour de décembre 2025 : Stripe a atteint une réduction de 73 % des coûts d'inférence grâce à la migration vers vLLM (50 millions d'appels API quotidiens sur un tiers de la flotte GPU). PagedAttention élimine 60 à 80 % du gaspillage mémoire dû à la fragmentation du cache KV. vLLM offre un débit 2 à 24 fois supérieur aux solutions de service conventionnelles. Utilisé en production chez Meta, Mistral AI, Cohere et IBM. Les API compatibles OpenAI simplifient l'adoption.

L'équipe plateforme ML de Stripe a vu ses coûts d'inférence chuter de 73 % après la migration de Hugging Face Transformers vers vLLM, traitant les mêmes 50 millions d'appels API quotidiens avec un tiers de la flotte GPU.¹ Le secret de l'efficacité de vLLM réside dans PagedAttention, un algorithme qui traite la mémoire GPU comme la mémoire virtuelle dans les systèmes d'exploitation, éliminant la fragmentation qui gaspille 60 à 80 % de la mémoire dans les systèmes d'inférence traditionnels.² Les organisations exécutant des charges de travail LLM en production découvrent que vLLM offre des améliorations de débit de 2 à 24x par rapport aux frameworks de service conventionnels, transformant l'économie du déploiement de grands modèles de langage à grande échelle.³

Le paysage du service d'inférence se fragmente en dizaines d'options : TensorRT-LLM promet une optimisation NVIDIA maximale, Hugging Face TGI offre une intégration familière, et Ollama simplifie le déploiement local. Pourtant, vLLM s'est imposé comme le choix dominant pour les charges de travail en production, alimentant l'inférence chez Meta, Mistral AI, Cohere et IBM.⁴ La combinaison de PagedAttention, du batching continu et des API compatibles OpenAI du framework crée une expérience de déploiement qui équilibre performance brute et simplicité opérationnelle. Comprendre l'architecture et les patterns de déploiement de vLLM distingue les organisations qui atteignent une inférence rentable de celles qui croulent sous les factures GPU.

PagedAttention transforme la gestion de la mémoire

L'inférence LLM traditionnelle alloue un bloc mémoire contigu pour le cache clé-valeur (KV) de chaque séquence, réservant de l'espace pour la longueur de séquence maximale possible indépendamment de l'utilisation réelle. Un système configuré pour 4 096 tokens alloue cette mémoire complète même pour des réponses de 100 tokens, gaspillant 97 % de la capacité réservée. Multipliez par des centaines de requêtes concurrentes et la mémoire GPU se remplit de réservations vides tandis que les séquences réelles font la queue en attendant des ressources.

PagedAttention réimagine cette architecture en divisant la mémoire GPU en pages de taille fixe, généralement 16 tokens chacune.⁵ Chaque séquence maintient une liste de références de pages plutôt qu'une allocation contiguë, permettant plusieurs capacités révolutionnaires :

Le stockage non contigu permet aux blocs de cache KV de se disperser dans la mémoire GPU disponible. Le système n'a plus besoin de grandes régions contiguës, éliminant la fragmentation qui afflige les allocateurs traditionnels. Une séquence de 2 000 tokens stocke son cache sur 125 pages distribuées partout où l'espace existe.

L'allocation dynamique provisionne la mémoire uniquement au fur et à mesure que les séquences grandissent. Le premier token alloue une page. Le dix-septième token déclenche l'allocation d'une deuxième page. La consommation mémoire suit l'utilisation réelle plutôt que les maximums théoriques, améliorant considérablement la capacité effective.

Le partage de mémoire permet aux préfixes de prompts identiques de partager des pages de cache KV entre les requêtes. Dix utilisateurs posant des variations de la même invite système partagent une seule copie en cache de ce préfixe, réduisant la consommation mémoire de 90 % pour les patterns courants. Les systèmes de production avec des prompts standardisés voient des améliorations d'utilisation dépassant 400 %.⁶

Le gaspillage quasi nul élimine la fragmentation interne courante dans l'allocation statique. Les systèmes traditionnels gaspillent en moyenne 4,1 tokens par séquence dans des blocs partiellement remplis. La granularité au niveau page de PagedAttention réduit le gaspillage à des fractions de page, généralement moins de 8 tokens par séquence quelle que soit la longueur.

L'algorithme s'inspire directement de la mémoire virtuelle des systèmes d'exploitation, appliquant des décennies de recherche en gestion de mémoire à l'inférence GPU. Tout comme les systèmes d'exploitation modernes mappent les adresses virtuelles vers des pages de mémoire physique, PagedAttention mappe les positions logiques du cache KV vers des blocs de mémoire GPU physique. La surcharge de traduction ajoute des microsecondes à chaque calcul d'attention mais économise des gigaoctets de capacité mémoire.

Le batching continu maximise l'utilisation du GPU

Le batching statique attend un nombre fixe de requêtes avant de les traiter ensemble, créant des pics de latence lorsque les lots se remplissent partiellement et des baisses de débit lorsque les requêtes arrivent de manière inégale. Une taille de lot de 32 signifie que la 31e requête attend une arrivée supplémentaire avant que le traitement ne commence, ajoutant potentiellement des secondes de latence pendant les périodes de faible trafic.

Le batching continu dans vLLM élimine entièrement les frontières de lots.⁷ Le planificateur opère au niveau des itérations plutôt qu'au niveau des requêtes, prenant des décisions à chaque passage forward plutôt qu'à chaque lot. Lorsqu'une séquence termine sa génération, son slot accepte immédiatement une nouvelle requête sans attendre que les séquences sœurs se terminent. Le GPU traite tout travail existant à chaque instant, comblant les vides que le batching statique laisse vides.

L'implémentation nécessite une coordination soignée entre la gestion de la mémoire et la planification :

La planification au niveau itération évalue la file d'attente des requêtes à chaque étape du décodeur. Les séquences terminées libèrent leurs slots, les requêtes en attente revendiquent la capacité disponible, et l'itération suivante procède avec un lot optimalement rempli. La variance de latence entre les requêtes est absorbée plutôt qu'amplifiée.

La gestion de la préemption gère les situations où la pression mémoire force l'éviction de séquences. Les requêtes de priorité inférieure sauvegardent l'état de leur cache KV et cèdent la mémoire GPU aux séquences de priorité supérieure. Lorsque la capacité revient, les séquences préemptées reprennent depuis leurs points de contrôle plutôt que de redémarrer de zéro.

La mise en cache des préfixes identifie les requêtes partageant des préfixes communs et les dirige vers des instances détenant déjà les pages de cache KV pertinentes. Un système de support client où chaque requête commence avec le même contexte de 500 tokens sert les tokens suivants depuis l'état en cache, éliminant le calcul redondant des préfixes.

Les benchmarks démontrent l'impact : vLLM atteint un débit de 793 tokens par seconde comparé aux 41 tokens par seconde d'Ollama à configurations équivalentes, avec une latence P99 de 80 ms contre 673 ms.⁸ L'architecture de batching continu maintient ces avantages à travers les niveaux de concurrence de 1 à 256 utilisateurs simultanés.

L'architecture de production s'étend à travers les clusters

Les déploiements vLLM sur nœud unique gèrent un trafic substantiel, mais les systèmes de production nécessitent une orchestration à l'échelle du cluster pour la fiabilité, l'échelle et l'efficacité. La production-stack vLLM transforme le moteur d'inférence en un système de service complet avec quatre ajouts critiques.⁹

Le routage des requêtes dirige les requêtes entrantes vers les instances backend appropriées en fonction des clés de routage, des identifiants de session ou de la correspondance de préfixes. Le routage intelligent maximise la réutilisation du cache KV en envoyant les requêtes connexes aux instances détenant déjà le contexte pertinent. Une conversation avec plusieurs tours est routée de manière cohérente vers le même backend, évitant le calcul redondant des préfixes entre instances.

Le partage du cache KV étend l'efficacité mémoire de PagedAttention à travers plusieurs instances vLLM via le projet LMCache. Les backends partagent les blocs de cache KV calculés via des interconnexions à haute vitesse, permettant des hits de cache même lorsque les requêtes sont routées vers différentes instances. Les systèmes avec des charges de travail répétitives voient une réduction de latence de 3 à 10x et une amélioration de débit de 2 à 5x grâce au partage de cache inter-instances.¹⁰

L'intégration de l'observabilité expose les métriques via Prometheus et la visualisation via des tableaux de bord Grafana. Les métriques par requête capturent le time-to-first-token (TTFT), le time-between-tokens (TBT) et la latence de bout en bout. Les métriques par instance suivent l'utilisation GPU, la pression mémoire, la profondeur de file d'attente et les taux de hit du cache. Les équipes d'exploitation gagnent en visibilité sur les goulots d'étranglement de performance et les données de planification de capacité.

La mise à l'échelle horizontale ajoute et supprime des instances vLLM en fonction des signaux de demande. Les déploiements Kubernetes utilisent le Horizontal Pod Autoscaler avec des métriques personnalisées ciblant la profondeur de file d'attente ou les percentiles de latence. La couche routeur découvre automatiquement les nouvelles instances et rééquilibre le trafic, permettant une capacité élastique qui suit la demande réelle.

Le déploiement suit les patterns Kubernetes standard via des charts Helm :

# values.yaml pour vLLM production-stack
replicaCount: 4
model:
  name: "meta-llama/Llama-3.1-70B-Instruct"
  tensorParallelism: 4
resources:
  limits:
    nvidia.com/gpu: 4
router:
  enabled: true
  prefixAwareRouting: true
observability:
  prometheus: true
  grafana: true

La stack déployée expose une API compatible OpenAI via un service Kubernetes, permettant un remplacement direct pour les applications appelant actuellement les endpoints OpenAI ou Azure OpenAI. Les bases de code existantes ne nécessitent que des changements d'URL d'endpoint pour migrer des API cloud vers l'inférence auto-hébergée.

Les exigences d'infrastructure façonnent les décisions de déploiement

L'efficacité mémoire de vLLM permet des modèles plus grands sur des configurations GPU plus petites, mais la sélection du matériel détermine toujours les caractéristiques de performance. Comprendre la relation entre la taille du modèle, la mémoire GPU et le débit informe les décisions d'approvisionnement.

La mémoire GPU contraint la taille maximale du modèle et la capacité de lot concurrent. Un modèle de 70B paramètres en FP16 nécessite 140 Go rien que pour les poids, nécessitant un parallélisme tensoriel multi-GPU sur tout matériel actuel. Le même modèle en quantification INT4 tient dans 35 Go, déployable sur un seul A100 80 Go ou H100 avec une marge substantielle pour le cache KV. La bande passante mémoire limite souvent le débit plus que le calcul brut, rendant les GPU équipés de HBM3 disproportionnellement efficaces.

Le parallélisme tensoriel divise les couches du modèle sur plusieurs GPU au sein d'un nœud, essentiel pour les modèles dépassant la mémoire d'un seul GPU. vLLM supporte des degrés de parallélisme tensoriel correspondant au nombre de GPU, shardant automatiquement les couches d'attention et feed-forward. Un nœud 8 GPU exécutant un parallélisme tensoriel de 8 sert un modèle de 405B paramètres qui nécessiterait autrement plusieurs nœuds avec un parallélisme de pipeline plus lent.

Le fabric réseau devient critique pour les déploiements multi-nœuds. Le parallélisme de pipeline entre nœuds nécessite des interconnexions à faible latence et haute bande passante entre les étapes. Les réseaux InfiniBand ou RoCE avec une bande passante de 200-400 Gbps supportent un service multi-nœud efficace, tandis que l'Ethernet standard introduit une latence qui dégrade substantiellement le time-to-first-token.

Le débit de stockage impacte la performance de démarrage à froid lors du chargement des poids du modèle. Un modèle de 70B en FP16 nécessite le transfert de 140 Go du stockage vers la mémoire GPU avant de servir les premières requêtes. Un stockage NVMe délivrant 7 Go/s charge le modèle en 20 secondes ; un stockage attaché au réseau à 500 Mo/s prend 5 minutes. Les systèmes de production maintiennent soit des instances de standby warm, soit implémentent des stratégies de mise en cache des modèles pour minimiser l'impact du démarrage à froid.

Introl aide les organisations à concevoir l'infrastructure vLLM à travers notre zone de couverture mondiale, adaptant les configurations matérielles aux exigences de charge de travail tout en optimisant la rentabilité.¹¹ Nos ingénieurs ont déployé des infrastructures d'inférence servant des milliards de requêtes mensuellement, comprenant les nuances qui séparent les déploiements fonctionnels des systèmes hautement optimisés.

Comparaison de vLLM avec les alternatives

L'écosystème de service d'inférence offre plusieurs frameworks, chacun avec des forces distinctes. Sélectionner le bon outil nécessite de faire correspondre les capacités du framework aux caractéristiques de la charge de travail.

TensorRT-LLM offre une performance maximale sur le matériel NVIDIA grâce à une optimisation agressive des kernels et à la compilation de graphes. Les benchmarks montrent TensorRT-LLM atteignant plus de 10 000 tokens de sortie par seconde sur H100 avec quantification FP8, avec un time-to-first-token autour de 100 ms.¹² Le compromis : une configuration complexe nécessitant la conversion de checkpoints, la construction de moteurs et une configuration extensive à travers TensorRT-LLM, tensorrtllm_backend et Triton Inference Server. Les organisations avec des équipes d'infrastructure ML dédiées et des déploiements de modèles stables en bénéficient le plus.

**Hugging Fa

[Contenu tronqué pour la traduction]