Démarrage rapide de vLLM : Hébergement de LLM à haute performance - en 2026

Déduire rapidement des modèles LLM avec l'API OpenAI

Sommaire

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

Avec son algorithme révolutionnaire PagedAttention, vLLM atteint un débit 14 à 24 fois plus élevé que les méthodes de service traditionnelles, ce qui en fait le choix idéal pour les déploiements de LLM en production. Pour voir comment vLLM s’intègre parmi Ollama, Docker Model Runner, LocalAI et les fournisseurs de nuage – y compris les compromis en termes de coût et d’infrastructure – consultez LLM Hosting: Local, Self-Hosted & Cloud Infrastructure Compared.

vllm logo

Qu’est-ce que vLLM ?

vLLM (virtual LLM) est une bibliothèque open source pour l’inférence et le service rapide des LLM qui est rapidement devenue l’industrie standard pour les déploiements en production. Sorti en 2023, il a introduit PagedAttention, une technique révolutionnaire de gestion de la mémoire qui améliore considérablement l’efficacité du service.

Fonctionnalités clés

Haute performance en termes de débit : vLLM fournit un débit 14 à 24 fois plus élevé par rapport à HuggingFace Transformers avec le même matériel. Ce gain de performance considérable provient du batchage continu, 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é qui est pleinement compatible avec le format OpenAI. Cela permet une migration sans problème d’OpenAI vers l’infrastructure auto-hébergée sans modifier le code de l’application. Il suffit de pointer votre client API vers l’extrémité de vLLM et il fonctionne de manière transparente.

Algorithme PagedAttention : L’innovation principale 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 sur demande. Cela réduit le gaspillage de mémoire jusqu’à 4 fois et permet des tailles de lots beaucoup plus grandes.

Batching continu : Contrairement au batching statique où vous attendez que toutes les séquences se terminent, vLLM utilise un batching 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 requêtes entrantes.

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

Large gamme de modèles pris en charge : Compatibilité avec des architectures de modèles populaires telles que LLaMA, Mistral, Mixtral, Qwen, Phi, Gemma et bien d’autres. Prend en charge à la fois les modèles instruction-tunés et les modèles de base provenant du HuggingFace Hub.

Quand utiliser vLLM

vLLM excelle dans des scénarios spécifiques où ses forces sont mises en évidence :

Services API de production : Lorsque vous avez besoin de servir un LLM à de nombreux utilisateurs simultanés via une API, le haut débit et le batchage efficace de vLLM en font le meilleur choix. Les entreprises qui gèrent 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 à forte concurrence : Si votre application a de nombreux utilisateurs simultanés qui font des requêtes, le batchage continu et PagedAttention de vLLM permettent de servir davantage d’utilisateurs avec le même matériel par rapport aux alternatives.

Optimisation des coûts : Lorsque les coûts 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é de mémoire de 4 fois de PagedAttention permet également d’utiliser des instances de GPU plus petites et moins chères.

Déploiements Kubernetes : La conception stateless de vLLM et son architecture adaptée aux conteneurs en font un choix idéal pour les clusters Kubernetes. Sa performance cohérente sous charge et sa gestion simple des ressources s’intègrent bien à l’infrastructure native du cloud.

Quand NE PAS utiliser vLLM : Pour le développement local, l’expérimentation ou les scénarios à usage unique, des outils comme Ollama offrent une meilleure expérience utilisateur avec une configuration plus simple. La complexité de vLLM est justifiée lorsqu’on a 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, RTX 20/30/40 series)
  • CUDA : Version 11.8 ou supérieure
  • Python : 3.8 à 3.11
  • VRAM : Minimum 16 Go pour les modèles de 7B, 24 Go+ pour les modèles de 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 l’utilisation de 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 les environnements de production :

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

# Exécuter vLLM avec le 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.

Compilation à partir des sources

Pour les dernières fonctionnalités ou les modifications personnalisées, compilez à partir des sources :

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

Guide de démarrage rapide de vLLM

Exécuter votre premier modèle

Démarrer vLLM avec un modèle via 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 le HuggingFace Hub (s’il n’est pas en cache) et démarrera le serveur. Vous verrez des sorties 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 que le serveur est en cours d’exécution, vous pouvez faire des requêtes en utilisant le client Python OpenAI ou curl :

