Quantization (LLM)

Définition

La quantization (ou quantification) désigne la réduction de la précision numérique utilisée pour stocker les poids et, parfois, les activations d'un grand modèle de langage (LLM). Là où un modèle est entraîné en virgule flottante 32 bits (FP32) ou 16 bits (FP16/BF16), la quantization convertit ces paramètres en entiers sur 8 bits (INT8), 4 bits (INT4) voire moins. L'objectif est double : diviser l'empreinte mémoire du modèle et accélérer l'inférence, au prix d'une perte de fidélité contrôlée. Les formats les plus répandus sont GGUF (écosystème llama.cpp), GPTQ et AWQ (inférence GPU).

Pour un RSSI ou un analyste SOC, la quantization est la technologie qui rend possible l'exécution d'un LLM on-premise, sur du matériel raisonnable, sans envoyer de données sensibles vers une API tierce.

Fonctionnement technique

Un poids en FP16 occupe 2 octets ; en INT4, 0,5 octet. La conversion repose sur une projection affine : chaque groupe de poids est associé à un facteur d'échelle (scale) et parfois à un point zéro (zero-point), qui permettent de reconstituer une valeur approchée lors du calcul. Plus le groupe est petit (group_size=32 ou 128), plus la reconstruction est fidèle, mais plus les métadonnées pèsent.

• PTQ (Post-Training Quantization) : le modèle déjà entraîné est quantifié directement. C'est le cas de GPTQ, AWQ et GGUF. Rapide, peu coûteux, sans réentraînement.
• QAT (Quantization-Aware Training) : la contrainte de précision est simulée pendant l'entraînement ou le fine-tuning. Résultat de meilleure qualité, mais coût de calcul élevé.
• GPTQ : quantification couche par couche, minimisant l'erreur de reconstruction sur un jeu de calibration à l'aide d'une approximation de la matrice hessienne.
• AWQ (Activation-aware Weight Quantization) : identifie le faible pourcentage de poids « saillants » qui portent l'essentiel de l'information et les protège d'une dégradation trop forte.
• GGUF : format conteneur de llama.cpp, avec des variantes dites k-quants (Q4_K_M, Q5_K_M, Q8_0…) mélangeant plusieurs précisions selon la sensibilité des couches. Il permet l'exécution CPU, GPU ou hybride.

Exemples concrets

Un modèle de 70 milliards de paramètres pèse environ 140 Go en FP16 : hors de portée d'un serveur standard. Quantifié en Q4_K_M, il descend autour de 40 Go et devient exploitable sur une station équipée de deux GPU grand public ou sur un serveur doté de suffisamment de RAM. Un modèle de 8 milliards de paramètres passe de ~16 Go à ~4,5 Go et tourne sur un ordinateur portable.

Dans un contexte cyber, cela ouvre des usages très concrets : résumé automatique de tickets d'incident, triage de logs, reformulation d'alertes EDR, assistance à la rédaction de rapports d'audit, ou classification de mails suspects — le tout dans une enclave réseau isolée, sans exfiltration de données vers un service SaaS. Les outils llama.cpp, Ollama, vLLM et text-generation-webui consomment nativement ces formats.

Liens avec les autres enjeux de cybersécurité

• Souveraineté et RGPD : l'inférence locale évite le transfert de données personnelles ou de secrets industriels hors de l'organisation. C'est un argument déterminant pour les traitements couverts par le RGPD ou soumis à une exigence de confidentialité contractuelle.
• Chaîne d'approvisionnement logicielle : les modèles quantifiés sont massivement téléchargés depuis des dépôts publics, souvent republiés par des tiers anonymes. Un fichier de modèle est un artefact au même titre qu'une dépendance logicielle et relève de la même vigilance que celle imposée par la directive NIS 2 sur la sécurité de la chaîne d'approvisionnement.
• Formats de sérialisation : les anciens checkpoints PyTorch reposent sur pickle, qui exécute du code arbitraire au chargement. Les formats safetensors et GGUF sont conçus pour être inertes ; ils restent toutefois exposés aux vulnérabilités du parseur lui-même — plusieurs CVE ont visé llama.cpp.
• Dégradation de l'alignement : la recherche montre qu'une quantization agressive peut affaiblir les garde-fous d'un modèle et le rendre plus sensible aux techniques de jailbreak ou d'injection de prompt. La robustesse observée sur le modèle FP16 n'est pas automatiquement héritée par sa version 4 bits.
• Portes dérobées : des travaux académiques ont démontré qu'un modèle peut se comporter normalement en pleine précision et déclencher un comportement malveillant uniquement une fois quantifié — un scénario d'attaque difficile à détecter par un simple test sur l'original.

Bonnes pratiques

• Ne récupérer les modèles que depuis des organisations vérifiées et contrôler systématiquement l'empreinte SHA-256 publiée.
• Privilégier safetensors ou GGUF et proscrire le chargement de fichiers .bin/.pt d'origine incertaine.
• Maintenir à jour le moteur d'inférence : c'est lui, et non le modèle, qui constitue la surface d'attaque logicielle.
• Rejouer une campagne de tests de sécurité (red teaming, injection de prompt) sur la version quantifiée réellement déployée, pas sur le modèle de référence.
• Éviter les précisions inférieures à 4 bits pour tout usage impliquant une décision de sécurité ; Q5_K_M ou Q8_0 offrent un meilleur compromis.
• Isoler le service d'inférence dans un conteneur sans accès sortant à Internet et journaliser les requêtes pour tracer les usages.
• Inventorier les modèles déployés dans un SBOM étendu à l'IA, en documentant origine, version, format et niveau de quantization.