Héberger et opérer un modèle Mistral open-weight : le guide pratique

Mistral AI a publié l'ensemble de ses modèles en open-weight. Ça signifie que vous pouvez les télécharger, les héberger sur votre infrastructure, et faire circuler vos données sans qu'elles quittent votre périmètre. C'est l'argument de souveraineté central. Mais héberger un LLM en production n'est pas anodin. Ce guide couvre les décisions pratiques, dans l'ordre où vous les prendrez.

01 / Dimensionner son GPU : la règle simple

La règle de départ est brutale dans sa simplicité : VRAM nécessaire ≈ nombre de paramètres × bytes par paramètre. Un modèle 7B en float16 (2 bytes par paramètre) nécessite environ 14 Go de VRAM pour le modèle seul — sans compter le KV cache, les activations et les buffers d'inférence qui s'y ajoutent en production.

La quantification réduit ce coût. En int8 (1 byte), on divise par 2. En int4 (~0.5 byte), on divise par 4, avec une légère dégradation de qualité. Le tableau ci-dessous donne les chiffres pour les trois modèles Mistral open-weight principaux.

Pour la VRAM disponible sur les clouds principaux : une A100 80 Go (AWS p4d) coûte environ 3,50 $/h. Une A10G 24 Go (AWS g5) environ 1,05 $/h. Pour du multi-GPU, le tensor parallelism de vLLM vous permet de distribuer un modèle sur plusieurs cartes — un Mistral 123B en fp16 tiendra sur 4× A100 80 Go avec --tensor-parallel-size 4.

02 / Choisir son moteur de serving

Il existe trois moteurs sérieux pour héberger Mistral en production. Le choix dépend de votre cas d'usage — pas de vos préférences esthétiques.

vLLM — le standard production

vLLM est la référence pour les déploiements multi-utilisateurs en production. Son innovation centrale est le PagedAttention : une gestion du KV cache inspirée de la pagination mémoire des OS, qui élimine la fragmentation et permet un batching continu (continuous batching). Résultat : un throughput 2 à 10× supérieur aux implémentations naïves. L'API est compatible OpenAI — tous vos clients qui appellent GPT-4 peuvent pointer vers vLLM sans modification.

SGLang — pour les agents et les sorties structurées

SGLang excelle sur les workloads agentiques et les requêtes structurées (JSON mode, grammaires contraintes). Son RadixAttention permet un cache de préfixe efficace — particulièrement utile quand beaucoup de requêtes partagent le même prompt système. Sur les benchmarks de génération structurée, SGLang dépasse vLLM de 20 à 40%.

llama.cpp / Ollama — développement et CPU

llama.cpp est optimisé pour CPU et GPU grand public. Avec Ollama qui l'encapsule dans une interface conviviale, c'est la solution idéale pour le développement local et les déploiements sur machines sans GPU datacenter. Les performances en production multi-utilisateurs ne soutiennent pas la comparaison avec vLLM, mais pour un poste de développeur ou un usage mono-utilisateur, c'est parfait.

03 / Lancer vLLM en production

vLLM expose une API REST compatible OpenAI. Une fois lancé, n'importe quel SDK OpenAI peut pointer dessus en changeant simplement le base_url. Voici la configuration minimale pour un déploiement production de Mistral 7B Instruct.

# Installation
pip install vllm

# Lancement — Mistral 7B Instruct en AWQ 4-bit, single GPU
python -m vllm.entrypoints.openai.api_server \
  --model mistralai/Mistral-7B-Instruct-v0.3 \
  --quantization awq \            # awq | gptq | fp8 | None
  --max-model-len 8192 \          # context window max
  --max-num-seqs 256 \            # requêtes simultanées max
  --gpu-memory-utilization 0.90 \ # % VRAM alloué à vLLM
  --host 0.0.0.0 \
  --port 8000 \
  --api-key ${VLLM_API_KEY}       # auth basique

# Multi-GPU (ex: Mistral 22B sur 2× A100)
python -m vllm.entrypoints.openai.api_server \
  --model mistralai/Mistral-Small-3.1-22B-Instruct-2503 \
  --tensor-parallel-size 2 \      # distribue le modèle sur 2 GPU
  --pipeline-parallel-size 1 \
  --max-model-len 32768 \
  --host 0.0.0.0 --port 8000

