Ember-1 vs Gemma 4 12B: Uno te alquila menos tokens, el otro te entrega los pesos

Ember-1 y Gemma 4 12B no compiten por la misma línea en una orden de compra, y la forma más rápida de ver por qué es preguntar qué tendrías en propiedad al final de cada mes. Gemma 4 12B es el modelo multimodal denso de 11,95 mil millones de parámetros de Google, lanzado el 3 de junio de 2026 bajo Apache 2.0: lo descargas y el checkpoint es tuyo. Ember-1 es un derivado especializado de Kimi K3, de Moonshot AI, creado por Fireworks Research, publicado el 23 de septiembre de 2026 como vista previa de investigación en la propia plataforma sin servidor del proveedor: lo invocas y no posees nada más que la factura. Uno es un argumento de alquiler con opción a compra sobre tokens; el otro es una compra de capital. Si los pones uno al lado del otro, la comparación útil no es qué modelo es mejor, porque nada de lo publicado permite resolverlo. Es cuál de las dos formas de adquisición encaja con lo que estás construyendo.

Los dos contratos, expuestos llanamente.

Gemma 4 12B es una versión final de pesos abiertos. Goog​le publica los pesos, la arquitectura, la hoja de benchmarks y la licencia, y una comunidad de entornos de ejecución —llama.cpp, vLLM, MLX, SGLang, Transformers— lo sirve en hardware que tú controlas. El costo de un token después de la compra es electricidad y amortización, no una partida de un proveedor. Lo que sacrificas son las cosas que los pesos abiertos siempre cuestan: tú asumes la planificación de capacidad, y tu techo de calidad queda fijado en 11,95B parámetros.

Ember-1 es lo inverso. No hay pesos que descargar —existe como una opción de servicio en la plataforma del propio proveedor— y no hay un precio publicado. Lo que ofrece en cambio es una afirmación más limitada, ejecutada sobre un modelo mucho más grande: la precisión de Kimi K3, con aproximadamente un 40 % menos de tokens para llegar a ella. Fireworks Research lo entrenó específicamente para acortar las trazas de razonamiento sin cambiar las respuestas, y reporta que la longitud del razonamiento podría reducirse entre un 35 y un 50 % sin pérdida de precisión en siete benchmarks y dos pruebas A/B de producción de clientes. Cada cifra procede del proveedor y no ha sido reproducida.

El valor que tiene el argumento del token depende enteramente de quién paga por los tokens.

El argumento de venta de Ember-1 asume una facturación por token. Esa suposición es correcta para el público para el que fue diseñado: equipos que ejecutan bucles de agentes largos contra un modelo frontera alojado, donde Fireworks Research señala que Kimi K3 puede gastar más del 90 % de los tokens generados en razonamiento interno, y donde cada turno reproduce turnos anteriores, de modo que el razonamiento previo se vuelve a leer y se vuelve a facturar. En ese contexto, reducir la longitud de la traza es un recorte directo a la factura mensual, y el resultado A/B de 29,9K tokens de salida frente a los 49,3K de K3 es el número que importa.

Aplica el mismo modelo a los términos de Gemma 4 12B y el argumento se desvanece. Cuando autoalojas un checkpoint Apache-2.0, los tokens de razonamiento adicionales cuestan tiempo de reloj y ocupación de GPU, no dólares por millón. Una traza de razonamiento verbosa en tu propio portátil de 16 GB es una respuesta más lenta, no una factura más grande. Eso no hace que la ineficiencia sea inofensiva —en un bucle de agente, todavía se acumula, y todavía se manifiesta como latencia—, pero el tipo de cambio es diferente, y tratar una reducción del 40 % en tokens como un ahorro del 40 % en hardware autoalojado es un error de categoría.

La hoja de especificaciones, una línea por dimensión

• Qué es — Ember-1: un derivado de vista previa de investigación de Kimi K3, reentrenado para un razonamiento más breve. Gemma 4 12B: un modelo multimodal denso de 11.95B con pesos abiertos de la familia Gemma 4 de Google.

• Pesos — Ember-1: ninguno publicado; solo se ofrece a través de la plataforma del proveedor. Gemma 4 12B: Apache 2.0, descargable, sin restricciones de acceso.

• Tamaño — Ember-1: no revelado; heredado de la arquitectura de Kimi K3. Gemma 4 12B: 11,95B denso, 48 capas, aproximadamente 18GB de pesos en BF16.

• Ventana de contexto — Ember-1: no publicada para la vista previa; su modelo base tiene 1.048.576 tokens. Gemma 4 12B: 256K tokens.

• Entradas — Ember-1: texto. Gemma 4 12B: texto, imagen y audio mediante un diseño unificado sin codificador, con video incluido por algunas fuentes.

• Precio — Ember-1: ninguno publicado; los dólares de la hoja de referencia se calculan a partir de la tarifa de Kimi K3. Gemma 4 12B: gratis para descargar; pagas el hardware.

• Requisitos mínimos de hardware — Ember-1: lo que el proveedor programe. Gemma 4 12B: 16 GB de VRAM o memoria unificada, según el posicionamiento de Google.

• Evidencia — Ember-1: benchmarks de proveedores y dos pruebas A/B realizadas por el proveedor, sin reproducir. Gemma 4 12B: evaluaciones reportadas por Google más un ecosistema independiente de ejecuciones locales.

