Noqta
écrits/blog/2026/06
● Blog14 juin 2026·6 min

vLLM en production : le guide du développeur 2026

Servez des LLM open source à grande échelle avec vLLM : PagedAttention, batching continu, parallélisme tensoriel, quantification FP8 et une API compatible OpenAI pour la production en 2026.

Équipe Noqta
·EN · FR · AR

Faire tourner une démo de chatbot sur un seul GPU avec transformers, c'est facile. Servir le même modèle à des milliers d'utilisateurs simultanés sans faire exploser votre budget, c'est un tout autre problème. Cet écart — entre un notebook qui fonctionne et un endpoint qui survit au trafic de production — est précisément là où vLLM s'est imposé comme la réponse par défaut en 2026.

Si votre équipe auto-héberge des modèles open source comme Qwen, Llama, Mistral ou DeepSeek plutôt que de payer au token une API fermée, ce guide explique ce que fait vLLM, pourquoi il est rapide, et comment le déployer pour des charges de travail réelles.

Pourquoi le service naïf s'effondre

La boucle d'inférence standard de Hugging Face traite les requêtes un lot à la fois. Le lot entier doit se terminer avant que le suivant ne démarre : une seule génération longue bloque donc les courtes derrière elle. Pire, la mémoire GPU du cache KV — l'état d'attention cumulé pour chaque token de chaque séquence — est allouée comme un grand bloc contigu par requête, dimensionné pour le pire cas. La majeure partie reste vide.

Résultat : l'utilisation du GPU tourne généralement autour de 30–40 %. Vous payez du matériel qui passe l'essentiel de son temps à attendre. Sur des accélérateurs coûteux, ce gaspillage est le poste de dépense le plus important d'un budget d'inférence.

PagedAttention : l'idée centrale

La percée de vLLM est PagedAttention, qui emprunte la pagination de la mémoire virtuelle aux systèmes d'exploitation. Au lieu d'une région de cache KV contiguë par requête, le cache est découpé en blocs de taille fixe (pages). Les positions logiques des tokens sont mappées vers des blocs physiques non contigus, exactement comme un OS associe des pages virtuelles à la RAM physique.

Cela élimine deux problèmes d'un coup. La fragmentation disparaît presque, ce qui permet de loger bien plus de séquences simultanées dans la même mémoire. Et les blocs deviennent partageables : lorsque plusieurs requêtes partagent un préfixe de prompt commun (un prompt système, un gabarit few-shot), elles peuvent pointer vers les mêmes pages physiques au lieu de les dupliquer. En récupérant la mémoire gaspillée, PagedAttention augmente la taille de lot atteignable pour un GPU donné, ce qui augmente directement le débit.

Le batching continu

Le second pilier est le batching continu (aussi appelé in-flight batching). Plutôt que d'attendre la fin d'un lot complet, l'ordonnanceur de vLLM opère au niveau du token : dès qu'une séquence émet son token de fin et libère sa place, une requête en file d'attente la remplace au pas suivant.

Passer du batching statique au batching continu avec PagedAttention fait généralement grimper l'utilisation du GPU de cette plage de 30–40 % à 75–90 %, ce qui se traduit par environ 2 à 4 fois plus de tokens produits par GPU-heure. Sur les benchmarks, vLLM offre couramment un débit 2 à 3 fois supérieur au service de base, et bien davantage face aux boucles naïves à requête unique.

En 2026, le moteur V1 réécrit est celui par défaut. Il a assaini l'ordonnanceur, rendu le prefill fragmenté standard et amélioré la mise en cache des préfixes — les gains ci-dessus sont donc ceux que vous obtenez d'emblée, sans réglage lourd.

Démarrer

L'installation tient en un paquet, et le service en une commande. vLLM expose un serveur compatible OpenAI, la fonctionnalité qui rend l'adoption indolore : tout code déjà écrit pour le SDK OpenAI pointe vers votre endpoint en changeant une seule URL.

pip install vllm
 
# Démarrer un serveur compatible OpenAI sur le port 8000
vllm serve Qwen/Qwen2.5-7B-Instruct \
  --gpu-memory-utilization 0.90 \
  --max-num-batched-tokens 8192

Appelez-le ensuite exactement comme l'API OpenAI :

from openai import OpenAI
 
client = OpenAI(
    base_url="http://localhost:8000/v1",
    api_key="not-needed-for-local",
)
 
resp = client.chat.completions.create(
    model="Qwen/Qwen2.5-7B-Instruct",
    messages=[{"role": "user", "content": "Explique PagedAttention en une phrase."}],
)
print(resp.choices[0].message.content)

Aucune réécriture de SDK, aucun client propriétaire. Cette seule propriété explique pourquoi les équipes qui migrent depuis des API fermées se tournent d'abord vers vLLM.

Passer à l'échelle des grands modèles

Un modèle de 7B tient confortablement sur un GPU. Un modèle de 70B, non. Pour cela, vLLM prend en charge le parallélisme tensoriel, qui répartit les poids de chaque couche sur plusieurs GPU d'un même nœud :

