Matériel, VRAM et quantisation

Introduction

Avant de choisir un moteur d'inférenceinférenceIAUtilisation d'un modèle déjà entraîné sur une donnée nouvelle. Peu coûteuse à l'unité mais répétée à chaque requête, elle constitue le coût récurrent d'exploitation.Voir dans le glossaire ou un modèle, une question doit être tranchée : sur quel matériel va tourner le LLMLLMIAGrand modèle de langage (Large Language Model) entraîné sur d'énormes corpus pour prédire et générer du texte.Voir dans le glossaire, et avec combien de mémoire vidéo. Cette question est structurante : elle détermine quels modèles sont accessibles, quelle latence est atteignable, combien d'utilisateurs simultanés peuvent être servis, et quel budget matériel doit être engagé. Un projet qui commence par choisir le modèle avant de vérifier la VRAM disponible se condamne presque toujours à revoir ses choix en cours de route.

Ce chapitre pose les bases du dimensionnement matériel : la relation entre taille de modèle et mémoire, les formats de quantisation qui réduisent cette empreinte, et les grandes familles de configurations matérielles rencontrées en entreprise.

La VRAM disponible sur le GPUGPUIAProcesseur graphique parallélisant massivement les calculs matriciels ; indispensable à l'entraînement et à l'inférence des modèles de deep learning.Voir dans le glossaire est la contrainte dure de tout déploiement de LLMgrand modèle de langageIAModèle entraîné à prédire le token suivant d'une séquence de texte. Toutes ses capacités apparentes — résumer, traduire, coder — découlent de cette unique tâche.Voir dans le glossaire local. Un modèle qui ne tient pas en mémoire ne tourne pas, quelle que soit la puissance de calcul du GPU. Le dimensionnement mémoire précède donc toujours le choix du modèle, pas l'inverse.

VRAM et taille de modèle : la relation de base

Un LLM est un ensemble de paramètres (des poids numériques) organisés en couches. La taille d'un modèle s'exprime en nombre de paramètres : 7 milliards (7B), 13B, 34B, 70B, etc. Chaque paramètre doit être stocké en mémoire pour que le modèle puisse effectuer un calcul, et c'est cette mémoire de stockage des poids qui occupe l'essentiel de la VRAM.

La taille en octets d'un modèle dépend directement de deux facteurs : le nombre de paramètres et la précisionprécisionIAProportion des alertes émises par un modèle qui sont justifiées. Elle s'oppose au rappel : améliorer l'une dégrade l'autre.Voir dans le glossaire numérique utilisée pour les représenter. Un paramètre stocké en précision 16 bits (2 octets) occupe deux fois moins de place que le même paramètre stocké en 32 bits (4 octets), et deux fois plus qu'un paramètre stocké en 8 bits (1 octet).

À cette mémoire de base pour les poids s'ajoutent deux postes souvent sous-estimés :

• Le cache KV (clé-valeur) : pendant l'inférence, le modèle conserve en mémoire les représentations internes des tokenstokenIAFragment de texte manipulé par un modèle de langage, généralement plus court qu'un mot — trois à quatre caractères en français. La tarification et la limite de contexte se comptent en tokens.Voir dans le glossaire déjà traités, pour éviter de tout recalculer à chaque nouveau token. Ce cache grandit avec la longueur du contextefenêtre de contexteIAQuantité de texte qu'un modèle peut prendre en compte simultanément : question, documents fournis et historique. Au-delà, les éléments les plus anciens sortent du champ.Voir dans le glossaire et le nombre de requêtes traitées en parallèle.
• La mémoire d'activationfonction d'activationIAOpération non linéaire appliquée en sortie d'un neurone. Sans elle, empiler des couches serait inutile : une succession d'opérations linéaires reste équivalente à une seule.Voir dans le glossaire : les calculs intermédiaires effectués pendant le passage avant (forward pass) occupent également de la VRAM, en particulier avec des batchs de plusieurs requêtes simultanées.

En pratique, sur un usage conversationnel standard, le cache KV et les activations représentent souvent 10 à 30 % de VRAM supplémentaire par rapport au poids brut du modèle, davantage si le contexte est long ou si plusieurs utilisateurs sont servis en parallèle.

Un modèle « 7B » ne désigne pas une taille fixe en gigaoctets. Sa taille réelle en mémoire dépend entièrement de la précision choisie. C'est précisément ce que la quantisation exploite.

