INT4 (Integer 4-bit)

INT4 est un type de donnée entier signé codé sur 4 bits (0,5 octet), représentant des valeurs de -8 à 7, utilisé en quantization pour réduire d’environ 75 % l’empreinte mémoire d’un modèle IA par rapport au FP16, rendant possible l’exécution de LLM de plusieurs dizaines de milliards de paramètres sur du matériel grand public.

C’est le format de quantification le plus populaire pour l’inférence locale. Un modèle de 7 milliards de paramètres en FP16 pèse environ 14 Go. En INT4, il descend à 3,5 à 5 Go selon la méthode, ce qui le fait tenir sur un GPU de 8 Go ou sur un MacBook de 16 Go sans difficulté. La contrepartie : une perte de qualité légèrement plus marquée qu’en INT8, mais que les méthodes modernes (GPTQ, AWQ, K-quants) ramènent à des niveaux très acceptables pour la majorité des usages.

Type: Entier signé 4 bits
Plage de valeurs: -8 à 7 (signé) / 0 à 15 (non signé)
Taille: 0,5 octet par valeur
Gain mémoire: ~75 % vs FP16, ~87,5 % vs FP32
Perte de qualité: 1-3 % selon la méthode (97-99 % de la qualité FP16 avec AWQ ou Q4_K_M)
Méthodes associées: GPTQ, AWQ, Q4_K_M (GGUF), NF4 (bitsandbytes), EXL2
Outils compatibles: vLLM, Ollama, LM Studio, Jan, TensorRT-LLM, llama.cpp
Cas d’usage principal: Inférence locale, déploiement edge, serving haute concurrence

Pourquoi INT4 change la donne

INT4 est le format qui a rendu les LLM accessibles au grand public. Avant l’essor des méthodes de quantification 4 bits, faire tourner un modèle de 13 milliards de paramètres exigeait un GPU serveur coûteux. Avec INT4, ce même modèle rentre dans un GPU gaming de 12 Go.

L’impact est double. Pour l’inférence locale, INT4 permet de faire tourner des modèles 7B sur des cartes de 8 Go, des modèles 13B sur des cartes de 12 Go, et des modèles 32B-70B sur des cartes de 24 Go (RTX 4090). Pour la production serveur, INT4 libère de la VRAM pour le cache KV, ce qui multiplie le nombre d’utilisateurs concurrents. Sur un H100 80 Go, un modèle 32B en BF16 consomme ~64 Go pour les poids seuls. En INT4, il passe à ~18 Go, libérant plus de 40 Go pour le cache et les requêtes simultanées.

Les chiffres parlent d’eux-mêmes : un benchmark récent sur H100 montre qu’un modèle Qwen3-32B en INT4 (GPTQ) atteint 2,69× le throughput de la version BF16, car l’inférence LLM au batch size 1 est limitée par la bande passante mémoire, pas par le calcul. Réduire la taille des tenseurs accélère directement le transfert de données.

Comment fonctionne la représentation INT4

Seulement 16 valeurs possibles

Avec 4 bits, vous ne disposez que de 16 valeurs distinctes. En signé, la plage va de -8 à 7. En non signé, de 0 à 15. C’est drastiquement peu comparé aux 256 valeurs d’INT8 ou aux 65 536 de FP16. Chaque valeur flottante du modèle original doit être mappée vers l’une de ces 16 « marches » (notches), ce qui introduit inévitablement une erreur d’arrondi.

Prenez un poids de 0.15625 dans un groupe dont la valeur max est 1.0. Le scale factor en INT4 signé est 7 / 1.0 = 7. Le poids quantifié vaut 0.15625 × 7 = 1.09, arrondi à 1. Déquantifié : 1 / 7 = 0.1429. L’erreur est d’environ 8,6 %, bien plus élevée qu’en INT8 (0,7 % pour la même valeur). C’est pourquoi la granularité de la quantification (la taille des groupes) et la méthode utilisée sont cruciales en 4 bits.

L’importance de la taille de groupe

