vLLM : Démarrage rapide pour le déploiement de LLM hautes performances - en 2026

Inférence rapide de LLM avec l'API OpenAI

Sommaire

vLLM est un moteur d’inférence et de déploiement à 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’Université de Californie à Berkeley.

Grâce à son algorithme révolutionnaire PagedAttention, vLLM offre un débit 14 à 24 fois supérieur aux méthodes de service traditionnelles, ce qui en fait le choix privilégié pour les déploiements de LLM en production. Pour voir comment vLLM se situe par rapport à Ollama, Docker Model Runner, LocalAI et aux fournisseurs cloud — y compris les compromis en matière de coût et d’infrastructure — consultez Hébergement de LLM : Local, Auto-hébergé & Infrastructure Cloud Comparés.

Logo vllm

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 industrielle pour les déploiements en production. Lancé en 2023, il a introduit PagedAttention, une technique de gestion de la mémoire révolutionnaire qui améliore considérablement l’efficacité du service.

Fonctionnalités clés

Performances à haut débit : vLLM offre un débit 14 à 24 fois supérieur par rapport aux Transformers de HuggingFace avec le même matériel. Cette énorme amélioration des performances 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 l’endpoint 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’à 4x et permet des tailles de lot beaucoup plus grandes.

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

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

Large prise en charge des modèles : Compatible avec les architectures de modèles populaires telles que LLaMA, Mistral, Mixtral, Qwen, Phi, Gemma, et beaucoup d’autres. Prend en charge les modèles ajustés pour les instructions et les modèles de base de HuggingFace Hub.

Quand utiliser vLLM

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

Services d’API en production : Lorsque vous devez servir un LLM à de nombreux utilisateurs simultanés via une API, le haut débit et le regroupement efficace de vLLM en font le meilleur choix. Les entreprises qui exécutent 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 requêtes, 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 GPU sont un sujet de 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 de 4x grâce à PagedAttention permet également d’utiliser des instances GPU plus petites et moins chères.

Déploiements Kubernetes : La conception sans état de vLLM et son architecture conviviale pour les conteneurs en font l’idéal pour les clusters Kubernetes. Ses performances cohérentes 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 à un seul utilisateur, des outils comme Ollama ou llama.cpp offrent une meilleure expérience utilisateur avec une configuration plus simple. La complexité de vLLM est justifiée lorsque vous avez besoin de ses avantages de performance pour des charges de travail de production.

Comment installer vLLM

Prérequis

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

  • GPU : NVIDIA GPU avec 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 les 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 consiste à 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 des versions CUDA différentes, 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 correcte.

Construction à partir de la source

Pour les dernières fonctionnalités ou modifications personnalisées, construisez à partir de la source :

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

Guide rapide de vLLM

Exécution de votre premier modèle

Démarrage de 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:     Started server process [12345]
INFO:     Waiting for application startup.
INFO:     Application startup complete.
INFO:     Uvicorn running on http://0.0.0.0:8000

Faire des requêtes API

Une fois le serveur en cours d’exécution, vous pouvez faire des requêtes 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 de 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 de tenseur
    --dtype float16 \                 # Utiliser la précision FP16
    --max-num-seqs 256                # Taille de lot maximale

Explication des paramètres clés :

  • --gpu-memory-utilization : Quelle quantité 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 cela é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 maximum de séquences à traiter dans un lot.

Comparaison vLLM vs Ollama

vLLM et Ollama sont tous deux des choix populaires pour l’hébergement local de LLM, mais ils ciblent des cas d’utilisation différents. Comprendre quand utiliser chaque outil peut avoir un impact significatif sur le succès de votre projet.

Performances et débit

vLLM est conçu pour un débit maximal dans les scénarios multi-utilisateurs. Son PagedAttention et son regroupement continu permettent de servir des centaines de requêtes simultanées efficacement. Les benchmarks montrent que vLLM atteint un débit 14 à 24 fois supérieur aux implémentations standard et 2 à 4 fois supérieur à Ollama sous haute concurrence.