# Test rapide de l'API (compatible OpenAI)
curl http://localhost:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer ${VLLM_API_KEY}" \
  -d '{
    "model": "mistralai/Mistral-7B-Instruct-v0.3",
    "messages": [{"role": "user", "content": "Bonjour"}],
    "max_tokens": 256,
    "temperature": 0.7
  }'

version: '3.8'

services:
  vllm:
    image: vllm/vllm-openai:latest
    runtime: nvidia
    environment:
      - HUGGING_FACE_HUB_TOKEN=${HF_TOKEN}
      - VLLM_API_KEY=${VLLM_API_KEY}
    volumes:
      - ~/.cache/huggingface:/root/.cache/huggingface
    command: >
      --model mistralai/Mistral-7B-Instruct-v0.3
      --quantization awq
      --max-model-len 8192
      --gpu-memory-utilization 0.90
      --host 0.0.0.0 --port 8000
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: 1
              capabilities: [gpu]
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:8000/health"]
      interval: 30s
      timeout: 10s
      retries: 3

  nginx:
    image: nginx:alpine
    ports:
      - "443:443"
    volumes:
      - ./nginx.conf:/etc/nginx/nginx.conf:ro
      - ./ssl:/etc/ssl/certs:ro
    depends_on:
      vllm:
        condition: service_healthy

04 / Quantization : AWQ, GPTQ, GGUF

La quantization réduit la précision des poids du modèle pour économiser VRAM et accélérer l'inférence, au prix d'une légère dégradation de qualité. Il existe trois formats majeurs, chacun avec ses cas d'usage.

AWQ (Activation-aware Weight Quantization)

AWQ est le format recommandé pour la production GPU. Il quantize les poids en 4-bit en identifiant et préservant les poids les plus importants (ceux activés par les features saillantes). Résultat : meilleur rapport qualité/vitesse que GPTQ à précision équivalente. Compatible nativement avec vLLM et SGLang via --quantization awq.

GPTQ

GPTQ est le format le plus répandu sur HuggingFace. Large choix de modèles quantisés à différents niveaux (2-bit à 8-bit). Légèrement moins performant qu'AWQ en throughput, mais excellent pour les cas où un modèle GPTQ pré-quantisé est disponible et qu'on ne veut pas requantizer.

GGUF (llama.cpp)

GGUF est le format natif de llama.cpp et Ollama. Optimisé pour CPU et GPU grand public, il supporte des quantizations de 2 à 8 bits avec plusieurs niveaux de qualité intermédiaires (Q4_K_M, Q5_K_S, etc.). Excellent pour le développement local, inadapté à la production GPU haute performance.

Pour trouver les modèles Mistral pré-quantisés : cherchez bartowski sur HuggingFace (successeur de TheBloke pour les GGUF récents) pour GGUF, et solidrust ou TheBloke pour AWQ/GPTQ.

05 / Monitoring en production

Un LLM en production est une boîte noire si vous ne le monitorez pas. vLLM expose nativement un endpoint /metrics au format Prometheus. Branchez-y Grafana pour les métriques système, et Langfuse pour les traces LLM (inputs, outputs, latences, coûts, évaluations).

Les 4 KPI critiques

Latence P99 (Time To First Token, TTFT) : le temps que met le modèle à générer le premier token. Critique pour les interfaces utilisateur. Un P99 > 3s commence à être perceptible. Agissez sur la taille du batch ou la taille du modèle si ce chiffre dérive.

Throughput (tokens/s) : le débit de génération. Surveiller en tendance — une chute soudaine signale une surcharge, un changement de configuration, ou une régression après mise à jour.

GPU Utilization : entre 70% et 90%, c'est l'idéal. En dessous de 50%, vous surprovisionnez. Au-dessus de 95% en continu, vous risquez des timeout et des erreurs OOM (Out of Memory).

KV Cache Hit Rate : le pourcentage de requêtes qui bénéficient du cache de préfixe. Plus c'est élevé, moins de calcul redondant. Si vous avez beaucoup de requêtes avec le même prompt système, ce chiffre devrait être > 70%.

Outils recommandés

vLLM /metrics expose directement les métriques Prometheus : vllm:e2e_request_latency_seconds, vllm:gpu_cache_usage_perc, vllm:num_requests_running, etc. Un dashboard Grafana communautaire est disponible directement dans le repo vLLM.

Langfuse (open-source, auto-hébergeable) est le choix de référence pour les traces LLM. Il capture chaque requête avec son input, output, latence, et les éventuels coûts. Indispensable pour détecter les dérives de qualité, les prompts qui échouent, et les usages inattendus.