vLLM Quickstart : Déploiement haute performance de LLM - en 2026

vLLM est un moteur d’inférence et de service à haut débit et économe en mémoire pour les grands modèles de langage (LLM), développé par le Sky Computing Lab de l’UC Berkeley.

Grâce à son algorithme révolutionnaire PagedAttention, vLLM atteint un débit 14 à 24 fois supérieur à celui des méthodes de service traditionnelles, ce qui en fait le choix privilégié pour les déploiements LLM en production. Pour voir comment vLLM se positionne par rapport à Ollama, Docker Model Runner, LocalAI et les fournisseurs cloud — y compris les compromis en matière de coûts et d’infrastructure — consultez Hébergement LLM : Infrastructure locale, auto-hébergée et cloud comparée.

Qu’est-ce que vLLM ?

vLLM (virtual LLM) est une bibliothèque open-source pour l’inférence et le service rapides de LLM qui est rapidement devenue la norme de l’industrie pour les déploiements en production. Lancée en 2023, elle a introduit PagedAttention, une technique de gestion de la mémoire novatrice qui améliore considérablement l’efficacité du service.

Fonctionnalités principales

Performances à haut débit : vLLM offre un débit 14 à 24 fois supérieur à celui de HuggingFace Transformers sur le même matériel. Ce gain de performance massif provient du regroupement continu (continuous batching), des noyaux CUDA optimisés et de l’algorithme PagedAttention qui élimine la fragmentation de la mémoire.

Compatibilité avec l’API OpenAI : vLLM inclut un serveur API intégré entièrement compatible avec le format d’OpenAI. Cela permet une migration transparente d’OpenAI vers une infrastructure auto-hébergée sans modifier le code de l’application. Il suffit de pointer votre client API vers le point de terminaison de vLLM et cela fonctionne de manière transparente.

Algorithme PagedAttention : L’innovation centrale derrière les performances de vLLM est PagedAttention, qui applique le concept de pagination de la mémoire virtuelle aux mécanismes d’attention. Au lieu d’allouer des blocs de mémoire contigus pour les caches KV (ce qui entraîne une fragmentation), PagedAttention divise la mémoire en blocs de taille fixe qui peuvent être alloués à la demande. Cela réduit le gaspillage de mémoire jusqu’à 4 fois et permet des tailles de lot beaucoup plus grandes.

Regroupement continu (Continuous Batching) : Contrairement au regroupement statique où l’on attend que toutes les séquences soient terminées, vLLM utilise un regroupement continu (roulant). Dès qu’une séquence se termine, une nouvelle peut être ajoutée au lot. Cela maximise l’utilisation du GPU et minimise la latence des demandes entrantes.

Prise en charge multi-GPU : vLLM prend en charge le parallélisme tensoriel et le parallélisme de pipeline pour distribuer les grands modèles sur plusieurs GPU. Il peut servir efficacement des modèles qui ne tiennent pas dans la mémoire d’un seul GPU, supportant des configurations allant de 2 à 8+ GPU.

Large support des modèles : Compatible avec les architectures de modèles populaires, notamment LLaMA, Mistral, Mixtral, Qwen, Phi, Gemma et bien d’autres. Prend en charge les modèles ajustés par instruction et les modèles de base du Hub HuggingFace.

Quand utiliser vLLM

vLLM excelle dans des scénarios spécifiques où ses forces brillent :

Services API de production : Lorsque vous devez servir un LLM à de nombreux utilisateurs concurrents via une API, le haut débit et le regroupement efficace de vLLM en font le meilleur choix. Les entreprises exploitant des chatbots, des assistants de code ou des services de génération de contenu bénéficient de sa capacité à gérer des centaines de requêtes par seconde.

Charges de travail à haute concurrence : Si votre application a de nombreux utilisateurs simultanés faisant des demandes, le regroupement continu et PagedAttention de vLLM permettent de servir plus d’utilisateurs avec le même matériel par rapport aux alternatives.

Optimisation des coûts : Lorsque les coûts des GPU sont une préoccupation, le débit supérieur de vLLM signifie que vous pouvez servir le même trafic avec moins de GPU, réduisant directement les coûts d’infrastructure. L’efficacité mémoire 4x de PagedAttention permet également d’utiliser des instances GPU plus petites et moins chères.

Déploiements Kubernetes : L’architecture sans état et conviviale aux conteneurs de vLLM le rend idéal pour les clusters Kubernetes. Ses performances constantes sous charge et sa gestion des ressources simple s’intègrent bien avec l’infrastructure cloud-native.

