Réponse directe
Si vous déployez un LLM local pour une équipe (Suisse, France, Belgique, Québec), la contrainte n°1 est la VRAM (poids + KV cache), puis la latence perçue. En pratique, un bon point de départ est un modèle 7–14B quantisé sur une machine 24GB VRAM pour des assistants internes, puis un routing vers des modèles plus gros (multi-GPU) pour les requêtes complexes.
1. Contexte & objectifs
Le “LLM local / on-prem” revient de plus en plus souvent dès qu'il y a des contraintes de confidentialité (données sensibles), de souveraineté, ou de maîtrise des coûts. Mais beaucoup de projets échouent par mauvais dimensionnement : le modèle “rentre” en VRAM, mais la latence explose dès que le contexte s'allonge, ou dès qu'il y a plusieurs utilisateurs simultanés.
Ce benchmark fournit :
- Une méthodologie reproductible (ce que vous devez mesurer et pourquoi).
- Des règles de dimensionnement VRAM (poids + KV cache).
- Une matrice de recommandation modèle × hardware × usage.
2. Méthodologie de benchmark
Un benchmark utile en entreprise ne se limite pas à un score académique. Les critères qui comptent :
- Latence (TTFT) : temps avant le premier token (perception utilisateur).
- Débit : tokens/seconde pendant la génération (productivité).
- VRAM : poids du modèle + KV cache (contexte & concurrence).
- Coût total : hardware, énergie, ops, MLOps, maintenance.
- Qualité utile : réponses correctes sur vos tâches (et pas “sur un benchmark”).
Protocole minimal (recommandé)
- 3 tailles de prompts : court (≤512 tokens), moyen (~2k), long (8k+).
- 3 modes : chat simple, chat + RAG, extraction structurée (JSON).
- Concurrence : 1, 5, 20 sessions selon usage.
- Mesures : TTFT, tokens/s, VRAM, CPU/GPU utilization, p95 latence.
3. Dimensionnement VRAM (poids + KV cache)
Pour décider vite, il faut séparer :
- Poids du modèle : dépend du nombre de paramètres et de la quantization.
- KV cache : dépend de la longueur de contexte, du nombre de couches et de la précision du cache.
# Règle simple (ordre de grandeur) # 1) Poids du modèle VRAM_weights_GB ≈ (params_in_billions * bits_per_weight) / 8 # 2) Surcoûts (runtime, buffers, fragmentation) VRAM_overhead_GB ≈ 10% à 30% (selon moteur + batch + features) # 3) KV cache # Dépend du contexte, du batch et de l'implémentation. # En pratique : plus votre contexte et vos utilisateurs augmentent, # plus le KV cache devient le facteur limitant.
Tableau (estimations VRAM poids uniquement)
Ordre de grandeur des poids en VRAM (hors KV cache et overhead). Les chiffres varient selon le format exact (GGUF, AWQ, GPTQ) et le runtime.
| Modèle (taille) | FP16 | INT8 | Q4 | Notes |
|---|---|---|---|---|
| 7B | ~14 GB | ~7 GB | ~3.5–4.5 GB | Très bon “sweet spot” pour assistants internes + RAG. |
| 14B | ~28 GB | ~14 GB | ~7–9 GB | Bon compromis qualité/coût, surtout avec un bon prompt et un RAG. |
| 32B | ~64 GB | ~32 GB | ~16–20 GB | Possible sur 24GB (Q4) avec contraintes sur contexte/concurrence. |
| 70B | ~140 GB | ~70 GB | ~35–45 GB | Généralement multi-GPU ou GPU 48GB+. |
4. Modèles & quantization (2025)
En entreprise, les familles suivantes sont souvent pertinentes (compatibilité outillage, performances, licences, communauté) :
- Llama 3.1 (8B, 70B) : base solide, bon écosystème.
- Mistral (7B, Mixtral) : bon compromis perf/coût, variantes MoE.
- Qwen 2.5 (7B, 14B, 32B) : très bon en raisonnement et multilingue selon les cas.
- Gemma 2 (9B, 27B) : intéressant en performance/qualité.
- Phi (petits modèles) : utile pour certaines tâches (classification/extraction) mais pas universel.
Quantization : comment choisir ?
La quantization réduit la VRAM et peut améliorer le débit, au prix d'une baisse de qualité. En pratique :
- Q4 : souvent suffisant pour assistants + RAG, surtout si vous gardez les prompts courts et que vous soignez la retrieval.
- INT8 : bon compromis pour certains runtimes (et certaines cartes).
- FP16 : réservé aux gros GPU / multi-GPU / exigences qualité maximales.
5. Stack d'inférence (local)
Le choix du moteur change autant la perf que le modèle :
| Moteur | Points forts | À privilégier quand… |
|---|---|---|
llama.cpp (GGUF) |
Portabilité, CPU/Apple Silicon, simplicité | Vous voulez un POC rapide et robuste, y compris sans GPU. |
vLLM |
Très bon débit, batching, prod | Vous avez de la concurrence et un besoin API type OpenAI-compatible. |
| TGI (Text Generation Inference) | Écosystème, prod, observabilité | Vous standardisez l'inférence et le monitoring. |
6. Matrice de choix (recommandations)
Ci-dessous une matrice de décision pragmatique (à adapter selon votre contexte, vos langues et votre RAG).
| Objectif | Modèle conseillé | Quantization | Hardware | Remarques |
|---|---|---|---|---|
| Assistant interne (Q/R) + RAG | 7B–14B | Q4 / INT8 | 1× GPU 24GB | Très bon ROI. Optimiser la retrieval avant d'augmenter la taille du modèle. |
| Rédaction & synthèse longue | 14B–32B | INT8 / Q4 | 24GB (limites) ou 48GB | Attention KV cache : le contexte long coûte cher. |
| Cas complexes / raisonnement | 32B–70B | Q4 / FP16 | Multi-GPU | Souvent rentable avec routing (petit modèle par défaut, gros modèle à la demande). |
| Extraction structurée (JSON) | 7B–14B | Q4 | CPU ou GPU 24GB | Privilégier prompts stricts + validation + retries. |
7. Pièges & checklists
Pièges fréquents
- Contexte trop long : le KV cache explose et la latence devient imprévisible.
- RAG non évalué : on blâme le LLM alors que la retrieval est la vraie cause.
- Pas de limites : pas de quotas, pas de rate limiting, pas de timeouts.
- Pas d'observabilité : impossible d'optimiser TTFT, tokens/s, coûts.
Checklist déploiement “propre”
- Définir SLA : p95 latence, disponibilité, volume.
- Limiter le contexte : résumés, chunking, citations.
- Mettre en place logs & traces : prompt, tokens, coût GPU.
- Tester sécurité : injection, exfiltration, data leakage.