Mistral – ⚙️ Optimisations & Efficacité
Sparse/Sliding Attention · Quantization 4/8-bit · Pruning & Distillation · Parallelism (Tensor/Pipeline). Modales ultra-densifiées : schémas, tableaux, KPIs, checklists Dev/Ops & snippets.
Throughput & latence Empreinte VRAM Coûts / 1k tokens
Glossaire express
- Sparse attention : masque parcimonieux (blocs, bandes, dilatations).
- Sliding window : attention locale taille w ≪ T.
- KV cache : mémo K,V pour génération rapide (stream).
- GPTQ/AWQ : quantization poids (post-training).
- QLoRA : FT 4-bit avec adapters LoRA.
- Pruning : suppression neurones/canaux/heads.
- Distillation : élève imite prof (logits/séquences).
- TP/PP : tensor/pipeline parallel, DP/ZeRO pour mémoire.
- Activation checkpoint : recompute fwd pour mémoire↓.
- Offload : déporter poids/optims (CPU/NVMe).
Sparse Attention / Fenêtres glissantes — réduire O(T²)
Idée générale
- Remplacer l’attention dense par des modèles parcimonieux : bandes, blocs, dilatations.
- Sliding window (w) : chaque token ne regarde qu’une fenêtre récente.
- Complexité réduite : O(T·w) en temps et mémoire vs O(T²).
Schéma (ASCII)
DENSE (T×T) SLIDING (T×w)
████████████ ░░░░░███
████████████ → ░░░░████
████████████ ░░░█████
... ...███░░
Quand l’activer ?
- Longs prompts ou streaming (chat, log analysis, RAG volumineux).
- GPU mémoire limitée, batchs dynamiques (serveur multi-tenants).
- Documents avec dépendances essentiellement locales.
Comparatif rapide
| Type | Complexité | Qualité | Notes |
|---|---|---|---|
| Dense | O(T²) | ⭐⭐⭐⭐⭐ | Référence |
| Fenêtre (w) | O(T·w) | ⭐⭐⭐–⭐⭐⭐⭐ | Choisir w selon tâche |
| Bandes/Blocs | ~O(T·√T) | ⭐⭐⭐⭐ | Bon pour textes structurés |
Anti-patterns
- w trop petit → pertes de dépendances longues (raisonnement).
- Masques incohérents entre Q/K → artefacts.
- Ne pas réévaluer les prompts long-range critiques après switch.
Tip : pour RAG, combiner retrieval hiérarchique + fenêtres glissantes : garder w modéré (512–1024) et injecter les passages pertinents.
Quantization — 8-bit / 4-bit (déploiement allégé)
Objectif
- Réduire VRAM et latence en passant FP16/BF16 → INT8/INT4.
- Deux familles : PTQ (post-training quantization) vs QAT (quantization aware training).
- Pour FT : QLoRA (4-bit + LoRA) = sweet spot VRAM/qualité.
VRAM ↓ x2 (INT8), x3–x4 (INT4)
Tableau (indicatif)
| Schéma | Qualité | VRAM | Usage |
|---|---|---|---|
| FP16/BF16 | ⭐⭐⭐⭐⭐ | 100% | Référence, FT pleine |
| INT8 (LLM.int8) | ⭐⭐⭐⭐ | ~50–60% | Prod générique |
| INT4 (GPTQ/AWQ) | ⭐⭐⭐–⭐⭐⭐⭐ | ~25–35% | Edge/latence |
| QLoRA 4-bit | ⭐⭐⭐⭐ | ~30–40% | FT mémoire réduite |
Pièges & bonnes pratiques
- Évaluer sur ton golden set (pas seulement perplexity).
- Éviter INT4 agressif sur tâches de calcul/raisonnement précis.
- Layer-wise quantization + calibration set diversifié.
- Valider la stabilité sampling (temp/top-p) post-quantization.
Snippets
# bitsandbytes (8-bit load)
model = AutoModelForCausalLM.from_pretrained(
"mistralai/Mistral-7B-v0.2",
load_in_8bit=True, device_map="auto"
)# QLoRA (schéma)
peft = LoraConfig(r=64, lora_alpha=16, target_modules=["q_proj","v_proj"])Ops/Prod
- Mesurer p50/p95, tokens/s, coût/1k tokens, qualité (exact-match).
- Conserver FP16 de référence pour A/B & rollback.
- Sur vLLM/TGI : choisir build supportant int8/4bit + paged KV cache.
Tip : INT8 pour back-office stable; INT4 pour edge & forte contrainte VRAM — en gardant un canary FP16.
Pruning & Distillation — modèles plus compacts
Pruning (coupes)
- Unstructured (magnitude) : zéros dispersés → exige kernels sparsity.
- Structured : couper têtes, canaux, MLP dims → accélération plus simple.
- Critères : importance (magnitudes), sensibilité (Hessian), impact qualité.
Distillation (prof → élève)
- Pertes : KD (logits soft), SeqKD (séquences), DPO/ORPO (préférences).
- Obj : rapprocher l’élève sur tâches cibles avec moins de params.
- Datasets : mélange réel + synthétique (auto-généré par prof).
Tableau pratique
| Méthode | Gain latence | Qualité | Complexité |
|---|---|---|---|
| Pruning structuré | ⭐⭐⭐ | ⭐⭐⭐–⭐⭐⭐⭐ | ⭐⭐ |
| Pruning non structuré | ⭐–⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐ (kernels) |
| Distillation KD | ⭐⭐⭐ | ⭐⭐⭐–⭐⭐⭐⭐ | ⭐⭐ |
| Distillation DPO/ORPO | ⭐⭐ | ⭐⭐⭐⭐ (alignement) | ⭐⭐⭐ |
Formules (intuition)
# KD (Kullback-Leibler entre élève et prof)
L_KD = τ^2 * KL( softmax(z_s/τ) || softmax(z_t/τ) )
# Pruning magnitude (seuil λ)
W_pruned = W * (|W| ≥ λ)Anti-patterns & Ops
- Pruning agressif sans ré-entrainement → chute brutale.
- Élève trop petit pour la tâche (contexte/raisonnement).
- Ne pas versionner (prof/datasets/pertes) → non-reproductible.
- KPIs : exact-match, groundedness, latence p95/p99, coûts.
Tip : pipeline “prune → FT court → éval” en boucle, jusqu’à atteindre le ratio cible sans casser tes métriques métier.
Parallelism — tensor/pipeline, ZeRO & communication
Stratégies
- TP : divise matrices d’une même couche entre GPUs (all-reduce).
- PP : sépare blocs de couches en “stages” (bubbles à gérer).
- DP/ZeRO : sharde poids/grads/optim (économie mémoire).
- Activation checkpoint : recompute fwd → mémoire↓.
Tableau de choix
| Contrainte | Préférence | Notes |
|---|---|---|
| VRAM par GPU faible | PP + ZeRO + checkpoint | Stages plus nombreux |
| Interconnect rapide (NVLink) | TP | All-reduce rapide |
| Beaucoup de GPUs | Hybride TP+PP | Équilibrage fin |
Bonnes pratiques
- Équilibrer la charge entre stages PP (latence la + lente = goulot).
- Minimiser communications (fusion, bucketisation).
- Profiler : p50/p95, utilisation GPU, % temps en comms.
Exemple (vLLM serveur)
python -m vllm.entrypoints.openai.api_server \
--model mistralai/Mixtral-8x7B-Instruct-v0.1 \
--tensor-parallel-size 2 --max-model-len 32768Ops/Prod
- Autoscaling par QPS & jetons/s, warm pools (scale-to-zero hors pics).
- Logs: tokens, latence p95/p99, coûts, erreurs/refus.
- Tests charge : profils “long-context” vs “short-burst”.
Tip : viser une occupation GPU > 70% avec latence p95 sous SLA; ajuster batch size, max_new_tokens, TP/PP et checkpointing.