vllm serve meta-llama/Llama-3.3-70B-Instruct \
  --tensor-parallel-size 4 \
  --gpu-memory-utilization 0.90

Réglez --tensor-parallel-size sur le nombre de GPU de la machine. Pour les modèles trop grands pour un seul nœud, le parallélisme de pipeline répartit aussi les couches entre nœuds. La règle empirique : utilisez d'abord le parallélisme tensoriel à l'intérieur d'une machine, car il est gourmand en bande passante et profite des interconnexions rapides intra-nœud.

La quantification pour le débit et l'empreinte mémoire

La quantification réduit les poids pour qu'un modèle consomme moins de mémoire et aille plus vite. vLLM prend en charge un large éventail de méthodes — dont FP8, AWQ, GPTQ, GPTQ-Marlin, bitsandbytes et compressed-tensors.

Deux voies pratiques :

  • FP8 sur les accélérateurs modernes est le compromis idéal en 2026. La plupart des grands modèles ouverts (Llama 3.x, Mistral, Qwen 2.5, Phi-4) sont validés avec vLLM FP8, et si aucun poids préquantifié n'existe, vLLM peut quantifier à la volée à partir des poids d'origine.
  • AWQ est un choix solide quand vous visez environ le double du débit avec une perte de qualité minime, sur du matériel sans FP8 natif.
vllm serve Qwen/Qwen2.5-72B-Instruct-AWQ \
  --quantization awq \
  --tensor-parallel-size 2

Le bénéfice est concret : la quantification libère de la mémoire, plus de mémoire libre signifie un cache KV plus grand, un cache plus grand signifie plus de séquences simultanées, et plus de concurrence signifie un débit plus élevé. Les optimisations se cumulent.

Une configuration prête pour la production

Pour un GPU de classe 80 Go servant un modèle de taille moyenne en ligne, un bon point de départ ressemble à ceci :

vllm serve <votre-modele> \
  --gpu-memory-utilization 0.90 \
  --max-num-batched-tokens 16384 \
  --max-model-len 32768 \
  --enable-prefix-caching \
  --tensor-parallel-size 2

Quelques notes sur les réglages qui comptent le plus :

  • gpu-memory-utilization — gardez une marge (0.90, pas 0.98) pour que les pics de mémoire ne provoquent pas de plantages par dépassement sous charge.
  • max-num-batched-tokens — le levier débit contre latence. Des valeurs élevées tassent plus de travail par pas (bon pour les jobs par lots) ; des valeurs basses gardent les réponses individuelles réactives.
  • enable-prefix-caching — un gain quasi gratuit quand de nombreuses requêtes partagent un prompt système ou un gabarit, grâce aux blocs partageables que rend possibles PagedAttention.
  • max-model-len — plafonnez le contexte à ce dont vous avez réellement besoin. Réserver de la place pour 128 K tokens jamais utilisés ne fait que voler de la capacité de cache KV au trafic réel.

Exécutez-le derrière un gestionnaire de processus, placez-le sur un réseau privé, et mettez devant un proxy inverse qui gère le TLS et la limitation de débit. Comme l'API est au format OpenAI, une passerelle LLM ou un routeur peut répartir la charge entre plusieurs instances vLLM sans code de liaison spécifique.

Pourquoi cela compte pour les équipes MENA

Pour les startups et entreprises de Tunisie, d'Arabie saoudite et de la région au sens large, l'équation économique est convaincante. Auto-héberger un modèle ouvert sur vLLM transforme une facture variable au token — payée en devise étrangère à un fournisseur potentiellement soumis à des restrictions d'exportation — en un coût d'infrastructure fixe et prévisible que vous maîtrisez. Les données ne quittent jamais votre environnement, ce qui importe pour les exigences de protection des données personnelles et de souveraineté. Et comme vLLM exécute les poids ouverts auxquels vous faites déjà confiance, vous êtes à l'abri des suppressions soudaines d'API ou des changements d'accès régionaux.

Les gains de débit sont ce qui rend tout cela viable plutôt que théorique : obtenir 3 à 4 fois plus de tokens de chaque GPU-heure fait la différence entre un auto-hébergement centre de coûts et une véritable économie.

Conclusion

vLLM a transformé le service de LLM hautes performances d'un problème de recherche en une commande d'une ligne. PagedAttention récupère la mémoire de cache KV gaspillée, le batching continu garde le GPU occupé, le parallélisme tensoriel dépasse la carte unique, et la quantification étire chaque gigaoctet — le tout derrière une API compatible OpenAI qui s'insère dans le code existant.

Si vous servez encore le trafic de production via transformers brut, vous laissez l'essentiel de votre matériel inactif. Commencez par vllm serve, mesurez vos tokens par GPU-heure, puis ajustez les réglages de lot et de mémoire. Le chemin de la démo à un endpoint durable n'a jamais été aussi court.

Besoin d'aide pour concevoir une pile d'inférence auto-hébergée ou migrer depuis une API fermée ? Noqta construit des infrastructures d'IA prêtes pour la production pour les équipes de la région MENA.