Ember-1 reduce el razonamiento de Kimi K3 en un 40 % — y la letra pequeña es la historia

El número que se citará es el 40 %. Fireworks Research publicó Ember-1 el 23 de septiembre de 2026, describiéndolo como un derivado especializado de Kimi K3, de Moonshot AI, que mantiene la precisión de K3 a la vez que consume aproximadamente un 40 % menos de tokens para lograrlo. Es una afirmación real e inusualmente específica, y llega acompañada de tres cosas: una hoja de evaluación comparativa completa con columnas de reducción de tokens, dos pruebas A/B de clientes a partir de tráfico de programación en producción y un estado de lanzamiento que no es disponibilidad general. Ember-1 está disponible como vista previa de investigación, en la propia plataforma sin servidor del proveedor, con una ventana de acceso de dos semanas y una decisión sobre su permanencia que depende de la demanda. Entender qué parte de esto es un producto ya lanzado y qué parte es un resultado de investigación bien argumentado es todo el ejercicio.

También hay una colisión de nombres que conviene aclarar antes que nada. Un proyecto de investigación abierto e independiente llamado Ember (v0.1.5, de Slow Lit Labs) dedicó 2026 a publicar evaluaciones de coherencia de horizonte largo, y no tiene ninguna relación con este modelo. Cualquier cosa que leas sobre que Ember no logra superar a Qwen3-8B en configuraciones de inferencia equivalentes se refiere a ese proyecto. Ember-1, el tema aquí, es un derivado de Kimi K3 de Fireworks Research.

Qué es Ember-1 en realidad

Ember-1 no es una arquitectura nueva ni un modelo base nuevo. Es Kimi K3, reentrenado para razonar de forma más concisa. Fireworks Research realizó más de 50 experimentos de entrenamiento y más de 200 evaluaciones en su propia pila de entrenamiento sin servidor, en matemáticas, programación, seguimiento de instrucciones, conversación, búsqueda, uso de herramientas e ingeniería de software, con el objetivo explícito de eliminar el razonamiento que no cambia la respuesta. El laboratorio afirma 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 conjuntos de tráfico de producción de clientes. Cada una de esas cifras es reportada por el proveedor y no ha sido reproducida de forma independiente; ningún tercero ha publicado una ejecución de Ember-1 hasta el momento de escribir esto.

El planteamiento importa porque la alternativa obvia ya existía. Kimi K3 viene con ajustes de esfuerzo de razonamiento, y la forma barata de gastar menos tokens es bajar el esfuerzo. Fireworks Research dice que lo intentó y que el ajuste bajo sacrificó demasiada calidad, un resultado familiar para cualquiera que haya ajustado niveles de esfuerzo en un modelo de razonamiento. La afirmación de Ember-1 es que el dial de esfuerzo es tosco y el reentrenamiento es fino.

Por qué los tokens de razonamiento valen tanto esfuerzo

El costo de un modelo de razonamiento no está dominado por su respuesta. Fireworks Research señala que K3 puede gastar más del 90% de sus tokens generados en razonamiento interno antes de escribir algo que vea un usuario. En una única solicitud, eso es solo costoso. En un bucle de agente multiturno, se acumula, porque cada turno reproduce la conversación anterior, así que los rastros de razonamiento de turnos anteriores se vuelven a leer y se vuelven a facturar en cada llamada posterior. Fireworks Research describe que el contexto crece de forma aproximadamente cuadrática con el número de turnos. Ese es el objetivo real de esta versión, y es por eso que la métrica principal es aproximadamente un 40% menos de tokens en lugar de un salto de calidad.

El mecanismo también explica el riesgo. La compresión que elimina deliberación desperdiciada no tiene costo; la que elimina un paso que el modelo necesitaba, no. El modo de fallo ampliamente reportado de la reducción del razonamiento demasiado agresiva es un modelo que se salta una verificación intermedia y salta a una conclusión, lo cual, en un agente, se manifiesta mucho después como una llamada incorrecta a una herramienta en lugar de como una frase incorrecta. El énfasis repetido de Fireworks Research en la calidad equivalente se lee como una respuesta a esa inquietud, y los números A/B son lo más parecido a evidencia de ello — con la advertencia habitual de que los conjuntos de prueba, los criterios de aprobación y los tamaños de muestra fueron elegidos por la parte que hace la afirmación.