Qué publica Gemma 4 12B, y cómo lee

Los propios números de Google para Gemma 4 12B lo sitúan entre el Gemma 4 E4B, dimensionado para el edge, y el 26B MoE más grande: GPQA Diamond 78.8%, MMLU Pro 77.2%, AIME 2026 sin herramientas 77.5%, LiveCodeBench v6 72.0, ELO de Codeforces 1659, promedio de τ-2 69.0%, MMMU Pro 69.1%, DocVQA 94.9 y BigBench Extra Hard 53.0%. Esos también son reportados por el proveedor —Google evaluó su propio modelo y publicó la hoja—, pero tienen la ventaja de describir un checkpoint que cualquiera puede descargar y volver a ejecutar, y por eso las afirmaciones de pesos abiertos tienden a obtener confirmación de terceros rápidamente, mientras que las afirmaciones de vistas previas cerradas no.

La verdadera distinción del modelo es estructural, no numérica. Gemma 4 12B no tiene un codificador de visión o audio separado: los parches de imagen y las formas de onda de audio se proyectan directamente en el espacio de tokens, que es lo que permite que un modelo de 12B acepte una captura de pantalla o una grabación como entrada. También incluye borradores de predicción multitoken para decodificación especulativa, que es una característica de latencia más que de calidad: el tipo de cosa que importa cuando ejecutas el modelo tú mismo y cada milisegundo de prefill lo pagas tú.

Donde los dos realmente chocan

Ambos modelos se comercializan para la codificación agéntica y el uso de herramientas, y este es el único terreno en el que existe una elección real. La cifra de Ember-1 en Terminal Bench 2.1 es del 82,0 % frente al 80,9 % de Kimi K3 Max, con un 51,9 % menos de tokens; su resultado en SWE-bench Verified es del 92,2 % frente al 93,2 % de K3 Max. Gemma 4 12B no tiene ninguna cifra de Terminal Bench ni de SWE-bench en el conjunto publicado por Google — su evidencia agéntica es τ-2 con un 69,0 %. Por eso no se pueden alinear los dos en un benchmark compartido, y cualquier artículo que lo haga se está inventando la comparación.

Lo que se puede decir es que ocupan puntos distintos en una curva de costos. Si tu carga de trabajo de agente se ejecuta contra un modelo de frontera alojado y la factura está dominada por tokens de razonamiento, Ember-1 ataca exactamente ese término — a costa de una ventana de acceso de dos semanas y sin tarifa publicada. Si tu carga de trabajo necesita ejecutarse en hardware que controlas, manejar una captura de pantalla o sobrevivir a que un proveedor decida no continuar una vista previa, Gemma 4 12B es la única de las dos que responde siquiera a la pregunta.

Un camino intermedio, y dónde encontrarlo

Hay una tercera opción en torno a la cual no está construido el marketing de ninguno de los dos modelos: usar los niveles más grandes de Gemma 4 como la mitad alojada de un híbrido. OrcaRouter enruta el Gemma 4 26B-A4B de Google y el Gemma 4 31B junto con más de 200 otros modelos detrás de una sola API al precio de lista del proveedor con 0% de margen, de modo que la misma clave que llega a un Gemma de tamaño medio también llega a los modelos frontera para los que de otro modo necesitarías un segundo contrato. El propio Gemma 4 12B no está en nuestra plataforma, y Ember-1 tampoco — si necesitas el 12B localmente, descárgalo; si quieres probar primero si un Gemma más grande cierra la brecha, esa prueba cuesta un endpoint.

Esa configuración también es la forma honesta de evaluar una vista previa de investigación. La conmutación por error automática entre proveedores significa que un modelo que desaparece de una ventana de vista previa no se lleva tu aplicación consigo, que es el riesgo específico que introduce el estado de lanzamiento de Ember-1 y el riesgo específico que nada en su tabla de benchmarks aborda.

¿Cuál va en tu hoja de ruta?

Elige Gemma 4 12B si la propiedad es un requisito — privacidad, funcionamiento sin conexión, un piso de costos fijo, o un producto que tenga que seguir funcionando si un proveedor cambia de opinión. Su techo publicado es más bajo que el de un derivado de frontera y su entrada multimodal es genuinamente diferenciadora, y ninguno de esos hechos depende de la hoja de ruta de nadie más.

Elige Ember-1 si tu problema es una factura por token en ejecuciones largas de agentes y puedes asumir el riesgo de la versión preliminar. Ejecútalo en modo sombra contra tu proveedor actual durante las dos semanas que tengas, mide los tokens por tarea completada con tu propio tráfico y trata el 40% como una hipótesis, no como una tarifa. Lo que no deberías hacer es elegir entre ellos en función de la calidad, porque nadie —incluido el laboratorio que creó Ember-1— ha publicado una comparación que te lo permita.

Lo más importante es que estos dos lanzamientos representan las dos formas en que se está vendiendo la capacidad a finales de 2026. Un laboratorio publica un checkpoint y deja que el ecosistema encuentre su nivel; otro toma un modelo que alguien más entrenó, mejora un eje de su comportamiento y vende la mejora como servicio. Ambos son legítimos, y fallan de maneras distintas: los pesos abiertos fallan lentamente y en público, las previews fallan de repente y por anuncio.