Quand NE PAS utiliser vLLM : Pour le développement local, l’expérimentation ou les scénarios mono-utilisateur, des outils comme Ollama ou llama.cpp offrent une meilleure expérience utilisateur avec une installation plus simple. La complexité de vLLM est justifiée lorsque vous avez besoin de ses avantages de performance pour les charges de travail de production.

Comment installer vLLM

Prérequis

Avant d’installer vLLM, assurez-vous que votre système répond à ces exigences :

• GPU : GPU NVIDIA avec une capacité de calcul 7.0+ (V100, T4, A10, A100, H100, série RTX 20/30/40)
• CUDA : Version 11.8 ou supérieure
• Python : 3.8 à 3.11
• VRAM : Minimum 16 Go pour les modèles 7B, 24 Go+ pour 13B, 40 Go+ pour les modèles plus grands
• Pilote : Pilote NVIDIA 450.80.02 ou plus récent

Installation via pip

La méthode d’installation la plus simple est d’utiliser pip. Cela fonctionne sur les systèmes avec CUDA 11.8 ou plus récent :

# Créer un environnement virtuel (recommandé)
python3 -m venv vllm-env
source vllm-env/bin/activate

# Installer vLLM
pip install vllm

# Vérifier l'installation
python -c "import vllm; print(vllm.__version__)"

Pour les systèmes avec différentes versions de CUDA, installez la roue appropriée :

# Pour CUDA 12.1
pip install vllm==0.4.2+cu121 -f https://github.com/vllm-project/vllm/releases

# Pour CUDA 11.8
pip install vllm==0.4.2+cu118 -f https://github.com/vllm-project/vllm/releases

Installation avec Docker

Docker fournit la méthode de déploiement la plus fiable, en particulier pour la production :

# Tirer l'image officielle vLLM
docker pull vllm/vllm-openai:latest

# Exécuter vLLM avec support GPU
docker run --runtime nvidia --gpus all \
    -v ~/.cache/huggingface:/root/.cache/huggingface \
    -p 8000:8000 \
    --ipc=host \
    vllm/vllm-openai:latest \
    --model mistralai/Mistral-7B-Instruct-v0.2

Le drapeau --ipc=host est important pour les configurations multi-GPU car il permet une communication inter-processus appropriée.

Construction à partir du code source

Pour les dernières fonctionnalités ou des modifications personnalisées, construisez à partir du code source :

git clone https://github.com/vllm-project/vllm.git
cd vllm
pip install -e .

Guide de démarrage rapide vLLM

Exécuter votre premier modèle

Démarrez vLLM avec un modèle en utilisant l’interface en ligne de commande :

# Télécharger et servir Mistral-7B avec une API compatible OpenAI
python -m vllm.entrypoints.openai.api_server \
    --model mistralai/Mistral-7B-Instruct-v0.2 \
    --port 8000

vLLM téléchargera automatiquement le modèle depuis HuggingFace Hub (s’il n’est pas en cache) et démarrera le serveur. Vous verrez une sortie indiquant que le serveur est prêt :

INFO:     Démarrage du processus serveur [12345]
INFO:     Attente du démarrage de l'application.
INFO:     Démarrage de l'application terminé.
INFO:     Uvicorn en cours d'exécution sur http://0.0.0.0:8000

Faire des requêtes API

Une fois le serveur en cours d’exécution, vous pouvez faire des demandes en utilisant le client Python OpenAI ou curl :

En utilisant curl :

curl http://localhost:8000/v1/completions \
    -H "Content-Type: application/json" \
    -d '{
        "model": "mistralai/Mistral-7B-Instruct-v0.2",
        "prompt": "Expliquez ce qu'est vLLM en une phrase :",
        "max_tokens": 100,
        "temperature": 0.7
    }'

En utilisant le client Python OpenAI :

from openai import OpenAI

# Pointer vers votre serveur vLLM
client = OpenAI(
    base_url="http://localhost:8000/v1",
    api_key="not-needed"  # vLLM ne nécessite pas d'authentification par défaut
)

response = client.completions.create(
    model="mistralai/Mistral-7B-Instruct-v0.2",
    prompt="Expliquez ce qu'est vLLM en une phrase :",
    max_tokens=100,
    temperature=0.7
)

print(response.choices[0].text)

API des complétions de chat :

response = client.chat.completions.create(
    model="mistralai/Mistral-7B-Instruct-v0.2",
    messages=[
        {"role": "system", "content": "Vous êtes un assistant utile."},
        {"role": "user", "content": "Qu'est-ce que PagedAttention ?"}
    ],
    max_tokens=200
)

print(response.choices[0].message.content)

Configuration avancée

vLLM offre de nombreux paramètres pour optimiser les performances :

