Gemma 4: Cómo Google Metió IA de Frontera en 31 Mil Millones de Parámetros

Google Gemma 4 31B dense model running on Raspberry Pi, phone, and laptop with glowing neural network

Leer en: English | Español | Italiano

Google DeepMind lanzó Gemma 4 el 2 de abril de 2026. Cuatro tamaños de modelo, soporte multimodal completo, licencia Apache 2.0 y puntuaciones en benchmarks que ponen nerviosos a modelos 20 veces más grandes. La variante más pequeña corre en una Raspberry Pi 5. La más grande, un modelo denso de 31B, ocupa el puesto #3 entre todos los modelos abiertos en el leaderboard de Arena AI.

Esto no es incremental. Es un argumento fundamentalmente distinto sobre cuán grande necesita ser un modelo.

Pasé el último día diseccionando cada detalle técnico del blog de integración de Hugging Face, el anuncio oficial de Google, la guía de despliegue edge de NVIDIA, la model card de DeepMind, el leaderboard de Chatbot Arena y 445 comentarios en Hacker News. Esto es todo lo que encontré.

La familia completa de Gemma 4: cuatro modelos, un linaje arquitectónico

Gemma 4 se distribuye en cuatro tamaños, todos disponibles como checkpoints base e instruction-tuned:

  • E2B: 2.3B parámetros efectivos (5.1B totales con embeddings), contexto de 128K, sliding window de 512 tokens
  • E4B: 4.5B parámetros efectivos (7.9B totales con embeddings), contexto de 128K, sliding window de 512 tokens
  • 26B-A4B: Mixture-of-Experts, 3.8B activos de 25.2B totales (128 experts, 8 activos + 1 compartido), contexto de 256K
  • 31B: Completamente denso, 30.7B parámetros, contexto de 256K, sliding window de 1024 tokens

Los cuatro manejan texto, imágenes y video. El E2B y el E4B también soportan entrada de audio nativa (reconocimiento y comprensión de voz, hasta 30 segundos). Todos los modelos incluyen function calling nativo, salida JSON estructurada, instrucciones de sistema y modos de thinking/reasoning. Soportan más de 140 idiomas con un vocabulario de 262K tokens.

La “E” en E2B y E4B significa “Effective.” Estos modelos usan Per-Layer Embeddings (PLE), una arquitectura heredada de Gemma 3n, que hace que el conteo total de parámetros sea mayor que el conteo efectivo. Los parámetros extra son tablas de embeddings, no pesos del decoder, así que no contribuyen al cómputo de inferencia de la misma manera.

El cambio a Apache 2.0

Cada versión anterior de Gemma usaba una licencia personalizada de Google. Técnicamente permitía uso comercial, pero incluía cláusulas que dejaban a Google restringir el uso bajo ciertas condiciones. Los desarrolladores construyendo sistemas en producción sobre modelos Gemma tenían incertidumbre legal integrada en su stack.

Gemma 4 es Apache 2.0. Punto. Puedes usar estos modelos comercialmente, modificarlos, redistribuirlos, crear obras derivadas, fusionarlos con código propietario y construir productos sin pedir permiso ni preocuparte por futuros cambios de licencia. Para industrias reguladas (salud, finanzas, gobierno) donde la revisión legal de licencias de modelos puede tomar meses, esto elimina un obstáculo significativo para la adopción.

La decisión de Apache 2.0 también abre la puerta a modificaciones comunitarias que antes estaban en una zona gris legal: variantes abliterated/sin censura, fine-tunes específicos de dominio con perfiles de seguridad personalizados e integración en proyectos copyleft. Al menos una variante sin censura de Gemma 4 apareció a las pocas horas del lanzamiento.

El denso 31B: el modelo que cambió la conversación

El Gemma 4 31B es un transformer completamente denso. Cada uno de sus 30.7 mil millones de parámetros se activa en cada token. Sin routing, sin selección de experts, sin trucos de sparsity. Y obtiene una puntuación estimada de 1452 en Arena AI (texto), ubicándose en el puesto #3 entre todos los modelos open-source del mundo y convirtiéndolo en el modelo open-source #1 de EE.UU.

Para entender por qué esto importa, mira qué hay a su alrededor en el leaderboard:

  • GLM-5 (Z.ai/Zhipu): Arena score 1452, licencia MIT, estimado ~750B parámetros. 24 veces más grande que Gemma 4 31B.
  • Kimi-K2.5-Thinking (Moonshot AI): Arena score 1451, MIT modificada. Estimado 1T+ parámetros totales. 34 veces más grande.
  • Qwen 3.5-397B-A17B (Alibaba): Arena score 1450, Apache 2.0. 397B parámetros totales, 17B activos. 13 veces más grande en parámetros totales.
  • Gemma 4 31B (Google): Arena score 1452, Apache 2.0. 31B denso. Empata o supera a todos los anteriores.

Por debajo: DeepSeek-R1-0528 con 1426, GPT-5-high con 1444, Grok-4 con 1442. Estos son modelos propietarios solo accesibles por API, de laboratorios con gran financiación. Que un modelo abierto de 31B los iguale no es normal.

Análisis detallado de benchmarks

Aquí está la tabla completa de benchmarks para los modelos instruction-tuned con thinking habilitado, comparados contra Gemma 3 27B (la generación anterior):

