Gemma 4 12B: el modelo multimodal de Google pensado para portátiles

Google DeepMind presentó el 3 de junio de 2026 Gemma 4 12B, un modelo multimodal de pesos abiertos diseñado para ejecutarse localmente en portátiles. El anuncio oficial afirma que cabe en 16 GB de VRAM o memoria unificada, recibe texto, imagen y audio, y reduce la huella de memoria al prescindir de codificadores multimodales separados. «Cabe» es una afirmación de compatibilidad; no significa que cualquier portátil con esa cifra vaya a ofrecer la misma velocidad, contexto o calidad.

El nombre contiene dos datos distintos. «12B» identifica un modelo denso de unos doce mil millones de parámetros. «Gemma 4» lo sitúa dentro de una familia que también incluye variantes para dispositivos de borde, una mezcla de expertos de 26B parámetros totales y un modelo denso de 31B. La tarjeta oficial de la familia declara licencia Apache 2.0, pesos preentrenados y ajustados a instrucciones, y ventanas de contexto de hasta 256.000 tokens en los tamaños medianos.

Qué significa realmente «sin codificador»

Un sistema multimodal necesita convertir una imagen o una onda de audio en representaciones que el transformador pueda procesar. Muchos modelos encargan esa traducción a un codificador especializado y entregan después sus vectores al modelo de lenguaje. Gemma 4 12B evita esos módulos separados, pero no introduce píxeles o sonido sin transformación alguna.

Google explica que para visión usa un módulo ligero con una multiplicación de matrices, posiciones y normalización; para audio proyecta la señal al mismo espacio dimensional que los tokens de texto. El informe técnico de Gemma 4 concreta que el modelo recibe parches de imagen y fragmentos de audio de 40 milisegundos mediante proyecciones al espacio de embeddings. La precisión importa: «encoder-free» describe una arquitectura unificada, no ausencia de preprocesamiento.

La ventaja buscada es reducir fragmentación y memoria adicional, y permitir que el núcleo del modelo aprenda relaciones entre modalidades. El coste potencial es que un diseño unificado debe demostrar calidad en tareas donde un codificador dedicado había acumulado optimización específica. La arquitectura indica cómo circula la información; no decide por sí sola si una transcripción, un gráfico o una fotografía se interpretan bien.

Los 16 GB son un punto de partida, no una garantía

La cifra de Google especifica VRAM o memoria unificada. En un equipo con GPU dedicada, la memoria del sistema y la VRAM son reservas diferentes; en un equipo con memoria unificada, sistema operativo, aplicaciones y modelo comparten el mismo conjunto. El checkpoint, la precisión numérica, la caché de atención, el tamaño del contexto y los recursos visuales o de audio también consumen memoria.

Por eso dos ordenadores que anuncian 16 GB pueden comportarse de manera distinta. Uno puede cargar el modelo y quedarse sin margen al ampliar el contexto; otro puede derivar parte del cálculo a CPU; un tercero puede cerrar procesos o ralentizarse por presión de memoria. «El modelo arranca» tampoco equivale a «la tarea termina a una velocidad útil».

La promesa correcta es más estrecha: Google diseñó el modelo para una clase de hardware de consumo y publica una configuración de memoria como referencia. El usuario debe verificar el checkpoint exacto, el runtime, la cuantización o precisión y el contexto probado. Sin esos cuatro datos, una demostración de portátil no es reproducible.

Un protocolo de prueba local

El primer paso es registrar el equipo: procesador, GPU, RAM, VRAM o memoria unificada, sistema operativo y espacio libre. Después se anota el artefacto exacto. El repositorio oficial de Google en Hugging Face distingue el modelo base y ofrece instrucciones para cargar el checkpoint con Transformers. El identificador y la revisión son necesarios porque una actualización puede cambiar archivos, compatibilidad o comportamiento.

El segundo paso es fijar la configuración: runtime y versión, precisión o cuantización, longitud máxima de contexto y modo de razonamiento. No se comparan dos modelos si uno recibe más contexto, una cuantización diferente o un presupuesto de generación mayor. Tampoco se atribuye al modelo un fallo que procede de una versión de biblioteca incompatible.