En INT4, chaque groupe de poids (typiquement 32 à 128 éléments) partage un scale factor stocké en FP16. Plus le groupe est petit, plus la quantification est précise, car le scale factor s’adapte à la distribution locale des poids. Mais des groupes plus petits signifient plus de scale factors à stocker, ce qui augmente l’overhead.

En pratique, des groupes de 128 éléments offrent un bon compromis. Avec des groupes de 128 et un scale factor FP16 (2 octets) pour chaque groupe, l’overhead est d’environ 0,125 bit par poids (2 octets / 128 poids × 8 bits). C’est pourquoi un modèle « 4 bits » pèse en réalité entre 4,1 et 4,8 bits effectifs par poids, et non exactement 4.

Les K-quants de llama.cpp vont encore plus loin avec une structure de super-blocs contenant des sous-blocs, chacun avec ses propres facteurs d’échelle, le tout hiérarchiquement quantifié. C’est cette sophistication qui explique les performances remarquables du format Q4_K_M.

Les méthodes de quantification INT4

Cinq méthodes dominent l’écosystème INT4. Le choix dépend de votre stack d’inférence et de vos priorités.

GPTQ

GPTQ est la première méthode à avoir démontré qu’on pouvait compresser un LLM de 175 milliards de paramètres à 4 bits avec une perte de qualité acceptable. Elle quantifie les poids couche par couche en minimisant l’erreur quadratique de reconstruction, en utilisant une approximation de second ordre (matrice Hessienne). GPTQ nécessite un dataset de calibration (128-512 exemples) mais ne touche pas aux activations (format W4A16 : poids en 4 bits, activations en FP16).

GPTQ reste la méthode la plus répandue côté GPU, avec un écosystème riche de modèles pré-quantifiés sur Hugging Face Hub. Elle est supportée par vLLM, AutoGPTQ, et TGI. Un modèle 32B en GPTQ-INT4 peut être quantifié en quelques heures sur un seul GPU.

Kernels Marlin : le turbo pour GPTQ/AWQ La vitesse d’inférence d’un modèle INT4 dépend autant du kernel que de la méthode de quantification. Les kernels Marlin, optimisés pour les multiplications matricielles INT4 sur GPU, accélèrent considérablement les modèles GPTQ et AWQ. Sur un benchmark Qwen2.5-32B avec H200, Marlin-GPTQ atteint 712 tok/s contre 276 tok/s pour GPTQ standard (2,6× plus rapide), et Marlin-AWQ atteint 741 tok/s contre 68 tok/s pour AWQ standard (10,9× plus rapide). Dans vLLM, activez Marlin avec --quantization marlin.

AWQ

AWQ (Activation-aware Weight Quantization) part d’une observation simple mais puissante : moins de 1 % des poids d’un LLM sont « saillants », c’est-à-dire qu’ils ont un impact disproportionné sur la qualité des sorties. Plutôt que de quantifier tous les poids uniformément, AWQ identifie ces poids critiques en analysant les distributions d’activation lors d’une passe de calibration, puis applique un facteur de mise à l’échelle par canal pour les protéger avant la quantification uniforme.

Le résultat : AWQ atteint systématiquement une perplexité plus basse que GPTQ à précision équivalente sur les modèles Llama. AWQ ne dépend pas de la rétropropagation ni de la reconstruction des sorties (contrairement à GPTQ), ce qui le rend moins sujet à l’overfitting sur les données de calibration. C’est un avantage concret pour les modèles instruction-tuned et multimodaux.

AWQ est le format recommandé quand la qualité est prioritaire en INT4 sur GPU. L’inférence est optimale avec vLLM + kernels Marlin.

Q4_K_M (GGUF / llama.cpp)

Q4_K_M est le format de référence pour l’inférence locale via llama.cpp, Ollama, LM Studio ou Jan. Le nom encode trois informations : Q4 = poids principalement en 4 bits, K = méthode K-quant (précision mixte par couche), M = Medium (compromis moyen entre taille et qualité).

