GGUF y cuantización: Q4_K_M vs Q6_K vs Q8_0, medidos

👁 113 lecturas

El formato GGUF permite comprimir modelos de lenguaje para ejecutarlos en hardware doméstico mediante diferentes niveles de cuantización como Q4_K_M, Q6_K o Q8_0. La cuantización GGUF es el método que decide cuántos bits asignamos a cada peso: en mis pruebas reales, Q4_K_M representa el mínimo razonable para no degradar el texto, mientras que Q5_K_M y Q6_K resultan prácticamente indistinguibles del original y Q8_0 solo aporta ventaja si dispones de memoria de sobra. Tienes una visión completa del ecosistema en la guía de IA local de este blog.

Qué cuantización GGUF elegir: conclusiones directas

• Q4_K_M: el archivo más pequeño con el que el texto no sufre de forma perceptible. En el modelo de 11B ocupa 6,72 GB y coincide en el token más probable con Q8_0 en el 94,1% de los casos.
• Q5_K_M y Q6_K: si tu tarjeta gráfica lo permite, es el mejor equilibrio. La diferencia de perplejidad respecto a Q8_0 entra dentro del margen de error de la medición.
• Q8_0: prácticamente idéntico al original en coma flotante (96,7% de coincidencia con F16 en 1.5B), pero duplica el tamaño de Q4_K_M y reduce los tokens por segundo.
• Q3_K_M e inferiores: solo como recurso extremo en arquitecturas muy grandes. En modelos pequeños como 1.5B en Q2_K, las respuestas pierden todo el sentido (0 aciertos de 12 pruebas).
• Un modelo grande en Q4 supera a un modelo pequeño en Q8: el de 11B en Q3_K_M (5,40 GB) resolvió 11 de 12 tareas, mientras que el de 4.5B en Q8_0 (5,06 GB) solo acertó 5.

Qué es GGUF

GGUF es un formato binario desarrollado por el equipo de ggml-org (los creadores de llama.cpp) introducido en agosto de 2023. Su gran ventaja técnica reside en que empaqueta en un único archivo tanto los tensores con los pesos del modelo como todos sus metadatos críticos: arquitectura, configuración del tokenizador, plantilla de chat y límite de contexto. Esto hace posible cargar el mismo binario en llama.cpp, en LM Studio o en Ollama, e interactuar con interfaces como Open WebUI.

La especificación define una nomenclatura estandarizada: Nombre-Tamaño-Ajuste-Versión-Codificación.gguf. De este modo, en Bielik-11B-v3.0-Instruct.Q4_K_M.gguf, la parte final identifica con exactitud el algoritmo de cuantización aplicado.

Qué significan Q4_K_M, Q6_K, Q8_0, F16 e IQ

Cuantizar un modelo consiste en representar sus pesos matemáticos con menos bits. En su estado sin comprimir, cada peso suele ocupar 16 bits (F16 o BF16). Con Q8_0 se pasa a unos 8,5 bits por peso, y con Q4_K_M baja a menos de 5 bits. El archivo resultante ocupa menos espacio en disco, encaja en GPUs con menos VRAM y genera texto más rápido al verse menos limitado por el ancho de banda de la memoria, a cambio de introducir una ligera desviación numérica en cada peso.

Los valores de bits por peso proceden de la documentación de llama-quantize (medidos sobre Llama 3.1 8B). La K hace referencia a los k-quants, donde los pesos se agrupan en superbloques de 256 elementos y las propias escalas se cuantizan para ahorrar espacio. Los sufijos _S, _M y _L indican esquemas mixtos: en Q4_K_M, las capas más críticas reciben mayor precisión (Q6_K), mientras que en Q4_K_S se comprime todo a Q4_K. Los IQ son cuantizaciones con rejillas no lineales diseñadas para operar por debajo de 4 bits. Por último, una imatrix (matriz de importancia) analiza un texto de calibración para detectar qué pesos específicos son más sensibles y preservarlos con menor error.

Mediciones en mi RTX 4090

Realicé las pruebas el 17 de octubre de 2026 en mi equipo con una tarjeta NVIDIA GeForce RTX 4090 de 24 GB, procesador Intel Core i9-14900KF, 64 GB de memoria RAM y Windows 11. Ejecuté llama.cpp con aceleración CUDA completa, manteniendo el modelo íntegramente en la VRAM de la tarjeta.

• Modelos analizados: descargué los binarios oficiales F16 y Q8_0 de Bielik 1.5B v3.0, así como los Q8_0 de 4.5B y 11B desde el perfil de speakleash en Hugging Face, validando sus sumas sha256. El resto de variantes intermedias las generé mediante llama-quantize (para 1.5B partiendo de F16; para 4.5B y 11B a partir de Q8_0). En el caso de 11B sumé el Q4_K_M oficial que ya tenía configurado en Ollama.
• Perplejidad y coincidencia: empleé llama-perplexity con un contexto de 2048 sobre un texto literario extenso (aproximadamente 7.900 palabras en dominio público). La coincidencia refleja el porcentaje de tokens en los que la variante elige exactamente la misma palabra más probable que el archivo de referencia (F16 en 1.5B; Q8_0 en 4.5B y 11B).
• Rendimiento: medido con llama-bench simulando una generación continua de 128 tokens, con 3 repeticiones por prueba.
• Uso de VRAM: incremento reportado por nvidia-smi con llama-server en ejecución bajo un contexto de 4096 tokens.
• Pruebas de tareas: batería de 12 preguntas cortas de respuesta unívoca (declinaciones, ortografía, porcentajes, salida estructurada en JSON y comprensión) evaluadas con temperatura 0.

Resultados con el modelo de 1.5B (de F16 a Q2_K)