Razonamiento y conocimiento:

  • MMLU-Pro (Q&A multilingüe): Gemma 4 31B 85.2% | 26B-A4B 82.6% | E4B 69.4% | E2B 60.0% | Gemma 3 27B 67.6%
  • AIME 2026 (matemáticas de competición, sin herramientas): 31B 89.2% | 26B 88.3% | E4B 42.5% | E2B 37.5% | Gemma 3 20.8%
  • GPQA Diamond (ciencia nivel doctorado): 31B 84.3% | 26B 82.3% | E4B 58.6% | E2B 43.4% | Gemma 3 42.4%
  • Tau2 Bench (uso agéntico de herramientas, promedio de 3): 31B 76.9% | 26B 68.2% | E4B 42.2% | E2B 24.5% | Gemma 3 16.2%
  • BigBench Extra Hard: 31B 74.4% | 26B 64.8% | E4B 33.1% | E2B 21.9% | Gemma 3 19.3%
  • MMMLU (multilingüe): 31B 88.4% | 26B 86.3% | E4B 76.6% | E2B 67.4% | Gemma 3 70.7%

Código:

  • LiveCodeBench v6: 31B 80.0% | 26B 77.1% | E4B 52.0% | E2B 44.0% | Gemma 3 29.1%
  • Codeforces ELO: 31B 2150 | 26B 1718 | E4B 940 | E2B 633 | Gemma 3 110
  • HLE (Humanity’s Last Exam, sin herramientas): 31B 19.5% | 26B 8.7%
  • HLE with search: 31B 26.5% | 26B 17.2%

Visión:

  • MMMU Pro (razonamiento multimodal): 31B 76.9% | 26B 73.8% | E4B 52.6% | E2B 44.2% | Gemma 3 49.7%
  • MATH-Vision: 31B 85.6% | 26B 82.4% | E4B 59.5% | E2B 52.4% | Gemma 3 46.0%
  • OmniDocBench 1.5 (edit distance, menor es mejor): 31B 0.131 | 26B 0.149 | E4B 0.181 | E2B 0.290 | Gemma 3 0.365
  • MedXPertQA MM (multimodal médico): 31B 61.3% | 26B 58.1% | E4B 28.7% | E2B 23.5%

Audio (solo E2B y E4B):

  • CoVoST (traducción de voz): E4B 35.54 | E2B 33.47
  • FLEURS (reconocimiento de voz, menor es mejor): E4B 0.08 | E2B 0.09

Contexto largo:

  • MRCR v2 8-needle 128K (promedio): 31B 66.4% | 26B 44.1% | E4B 25.4% | E2B 19.1% | Gemma 3 13.5%

El salto generacional de Gemma 3 27B a Gemma 4 31B es asombroso. AIME pasa de 20.8% a 89.2%. LiveCodeBench de 29.1% a 80.0%. Codeforces ELO de 110 a 2150. Estas no son mejoras pequeñas. Son saltos cualitativos hacia un nivel de capacidad completamente diferente.

Gemma 4 31B vs Qwen 3.5 27B: cara a cara

La comunidad no perdió tiempo construyendo comparaciones lado a lado. Este es el panorama consolidado de múltiples testers independientes:

  • MMLU-Pro: Gemma 4 85.2% vs Qwen 3.5 86.1% (Qwen gana por poco)
  • GPQA Diamond: Gemma 4 84.3% vs Qwen 3.5 85.5% (Qwen gana por poco)
  • LiveCodeBench v6: Gemma 4 80.0% vs Qwen 3.5 80.7% (empate)
  • Codeforces ELO: Gemma 4 2150 vs Qwen 3.5 1899 (Gemma gana por mucho)
  • TAU2-Bench: Gemma 4 76.9% vs Qwen 3.5 79.0% (Qwen gana)
  • MMMLU (multilingüe): Gemma 4 88.4% vs Qwen 3.5 85.9% (Gemma gana)
  • HLE (sin herramientas): Gemma 4 19.5% vs Qwen 3.5 24.3% (Qwen gana)

En benchmarks automatizados puros, es prácticamente un empate, con Qwen 3.5 manteniendo una ligera ventaja en tareas de razonamiento y Gemma 4 ganando en coding competitivo y multilingüe. Pero el Arena AI ELO (que mide la preferencia humana a partir de millones de comparaciones ciegas) favorece a Gemma 4: 1452 vs 1450. La diferencia entre ELO y benchmarks automatizados sugiere que Gemma 4 produce respuestas que los humanos realmente prefieren, incluso cuando las cifras de precisión bruta son similares. Eso es una señal de calidad de datos de entrenamiento y RLHF, no de arquitectura.

Un early adopter en dev.to lo resumió bien: “La opinión honesta es que Gemma 4 empata con Qwen, si no es que Qwen va ligeramente por delante. Y Qwen 3.5 es más eficiente computacionalmente también.” Pero otro señaló: “Gemma 4 hace que translategemma se sienta obsoleto al instante” para tareas en idiomas distintos al inglés. La historia multilingüe es donde Gemma 4 se separa claramente del resto.

Arquitectura: cómo 31B parámetros golpean tan por encima de su peso

Gemma 4 no logra estos números simplemente escalando un transformer estándar. El blog de integración de Hugging Face detalla varias innovaciones arquitectónicas que trabajan juntas para exprimir la máxima inteligencia de cada parámetro. Cabe destacar que Google eliminó características complejas o inconclusas como Altup que aparecieron en investigaciones anteriores de Gemma, favoreciendo una combinación más limpia que es altamente compatible con distintas librerías de inferencia.

Atención dual: Sliding Window + Global Full-Context

Gemma 4 alterna entre dos tipos de capas de atención:

  • Atención local con sliding window: Cada token atiende solo a tokens cercanos dentro de una ventana fija. Los modelos 31B y 26B usan ventanas de 1024 tokens; el E2B y E4B usan ventanas de 512 tokens. Esto es barato porque la matriz de atención es pequeña.
  • Atención global de contexto completo: Atención estándar sobre toda la secuencia. Costosa en contextos largos, pero necesaria para capturar dependencias de largo alcance.

