Quantization et inférence rapide sur votre propre matériel

La première réaction de beaucoup d'ingénieurs en regardant les exigences matérielles d'un grand modèle de langage de pointe est le choc du prix. Un modèle de 70 milliards de paramètres dans son format FP32 natif nécessiterait environ 280 Go de mémoire GPU — plus que la plupart des organisations n'en ont dans un seul serveur, et bien plus qu'elles souhaitent provisionner juste pour répondre aux questions des employés. La quantization est la technique qui rend ces chiffres gérables, et la comprendre est essentielle pour quiconque conçoit une pile IA on-premise.

Ce que fait réellement la quantization

Un réseau neuronal est en fin de compte une très grande collection de nombres — les poids appris pendant l'entraînement. Par défaut, ces poids sont stockés sous forme de valeurs à virgule flottante 32 bits (FP32), chacune consommant 4 octets de mémoire. La quantization remplace les nombres haute précision par des représentations basse précision : des flottants 16 bits (FP16 ou BF16), des entiers 8 bits (INT8) ou même des entiers 4 bits (INT4). L'empreinte mémoire rétrécit proportionnellement, et sur du matériel avec support natif pour l'arithmétique basse précision, l'inférence est également plus rapide.

• FP16 / BF16 — flottants demi-précision. Pratiquement sans perte pour la plupart des tâches ; le choix privilégié pour les déploiements en production où la précision est critique. Économies mémoire : 2x par rapport à FP32.
• INT8 — entiers 8 bits, typiquement produits par des méthodes de quantization post-entraînement (PTQ) telles que GPTQ ou llm.int8(). Légère dégradation de la qualité sur le raisonnement complexe ; significative sur la plupart des tâches pratiques. Économies mémoire : 4x par rapport à FP32.
• INT4 — entiers 4 bits, la frontière de la quantization agressive. Des outils comme GGUF Q4_K_M et AWQ délivrent une qualité étonnamment bonne pour leur taille. Économies mémoire : 8x par rapport à FP32, avec une dégradation acceptable pour les charges de chat et de résumé.

Le compromis qualité vs taille

La quantization n'est pas gratuite. Chaque bit que vous supprimez est de l'information abandonnée, et à un moment donné cela se manifeste sous forme de sorties dégradées — hallucinations, erreurs de raisonnement ou perte de nuance. Le constat pratique des déploiements Privonis est que le compromis est étonnamment favorable pour la plupart des tâches d'entreprise. Un modèle 70 Md quantifié en INT4 surpasse généralement un modèle 13 Md en FP16, même si les deux tiennent dans une mémoire GPU similaire. En cas de doute, utilisez le plus grand modèle qui tient à la précision la plus haute que votre matériel supporte.

Choisir la bonne quantization est moins une question de nombre de bits que d'adaptation de la capacité du modèle à la tâche : un 70 Md INT4 bien choisi bat un 13 Md FP16 mal choisi à chaque fois.

Serveurs d'inférence : d'où vient le débit

Faire tourner un modèle quantifié n'est que la moitié de l'histoire. Le servir efficacement sous charge concurrente nécessite un serveur d'inférence qui comprend la structure de l'attention transformer. L'option open source dominante aujourd'hui est vLLM, qui a introduit PagedAttention — une technique de gestion de mémoire empruntée à la mémoire virtuelle des systèmes d'exploitation qui permet au serveur d'intercaler de nombreuses requêtes simultanément sans gaspiller la mémoire GPU sur des blocs de cache KV pré-alloués. L'effet pratique est une amélioration de 10 à 30x du débit par rapport à une boucle naïve à requête unique.

Parmi les autres options notables : llama.cpp (compatible CPU, excellent pour les modèles plus petits sur du matériel générique), Ollama (wrapper convivial autour de llama.cpp), TGI de Hugging Face (fort support des formats de modèles Hugging Face) et TensorRT-LLM de NVIDIA (débit maximal sur matériel NVIDIA, au prix d'un pipeline de compilation plus complexe). Privonis évalue et compare tous ces systèmes pour chaque configuration client.

Batching et débit

Les GPU atteignent leur efficacité maximale lorsqu'ils traitent de nombreuses opérations simultanément — c'est pour cela qu'ils ont été conçus. Le batching continu (également appelé batching dynamique ou ordonnancement au niveau de l'itération) permet à un serveur d'inférence de regrouper les tokens de plusieurs requêtes concurrentes dans un seul appel de noyau GPU, améliorant dramatiquement l'utilisation. Sans batching, une seule requête utilisateur peut utiliser 5 % de la capacité de votre GPU ; avec le batching continu, vous pouvez pousser l'utilisation à 70-80 % sous des patterns de trafic réels. Pour une entreprise avec des dizaines d'utilisateurs simultanés, la différence entre un serveur compatible batching et un serveur naïf peut signifier la différence entre avoir besoin d'un serveur GPU ou de quatre.

Choisir la bonne quantization pour votre GPU

L'arbre de décision est plus simple qu'il n'y paraît. Commencez par votre budget VRAM GPU, soustrayez la marge pour l'OS et le serveur d'inférence (typiquement 4 à 8 Go), puis trouvez le plus grand modèle qui tient au niveau de précision le plus élevé. Quelques points de référence pratiques :

• 24 Go VRAM (ex. RTX 4090, A5000) — fait tourner confortablement un modèle 13 Md en FP16, ou un modèle 34 Md en INT4.
• 48 Go VRAM (ex. RTX 6000 Ada, A6000) — fait tourner un modèle 34 Md en FP16, ou un modèle 70 Md en INT4.
• 2 × 80 Go (ex. paire A100 via NVLink) — fait tourner un modèle 70 Md en FP16, ou un modèle 140 Md en INT4 avec parallélisme tensoriel.
• CPU uniquement (sans GPU) — llama.cpp avec un modèle Q4_K_M 7 Md ou 13 Md est viable pour des outils développeur à faible concurrence ; attendez 5 à 15 tokens/s.

Tout assembler avec Privonis

Choisir un format de quantization et un serveur d'inférence est un travail d'ingénierie qui nécessite un profilage sur votre matériel spécifique avec votre charge de travail spécifique. Privonis gère ce benchmarking dans le cadre de chaque déploiement : nous exécutons des tests de débit, mesurons la qualité des sorties sur un échantillon représentatif de vos prompts réels, et livrons une configuration qui maximise les performances dans votre budget matériel. Le résultat est une pile d'inférence en production que votre équipe peut exploiter sans avoir un ingénieur ML spécialisé en permanence. Si vous êtes prêt à explorer ce qui convient à votre environnement, notre équipe est heureuse de faire les calculs avec vous.