Comment configurer Mistral Medium 3.5 en local avec vLLM pour la production en 7 etapes

Avec la sortie de Mistral Medium 3.5 le 2 mai 2026, le self-hosting d un modele de code frontier est devenu une realite pour les equipes francaises. Le modele atteint 77.6% SWE-Bench Verified, les poids sont disponibles sur Hugging Face sous licence MIT modifiee, et vLLM supporte nativement l architecture depuis la version 0.8.2. Mais deployer un modele dense de 128 milliards de parametres en production n est pas trivial. Ce guide couvre les 7 etapes necessaires, du sizing hardware jusqu a l integration CI/CD, calibrees pour un deploiement production sur infrastructure souveraine francaise.

Pourquoi self-hoster plutot qu utiliser l API Mistral ? Trois raisons. Une, la conformite : les donnees de code ne quittent jamais votre infrastructure, ce qui simplifie drastiquement la conformite NIS2 et RGPD. Deux, le cout a l echelle : au-dela de 40-60 developpeurs actifs, le self-hosting est moins cher que l API. Trois, la latence : un serveur colocate en France offre des latences de 50-100 ms versus 150-300 ms pour une API distante, ce qui change l experience dans un IDE. Pour le contexte sur la release du modele, voir notre analyse complete de Mistral Medium 3.5 et Remote Agents Vibe.

Etape 1 : Sizing hardware et choix du fournisseur cloud

Mistral Medium 3.5 est un modele dense de 128B parametres. Chaque parametre en FP16 occupe 2 octets, soit environ 256 Go de VRAM pour les poids seuls. Ajoutez 20 a 30% pour le KV cache et les activations lors de l inference avec batching, et vous arrivez a 300-330 Go de VRAM en FP16. En pratique, cela impose un minimum de 4x A100 80 Go ou 2x H100 80 Go avec tensor parallelism configure dans vLLM.

La configuration recommandee pour la production est la GPTQ-INT4. Le modele quantifie occupe environ 70 Go de VRAM, soit 1x H100 80 Go avec marge pour le KV cache. La degradation de qualite est minimale : on observe typiquement 0.5 a 1.5 points de perte sur SWE-Bench (76-77% au lieu de 77.6%), ce qui reste largement superieur a GPT-4o et Claude Sonnet.

Pour les fournisseurs cloud francais, deux options principales en mai 2026 : OVHcloud (instances GPU H100 a partir de 3.50 EUR/h en reserved) et Scaleway (instances L40S ou H100 a partir de 3.20 EUR/h). Pour les equipes qui privilegient la latence minimale, la colocation d un serveur dediee chez un hebergeur francais (Equinix Paris, Interxion) avec des GPU achetes coute environ 60 000-80 000 EUR a l achat, amorti sur 3 ans.

# Verifier la VRAM disponible
nvidia-smi --query-gpu=name,memory.total,memory.free --format=csv

# Resultat attendu pour 2x H100 :
# NVIDIA H100 80GB HBM3, 81920 MiB, 81200 MiB
# NVIDIA H100 80GB HBM3, 81920 MiB, 81200 MiB

# Verifier NVLink / NVSwitch (requis pour tensor parallelism)
nvidia-smi topo -m

Etape 2 : Installer vLLM et les dependencies

vLLM est le moteur d inference de reference pour les modeles LLM en production. La version 0.8.2+ supporte nativement l architecture Mistral Medium 3.5 avec PagedAttention v2, continuous batching, et tensor parallelism multi-GPU. L installation se fait dans un environnement Python 3.10+ avec CUDA 12.x.

# Creer un environnement dedie
python3.10 -m venv /opt/vllm-mistral
source /opt/vllm-mistral/bin/activate

# Installer vLLM avec support CUDA 12.4
pip install vllm==0.8.4 --extra-index-url https://download.pytorch.org/whl/cu124

# Installer les dependencies pour quantification GPTQ
pip install auto-gptq optimum

