vLLM Quickstart : Servir des LLM à haute performance

vLLM est un moteur d’inférence et de service 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 aux méthodes de service traditionnelles, ce qui en fait le choix privilégié pour les déploiements de production de LLM.

Qu’est-ce que vLLM ?

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

Fonctionnalités clés

Performance à haut débit : vLLM offre un débit 14 à 24 fois supérieur à celui de HuggingFace Transformers avec le même matériel. Ce gain de performance considérable provient du batching 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é entièrement compatible avec le format OpenAI. Cela permet une migration transparente d’OpenAI vers une infrastructure auto-hébergée sans modifier le code de l’application. Il suffit d’orienter votre client API vers le point de terminaison de vLLM et cela fonctionne de manière transparente.

Algorithme PagedAttention : L’innovation centrale derrière la performance 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 batch beaucoup plus grandes.

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

Support multi-GPU : vLLM prend en charge le parallélisme de tenseur et le parallélisme de pipeline pour distribuer de 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, en supportant des configurations de 2 à 8+ GPU.

Large support des modèles : Compatible avec les architectures de modèles populaires, y compris LLaMA, Mistral, Mixtral, Qwen, Phi, Gemma et bien d’autres. Prend en charge à la fois les modèles ajustés aux instructions et les modèles de base de HuggingFace Hub.

Quand utiliser vLLM

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

Services API de production : Lorsque vous devez servir un LLM à de nombreux utilisateurs simultanés via une API, le haut débit et le batching 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 concurité : Si votre application a de nombreux utilisateurs simultanés faisant des requêtes, le batching continu et PagedAttention de vLLM permettent de servir plus d’utilisateurs avec le même matériel que les alternatives.

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

Déploiements Kubernetes : La conception sans état et l’architecture conviviale des conteneurs de vLLM en font un choix idéal pour les clusters Kubernetes. Sa performance constante sous charge et sa gestion des ressources directe s’intègrent bien avec les infrastructures cloud natives.

Quand NE PAS utiliser vLLM : Pour le développement local, l’expérimentation ou les scénarios à utilisateur unique, des outils comme Ollama 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 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 les modèles 13B, 40 Go+ pour les modèles plus grands
• Pilote : Pilote NVIDIA 450.80.02 ou ultérieur

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 ultérieur :

# 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, surtout pour la 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 appropriée.

Construction à partir de la source

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

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

Guide de démarrage rapide de vLLM

Exécution de 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 requêtes en utilisant le client Python OpenAI ou curl :

Utilisation de 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
    }'

Utilisation du 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 n'exige 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étion 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 maximale de la séquence
    --tensor-parallel-size 2 \        # Utiliser 2 GPU avec parallélisme de tenseur
    --dtype float16 \                 # Utiliser la précision FP16
    --max-num-seqs 256                # Taille maximale du batch

Paramètres clés expliqués :

• --gpu-memory-utilization : Pourcentage de la mémoire GPU à utiliser (0,90 = 90 %). Des valeurs plus élevées permettent des batches plus grands mais laissent moins de marge pour les pics de mémoire.
• --max-model-len : Longueur maximale du contexte. La réduire économise de la mémoire pour des batches 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 batch.

Comparaison entre vLLM et Ollama

vLLM et Ollama sont tous deux des choix populaires pour l’hébergement local de modèles de langage, 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 des scénarios multi-utilisateurs. Son mécanisme PagedAttention et le batching continu permettent de servir efficacement des centaines de requêtes simultanées. Les benchmarks montrent que vLLM atteint un débit 14 à 24 fois supérieur aux implémentations standards et 2 à 4 fois supérieur à Ollama dans des conditions de forte concurrence.

Ollama optimise l’utilisation interactive pour un seul utilisateur avec un accent sur la faible latence pour les requêtes individuelles. Bien qu’il ne rivalise pas avec le 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 ralenti plus faible.

Facilité d’utilisation

Ollama l’emporte clairement en simplicité. L’installation se fait en 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 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 en production où vous devez tirer le maximum de performance de votre matériel.

API et intégration

vLLM fournit des API REST compatibles avec OpenAI dès la sortie de la boîte, ce qui en fait un remplacement direct de l’API OpenAI dans les applications existantes. Cela 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 s’attendant au format OpenAI. Cependant, des projets communautaires comme les adaptateurs Ollama-OpenAI comblent cette lacune.

Gestion de la mémoire

