Servir un LLM en production avec vLLM (API compatible OpenAI)

Vous avez validé un modèle en local avec Ollama sur un poste, et la question suivante tombe en comité de direction à Lille ou en atelier technique à Amiens : comment servir une cinquantaine d’utilisateurs sans coller tout le monde sur le même laptop ? Ce tutoriel expert présente vLLM comme runtime d’inférence orienté débit, exposant une API compatible OpenAI, pour brancher chats internes, outils type Continue, ou scripts métier. On détaille l’installation sous Linux (souvent Docker), le lancement, les paramètres qui comptent, la gestion de charge, le monitoring, et surtout les risques — coût GPU, saturation, données, exposition réseau — sans inventer de tok/s ni de prix. Pour l’hébergement GPU en France, croisez avec [[ta28|serveur GPU France]]. IAHDF est indépendant.

Pourquoi vLLM (et pas seulement Ollama) ?

Ollama excelle pour le poste développeur et les petites équipes (premiers pas Ollama). Quand plusieurs utilisateurs interrogent le même gros modèle en parallèle, un runtime conçu pour le batching continu et le paging de cache de clés/valeurs devient pertinent. vLLM est largement utilisé dans cet usage « serveur d’inférence » : il expose des endpoints proches de l’API OpenAI, ce qui simplifie le branchement d’clients existants (SDKs, Continue, frontends).

Ce n’est pas magique : vous payez en complexité ops (Linux, drivers, conteneurs, supervision) et en coût de GPU serveur allumé. Si vous n’avez que cinq utilisateurs occasionnels, rester sur Ollama ou un seul poste dédié peut être plus sage. La question « comment servir 50 utilisateurs ? » implique aussi auth, quota, logs, et politique de données — pas seulement un binaire plus rapide.

vLLM

Moteur d’inférence open source orienté débit, avec API souvent utilisée en mode compatible OpenAI. Suivez la doc officielle du jour pour install et flags.

Batching continu

Technique qui regroupe des requêtes concurrentes pour mieux occuper le GPU, au lieu de les traiter strictement une par une.

API compatible OpenAI

Endpoints et formes de payloads proches de /v1/chat/completions, permettant de réutiliser clients et variables d’environnement habituels.

Saturation

État où files d’attente, VRAM ou compute empêchent de respecter une latence acceptable ; se détecte par monitoring, pas par intuition seule.

Risques production : coût, saturation, données, réseau

Coût GPU : une carte serveur allumée 24/7 coûte cher (cloud ou amortissement on-prem). Dimensionnez selon usage réel, prévoyez extinction hors plages si votre métier le permet. Saturation : au-delà d’un certain nombre de requêtes concurrentes, les latences explosent ; sans file d’attente bornée et sans message d’erreur clair, les users retentent et aggravent la charge.

Données : tout prompt et toute réponse peuvent être loggés ; minimisez, chiffrez, définissez des durées de rétention. Sécurité réseau : un port vLLM exposé sur Internet sans reverse proxy, TLS et authentification est une invitation aux abus (coût, fuite, prompt injection à grande échelle). Pour un hébergement en France / UE, voyez serveur GPU France plutôt que d’ouvrir un VPS bas de gamme n’importe où.

Matériel serveur : ordres de grandeur

La VRAM nécessaire dépend du modèle, de la quantification ou du type de poids, de la longueur de contexte et du nombre de séquences concurrentes. Les fiches modèles et la doc vLLM donnent des indications : confrontez-les à un essai sur votre carte. Un GPU serveur (ordre de grandeur : cartes data center ou workstation haut de gamme souvent citées pour la prod) n’est pas le même objet qu’un laptop 8 Go. IAHDF ne publie pas ici de tableau tok/s : ces chiffres varient trop selon driver, modèle et charge.

Prévoyez aussi CPU, RAM hôte, disque rapide pour les poids, et réseau interne stable. Une asso ou une collectivité qui mutualise un serveur à Roubaix doit budgéter électricité, climatisation, et astreinte humaine — pas seulement l’achat de la carte.

Prérequis : Linux, Docker, culture ops

Ce tutoriel suppose un hôte Linux, des drivers GPU installés et stables, Docker (ou un équivalent de conteneurs) si vous suivez la voie la plus reproductible, et la capacité à lire des logs, ouvrir des ports en interne, et configurer un reverse proxy. Sous Windows natif, la prod vLLM est rarement le premier choix ; préférez un Linux dédié ou une VM.

Sachez aussi écrire un runbook : démarrage, arrêt, mise à jour d’image, rollback de modèle, contact d’astreinte. Sans ça, « la prod » n’est qu’une démo fragile.

Installer vLLM proprement