# Verifier l installation
python -c "import vllm; print(vllm.__version__)"
# Output attendu: 0.8.4

# Telecharger le modele quantifie (recommande pour production)
huggingface-cli download mistralai/Mistral-Medium-3.5-GPTQ-INT4 \
  --local-dir /models/mistral-medium-3.5-int4 \
  --revision main

Le telechargement du modele quantifie INT4 prend environ 45 minutes sur une connexion 1 Gbps (environ 65 Go). Pour le modele FP16 complet, comptez 2-3 heures (environ 256 Go). Astuce : utilisez aria2 ou hf_transfer pour paralleliser le telechargement et gagner 2-3x en vitesse.

Etape 3 : Configurer la quantification GPTQ-INT4

Si vous avez telecharge le modele pre-quantifie par Mistral (Mistral-Medium-3.5-GPTQ-INT4), cette etape est deja faite. Sinon, si vous partez du modele FP16 et souhaitez quantifier vous-meme (par exemple pour une quantification AWQ customisee), voici la procedure :

# Option A : Utiliser le modele pre-quantifie (recommande)
# Deja telecharge a l etape 2

# Option B : Quantification AWQ custom
pip install autoawq
python -c "
from awq import AutoAWQForCausalLM
from transformers import AutoTokenizer

model_path = '/models/mistral-medium-3.5-fp16'
quant_path = '/models/mistral-medium-3.5-awq-int4'

model = AutoAWQForCausalLM.from_pretrained(model_path)
tokenizer = AutoTokenizer.from_pretrained(model_path)

quant_config = {
    'zero_point': True,
    'q_group_size': 128,
    'w_bit': 4,
    'version': 'GEMM'
}

model.quantize(tokenizer, quant_config=quant_config)
model.save_quantized(quant_path)
tokenizer.save_pretrained(quant_path)
print('Quantification terminee')
"

# La quantification prend 2-4 heures sur 4x A100

Conseil important : validez toujours la qualite du modele quantifie avant de le deployer en production. Executez un petit benchmark local sur 50-100 taches de codage representatives de votre workload et comparez avec le modele FP16 ou l API Mistral. Une degradation superieure a 2 points sur votre benchmark interne justifie de rester en FP16 ou d essayer une autre methode de quantification.

Etape 4 : Lancer le serveur vLLM en production

Voici la configuration vLLM optimisee pour la production avec Mistral Medium 3.5 en INT4 sur 1x H100. Les parametres cles sont le --max-model-len (fenetre de contexte effective), le --gpu-memory-utilization (pourcentage VRAM alloue), et le --max-num-seqs (requetes concurrentes max).

# Configuration production vLLM — Mistral Medium 3.5 INT4
# Fichier: /etc/vllm/serve.sh

#!/bin/bash
source /opt/vllm-mistral/bin/activate

vllm serve /models/mistral-medium-3.5-int4 \
  --host 0.0.0.0 \
  --port 8000 \
  --tensor-parallel-size 1 \
  --max-model-len 32768 \
  --gpu-memory-utilization 0.90 \
  --max-num-seqs 12 \
  --enable-prefix-caching \
  --quantization gptq \
  --dtype half \
  --api-key "${VLLM_API_KEY}" \
  --served-model-name "mistral-medium-3.5" \
  --trust-remote-code \
  --disable-log-requests

# Pour multi-GPU FP16 (2x H100), changer :
# --tensor-parallel-size 2
# --max-model-len 65536
# --max-num-seqs 16
# Retirer: --quantization gptq

Creez un service systemd pour le demarrage automatique et la gestion des crashes :

# /etc/systemd/system/vllm-mistral.service
[Unit]
Description=vLLM Mistral Medium 3.5
After=network.target nvidia-persistenced.service

[Service]
Type=simple
User=vllm
Group=vllm
ExecStart=/etc/vllm/serve.sh
Restart=on-failure
RestartSec=30
Environment="VLLM_API_KEY=sk-votre-cle-secrete"
Environment="CUDA_VISIBLE_DEVICES=0"
LimitNOFILE=65536

