Guía completa de cuantización 4-bit para Gemma 4 31B: rendimiento y calidad en pruebas reales (2026)

Gemma 4 31B es actualmente el modelo de lenguaje de código abierto y arquitectura densa más potente de Google, pero en precisión completa requiere 62 GB de memoria RAM — algo completamente inaccesible para la mayoría de los ordenadores personales.

La buena noticia es que con cuantización puedes reducir ese requisito a unos 15 GB, lo que permite ejecutar localmente el modelo en un MacBook con 16 GB o en una tarjeta RTX 4060. La mala noticia: comprimir siempre implica cierta pérdida de calidad. La pregunta real es cuánto se pierde y si esa pérdida es aceptable para tu caso de uso.

Esta guía te muestra los datos reales: qué diferencia hay entre los niveles 4-bit, 8-bit y FP16, en qué situaciones conviene cada uno y cómo ponerlo en marcha. Sin teoría innecesaria — solo datos para tomar decisiones.

¿Qué es la cuantización? Explicado en 30 segundos

La cuantización consiste en comprimir los parámetros del modelo desde números de alta precisión (por ejemplo, flotantes de 16 bits) a números de menor precisión (por ejemplo, enteros de 4 bits).

Una analogía sencilla: el modelo original almacena "3.14159265", pero tras la cuantización ese valor pasa a ser "3.1". Se pierde algo de información, pero el espacio de almacenamiento se reduce considerablemente.

En la práctica, el impacto más directo se nota en dos métricas: memoria ocupada y velocidad de inferencia. A menor precisión, menor memoria y mayor velocidad, aunque la calidad de las respuestas puede verse afectada. La clave está en encontrar ese punto de equilibrio donde el rendimiento sigue siendo suficiente.

Comparativa real: 4-bit vs 8-bit vs FP16

Hemos probado Gemma 4 31B con tres niveles de cuantización en dos configuraciones de hardware distintas. Las pruebas se ejecutaron con llama.cpp usando los formatos Q4_K_M (4-bit), Q8_0 (8-bit) y F16 (FP16).

Hardware y memoria requerida

Velocidad de inferencia (tok/s)

El modo 4-bit es entre 3 y 4 veces más rápido que FP16, y casi el doble que 8-bit. Para uso interactivo, 35+ tok/s es una velocidad en la que la generación supera con creces la velocidad de lectura.

Comparativa de calidad (datos clave)

Conclusión: 8-bit es prácticamente sin pérdidas — en el uso diario no se aprecia diferencia respecto a FP16. El modo 4-bit es suficiente para conversación general, generación de código sencilla y resumen de textos, pero muestra una caída clara en razonamiento complejo, llamadas a herramientas y tareas matemáticas.

Ejemplos reales de degradación de calidad

Tarea de generación de código: "Implementa en Python un pool de peticiones HTTP con soporte para concurrencia"

• 8-bit: Genera una solución completa con asyncio + aiohttp, incluyendo manejo de excepciones y límite del pool de conexiones. Lista para usar directamente.
• 4-bit: Genera el esqueleto básico, pero omite el límite del pool de conexiones y solo envuelve la capa más externa con gestión de errores. Requiere completar manualmente.

Tarea de razonamiento: "Si A es más alto que B, B más alto que C, C más bajo que D, y D más alto que E, ¿quién es más alto, B o E?"

• 8-bit: Razona correctamente que "no se puede determinar, porque la relación entre C y D invierte la cadena".
• 4-bit: Responde directamente "B es más alto que E", saltándose la inversión en el par C→D.

Árbol de decisión de 10 segundos: ¿qué nivel de cuantización necesitas?

¿Cuánta memoria tienes disponible?
├── < 20 GB (MacBook 16GB / RTX 4060)
│   └── 4-bit obligatorio (Q4_K_M)
│       Apto para: conversación, código sencillo, resumen de textos
│       No recomendado: llamadas a herramientas en producción, matemáticas complejas
│
├── 20-40 GB (Mac M1 Pro 32GB / RTX 4090)
│   └── Recomendado: 8-bit (Q8_0)
│       Casi sin pérdidas, cubre todos los casos de uso
│
└── > 40 GB (Mac M2 Max 64GB / doble GPU)
    └── Recomendado: FP16 (F16)
        Precisión completa, sin compromisos