Les formats de précision : FP16, INT8, GPTQ, AWQ, GGUF

FP16 et BF16 : le point de départ

La plupart des modèles sont entraînés et publiés en FP16 (virgule flottante 16 bits) ou BF16 (variante avec un exposant plus large, plus stable numériquement). C'est la référence de qualité : aucune perte de précision n'est introduite par rapport au format d'entraînement d'origine (souvent FP32, converti sans perte perceptible vers 16 bits). Chaque paramètre occupe 2 octets.

INT8 : la quantisation entière simple

La quantisation INT8 convertit les poids en entiers 8 bits, avec un facteur d'échelle par bloc ou par couche pour limiter la perte de précision. Elle divise par deux la taille mémoire par rapport au FP16, pour une dégradation de qualité généralement faible sur les tâches courantes, plus sensible sur le raisonnement complexe ou les tâches nécessitant une grande précision numérique.

GPTQ : quantisation post-entraînement calibrée

GPTQ (Generative Pre-trained TransformerTransformerIAArchitecture introduite en 2017, fondée sur le mécanisme d'attention, qui traite une séquence entière en parallèle. Elle sert de base à tous les grands modèles de langage actuels.Voir dans le glossaire Quantization) est une méthode de quantisation post-entraînement qui recalibre les poids couche par couche à partir d'un petit jeu de donnéesdonnéesIAEnsemble d'informations structurées ou non utilisées pour entraîner, évaluer ou alimenter un modèle. La qualité, la quantité et la représentativité des données sont les facteurs décisifs pour les performances en apprentissage automatique.Voir dans le glossaire de calibration, afin de minimiser l'erreur introduite. Elle permet de descendre à 4 bits, voire 3 bits, par paramètre, avec une perte de qualité maîtrisée, et s'est imposée comme un standard pour faire tourner de gros modèles sur du matériel grand public.

AWQ : cibler les poids qui comptent

AWQ (Activation-aware Weight Quantization) part d'une observation empirique : tous les poids d'un modèle ne contribuent pas de la même façon à la qualité des sorties. AWQ identifie les poids importants au regard des activations produites et les préserve avec une précision plus élevée, tandis que le reste est quantisé plus agressivement. À taux de compression équivalent, AWQ produit souvent une meilleure qualité que GPTQ.

GGUF : le format pensé pour le déploiement hétérogène

GGUF (GPT-Generated Unified Format), successeur de GGML, est le format utilisé par l'écosystème llama.cpp et par Ollama. Ce n'est pas qu'un algorithme de quantisation mais un format de fichier qui embarque les poids quantisés selon plusieurs niveaux (Q8_0, Q5_K_M, Q4_K_M, Q2_K, etc.), les métadonnées du modèle et parfois le tokenizer. Sa force est la portabilité : un même fichier GGUF peut tourner sur CPU pur, sur GPU, ou en répartition mixte CPU/GPU, ce qui en fait le format de référence pour les déploiements sur matériel hétérogène ou contraint.

Les suffixes GGUF comme Q4_K_M ou Q5_K_S indiquent le nombre de bits moyens par paramètre et la variante de regroupement (K-quant). En règle générale, Q4_K_M offre le meilleur compromis qualité/taille pour un usage de production, Q5_K_M quand la VRAM le permet, et Q8_0 quand la qualité prime sur l'empreinte mémoire.

Tableau comparatif

| Format | Bits/paramètre typique | Perte de qualité | Cas d'usage principal | |---|---|---| | FP16 / BF16 | 16 | Référence (aucune) | Serveurs GPU avec VRAM abondante | | INT8 | 8 | Faible | GPU avec VRAM moyenne, bon compromis simple | | GPTQ | 4 (parfois 3) | Faible à modérée | Inference GPU haute densité | | AWQ | 4 | Faible | Inference GPU, meilleure qualité que GPTQ à taille égale | | GGUF | 2 à 8 (variable) | Variable selon le niveau | CPU, GPU modeste, déploiement hybride |

Estimer la mémoire nécessaire : règles pratiques

Il n'est pas nécessaire de mesurer précisément chaque couche pour dimensionner un projet : une règle de pouce suffit dans la majorité des cas.

VRAM approximative (Go) ≈ Nombre de paramètres (milliards) × Octets par paramètre × 1,2

Le facteur 1,2 couvre la marge pour le cache KV et les activations sur un usage conversationnel standard, à contexte modéré (quelques milliers de tokens) et faible parallélisme.

Exemples de calcul

Un modèle de 13 milliards de paramètres en FP16 (2 octets) : 13 × 2 × 1,2 ≈ 31 Go de VRAM. Le même modèle quantisé en GGUF Q4_K_M (environ 0,55 octet/paramètre effectif) : 13 × 0,55 × 1,2 ≈ 8,6 Go. C'est la différence entre nécessiter un GPU de 40 Go et tenir confortablement sur un GPU grand public de 12 à 16 Go.

Un modèle 70B en FP16 nécessite environ 70 × 2 × 1,2 ≈ 168 Go, hors de portée d'un GPU unique, même haut de gamme. En quantisation 4 bits (GPTQ, AWQ ou GGUF Q4), l'estimation tombe à environ 70 × 0,5 × 1,2 ≈ 42 Go, ce qui reste au-delà d'un GPU 24 Go mais devient accessible avec un GPU 48 Go ou deux GPU de 24 Go en répartition de mémoire.

Ces chiffres sont des ordres de grandeur, pas des garanties. La longueur de contexte utilisée en production, le nombre de requêtes traitées en parallèle et le moteur d'inférence choisi (vLLM, llama.cpp, TensorRT-LLM) font varier la consommation réelle de plusieurs gigaoctets.

Sous-estimer la marge pour le cache KV est l'erreur de dimensionnement la plus fréquente. Avec un contexte long (32k tokens et plus) ou plusieurs utilisateurs servis en parallèle, le cache KV peut représenter plusieurs fois la taille des poids du modèle. Un dimensionnement calé au plus juste sur la taille du modèle seul finit systématiquement par saturer la VRAM en production, avec des erreurs out-of-memory imprévisibles.

CPU-only vs GPU NVIDIA/AMD

Inférence sur CPU

Faire tourner un LLM sur CPU seul est possible, en particulier avec des formats GGUF quantisés et un moteur comme llama.cpp. C'est une option viable pour du prototypage, des volumes de requêtes faibles, ou des contraintes de confidentialité extrêmes interdisant tout accélérateur externe. La contrepartie est un débit nettement inférieur : la génération token par token peut être cinq à vingt fois plus lente que sur GPU. Pour un usage interactif avec plusieurs utilisateurs, le CPU-only devient rapidement un goulot d'étranglement.

GPU NVIDIA

L'écosystème NVIDIA (CUDA) reste le plus mature pour l'inférence LLM. La quasi-totalité des moteurs d'inférence (vLLM, TensorRT-LLM, llama.cpp avec support CUDA) sont optimisés en priorité pour cette plateforme. Les cartes orientées data center (A100, H100, L40S) offrent de grandes quantités de VRAM (40 à 80 Go). Les cartes grand public (RTX 4090, RTX 5090) constituent une alternative économique pour des modèles de taille moyenne, avec 24 à 32 Go de VRAM.

GPU AMD

Les GPU AMD (via la pile logicielle ROCm) progressent mais restent en retrait sur la compatibilité logicielle : certains moteurs d'inférence ne supportent ROCm que partiellement, ou avec un décalage de version par rapport au support CUDA. Le rapport prix/VRAM peut être attractif, notamment sur les cartes orientées calcul (Instinct MI series), mais le choix AMD implique de valider en amont la compatibilité de la chaîne logicielle complète (moteur d'inférence, quantisation, pilotes) avant tout engagement budgétaire.