Ollama optimise pour une utilisation interactive à un seul utilisateur avec un accent sur la faible latence pour les requêtes individuelles. Bien qu’il ne corresponde pas au débit multi-utilisateurs de vLLM, il offre d’excellentes performances pour le développement et l’utilisation personnelle avec des temps de démarrage à froid plus rapides et une consommation de ressources au repos plus faible.

Facilité d’utilisation

Ollama gagne de manière décisive sur la simplicité. L’installation est une seule commande (curl | sh), et l’exécution de modèles est aussi simple que ollama run llama2. Il comprend une bibliothèque de modèles avec des versions quantifiées optimisées pour différents profils matériels. L’expérience utilisateur ressemble à Docker : tirer, exécuter, et partir.

vLLM nécessite plus de configuration : gestion de l’environnement Python, installation de CUDA, compréhension des paramètres de service, et spécification manuelle des modèles. La courbe d’apprentissage est plus raide, mais vous gagnez un contrôle fin sur l’optimisation des performances. Cette complexité est justifiée pour les déploiements de production où vous devez extraire les performances maximales de votre matériel.

API et intégration

vLLM fournit des API REST compatibles avec OpenAI dès la sortie, ce qui en fait un remplacement direct pour l’API OpenAI dans les applications existantes. C’est crucial pour migrer les services de production des fournisseurs cloud vers une infrastructure auto-hébergée sans modifier le code.

Ollama offre une API REST plus simple et une bibliothèque Python/JavaScript dédiée. Bien que fonctionnelle, elle n’est pas compatible avec OpenAI, nécessitant des modifications de code lors de l’intégration avec des applications attendant le format d’OpenAI. Cependant, des projets communautaires comme les adaptateurs Ollama-OpenAI comblent ce fossé.

Gestion de la mémoire

PagedAttention de vLLM offre une efficacité mémoire supérieure pour les requêtes simultanées. Il peut servir 2 à 4 fois plus d’utilisateurs simultanés avec la même VRAM par rapport aux implémentations naïves. Cela se traduit directement par des économies de coûts dans les déploiements de production.

Ollama utilise une gestion de mémoire plus simple adaptée aux scénarios à un seul utilisateur. Elle gère automatiquement le chargement/déchargement des modèles en fonction de l’activité, ce qui est pratique pour le développement mais pas optimal pour une utilisation de production à haute concurrence.

Support multi-GPU

vLLM excelle avec le parallélisme de tenseur et le parallélisme de pipeline natifs, distribuant efficacement les modèles sur 2 à 8+ GPU. C’est essentiel pour servir de grands modèles comme les LLM de 70 milliards de paramètres qui ne rentrent pas dans un seul GPU.

Ollama a actuellement un support multi-GPU limité, fonctionnant principalement mieux avec un seul GPU. Cela le rend moins adapté pour les modèles très gros nécessitant une inférence distribuée.

Recommandations de cas d’utilisation

Choisissez vLLM lorsque :

  • Vous servez des APIs de production avec de nombreux utilisateurs simultanés
  • Vous optimisez le coût par requête dans les déploiements cloud
  • Vous exécutez dans Kubernetes ou des plateformes d’orchestration de conteneurs
  • Vous avez besoin de la compatibilité API OpenAI pour les applications existantes
  • Vous servez de grands modèles nécessitant un support multi-GPU
  • Les performances et le débit sont des exigences critiques

Choisissez Ollama lorsque :

  • Développement local et expérimentation
  • Utilisation interactive à un seul utilisateur (assistants personnels, chatbots)
  • Prototypage rapide et évaluation de modèles
  • Apprendre les LLM sans complexité d’infrastructure
  • Exécution sur des postes de travail personnels ou des ordinateurs portables
  • La simplicité et la facilité d’utilisation sont des priorités

De nombreuses équipes utilisent les deux : Ollama pour le développement et l’expérimentation, puis vLLM pour le déploiement en production. Cette combinaison offre une productivité des développeurs tout en maintenant les performances de production.