L’algorithme 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 la mémoire plus simple adaptée aux scénarios à utilisateur 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 une utilisation en production à haute concurrence.

Prise en charge multi-GPU

vLLM excelle avec un parallélisme de tenseur natif et un parallélisme de pipeline, distribuant efficacement les modèles sur 2 à 8+ GPU. Cela est essentiel pour servir des modèles volumineux comme les LLMs de 70 milliards de paramètres qui ne tiennent pas dans un seul GPU.

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

Recommandations d’utilisation

Choisissez vLLM lorsque :

• Vous servez des API 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 compatibilité avec l’API OpenAI pour les applications existantes
• Vous servez de grands modèles nécessitant une prise en charge multi-GPU
• Les performances et le débit sont des exigences critiques

Choisissez Ollama lorsque :

• Développement local et expérimentation
• Utilisation interactive pour un seul utilisateur (assistants personnels, chatbots)
• Prototypage rapide et évaluation des modèles
• Apprentissage sur les LLMs sans complexité d’infrastructure
• Exécution sur des postes de travail ou des ordinateurs portables personnels
• Simplicité et 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é de développement tout en maintenant des performances de production.

vLLM vs Docker Model Runner

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

Philosophie d’architecture

Docker Model Runner vise à être le “Docker pour l’IA” – une méthode simple et standardisée pour exécuter des modèles d’IA localement avec la même facilité que l’exécution de conteneurs. Il abstrait 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 de LLMs avec une performance maximale. C’est un outil de niveau inférieur que vous conteneurisez avec Docker, plutôt qu’une plateforme complète.

Configuration et prise en main

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 workflow des images 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 <model-name>

Caractéristiques de performance

vLLM offre un débit supérieur pour les scénarios multi-utilisateurs grâce à PagedAttention et au batching continu. Pour les services d’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 la performance maximale. Il convient 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.

Prise en charge des modèles

Docker Model Runner fournit une bibliothèque de modèles sélectionnés avec un accès en une seule commande aux modèles populaires. Il prend en charge plusieurs frameworks (pas seulement les LLMs) y compris 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 LLMs 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 d’IA comme la génération d’images ou la reconnaissance vocale.

Déploiement en production

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

Docker Model Runner est plus récent et se positionne davantage pour les scénarios de développement et de tests locaux. 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é étendue 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 déjà standardisées sur Docker, cette intégration offre une expérience cohésive mais moins de fonctionnalités spécialisées pour le service de LLMs.

Quand utiliser chacun

Utilisez vLLM pour :

• Services d’API de LLMs en production
• Déploiements multi-utilisateurs à haut débit
• 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

Utilisez Docker Model Runner pour :

• Développement et tests locaux
• Exécution de différents types de modèles d’IA (pas seulement des LLMs)
• Équipes fortement investies dans l’écosystème Docker
• Expérimentation rapide sans configuration d’infrastructure
• Apprentissage et objectifs éducatifs

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.

Bonnes pratiques de 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 avec Kubernetes

Déployez vLLM sur Kubernetes pour une mise à l’échelle en 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 de la mémoire 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 de mémoire insuffisante lors des pics de trafic.

Régler 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 le maximum du modèle (souvent 8K-32K).

Choisir une quantification appropriée : Pour les modèles qui la supportent, utilisez des versions quantifiées (8 bits, 4 bits) 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 des préfixes : Pour les applications avec des invites répétées (comme les chatbots avec des messages système), activez le 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 de mémoire insuffisante.

Solutions :

• Réduisez --gpu-memory-utilization à 0,85 ou 0,80
• Diminuez --max-model-len si votre cas d’utilisation le permet
• Abaissez --max-num-seqs pour réduire la taille des lots
• Utilisez une version quantifiée du modèle
• Activez le parallélisme de tenseurs 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 CPU plus rapides
• Vérifiez l’utilisation du GPU avec nvidia-smi – elle devrait être de 95 %+
• Activez FP16 si vous utilisez FP32 : --dtype float16

Temps de premier jet 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 des préfixes pour les invites répétées
• Réduisez --max-num-seqs pour privilégier la latence par rapport au débit
• Envisagez le décodage spéculatif pour les modèles pris en charge
• Optimisez la configuration du parallélisme de tenseurs

Échecs de chargement du 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 avec le Hub HuggingFace
• Assurez-vous d’avoir suffisamment d’espace disque dans ~/.cache/huggingface
• Pour les modèles protégé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 jetons qu’un modèle cible plus grand vérifie. 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