Pour une première infrastructure d'entreprise, privilégier NVIDIA/CUDA réduit significativement le risque d'intégration, même si le coût par gigaoctet de VRAM est plus élevé qu'en AMD. Le gain de temps sur la mise en production compense généralement l'écart de prix pour des équipes qui découvrent le sujet.

Serveurs rack vs workstation

Deux grandes familles de configurations matérielles se rencontrent en entreprise :

La workstation GPU : un poste de travail ou un petit serveur intégrant un à deux GPU grand public ou semi-professionnels (RTX 4090, RTX 6000 Ada). Coût d'entrée maîtrisé, déploiement rapide, adapté aux équipes de quelques dizaines d'utilisateurs ou aux phases de validation de projet. Limites : refroidissement et alimentation dimensionnés pour un usage bureautique/poste unique, extensibilité réduite, absence de redondance.

Le serveur rack GPU : un serveur data center avec plusieurs GPU professionnels (A100, H100, L40S), alimentation redondante, refroidissement adapté à une charge continue, et souvent une interconnexion GPU-à-GPU haut débit (NVLink) permettant de répartir un modèle sur plusieurs cartes. Coût d'entrée nettement plus élevé, mais seule option viable pour des modèles au-delà de 30-40B en production avec de nombreux utilisateurs simultanés.

