TurboQuant : quantifier les gros modèles pour les faire tenir en local

#Pourquoi TurboQuant ?

Les K-quants GGUF (Q4_K_M, Q5_K_M…) sont la référence depuis 2023 : universellement supportés par llama.cpp, Ollama, LM Studio, et faciles à produire. Mais ils touchent leur plafond sur les très gros modèles. Un Llama 3 70B en Q4_K_M réclame environ 40 Go de VRAM — hors d'atteinte d'une RTX 4090 24 Go. Descendre à Q3 ou Q2 fait s'effondrer la qualité.

La turboquant quantization adresse spécifiquement ce trou. C'est une famille de techniques qui combinent calibration sur dataset, allocation de bits non-uniforme par couche, et compression par blocs avec dictionnaire partagé. Le résultat : 2.5 à 3 bits effectifs par poids avec une perte de qualité inférieure à celle d'un Q3_K_M GGUF.

#Comment ça compresse

Trois mécanismes se cumulent. Aucun n'est révolutionnaire pris seul ; c'est leur combinaison qui fait la différence.

Calibration sur données

Quelques centaines de prompts représentatifs sont passés dans le modèle pour mesurer quels poids influencent vraiment les sorties. Les autres peuvent être agressivement quantifiés.

Allocation de bits par couche

Au lieu d'un budget fixe (4 bits partout), TurboQuant attribue 5-6 bits aux couches d'attention critiques et descend à 2 bits sur des MLP redondants. Le total moyen tombe à 2.7-3.2 bpw.

Compression par blocs

Les poids sont groupés en blocs de 32 ou 64 valeurs partageant un scale et un offset, avec un codebook compressé par groupe. Cela évite l'overhead par paramètre des K-quants.

#TurboQuant vs GGUF classique

Sur un 70B dense, voici l'ordre de grandeur typique :

GGUF Q4_K_M (~4.5 bpw)

~40 Go, qualité quasi-FP16, supporté partout. La référence.

GGUF Q3_K_M (~3.4 bpw)

~32 Go, perte sensible sur le raisonnement long, des hallucinations apparaissent.

GGUF Q2_K (~2.6 bpw)

~26 Go, modèle clairement dégradé, à éviter pour l'usage sérieux.

TurboQuant ~3.0 bpw

~28 Go, qualité proche du Q4_K_M. Tient sur 1×RTX 3090 ou 1×4090 avec contexte court.

TurboQuant ~2.5 bpw

~23 Go, légèrement en dessous du Q4 mais bien au-dessus du Q3. Permet le 70B sur 24 Go de VRAM.

#Gain VRAM mesuré par taille de modèle

Les chiffres ci-dessous sont relevés sur Llama 3 et Qwen2.5 en architecture dense, contexte 4k, sans Flash Attention. Ajoutez 10-20 % de marge pour le KV cache et l'overhead runtime.

7B — Q4_K_M : 4.4 Go

TurboQuant 3.0 bpw : ~2.9 Go. Intérêt limité, le 7B tient déjà partout.

13B — Q4_K_M : 7.8 Go

TurboQuant 3.0 bpw : ~5.1 Go. Permet 16k+ de contexte sur 8 Go de VRAM.

32B — Q4_K_M : 19 Go

TurboQuant 3.0 bpw : ~13 Go. Tient confortablement sur RTX 4080 16 Go avec contexte 8k.

70B — Q4_K_M : 40 Go

TurboQuant 2.5 bpw : ~23 Go. Permet le 70B sur 1×RTX 4090 24 Go ou 1×3090 24 Go.

120B MoE — Q4_K_M : ~70 Go

TurboQuant 2.7 bpw : ~42 Go. Faisable sur 2×3090 ou un Mac Studio 64 Go.

#Impact sur la qualité

Sur les benchmarks habituels (MMLU, HellaSwag, HumanEval), un TurboQuant 3.0 bpw d'un 70B reste à 0.5-1.5 point du FP16. Sur le raisonnement multi-étapes et le code long, on commence à voir des différences plus nettes. Le test qui sépare le plus clairement les méthodes : un long extrait de code Python avec dépendances croisées.

Connaissances générales

Quasi-imperceptible. Si vous posez des questions de culture générale, vous ne verrez pas la différence.

Raisonnement court

Perte mineure. Les chaînes de pensée restent cohérentes sur 5-10 étapes.

Raisonnement long (math/preuves)

Perte visible. Le modèle peut sauter une étape ou se perdre après 20+ tours de raisonnement. Privilégiez 3.5+ bpw si c'est votre usage.

Code

Sensible aux quantizations agressives. Sous 3.0 bpw, attendez-vous à plus de bugs subtils (mauvais index, conditions inversées). Restez sur Q4_K_M ou TurboQuant ≥3.5 bpw pour Aider/Continue.

Langues rares

Le français passe bien jusqu'à 2.5 bpw. Les langues peu représentées dans le corpus de calibration souffrent davantage.

#Prérequis matériels et logiciels

Quantifier vous-même un modèle reste une opération lourde. Le télécharger pré-quantifié depuis Hugging Face est presque toujours plus simple. Si vous voulez quand même produire votre propre version :

