Déploiement avec vLLM

vLLM : le moteur d’inférence recommandé

vLLM est le moteur d’inférence Python le plus populaire pour les LLM. Il est recommandé par Mistral AI pour le self-hosting grâce à sa facilité d’utilisation, ses performances et son API compatible OpenAI. Nous allons parcourir l’installation, la configuration, puis les deux modes d’utilisation qu’il propose : le mode batch, dit offline, et le mode serveur. Ces deux modes ne s’opposent pas — beaucoup d’équipes utilisent le premier pour préparer des données et le second pour servir l’application.

Ce qu’il faut avoir sous la main

Le téléchargement des modèles passe par Hugging Face, donc par un token disposant de la permission READ :

export HF_TOKEN="hf_votre_token_ici"

Avant le premier téléchargement, acceptez les conditions d’utilisation sur la page du modèle sur Hugging Face (par exemple : huggingface.co/mistralai/Mistral-Nemo-Instruct-2407). Cette acceptation est manuelle et se fait une seule fois par compte ; l’oublier produit un échec de téléchargement que l’on met parfois une heure à diagnostiquer parce qu’il ressemble à un problème d’authentification.

Côté environnement Python, un virtualenv dédié évite les conflits de versions avec le reste de vos projets :

# Créer un environnement virtuel
python -m venv vllm-env
source vllm-env/bin/activate

# Installer vLLM (version >= 0.6.1.post1)
pip install vllm

Reste le matériel, qui détermine ce que vous pourrez réellement servir. Mistral 7B et Nemo tiennent sur un seul GPU de 24 Go, typiquement une A10G, une RTX 4090 ou une L4. Mixtral 8x7B exige deux GPU de 80 Go, en pratique des A100-80GB. Mistral Large 2 en version open-weight, avec ses 123 milliards de paramètres, demande au minimum quatre A100-80GB. Dans tous les cas, les drivers NVIDIA et CUDA 12.x doivent être installés avant vLLM.

Mode offline : traiter des lots

Le mode offline est adapté au traitement de lots de requêtes sans serveur HTTP. Vous chargez le modèle en mémoire, traitez vos requêtes et récupérez les résultats. Notez les trois arguments tokenizer_mode, load_format et config_format : nous y reviendrons, ils ne sont pas facultatifs.

from vllm import LLM
from vllm.sampling_params import SamplingParams

# Charger le modèle avec les flags Mistral
llm = LLM(
    model="mistralai/Mistral-Nemo-Instruct-2407",
    tokenizer_mode="mistral",
    load_format="mistral",
    config_format="mistral"
)

# Paramètres de génération
sampling = SamplingParams(
    max_tokens=8192,
    temperature=0.3
)

# Traiter un lot de requêtes
messages_batch = [
    [{"role": "user", "content": "Qu'est-ce que PagedAttention ?"}],
    [{"role": "user", "content": "Explique le tensor parallelism."}],
    [{"role": "user", "content": "Comment fonctionne le KV cache ?"}],
]

results = llm.chat(messages=messages_batch[0], sampling_params=sampling)
for output in results:
    print(output.outputs[0].text)

Ce mode brille sur le traitement batch de documents — résumé, classification —, sur l’évaluation de modèles au regard de benchmarks, sur la génération de données synthétiques et sur les scripts de test et de prototypage. Chaque fois que personne n’attend la réponse en direct, vous gagnez à éviter la couche HTTP.

Mode serveur : exposer une API

Le mode serveur lance un endpoint HTTP compatible avec l’API OpenAI :

vllm serve mistralai/Mistral-Nemo-Instruct-2407 \
    --tokenizer_mode mistral \
    --config_format mistral \
    --load_format mistral \
    --host 0.0.0.0 \
    --port 8000

Le serveur expose l’API sur le port 8000. La conséquence pratique est considérable : une application écrite pour l’API OpenAI bascule sur votre modèle auto-hébergé en changeant deux lignes, base_url et api_key. Vos bibliothèques, vos frameworks d’agents et vos outils de test continuent de fonctionner.

from openai import OpenAI

# Se connecter au serveur vLLM local
client = OpenAI(
    base_url="http://localhost:8000/v1",
    api_key="not-needed"  # Pas d'auth par défaut
)