El tercero es avanzar por escalones. Primero se carga el modelo y se ejecuta una petición de texto breve. Luego una imagen pequeña con una pregunta cuya respuesta se conoce. Después un audio corto con transcripción de referencia. Solo entonces se prueba la tarea real. En cada escalón se registran memoria máxima, tiempo de carga, tiempo hasta la primera salida, velocidad de generación, errores y calidad.

El cuarto paso es comprobar el flujo de datos. Ejecución local significa que la inferencia puede ocurrir en la máquina, pero la aplicación empleada puede descargar modelos, buscar actualizaciones o enviar telemetría. Para una tarea sensible hay que leer la documentación del runtime, observar las conexiones de red, trabajar sin servicios remotos y comprobar que entradas y resultados permanecen en la carpeta prevista.

Cómo leer la comparación con el modelo grande

Google afirma que 12B se aproxima al 26B MoE en pruebas estándar y usa menos de la mitad de su huella total de memoria. La frase tiene dos ejes: resultado de benchmark y memoria. No dice que ambos modelos sean intercambiables en cada modalidad o tarea. El 26B es una mezcla de expertos con 3,8B parámetros activos declarados en el informe; su tamaño total no describe por sí solo el cómputo de cada paso.

Para trasladar la comparación a un caso real, se construye un conjunto de ejemplos con respuestas o criterios verificables. En visión puede incluir extracción de campos, lectura de gráficos y descripción de relaciones espaciales. En audio, transcripción con ruido, nombres propios y cambios de hablante. En texto, una tarea de razonamiento y otra de formato estricto. Se puntúan exactitud, omisiones, latencia y necesidad de corrección humana.

Los promedios públicos sirven para elegir candidatos, no para cerrar una compra o un despliegue. La tarjeta del modelo reúne resultados por pruebas y modalidades, pero el lector debe comprobar la métrica, la configuración y si su problema se parece al conjunto evaluado. «Cerca» solo adquiere significado cuando se define un margen aceptable sobre una tarea concreta.

Local y abierto también requieren matices

Los pesos abiertos permiten descargar, ejecutar e inspeccionar el artefacto en una medida que una API cerrada no ofrece. La licencia Apache 2.0 declarada por Google facilita modificación y uso comercial bajo sus términos. Eso no convierte automáticamente en abiertos los datos de entrenamiento, cada componente del runtime o una aplicación que empaquete el modelo. La auditoría debe separar pesos, código, licencia, documentación y dependencias.

La ejecución local ofrece control sobre disponibilidad y recorrido de los datos, pero traslada responsabilidades. El operador gestiona actualizaciones, seguridad del equipo, archivos temporales, permisos y evaluación de salidas. También decide si una llamada de herramienta puede modificar el sistema. Un modelo local con acceso amplio puede causar daño local; la ausencia de nube no elimina el principio de mínimo privilegio.

Qué aporta la arquitectura unificada

Gemma 4 12B es interesante porque cambia el reparto de trabajo dentro del modelo y acerca tres modalidades a hardware de consumo. La afirmación verificable es que Google publicó pesos, arquitectura, requisitos de referencia y rutas de ejecución. La calidad para una aplicación particular sigue siendo una pregunta experimental.

La capacidad transferible consiste en convertir «funciona en tu portátil» en una ficha reproducible: hardware, checkpoint, runtime, precisión, contexto, memoria, latencia, calidad y flujo de datos. Esa ficha separa una carga exitosa de un sistema útil y permite decidir si la arquitectura sin codificadores mejora el trabajo propio, no solo la demostración del fabricante.

La ficha debe conservar también la fecha, la revisión del modelo, el hash de los archivos de configuración y una muestra de entradas y salidas no sensibles. Si el runtime o el checkpoint cambian, se repite el conjunto de prueba antes de comparar. Así una mejora aparente no se confunde con un cambio de versión, y un resultado puede ser revisado por otra persona.