GPU pour la calibration

Il faut pouvoir charger le modèle en FP16 ou en BF16 pendant l'analyse. Pour un 70B, cela suppose 2×A100 80 Go ou un Mac Studio M2 Ultra 192 Go. Pour un 32B, une RTX 4090 24 Go suffit en offload partiel.

Modèle de base

Les poids non quantifiés (safetensors) téléchargés depuis le repo Hugging Face d'origine. Comptez 140 Go pour un 70B FP16.

Dataset de calibration

256 à 1024 échantillons représentatifs de votre usage. Wikipedia FR, code, vos propres prompts. Évitez les datasets génériques si vous avez un domaine précis.

Runtime cible

Décidez en amont : ExLlamaV3 (le plus rapide sur Nvidia), llama.cpp avec backend turbo, ou un fork spécifique. Le format de fichier diffère entre runtimes.

Python 3.10+ et CUDA 12+

Toolchain standard. Côté AMD, ROCm 6.x fonctionne avec llama.cpp mais pas (encore) avec tous les forks turbo.

#Workflow pour quantifier soi-même

Le déroulé type, depuis un modèle Hugging Face FP16 jusqu'à un fichier exécutable dans Ollama ou llama.cpp.

1. 01
   Récupérer les poids d'origine

   Cloner le repo Hugging Face du modèle non quantifié. Compter une heure minimum sur un 70B avec une bonne connexion. Utilisez huggingface-cli download pour pouvoir reprendre une interruption.
2. 02
   Préparer le dataset de calibration

   Construire un fichier JSONL avec 256-1024 prompts. La diversité prime sur la quantité : code, prose française, dialogues, questions techniques. Un fichier de 5-20 Mo suffit largement.
3. 03
   Lancer la calibration

   L'outil (par exemple le script quantize fourni par le projet TurboQuant choisi) charge le modèle, fait passer chaque prompt en avant, et collecte des statistiques d'activation couche par couche. Comptez 1-4h sur un 70B selon le GPU.
4. 04
   Quantifier et exporter

   L'allocation de bits est calculée à partir des statistiques, puis chaque tenseur est encodé. Sortie : un fichier .safetensors ou .gguf selon le runtime. Comptez 30 min à 2h de plus.
5. 05
   Convertir vers le format runtime

   Pour Ollama : créer un Modelfile pointant vers le fichier quantifié, puis ollama create monmodele -f Modelfile. Pour llama.cpp : le binaire main accepte le .gguf directement.
6. 06
   Valider la qualité

   Lancer une mini-batterie de tests : 20-30 prompts couvrant vos usages. Comparer côte-à-côte avec la version GGUF Q4_K_M de référence. Si la dégradation est trop forte, refaire avec plus de bits ou un meilleur dataset.

# Une fois le .gguf TurboQuant produit
cat > Modelfile <<EOF
FROM ./llama3-70b-turboquant-3.0bpw.gguf
PARAMETER num_ctx 8192
PARAMETER temperature 0.7
EOF

ollama create llama3-70b-turbo -f Modelfile
ollama run llama3-70b-turbo "Explique le théorème de Bayes en 3 phrases."

#Pièges courants et dépannage

Le runtime ne reconnaît pas le fichier

TurboQuant n'est pas un format standard unique. Vérifiez que vous chargez bien le fichier avec le runtime correspondant à la méthode utilisée (ExLlamaV3 pour EXL3, llama.cpp version récente pour les GGUF turbo).

VRAM dépassée à l'inférence alors que le fichier rentrait

Vous oubliez le KV cache. Sur un contexte 32k, le KV peut prendre 4-8 Go supplémentaires. Réduisez num_ctx ou activez Flash Attention via OLLAMA_FLASH_ATTENTION=1.

Qualité catastrophique sur votre cas d'usage

Le dataset de calibration ne couvre pas votre domaine. Refaites en ajoutant 100-200 prompts représentatifs. C'est de loin le levier le plus puissant.

Le modèle quantifié est plus lent que le Q4_K_M

Normal sur certaines architectures : la décompression turbo a un overhead. Sur des cartes anciennes (RTX 20xx), le gain VRAM peut se payer en tokens/sec. Mesurez avant d'adopter.

Différences entre runs

La calibration introduit du non-déterminisme. Deux quantizations du même modèle avec le même dataset peuvent diverger légèrement en qualité. Faites plusieurs runs et gardez la meilleure.

#Pour aller plus loin

TurboQuant est un outil parmi d'autres pour repousser la limite de ce qui tient en local. Quelques pistes complémentaires :

Choisir sa quantification (Q4, Q5, Q8, FP16)

Pour bien situer TurboQuant face aux K-quants GGUF classiques et choisir au cas par cas.

Fine-tuning LLM en local : LoRA et QLoRA

Si vous voulez aller plus loin que la quantization et adapter un modèle à votre domaine — souvent un meilleur levier qu'une quantization plus agressive.

Choisir son GPU pour l'IA locale

Pour décider quelle carte cibler en sachant que la VRAM reste la contrainte numéro un, même avec TurboQuant.