Contrairement à GPTQ ou AWQ qui appliquent une précision uniforme, les K-quants allouent la précision par type de couche. Dans Q4_K_M, les tenseurs d’attention output (wv, wo) sont quantifiés à 6 bits (Q6_K), tandis que les couches feedforward descendent à 4 bits (Q4_K). Cette stratégie de précision mixte est la raison pour laquelle Q4_K_M conserve 97 à 99 % de la qualité FP16 sur les benchmarks de perplexité, tout en réduisant la taille de 65 à 70 %.

Q4_K_M excelle en inférence CPU et en configuration hybride CPU+GPU. C’est le sweet spot reconnu par la communauté llama.cpp. Pour un modèle Llama 3.1 8B, Q4_K_M pèse environ 4,9 Go.

NF4 (NormalFloat 4-bit / bitsandbytes)

NF4 est un format 4 bits spécifiquement optimisé pour les poids de réseaux de neurones. L’idée : les poids d’un Transformer suivent approximativement une distribution normale centrée autour de zéro. INT4 standard répartit ses 16 niveaux de manière uniforme sur l’intervalle, gaspillant de la résolution dans les zones peu peuplées. NF4 place davantage de niveaux de quantification dans la zone dense autour de zéro, là où se concentrent la majorité des poids.

Le résultat : NF4 atteint une erreur d’environ 0,2 % par rapport aux valeurs originales, significativement mieux que l’INT4 uniforme. Combiné à la Double Quantization (quantification des scale factors eux-mêmes), NF4 économise environ 0,4 bit supplémentaire par poids. C’est le format utilisé par QLoRA pour le fine-tuning de gros modèles sur un seul GPU.

L’usage est trivial avec Hugging Face Transformers :

from transformers import AutoModelForCausalLM, BitsAndBytesConfig

bnb_config = BitsAndBytesConfig(
    load_in_4bit=True,
    bnb_4bit_quant_type="nf4",
    bnb_4bit_compute_dtype="bfloat16",
    bnb_4bit_use_double_quant=True,
)

model = AutoModelForCausalLM.from_pretrained(
    "meta-llama/Llama-3.1-8B-Instruct",
    quantization_config=bnb_config,
    device_map="auto",
)

EXL2 (ExLlamaV2)

EXL2 est une évolution de GPTQ développée par ExLlamaV2, un moteur d’inférence GPU optimisé pour la faible latence. Sa particularité : l’allocation dynamique de bits par couche. Au lieu d’appliquer 4 bits uniformément, EXL2 peut assigner 5 ou 6 bits aux couches sensibles et 3 bits aux moins importantes, en ciblant un taux moyen (par exemple 4,0 bpw). Cela produit souvent de meilleurs résultats que la quantification uniforme à bits équivalents.

EXL2 excelle à des taux intermédiaires comme 5,0 ou 6,0 bpw, mais reste compétitif à 4,0 bpw. Son usage est plus restreint que GPTQ/AWQ (il nécessite ExLlamaV2 pour l’inférence), mais c’est un excellent choix pour les utilisateurs GPU qui veulent maximiser la qualité.

Comparaison des méthodes INT4

Méthode	Format de fichier	Stack d’inférence	CPU	GPU	Fine-tuning	Point fort
GPTQ	SafeTensors	vLLM, AutoGPTQ, TGI	Non	Oui	Non	Écosystème mature, large bibliothèque de modèles pré-quantifiés
AWQ	SafeTensors	vLLM, AutoAWQ, TGI	Non	Oui	Non	Meilleure qualité à 4 bits, robust sur modèles instruction-tuned
Q4_K_M (GGUF)	GGUF	llama.cpp, Ollama, LM Studio, Jan	Oui	Oui (hybride)	Non	Meilleur compromis CPU/hybride, précision mixte par couche
NF4 (bitsandbytes)	SafeTensors (runtime)	HF Transformers	Non	Oui	Oui (QLoRA)	Seule option qui supporte le fine-tuning en 4 bits
EXL2	EXL2	ExLlamaV2	Non	Oui	Non	Allocation dynamique de bits, faible latence