vLLM vs Docker Model Runner

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

Philosophie architecturale

Docker Model Runner vise à être le “Docker pour l’IA” — une manière simple et standardisée de faire fonctionner des modèles d’IA localement avec la même facilité que l’exécution de conteneurs. Il abstraie la complexité et fournit une interface cohérente entre différents modèles et cadres.

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

Configuration et démarrage

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

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

Cette ressemblance avec le flux de travail des images de Docker le rend immédiatement 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-modèle>

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 d’API de production gérant des centaines de requêtes par seconde, les optimisations de vLLM offrent 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 des performances maximales. Il convient au développement local, aux tests et aux charges de travail modérées, mais ne met pas en œuvre les optimisations avancées qui permettent à vLLM de s’extraire à grande échelle.

Prise en charge 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 cadres (pas seulement les LLM) incluant Stable Diffusion, Whisper et d’autres modèles d’IA, le rendant plus polyvalent pour différentes charges de travail d’IA.

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

Déploiement de production

vLLM a été testé en production dans des entreprises comme Anthropic, Replicate, et beaucoup d’autres servant des milliards de jetons quotidiennement. Ses caractéristiques de performance et sa stabilité sous forte charge en font la norme de facto pour le service de 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 exigent.

É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 vaste compatibilité API OpenAI pour les applications existantes.

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

Quand utiliser chacun

Utilisez vLLM pour :

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

Utilisez Docker Model Runner pour :

  • Développement et test local
  • Exécution de divers types de modèles d’IA (pas seulement des LLM)
  • Équipes fortement investies dans l’écosystème Docker
  • Expérimentation rapide sans configuration d’infrastructure
  • Buts pédagogiques et d’apprentissage

Approche hybride : De nombreuses équipes développent avec Docker Model Runner localement pour la commodité, puis déploient avec vLLM en production pour la performance. 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 de production

Déploiement Docker

Créer une configuration Docker Compte 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 l’é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)

Métriques clés à 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

Réglage 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 lors des pics de trafic.

Réglage de 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 économise de la mémoire pour des lots plus grands. Par exemple, si vous avez seulement besoin 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 des 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 courants, 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 de mémoire insuffisante.

Solutions :

  • Réduire --gpu-memory-utilization à 0.85 ou 0.80
  • Diminuer --max-model-len si votre cas d’utilisation le permet
  • Diminuer --max-num-seqs pour réduire la taille du lot
  • Utiliser une version de modèle quantifiée
  • Activer le parallélisme de tenseur 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 un goulot d’étranglement avec htop — envisager 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 de premier token 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 sensibles à la latence
  • Activer la mise en cache des préfixes pour les invites répétées
  • Réduire --max-num-seqs pour prioriser la latence sur le débit
  • Envisager le décodage spéculatif pour les modèles pris en charge
  • Optimiser la configuration du parallélisme de tenseur

Échecs de chargement de modèle

Symptômes : Le serveur échoue à démarrer, 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 d’avoir suffisamment d’espace disque dans ~/.cache/huggingface
  • Pour les modèles verrouillés, définir la variable d’environnement HF_TOKEN
  • Essayer de télécharger manuellement avec huggingface-cli download <modèle>

Fonctionnalités avancées

Décodage spéculatif

vLLM prend en charge le décodage spéculatif, où un modèle de brouillon 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 à 2x :

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=./path/to/sql-adapter \
                   code-lora=./path/to/code-adapter

Puis spécifier quel adaptateur utiliser par requête :

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

Service multi-LoRA

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

# Requête avec un 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 des préfixes automatique 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 invites système fixes
  • Applications RAG avec des modèles de contexte cohérents
  • Invites d’apprentissage few-shot répétées entre les requêtes