Al alternar estas, el modelo obtiene el beneficio de la conciencia de contexto completo (a través de las capas globales) sin pagar el costo cuadrático completo en cada capa. Cada tipo de atención también tiene su propia configuración de RoPE: RoPE estándar para capas de sliding window, RoPE proporcional para capas globales. La variante proporcional habilita la ventana de contexto de 256K en los modelos más grandes sin que la codificación posicional se deteriore en posiciones extremas.

KV Cache compartido

Esta es una optimización de eficiencia que reduce directamente tanto el cómputo como la memoria durante la inferencia. Las últimas num_kv_shared_layers capas del modelo no calculan sus propias proyecciones de key y value. En su lugar, reutilizan los tensores K/V de la última capa no compartida del mismo tipo de atención (sliding o full).

En la práctica, esto significa que el modelo tiene menos KV caches distintos que mantener durante la generación. Para uso con contexto largo (la ventana de 256K) y despliegue on-device, esto es significativo. Es la diferencia entre caber en memoria y no caber. El impacto en calidad, según las pruebas de Hugging Face, es mínimo.

Un comentarista de Hacker News señaló que el comportamiento del KV cache del 31B no es un bug (como algunos sospecharon inicialmente) sino que refleja un costo estático de sliding window de 3.6GB. Con una cuantización IQ4_XS de 15.2GB para los pesos, estamos hablando de aproximadamente 64K de contexto en una GPU de 24GB, o 100K+ con cuantización KV de 8 bits tras una optimización reciente en llama.cpp.

Per-Layer Embeddings (PLE)

Esta es la característica arquitectónica más distintiva de los modelos más pequeños de Gemma 4 (E2B y E4B), heredada de Gemma 3n. Los transformers estándar dan a cada token un único vector de embedding en la entrada. Ese único vector tiene que anticipar todo lo que el modelo podría necesitar a lo largo de todas las capas. Es un cuello de botella.

PLE añade una vía de condicionamiento paralela de menor dimensión junto al flujo residual principal. Para cada token, PLE produce un pequeño vector dedicado para cada capa combinando dos señales:

  1. Un componente de identidad del token: de una segunda tabla de embedding
  2. Un componente consciente del contexto: de una proyección aprendida de los embeddings principales

Cada capa del decoder usa entonces su vector PLE correspondiente para modular los estados ocultos mediante un bloque residual ligero después de la atención y el feed-forward. Esto da a cada capa su propio canal para recibir información específica del token exactamente cuando se vuelve relevante, en lugar de requerir que todo esté empaquetado en un único embedding inicial.

Como la dimensión de PLE es mucho más pequeña que el tamaño oculto principal, esto añade una especialización por capa significativa a un costo modesto en parámetros. Por esto el conteo total de parámetros (5.1B para E2B) es mayor que el conteo efectivo (2.3B): las tablas de embeddings de PLE añaden parámetros, pero son baratas en tiempo de inferencia.

Para entradas multimodales (imágenes, audio, video), PLE se calcula antes de que los soft tokens se fusionen con la secuencia de embeddings. Las posiciones multimodales usan el pad token ID, por lo que reciben señales por capa neutrales. El modelo aprende a distinguir texto de contenido multimodal en parte a través de este mecanismo.

Vision Encoder

El encoder de imágenes usa embeddings posicionales 2D aprendidos con RoPE multidimensional. Dos mejoras críticas sobre Gemma 3:

  • Relaciones de aspecto variables: Sin recortes cuadrados forzados. Las imágenes se procesan en sus dimensiones naturales, preservando información que el recorte cuadrado destruye.
  • Presupuestos de tokens configurables: El encoder puede producir 70, 140, 280, 560 o 1120 tokens de imagen por imagen. Eliges tu balance velocidad/memoria/calidad por solicitud. Un análisis rápido de miniatura podría usar 70 tokens; una tarea detallada de OCR podría usar 1120.

El equipo de Hugging Face probó los cuatro tamaños de modelo en detección de objetos, detección de elementos GUI, generación de descripciones de imágenes y reproducción de HTML a partir de capturas de pantalla. Todos los modelos funcionaron bien, con el 31B produciendo las respuestas más detalladas y precisas. Incluso el E2B identificó correctamente bounding boxes de elementos de interfaz y generó HTML aceptable a partir de capturas de pantalla, lo cual es notable para un modelo de 2.3B efectivos.

Audio Encoder

Los modelos E2B y E4B incluyen un audio encoder conformer estilo USM, la misma arquitectura base usada en Gemma 3n. Maneja reconocimiento de voz, transcripción speech-to-text y respuesta a preguntas sobre audio para clips de hasta 30 segundos. En las pruebas de Hugging Face, ambos modelos transcribieron con precisión un extracto de un discurso de Obama y respondieron preguntas sobre el contenido de audio de un video de concierto en vivo (aunque el E2B alucinó algunos detalles de audio).

Los modelos más grandes, 31B y 26B, no incluyen soporte de audio. Manejan video procesando los fotogramas visuales sin la pista de audio. Esto es presumiblemente una decisión de presupuesto de parámetros: incluir un audio encoder completo en un modelo de 31B añadiría parámetros significativos sin un beneficio proporcional para el caso de uso principal de texto/código/razonamiento.

El E2B: IA de frontera en una Raspberry Pi 5

El miembro más sorprendente de la familia es el más pequeño. Gemma 4 E2B tiene 2.3 mil millones de parámetros efectivos y cabe cómodamente en dispositivos con 4GB+ de RAM. Google lista explícitamente Raspberry Pi, teléfonos Android y NVIDIA Jetson Orin Nano como hardware objetivo.