Quel format choisir ? Pour l’inférence locale (CPU ou hybride) : Q4_K_M via Ollama. C’est le standard de facto. Pour le serving GPU haute performance : AWQ + vLLM avec kernel Marlin. C’est le combo le plus rapide et le plus qualitatif. Pour le fine-tuning sur GPU limité : NF4 avec bitsandbytes et QLoRA. C’est la seule option viable en 4 bits. Pour la faible latence GPU pure : EXL2 via ExLlamaV2.

Impact sur la qualité : benchmarks détaillés

La perte de qualité en INT4 est réelle mais contenue, et elle varie fortement selon le type de tâche et la méthode.

Benchmarks généraux

Sur un Qwen3-32B évalué sur H100, la quantification INT4 via GPTQ conserve 98,1 % de la capacité de raisonnement baseline sur MMLU-Pro. Sur les modèles 8B type Llama 3.1, la perplexité en Q4_K_M (6,74) et en AWQ (6,84) reste proche du baseline BF16 (6,36), soit un écart d’environ 6 % en perplexité. Pour la plupart des applications, cette différence ne se ressent pas dans les réponses.

Sensibilité par type de tâche

Les benchmarks récents révèlent des différences importantes selon la tâche :

Conversation et rédaction : très résistant à la quantification 4 bits. Les réponses restent fluides et cohérentes. C’est le cas d’usage idéal pour INT4.

Raisonnement mathématique (GSM8K) : étonnamment résistant. Les tâches arithmétiques étape par étape conservent 84 à 87 % de la qualité baseline même en Q4_K_M. Les architectures de raisonnement solides (comme Qwen) s’en sortent particulièrement bien.

Génération de code (HumanEval) : modérément sensible. AWQ et Q4_K_M atteignent environ 51,8 % de Pass@1 contre 56,1 % pour le baseline, soit une baisse d’environ 4 points. GPTQ tend à mieux préserver la précision token par token nécessaire au code.

Suivi d’instructions (IFEval) : le plus sensible. Les benchmarks montrent des pertes pouvant dépasser 10 % en INT4, avec des comportements parfois erratiques. L’alignement du décodeur, crucial pour le suivi précis d’instructions, souffre à très basse précision.

Attention aux agents IA Si vous déployez un modèle quantifié en INT4 pour un agent IA qui doit suivre des instructions de manière déterministe (remplissage de formulaires, classification de documents, appels d’outils), testez abondamment. Le suivi d’instructions est le point le plus fragile de la quantification 4 bits. Préférez INT8 ou FP8 pour ces cas d’usage critiques.

Tableau des tailles par modèle et format

Modèle	Paramètres	FP16	INT8 (Q8_0)	INT4 (Q4_K_M)	INT4 (AWQ/GPTQ)	GPU min (INT4)
Llama 3.1 8B	8B	~16 Go	~8,5 Go	~4,9 Go	~4,5 Go	8 Go (RTX 4060)
Mistral 7B	7B	~14 Go	~7,5 Go	~4,4 Go	~4 Go	8 Go
Llama 3.1 13B	13B	~26 Go	~13,5 Go	~7,9 Go	~7,5 Go	12 Go (RTX 4060 Ti)
Qwen3 32B	32B	~64 Go	~32 Go	~19 Go	~18 Go	24 Go (RTX 4090)
Llama 3.1 70B	70B	~140 Go	~70 Go	~40 Go	~35 Go	48 Go (2× RTX 4090 ou A100)

Pourquoi Q4_K_M est plus gros que GPTQ/AWQ ? Q4_K_M utilise une précision mixte : certaines couches sont à 6 bits (Q6_K) au lieu de 4. C’est ce qui explique une taille supérieure (~4,8 bits effectifs par poids) par rapport à GPTQ/AWQ (~4,1 bits). En contrepartie, la qualité est souvent légèrement meilleure, et le format fonctionne aussi sur CPU.

INT4 en pratique

Inférence locale

La manière la plus simple de lancer un modèle INT4 en local est d’utiliser Ollama :

# Modèle 8B en Q4_K_M (par défaut)
ollama run llama3.1

# Spécifier explicitement la quantification
ollama run llama3.1:8b-q4_K_M