response = client.chat.completions.create(
    model="mistralai/Mistral-Nemo-Instruct-2407",
    messages=[
        {"role": "system", "content": "Vous êtes un expert DevOps."},
        {"role": "user", "content": "Comment monitorer un serveur vLLM en production ?"}
    ],
    temperature=0.3,
    max_tokens=1024
)
print(response.choices[0].message.content)

Le commentaire # Pas d'auth par défaut mérite qu’on s’y arrête : un serveur vLLM lancé tel quel n’authentifie personne. Sur un poste de développement, c’est confortable. Sur une machine accessible depuis le réseau, c’est une porte ouverte. Un test rapide en ligne de commande confirme que tout répond avant de passer à la suite :

curl http://localhost:8000/v1/chat/completions \
    -H "Content-Type: application/json" \
    -d '{
        "model": "mistralai/Mistral-Nemo-Instruct-2407",
        "messages": [{"role": "user", "content": "Bonjour, ça fonctionne ?"}],
        "temperature": 0.3
    }'

Déploiement Docker

Pour un déploiement reproductible, l’image officielle évite de rejouer l’installation sur chaque machine :

docker run --runtime nvidia --gpus all \
    -v ~/.cache/huggingface:/root/.cache/huggingface \
    --env "HUGGING_FACE_HUB_TOKEN=${HF_TOKEN}" \
    -p 8000:8000 \
    --ipc=host \
    vllm/vllm-openai:latest \
    --model mistralai/Mistral-Nemo-Instruct-2407 \
    --tokenizer_mode mistral \
    --load_format mistral \
    --config_format mistral

Trois options de cette commande méritent une explication. --runtime nvidia --gpus all donne au conteneur l’accès aux GPU NVIDIA, sans quoi le modèle tenterait de tourner sur CPU. Le montage -v ~/.cache/huggingface:... partage le cache des modèles avec l’hôte et vous évite de retélécharger plusieurs dizaines de gigaoctets à chaque redémarrage du conteneur. --ipc=host accorde la mémoire partagée nécessaire à la communication inter-processus entre GPU ; son absence provoque des plantages difficiles à interpréter dès que vous passez à plusieurs cartes.

Les trois flags Mistral essentiels

Sans ces flags, le modèle peut fonctionner mais avec des performances dégradées ou des résultats incorrects. C’est le piège le plus courant du self-hosting Mistral : rien ne plante, le serveur démarre, les réponses arrivent — elles sont simplement moins bonnes qu’elles ne devraient l’être, et vous risquez d’en conclure à tort que le modèle est décevant.

Ajuster les performances

Quand un modèle ne tient pas sur une seule carte, le tensor parallelism répartit ses couches sur plusieurs GPU. La valeur passée correspond au nombre de cartes utilisées :

vllm serve mistralai/Mixtral-8X7B-Instruct-v0.1 \
    --tokenizer_mode mistral \
    --config_format mistral \
    --load_format mistral \
    --tensor-parallel-size 2

Le second levier concerne la proportion de mémoire GPU que vLLM se réserve :

vllm serve mistralai/Mistral-Nemo-Instruct-2407 \
    --tokenizer_mode mistral \
    --config_format mistral \
    --load_format mistral \
    --gpu-memory-utilization 0.9

La valeur par défaut (0.9) convient dans la plupart des cas. Réduisez-la si d’autres processus utilisent le GPU — un service de vision, un notebook oublié — faute de quoi le premier arrivé prendra toute la mémoire et le second échouera au démarrage.

Deux appels suffisent enfin à vérifier qu’un serveur est bien en vie, ce qui en fait de bonnes sondes pour votre orchestrateur :

# Lister les modèles disponibles
curl http://localhost:8000/v1/models

# Vérifier la santé du serveur
curl http://localhost:8000/health

Points clés à retenir

• vLLM expose une API compatible OpenAI — vous pouvez utiliser le SDK openai pour communiquer
• Les trois flags --tokenizer_mode mistral, --config_format mistral, --load_format mistral sont obligatoires
• Le mode offline est adapté au batch processing, le mode serveur aux applications temps réel
• Docker simplifie le déploiement et garantit la reproductibilité
• Le tensor parallelism permet de distribuer les gros modèles sur plusieurs GPU