Gemma 4 31B vs LLaMA 3.2 Vision: por qué cambiamos el modelo base de nuestro VLM dental en el Día 5

Capítulo 2 de la serie Sprint DGX. Del pitch firmado al primer mail formal de pivot.

Cómo un benchmark pre-registrado sobre MMOral-Bench nos obligó a renegociar el modelo del proyecto con NVIDIA Inception en la primera semana del sprint — y a explicar honestamente por qué evaluamos 3 modelos del catálogo de 11 candidatos, por qué los tamaños eran distintos (8B vs 11B vs 31B), y qué trade-offs aceptamos al elegir el ganador.

El contexto: 60 días, un nodo 8×H100, y una hipótesis que pinchó al quinto día

En abril de 2026 arrancamos un sprint de 60 días dentro del programa NVIDIA Inception Innovation Lab con un nodo DGX de 8×H100 a disposición. El objetivo: llevar el modelo de visión clínica de Dental Brain al siguiente nivel mediante un pipeline de fine-tuning multimodal de cuatro fases.

La propuesta que firmamos con NVIDIA daba por hecho que el modelo base sería LLaMA 3.2 11B Vision. Tenía sentido sobre el papel: pesos abiertos, comunidad amplia, lo conocíamos por dentro.

El Día 5 del sprint descubrimos, con datos en la mano, que esa elección era un error. Este es el post que cuenta cómo lo descubrimos, qué hicimos al respecto y por qué escribir un mail a NVIDIA explicando el cambio el mismo día fue la decisión más fácil del sprint.

Día 4: el plan que se firma antes de ver los datos

Cualquiera que haya trabajado en evaluación de modelos sabe que la trampa más común es justificar a posteriori la elección que ya habías decidido. El antídoto es el plan de análisis pre-registrado: escribes las reglas del juego antes de tirar los dados, las firmas, y las publicas.

El Día 4 (11 de abril de 2026) escribimos exactamente eso. Tres piezas:

1. Los pesos de la decisión, definidos antes de ver un solo número

Dimensión evaluada	Peso en la decisión final
Accuracy global en MMOral-Bench (preguntas cerradas)	40 %
Razonamiento visual dental cualitativo	25 %
Compatibilidad con los frameworks de entrenamiento del pipeline	15 %
Viabilidad de despliegue en INT4	10 %
Alineamiento con el stack NVIDIA (NIM, TensorRT-LLM)	10 %

2. La estadística, también pre-registrada

• Test principal: McNemar pareado — el clásico test «para el mismo ítem, ¿modelo A acierta cuando B falla?».
• Intervalos de confianza: bootstrap con 1000 remuestreos, semilla fija, CI 95 %.
• Regla operativa: dos modelos se consideran distintos solo si sus intervalos de confianza no se solapan.

3. Un árbol de decisión formal con regla de veto

Si la diferencia de score compuesto entre el primero y el segundo era inferior a 0,05, había tiebreakers explícitos. Y, sobre todo, una regla de veto: ningún modelo podía ser seleccionado si rompía la compatibilidad con los frameworks de entrenamiento sin un plan alternativo documentado.

El plan se redactó, se revisó y se firmó antes de ejecutar nada. Ese gesto es el que separa un benchmark de un ejercicio de confirmación del sesgo propio.

Día 10: del catálogo de 11 candidatos a 3 finalistas

Antes del benchmark hicimos un mapeo del estado del arte open-weight en multimodal vision a abril de 2026. Once modelos plausibles: LLaMA 3.2 11B Vision (el del pitch), Qwen3-VL-8B, Qwen3-VL-32B, Qwen2.5-VL-7B, Gemma 3 27B, Gemma 4 26B-A4B (MoE), Gemma 4 31B-IT, Nemotron Nano v2 VL 12B, InternVL3.5-8B, Pixtral 12B, Molmo 7B/72B, DeepSeek-VL2.

De esos 11, el plan inicial era benchmark-ar 4: LLaMA 3.2 11B Vision (compromiso del pitch), Gemma 4 26B-A4B MoE (recomendación del programa), Qwen2.5-VL-7B (baseline reproducible OralGPT-Omni — el único modelo del que existía una receta dental fine-tuned publicada con +24,7 % sobre MMOral) y Qwen3-VL-8B (SOTA octubre 2025). Dos opcionales: Nemotron Nano v2 VL 12B y InternVL3.5-8B.