Adaptateurs LoRA

Servez plusieurs adaptateurs 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 adaptateur utiliser par requête :

response = client.completions.create(
    model="sql-lora",  # Utiliser l'adaptateur SQL
    prompt="Convert this to SQL: Show me all users created this month"
)

Hébergement multi-LoRA

Le service multi-LoRA de vLLM permet d’héberger des dizaines d’adaptateurs finement ajustés avec un faible surcoût en mémoire. Cela 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": "Write SQL query"}],
    extra_body={"lora_name": "sql-lora"}
)

Cache des préfixes

Activez le cache automatique des préfixes pour éviter de recomputer le cache KV pour les préfixes d’invite répétés :

--enable-prefix-caching

Cela est particulièrement efficace pour :

• Les chatbots avec des invites système fixes
• Les applications RAG avec des modèles de contexte constants
• Les invites d’apprentissage par quelques exemples répétées entre les requêtes

Le 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 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("Explain PagedAttention in simple terms")
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("What is 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 du 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 simultanéité
• Ollama : ~1 200 jetons/seconde avec la même simultanéité
• 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 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
• Serveur standard : Latence P50 650 ms, Latence P99 3 200 ms à 100 req/s
• Résultat : vLLM maintient une latence constante sous charge élevée

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 :

• Nécessaire : 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 :

• Nécessaire : 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 financier augmente avec l’échelle. Les organisations servant des milliards de jetons par mois é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 une utilisation en production, implémentez l’authentification au niveau du reverse proxy :

# 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.

Isolement réseau

Exécutez vLLM dans des réseaux privés, non 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

Implémentez une limitation de débit pour prévenir les 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 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 à vLLM

La migration de OpenAI à vLLM auto-hébergé est simple grâce à la compatibilité des 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": "Hello"}]
)

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": "Hello"}]
)

Seules deux modifications sont nécessaires : mettre à jour base_url et le nom du model. Tout le reste du 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': 'Why is the sky blue?'
    })

É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="Why is the sky blue?"
)

Vous devrez mettre à jour les appels API dans votre code, mais les bibliothèques clientes OpenAI fournissent une meilleure gestion des 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("Hello", 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("Hello", 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.

Avenir de vLLM

vLLM continue son développement rapide avec des fonctionnalités passionnantes à venir :

Serveur désagrégé : Séparation du préremplissage (traitement de l’invite) et du décodage (génération de jetons) sur différentes GPUs pour optimiser l’utilisation des ressources. Le préremplissage est borné par le calcul tandis que le décodage est borné par la mémoire, donc les exécuter sur des matériels spécialisés améliore l’efficacité.

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

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 brouillon plus efficaces et stratégies de spéculation adaptatives pour obtenir 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+ 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 au fur et à mesure de leur émergence.

Le projet vLLM maintient un développement actif avec des contributions de l’UC Berkeley, Anyscale et de la communauté open-source plus large. À mesure que le déploiement des 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.

Liens utiles

Articles connexes sur ce site

• Hébergement local de LLM : Guide complet 2025 - Ollama, vLLM, LocalAI, Jan, LM Studio & plus - Comparaison complète 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 autres. Couvre la maturité de l’API, le support des appels d’outils, la compatibilité GGUF et les benchmarks de performance pour aider à choisir la bonne solution.

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

• Docker Model Runner vs Ollama : lequel choisir ? - Comparaison approfondie de Docker Model Runner et 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 vLLM opère.

• Fiche mémo Docker Model Runner : commandes et exemples - Fiche mémo 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 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 API, les guides de réglage des performances et les bonnes 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 versions, les benchmarks de performance, les analyses techniques approfondies et les études de cas communautaires issues de déploiements en production.

• Hub de modèles HuggingFace - Répertoire 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 modèle adapté à 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’auto-échelle, 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 GPUs NVIDIA. Alternative à vLLM avec différentes stratégies d’optimisation, utile pour la comparaison et la compréhension du paysage d’optimisation de l’inférence.

• Référence de l’API OpenAI - Documentation officielle de l’API OpenAI avec laquelle l’API vLLM est compatible. Référez-vous à cela lorsque vous construisez des applications qui doivent fonctionner avec les points de terminaison OpenAI et vLLM auto-hébergés de manière interchangeable.