python -m vllm.entrypoints.openai.api_server \
    --model mistralai/Mistral-7B-Instruct-v0.2 \
    --port 8000 \
    --gpu-memory-utilization 0.95 \  # Utiliser 95 % de la mémoire GPU
    --max-model-len 8192 \            # Longueur de séquence maximale
    --tensor-parallel-size 2 \        # Utiliser 2 GPU avec parallélisme tensoriel
    --dtype float16 \                 # Utiliser la précision FP16
    --max-num-seqs 256                # Taille de lot maximale

Paramètres clés expliqués :

• --gpu-memory-utilization : Combien de mémoire GPU utiliser (0.90 = 90 %). Des valeurs plus élevées permettent des lots plus grands mais laissent moins de marge pour les pics de mémoire.
• --max-model-len : Longueur de contexte maximale. Réduire ceci économise de la mémoire pour des lots plus grands.
• --tensor-parallel-size : Nombre de GPU pour diviser le modèle.
• --dtype : Type de données pour les poids (float16, bfloat16 ou float32). FP16 est généralement optimal.
• --max-num-seqs : Nombre maximal de séquences à traiter dans un lot.

vLLM vs Ollama

vLLM est conçu pour le service de production à haut débit et multi-utilisateurs avec regroupement continu, PagedAttention et support multi-GPU. Ollama optimise pour une configuration locale rapide, la commodité d’un seul utilisateur et une gestion simple des modèles.

Pour un guide de décision détaillé couvrant les signaux de migration, les étapes de planification, la configuration Docker Compose et une liste de contrôle pratique, consultez Ollama à vLLM : Quand migrer votre serveur LLM local.

vLLM vs Docker Model Runner

Docker a récemment introduit Model Runner (anciennement GenAI Stack) comme leur solution officielle pour le déploiement local de modèles IA. Comment cela se compare-t-il à vLLM ?

Philosophie d’architecture

Docker Model Runner vise à être le “Docker pour l’IA” – un moyen simple et standardisé d’exécuter des modèles IA localement avec la même facilité que l’exécution de conteneurs. Il abstraite la complexité et fournit une interface cohérente à travers différents modèles et frameworks.

vLLM est un moteur d’inférence spécialisé axé uniquement sur le service LLM avec des performances maximales. C’est un outil de bas niveau que vous conteneurisez avec Docker, plutôt qu’une plateforme complète.

Configuration et démarrage

L’installation de Docker Model Runner est simple pour les utilisateurs de Docker :

docker model pull llama3:8b
docker model run llama3:8b

Cette similitude avec le flux de travail d’image de Docker le rend instantanément familier aux développeurs utilisant déjà des conteneurs.

vLLM nécessite plus de configuration initiale (Python, CUDA, dépendances) ou l’utilisation d’images Docker pré-construites :

docker pull vllm/vllm-openai:latest
docker run --runtime nvidia --gpus all vllm/vllm-openai:latest --model <nom-du-modele>

Caractéristiques de performance

vLLM offre un débit supérieur pour les scénarios multi-utilisateurs grâce à PagedAttention et au regroupement continu. Pour les services API de production gérant des centaines de requêtes par seconde, les optimisations de vLLM fournissent un débit 2 à 5 fois meilleur que les approches de service génériques.

Docker Model Runner se concentre sur la facilité d’utilisation plutôt que sur les performances maximales. Il est adapté au développement local, aux tests et aux charges de travail modérées, mais n’implémente pas les optimisations avancées qui font exceller vLLM à grande échelle.

Support des modèles

Docker Model Runner fournit une bibliothèque de modèles curatée avec un accès en une commande aux modèles populaires. Il prend en charge plusieurs frameworks (pas seulement les LLM) y compris Stable Diffusion, Whisper et d’autres modèles IA, ce qui le rend plus polyvalent pour différentes charges de travail IA.

vLLM se spécialise dans l’inférence LLM avec un support approfondi pour les modèles de langage basés sur les transformateurs. Il prend en charge tout LLM compatible avec HuggingFace mais ne s’étend pas à d’autres types de modèles IA comme la génération d’images ou la reconnaissance vocale.

Déploiement en production

vLLM est éprouvé en production chez des entreprises comme Anthropic, Replicate et bien d’autres servant des milliards de jetons quotidiennement. Ses caractéristiques de performance et sa stabilité sous charge lourde en font la norme de facto pour le service LLM en production.

Docker Model Runner est plus récent et se positionne davantage pour les scénarios de développement et de test local. Bien qu’il puisse servir du trafic de production, il manque de l’historique prouvé et des optimisations de performance que les déploiements de production nécessitent.

Écosystème d’intégration