Deux voies courantes : conteneur officiel / communautaire documenté, ou environnement Python gelé sur l’hôte. La voie conteneur simplifie les mises à jour et l’alignement CUDA, à condition de monter correctement les devices GPU et les volumes de poids. Lisez la page d’installation vLLM du jour pour votre version CUDA ; les commandes copiées d’un blog ancien cassent souvent. Gardez une image de secours sur un registry interne si votre politique l’exige.

Dans une ESN ou une DSI de collectivité, faites valider l’image par le process sécurité interne (scan, provenance, utilisateur non-root si exigé). Épingler le digest d’image est une bonne hygiène. Prévoyez aussi le redémarrage automatique du conteneur après reboot de l’hôte, sans pour autant masquer une panne GPU silencieuse : un healthcheck qui appelle `/v1/models` en local reste un filet minimal.

Lancer le modèle et vérifier l’API

Le processus écoute en interne, charge les poids, puis sert les completions. Un premier test manuel avec curl ou un SDK OpenAI pointant vers votre base URL interne valide le chemin. Vérifiez le nom de modèle renvoyé : les clients devront utiliser exactement ce nom. Gardez un notebook ou un fichier http de smoke test dans le dépôt ops.

# GPU visible ?
nvidia-smi

# Exemple de forme — image, flags et nom de modèle = doc vLLM du jour
docker run --gpus all -d --name vllm \
  -v /var/lib/llm-weights:/weights \
  -p 127.0.0.1:8000:8000 \
  IMAGE_VLLM_TAG_EPINGLE \
  # ... args officiels pour servir MODEL_ID_EXACT \
  # --host 0.0.0.0 --port 8000  (reste derrière proxy ; bind public déconseillé)

# Smoke test API (clé et chemins selon votre proxy / auth)
curl -s http://127.0.0.1:8000/v1/models

curl -s http://127.0.0.1:8000/v1/chat/completions \
  -H 'Content-Type: application/json' \
  -d '{
    "model": "MODEL_ID_EXACT",
    "messages": [{"role":"user","content":"Réponds en une phrase : OK local."}],
    "max_tokens": 64
  }'

Paramètres qui comptent vraiment

Contexte max, concurrence, quantification éventuelle, et choix du modèle dominent le comportement sous charge. Les micro-flags avancés viennent ensuite. Changez un paramètre à la fois et rejouez le même scénario. Documentez chaque changement dans le runbook avec la date et l’auteur.

Méfiez-vous des valeurs « maxées » pour une démo : elles passent à deux utilisateurs et s’effondrent à vingt. La prod, c’est le contraire d’une démo salon.

Charge multi-utilisateurs : gestes sobres

Les « 50 utilisateurs » ne frappent pas tous le modèle à la même milliseconde. Estimez le nombre de requêtes simultanées réalistes (souvent bien plus bas), la longueur moyenne des prompts, et les pics (lundi matin, avant un comité). Mettez des quotas par clé API. Communiquez les heures de maintenance. Si la charge dépasse durablement la capacité, scalez horizontalement (plusieurs GPU / instances) ou réduisez le modèle — plutôt que de promettre une fluidité impossible. Un tableau de bord simple partagé avec le métier (vert / orange / rouge latence) évite les débats stériles sur des tok/s hors contexte.

Les clients (Open WebUI, Continue, scripts) doivent gérer les timeouts et backoff. Un client qui retente immédiatement en boucle transforme une saturation en panne totale. Documentez le comportement attendu côté intégrateurs : code HTTP de refus, message utilisateur, et qui appeler si le service reste orange plus d’une heure sur le site de Lille.

Monitoring sans folklore de bench

Suivez disponibilité, latence (médiane et queue haute), taux d’erreur, occupancy GPU, mémoire, et longueur des files. Gardez les mesures dans votre outil interne. Ne les transformez pas en « score IAHDF » public. Pour comparer deux modèles, utilisez le même scénario de charge et la même grille qualitative métier (exactitude, ton, refus hors sujet).

Brancher des clients (OpenAI SDK, Continue, fronts)

Pointez la base URL vers votre proxy interne, fournissez la clé, utilisez le nom de modèle servi. Dans Continue ou un chat web self-hosté, désactivez les providers cloud si la politique l’exige. Testez un cas d’échec (clé invalide, serveur down) pour vérifier les messages utilisateurs. Une intégration qui affiche une stack trace Python à un agent de mairie n’est pas terminée.

Limites franches

vLLM ne gère pas à votre place la conformité, le support utilisateur, ni la qualité du modèle. Un LoRA médiocre (fine-tuning Unsloth) restera médiocre derrière une API rapide. Sans GPU adapté et sans ops, vous n’avez pas de production — vous avez une démo. IAHDF ne revend pas de capacité GPU et ne garantit aucun débit.

Pour aller plus loin