Lo que pasó en la práctica al ejecutar el benchmark esa misma semana:

• Gemma 4 26B-A4B MoE: descartado pre-benchmark. La compatibilidad con ms-swift 4.1.0 (nuestro framework de training) era parcial, los expertos MoE no aprovechaban el budget VRAM del deploy target Spark 128 GB, y la variante 31B-IT dense del mismo release abril 2026 era una opción más limpia. Pivotamos a Gemma 4 31B-IT como representante de la familia Gemma 4.
• Qwen2.5-VL-7B: descartado del benchmark final. Quedaba duplicado por Qwen3-VL-8B (mismo equipo, generación siguiente, supuesto SOTA). El argumento honest contra esta decisión: era el único modelo con receta dental reproducible publicada (OralGPT-Omni); habría dado el único punto de comparación apples-vs-apples-by-recipe contra literatura existente. Trade-off aceptado: priorizamos modelos más recientes a costa de perder ese ancla bibliográfica.
• Nemotron Nano v2 VL 12B: descartado del benchmark. La arquitectura Hybrid Mamba-Transformer no era path rodado para QLoRA en ms-swift y el encoder RADIOv2.5 requería pipeline preprocesado custom. Sin tiempo para integrar antes de Day 12, lo dejamos como candidato post-sprint.
• InternVL3.5-8B: descartado del benchmark. Licencia derivada de Qwen base en algunos tamaños — complicaba el chain-of-custody comercial para deploy en clínica cliente (Apache 2.0 puro nos daba menos fricción legal).
• Los 4 restantes (Qwen3-VL-32B, Gemma 3 27B, Pixtral 12B, Molmo, DeepSeek-VL2): descartados por VRAM mayor (32B+ no entraban en tier Spark consumer-grade) o por release pre-2025 (no SOTA Q2 2026).

Resultado: 3 modelos en el benchmark final del Día 11-12, no 4. La asimetría merece explicarse antes de leer la tabla de resultados, porque sin este filtro previo cualquiera puede preguntarse «¿y dónde está Qwen2.5-VL-7B con su receta dental publicada?» — pregunta legítima cuya respuesta es trade-off, no descuido.

MMOral-Bench: el benchmark dental que usamos y el problema de extracción que tuvimos que resolver

MMOral-Bench (NeurIPS 2025) es un benchmark dental multimodal con 100 radiografías panorámicas y 1.069 preguntas asociadas, divididas en dos formatos:

• 491 preguntas cerradas de respuesta múltiple A/B/C/D.
• 578 preguntas abiertas, evaluadas por un juez LLM.

El primer smoke test del Día 4 reveló un problema operativo: los modelos VLM no siempre responden con una letra. A veces escriben tres párrafos de razonamiento y meten la respuesta en medio. El comparador ingenuo (literal «A» contra el output) marcaba acierto en muy pocos casos, deprimiendo artificialmente la accuracy.

Construimos un extractor de respuesta multi-paso con cinco fallbacks que recorre el texto buscando, en orden:

1. Una letra A-D aislada al final del texto (lo típico en respuestas con cadena de razonamiento).
2. Una letra A-D aislada al inicio.
3. Match del texto exacto de una de las opciones dentro del output.
4. Match difuso por similitud de cadena, con umbral 0,4.
5. Si nada de lo anterior funciona, se cuenta como fallo. Nunca se descarta el ítem. Esto es importante: descartar ítems «ambiguos» es otra forma clásica de cocinar resultados.

Cada respuesta loggea qué método se usó para extraerla. Más adelante esto va a ser clave para interpretar los resultados con honestidad.

Para las preguntas abiertas usamos un LLM-as-judge binario con Claude Sonnet 4.5, temperatura 0, semilla fija, y un prompt de evaluación inmutable. Coste total del juez: 2,10 USD, 32 minutos de reloj, cero errores de API. (Sí, ese es el precio de evaluar 578 respuestas con un modelo frontier. La era del benchmark caro se acabó.)

Los resultados del Día 5: tres modelos, una sorpresa

Comparamos tres candidatos VLM con el mismo protocolo:

