GGUF e quantizzazione: Q4_K_M vs Q6_K vs Q8_0, testati

👁 115 letture

Il formato GGUF e la quantizzazione GGUF consentono di eseguire modelli linguistici in locale riducendo i requisiti hardware, dove una variante come Q4_K_M rappresenta spesso il miglior compromesso tra memoria e precisione. In questa guida analizzo il comportamento reale dei vari livelli di compressione, misurati sul mio banco di prova con RTX 4090: puoi approfondire i principi base dei modelli in locale nel mio hub sull’intelligenza artificiale locale.

Cosa scegliere in sintesi

• Q4_K_M - Il livello di compressione minimo consigliabile in cui la qualita del testo non subisce cali evidenti. Bielik 11B in Q4_K_M pesa 6,72 GB e azzecca lo stesso token piu probabile della versione Q8_0 nel 94,1% dei casi.
• Q5_K_M e Q6_K - Se la VRAM a bordo lo permette, offrono l’equilibrio ideale: lo scarto di perplexity rispetto a Q8_0 rientra nei limiti dell’errore di misurazione.
• Q8_0 - Praticamente sovrapponibile alla versione non compressa (96,7% di corrispondenza con F16 su Bielik 1.5B), ma richiede quasi il doppio della memoria rispetto a Q4_K_M ed e piu lento in generazione.
• Q3_K_M e inferiori - Da usare esclusivamente come ripiego estremo su modelli molto grandi. La variante 1.5B in Q2_K smette di comprendere le richieste (0 risposte corrette su 12).
• Un modello piu grande in quantizzazione Q4 offre prestazioni migliori rispetto a uno piu piccolo in Q8: Bielik 11B in Q3_K_M (5,40 GB) ha risolto 11 compiti su 12, contro i 5 su 12 di Bielik 4.5B in Q8_0 (5,06 GB).

Cos’e il formato GGUF

GGUF e un formato binario introdotto dal team ggml-org (gli sviluppatori di llama.cpp) nell’agosto 2023. Un singolo archivio include sia i pesi del modello sia tutti i metadati indispensabili all’esecuzione: architettura, configurazione del tokenizer, template della chat e contesto massimo utilizzabile. Questo approccio unificato ti consente di usare lo stesso identico file sia tramite interfaccia a riga di comando con llama.cpp, sia integrato in soluzioni ad alte prestazioni descritte nel mio confronto tra Ollama e LM Studio oppure configurato con un’interfaccia completa tramite Open WebUI e Ollama.

La convenzione ufficiale adotta la nomenclatura strutturata Nome-Dimensione-Addestramento-Versione-Codifica.gguf. Nel file denominato Bielik-11B-v3.0-Instruct.Q4_K_M.gguf, la stringa conclusiva individua con precisione il metodo di quantizzazione impiegato.

La quantizzazione GGUF spiegata: differenze tra Q4_K_M, Q6_K e Q8_0

La quantizzazione serve a codificare i pesi del modello impiegando meno bit. Mentre un modello nativo conserva ogni peso su 16 bit (F16 o BF16), la variante Q8_0 ne utilizza circa 8,5 e un formato come Q4_K_M scende a meno di 5 bit per peso. Cio riduce l’impronta su disco e consente al modello di entrare interamente nella memoria della scheda video, aumentando la velocita visto che la generazione locale e limitata principalmente dalla larghezza di banda della memoria.

I valori di bit per peso derivano dalla documentazione di llama-quantize basata su Llama 3.1 8B. La lettera K identifica i cosiddetti k-quants, dove i pesi sono suddivisi in superblocchi da 256 elementi le cui scale vengono a loro volta compresse. Le terminazioni _S, _M, _L indicano approcci a precisione mista: in Q4_K_M i tensori strutturalmente piu importanti beneficiano di una precisione piu alta a 6 bit, mentre in Q4_K_S l’intero set viene uniformato a 4 bit. Le varianti IQ gestiscono distribuzioni non lineari sotto i 4 bit tramite matrici di calibrazione (imatrix), che assegnano minore tolleranza di errore ai tensori statisticamente piu rilevanti.

Test su RTX 4090: misurazioni su Bielik 1.5B e 11B

Ho effettuato i test il 17 ottobre 2026 utilizzando la mia workstation con GPU NVIDIA RTX 4090 24 GB, CPU Intel Core i9-14900KF, 64 GB di RAM e Windows 11, sfruttando llama.cpp compilato con CUDA caricando tutti i layer del modello nella memoria grafica.