Un modelo de 1.5B resulta demasiado modesto para tareas de razonamiento riguroso al margen de cómo esté cuantizado: en F16 cometió fallos factuales básicos de atribución de autoría. No obstante, al bajar a Q3_K_M las alucinaciones se dispararon por completo, y en Q2_K entró en bucles repetitivos respondiendo únicamente números incoherentes.

Resultados con el modelo de 11B (de Q8_0 a Q3_K_M)

La fila Q4_K_M oficial corresponde al archivo descargado. Mi versión cuantizada manualmente desde Q8_0 arrojó el mismo peso exacto y cifras operativas equivalentes (109,1 tok/s y 10/12 aciertos).

De estos datos se extraen patrones claros:

• Hasta Q5_K_M, las diferencias de perplejidad caen por debajo del margen de error habitual (±0,10 en 11B). La primera caída detectable de fidelidad aparece en Q4_K_M con modelos pequeños y en Q3_K_M con modelos mayores.
• Cuanto mayor es el volumen de parámetros, mejor tolera la compresión. Q4_K_M retuvo un 94,1% de fidelidad de tokens en 11B, frente al 83,6% en 1.5B y el 82,7% en 4.5B.
• Aplicar imatrix aporta mejoras gratuitas: Q4_K_M con calibración retuvo exactamente el mismo peso en disco pero subió su coincidencia de tokens del 83,6% al 88,1%.
• Las pruebas sintéticas de 12 preguntas muestran fluctuaciones estadísticas menores (oscilando entre 9 y 11 aciertos), por lo que la perplejidad y el análisis token a token resultan mucho más concluyentes.

Qué variante elegir según tu VRAM (8, 12, 16 y 24 GB)

Los consumos de VRAM expuestos reflejan el aislamiento del modelo cargado en llama-server. En un entorno de escritorio con Windows y navegadores web activos, debes reservar entre 1 y 2 GB adicionales para la interfaz gráfica. Si evalúas el impacto económico de tu hardware frente a servidores remotos, puedes leer el desglose sobre coste real de IA local frente a API.

• 8 GB de VRAM: Bielik 11B en Q3_K_M (consume 6,3 GB con contexto 4096) o bien Bielik 4.5B en Q8_0 (5,3 GB). La variante Q4_K_M de 11B exige 7,5 GB, dejando un margen demasiado estrecho.
• 12 GB de VRAM: Bielik 11B en Q4_K_M o Q5_K_M (entre 7,5 y 8,6 GB), lo que otorga margen para ampliar la ventana de contexto sin desbordar la memoria.
• 16 GB de VRAM: Bielik 11B en Q6_K (9,7 GB) o la versión Q4_K_M explotando su ventana máxima de 32.768 tokens (13,0 GB de VRAM).
• 24 GB de VRAM: Bielik 11B en Q8_0 incluso con 32.768 de contexto (17,7 GB) o modelos notablemente superiores, como he comprobado al analizar arquitecturas como Gemma 4 31B en local en Q4_K_M.

Cómo comparar cuantizaciones tú mismo paso a paso

1. Descarga el ejecutable de llama.cpp desde el GitHub de ggml-org (el paquete compilado con soporte CUDA para gráficas NVIDIA) y descomprímelo en una carpeta local, por ejemplo D:\llama-cuda.
2. Descarga 2 o 3 cuantizaciones del modelo que desees analizar a un directorio de trabajo, usando el cliente oficial: hf download speakleash/Bielik-11B-v3.0-Instruct-GGUF Bielik-11B-v3.0-Instruct.Q4_K_M.gguf --local-dir D:\modele.
3. Verifica la integridad de los archivos con PowerShell ejecutando Get-FileHash D:\modele\*.gguf y coteja el valor SHA256 con el que figura en Hugging Face.
4. Prepara un archivo .txt en codificación UTF-8 con varios miles de palabras de un texto que el modelo no haya memorizado previamente durante su entrenamiento.
5. Ejecuta el script automatizado para obtener una tabla comparativa con velocidad, tamaño y perplejidad junto a un informe en CSV.

Script listo para usar: porownaj-kwantyzacje.ps1

Comprobé el funcionamiento del script el 17 de octubre en un directorio limpio con dos cuantizaciones de Bielik 1.5B. Evaluado exclusivamente sobre procesador (-Warstwy 0), Q4_K_M arrojó una perplejidad de 54,31, prácticamente idéntica al 54,27 registrado al computar sobre la GPU en las pruebas principales:

# 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

Si prefieres gestionar tus modelos mediante Ollama no necesitas realizar conversiones manuales: la orden ollama run SpeakLeash/bielik-11b-v3.0-instruct:Q4_K_M descarga exactamente el mismo binario publicado en Hugging Face, como he comprobado revisando el sha256 de las capas en el registro del software.

Preguntas frecuentes

Fuentes

• ggml-org: especificación del formato GGUF
• llama.cpp: documentación de llama-quantize (tipos y bits por peso)
• llama.cpp PR 1684: detalle de k-quants y variantes mixtas _S/_M
• speakleash/Bielik-11B-v3.0-Instruct-GGUF en Hugging Face
• speakleash/Bielik-4.5B-v3.0-Instruct-GGUF en Hugging Face
• speakleash/Bielik-1.5B-v3.0-Instruct-GGUF en Hugging Face
• Ollama: repositorio SpeakLeash/bielik-11b-v3.0-instruct
• llama.cpp: registro de versiones oficiales

Comprobado el 17 de octubre de 2026.

// sigue leyendoOllama vs LM Studio: comparativa y rendimiento medidoRevistaImage to video con IA: de foto a vídeo sin perder la caraRevistaNiños y chatbots: Meta AI tiene más tiempo que los adultosRevista

Kinetyra