vLLM s’intègre avec les outils d’infrastructure de production : opérateurs Kubernetes, métriques Prometheus, Ray pour le service distribué et une compatibilité API OpenAI étendue pour les applications existantes.

Docker Model Runner s’intègre naturellement avec l’écosystème de Docker et Docker Desktop. Pour les équipes déjà standardisées sur Docker, cette intégration offre une expérience cohérente mais moins de fonctionnalités de service LLM spécialisées.

Quand utiliser chacun

Utiliser vLLM pour :

• Services API LLM de production
• Déploiements à haut débit et multi-utilisateurs
• Déploiements cloud sensibles aux coûts nécessitant une efficacité maximale
• Environnements Kubernetes et cloud-native
• Lorsque vous avez besoin d’une évolutivité et de performances éprouvées

Utiliser Docker Model Runner pour :

• Développement et tests locaux
• Exécution de divers types de modèles IA (pas seulement les LLM)
• Équipes fortement investies dans l’écosystème Docker
• Expérimentation rapide sans configuration d’infrastructure
• Apprentissage et fins éducatives

Approche hybride : De nombreuses équipes développent avec Docker Model Runner localement pour la commodité, puis déploient avec vLLM en production pour les performances. Les images Docker Model Runner peuvent également être utilisées pour exécuter des conteneurs vLLM, combinant les deux approches.

Meilleures pratiques de déploiement en production

Déploiement Docker

Créez une configuration Docker Compose prête pour la production :

version: '3.8'

services:
  vllm:
    image: vllm/vllm-openai:latest
    runtime: nvidia
    environment:
      - CUDA_VISIBLE_DEVICES=0,1
    volumes:
      - ~/.cache/huggingface:/root/.cache/huggingface
      - ./logs:/logs
    ports:
      - "8000:8000"
    command: >
      --model mistralai/Mistral-7B-Instruct-v0.2
      --tensor-parallel-size 2
      --gpu-memory-utilization 0.90
      --max-num-seqs 256
      --max-model-len 8192      
    restart: unless-stopped
    shm_size: '16gb'
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: 2
              capabilities: [gpu]

Déploiement Kubernetes

Déployez vLLM sur Kubernetes pour une échelle de production :

apiVersion: apps/v1
kind: Deployment
metadata:
  name: vllm-server
spec:
  replicas: 2
  selector:
    matchLabels:
      app: vllm
  template:
    metadata:
      labels:
        app: vllm
    spec:
      containers:
      - name: vllm
        image: vllm/vllm-openai:latest
        args:
          - --model
          - mistralai/Mistral-7B-Instruct-v0.2
          - --tensor-parallel-size
          - "2"
          - --gpu-memory-utilization
          - "0.90"
        resources:
          limits:
            nvidia.com/gpu: 2
        ports:
        - containerPort: 8000
        volumeMounts:
        - name: cache
          mountPath: /root/.cache/huggingface
      volumes:
      - name: cache
        hostPath:
          path: /mnt/huggingface-cache
---
apiVersion: v1
kind: Service
metadata:
  name: vllm-service
spec:
  selector:
    app: vllm
  ports:
  - port: 80
    targetPort: 8000
  type: LoadBalancer

Surveillance et observabilité

vLLM expose des métriques Prometheus pour la surveillance :

import requests

# Obtenir les métriques
metrics = requests.get("http://localhost:8000/metrics").text
print(metrics)

Principales métriques à surveiller :

• vllm:num_requests_running - Requêtes actives
• vllm:gpu_cache_usage_perc - Utilisation du cache KV
• vllm:time_to_first_token - Métrique de latence
• vllm:time_per_output_token - Vitesse de génération

Optimisation des performances

Optimiser l’utilisation de la mémoire GPU : Commencez avec --gpu-memory-utilization 0.90 et ajustez en fonction du comportement observé. Des valeurs plus élevées permettent des lots plus grands mais risquent des erreurs OOM (Out Of Memory) lors des pics de trafic.

Ajuster la longueur de séquence maximale : Si votre cas d’utilisation n’a pas besoin de la longueur de contexte complète, réduisez --max-model-len. Cela libère de la mémoire pour des lots plus grands. Par exemple, si vous n’avez besoin que d’un contexte 4K, définissez --max-model-len 4096 au lieu d’utiliser le maximum du modèle (souvent 8K-32K).

Choisir une quantification appropriée : Pour les modèles qui le supportent, utilisez des versions quantifiées (8-bit, 4-bit) pour réduire la mémoire et augmenter le débit :

--quantization awq  # Pour les modèles quantifiés AWQ
--quantization gptq # Pour les modèles quantifiés GPTQ