Avec curl :

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

Avec le client Python OpenAI :

from openai import OpenAI

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

response = client.completions.create(
    model="mistralai/Mistral-7B-Instruct-v0.2",
    prompt="Expliquez ce que 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 propose 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 maximale de séquence
    --tensor-parallel-size 2 \        # Utiliser 2 GPU avec parallélisation tensorielle
    --dtype float16 \                 # Utiliser la précision FP16
    --max-num-seqs 256                # Taille maximale du lot

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 maximale du contexte. Réduire cela économise de la mémoire pour des lots plus grands.
  • --tensor-parallel-size : Nombre de GPU sur lesquels diviser le modèle.
  • --dtype : Type de données pour les poids (float16, bfloat16 ou float32). Le FP16 est généralement optimal.
  • --max-num-seqs : Nombre maximum de séquences à traiter dans un lot.

Comparaison entre vLLM et Ollama

À la fois vLLM et Ollama sont des choix populaires pour l’hébergement local des 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.

Performance et débit

vLLM est conçu pour un débit maximal dans les scénarios à plusieurs utilisateurs. Son algorithme PagedAttention et son batchage continu permettent de servir efficacement des centaines de demandes simultanées. Les benchmarks montrent que vLLM atteint un débit 14 à 24 fois plus élevé que les implémentations standard et 2 à 4 fois plus élevé qu’Ollama sous forte concurrence.

Ollama optimise pour l’utilisation interactive à usage unique avec un accent sur la latence faible pour les demandes individuelles. Bien qu’il ne corresponde pas au débit multi-utilisateurs de vLLM, il fournit une excellente performance pour le développement et l’utilisation personnelle avec des temps de démarrage froids plus rapides et une consommation de ressources inactives plus faible.

Facilité d’utilisation

Ollama remporte clairement en simplicité. L’installation est une seule commande (curl | sh), et l’exécution des modèles est aussi simple que ollama run llama2. Il inclut une bibliothèque de modèles avec des versions quantifiées optimisées pour différents profils de matériel. L’expérience utilisateur ressemble à celle de Docker – télécharger, 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 en production où vous avez besoin de tirer le maximum de performance de votre matériel.

API et intégration

vLLM fournit des API REST compatibles avec OpenAI par défaut, ce qui en fait un remplacement direct pour l’API OpenAI dans les applications existantes. Cela est crucial pour migrer les services en production des fournisseurs de nuage vers l’infrastructure auto-hébergée sans modification du code.

Ollama propose une API REST plus simple et une bibliothèque dédiée Python/JavaScript. Bien qu’elle soit fonctionnelle, elle n’est pas compatible avec OpenAI, ce qui nécessite des modifications du code lors de l’intégration avec des applications s’attendant à la format OpenAI. Cependant, des projets communautaires comme les adaptateurs Ollama-OpenAI comblent cette lacune.

Gestion de la mémoire

L’algorithme PagedAttention de vLLM fournit une efficacité de mémoire supérieure pour les demandes 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 en production.

Ollama utilise une gestion de mémoire plus simple adaptée aux scénarios à usage unique. Il 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 les usages de production à forte concurrence.

Prise en charge multi-GPU

vLLM excelle avec la parallélisation tensorielle native et la parallélisation en pipeline, répartissant efficacement les modèles sur 2 à 8+ GPU. Cela est essentiel pour servir des modèles volumineux comme les LLM de 70B paramètres qui ne tiennent pas dans la mémoire d’un seul GPU.

Ollama a actuellement une prise en charge limitée multi-GPU, fonctionnant principalement de manière optimale avec un seul GPU. Cela le rend moins adapté aux très grands modèles nécessitant une inférence distribuée.

Recommandations pour les cas d’utilisation

Choisissez vLLM lorsque :

  • Vous servez des API de production à de nombreux utilisateurs simultanés
  • Vous optimisez le coût par demande dans les déploiements de nuage
  • Vous exécutez dans des clusters Kubernetes ou des plateformes de orchestration de conteneurs
  • Vous avez besoin de la compatibilité API OpenAI pour les applications existantes
  • Vous servez des modèles volumineux nécessitant une prise en charge multi-GPU
  • La performance et le débit sont des exigences critiques

Choisissez Ollama lorsque :

  • Vous faites du développement local et de l’expérimentation
  • Vous avez besoin d’utilisation interactive à usage unique (assistants personnels, chatbots)
  • Vous faites de la prototypage rapide et de l’évaluation de modèles
  • Vous apprenez sur les LLM sans complexité d’infrastructure
  • Vous exécutez sur des ordinateurs de bureau ou des laptops personnels
  • La simplicité et la facilité d’utilisation sont des priorités

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

Comparaison entre vLLM et Docker Model Runner

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

Philosophie d’architecture

Docker Model Runner vise à être le « Docker pour l’IA » – une façon simple et standardisée de faire fonctionner localement les modèles d’IA avec la même facilité que d’exécuter des conteneurs. Il abstrait la complexité et fournit une interface cohérente à travers différents modèles et cadres.

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

Configuration et commencement

Docker Model Runner est simple à installer pour les utilisateurs de Docker :

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

Cette similarité avec le flux de travail des images Docker rend cela instantanément familier aux développeurs déjà utilisant 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 <model-name>

Caractéristiques de performance

vLLM fournit un débit supérieur pour les scénarios à plusieurs utilisateurs grâce à PagedAttention et au batchage continu. Pour les services API de production gérant des centaines de requêtes par seconde, les optimisations de vLLM offrent un débit 2 à 5 fois plus élevé que les approches de service générales.

Docker Model Runner se concentre sur la facilité d’utilisation plutôt que sur la performance maximale. Il est adapté aux développements locaux, tests et charges de travail modérées, mais ne met pas en œuvre les optimisations avancées qui font la force de vLLM à 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 (non seulement les LLM) y compris Stable Diffusion, Whisper et d’autres modèles d’IA, ce qui le rend plus versatile pour différentes charges de travail d’IA.

vLLM se spécialise dans l’inférence des LLM avec un soutien approfondi pour les modèles de langage basés sur les transformateurs. Il prend en charge tout 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 en production

vLLM a été éprouvé en production chez des entreprises comme Anthropic, Replicate et bien d’autres qui servent des milliards de tokens quotidiennement. Ses caractéristiques de performance et sa stabilité sous charge lourde en font le standard de facto pour le service des LLM en production.

Docker Model Runner est plus récent et se positionne davantage pour les scénarios de développement et de test locaux. Bien qu’il puisse servir le trafic de production, il manque de l’expérience éprouvée et des optimisations de performance nécessaires aux déploiements en production.

Écosystème d’intégration

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

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

Quand utiliser chaque outil

Utilisez vLLM pour :

  • Services API de production LLM
  • Déploiements à haut débit, à plusieurs utilisateurs
  • Déploiements en nuage sensibles au coût nécessitant une efficacité maximale
  • Environnements Kubernetes et natifs du cloud
  • Lorsque vous avez besoin d’une scalabilité éprouvée et de performances

Utilisez Docker Model Runner pour :

  • Développement et tests locaux
  • Exécution de différents types de modèles d’IA (non seulement les LLM)
  • Équipes fortement investies dans l’écosystème Docker
  • Expérimentation rapide sans configuration d’infrastructure
  • Apprentissage et usages pédagogiques

Approche hybride : Beaucoup d’équipes développent avec Docker Model Runner localement pour la commodité, puis déployent 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 pour le déploiement en production

Déploiement avec 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 sur 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 des métriques
metrics = requests.get("http://localhost:8000/metrics").text
print(metrics)

Métriques clés à surveiller :

  • vllm:num_requests_running - Demandes actives
  • vllm:gpu_cache_usage_perc - Utilisation du cache GPU
  • 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 selon le comportement observé. Des valeurs plus élevées permettent des lots plus grands mais risquent des erreurs OOM pendant les pics de trafic.

Ajuster la longueur maximale de séquence : 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 de 4K de contexte, définissez --max-model-len 4096 au lieu d’utiliser la longueur maximale du modèle (souvent 8K-32K).

Choisir la 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 le cache de préfixe : Pour les applications avec des prompts répétés (comme des chatbots avec des messages système), activez le cache de préfixe :

--enable-prefix-caching

Cela cache les valeurs KV pour les préfixes communs, réduisant le calcul pour les requêtes partageant le même préfixe de prompt.

Dépannage des problèmes courants

Erreurs de mémoire insuffisante

Symptômes : Le serveur se termine avec des erreurs de mémoire CUDA.

Solutions :

  • Réduisez --gpu-memory-utilization à 0,85 ou 0,80
  • Réduisez --max-model-len si votre cas d’utilisation le permet
  • Diminuez --max-num-seqs pour réduire la taille du lot
  • Utilisez une version quantifiée du modèle
  • Activez la parallélisation tensorielle pour répartir sur plus de GPU

Faible débit

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

Solutions :

  • Augmentez --max-num-seqs pour permettre des lots plus grands
  • Augmentez --gpu-memory-utilization si vous avez de la marge
  • Vérifiez si le CPU est un goulot d’étranglement avec htop – envisagez des processeurs plus rapides
  • Vérifiez l’utilisation du GPU avec nvidia-smi – devrait être de 95 %+
  • Activez le FP16 si vous utilisez le FP32 : --dtype float16

Temps de premier token lent

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

Solutions :

  • Utilisez des modèles plus petits pour les applications critiques en termes de latence
  • Activez le cache de préfixe pour les prompts répétés
  • Réduisez --max-num-seqs pour privilégier la latence par rapport au débit
  • Envisagez la décodage spéculative pour les modèles pris en charge
  • Optimisez la configuration de la parallélisation tensorielle

Échecs de chargement de modèle

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

Solutions :

  • Vérifiez que le nom du modèle correspond exactement au format HuggingFace
  • Vérifiez la connectivité réseau vers le HuggingFace Hub
  • Assurez-vous qu’il y a suffisamment d’espace disque dans ~/.cache/huggingface
  • Pour les modèles verrouillés, définissez la variable d’environnement HF_TOKEN
  • Essayez de télécharger manuellement avec huggingface-cli download <model>

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 tokens que vérifie un modèle cible plus grand. Cela peut accélérer la génération de 1,5 à 2 fois :

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

Adapters LoRA

Servez plusieurs adapters LoRA sur 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écifiez quel adapter utiliser par requête :

response = client.completions.create(
    model="sql-lora",  # Utiliser l'adapter SQL
    prompt="Convertissez cela en SQL : Affichez tous les utilisateurs créés ce mois-ci"
)

Service multi-LoRA

Le service multi-LoRA de vLLM permet d’héberger des dizaines d’adapters finement ajustés avec un surcoût mémoire minimal. C’est idéal pour servir des variantes de modèles spécifiques à un client ou à une tâche :

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

Cache de préfixe

Activez le cache automatique de préfixe pour éviter de recalculer le cache KV pour les préfixes de prompt répétés :

--enable-prefix-caching

Cela est particulièrement efficace pour :

  • Chatbots avec des prompts système fixes
  • Applications RAG avec des modèles de contexte cohérents
  • Prompts de few-shot répétés sur plusieurs demandes

Le cache de préfixe peut réduire le temps jusqu’au premier token de 50 à 80 % pour les demandes partageant des préfixes de prompt.

Exemples d’intégration

Intégration avec 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 avec 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 du débit (Mistral-7B sur GPU A100) :

  • vLLM : ~3 500 tokens/seconde avec 64 utilisateurs simultanés
  • HuggingFace Transformers : ~250 tokens/seconde avec la même concurrence
  • Ollama : ~1 200 tokens/seconde avec la même concurrence
  • Résultat : vLLM fournit une amélioration de 14 fois par rapport aux implémentations basiques

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

  • Implémentation standard : 24 Go de VRAM, 32 séquences simultanées
  • vLLM avec PagedAttention : 24 Go de VRAM, 128 séquences simultanées
  • Résultat : 4 fois 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 charge élevée

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

Analyse des coûts

Comprendre les implications des coûts de choisir vLLM :

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

Avec le service standard :

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

Avec vLLM :

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

Cette avantage de coût s’accroît avec l’échelle. Les organisations servant des milliards de tokens par mois économisent des centaines de milliers de dollars en utilisant le service optimisé de vLLM au lieu des implémentations naïves.

Considérations de sécurité

Authentification

vLLM ne comprend 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 un contrôle de débit d’entreprise.

Isolation réseau

Exécutez vLLM sur 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

Contrôle de débit

Implémentez un contrôle de débit pour prévenir les abus :

# Exemple d'utilisation de Redis pour le contrôle 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 lesquels utilisateurs peuvent accéder auxquels 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 à vLLM

Migrer de OpenAI à 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é l'authentification
)
response = client.chat.completions.create(
    model="mistralai/Mistral-7B-Instruct-v0.2",
    messages=[{"role": "user", "content": "Bonjour"}]
)