Si no estás seguro de qué puede ejecutar tu hardware, consulta primero esta guía: ¿Tu ordenador puede ejecutar Gemma 4? Guía completa de requisitos de hardware.

Tutorial de cuantización: dos caminos posibles

Camino 1: Ollama (el más sencillo, recomendado para principiantes)

Ollama incluye modelos ya cuantizados. Un solo comando es suficiente:

# Descargar la versión 4-bit (por defecto)
ollama pull gemma4:31b

# O especificar 8-bit
ollama pull gemma4:31b-q8_0

# Ejecutar
ollama run gemma4:31b

Ollama selecciona automáticamente la estrategia óptima de offload a GPU según tu hardware. Si solo quieres poner el modelo en marcha sin complicaciones, esta es la mejor opción.

Para el tutorial completo de despliegue con Ollama, consulta: Cómo ejecutar Gemma 4 localmente con Ollama: guía paso a paso.

Camino 2: llama.cpp (control total)

Si prefieres elegir el formato de cuantización, ajustar parámetros y exprimir el rendimiento al máximo, usa llama.cpp:

Paso 1: Descargar el modelo original

# Instalar huggingface-cli (si no lo tienes)
pip install huggingface-hub

# Descargar Gemma 4 31B
huggingface-cli download google/gemma-4-31b-it --local-dir ./gemma-4-31b

Paso 2: Convertir al formato GGUF

# Compilar llama.cpp (si no lo tienes)
git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp && cmake -B build && cmake --build build -j

# Convertir el modelo
python convert_hf_to_gguf.py ../gemma-4-31b --outfile gemma-4-31b-f16.gguf

Paso 3: Cuantizar

# Cuantización 4-bit (Q4_K_M recomendado: mejor equilibrio entre calidad y compresión)
./build/bin/llama-quantize gemma-4-31b-f16.gguf gemma-4-31b-Q4_K_M.gguf Q4_K_M

# Otros formatos disponibles:
# Q4_K_S — más compacto que Q4_K_M, calidad algo inferior
# Q5_K_M — 5-bit, punto intermedio entre 4-bit y 8-bit
# Q8_0   — 8-bit, prácticamente sin pérdidas

Paso 4: Ejecutar la inferencia

./build/bin/llama-cli \
  -m gemma-4-31b-Q4_K_M.gguf \
  -ngl 40 \
  -c 8192 \
  -p "Eres un asistente de programación experto." \
  --interactive

Descripción de los parámetros:

• -ngl 40: capas con offload a GPU; ajusta según tu VRAM (para tarjetas de 12 GB se recomienda 28-32)
• -c 8192: longitud del contexto
• --interactive: modo interactivo

¿Quieres conocer más detalles sobre el formato GGUF? Lee esta guía: Guía del formato GGUF de Gemma 4: explicación y descarga.

Resolución de problemas comunes

"Error: mmap failed" o "out of memory"

El problema es falta de memoria. Dos soluciones posibles:

1. Usar un formato de cuantización más agresivo (de Q4_K_M a Q4_K_S, o prueba Q3_K_M)
2. Reducir las capas con offload a GPU (bajar el valor de -ngl)

Velocidad de inferencia muy baja (< 10 tok/s)

Verifica que se está usando aceleración por GPU. Los usuarios de Mac deben confirmar que llama.cpp se compiló con soporte Metal (cmake -B build -DLLAMA_METAL=ON); los usuarios de NVIDIA, que se habilitó CUDA (cmake -B build -DLLAMA_CUDA=ON).

El modelo 4-bit falla frecuentemente en llamadas a herramientas

Es una limitación conocida de la cuantización 4-bit. Usuarios de Reddit reportan un ~15% de errores de formato en function calling con Gemma 4 31B Q4_K_M. Si tu caso de uso depende de llamadas a herramientas, lo más recomendable es subir a 8-bit. Para optimización avanzada de function calling, consulta: Guía completa de Function Calling con Gemma 4.

Para más problemas frecuentes, visita: Solución de problemas comunes de Gemma 4.

Avanzado: autoajuste de parámetros en llama.cpp