Activer la mise en cache des préfixes : Pour les applications avec des invites répétées (comme les chatbots avec des messages système), activez la mise en cache des préfixes :

--enable-prefix-caching

Cela met en cache les valeurs KV pour les préfixes communs, réduisant le calcul pour les requêtes partageant le même préfixe d’invite.

Dépannage des problèmes courants

Erreurs de mémoire insuffisante

Symptômes : Le serveur plante avec des erreurs CUDA out of memory.

Solutions :

• Réduire --gpu-memory-utilization à 0.85 ou 0.80
• Diminuer --max-model-len si votre cas d’utilisation le permet
• Abaisser --max-num-seqs pour réduire la taille du lot
• Utiliser une version quantifiée du modèle
• Activer le parallélisme tensoriel pour distribuer sur plus de GPU

Débit faible

Symptômes : Le serveur gère moins de requêtes que prévu.

Solutions :

• Augmenter --max-num-seqs pour permettre des lots plus grands
• Augmenter --gpu-memory-utilization si vous avez de la marge
• Vérifier si le CPU est goulots d’étranglement avec htop – considérer des CPU plus rapides
• Vérifier l’utilisation du GPU avec nvidia-smi – devrait être à 95 %+
• Activer FP16 si vous utilisez FP32 : --dtype float16

Temps du premier jeton lent

Symptômes : Latence élevée avant le début de la génération.

Solutions :

• Utiliser des modèles plus petits pour les applications critiques en latence
• Activer la mise en cache des préfixes pour les invites répétées
• Réduire --max-num-seqs pour privilégier la latence au débit
• Considérer le décodage spéculatif pour les modèles pris en charge
• Optimiser la configuration du parallélisme tensoriel

Échecs de chargement du modèle

Symptômes : Le serveur ne démarre pas, ne peut pas charger le modèle.

Solutions :

• Vérifier que le nom du modèle correspond exactement au format HuggingFace
• Vérifier la connectivité réseau vers HuggingFace Hub
• S’assurer qu’il y a suffisamment d’espace disque dans ~/.cache/huggingface
• Pour les modèles gated, définir la variable d’environnement HF_TOKEN
• Essayer de télécharger manuellement avec huggingface-cli download <modele>

Fonctionnalités avancées

Décodage spéculatif

vLLM prend en charge le décodage spéculatif, où un modèle de brouillard plus petit propose des jetons qu’un modèle cible plus grand vérifie. Cela peut accélérer la génération de 1,5 à 2 fois. Pour un guide complet sur les méthodes de décodage spéculatif — modèles de brouillard, EAGLE-3, P-EAGLE et n-gramme — consultez Décodage spéculatif : Inférence plus rapide sans perte de qualité.

python -m vllm.entrypoints.openai.api_server \
    --model meta-llama/Llama-2-70b-chat-hf \
    --speculative-model meta-llama/Llama-2-7b-chat-hf \
    --num-speculative-tokens 5

Adaptateurs LoRA

Servir plusieurs adaptateurs LoRA au-dessus d’un modèle de base sans charger plusieurs modèles complets :

python -m vllm.entrypoints.openai.api_server \
    --model meta-llama/Llama-2-7b-hf \
    --enable-lora \
    --lora-modules sql-lora=./chemin/vers/adapter-sql \
                   code-lora=./chemin/vers/adapter-code

Ensuite, spécifiez quel adaptateur utiliser par demande :

response = client.completions.create(
    model="sql-lora",  # Utiliser l'adaptateur SQL
    prompt="Convertir ceci en SQL : Montrez-moi tous les utilisateurs créés ce mois"
)

Service Multi-LoRA

Le service multi-LoRA de vLLM permet d’héberger des dizaines d’adaptateurs affinés avec une surcharge mémoire minimale. C’est idéal pour servir des variantes de modèles spécifiques aux clients ou aux tâches :

# Demande avec adaptateur LoRA spécifique
response = client.chat.completions.create(
    model="meta-llama/Llama-2-7b-hf",
    messages=[{"role": "user", "content": "Écrire une requête SQL"}],
    extra_body={"lora_name": "sql-lora"}
)

Mise en cache des préfixes

Activer la mise en cache automatique des préfixes pour éviter de recalculer le cache KV pour les préfixes d’invite répétés :

--enable-prefix-caching

Cela est particulièrement efficace pour :

• Chatbots avec des prompts système fixes
• Applications RAG avec des templates de contexte cohérents
• Prompts d’apprentissage par few-shot répétés à travers les requêtes

La mise en cache des préfixes peut réduire le temps jusqu’au premier jeton de 50 à 80 % pour les requêtes partageant des préfixes d’invite.