Seulement deux changements nécessaires : mettre à jour base_url et le nom du modèle. Toute autre code reste identique.

De Ollama à 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 API à travers votre codebase, mais les bibliothèques de client OpenAI offrent de meilleures gestion d’erreurs et des fonctionnalités.

De HuggingFace Transformers à vLLM

Migration directe de l’utilisation 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 bien plus rapide pour l’inférence par lot.

Avenir de vLLM

vLLM continue de développer rapidement avec des fonctionnalités passionnantes sur la roadmap :

Service défragmenté : Séparer le préremplissage (traitement des prompts) et le décodage (génération des tokens) 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 exécuter sur du matériel spécialisé améliore l’efficacité.

Inférence multi-nœuds : Répartir les très grands modèles (100B+ paramètres) sur plusieurs machines, permettant de servir des modèles trop volumineux 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 une meilleure performance avec les modèles quantifiés.

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

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

Meilleure couverture de modèles : Étendre le support aux modèles multimodaux (modèles vision-langage), modèles audio et architectures spécialisées à mesure qu’elles apparaissent.

Le projet vLLM maintient un développement actif avec des contributions de l’Université de Californie à Berkeley, d’Anyscale et de la communauté open source plus large. Alors que le déploiement des LLM devient de plus en plus critique pour les systèmes en production, le rôle de vLLM comme standard de performance continue de croître. Pour une comparaison plus large de vLLM avec d’autres infrastructures locales et cloud des LLM, consultez notre LLM Hosting: Local, Self-Hosted & Cloud Infrastructure Compared.