La hoja de referencia, con su procedencia adjunta

Estas son las cifras de Fireworks Research, no reproducidas. La columna de la derecha es la parte que vale la pena leer con atención: empareja cada puntuación con cuántos tokens y dólares requirió en relación con K3 Max.

Eres un motor profesional de localización de software. Traduce el mensaje del usuario al español. El texto contiene elementos de lista numerados. Para cada elemento numerado, traduce el texto del elemento, manteniendo la numeración. Traduce de forma natural, como lo haría un motor profesional de localización de software. No añadas explicaciones ni texto adicional. Salida solo el texto traducido. 1. Texto del primer elemento aquí. 2. Texto del segundo elemento aquí. 3. Texto del tercer elemento aquí.

• SWE-bench Verified (n=500) — Ember-1 92,2 % frente a K3 Max 93,2 %; un 15,5 % menos de tokens, 68,10 $ menos por tarea.

• SWE-Interact (n=75) — Ember-1 20,0 % frente a K3 Max 21,3 %, K3 High 13,3 %, K3 Low 6,7 %; 32,5 % menos tokens.

• DeepSWE 1.1 (n=113) — Ember-1 75,2 % frente a K3 Max 66,4 %; 23,7 % menos tokens, 126,90 $ menos por tarea.

• τ-2 Bench Airline (n=50) — Ember-1 66% vs. K3 Max 64%, K3 High y Low, ambos 64%; 5,9% menos tokens, $0,30 menos por tarea.

Hay dos cosas que destacan. En primer lugar, Ember-1 gana de forma contundente en Terminal Bench 2.1 y DeepSWE 1.1, mientras que pierde por un margen estrecho en SWE-bench Verified y SWE-Interact — un patrón consistente con un modelo que no ha perdido capacidad, sino que ha cambiado las tareas en las que dedica deliberación. En segundo lugar, el ahorro de tokens es extremadamente desigual: 51,9 % en Terminal Bench frente a 5,9 % en τ-2 Airline. Sea lo que sea que Ember-1 haya aprendido, no es un recorte uniforme del 40 % en el razonamiento. El «aproximadamente 40 %» del titular es un promedio dentro de un rango que va de aproximadamente el 6 % a aproximadamente el 52 %, y un equipo cuyo volumen de trabajo se parezca al de τ-2 Airline no debería esperar notarlo.

Los A/B tests en producción son la evidencia más convincente, precisamente porque no se diseñaron para ser benchmarks. En la carga de trabajo de programación de un cliente, Ember-1 obtuvo 0,753 frente a los 0,751 de K3, necesitó 21,4 pasos frente a 23,8 y emitió 29,9K tokens de salida frente a 49,3K — una reducción del 71,3% en tokens de razonamiento y del 39% en tokens totales, con una calidad aproximadamente equivalente. Un segundo cliente observó alrededor de un 35% menos de tokens por tarea con una calidad comparable, y Fireworks Research afirma que primero probó el cambio en su propio tráfico interno de programación y de coworking, con el resultado reportado de que nadie lo notó. Tómese todo ello como informado por el proveedor, pero tómese como la forma más sólida de lo informado por el proveedor: los datos de preferencia A/B y de finalización de tareas son más difíciles de manipular que una tabla de clasificación.

Hay una evaluación más, en Bedside Bench de Doximity —500 casos clínicos validados por médicos en diez categorías—, donde Fireworks Research afirma que Ember-1 estableció una nueva frontera de Pareto en costo por tarea, comparándolo con modelos abiertos y cerrados, incluidos GPT-5.6 Sol, GPT-6 Astra y Claude Opus 5. Esa es una afirmación de un proveedor sobre una posición de Pareto, lo que constituye una afirmación sobre una disyuntiva bidimensional en lugar de una puntuación única, y solo es tan buena como los supuestos de costo que la sustentan. Esos supuestos provinieron de la lista pública de tarifas de la API de Kimi K3. Lo que nos lleva a la parte de la historia que un lector puede verificar hoy realmente.

