GGUF et quantification : Q4_K_M vs Q6_K vs Q8_0 mesurés

👁 121 lectures

Le format GGUF et la quantification GGUF déterminent le compromis direct entre empreinte mémoire, vitesse d’inférence et fidélité du modèle. En pratique, le palier Q4_K_M représente le seuil d’efficacité idéal au quotidien, tandis que Q5_K_M et Q6_K offrent une précision quasi indiscernable de la référence sans saturer votre matériel. Pour explorer le déploiement de ces architectures chez vous, consultez mon dossier complet sur l’IA locale et les modèles de texte, image et vidéo.

Synthèse : que choisir selon vos besoins

• Q4_K_M - le format le plus compact recommandable. Sur Bielik 11B, le fichier pèse 6,72 Go et reproduit le token le plus probable de Q8_0 dans 94,1 % des situations.
• Q5_K_M et Q6_K - le compromis optimal si votre VRAM le permet. L’écart de perplexité par rapport à Q8_0 reste confiné dans la marge d’erreur de mesure.
• Q8_0 - quasiment identique au fichier non quantifié (96,7 % d’alignement avec F16 sur le modèle 1.5B), mais il est presque deux fois plus lourd que Q4_K_M et sensiblement plus lent.
• Q3_K_M et inférieurs - à réserver exclusivement aux grands modèles en cas de contrainte extrême. Un modèle 1.5B en Q2_K perd toute cohérence (0 tâche réussie sur 12).
• Un modèle plus imposant en Q4 surpasse systématiquement un modèle plus petit conservé en Q8 : Bielik 11B en Q3_K_M (5,40 Go) valide 11 tests sur 12, contre 5 sur 12 pour Bielik 4.5B en Q8_0 (5,06 Go).

Qu’est-ce que le format GGUF ?

GGUF est un format binaire conçu par l’équipe ggml-org (à l’origine de llama.cpp) introduit en août 2023. Un unique fichier rassemble les poids du modèle ainsi que l’ensemble des métadonnées indispensables à son exécution : architecture, tokenizer, template de discussion et fenêtre de contexte maximale. Cette structure unifiée permet de charger exactement le même fichier dans llama.cpp, dans LM Studio ou Ollama.

La spécification suit une nomenclature standardisée de type Nom-Taille-Ajustement-Version-Encodage.gguf. Dans le nom de fichier Bielik-11B-v3.0-Instruct.Q4_K_M.gguf, le dernier segment détaille précisément le schéma de quantification appliqué.

Comprendre la quantification GGUF : Q4_K_M, Q6_K, Q8_0, F16 et IQ

Quantifier un modèle consiste à stocker ses poids numériques sur un nombre réduit de bits. Les versions d’origine conservent chaque poids sur 16 bits (F16 ou BF16). Q8_0 le compresse sur environ 8,5 bits et Q4_K_M sur un peu moins de 5 bits. Le fichier devient plus léger, tient sur une carte graphique plus modeste et génère du texte plus vite, la bande passante mémoire étant le principal facteur limitant lors de l’inférence.

Ces densités de bits proviennent de la documentation officielle de llama-quantize mesurée sur Llama 3.1 8B. Le suffixe K désigne les k-quants, où les poids sont regroupés par super-blocs de 256 éléments dont les échelles sont elles-mêmes quantifiées. Les déclinaisons _S, _M, _L appliquent des précisions hybrides : Q4_K_M conserve les tenseurs les plus sensibles en Q6_K, tandis que Q4_K_S traite l’intégralité en 4 bits. La famille IQ repose sur des distributions de quantification non linéaires optimisées par une matrice d’importance (imatrix), calculée à partir d’un échantillon textuel pour minimiser les erreurs sur les zones clés.

Mesures sur banc d’essai : Bielik sur RTX 4090

J’ai réalisé l’ensemble de ces mesures le 17 octobre 2026 sur ma machine personnelle équipée d’une carte RTX 4090 24 Go, d’un processeur i9-14900KF et de 64 Go de RAM sous Windows 11, en exécutant llama.cpp CUDA avec l’intégralité des couches déchargée sur le GPU.