Deja que eso se asiente. Este es un modelo que:

  • Maneja texto, imágenes, audio y video como entrada
  • Tiene una ventana de contexto de 128K tokens
  • Soporta function calling nativo para flujos de trabajo agénticos
  • Soporta más de 140 idiomas
  • Incluye modos de thinking/reasoning
  • Corre completamente offline con latencia cercana a cero
  • Obtiene 60% en MMLU-Pro y 37.5% en AIME 2026

Para comparar, el modelo completo de 27B de Gemma 3 (que requería una GPU potente) obtuvo 67.6% en MMLU-Pro y 20.8% en AIME 2026. El E2B puntúa casi igual en benchmarks de conocimiento y casi el doble en matemáticas comparado con un modelo que era 12 veces su tamaño de la generación anterior. Un modelo de 2.3B de abril de 2026 supera a un modelo de 27B de 2025 en matemáticas de competición. El ritmo de mejora es vertiginoso.

Ejecutarlo es trivial:

ollama run gemma4:e2b

Eso es una descarga cuantizada de 7.2GB (Q4_K_M) que te da una IA multimodal con function calling nativo en una computadora de placa única de $80. O en el teléfono que llevas en el bolsillo. O en una pestaña del navegador vía WebGPU.

Qué puedes hacer realmente con el E2B

El blog de Hugging Face incluye pruebas extensivas en todas las modalidades. Esto es lo que funciona de fábrica con el modelo más pequeño:

Detección de objetos y señalamiento de GUI: Dale una captura de pantalla y pregunta “¿Cuál es el bounding box del elemento ‘view recipe’?” Responde en formato JSON con coordenadas, sin necesidad de prompting especial. Las coordenadas se refieren a un espacio de imagen de 1000×1000 relativo a las dimensiones de entrada.

Transcripción de audio: Aliméntalo con un MP3 y pide una transcripción. El E2B produjo: “This week I traveled to Chicago to deliver my final farewell address to the nation following in the tradition of presidents before me It was an opportunity to say thank you whether we’ve seen eye to eye or rarely agreed at all…” Limpia, precisa, sin peculiaridades de puntuación.

Comprensión de video: El E2B identificó correctamente una actuación de concierto en vivo a partir de video, incluyendo el escenario (festival al aire libre), artistas, montaje del escenario, e intentó describir las letras, aunque alucinó algunos detalles de audio. El E4B manejó esto con mayor precisión.

Descripción de imágenes: “A medium shot captures a weathered seagull perched atop a stone pedestal in what appears to be a bustling European square, with a grand, classical-style building featuring ornate columns and architectural details dominating the right side of the frame.” Eso es del modelo de 2.3B. Preciso, detallado, correctamente estructurado.

Function calling multimodal: Dale una imagen de un templo tailandés y el prompt “¿Cuál es la ciudad en esta imagen? Revisa el clima ahí ahora mismo” junto con una definición de herramienta get_weather. El E2B identifica correctamente Bangkok por el estilo arquitectónico, razona paso a paso su enfoque y genera la llamada a función correcta: get_weather(city="Bangkok").

Despliegue en Raspberry Pi 5

La Raspberry Pi 5 tiene variantes de 4GB u 8GB de RAM, un Broadcom BCM2712 quad-core Cortex-A76 a 2.4GHz y no tiene GPU en el sentido tradicional. Ejecutar un modelo E2B cuantizado (Q4_K_M a ~3.5GB en memoria) en la Pi 5 de 8GB deja suficiente margen para el sistema operativo y una ventana de contexto razonable.

Google y NVIDIA apuntan explícitamente a este despliegue. El Jetson AI Lab de NVIDIA proporciona contenedores y tutoriales para ejecutar Gemma 4 E2B y E4B en Jetson Orin Nano, que tiene un perfil de hardware comparable al de la Pi 5 pero con una GPU pequeña. Las características arquitectónicas que permiten esto son los Per-Layer Embeddings (que pueden cachearse para una carga más rápida y menor uso de memoria) y el KV cache compartido (que reduce la sobrecarga de memoria para el contexto).

Las implicaciones para IoT, robótica y edge computing son significativas. Una cámara de seguridad con una Raspberry Pi ahora puede hacer razonamiento multimodal sobre su propio feed de video. Un hub de hogar inteligente puede entender comandos de voz y procesar imágenes de cámaras sin conectarse jamás a internet. Un dron agrícola puede clasificar la salud de los cultivos a partir de fotos aéreas usando cómputo a bordo.

iPhone y Android: Google AI Edge Gallery

Cuatro días después del lanzamiento de Gemma 4, Google publicó Google AI Edge Gallery, una app gratuita que ejecuta Gemma 4 E2B completamente en tu iPhone o teléfono Android. Sin nube. Sin API key. Sin necesidad de cuenta de Google. El modelo se descarga una vez (~3.5GB) y corre localmente usando el runtime LiteRT-LM de Google.

La app alcanzó 719 puntos y 201 comentarios en Hacker News en menos de 18 horas. Y con razón: no solo ejecuta un chatbot. Incluye mobile actions, llamadas a herramientas que permiten al modelo on-device activar funciones nativas del teléfono. Encender la linterna, abrir Maps en una ubicación, poner un temporizador. Todo decidido por el LLM, todo ejecutado localmente.

El rendimiento es sorprendentemente usable. Los benchmarks oficiales de Google muestran 56 tokens/seg en iPhone y 52 tok/s en Qualcomm. Los reportes de la comunidad varían según el dispositivo: ~40 tok/s vía MLX en iPhones recientes, 29 tok/s en un Samsung Galaxy S25 edge y ~12 tok/s en un iPhone 14 (chip A15 más antiguo). Un usuario construyó una demo en tiempo real de audio/video-in y voz-out en un MacBook con el E2B y estimó que el mismo pipeline podría correr en un iPhone 17 Pro.