Exemples d’intégration

Intégration LangChain

from langchain.llms import VLLMOpenAI

llm = VLLMOpenAI(
    openai_api_key="EMPTY",
    openai_api_base="http://localhost:8000/v1",
    model_name="mistralai/Mistral-7B-Instruct-v0.2",
    max_tokens=512,
    temperature=0.7,
)

response = llm("Expliquer PagedAttention en termes simples")
print(response)

Intégration LlamaIndex

from llama_index.llms import VLLMServer

llm = VLLMServer(
    api_url="http://localhost:8000/v1",
    model="mistralai/Mistral-7B-Instruct-v0.2",
    temperature=0.7,
    max_tokens=512
)

response = llm.complete("Qu'est-ce que vLLM ?")
print(response)

Application FastAPI

from fastapi import FastAPI
from openai import AsyncOpenAI

app = FastAPI()
client = AsyncOpenAI(
    base_url="http://localhost:8000/v1",
    api_key="not-needed"
)

@app.post("/generate")
async def generate(prompt: str):
    response = await client.completions.create(
        model="mistralai/Mistral-7B-Instruct-v0.2",
        prompt=prompt,
        max_tokens=200
    )
    return {"result": response.choices[0].text}

Benchmarks de performance

Les données de performance du monde réel aident à illustrer les avantages de vLLM :

Comparaison de débit (Mistral-7B sur GPU A100) :

• vLLM : ~3 500 jetons/seconde avec 64 utilisateurs concurrents
• HuggingFace Transformers : ~250 jetons/seconde avec la même concurrence
• Ollama : ~1 200 jetons/seconde avec la même concurrence
• Résultat : vLLM offre une amélioration de 14x par rapport aux implémentations de base

Efficacité mémoire (LLaMA-2-13B) :

• Implémentation standard : 24 Go VRAM, 32 séquences concurrentes
• vLLM avec PagedAttention : 24 Go VRAM, 128 séquences concurrentes
• Résultat : 4 fois plus de requêtes concurrentes avec la même mémoire

Latence sous charge (Mixtral-8x7B sur 2xA100) :

• vLLM : Latence P50 180 ms, latence P99 420 ms à 100 req/s
• Service standard : Latence P50 650 ms, latence P99 3 200 ms à 100 req/s
• Résultat : vLLM maintient une latence constante sous haute charge

Ces benchmarks démontrent pourquoi vLLM est devenu la norme de facto pour le service LLM en production où les performances comptent.

Analyse des coûts

Comprendre les implications des coûts du choix de vLLM :

Scénario : Servir 1M de requêtes/jour

Avec le service standard :

• Requis : 8x GPU A100 (80 Go)
• Coût AWS : ~32 $/heure × 24 × 30 = 23 040 $/mois
• Coût par 1M de jetons : ~0,75 $

Avec vLLM :

• Requis : 2x GPU A100 (80 Go)
• Coût AWS : ~8 $/heure × 24 × 30 = 5 760 $/mois
• Coût par 1M de jetons : ~0,19 $
• Économies : 17 280 $/mois (réduction de 75 %)

Cet avantage de coût augmente avec l’échelle. Les organisations servant des milliards de jetons mensuellement économisent des centaines de milliers de dollars en utilisant le service optimisé de vLLM au lieu d’implémentations naïves.

Considérations de sécurité

Authentification

vLLM n’inclut pas d’authentification par défaut. Pour la production, implémentez l’authentification au niveau du proxy inverse :

# Configuration Nginx
location /v1/ {
    auth_request /auth;
    proxy_pass http://vllm-backend:8000;
}

location /auth {
    proxy_pass http://auth-service:8080/verify;
    proxy_pass_request_body off;
    proxy_set_header Content-Length "";
    proxy_set_header X-Original-URI $request_uri;
}

Ou utilisez des passerelles API comme Kong, Traefik ou AWS API Gateway pour une authentification et une limitation de débit de niveau entreprise.

Isolation réseau

Exécuter vLLM dans des réseaux privés, pas exposés directement à Internet :

# Exemple de NetworkPolicy Kubernetes
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: vllm-access
spec:
  podSelector:
    matchLabels:
      app: vllm
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          role: api-gateway
    ports:
    - protocol: TCP
      port: 8000

Limitation de débit

Implémenter une limitation de débit pour prévenir l’abus :

# Exemple utilisant Redis pour la limitation de débit
from fastapi import FastAPI, HTTPException
from fastapi.middleware.cors import CORSMiddleware
import redis
from datetime import datetime, timedelta

app = FastAPI()
redis_client = redis.Redis(host='localhost', port=6379)