Modelo	Cerradas (n=491)	CI 95 %	Abiertas (juez, n=578)	Combinado	Latencia media
Gemma 4 31B-IT	43,58 %	[39,31 – 48,27]	14,01 %	27,60 %	1.678 ms
Qwen3-VL-8B	26,27 %	[22,40 – 30,35]	11,25 %	18,15 %	3.342 ms
LLaMA 3.2 11B Vision	18,33 %	[14,87 – 22,00]	5,19 %	11,23 %	2.853 ms

Gemma 4 31B-IT obtiene 2,4× la accuracy de LLaMA 3.2 en preguntas cerradas (43,58 % vs 18,33 %) sobre el mismo conjunto. Los intervalos de confianza bootstrap no se solapan entre Gemma 4 y los otros dos modelos. La regla pre-registrada (delta significativo si los CIs no se tocan) se cumple holgadamente.

Y en preguntas abiertas, evaluadas con Claude Sonnet 4.5 como juez independiente, el ranking se mantiene: Gemma 4 (14,01 %) > Qwen3 (11,25 %) > LLaMA 3.2 (5,19 %).

El elefante en la habitación: tres tamaños distintos

Antes de pasar al McNemar paired, hay que reconocer un detalle incómodo. Los tres modelos no tienen el mismo tamaño:

• Gemma 4 31B-IT — 31 mil millones de parámetros (denso)
• LLaMA 3.2 11B Vision — 11 mil millones de parámetros (8B text + 3B vision)
• Qwen3-VL-8B — 8 mil millones de parámetros (denso)

El modelo ganador tiene casi 3× los parámetros del modelo del pitch original. Un escéptico legítimo dirá: «claro que gana, es 3× más grande».

La respuesta honest es que el benchmark NO era apples-vs-apples por parameter count. Era apples-vs-apples por deploy target del producto. El sprint NVIDIA estaba diseñado para entregar un VLM dental deployable on-premise en DGX Spark 128 GB unified (Blackwell GB10, release Q2 2026). Los tres modelos comparados caben en ese hardware. Los tier 70B+ del catálogo (LLaMA 3.2 90B Vision, Qwen3-VL-235B MoE) no caben en Spark single-GB10 con headroom para serving — quedaron fuera del escrutinio precisamente porque no entran en la decisión de producto.

Cambia el framing del benchmark:

• Apples-vs-apples por params: «¿qué arquitectura aprende mejor por parámetro?» — pregunta académica, sin valor inmediato para el cliente que tiene presupuesto fijo de hardware.
• Apples-vs-apples por deploy target: «de todos los modelos que CABEN en el hardware que el cliente va a comprar, ¿cuál rinde mejor en su dominio (dental, multimodal vision)?» — pregunta operativa, alineada con el caso de uso real.

Bajo el segundo framing, Gemma 4 31B-IT gana porque es el modelo más grande que entra en el deploy target, y porque el extra de parámetros se traduce en accuracy clínica medible (43,58 % vs 26,27 % vs 18,33 % MMOral closed). No es trampa: es la decisión óptima de producto para el escenario concreto. Si el cliente fuera un proveedor cloud con 1 TB de VRAM, el benchmark habría incluido tier 70B+ y la decisión podría haber sido distinta. Pero el deploy target es una workstation NVIDIA Spark on-premise; comparamos lo que vamos a deployar.

Cabe añadir un matiz importante para el lector escéptico: la cifra que mide la calidad del sprint en su conjunto no es el delta entre familias de modelos del Día 5, sino el delta del mismo Gemma 4 31B-IT antes y después del pipeline de fine-tuning. Ese sí es apples-vs-apples por parámetros, arquitectura, familia y tamaño — la única variable que cambia es el entrenamiento. Es la métrica con la que se evalúa lo que hicimos, y a la que dedicaremos un análisis específico cuando los gates de evaluación estén firmados.

McNemar paired: ¿la diferencia es real, o es ruido?

Aquí es donde el plan pre-registrado se gana su sueldo. McNemar pareado mira, ítem a ítem, cuántas veces un modelo acierta donde el otro falla:

Comparación	n	Ambos aciertan	Solo A acierta	Solo B acierta	Ambos fallan	p-value
LLaMA 3.2 vs Gemma 4	491	42	48	172	229	< 0,001
LLaMA 3.2 vs Qwen3-VL	491	46	44	83	318	0,000685
Qwen3-VL vs Gemma 4	491	75	54	139	223	< 0,001