Los primeros testers en HN ya están imaginando lo que esto habilita. Un desarrollador que construye apps con privacidad prioritaria para profesores lo describió como exactamente lo que necesitan: IA local que respeta las estrictas leyes de privacidad educativa sin que ningún dato salga del dispositivo. Otro señaló que Apple supuestamente está trabajando con Google para integrar Gemma en una futura versión de Siri. El autor original del post lo resumió así: “Esto me da esperanza para un futuro Siri, al estilo ‘Her’.”

La app también está disponible en Android, y forma parte de la iniciativa más amplia AI Edge de Google. Actualmente corre en la GPU, pero el soporte para NPU (el Neural Engine de Apple tiene 35 TOPS contra los 7 TFLOPS de la GPU) podría traer otro salto significativo en velocidad.

Antes de intentarlo: revisa canirun.ai

Antes de intentar ejecutar cualquier variante de Gemma 4 localmente, revisa canirun.ai. El sitio detecta tu GPU, VRAM, ancho de banda de memoria, RAM y núcleos de CPU, y luego muestra exactamente qué modelos y niveles de cuantización tu hardware puede realmente ejecutar. Lista todas las variantes de Gemma con requisitos de memoria en cada nivel de cuantización desde Q2_K hasta F16.

Esto es particularmente valioso para Gemma 4 porque los requisitos de memoria varían drásticamente en la familia:

  • E2B Q4_K_M: ~3.5GB (corre en una Raspberry Pi 5 de 8GB)
  • E4B Q4_K_M: ~5GB (corre en teléfonos con 8GB de RAM)
  • 26B-A4B Q4_K_XL: ~14GB (cabe en una GPU de 16GB con contexto limitado)
  • 31B Q4_K_XL: ~18GB (necesita una GPU de 24GB, ajustado en contexto)
  • 31B BF16: ~62GB (necesita un H100 de 80GB o equivalente)

La diferencia entre “corre rápido” y “se muere haciendo swap” puede ser unos pocos cientos de megabytes de VRAM. canirun.ai elimina las conjeturas. También recomienda Ollama (versión 0.6+) como runtime por defecto y muestra los comandos exactos para empezar.

El MoE 26B-A4B: la variante de velocidad

El modelo 26B Mixture-of-Experts es el primer lanzamiento MoE de Gemma. Activa solo 3.8 mil millones de parámetros por token de 25.2B totales, usando 128 experts con 8 activos más 1 expert compartido por forward pass. Puntúa 1441 en Arena AI, solo 11 puntos detrás del denso 31B, ubicándose en el puesto #6 entre modelos abiertos.

El 26B está diseñado para uso interactivo sensible a la latencia. En un MacBook Air M4 con 32GB de RAM, los usuarios reportan ejecutar la cuantización Q4_K_XL con contexto de 32K cómodamente. Un usuario en HN hizo benchmarks con una RX 7900 XTX de 24GB y obtuvo resultados impresionantes:

llama-batched-bench -hf unsloth/gemma-4-26B-A4B-it-GGUF:UD-Q4_K_XL
| Context |  TG tok/s |
|---------|-----------|
|    1K   |   120.29  |
|    2K   |   119.04  |
|    4K   |   117.08  |
|    8K   |   114.87  |
|   16K   |   107.65  |
|   32K   |   100.12  |
|   64K   |    88.12  |
|  128K   |    71.25  |

100+ tokens/seg a 32K de contexto y 71 tok/s a los 128K completos en una sola GPU de consumo. Eso es suficientemente rápido para uso interactivo en tiempo real, incluso en contextos muy largos. La velocidad de procesamiento de prompts es aún más impresionante: 2,650 tokens/seg a 2K de contexto, manteniéndose por encima de 960 tok/s incluso a los 128K completos.

Tanto los pesos unquantized bfloat16 del 31B como del 26B caben en un solo NVIDIA H100 de 80GB. Las versiones cuantizadas corren en GPUs de consumo desde la RTX 4060 en adelante.

Capacidades multimodales: qué funciona realmente

El equipo de Hugging Face realizó pruebas extensivas en todas las modalidades. Aquí está un desglose detallado de qué funciona en cada tamaño de modelo.

Generación de HTML a partir de capturas de pantalla

Le dieron a cada modelo una captura de pantalla de una landing page y le pidieron “Write HTML code for this page” con thinking habilitado y 4000 max tokens. Los cuatro modelos produjeron HTML funcional. Las versiones 31B y 26B fueron reproducciones casi pixel-perfect. Incluso el E2B produjo una aproximación reconocible. Esto tiene aplicaciones obvias para flujos de trabajo de diseño a código y testing automatizado de interfaces.

Comprensión de video

Los modelos más pequeños (E2B, E4B) procesan video con audio. Los modelos más grandes procesan solo los fotogramas del video (sin pista de audio). A pesar de no haber sido específicamente post-entrenados con datos de video, todos los modelos demuestran comprensión de video. El E4B describió correctamente una escena de concierto incluyendo los temas líricos de la canción (“struggles and disillusionment of modern life, specifically the feeling of being stuck”). El 31B, trabajando sin audio, describió con precisión la escena visual, las acciones del artista y el montaje del escenario.

Function calling multimodal con thinking

Aquí es donde Gemma 4 se pone interesante para los constructores de agentes de IA. Puedes definir herramientas, mostrarle al modelo una imagen y pedirle que use las herramientas basándose en lo que ve. La traza de thinking muestra la cadena de razonamiento del modelo: “Analizar la imagen… identificar el punto de referencia… determinar que la ciudad es Bangkok… formular la llamada a la herramienta.” Incluso el E2B sigue este patrón, aunque su razonamiento es más verboso.

