Gemma 4 con QAT: Cómo Google logró que modelos de 31B funcionen en tu tarjeta gráfica y en móviles de 1 GB

Los puntos de control oficiales utilizan un esquema W4A16: pesos enteros de 4 bits con activaciones de 16 bits, un group_size de 32 y el formato compressed-tensors . Este es el mismo enfoque que Google documenta para la inferencia con vLLM, donde la combinación de pesos de pocos bits y activaciones de mayor precisión equilibra el ahorro de memoria con la velocidad de procesamiento .

La familia completa de modelos Gemma 4 QAT

Cinco tamaños de modelo recibieron puntos de control QAT, junto con sus respectivos modelos "drafter" para decodificación especulativa. Cada uno está disponible en múltiples formatos (que veremos más abajo), y las huellas de memoria prácticas cambian drásticamente entre la precisión BF16 y la de QAT 4-bit .

Las cifras de memoria provienen del resumen oficial de modelos de Google y de la documentación de Unsloth, y los números de Q4_0 representan el popular nivel de cuantización GGUF . La cifra de ~1 GB para el E2B en formato móvil es el número más llamativo: Google diseñó un esquema personalizado con capas de decodificación de 2 bits y cachés KV optimizados para lograrlo . Para modelos solo texto sin los Per-Layer Embeddings, se informa que la huella puede bajar de 1 GB .

El modelo 26B A4B merece atención especial. Es una arquitectura de Mezcla de Expertos que activa solo unos 3.8 mil millones de parámetros por token, a pesar de tener 26 mil millones en total. Esto significa que ofrece un comportamiento de cómputo más cercano a un modelo de 4B, a la vez que proporciona una calidad de razonamiento comparable a la de un modelo denso mucho mayor . En su forma de 4 bits, cabe en GPUs de 12-16 GB —el tipo de hardware que muchos desarrolladores ya poseen— .

Formatos de despliegue: elige con cuidado

Google lanzó los puntos de control QAT en cuatro formas distintas, y la elección del formato afecta directamente a la calidad :

• Compressed-tensors (W4A16): El formato oficial para la inferencia con vLLM, que utiliza pesos enteros de 4 bits y activaciones de 16 bits con group_size=32. Es la ruta preferida si quieres mantenerte dentro del margen de calidad probado por Google .
• GGUF / Q4_0: El formato más utilizado para llama.cpp, Ollama y herramientas similares del ecosistema. Hay archivos GGUF listos para desplegar disponibles para los cinco tamaños de modelo del lanzamiento QAT .
• Formato optimizado para móviles: Un esquema personalizado que utiliza una mezcla de anchos de cuantización, diseñado explícitamente para hardware móvil. Disponible solo para E2B y E4B, es lo que logra la cifra de 1 GB en el E2B .
• Checkpoints QAT no cuantizados: Pesos de media precisión extraídos de la tubería de QAT. Están destinados a investigadores y desarrolladores que quieran aplicar sus propios flujos de trabajo de cuantización o compilación personalizados .

La advertencia más importante de todo el lanzamiento tiene que ver con la conversión ingenua de formatos. Convertir los pesos QAT directamente a Q4_0 sin el manejo adecuado puede reducir drásticamente la precisión. Según la documentación de Unsloth, una conversión ingenua a Q4_0 del modelo QAT 26B logra solo un 70.2 % de precisión top-1 . Su propio método de cuantización dinámica lo eleva al 85.6 %, una mejora de 15.4 puntos porcentuales, pero la cuestión es que la selección del formato y la metodología de conversión son críticas para preservar la calidad que se supone que el QAT debe ofrecer .

Para la mayoría de los usuarios, los puntos de control oficiales en compressed-tensors o GGUF son el punto de partida más seguro.

¿Qué hardware puede realmente ejecutar estos modelos?

El QAT no solo reduce la memoria: remodela el panorama del hardware para la inferencia de IA local. Modelos que antes requerían GPUs de centros de datos ahora pueden ejecutarse en hardware de consumo e incluso en teléfonos inteligentes.

Smartphones y dispositivos edge: El E2B está diseñado específicamente para móviles. El marco LiteRT-LM de Google puede ejecutar E2B con menos de 1.5 GB de RAM usando cuantización de 2 y 4 bits, y la propia app AI Edge Gallery de Google en la Play Store permite a los usuarios seleccionar y ejecutar E2B o E4B completamente en el dispositivo . Ambos modelos soportan entrada de texto, imagen y audio: la traducción de voz en tiempo real, las preguntas visuales y los asistentes en el dispositivo se vuelven plausibles sin necesidad de conexión a la nube .

GPUs de 8 GB: El punto óptimo para el despliegue de QAT. El E2B (~3.2 GB), el E4B (~5 GB) y el modelo 12B (~7 GB) caben holgadamente en 8 GB de VRAM con cuantización Q4_0 . Esto significa que un portátil de gama media con una RTX 4060 móvil o una vieja RTX 2070 de escritorio ahora puede ejecutar un modelo multimodal unificado con una ventana de contexto de 256K, algo que habría requerido 24 GB o más en precisión de 16 bits.

