Déploiement de production vLLM : 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 réalise une réduction de 73% des coûts d'inférence via la migration vLLM (50M d'appels API quotidiens sur 1/3 de la flotte GPU). PagedAttention élimine 60-80% du gaspillage mémoire de la fragmentation du cache KV. vLLM délivre 2-24x le débit vs service conventionnel. Alimentant la production chez Meta, Mistral AI, Cohere, IBM. Les APIs compatibles OpenAI simplifient l'adoption.

L'équipe de la plateforme ML de Stripe a vu leurs coûts d'inférence chuter de 73% après avoir migré de Hugging Face Transformers vers vLLM, traitant les mêmes 50 millions d'appels API quotidiens sur un tiers de la flotte GPU.¹ Le secret derrière 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 délivre des améliorations de débit 2-24x par rapport aux frameworks de service conventionnels, transformant l'économie du déploiement de grands modèles de langage à l'é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 a émergé comme le choix dominant pour les charges de travail de production, alimentant l'inférence chez Meta, Mistral AI, Cohere, et IBM.⁴ La combinaison du framework de PagedAttention, du traitement par lots continu, et des APIs compatibles OpenAI crée une expérience de déploiement qui équilibre performance brute et simplicité opérationnelle. Comprendre l'architecture et les modèles de déploiement de vLLM sépare les organisations qui réalisent une inférence rentable de celles qui se noient dans les factures GPU.

PagedAttention transforme la gestion de la mémoire

L'inférence LLM traditionnelle alloue un bloc de mémoire contigu pour le cache clé-valeur (KV) de chaque séquence, réservant 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 pendant que les séquences réelles attendent en file pour les ressources.

PagedAttention réinvente cette architecture en divisant la mémoire GPU en pages de taille fixe, typiquement 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 à travers 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 à travers 125 pages distribuées où que l'espace existe.

L'allocation dynamique provisionne la mémoire seulement quand les séquences grandissent. Le premier token alloue une page. Le dix-septième token déclenche une allocation de seconde page. La consommation mémoire suit l'utilisation réelle plutôt que les maximums théoriques, améliorant dramatiquement la capacité effective.

Le partage de mémoire permet aux préfixes de prompt identiques de partager les pages de cache KV à travers les requêtes. Dix utilisateurs demandant des variations du même prompt système partagent une copie unique mise en cache de ce préfixe, réduisant la consommation mémoire de 90% pour les modèles communs. 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 commune 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, typiquement sous 8 tokens par séquence indépendamment de 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 aux pages de mémoire physique, PagedAttention mappe les positions logiques de cache KV aux blocs de mémoire GPU physique. Le surcoût de traduction ajoute des microsecondes à chaque calcul d'attention mais économise des gigaoctets de capacité mémoire.

Le traitement par lots continu maximise l'utilisation GPU

Le traitement par lots statique attend un nombre fixe de requêtes avant de les traiter ensemble, créant des pics de latence quand les lots se remplissent partiellement et le débit chute quand 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 de plus avant que le traitement commence, potentiellement ajoutant des secondes de latence pendant les périodes de faible trafic.

Le traitement par lots continu dans vLLM élimine complètement les frontières de lots.⁷ Le planificateur opère au niveau itération plutôt qu'au niveau requête, prenant des décisions à chaque passage avant plutôt qu'à chaque lot. Quand une séquence termine la génération, son slot accepte immédiatement une nouvelle requête sans attendre que les séquences sœurs finissent. Le GPU traite le travail qui existe à chaque moment, remplissant les lacunes que le traitement par lots statique laisse vides.

L'implémentation requiert une coordination attentive entre la gestion de mémoire et la planification :

La planification au niveau itération évalue la file de requêtes à chaque étape du décodeur. Les séquences complété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 préemption gère les situations où la pression mémoire force l'éviction de séquence. Les requêtes de priorité plus basse sauvegardent leur état de cache KV et cèdent la mémoire GPU aux séquences de priorité plus haute. Quand la capacité revient, les séquences préemptées reprennent de leurs points de sauvegarde plutôt que de redémarrer de zéro.

La mise en cache de préfixe identifie les requêtes partageant des préfixes communs et les route vers des instances 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 mis en cache, éliminant le calcul de préfixe redondant.

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 80ms versus 673ms.⁸ L'architecture de traitement par lots continu maintient ces avantages à travers les niveaux de concurrence de 1 à 256 utilisateurs simultanés.

L'architecture de production s'adapte à travers les clusters

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

Le routage de requêtes dirige les requêtes entrantes vers les instances backend appropriées basé sur les clés de routage, IDs de session, ou correspondance de préfixe. Le routage intelligent maximise la réutilisation du cache KV en envoyant les requêtes liées aux instances tenant déjà le contexte pertinent. Une conversation avec plusieurs tours route de manière consistante vers le même backend, évitant le calcul de préfixe redondant à travers les instances.

Le partage de 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 sur des interconnexions haut débit, permettant des hits de cache même quand les requêtes routent vers différentes instances. Les systèmes avec des charges de travail répétitives voient une réduction de latence 3-10x et une amélioration de débit 2-5x du partage de cache inter-instances.¹⁰

L'intégration d'observabilité expose les métriques via Prometheus et la visualisation via les tableaux de bord Grafana. Les métriques par requête capturent le time-to-first-token (TTFT), time-between-tokens (TBT), et la latence bout-en-bout. Les métriques par instance suivent l'utilisation GPU, la pression mémoire, la profondeur de file, et les taux de hit de cache. Les équipes opérationnelles 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 les instances vLLM basé sur les signaux de demande. Les déploiements Kubernetes utilisent le Horizontal Pod