Combinado con la salida JSON estructurada y las instrucciones de sistema nativas, esto hace de Gemma 4 una base lista para producción para agentes multimodales. El hecho de que el function calling funcione en un modelo lo suficientemente pequeño para correr en un teléfono significa que puedes construir agentes que operen completamente offline.

Ecosistema de inferencia: soporte desde el día uno en todas partes

Una de las historias de lanzamiento más fuertes de Gemma 4 es la amplitud de integración desde el día uno. Google claramente invirtió en asegurar que cada motor de inferencia importante funcionara en el lanzamiento.

llama.cpp

Soporte de imagen+texto desde el primer día. Inicia un servidor compatible con OpenAI con un solo comando:

llama-server -hf ggml-org/gemma-4-E2B-it-GGUF

Esto funciona con LM Studio, Jan y agentes de código como Pi. Los checkpoints GGUF cuantizados tanto de ggml-org oficial como de Unsloth están disponibles. Las cuantizaciones “Dynamic 2.0” de Unsloth son particularmente interesantes: analizan cada capa y ajustan selectivamente el tipo de cuantización por capa, usando un dataset de calibración curado a mano de 1.5M+ tokens. Los usuarios reportan que estas entregan mejor calidad que las cuantizaciones GGUF estándar al mismo ancho de bits.

Configuraciones para agentes de código

El blog de Hugging Face incluye archivos de configuración completos para cuatro agentes de código:

  • Hermes: simplemente ejecuta hermes model después de iniciar el servidor de llama.cpp
  • OpenClaw: ejecuta openclaw onboard
  • Pi: define ~/.pi/agent/models.json apuntando a localhost:8080/v1
  • Open Code: define ~/.config/opencode/opencode.json con el proveedor compatible con OpenAI

Esto significa que puedes convertir tu laptop en un asistente de código IA completamente local. Sin API keys, sin dependencia de la nube, sin datos saliendo de tu máquina. Combinado con la ventana de contexto de 256K del 31B, puedes pasar repositorios completos en un solo prompt.

MLX (Apple Silicon)

Soporte multimodal completo vía mlx-vlm. La característica notable: TurboQuant, que entrega la misma precisión que el baseline sin comprimir mientras usa ~4 veces menos memoria activa y corre significativamente más rápido de extremo a extremo. Esto hace que la inferencia de contexto largo sea práctica en Macs sin sacrificar calidad:

mlx_vlm.generate 
  --model "mlx-community/gemma-4-26B-A4B-it" 
  --prompt "Your prompt here" 
  --kv-bits 3.5 
  --kv-quant-scheme turboquant

transformers (Python)

La nueva clase AutoModelForMultimodalLM y el pipeline any-to-any hacen la inferencia directa. El chat template integrado maneja el formato, el modo de thinking, la extracción de audio del video y las definiciones de herramientas. Este es el camino para fine-tuning con TRL, PEFT y bitsandbytes.

WebGPU

El E2B corre en el navegador vía transformers.js. Hugging Face publicó una demo funcional. Esto abre patrones de despliegue completamente nuevos: aplicaciones de IA que corren del lado del cliente sin ninguna infraestructura backend.

Infraestructura NVIDIA

NVIDIA publicó guías de despliegue para todo su stack de hardware:

  • DGX Spark: GB10 Grace Blackwell Superchip con 128GB de memoria unificada. Ejecuta el 31B en BF16 nativamente. Incluye recetas de NeMo Automodel para fine-tuning.
  • Jetson Orin Nano: E2B y E4B para robótica e IA en el edge. Contenedores disponibles en Jetson AI Lab.
  • GPUs RTX: Inferencia cuantizada vía Ollama y llama.cpp. Los usuarios de RTX Pro también pueden usar vLLM.
  • NVIDIA NIM: Microservicios optimizados pre-empaquetados para despliegue en producción. API gratuita disponible para prototipos en build.nvidia.com.
  • NVFP4: Checkpoint cuantizado a 4 bits para GPUs Blackwell usando NVIDIA Model Optimizer. Precisión de 4 bits con exactitud casi idéntica a 8 bits.

Fine-tuning: desde el día uno, con salvedades

El soporte de fine-tuning existe pero tuvo un lanzamiento accidentado. Múltiples early adopters reportaron problemas en cuestión de horas:

  1. HuggingFace Transformers no reconocía la arquitectura gemma4 al principio. Requería instalar desde source.
  2. PEFT no podía manejar Gemma4ClippableLinear, un nuevo tipo de capa en el vision encoder. Requería un monkey-patch.
  3. Un nuevo campo mm_token_type_ids es requerido durante el entrenamiento incluso para datos solo de texto. Requería un data collator personalizado.

Los tres problemas tuvieron reportes de bugs archivados y respuestas en cuestión de horas. Unsloth Studio proporcionó soporte de fine-tuning desde el día uno con una interfaz que maneja estos casos extremos. El equipo de TRL de HuggingFace también publicó una demo notable: entrenar a Gemma 4 para conducir en el simulador de conducción CARLA, donde el modelo ve la carretera a través de una cámara, decide acciones y aprende de los resultados. Después del entrenamiento, cambia de carril consistentemente para evitar peatones.

Para fine-tuning en producción, NVIDIA NeMo Automodel proporciona recetas para supervised fine-tuning (SFT) y LoRA eficiente en memoria directamente desde checkpoints de HuggingFace, sin necesidad de conversión de formato.

Qué significa esto para Qwen, Llama y el paradigma de “más grande es mejor”