[Install]
WantedBy=multi-user.target

# Activer et demarrer
# systemctl enable vllm-mistral && systemctl start vllm-mistral

Le serveur vLLM demarre en environ 3-5 minutes (chargement du modele en VRAM). Verifiez que tout fonctionne avec un test rapide :

curl -s http://localhost:8000/v1/chat/completions \
  -H "Authorization: Bearer sk-votre-cle-secrete" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "mistral-medium-3.5",
    "messages": [{"role": "user", "content": "Ecris une fonction Python qui trie un dictionnaire par valeur."}],
    "max_tokens": 512,
    "temperature": 0.1
  }' | python -m json.tool

Etape 5 : Reverse proxy et securite reseau

Ne jamais exposer le serveur vLLM directement sur Internet. Placez un reverse proxy devant (Caddy, Nginx, ou Traefik) qui gere le TLS, le rate limiting, et l authentification. Caddy est recommande pour sa simplicite de configuration et son renouvellement automatique de certificats Let s Encrypt.

# /etc/caddy/Caddyfile
llm.votre-domaine.fr {
    reverse_proxy localhost:8000 {
        # Health check
        health_uri /health
        health_interval 30s
        health_timeout 10s
    }

    # Rate limiting: 60 requetes/min par IP
    rate_limit {
        zone dynamic_zone {
            key {remote_host}
            events 60
            window 1m
        }
    }

    # Headers securite
    header {
        Strict-Transport-Security "max-age=31536000; includeSubDomains"
        X-Content-Type-Options "nosniff"
        X-Frame-Options "DENY"
    }

    # Logs pour audit NIS2
    log {
        output file /var/log/caddy/llm-access.log {
            roll_size 100MiB
            roll_keep 30
        }
    }
}

Configurez egalement un firewall qui n autorise que le trafic entrant sur les ports 443 (HTTPS) et 22 (SSH) depuis vos IPs connues. Le serveur vLLM ecoute sur localhost:8000 et n est accessible qu a travers le reverse proxy. Pour les equipes qui utilisent un VPN WireGuard, limitez l acces au endpoint LLM aux IPs du tunnel VPN uniquement.

Etape 6 : Monitoring et alerting avec Prometheus + Grafana

vLLM expose nativement des metriques Prometheus sur /metrics. Les metriques critiques a surveiller en production sont : vllm:num_requests_running (requetes en cours), vllm:gpu_cache_usage_perc (utilisation du KV cache), vllm:e2e_request_latency_seconds (latence bout en bout), et vllm:avg_generation_throughput_toks_per_s (debit en tokens/s).

# prometheus.yml — scrape config pour vLLM
scrape_configs:
  - job_name: 'vllm-mistral'
    scrape_interval: 15s
    static_configs:
      - targets: ['localhost:8000']
    metrics_path: /metrics

# Alertes critiques (alertmanager rules)
groups:
  - name: vllm-alerts
    rules:
      - alert: VLLMHighLatency
        expr: histogram_quantile(0.95, vllm:e2e_request_latency_seconds_bucket) > 5
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "Latence P95 vLLM > 5s"

      - alert: VLLMGPUCacheFulle
        expr: vllm:gpu_cache_usage_perc > 0.95
        for: 2m
        labels:
          severity: critical
        annotations:
          summary: "KV cache GPU > 95% — risque OOM"

      - alert: VLLMDown
        expr: up{job="vllm-mistral"} == 0
        for: 1m
        labels:
          severity: critical
        annotations:
          summary: "Serveur vLLM Mistral down"

Importez le dashboard Grafana vLLM (ID 19927 dans la galerie Grafana) pour une vue complete : requetes en cours, latence P50/P95/P99, debit tokens/s, utilisation GPU et VRAM, erreurs HTTP. Ajoutez nvidia-smi-exporter pour les metriques GPU hardware (temperature, puissance, utilisation compute). Pour un guide plus large sur l observabilite en production, voir notre article sur la configuration OpenTelemetry.