• Origine dei file: build ufficiali F16 e Q8_0 di Bielik 1.5B v3.0 e versioni Q8_0 di 4.5B e 11B provenienti dall’account Hugging Face di speakleash (con hash sha256 verificati). I restanti formati intermedi sono stati creati direttamente tramite il binario llama-quantize (per il modello 1.5B partendo dal file sorgente F16, per le varianti 4.5B e 11B partendo dalla base Q8_0 per rispettare il limite di download di 5 GB). Per il modello 11B ho aggiunto il file ufficiale Q4_K_M scaricato tramite Ollama.
• Perplexity e aderenza: misurazioni eseguite tramite il tool llama-perplexity a finestra di contesto 2048 su un testo in prosa (circa 7.900 parole tratte da Wolne Lektury). La percentuale di aderenza indica quanti token scelti come piu probabili corrispondono a quelli della versione di riferimento non quantizzata.
• Velocita di calcolo: misurata con llama-bench simulando la generazione di 128 token su 3 ripetizioni consecutive.
• Occupazione VRAM: letta tramite comando nvidia-smi con llama-server attivo su contesto fissato a 4096 token.
• Batteria di test: 12 problemi sintetici a risposta secca verificabile impostando la temperatura di generazione a 0.

Bielik 1.5B: il comportamento da F16 a Q2_K

Un’architettura da 1,5 miliardi di parametri risulta strutturalmente troppo limitata per compiti complessi a prescindere dal livello di quantizzazione: gia nella variante integrale F16 produce allucinazioni letterarie di base, mentre scendendo a Q2_K finisce per entrare in cicli ricorsivi infiniti.

Bielik 11B: il test di efficienza da Q8_0 a Q3_K_M

I dati di riga per Q4_K_M nella seconda tabella fanno riferimento alla release ufficiale scaricata. La mia build locale Q4_K_M ricavata da Q8_0 possiede una firma sha256 diversa ma ha restituito valori equivalenti nei test (109,1 tok/s e 10/12 compiti completati).

Conclusioni tecniche emerse dai dati

• Fino al profilo Q5_K_M la fluttuazione di perplexity e trascurabile e inferiore alla soglia di errore sperimentale (circa ±0,10 sul modello 11B). La prima degradazione osservabile si nota in Q4_K_M sui modelli piccoli e in Q3_K_M su quelli piu estesi.
• All’aumentare dei parametri dell’architettura la resistenza alla compressione migliora nettamente: il formato Q4_K_M sul modello 11B trattiene il 94,1% dell’accordo con la base, mentre sull’1.5B si ferma all’83,6% e sul 4.5B tocca l’82,7% rispetto a Q8_0.
• L’adozione di un profilo imatrix garantisce vantaggi tangibili a parita di peso: la versione Q4_K_M calibrata tramite matrice mantiene le stesse dimensioni fisiche migliorando la concordanza dal basale 83,6% fino all’88,1%.
• I compiti logici a risposta secca non evidenziano disparita nette sul modello 11B (fluttuando casualmente tra 9 e 11 su 12 a causa della sintassi delle risposte). I valori di aderenza e perplexity sono indici analitici molto piu affidabili.
• I punteggi di perplexity non vanno incrociati direttamente tra modelli 1.5B e 11B, poiche i rispettivi tokenizer segmentano lo stesso estratto di lettura in volumi differenti di token (14.767 contro 23.760 token).

Cosa scegliere in base alla VRAM: 8, 12, 16 e 24 GB

Le misurazioni di memoria indicate considerano il solo modello allocato in llama-server. Per la gestione dell’ambiente grafico di Windows 11 e delle applicazioni in background e necessario mettere in conto un consumo fisso di altri 1-2 GB di VRAM:

• 8 GB di VRAM: La scelta migliore e orientarsi su Bielik 11B in versione Q3_K_M (richiede 6,3 GB su contesto a 4096 token) oppure Bielik 4.5B in Q8_0 (5,3 GB). Il file 11B in Q4_K_M tocca 7,5 GB, risultando troppo al limite se si considerano i processi di sistema.
• 12 GB di VRAM: Permette di utilizzare comodamente Bielik 11B in formato Q4_K_M oppure Q5_K_M (tra 7,5 e 8,6 GB di carico) conservando margine sufficiente per espandere il contesto operativo.
• 16 GB di VRAM: Consente di eseguire Bielik 11B in variante Q6_K (9,7 GB) o in Q4_K_M sfruttando l’intera finestra di contesto a 32.768 token (13,0 GB complessivi).
• 24 GB di VRAM: Capacita adatta per gestire Bielik 11B in versione Q8_0 anche a 32.768 token di contesto (17,7 GB) oppure per ospitare modelli ancora piu strutturati, come descritto nelle mie prove con Gemma 4 31B su RTX 4090. Se valuti soluzioni hardware specifiche puoi consultare anche la mia analisi su costi reali tra modelli locali e API.

Come confrontare le quantizzazioni in autonomia

1. Scarica i binari ufficiali di llama.cpp da GitHub (per GPU NVIDIA preleva la release predisposta per CUDA) ed estraili in una cartella a tua scelta, come D:\llama-cuda.
2. Scarica due o tre varianti quantizzate dello stesso modello dal repository ufficiale posizionandole nella stessa cartella, ad esempio con il comando hf download speakleash/Bielik-11B-v3.0-Instruct-GGUF Bielik-11B-v3.0-Instruct.Q4_K_M.gguf --local-dir D:\modele.
3. Verifica l’integrita dei file scaricati eseguendo Get-FileHash D:\modele\*.gguf e controlla che l’impronta SHA256 coincida con quella registrata su Hugging Face.
4. Prepara un file di testo in formato .txt con codifica UTF-8 lungo alcune migliaia di parole non appartenenti ai dataset piu comuni di addestramento.
5. Esegui lo script PowerShell riportato di seguito per ottenere un riepilogo tabellare esportato anche in formato CSV contenente peso, velocita di elaborazione e perplexity.

