Migrar de Gemma 2 a Gemma 3: errores que evitar y verificaciones

#Lo que cambia realmente entre Gemma 2 y Gemma 3

Tres cambios estructurales afectan a una aplicación existente: el contexto máximo, la estructura de los mensajes enviados al modelo y la presencia de una entrada de imagen. Un simple cambio de nombre de modelo en tu código (gemma2 por gemma3) no garantiza un comportamiento idéntico, incluso si el formato de salida sigue siendo texto.

Gemma 2 solo existía en 9 y 27 mil millones de parámetros. Gemma 3 añade un 1B y un 4B, y redefine el contexto de cada tamaño: no es solo «más grande», es una arquitectura diferente internamente. Si su elección de tamaño de modelo se basaba en las limitaciones de Gemma 2, merece ser reevaluado en lugar de repetirse idéntico.

#Tamaños y contexto: el verdadero salto

Gemma 2 tiene un contexto fijo de 8.192 tokens, independientemente del tamaño del modelo. Gemma 3 amplía este contexto a 32.768 tokens para el 1B y a 131.072 tokens para los 4B, 12B y 27B: un factor de 16 para los tamaños medios y grandes. Es la información más útil para dimensionar un uso de RAG o un historial de conversación largo, pero este contexto anunciado es un límite del modelo, no la memoria realmente asignada por tu runtime: Ollama y los servidores de inferencia suelen limitar por defecto el contexto a un valor mucho más bajo (a menudo 4096 o 8192 tokens) mientras no se aumente explícitamente.

#Plantilla de chat: el error más común

La causa más frecuente de respuestas de peor calidad tras una migración no es la calidad del modelo, sino una plantilla de chat mal aplicada. Cada familia de modelos espera un formato preciso para los turnos de conversación (etiquetas de inicio y fin de turno, posición del prompt del sistema). Si tu aplicación construye el prompt final por sí misma en lugar de dejar que el entorno de ejecución aplique la plantilla del modelo, una plantilla que sigue configurada para Gemma 2 produce respuestas truncadas, fuera de tema o que siguen generándose después del final esperado.

1. 01
   Identificar quién construye el prompt

   Verificar si tu código construye por sí mismo el texto enviado al modelo o si utiliza la API de chat del entorno de ejecución (Ollama /api/chat, servidor llama.cpp), que aplica automáticamente la plantilla correcta.
2. 02
   Comparar plantillas

   Recuperar el archivo de plantilla integrado en el modelo Gemma 3 usado (GGUF o Hugging Face) y compararlo con el de Gemma 2 usado hasta ahora, en lugar de asumir que son iguales.
3. 03
   Volver a ejecutar un conjunto de prompts de referencia

   Probar los mismos 10 a 20 prompts de prueba con Gemma 2 y luego con Gemma 3 usando la nueva plantilla, y comparar la longitud, la pertinencia y si la generación termina correctamente.

El rol de sistema ilustra bien este error. Google indica, al presentar Gemma 4, que esta nueva familia «utiliza roles estándar system, assistant y user, a diferencia de Gemma 3»: una confirmación oficial de que Gemma 3 (como Gemma 2) no maneja exactamente el prompt de sistema de la misma manera que los runtimes que exponen un rol system nativo. En concreto, un código que envía un mensaje de rol system separado basándose en las convenciones de otras familias de modelos debe verificar, en Gemma 3 específicamente, cómo maneja su runtime ese mensaje en lugar de asumir que está aislado.

#Multimodalidad: los modelos 4B, 12B y 27B aceptan imágenes

A diferencia de Gemma 2, que solo admite texto, los modelos Gemma 3 4B, 12B y 27B incorporan un codificador de imágenes SigLIP que procesa imágenes redimensionadas a 896×896 píxeles; solo el 1B sigue siendo exclusivamente de texto. En concreto, si tu aplicación migra a un 12B o a un 27B, incorpora la capacidad de recibir imágenes aunque no la utilice: esto cambia el formato de API esperado por algunos runtimes (un campo de imagen además del texto) y puede aumentar ligeramente la memoria necesaria para la carga, incluso sin enviar ninguna imagen.

Este cambio hacia la multimodalidad tiene una consecuencia práctica que suele pasarse por alto durante la migración: un pipeline que validaba estrictamente el formato de los mensajes entrantes (esquema JSON, tipado estricto) puede rechazar o interpretar mal un campo de imagen ausente o vacío si el cliente de la API del nuevo modelo lo añade por defecto. En cambio, un pipeline que ya filtraba las entradas no textuales antes de llamar al modelo no necesita cambios: la capacidad de Gemma 3 para procesar imágenes permanece inactiva mientras no se envíe ninguna imagen; nunca se impone.

#Cuantización QAT: memoria dividida por un factor de 3 a 4

Google publica checkpoints de Gemma 3 entrenados teniendo en cuenta la cuantización (QAT), además de las versiones Q4_0 clásicas para Ollama, llama.cpp y MLX. La ventaja: una pérdida de calidad mucho menor que con una cuantización aplicada después del entrenamiento a un modelo no preparado para ello.