El panorama de modelos abiertos a principios de abril de 2026 presenta un cuadro de eficiencia contundente. Estos son los principales modelos abiertos por puntuación de Arena AI:

  • GLM-5 (Z.ai): 1452, ~750B parámetros, MIT
  • Kimi-K2.5-Thinking (Moonshot): 1451, ~1T+ parámetros, MIT modificada
  • Gemma 4 31B (Google): 1452, 31B denso, Apache 2.0
  • Qwen 3.5-397B-A17B (Alibaba): 1450, 397B MoE (17B activos), Apache 2.0
  • Qwen 3-235B-A22B-Instruct: 1418, 235B MoE (22B activos), Apache 2.0
  • DeepSeek-R1-0528: 1426, tamaño desconocido, MIT

Gemma 4 31B iguala o supera a todos ellos con 10 a 30 veces menos parámetros totales. Las implicaciones se propagan por cada capa del stack de IA.

Costo de servicio e infraestructura

Ejecutar un modelo denso de 31B cuesta una fracción de servir un MoE de 397B. Menos VRAM, menos ancho de banda, menos electricidad, menos dinero por token. El 31B cabe en un solo H100 en BF16; un modelo de 397B necesita una configuración multi-GPU incluso con cuantización. Para empresas desplegando a escala, esta es potencialmente la diferencia entre un modelo de negocio viable y uno que pierde dinero.

Esto es especialmente relevante a medida que la curva de costos de inferencia de frontera recibe más atención. Si dos modelos producen calidad de salida equivalente, el que es 13 veces más pequeño gana en economía unitaria siempre.

Accesibilidad de fine-tuning

Puedes hacer fine-tuning de un modelo de 31B con LoRA en una sola GPU de consumo (24GB de VRAM es suficiente para Q4 + LoRA). Hacer fine-tuning de un MoE de 397B requiere un clúster multi-GPU con cientos de gigabytes de VRAM agregada. Esta no es solo una diferencia de costo; es una diferencia de accesibilidad. Investigadores en universidades, startups sin clústeres de GPUs y desarrolladores individuales ahora pueden hacer fine-tuning de un modelo de calidad frontier en su estación de trabajo. Eso no era posible con los modelos más grandes.

Despliegue en el edge

Ningún modelo MoE con 397B parámetros totales corre en un teléfono. Punto. Incluso con solo 17B parámetros activos, el modelo de 397B necesita todos los pesos de sus experts cargados (o frecuentemente intercambiados) en memoria. El E2B de Gemma 4 corre en un teléfono, una Raspberry Pi, un Jetson Nano y en el navegador. El E4B corre en cualquier laptop de gama media. El MoE 26B corre en una GPU de gaming. El denso 31B corre en una estación de trabajo.

Esta diversidad de tamaños significa que una sola familia de modelos puede servir cada nivel de despliegue, desde la nube hasta el edge, con comportamiento consistente y compatibilidad de fine-tuning.

El contraargumento de velocidad

Gemma 4 no está exento de debilidades. Los benchmarks de la comunidad revelan brechas de rendimiento significativas contra Qwen 3.5:

  • Velocidad de generación de tokens: Un usuario midió 11 tok/s para Gemma 4 26B-A4B vs 60+ tok/s para Qwen 3.5 35B-A3B en la misma RTX 5060 Ti 16GB. El denso 31B alcanza 18-25 tok/s en GPUs NVIDIA duales. Es razonable pero no rápido.
  • VRAM para contexto: Una prueba mostró que Gemma 4 27B Q4 solo cabía con 20K de contexto en una 5090, mientras que Qwen 3.5 27B Q4 cabía con 190K en la misma tarjeta. El KV cache consume más.
  • Eficiencia computacional general: Qwen 3.5-397B activa solo 17B parámetros por token (45% de los 31B de Gemma 4). A calidad equivalente, Qwen 3.5 hace menos cómputo por token.

Estos son problemas reales para despliegues en producción donde la latencia y el throughput importan. El modelo MoE de Gemma 4 (26B-A4B) teóricamente aborda la preocupación del cómputo al activar solo 3.8B parámetros, pero la velocidad de inferencia actual no refleja esa ventaja en la práctica.

Posibles explicaciones: soporte de cuantización inmaduro (los modelos QAT aún no se han publicado), las optimizaciones de motores de inferencia no se han puesto al día con la nueva arquitectura, o el KV cache compartido y PLE añaden overhead que compensa la reducción de parámetros. Los parámetros de sampling recomendados por Google (temperature 1.0, top_p 0.95, top_k 64) también podrían impactar el throughput.

El argumento de la trayectoria

Los problemas de velocidad y VRAM tienden a mejorar con el tiempo. Los modelos con quantization-aware training (QAT) llegaron semanas después de Gemma 3 y mejoraron drásticamente la calidad de inferencia cuantizada. El ecosistema de motores de inferencia (llama.cpp, vLLM, SGLang) optimiza constantemente para modelos populares. Las optimizaciones específicas de arquitectura para el KV cache compartido y PLE presumiblemente están en progreso.

Lo que es más difícil de arreglar es la inteligencia bruta por parámetro. Si la receta de entrenamiento de Google puede extraer rendimiento de 1452-ELO de 31B parámetros hoy, la pregunta se convierte en: ¿qué pasa cuando aplican la misma receta a 100B parámetros? ¿O 200B? La extrapolación lineal es incómoda para todos los demás laboratorios en la carrera de modelos abiertos.

El veredicto de la comunidad tras 24 horas

El hilo de Hacker News alcanzó 1,678 puntos y 445 comentarios en un día. Estas son las opiniones destacadas.

Los entusiastas

Daniel Hanchen (fundador de Unsloth), quien trabaja estrechamente con todos los laboratorios importantes de modelos, llamó a Gemma 4 “sooooo good!!!” y dijo que Google es “definitely hands down” el laboratorio más colaborativo con el que trabajar, seguido por Qwen, Meta y Mistral. Cuando le preguntaron cuál es el mejor modelo open source, respondió: “Tbh Gemma-4 haha.”