# Modèle 70B en Q4_K_M (nécessite ~40 Go de RAM/VRAM)
ollama run llama3.1:70b-q4_K_M

Ollama télécharge automatiquement la variante Q4_K_M quand vous ne spécifiez pas de tag. C’est le format par défaut car il offre le meilleur compromis taille/qualité reconnu par la communauté.

LM Studio offre une interface graphique qui parcourt les modèles GGUF sur Hugging Face. Vous pouvez comparer les variantes (Q4_K_S, Q4_K_M, Q5_K_M, Q6_K) et choisir celle qui correspond à votre mémoire disponible. Jan fonctionne de manière similaire avec un focus sur la vie privée.

Serving GPU (production)

Pour le serving haute performance, vLLM avec un modèle AWQ ou GPTQ et le kernel Marlin est la configuration optimale :

# AWQ avec kernel Marlin (recommandé)
vllm serve Qwen/Qwen2.5-32B-Instruct-AWQ 
    --quantization marlin 
    --gpu-memory-utilization 0.9

# GPTQ-INT4 avec kernel Marlin
vllm serve Qwen/Qwen2.5-32B-Instruct-GPTQ-Int4 
    --quantization marlin 
    --gpu-memory-utilization 0.9

Le kernel Marlin exploite la hiérarchie mémoire du GPU (HBM → L2 → SMEM) de manière optimale pour les multiplications matricielles INT4, ce qui explique l’accélération spectaculaire par rapport aux kernels GPTQ/AWQ standards.

Fine-tuning avec QLoRA

NF4 via bitsandbytes est le seul chemin viable pour fine-tuner un modèle en 4 bits. Le modèle de base est gelé en NF4, et des adaptateurs LoRA légers sont ajoutés et entraînés en FP16/BF16. Cela permet de fine-tuner un modèle 70B sur un seul GPU de 24 Go (RTX 4090), une opération qui nécessiterait sinon 4 à 8 GPU A100 en pleine précision.

from peft import LoraConfig, get_peft_model

lora_config = LoraConfig(
    r=16,
    lora_alpha=32,
    target_modules=["q_proj", "v_proj"],
    lora_dropout=0.05,
    task_type="CAUSAL_LM",
)

model = get_peft_model(model, lora_config)
# Le modèle de base reste en NF4, seuls les adaptateurs sont entraînables

INT4 vs les alternatives

INT4 vs INT8

Le choix se résume à : avez-vous assez de mémoire pour INT8 ? Si oui, et que la qualité est critique, restez en INT8. Si la mémoire est serrée ou si vous voulez maximiser le throughput, INT4 est le bon choix. La perte de qualité entre INT8 et INT4 est modeste (environ 1 à 3 points de pourcentage sur les benchmarks) et imperceptible pour les usages conversationnels.

INT4 vs FP4 / NF4

FP4 utilise une représentation flottante sur 4 bits (signe + exposant + mantisse), offrant une plage dynamique plus large que l’INT4 uniforme. NF4 va encore plus loin en plaçant les niveaux de quantification selon une distribution normale. En pratique, NF4 offre la meilleure qualité à 4 bits (erreur ~0,2 % vs l’original) mais nécessite bitsandbytes pour l’inférence, ce qui le limite au prototypage et au fine-tuning. Pour la production, GPTQ et AWQ restent plus performants en throughput grâce à leurs kernels optimisés.

L’architecture Blackwell de NVIDIA introduit le support natif de NVFP4, une variante FP4 accélérée par les Tensor Cores de 5ème génération. Ce format promet des performances doubles par rapport au FP8, mais l’écosystème logiciel est encore en cours de maturation.

INT4 vs sub-4-bit (INT3, INT2)

En dessous de 4 bits, la dégradation devient significative. Les méthodes à 3 bits (Q3_K_S, Q3_K_M en GGUF) conviennent pour des scénarios de compression extrême sur matériel très limité, mais la perte de qualité est perceptible sur les tâches de raisonnement. Les quantifications à 2 bits et 1 bit (binarisation) sont encore expérimentales. INT4 reste le plancher pratique pour une qualité acceptable en production.