• Fichiers testés : versions officielles F16 et Q8_0 de Bielik 1.5B v3.0, ainsi que Q8_0 de Bielik 4.5B et 11B issues de l’organisation speakleash sur Hugging Face. Les autres variantes ont été quantifiées via llama-quantize (depuis F16 pour 1.5B, et depuis Q8_0 pour 4.5B et 11B). J’ai également inclus le fichier officiel Q4_K_M pour le 11B récupéré via Ollama.
• Perpexité et conformité : calculées avec llama-perplexity sur un contexte de 2048 jetons sur un extrait en langue polonaise du roman de Zofia Nałkowska (environ 7 900 mots). La conformité indique le pourcentage de jetons où le token le plus probable coïncide exactement avec la base F16 (ou Q8_0 pour 11B).
• Vitesse : mesurée via llama-bench sur une génération de 128 jetons (moyenne de 3 répétitions).
• VRAM : relèvement de l’allocation via nvidia-smi sur llama-server avec un contexte fixé à 4096 jetons.
• Évaluation pratique : série de 12 tâches courtes avec réponse univoque (conjugaison, logique, pourcentages, formatage JSON), exécutées à température 0.

Bielik 1.5B : échelle complète de F16 à Q2_K

Un modèle de 1,5 milliard de paramètres demeure intrinsèquement limité : même en version brute F16, il échoue sur des attributions d’auteurs élémentaires. En Q3_K_M les erreurs factuelles explosent, et la quantification Q2_K provoque des répétitions infinies sans lien avec la consigne.

Bielik 11B : comportement de Q8_0 à Q3_K_M

La version Q4_K_M créée manuellement à partir de Q8_0 affiche des scores strictement comparables au fichier officiel (109,1 tok/s et 10/12 tâches). Sur des modèles plus imposants comme Gemma 4 31B sur RTX 4090, la gestion de cette empreinte mémoire devient encore plus déterminante.

Enseignements clés des mesures

• Jusqu’au palier Q5_K_M, l’évolution de la perplexité est inférieure à la marge d’erreur expérimentale (environ ±0,10 sur le modèle 11B). La première dégradation notable apparaît à Q4_K_M sur le petit modèle, mais seulement à Q3_K_M sur le grand.
• Plus l’architecture d’un modèle compte de paramètres, mieux elle tolère la compression : Q4_K_M préserve 94,1 % d’alignement sur 11B, contre 83,6 % sur 1.5B et 82,7 % sur 4.5B.
• L’emploi d’une imatrix améliore la fidélité sans surcoût de stockage : sur 1.5B, la conformité passe de 83,6 % à 88,1 % à taille rigoureusement identique.
• Sur un texte mémorisé lors de l’entraînement, la perplexité mesurée s’effondre (1,20 sur le roman classique de Prus pour 11B). C’est pourquoi un texte littéraire non surreprésenté est nécessaire pour obtenir un banc d’essai objectif. Les valeurs absolues ne doivent pas être comparées entre 1.5B et 11B car leurs tokenizers segmentent un même passage en 14 767 contre 23 760 jetons.

Recommandations pratiques pour 8, 12, 16 et 24 Go de VRAM

Les consommations indiquées correspondent à l’empreinte de llama-server sans inclure l’environnement de bureau de Windows et le navigateur, qui mobilisent couramment 1 à 2 Go supplémentaires en arrière-plan.

• 8 Go de VRAM : privilégiez Bielik 11B en Q3_K_M (6,3 Go avec un contexte de 4096) ou Bielik 4.5B en Q8_0 (5,3 Go). Le palier Q4_K_M du modèle 11B requiert 7,5 Go et risque d’entraîner des débordements mémoire.
• 12 Go de VRAM : Bielik 11B en Q4_K_M ou Q5_K_M (7,5 à 8,6 Go) permet de conserver une marge confortable pour étendre la taille de contexte.
• 16 Go de VRAM : Bielik 11B en Q6_K (9,7 Go), ou la version Q4_K_M configurée avec son contexte intégral de 32 768 jetons (13,0 Go).
• 24 Go de VRAM : vous pouvez faire tourner Bielik 11B en Q8_0 sur son contexte complet de 32 768 jetons (17,7 Go), ou opter pour un modèle de gabarit supérieur quantifié en Q4_K_M pour maximiser les capacités de raisonnement. Vous pouvez facilement interfacer ce type d’instance avec une interface locale via Open WebUI et Ollama.

Script PowerShell pour mesurer vos fichiers GGUF

Pour reproduire ces tests sur votre configuration :