Liens utiles

Articles liés sur ce site

  • Hébergement local des LLM : Guide complet 2026 - Ollama, vLLM, LocalAI, Jan, LM Studio & Plus - Comparaison complète de 12+ outils d’hébergement local des LLM, incluant une analyse détaillée de vLLM, ainsi que Ollama, LocalAI, Jan, LM Studio et d’autres. Couvre la maturité de l’API, la prise en charge de l’appel d’outils, la compatibilité GGUF et les benchmarks de performance pour aider à choisir la bonne solution.

  • Fiche de référence Ollama - Référence complète des commandes d’Ollama et fiche de référence couvrant l’installation, la gestion des modèles, l’utilisation de l’API et les bonnes pratiques pour le déploiement local des LLM. Essentielle pour les développeurs utilisant Ollama, qu’ils l’utilisent avec ou à la place de vLLM.

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

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

Ressources externes et documentation

  • Dépôt GitHub vLLM - Dépôt officiel de vLLM avec le code source, une documentation complète, des guides d’installation et des discussions actives de la communauté. 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 aux configurations avancées. Inclut des références API, des guides d’optimisation des performances et des bonnes pratiques de déploiement.

  • Papier 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 de vLLM présentant les annonces de mise à jour, les benchmarks de performance, les analyses techniques approfondies et des études de cas de la communauté issues de déploiements en production.

  • HuggingFace Model Hub - Référentiel complet de modèles LLM open source compatibles 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 à grande échelle et distribués. Ray propose des fonctionnalités avancées comme l’autoscaling, le service multimodèle et la gestion des ressources pour les systèmes en 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 de l’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érez-vous-y lors de la création d’applications nécessitant de fonctionner avec les endpoints OpenAI et vLLM auto-hébergés de manière interchangeable.