Fíjate en la columna «Solo B acierta»: en los 491 ítems pareados LLaMA-vs-Gemma, hay 48 casos en los que LLaMA acierta y Gemma falla, frente a 172 en los que Gemma acierta y LLaMA falla. La asimetría es enorme y direccionalmente clara.

Las tres comparaciones son significativas con p < 0,001. La hipótesis nula —«los modelos son equivalentes, esto es ruido»— queda descartada.

El asterisco que hay que poner: el problema del formato de salida

Si solo mostráramos la tabla anterior estaríamos contando media historia. La extracción de respuesta no es igual de fácil para todos los modelos. El porcentaje de respuestas en las que ningún método de extracción consigue identificar una letra ni una opción es muy distinto:

Modelo	Letra al final	Match difuso	Extracción fallida
Gemma 4 31B-IT	0,8 %	3,0 %	13,4 %
Qwen3-VL-8B	1,2 %	17,3 %	41,1 %
LLaMA 3.2 11B Vision	1,0 %	13,9 %	51,5 %

LLaMA 3.2 falla la extracción en más de la mitad de los ítems. Eso significa que parte del gap en preguntas cerradas puede ser calidad del formato de salida, no capacidad clínica.

Aquí entra el control: las preguntas abiertas se evalúan con un juez LLM que mira el contenido clínico de la respuesta, no su formato. Y el juez confirma el mismo ranking (Gemma > Qwen3 > LLaMA), de forma independiente al extractor.

La decisión es robusta al caveat. Y mencionar el caveat en el post, en lugar de barrerlo bajo la alfombra, es exactamente la diferencia entre un benchmark serio y un anuncio disfrazado de benchmark.

La piedra en el zapato: cambiar el modelo significa cambiar el framework de entrenamiento

El benchmark también destapó un constraint técnico que no estaba en el plan original. Resumen sin jerga:

• Gemma 4 31B es un modelo nuevo y necesita la versión transformers >= 5.5.0 (introducida específicamente para soportar el model_type: gemma4 que aparece en el release de abril de 2026).
• El framework de entrenamiento que estábamos usando (LLaMA-Factory) está fijado a una versión más antigua de transformers.
• Son incompatibles. Si elegimos Gemma 4, tenemos que cambiar de framework.

Evaluamos cinco opciones formalmente:

Opción	Ventaja	Coste
A. Migrar todo el pipeline a ms-swift	Soporta Gemma 4, unifica el stack, ya lo necesitábamos para la fase final	Reescribir las configs de las 3 primeras fases
B. Mantener LLaMA-Factory en paralelo con otro entorno	Coste de migración cero a corto plazo	Dos entornos que mantener
C. Esperar a que LLaMA-Factory actualice	Esfuerzo cero	Sin fecha conocida — el sprint corre
D. Elegir Qwen3-VL (segundo en el ranking)	Stack actual funciona sin cambios	Sacrificar 17 puntos porcentuales de accuracy
E. Quedarse con LLaMA 3.2 (la opción del plan original)	Cero fricción política con NVIDIA	Sacrificar 25 puntos porcentuales

Elegimos la opción A. ms-swift era necesario igualmente para la última fase del pipeline de entrenamiento, así que extender su uso al resto del proceso simplifica el stack en lugar de complicarlo. El coste —reescribir las configs— es asumible.

El mail a NVIDIA, enviado el mismo Día 5

Aquí venía la parte humana de la decisión. La elección obvia desde el ego habría sido: empezamos a entrenar con Gemma 4 sin decir nada, y si en la entrega final el resultado es bueno, nadie pregunta. La elección correcta era la contraria.

El mismo Día 5 enviamos un mail formal al equipo de NVIDIA Innovation Lab. Sin defensa, sin disculpas, sin pedir permiso: simplemente explicando qué habíamos encontrado, qué íbamos a hacer y por qué. Un fragmento del cuerpo (en inglés, tal cual se envió):