El modelo base es la parte que ya puedes enrutar

Todo el argumento de costos de Ember-1 se mide frente a las tarifas publicadas de Kimi K3. Kimi K3 está disponible en OrcaRouter a $3.00 por millón de tokens de entrada, $0.30 por millón de tokens de entrada en caché y $15.00 por millón de tokens de salida, con una ventana de contexto de 1,048,576 tokens. Esa es la misma tabla de tarifas que usa la comparación de Fireworks Research, y vale la pena saber que los ahorros de esas columnas de reducción de tokens se calculan contra cifras que puedes ver por ti mismo en lugar de contra el modelo de costos interno de un proveedor.

Ember-1 en sí no está en OrcaRouter. Solo está disponible a través de la plataforma serverless propia del proveedor, como vista previa de investigación, y Fireworks Research no ha publicado un precio para él, así que las cifras en dólares de la tabla comparativa se derivan de las tarifas de K3 y los recuentos de tokens, no de una tarjeta de tarifas de Ember-1 que exista. Si lo que te interesa es la aritmética, la secuencia honesta es valorar la carga de trabajo con la ruta de K3 hoy, tomar los porcentajes de reducción de tokens como el límite superior de lo que podría suponer un cambio, y esperar a que se publique una tarifa antes de modelar el ahorro en términos monetarios.

Donde OrcaRouter sí ayuda aquí es con la cobertura. Una vista previa de investigación con una ventana de acceso de dos semanas es exactamente el tipo de modelo que quieres probar sin apostar una ruta de producción a él, y la forma de hacerlo sin un segundo contrato es ponerlo detrás del mismo endpoint que todo lo demás que llamas. OrcaRouter sirve más de 200 modelos detrás de una sola API con conmutación automática por error, así que un modelo de vista previa que resulte no estar disponible el próximo mes es un cambio de enrutamiento en lugar de una migración. Nada en Ember-1 requiere eso, pero nada en una ventana de dos semanas argumenta en contra tampoco.

Qué hacer con este lanzamiento

Si ya ejecutas Kimi K3 en un bucle de agentes, las cifras de Ember-1 describen tu factura. El problema de la reproducción multiturno es real, es el costo dominante en ejecuciones largas de agentes, y un modelo que acorta sus propias trazas sin cambiar sus respuestas merece el tiempo de evaluación. La prueba correcta no es la tabla de benchmarks; es tu propio tráfico, ejecutado en la sombra —envía una parte de las solicitudes reales a ambos modelos, compara las salidas y mantén los resultados en vivo intactos durante una semana o dos antes de cambiar algo. Ese es también el consejo que está dando el propio público crítico del lanzamiento, y es sensato.

Si ejecutas una carga de trabajo de baja deliberación, o una dominada por llamadas cortas de un solo turno, los ahorros se evaporan en gran medida y la fila τ-2 Airline es tu expectativa realista. Y si necesitas un compromiso de nivel de producción —un precio, un nivel de servicio, una garantía de que el endpoint exista en seis meses—, Ember-1 aún no ofrece ninguno. Es una vista previa de investigación cuya permanencia Fireworks Research vincula explícitamente a la demanda. La pregunta interesante durante el próximo mes es si la ventana de dos semanas se convierte en una opción de servicio permanente y si un tercero reproduce alguno de los números. Hasta que ocurra una de esas cosas, este es un resultado sólido para leer y uno pobre sobre el cual construir un presupuesto.

Nada de eso debería interpretarse como una forma de menospreciar el trabajo. Eliminar el razonamiento sin eliminar la precisión es un problema más difícil que añadirlo, y hacerlo sobre el modelo de frontera de otro en lugar de entrenar el tuyo propio es la forma que ha adoptado gran parte del trabajo de capacidades de 2026. Ember-1 es el primer lanzamiento de lo que Fireworks Research dice que será una serie continua, y la plantilla —tomar un modelo que ya es bueno, reentrenar un eje de su comportamiento, vender el delta en tokens— merece la pena observarla sin importar cómo se reciba esta vista previa en particular.