@app.middleware("http")
async def rate_limit_middleware(request, call_next):
    client_ip = request.client.host
    key = f"rate_limit:{client_ip}"
    
    requests = redis_client.incr(key)
    if requests == 1:
        redis_client.expire(key, 60)  # Fenêtre de 60 secondes
    
    if requests > 60:  # 60 requêtes par minute
        raise HTTPException(status_code=429, detail="Limite de débit dépassée")
    
    return await call_next(request)

Contrôle d’accès au modèle

Pour les déploiements multi-locataires, contrôler quels utilisateurs peuvent accéder à quels modèles :

ALLOWED_MODELS = {
    "user_tier_1": ["mistralai/Mistral-7B-Instruct-v0.2"],
    "user_tier_2": ["mistralai/Mistral-7B-Instruct-v0.2", "meta-llama/Llama-2-13b-chat-hf"],
    "admin": ["*"]  # Tous les modèles
}

def verify_model_access(user_tier: str, model: str) -> bool:
    allowed = ALLOWED_MODELS.get(user_tier, [])
    return "*" in allowed or model in allowed

Guide de migration

D’OpenAI à vLLM

La migration d’OpenAI vers vLLM auto-hébergé est simple grâce à la compatibilité API :

Avant (OpenAI) :

from openai import OpenAI

client = OpenAI(api_key="sk-...")
response = client.chat.completions.create(
    model="gpt-3.5-turbo",
    messages=[{"role": "user", "content": "Bonjour"}]
)

Après (vLLM) :

from openai import OpenAI

client = OpenAI(
    base_url="https://votre-serveur-vllm.com/v1",
    api_key="votre-clef-interne"  # Si vous avez ajouté une authentification
)
response = client.chat.completions.create(
    model="mistralai/Mistral-7B-Instruct-v0.2",
    messages=[{"role": "user", "content": "Bonjour"}]
)

Seuls deux changements sont nécessaires : mettre à jour base_url et le nom du model. Tout le reste du code reste identique.

D’Ollama à vLLM

Ollama utilise un format API différent. Le changement client de base consiste à passer du point de terminaison REST d’Ollama à l’API compatible OpenAI de vLLM :

API Ollama :

import requests

response = requests.post('http://localhost:11434/api/generate',
    json={'model': 'llama2', 'prompt': 'Pourquoi le ciel est-il bleu ?'})

Équivalent vLLM :

from openai import OpenAI

client = OpenAI(base_url="http://localhost:8000/v1", api_key="not-needed")
response = client.completions.create(
    model="meta-llama/Llama-2-7b-chat-hf",
    prompt="Pourquoi le ciel est-il bleu ?"
)

Pour un guide de migration approfondi couvrant la sélection des modèles, les templates de chat, la migration par étapes et une liste de contrôle pratique, consultez Ollama à vLLM : Quand migrer votre serveur LLM local.

De HuggingFace Transformers à vLLM

Migration d’utilisation directe Python :

HuggingFace :

from transformers import AutoModelForCausalLM, AutoTokenizer

model = AutoModelForCausalLM.from_pretrained("mistralai/Mistral-7B-Instruct-v0.2")
tokenizer = AutoTokenizer.from_pretrained("mistralai/Mistral-7B-Instruct-v0.2")

inputs = tokenizer("Bonjour", return_tensors="pt")
outputs = model.generate(**inputs, max_new_tokens=100)
result = tokenizer.decode(outputs[0])

vLLM :

from vllm import LLM, SamplingParams

llm = LLM(model="mistralai/Mistral-7B-Instruct-v0.2")
sampling_params = SamplingParams(max_tokens=100)

outputs = llm.generate("Bonjour", sampling_params)
result = outputs[0].outputs[0].text

L’API Python de vLLM est plus simple et beaucoup plus rapide pour l’inférence par lots.

L’avenir de vLLM

vLLM continue un développement rapide avec des fonctionnalités excitantes dans la feuille de route :

Service désagrégé : Séparer le préremplissage (traitement des invites) et le décodage (génération de jetons) sur différents GPU pour optimiser l’utilisation des ressources. Le préremplissage est limité par le calcul tandis que le décodage est limité par la mémoire, donc les exécuter sur du matériel spécialisé améliore l’efficacité.

Inférence multi-nœuds : Distribuer des modèles très grands (100B+ paramètres) sur plusieurs machines, permettant le service de modèles trop grands pour les configurations mono-nœud.

Quantification améliorée : Support pour de nouveaux formats de quantification comme GGUF (utilisé par llama.cpp) et une meilleure intégration AWQ/GPTQ pour de meilleures performances avec les modèles quantifiés.