Estas cifras son las que publicó Google cuando lanzó los checkpoints QAT; describen la memoria necesaria para cargar los pesos, no la memoria total utilizada durante la generación (se añaden el contexto y el caché KV). Una medición en tu propia máquina sigue siendo el único modo de confirmar una cifra para tu caso de uso.

El método adoptado por Google aplica aproximadamente 5.000 pasos de entrenamiento consciente de la cuantización utilizando las probabilidades del modelo no cuantizado como objetivo, lo que reduce en un 54 % la caída de perplejidad en comparación con una cuantización aplicada a posteriori a un modelo no preparado para ello. Para una aplicación migrada desde Gemma 2, esto significa que un mismo nivel de cuantización (por ejemplo, Q4) en Gemma 3 produce generalmente un resultado más cercano al modelo en precisión completa que el obtenido con Gemma 2 cuantizado de forma clásica: una mejora derivada de la preparación del modelo, no de un ajuste que deba realizar el usuario.

#¿Migrar a Gemma 3 o esperar a Gemma 4?

Gemma 4 ya está disponible en Ollama en el momento de escribir esta guía, lo que plantea una verdadera pregunta a quienes aún migran desde Gemma 2: ¿conviene quedarse en Gemma 3 o pasar directamente a la siguiente generación? La ficha de Gemma 4 en Ollama anuncia tamaños distintos de los de Gemma 3 (variantes E2B y E4B con un número reducido de parámetros efectivos, un 12B, una variante MoE de 26B con 3,8 mil millones de parámetros activos y un 31B denso), orientados al razonamiento, los flujos de trabajo con agentes y el código: un ámbito más amplio que la mera sustitución de Gemma 2.

Para una aplicación que ya está en producción con Gemma 2, esta guía sigue centrada en la migración a Gemma 3: las comprobaciones de contexto, plantilla y regresión descritas aquí se aplican de la misma manera si el destino final es Gemma 4, pero el cambio directo modifica más cosas (roles de chat estándar, nuevos tamaños, arquitectura MoE en la variante 26B) que una migración Gemma 2 → Gemma 3. Una guía específica detalla la instalación y el rendimiento de Gemma 4 en local.

#Lista de comprobación antes de pasar a producción

Versión del runtime

Verificar que Ollama, llama.cpp o MLX sean compatibles con la versión de Gemma 3 que se quiere utilizar (la compatibilidad se añadió después del lanzamiento del modelo y no siempre está disponible de inmediato en una versión antigua del entorno de ejecución).

Contexto realmente configurado

No dejar al azar el valor de contexto del servidor: configurarlo explícitamente según tus necesidades reales, no según el límite del modelo.

Formato de entrada de imagen

Si migras a 4B, 12B o 27B, verificar que tu cliente API no envíe un formato de imagen incompatible con el nuevo endpoint.

Elección de la cuantización

Comparar un GGUF Q4_K_M clásico y un checkpoint QAT oficial con tus propios prompts antes de tomar una decisión definitiva; ambos existen para Gemma 3.

Ventana de rollback

Mantener el modelo Gemma 2 y su configuración disponibles durante la fase de cambio, mientras se confirma la ausencia de regresión.

#Detectar una regresión en tus prompts

Una migración de modelo no se valida por una impresión tras dos o tres preguntas. Un conjunto de prompts de referencia, representativo del uso real de la aplicación y ejecutado exactamente igual en el modelo anterior y en el nuevo, es la única forma de detectar una regresión silenciosa: una respuesta más larga pero menos precisa, la pérdida de un formato de salida esperado (JSON, lista) o una desviación del tono. Conservar estas salidas de referencia también permite documentar la decisión de migración en lugar de basarse en una impresión.

#Prever una vuelta atrás

La opción más segura para una aplicación en producción consiste en desplegar Gemma 3 en paralelo con Gemma 2 (con un nombre de modelo distinto en el entorno de ejecución), dirigir parte del tráfico hacia la nueva versión y desactivar la antigua solo cuando las mediciones de calidad con tus prompts de referencia sean al menos equivalentes. Esto consume algo de espacio en disco y de RAM durante la transición, pero evita una interrupción del servicio si la nueva plantilla de chat o el nuevo contexto provoca un comportamiento inesperado en condiciones reales.

• Instalar Gemma 3 en local paso a paso
• Entender los formatos GGUF y safetensors
• Comparar IA local y ChatGPT
• Gemma 4 en local: instalación, VRAM y rendimiento
• Elegir tu cuantización (Q4, Q5, Q8, FP16)
• Cuantizar la caché KV para ahorrar VRAM con contextos largos
• Fuente: presentación oficial de Gemma 3 (Hugging Face)
• Fuente: checkpoints QAT Gemma 3 (Google Developers Blog)
• Fuente: presentación oficial de Gemma 2 (Hugging Face)
• Fuente: ficha de Gemma 4 en Ollama