Script di test: porownaj-kwantyzacje.ps1

Ho convalidato questo script il 17 ottobre testandolo su una cartella pulita contenente due build di Bielik 1.5B. Quando eseguito interamente su CPU impostando il parametro -Warstwy 0, la versione Q4_K_M ha registrato una perplexity di 54,31, contro il punteggio di 54,27 ottenuto nei test su GPU.

# porownaj-kwantyzacje.ps1 - porównanie kwantyzacji GGUF w llama.cpp (
# Dla każdego pliku .gguf w folderze: rozmiar, szybkość (llama-bench: prompt 512 i generowanie 128 tokenów, 3 powtórzenia)
# i opcjonalnie perplexity na Twoim pliku tekstowym (llama-perplexity, kontekst 2048). Wynik: tabela + plik CSV.
#
# Użycie (PowerShell):
#   powershell -ExecutionPolicy Bypass -File .\porownaj-kwantyzacje.ps1 -Modele D:\modele -Llama D:\llama-cuda -Tekst D:\tekst.txt
# -Modele  folder z plikami .gguf (różne kwantyzacje tego samego modelu)
# -Llama   folder z llama-bench.exe i llama-perplexity.exe (paczka llama.cpp z GitHuba ggml-org, wersja CUDA dla kart NVIDIA)
# -Tekst   (opcjonalnie) plik .txt w UTF-8, najlepiej 5-20 tysięcy słów po polsku; bez niego tylko szybkość
# -Warstwy (opcjonalnie) ile warstw na GPU, domyślnie 99 = wszystkie
param(
    [Parameter(Mandatory = $true)][string]$Modele,
    [Parameter(Mandatory = $true)][string]$Llama,
    [string]$Tekst = "",
    [int]$Warstwy = 99
)
$ErrorActionPreference = "Continue"   # llama.cpp pisze logi na stderr - "Stop" w PowerShell 5.1 przerwałby skrypt
$bench = Join-Path $Llama "llama-bench.exe"
$ppl = Join-Path $Llama "llama-perplexity.exe"
if (-not (Test-Path $bench)) { throw "Nie ma $bench - podaj folder z rozpakowanym llama.cpp w -Llama" }
$pliki = Get-ChildItem -Path $Modele -Filter *.gguf | Sort-Object Length -Descending
if ($pliki.Count -eq 0) { throw "W folderze $Modele nie ma plików .gguf" }
if ($Tekst -and -not (Test-Path $Tekst)) { throw "Nie ma pliku tekstowego $Tekst" }

$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 = "" }

    # 1. Szybkość: llama-bench zwraca JSON (jedna pozycja dla pp512, druga dla tg128)
    $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) }
        }
    } else { Write-Host "llama-bench nie zwrócił wyniku (za mało VRAM? spróbuj -Warstwy 20)" -ForegroundColor Yellow }

    # 2. Perplexity (im niżej, tym lepiej; porównuj tylko pliki tego samego modelu na tym samym tekście)
    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) }
        else { Write-Host "llama-perplexity: brak wyniku (tekst za krótki? potrzeba min. ok. 4100 tokenów)" -ForegroundColor Yellow }
    }
    $wyniki += [pscustomobject]$w
    Writ

Se adoperi l’ecosistema Ollama non e richiesta alcuna conversione manuale: eseguendo il comando ollama run SpeakLeash/bielik-11b-v3.0-instruct:Q4_K_M scarichi il medesimo file ospitato su Hugging Face, come ho potuto verificare confrontando gli hash sha256 dei layer estratti dal registro locale.

Domande frequenti

Fonti

• Specifiche ufficiali del formato GGUF sul repository ggml-org
• Documentazione llama-quantize: tipologie di quantizzazione e bit per peso
• Pull Request 1684 di llama.cpp: implementazione di k-quants e varianti miste
• Repository Hugging Face ufficiale: speakleash/Bielik-11B-v3.0-Instruct-GGUF
• Repository Hugging Face ufficiale: speakleash/Bielik-4.5B-v3.0-Instruct-GGUF
• Repository Hugging Face ufficiale: speakleash/Bielik-1.5B-v3.0-Instruct-GGUF
• Registro modelli Ollama: SpeakLeash/bielik-11b-v3.0-instruct
• Elenco release e changelog del progetto llama.cpp
• Misurazioni dirette condotte il 17 ottobre 2026: setup RTX 4090, llama.cpp CUDA build 11194 su 17 varianti GGUF.

Verificato il 17 ottobre 2026.

// continua a leggereGPT-6 Luna: il modello OpenAI più economico testato per 0,0024 USDMagazineAI per la revisione della letteratura: Elicit, Consensus e SciteGuideCopilot gratis: cosa offre e quando serve un abbonamentoGuide

Kinetyra