Améliorations du décodage spéculatif : Modèles de brouillard plus efficaces et stratégies de spéculation adaptatives pour atteindre des accélérations plus élevées sans perte de précision.

Optimisations d’attention : FlashAttention 3, attention en anneau pour des contextes extrêmement longs (100K+ jetons) et autres mécanismes d’attention de pointe.

Meilleure couverture des modèles : Expansion du support aux modèles multimodaux (modèles vision-langage), modèles audio et architectures spécialisées au fur et à mesure qu’ils émergent.

Le projet vLLM maintient un développement actif avec des contributions de UC Berkeley, Anyscale et la communauté open-source plus large. À mesure que le déploiement LLM devient plus critique pour les systèmes de production, le rôle de vLLM en tant que norme de performance continue de grandir. Pour une comparaison plus large de vLLM avec d’autres infrastructures LLM locales et cloud, consultez notre Hébergement LLM : Infrastructure locale, auto-hébergée et cloud comparée.

Liens utiles

Articles connexes sur ce site

• Hébergement LLM local : Guide complet 2026 - Ollama, vLLM, LocalAI, Jan, LM Studio & Plus - Comparaison complète de 12+ outils d’hébergement LLM locaux incluant une analyse détaillée de vLLM aux côtés d’Ollama, LocalAI, Jan, LM Studio et autres. Couvre la maturité API, le support d’appel d’outils, la compatibilité GGUF et les benchmarks de performance pour aider à choisir la bonne solution.

• Ollama Cheatsheet - Référence complète des commandes Ollama et feuille de commande couvrant l’installation, la gestion des modèles, l’utilisation API et les meilleures pratiques pour le déploiement LLM local. Essentiel pour les développeurs utilisant Ollama aux côtés ou à la place de vLLM.

• Démarrage rapide llama.cpp avec CLI et Serveur - Inférence C/C++ légère pour les modèles GGUF avec llama-cli et llama-server compatible OpenAI. Idéal lorsque vous avez besoin d’un contrôle fin, d’un déploiement hors ligne ou d’une pile minimale sans Python.

• Docker Model Runner vs Ollama : Lequel choisir ? - Comparaison approfondie du Model Runner de Docker et d’Ollama pour le déploiement LLM local, analysant les performances, le support GPU, la compatibilité API et les cas d’utilisation. Aide à comprendre le paysage concurrentiel dans lequel opère vLLM.

• Feuille de commande Docker Model Runner : Commandes & Exemples - Feuille de commande pratique Docker Model Runner avec commandes et exemples pour le déploiement de modèles IA. Utile pour les équipes comparant l’approche de Docker avec les capacités de service LLM spécialisées de vLLM.

Ressources externes et documentation

• Référentiel GitHub vLLM - Référentiel officiel vLLM avec code source, documentation complète, guides d’installation et discussions communautaires actives. Ressource essentielle pour rester à jour avec les dernières fonctionnalités et le dépannage des problèmes.

• Documentation vLLM - Documentation officielle couvrant tous les aspects de vLLM de la configuration de base à la configuration avancée. Inclut les références API, les guides d’optimisation des performances et les meilleures pratiques de déploiement.

• Article PagedAttention - Article académique introduisant l’algorithme PagedAttention qui alimente l’efficacité de vLLM. Lecture essentielle pour comprendre les innovations techniques derrière les avantages de performance de vLLM.

• Blog vLLM - Blog officiel vLLM présentant des annonces de version, des benchmarks de performance, des analyses techniques et des études de cas communautaires de déploiements en production.

• Hub de modèles HuggingFace - Référentiel complet de LLM open-source qui fonctionnent avec vLLM. Recherchez des modèles par taille, tâche, licence et caractéristiques de performance pour trouver le bon modèle pour votre cas d’utilisation.

• Documentation Ray Serve - Documentation du framework Ray Serve pour construire des déploiements vLLM distribués et évolutifs. Ray fournit des fonctionnalités avancées comme le redimensionnement automatique, le service multi-modèles et la gestion des ressources pour les systèmes de production.

• NVIDIA TensorRT-LLM - TensorRT-LLM de NVIDIA pour une inférence hautement optimisée sur les GPU NVIDIA. Alternative à vLLM avec des stratégies d’optimisation différentes, utile pour la comparaison et la compréhension du paysage d’optimisation d’inférence.

• Référence API OpenAI - Documentation officielle API OpenAI avec laquelle l’API de vLLM est compatible. Référencez ceci lors de la construction d’applications qui doivent fonctionner avec les points de terminaison OpenAI et vLLM auto-hébergés de manière interchangeable.