Limites et pièges courants

Les formats ne sont pas interconvertibles. Un modèle GGUF ne peut pas être converti en AWQ (ni l’inverse) sans repasser par les poids FP16 originaux. Convertir entre formats quantifiés entraîne une perte de qualité cumulative. Partez toujours des poids FP16 pour quantifier vers le format cible.

Les modèles plus petits souffrent davantage. Un modèle de 3B de paramètres quantifié en INT4 perdra proportionnellement plus de qualité qu’un 70B, car chaque poids individuel a plus d’importance relative dans un petit modèle. Si vous utilisez un modèle de moins de 7B, préférez INT8 ou Q5_K_M.

Tester sur vos données. La perplexité WikiText-2 ne capture pas tout. Un modèle peut avoir une bonne perplexité globale tout en échouant sur vos instructions métier spécifiques. Évaluez toujours sur un échantillon représentatif de votre cas d’usage.

Le kernel compte autant que la méthode. Un modèle AWQ sans kernel optimisé (Marlin) peut être plus lent que du FP16. Vérifiez que votre stack d’inférence utilise les kernels appropriés avant de conclure sur les performances.

Questions fréquentes sur INT4

Un modèle INT4 est-il suffisamment bon pour un usage quotidien ?

Oui, pour la très grande majorité des usages. En conversation, rédaction, résumé, Q&A et code standard, un modèle 7B ou 13B quantifié en INT4 (via AWQ ou Q4_K_M) produit des résultats quasi indistinguables de la version FP16. La perte se manifeste surtout sur les tâches de raisonnement mathématique avancé ou de suivi d’instructions complexes. Si vous utilisez un modèle pour discuter, rédiger ou coder au quotidien, INT4 est parfaitement adapté.

Quelle est la différence entre Q4_K_M, Q4_K_S et Q4_0 ?

Ce sont trois variantes de quantification 4 bits dans l’écosystème GGUF / llama.cpp. Q4_0 est le format legacy (quantification uniforme simple, obsolète). Q4_K_S (Small) utilise les K-quants avec une précision mixte minimale, produisant un fichier plus petit mais de qualité légèrement inférieure. Q4_K_M (Medium) est le sweet spot : il alloue plus de bits aux couches d’attention et offre le meilleur compromis taille/qualité. C’est celui à utiliser par défaut.

Puis-je fine-tuner un modèle pré-quantifié en GPTQ ou AWQ ?

Non, pas directement. Les poids pré-quantifiés en GPTQ ou AWQ sont figés et ne peuvent pas être entraînés. Pour le fine-tuning en 4 bits, utilisez NF4 via bitsandbytes avec QLoRA : le modèle de base est chargé en 4 bits, et des adaptateurs LoRA sont entraînés par-dessus en pleine précision. Alternativement, vous pouvez fine-tuner en FP16 puis quantifier le résultat en GPTQ/AWQ.

Combien de VRAM faut-il pour un modèle 70B en INT4 ?

Comptez environ 35 à 45 Go pour les poids seuls (selon le format), plus 5 à 15 Go pour le cache KV et l’overhead selon la longueur de contexte et le framework. En pratique, un modèle Llama 3.1 70B en Q4_K_M (~40 Go) peut tourner sur un setup dual-GPU de 24 Go chacun (2× RTX 4090 = 48 Go), ou sur un seul GPU A100/H100 de 80 Go avec de la marge pour la concurrence. Sur CPU via llama.cpp, il faut au minimum 48 Go de RAM système.

AWQ ou GPTQ : lequel est le meilleur en INT4 ?

AWQ offre généralement une meilleure qualité (perplexité plus basse) et se montre plus robuste sur les modèles instruction-tuned et multimodaux. GPTQ offre un écosystème plus large (plus de modèles pré-quantifiés disponibles) et se comporte légèrement mieux sur les tâches de génération de code dans certains benchmarks. Avec les kernels Marlin, les deux atteignent des performances similaires en throughput dans vLLM. En résumé : AWQ si la qualité prime, GPTQ si vous avez besoin d’un modèle spécifique uniquement disponible dans ce format.