«We’re pivoting our primary VLM from LLaMA 3.2 11B Vision to Gemma 4 31B-IT, based on benchmark results from our first week. We wanted to share the reasoning transparently since it deviates from the original pitch. […] Gemma 4 outperforms LLaMA 3.2 by 2.4× on closed-ended dental questions — a gap we believe will compound through our 4-stage fine-tuning pipeline. […] We see this as the kind of decision the Innovation Lab program is designed to enable — the compute access let us benchmark rigorously in Week 1 instead of committing to a model based on published benchmarks alone.»

El mail incluía la tabla de accuracies, el resultado de McNemar, la justificación del cambio de framework, y una lista explícita de «lo que no cambia» (las cuatro fases del pipeline, los agentes en producción, el calendario, la instancia 8×H100).

El tono no es defensivo: el cambio se presenta como exactamente el tipo de decisión que el programa Innovation Lab está diseñado para habilitar. La capacidad de cómputo del grant nos permitió hacer un benchmark riguroso en la primera semana, en lugar de comprometernos con un modelo basándonos en benchmarks publicados por terceros. Eso es el grant funcionando como debe.

Trade-offs aceptados: lo que cuesta cambiar de LLaMA 3.2 a Gemma 4

El modelo base del sprint queda fijado en Gemma 4 31B-IT (Apache 2.0). Score compuesto pre-registrado: 8,45 frente a 6,85 de Qwen3-VL y 5,95 de LLaMA 3.2. Asumimos cuatro trade-offs documentados, sin maquillar:

1. Deploy tier mínimo sube de 16 GB → 24 GB INT4 AWQ. Cualquier clínica que esperaba inferencia en una RTX 4080/4090 de 16 GB queda fuera del MVP. El nicho de hardware se acota a RTX 4090/5090 24 GB y up. La buena noticia: el target real del producto es DGX Spark con 128 GB de memoria unificada, y ahí Gemma 4 31B entra cómodamente.
2. Stack de training cambia: LLaMA-Factory → ms-swift en las 4 fases del pipeline. Forzado por el constraint transformers >= 5.5.0 que Gemma 4 introdujo en abril de 2026 y que LLaMA-Factory no soportaba en su release vigente. Configs reescritos, datasets JSONL idénticos.
3. VRAM por GPU durante training sube de ~28 GB/GPU (LLaMA 3.2 11B LoRA) a ~70 GB/GPU (Gemma 4 31B LoRA bf16). Cabe en 8×H100 80 GB pero con batch size más pequeño y más recompute.
4. El pitch con el programa Innovation Lab comprometía LLaMA 3.2 11B Vision. El cambio requería notificación formal con justificación basada en el benchmark antes de arrancar la primera fase de entrenamiento. Lo escribimos el mismo día.

Licencia Apache 2.0, sin restricciones comerciales para despliegue clínico. Era un requisito duro desde el principio y se cumple.

Esa es la transparencia técnica que mueve un proyecto: nombrar los costes sin maquillar, comprometer un deliverable nuevo (Gemma 4 fine-tuneado con el pipeline de cuatro fases) con la cifra real, y dejar la decisión auditada para cualquiera que la quiera revisar.

La lección, sin moralina

El sprint estaba diseñado para entrenar un modelo durante 60 días. Lo que descubrimos el Día 5 es que ese diseño tenía una vulnerabilidad antes de empezar: no habíamos validado empíricamente la elección del modelo base. Lo dimos por hecho.

Dedicar la primera semana a un benchmark riguroso, con plan pre-registrado, antes de tocar una sola línea de fine-tuning, fue la mejor inversión de todo el sprint. Hubiéramos tirado tres semanas entrenando sobre el modelo equivocado.

Y escribir el mail a NVIDIA el mismo día —en lugar de esconder el cambio o justificarlo más tarde con resultados finales— resultó ser la decisión más fácil de tomar, una vez los números estaban claros. La transparencia, contraintuitivamente, es más barata que el silencio.

Próximo capítulo

Día 10. Tenemos 142 GB de imágenes DICOM anonimizadas listas para subir al nodo de entrenamiento. Pero el RGPD Art. 9 (categoría especial: datos de salud) exige garantías de destrucción de datos que ningún proveedor cloud tiene documentadas por defecto. Dos hilos paralelos de mails con Brev y Hyperstack pidiendo Certificate of Destruction. El día que la legal estuvo a punto de paralizar el ML.