Un usuario que ejecuta OCR, búsqueda de texto completo, embeddings y resumen de registros de tierras de los 1800s localmente describió el impacto: “La gente está tan emocionada de que ahora pueden buscar los registros en múltiples idiomas que una espera de 1 minuto para procesar el documento les parece nada.” Esto era usando modelos Qwen de la generación anterior; planeaban migrar a Gemma 4 inmediatamente.

Otro usuario probando generación de código Nix encontró que Gemma 4 26B-A4B era “significativamente mejor que qwen3.5-35b-a3b” y compartió su configuración de llama-cli para un MacBook Air M4 de 32GB.

Los escépticos

Un comentarista de Hugging Face lo llamó un “lanzamiento algo decepcionante” y deseó que “las grandes empresas tecnológicas tomaran ejemplo de OpenAI y lanzaran OSS realmente competitivo.” Añadió: “Pero los modelos son estables. Definitivamente más consistencia y eficiencia de tokens que Qwen.”

Múltiples usuarios señalaron la brecha de velocidad de inferencia y cuestionaron si las puntuaciones de Arena AI cuentan la historia completa. Un análisis en dev.to concluyó: “Para despliegues en inglés solamente, optimizados para benchmarks y críticos en velocidad, Qwen 3.5 sigue siendo la mejor opción.”

Los modelos ausentes

Varios comentaristas expresaron decepción por lo que no se lanzó:

  • No hay modelo denso de 9-12B. El 12B de Gemma 3 era popular y no hay una ruta de actualización directa. La brecha entre el E4B (4.5B efectivos) y el MoE 26B es demasiado amplia para muchos casos de uso.
  • No hay modelo de 100B+. Había rumores de un 120B que no se materializó. Varios usuarios señalaron que esto habría sido transformador dado el rendimiento del 31B.
  • No hay modelos QAT en el lanzamiento. Las variantes QAT de Gemma 3 mejoraron significativamente la calidad de inferencia cuantizada. La comunidad espera estos para Gemma 4 pero aún no están disponibles.

Casos de uso reales emergiendo

En menos de 24 horas, la gente ya estaba desplegando Gemma 4 para:

  • OCR y traducción de documentos históricos (registros de tierras de los 1800s, múltiples idiomas)
  • Análisis local de PDFs con automatización de flujos de trabajo n8n y Ollama
  • Generación de código como asistente de código local (Nix, Python, propósito general)
  • Plataformas educativas para niños (un usuario dijo “esto encaja exactamente en nuestro dominio de educación infantil”)
  • Procesamiento de documentos sensibles a la privacidad donde las APIs en la nube requieren redacción
  • Análisis financiero (un usuario reportó que el E2B da “respuestas significativamente mejores que Qwen 3.5 4B” para finanzas)

Qué viene después

La comunidad está esperando varias cosas que determinarán si Gemma 4 consolida su posición o es superado:

Modelos QAT (quantization-aware training): Llegaron semanas después de Gemma 3 y mejoraron drásticamente la inferencia cuantizada. El E2B y E4B serán los más beneficiados, ya que los dispositivos edge dependen completamente de la inferencia cuantizada. Se esperan en días o semanas.

Optimizaciones de motores de inferencia: La brecha de velocidad actual contra Qwen 3.5 podría cerrarse a medida que llama.cpp, vLLM y otros motores añadan optimizaciones específicas de arquitectura para el KV cache compartido, PLE y el routing MoE.

Un modelo denso de 9-12B: Esto llenaría el hueco más grande en la alineación y daría a los usuarios del 12B de Gemma 3 una ruta de actualización limpia.

Variantes abliterated: Ahora completamente legales bajo Apache 2.0. Al menos una ya existe. Más seguirán a medida que investigadores de seguridad y comunidades de modelos sin censura trabajen con la arquitectura.

La pregunta más grande: si Google puede igualar modelos MoE de 400B con un modelo denso de 31B, ¿cómo será la siguiente generación? Un Gemma 5 de 100B usando esta receta de entrenamiento podría potencialmente igualar a modelos propietarios de frontera como Gemini 3 Pro (Arena 1492) o Claude Opus 4.6 (Arena 1490). Esa sería la primera vez que un modelo abierto compite genuinamente con las mejores ofertas propietarias.

La conclusión

Gemma 4 es la mayor inteligencia por parámetro jamás distribuida en un modelo abierto. El modelo denso de 31B empata en el leaderboard de Arena AI con modelos 10-30 veces su tamaño. El E2B pone IA multimodal en una Raspberry Pi de $80. Toda la familia es Apache 2.0, lo que significa cero minas legales de licencia para uso comercial.

No es perfecto. La velocidad de inferencia está por detrás de Qwen 3.5. El consumo de VRAM para contexto es peor. Las herramientas de fine-tuning necesitaron parches en el lanzamiento. No hay un modelo de 9-12B en la alineación.

Pero la trayectoria es clara. La carrera de modelos abiertos acaba de pasar de “quién puede entrenar más parámetros” a “quién puede extraer más inteligencia por parámetro.” Google, extrayendo de la misma investigación de Gemini 3 que impulsa sus modelos propietarios, parece estar ganando esa carrera de manera convincente.

Para los desarrolladores, la conclusión práctica: ahora puedes ejecutar un modelo de IA multimodal de calidad frontier en tu laptop, tu teléfono o una computadora de placa única de $80. Entiende imágenes, audio, video y 140 idiomas. Puede llamar funciones, razonar a través de problemas de múltiples pasos y generar código de calidad para producción. Es gratuito, es abierto y es Apache 2.0.

Esa combinación no existía hace 48 horas.

The user wants me to translate an HTML blog post from English to Spanish, keeping all HTML tags intact, not translating brand names, product names, technical terms, etc. Let me do this carefully.

English|Español|Italiano