La mise en cache des préfixes peut réduire le temps jusqu’au premier token 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("Expliquez 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 réelles aident à illustrer les avantages de vLLM :

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

  • vLLM : ~3 500 jetons/seconde avec 64 utilisateurs simultanés
  • Transformers HuggingFace : ~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 simultanées
  • vLLM avec PagedAttention : 24 Go VRAM, 128 séquences simultanées
  • Résultat : 4x plus de requêtes simultanées 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 cohérente sous forte charge

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

Analyse des coûts

Comprendre les implications financières du choix de vLLM :

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

Avec un service standard :

  • Requis : 8x GPU A100 (80 Go)
  • Coût AWS : ~32 $/heure × 24 × 30 = 23 040 $/mois
  • Coût par 1 million 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 1 million 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 plutôt que des implémentations naïves.

Considérations de sécurité

Authentification

vLLM n’inclut pas d’authentification par défaut. Pour la production, mettez en œuvre 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 de niveau entreprise et une limitation de débit.

Isolation réseau

Exécutez vLLM dans des réseaux privés, pas directement exposés à 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

Mettez en œuvre une limitation de débit pour prévenir les abus :

# Exemple en 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 aux modèles

Pour les déploiements multi-locataires, contrôlez 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

De OpenAI vers vLLM

La migration de 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://your-vllm-server.com/v1",
    api_key="your-internal-key"  # Si vous avez ajouté une authentification
)
response = client.chat.completions.create(
    model="mistralai/Mistral-7B-Instruct-v0.2",
    messages=[{"role": "user", "content": "Bonjour"}]
)

Seules deux modifications sont nécessaires : mettre à jour base_url et le nom du modèle. Tout le reste du code reste identique.

De Ollama vers vLLM

Ollama utilise un format d’API différent. Voici la conversion :

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 ?"
)

Vous devrez mettre à jour les appels d’API dans toute votre base de code, mais les bibliothèques clientes OpenAI offrent une meilleure gestion des erreurs et des fonctionnalités.

De HuggingFace Transformers vers 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 de se développer rapidement avec des fonctionnalités passionnantes sur la feuille de route :

Service désagrégé : Séparer le préfixe (traitement des invites) et le décodage (génération de jetons) sur différents GPU pour optimiser l’utilisation des ressources. Le préfixe 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 les modèles très gros (100 milliards de paramètres+) sur plusieurs machines, permettant de servir des modèles trop gros pour les configurations à nœud unique.

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

Améliorations du décodage spéculatif : Modèles de brouillon 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 circulaire pour les contextes extrêmement longs (100K+ jetons) et autres mécanismes d’attention de pointe.

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

Le projet vLLM maintient un développement actif avec des contributions de l’Université de Californie à Berkeley, Anyscale et de la communauté open-source plus large. À mesure que le déploiement de LLM devient plus critique pour les systèmes de production, le rôle de vLLM en tant que norme de performance continue de croître. Pour une comparaison plus large de vLLM avec d’autres infrastructures de LLM locales et cloud, consultez notre Hébergement de LLM : Local, Auto-hébergé & Infrastructure Cloud Comparés.

Liens utiles

Articles connexes sur ce site

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

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

  • Démarrage rapide de llama.cpp avec CLI et serveur - Inférence légère C/C++ 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 local de LLM, analysant les performances, le support GPU, la compatibilité API et les cas d’utilisation. Aide à comprendre le paysage concurrentiel dans lequel évolue vLLM.

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

Ressources externes et documentation

  • Dépôt GitHub vLLM - Dépôt 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 résoudre les 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 d’API, les guides de réglage 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 les annonces de version, les benchmarks de performance, les plongées techniques et les études de cas communautaires provenant de déploiements de production.

  • HuggingFace Model Hub - Dépôt 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 cadre Ray Serve pour construire des déploiements vLLM évolutifs et distribués. Ray fournit des fonctionnalités avancées comme l’évolutivité 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 de l’API OpenAI avec laquelle l’API de vLLM est compatible. Référencer ceci lors de la construction d’applications qui doivent fonctionner avec les endpoints OpenAI et vLLM auto-hébergés de manière interchangeable.