Un desarrollador en Reddit compartió un script de autoajuste que hace que el propio LLM pruebe diferentes combinaciones de parámetros de compilación en llama.cpp, logrando mejoras de hasta el 54% en velocidad de inferencia. El enfoque principal es automatizar el benchmark:

1. Iterar sobre distintas combinaciones de número de hilos, batch size y capas GPU
2. Ejecutar cada combinación 3 veces y calcular el promedio
3. Devolver los parámetros óptimos

Si buscas el máximo rendimiento posible, este método merece la pena. Los detalles de implementación se cubrirán en un artículo posterior.

Resumen: ¿cuál elegir?

Si estás dudando entre Gemma 4 y otros modelos, consulta Guía para elegir entre Gemma 4 E2B, E4B, 26B y 31B y Comparativa completa: Gemma 4 vs Qwen 3.5.

Los usuarios de Mac pueden consultar también Guía de optimización de rendimiento de Gemma 4 en Mac, y los usuarios de NVIDIA, Guía de despliegue de Gemma 4 en NVIDIA RTX.

Preguntas frecuentes

P1: ¿La cuantización 4-bit de Gemma 4 31B supone una pérdida de calidad importante?

Depende del caso de uso. En conversación general y tareas sencillas (resumen de texto, traducción, código básico) la diferencia es casi imperceptible. Sin embargo, en razonamiento complejo, demostraciones matemáticas y llamadas a herramientas la caída es notable — el MMLU pasa del 99,2% (8-bit) al 97,1% (4-bit), y los errores en function calling aumentan en torno al 15%.

P2: ¿Debería usar 4-bit u 8-bit en un Mac M2 Max con 64 GB?

8-bit, sin duda. Con 64 GB de memoria, ejecutar 8-bit (que requiere unos 36 GB) no supone ningún problema. No tiene sentido sacrificar calidad. El modo 4-bit es para máquinas con 16-32 GB.

P3: ¿Cuánto más rápido es 4-bit respecto a 8-bit?

En las pruebas, entre un 60 y un 90% más rápido. En un Mac M2 Max, 8-bit rinde aproximadamente 20 tok/s frente a los ~40 tok/s de 4-bit. La diferencia práctica es la que hay entre "esperar un momento" y "respuesta casi inmediata".

P4: ¿Se puede hacer fine-tuning sobre un modelo cuantizado?

No directamente sobre el archivo GGUF. El proceso correcto es: hacer fine-tuning con QLoRA sobre el modelo original en formato HuggingFace, y luego cuantizar el resultado. Consulta la sección de QLoRA en la Guía de fine-tuning de Gemma 4.

P5: ¿Qué diferencia hay entre Q4_K_M y Q4_K_S?

Q4_K_M (Medium) conserva mayor precisión en las capas de atención que Q4_K_S (Small). El archivo es aproximadamente un 10% más grande, pero la calidad es notablemente mejor. A menos que esos 1-2 GB extras sean realmente decisivos, elige Q4_K_M.

P6: ¿Existen alternativas más sencillas a llama.cpp para cuantizar?

Sí. Ollama es la más fácil: ollama pull gemma4:31b y listo, con cuantización Q4_K_M integrada. LM Studio ofrece interfaz gráfica, ideal para quienes prefieren evitar la línea de comandos. Si tienes GPU NVIDIA y priorizas la velocidad, la cuantización GPTQ (requiere CUDA) ofrece mayor rendimiento de inferencia.

P7: Entre Gemma 4 26B (MoE) y 31B (Dense) cuantizados, ¿cuál es mejor opción?

Son arquitecturas diferentes. El 26B es MoE (Mixture of Experts): durante la inferencia solo activa una parte de los parámetros, por lo que sus requisitos de memoria originales ya son menores que los del 31B. Si tu memoria es limitada, el 26B puede ser la mejor elección sin necesidad de cuantización agresiva. Para una comparativa detallada, consulta Gemma 4 26B vs 31B: diferencias de arquitectura y cuándo elegir cada uno.

Los datos de este artículo están basados en pruebas reales de la comunidad recopiladas en abril de 2026 (Reddit r/LocalLLaMA) y en benchmarks oficiales de llama.cpp. Los resultados pueden variar ligeramente según el hardware y la versión del software utilizada.