GPUs de 12–16 GB: El modelo MoE 26B A4B aterriza aquí con aproximadamente 15 GB en formato Q4_0, encajando en tarjetas como la RTX 3080, 4070 Ti o 4080 . Su arquitectura MoE también implica una menor latencia de inferencia que un modelo denso de huella similar, ya que solo una fracción de los parámetros se activa por token .

GPUs de 20–24 GB: El modelo denso de 31B requiere unos 17–18 GB en cuantización Q4_0, poniéndolo al alcance de los propietarios de RTX 3090 y 4090, con algo de margen para la caché KV y el tamaño del lote . En precisión completa de 16 bits, este modelo exige casi 60 GB, totalmente fuera del alcance de las GPUs de consumo. El QAT hace que el modelo Gemma 4 más grande sea genuinamente práctico en una sola tarjeta de consumo de gama alta.

Una comprobación de realidad importante: Las cifras de memoria aquí discutidas representan los tamaños de los pesos del modelo, no el consumo total de VRAM. La sobrecarga en tiempo de ejecución —particularmente la caché KV para ventanas de contexto largas— puede añadir gigabytes adicionales. El modelo de 31B con un contexto de 256K consumirá significativamente más memoria que el tamaño base de los pesos, y los reportes de la comunidad sugieren que las cargas de trabajo intensivas en contexto pueden llevar los requisitos al rango bajo de 20 GB . Siempre hay que presupuestar un margen extra más allá de la huella de pesos Q4_0 indicada.

Preservación de la calidad y límites prácticos

La promesa central del QAT es un rendimiento casi original con una memoria drásticamente reducida, y los benchmarks la respaldan en líneas generales. La propia documentación de Google describe el rendimiento como "casi original", con una reducción de memoria de alrededor del 72 %, y los benchmarks de la comunidad sugieren una pérdida de calidad en el rango del 3–5 % para la cuantización Q4 en comparación con BF16 .

Pero el diablo está en los detalles. La advertencia de conversión ingenua de Unsloth —70.2 % de precisión top-1 en el modelo 26B frente al 85.6 % después de su optimización dinámica— demuestra que la calidad que se obtiene depende en gran medida de cómo se conviertan y desplieguen los pesos QAT . Si simplemente se toma un checkpoint QAT y se pasa por un convertidor GGUF estándar sin un manejo consciente de QAT, es posible que no se obtenga la calidad esperada.

Para uso en producción, el enfoque más seguro es usar los puntos de control QAT oficiales de Google directamente en su formato compressed-tensors (para vLLM) o los archivos GGUF oficiales de Hugging Face . Si se necesita una cuantización personalizada más allá de lo que Google proporciona, hay que reservar tiempo para realizar benchmarks: los pesos QAT son más sensibles a la metodología de conversión que los pesos cuantizados post-entrenamiento estándar.

Lo que este lanzamiento desbloquea

A nivel práctico, este lanzamiento cambia la respuesta por defecto a "¿puedo ejecutar este modelo localmente?". Por primera vez, una familia importante de modelos de pesos abiertos se distribuye con puntos de control QAT como un producto de primera clase, no como una idea tardía. Las implicaciones se extienden a varias categorías de aplicaciones:

Cargas de trabajo sensibles a la privacidad: Las aplicaciones de asistentes médicos, legales y personales que antes requerían una API en la nube ahora pueden ejecutarse completamente en el dispositivo, en un portátil o teléfono, con el QAT preservando la calidad suficiente para que la inferencia local sea genuinamente útil .

Despliegue sin conexión y en el extremo (edge): La investigación de campo, la respuesta a desastres y los entornos industriales sin conectividad fiable pueden desplegar modelos multimodales capaces en hardware común. El soporte de audio del E2B, combinado con la cuantización móvil de 1 GB, hace de la traducción de voz en tiempo real en un teléfono de gama media una realidad práctica .

Herramientas de desarrollo e IDEs: Los modelos 12B y 26B caben en el hardware que los desarrolladores ya poseen, permitiendo completar código, refactorizar y generar documentación que se ejecuta localmente sin restricciones de latencia o coste. Google posicionó específicamente las versiones cuantizadas para "IDEs, asistentes de codificación y flujos de trabajo agénticos" .

Experimentación y ajuste fino: Equipos de investigación más pequeños y desarrolladores independientes que no podían permitirse clústeres de GPUs como las A100 o H100 ahora pueden trabajar con modelos en el rango de 12B–31B en hardware de consumo, reduciendo drásticamente la barrera de entrada para la personalización de modelos y el ajuste fino específico de dominio.

Google lanzó los puntos de control bajo la misma licencia Apache 2.0 que los modelos base de Gemma 4, y están disponibles de inmediato en Hugging Face para los cinco tamaños de modelo .