Entre les deux, une option intermédiaire existe : le serveur GPU en location chez un hébergeur spécialisé, qui permet de tester un dimensionnement sans investissement en capital, au prix d'une récurrence de coût et de contraintes de souveraineté à examiner selon le secteur.

Le choix entre workstation et serveur rack ne doit pas être arbitré uniquement sur le budget d'achat. Il doit intégrer la charge attendue en nombre d'utilisateurs simultanés, la disponibilité requise (redondance), et la trajectoire de croissance du projet sur 18 à 24 mois. Sous-dimensionner pour économiser au démarrage se traduit presque toujours par une migration matérielle coûteuse un an plus tard.

Trade-offs qualité, débit et coût

Trois curseurs s'opposent en permanence dans un projet de LLM local, et aucune configuration ne les optimise tous les trois simultanément :

• La qualité augmente avec la taille du modèle et la précision conservée.
• Le débit (tokens générés par seconde, nombre de requêtes simultanées) augmente quand le modèle est plus petit, plus quantisé, et que la VRAM disponible autorise un batching important.
• Le coût matériel augmente avec la VRAM totale nécessaire et le nombre de GPU.

Un modèle 70B en FP16 offre la meilleure qualité mais un coût et une lenteur qui le réservent à des cas d'usage à faible volume et forte exigence (analyse juridique, synthèse médicale). Un modèle 7B quantisé en 4 bits offre un débit élevé à coût contenu, suffisant pour de la classification ou des assistants conversationnels à faible enjeu, mais avec une qualité de raisonnement plus limitée sur des tâches complexes.

En pratique, la démarche la plus efficace consiste à partir du besoin métier plutôt que du matériel disponible, puis à choisir le couple modèle/quantisation le plus petit qui satisfait ce besoin. Un modèle surdimensionné n'apporte pas de valeur proportionnelle à son coût si le cas d'usage ne l'exige pas.

Choisir systématiquement le modèle le plus gros « pour être tranquille » est une fausse sécurité. Cela dégrade le débit, augmente le coût matériel, complexifie la maintenance, et n'améliore la qualité perçue que sur une fraction des cas d'usage réels. Le sur-dimensionnement est un risque budgétaire au même titre que le sous-dimensionnement.

Checklist de dimensionnement

Avant de valider une configuration matérielle, vérifiez les points suivants :

1. Charge cible : nombre d'utilisateurs simultanés attendu à 6 mois et à 18 mois.
2. Longueur de contexte typique des cas d'usage (chat court, RAGRAGIATechnique consistant à rechercher les documents pertinents et à les fournir au modèle dans son contexte. Elle permet des réponses à jour et citables, ce que l'affinage ne permet pas.Voir dans le glossaire avec documents longs, code avec fichiers entiers).
3. Taille et quantisation du modèle retenues, avec calcul de la VRAM selon la règle de pouce, marge de 20 à 40 % incluse pour le cache KV et les activations.
4. Compatibilité logicielle entre le moteur d'inférence envisagé (vLLM, llama.cpp, TensorRT-LLM) et le matériel GPU (CUDA vs ROCm).
5. Redondance et disponibilité requises : un GPU unique est un point de défaillance unique.
6. Trajectoire de croissance : la configuration permet-elle d'ajouter des GPU sans tout reconstruire ?
7. Coût total, incluant l'électricité et le refroidissement, souvent négligés à l'achat.

Conclusion

Le dimensionnement matériel d'un LLM local n'est pas un détail d'implémentation : c'est une décision qui conditionne la qualité, le coût et la scalabilité du projet. Comprendre la relation entre taille de modèle, précision numérique et VRAM permet d'anticiper ces contraintes avant de s'engager. Le chapitre suivant comparera les moteurs d'inférence Ollama et vLLM sur ce même arbitrage mémoire/débit.