Etape 7 : Integration CI/CD et utilisation quotidienne

Le serveur vLLM expose une API compatible OpenAI (/v1/chat/completions). Cela signifie que tous les outils qui supportent l API OpenAI fonctionnent directement : Continue.dev, Cody, aider, Cursor (avec custom API endpoint), et les scripts Python avec la librairie openai. Il suffit de pointer l endpoint vers votre serveur.

# .env pour vos outils de dev
OPENAI_API_BASE=https://llm.votre-domaine.fr/v1
OPENAI_API_KEY=sk-votre-cle-secrete

# Exemple : code review automatisee dans GitHub Actions
# .github/workflows/code-review.yml
name: Code Review Mistral
on: [pull_request]
jobs:
  review:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v5
      - name: Review avec Mistral Medium 3.5
        env:
          OPENAI_API_BASE: ${{ secrets.MISTRAL_ENDPOINT }}
          OPENAI_API_KEY: ${{ secrets.MISTRAL_API_KEY }}
        run: |
          pip install openai
          python scripts/code-review.py \
            --model mistral-medium-3.5 \
            --diff "$(git diff origin/main...HEAD)" \
            --output review-comments.json

Pour l integration IDE, configurez Continue.dev (VS Code / JetBrains) avec votre endpoint self-hosted :

// ~/.continue/config.json
{
  "models": [{
    "title": "Mistral Medium 3.5 (self-hosted)",
    "provider": "openai",
    "model": "mistral-medium-3.5",
    "apiBase": "https://llm.votre-domaine.fr/v1",
    "apiKey": "sk-votre-cle-secrete"
  }],
  "tabAutocompleteModel": {
    "title": "Mistral Medium 3.5",
    "provider": "openai",
    "model": "mistral-medium-3.5",
    "apiBase": "https://llm.votre-domaine.fr/v1",
    "apiKey": "sk-votre-cle-secrete"
  }
}

Avec cette configuration, vos developpeurs beneficient de l autocomplete, du chat inline, et de la generation de code avec Mistral Medium 3.5 directement dans leur IDE, sans qu une seule ligne de code ne quitte votre infrastructure. Pour les equipes qui utilisent deja LiteLLM comme proxy unifie, ajoutez simplement le endpoint vLLM comme nouveau backend dans la configuration LiteLLM.

Bonnes pratiques pour la production

Apres plusieurs deploiements de modeles LLM en production, voici les 5 regles que nous appliquons systematiquement :

1. Rotation des cles API. Generez une cle API unique par equipe/service et configurez une rotation tous les 90 jours. vLLM supporte plusieurs cles API simultanement via un fichier de configuration. Tracez chaque requete avec un header X-Team-ID pour l audit.

2. Backup et rollback. Gardez toujours la version N-1 du modele sur le disque. En cas de regression apres une mise a jour, le rollback prend 3-5 minutes (redemarrage vLLM avec le chemin du modele precedent). Automatisez ce processus dans un script rollback.sh.

3. Benchmark continu. Executez un benchmark automatise quotidien (50 taches de codage) et alertez si le score degrade de plus de 2 points. Cela detecte les corruptions de modele, les regressions de config, et les problemes hardware (GPU throttling thermique).

4. Haute disponibilite. Pour les equipes 50+ developpeurs, deployer 2 instances vLLM derriere un load balancer avec health checks. Le cout double, mais l indisponibilite d un outil de code assist impacte directement la productivite de toute l equipe.

5. Conformite NIS2. Documentez l architecture dans un registre de traitement, loguez toutes les requetes (sans le contenu sensible), et configurez une retention de logs de 12 mois minimum. Le reverse proxy Caddy avec les access logs structures couvre l essentiel. Pour les enjeux de conformite plus larges, consultez notre guide NIS2 conformite PME open source.

FAQ