1. Récupérez l’archive de llama.cpp avec prise en charge CUDA depuis le dépôt GitHub ggml-org et décompressez-la dans un répertoire dédié, par exemple D:\llama-cuda.
2. Téléchargez les variantes GGUF d’un modèle depuis son dépôt officiel vers un dossier local (par exemple D:\modele).
3. Vérifiez l’intégrité de vos fichiers via la commande Get-FileHash D:\modele\*.gguf en comparant avec l’empreinte SHA256 indiquée sur Hugging Face.
4. Préparez un fichier texte de test en encodage UTF-8 (plusieurs milliers de mots).
5. Exécutez le script suivant dans PowerShell pour collecter automatiquement débits, tailles et perplexités dans un fichier CSV.

# porownaj-kwantyzacje.ps1 - comparaison de quantifications GGUF sous llama.cpp
# Usage:
#   powershell -ExecutionPolicy Bypass -File .\porownaj-kwantyzacje.ps1 -Modele D:\modele -Llama D:\llama-cuda -Tekst D:\texte.txt
param(
    [Parameter(Mandatory = $true)][string]$Modele,
    [Parameter(Mandatory = $true)][string]$Llama,
    [string]$Tekst = "",
    [int]$Warstwy = 99
)
$ErrorActionPreference = "Continue"
$bench = Join-Path $Llama "llama-bench.exe"
$ppl = Join-Path $Llama "llama-perplexity.exe"
if (-not (Test-Path $bench)) { throw "Outil $bench introuvable" }
$pliki = Get-ChildItem -Path $Modele -Filter *.gguf | Sort-Object Length -Descending
if ($pliki.Count -eq 0) { throw "Aucun fichier .gguf dans $Modele" }
if ($Tekst -and -not (Test-Path $Tekst)) { throw "Fichier texte $Tekst introuvable" }

$wyniki = @()
foreach ($p in $pliki) {
    Write-Host "== $($p.Name)" -ForegroundColor Cyan
    $w = [ordered]@{ Plik = $p.Name; GB = [math]::Round($p.Length / 1e9, 2); Prompt_tok_s = ""; Generowanie_tok_s = ""; Perplexity = "" }

    $json = & $bench -m $p.FullName -p 512 -n 128 -r 3 -ngl $Warstwy -o json 2>$null | Out-String
    $start = $json.IndexOf("[")
    if ($start -ge 0) {
        foreach ($e in ($json.Substring($start) | ConvertFrom-Json)) {
            if ($e.n_prompt -gt 0) { $w.Prompt_tok_s = [math]::Round($e.avg_ts, 1) } else { $w.Generowanie_tok_s = [math]::Round($e.avg_ts, 1) }
        }
    }

    if ($Tekst) {
        $log = & $ppl -m $p.FullName -f $Tekst -c 2048 -ngl $Warstwy 2>&1 | Out-String
        $m = [regex]::Match($log, "Final estimate: PPL = ([\d.]+)")
        if ($m.Success) { $w.Perplexity = [double]::Parse($m.Groups[1].Value, [Globalization.CultureInfo]::InvariantCulture) }
    }
    $wyniki += [pscustomobject]$w
}
$wyniki | Format-Table -AutoSize
$wyniki | Export-Csv -Path ".\resultats_gguf.csv" -NoTypeInformation -Encoding utf8

Si vous utilisez l’écosystème Ollama, la commande ollama run SpeakLeash/bielik-11b-v3.0-instruct:Q4_K_M télécharge exactement le même binaire que le fichier publié sur Hugging Face (vérification effectuée via l’empreinte sha256 de la couche modèle stockée dans le registre Ollama).

Foire aux questions

Sources

• Spécification technique du format GGUF (ggml-org)
• Documentation llama-quantize : types et bits par poids
• Pull Request llama.cpp 1684 : implémentation des k-quants
• Dépôt Hugging Face speakleash/Bielik-11B-v3.0-Instruct-GGUF
• Dépôt Hugging Face speakleash/Bielik-4.5B-v3.0-Instruct-GGUF
• Dépôt Hugging Face speakleash/Bielik-1.5B-v3.0-Instruct-GGUF
• Bibliothèque Ollama : SpeakLeash/bielik-11b-v3.0-instruct
• Notes de version de llama.cpp sur GitHub

Vérifié le 17 octobre 2026.

// lire la suiteMidjourney Style Creator : créer son propre style visuel IAGuidesGumloop : créer un agent IA et automatiser sans coderGuidesSearch Console cache vos pages à fort potentiel SEOGuides

Kinetyra