⏱️ Lectura: 13 min
Fireworks AI probó el enrutamiento de modelos en producción: un pipeline agéntico que elige, tarea por tarea, entre un modelo abierto y uno cerrado, llegó a 93% de precisión, por encima de cualquiera de los dos modelos por separado.
📑 En este artículo
- TL;DR
- Qué pasó
- Contexto e historia: qué es el enrutamiento de modelos
- Detalles técnicos y rendimiento
- Cómo probarlo hoy en Fireworks
- Impacto y análisis
- Qué sigue
- Preguntas frecuentes
- ¿Qué es el enrutamiento oracle?
- ¿Kimi K3 es gratis por ser un modelo abierto?
- ¿En qué tareas conviene mandar trabajo a Kimi K3 en vez de a Fable 5?
- ¿Cómo puede K3 ser más barato si en SWE consume diez veces más tokens que Fable 5?
- ¿Necesito cambiar mi código si ya uso la API de Fireworks?
- ¿Qué benchmark usó Fireworks para esta comparación?
- Referencias
El experimento enfrentó a Kimi K3, el modelo abierto de Moonshot AI, contra Fable 5, el modelo cerrado de Anthropic, en 1.030 tareas agénticas reales: reparación de bugs en repositorios, sesiones largas de terminal, problemas algorítmicos, implementación en seis lenguajes y un benchmark legal calificado por abogados. En ciclos largos, enrutar hacia K3 puede costar hasta 50 veces menos que usar Fable 5 en solitario, según Fireworks.
TL;DR
- Fireworks evaluó a Kimi K3 (abierto) y Fable 5 (cerrado) en 1.030 tareas agénticas repartidas en 5 categorías.
- El enrutamiento de modelos entre ambos alcanzó 93% de precisión, por encima de cualquiera de los dos por separado.
- El enrutamiento oracle, el techo teórico, eligió a Kimi K3 en 72% a 96% de las tareas según la categoría.
- En tareas SWE, K3 empató con Fable 5: 92,4% contra 92,6% de tareas resueltas.
- K3 usó 55 turnos y 1,3 millones de tokens por tarea en SWE; Fable 5 solo 21 turnos y 130.000 tokens.
- En terminal, Fable 5 llegó a 64 turnos y 1,5 millones de tokens por tarea, a veces hasta el timeout.
- De 89 tareas de terminal, K3 ganó 11 en solitario contra 7 de Fable 5, y dominó seguridad y criptografía.
- Fireworks reporta que K3 puede resultar hasta 50 veces más barato que Fable 5 en ciclos agénticos largos.
Qué pasó
Fireworks, la plataforma de inferencia que sirve tanto modelos abiertos como cerrados, publicó los resultados de un benchmark propio comparando Kimi K3 contra Fable 5 en cinco familias de tareas agénticas. La medición corrió ambos modelos con el mismo harness, sobre tareas reales de desarrollo y operación de sistemas.
El conjunto de pruebas incluyó 460 casos estilo SWE-bench (arreglar bugs reales en repositorios), 89 tareas de terminal largas (seguridad, criptografía, ingeniería inversa, administración de sistemas), 100 problemas algorítmicos tipo LeetCode o AtCoder, 225 tareas de implementación en seis lenguajes distintos y 120 tareas de un benchmark legal calificado por abogados. En total, cerca de 1.030 tareas evaluadas con el mismo criterio para los dos modelos.
El titular es un empate: K3 resolvió 92,4% de las tareas SWE y Fable 5 92,6%. A simple vista, ambos modelos parecen intercambiables. Pero cuando Fireworks abrió cada benchmark por tipo de tarea, aparecieron diferencias consistentes: K3 domina en matemática simbólica y herramientas de desarrollo; Fable 5 gana en trabajo web, visualización de datos y en la amplitud de lenguajes (Java, Python, C++). Esa especialización, no el promedio general, es lo que hace valioso el enrutamiento de modelos en vez de elegir uno solo.
Contexto e historia: qué es el enrutamiento de modelos
El enrutamiento de modelos consiste en decidir, antes o durante una tarea, qué modelo de IA la va a resolver, en vez de mandar todo el tráfico a uno solo. La idea no es nueva: los proveedores de inferencia la vienen ofreciendo como feature de plataforma, pero hasta ahora la justificación solía ser solo de costo, mandar lo fácil a un modelo barato. El estudio de Fireworks agrega un argumento distinto: dos modelos de calidad similar en promedio pueden tener fortalezas opuestas por debajo del promedio, y explotar esa diferencia sube la precisión total por encima de cualquiera de los dos.
Kimi K3 es la última versión de la familia Kimi de Moonshot AI, la startup china que también publicó K2.6 y que reparte su asistente en variantes de trabajo, código y navegación. Fable 5 es el modelo cerrado más reciente de Anthropic, parte de la misma generación que Opus 4.8 y Sonnet 5. Ambos se sirven en Fireworks a través de una API compatible con OpenAI, lo que en la práctica permite enrutar entre los dos sin cambiar el cliente HTTP que ya usás.
Fireworks distingue entre el enrutamiento oracle, que corre la tarea contra ambos modelos y se queda con la respuesta correcta más barata (el techo teórico), y un router real de producción, que tiene que predecir cuál modelo conviene sin poder probar los dos. En este estudio, el oracle eligió a K3 entre el 72% y el 96% de las tareas, según la categoría.
Detalles técnicos y rendimiento
La diferencia de costo entre los dos modelos no viene de un solo factor. Fireworks identifica tres: el precio por token de cada modelo, el efecto de la caché de prompts y cuánto trabaja cada modelo según el tipo de tarea.
En las tareas SWE, K3 trabaja más: en promedio usa 55 turnos y 1,3 millones de tokens por tarea, contra 21 turnos y 130.000 tokens de Fable 5. En las tareas largas de terminal el patrón se invierte: Fable 5 es el que se dispara, con 64 turnos y 1,5 millones de tokens por tarea, a veces hasta llegar al timeout. Ningún modelo es más eficiente en todos los frentes: el esfuerzo extra de K3 cae en SWE, y el de Fable 5 en terminal.
Kimi K3 contra Fable 5, familia por familia
| Aspecto | Kimi K3 | Fable 5 |
|---|---|---|
| Tipo de modelo | Abierto, pesos descargables | Cerrado, solo vía API |
| SWE-bench-style (460 tareas) | 92,4% resuelto | 92,6% resuelto |
| Fortaleza principal | Matemática simbólica, dev tooling, seguridad y criptografía en terminal | Web, visualización de datos, amplitud multi-lenguaje (Java, Python, C++) |
| Turnos y tokens en SWE | ~55 turnos, ~1,3M tokens | ~21 turnos, ~130K tokens |
| Turnos y tokens en terminal largo | Menos turnos que Fable 5 | ~64 turnos, ~1,5M tokens, a veces timeout |
| Selección del router oracle | 72% a 96% de las tareas | 4% a 28% de las tareas |
En los 89 casos de terminal, K3 resolvió en solitario 11 tareas que Fable 5 nunca resolvió, entre ellas romper un hash 7z, criptoanálisis de FEAL, detectar secretos filtrados y explotar una vulnerabilidad activa, contra 7 tareas exclusivas de Fable 5. K3 se quedó con todo el clúster de seguridad y criptografía.
💡 Tip: el ahorro de costo de K3 depende del cache hit rate de los prompts: aunque K3 lea diez veces más tokens que Fable 5 en una tarea SWE, con suficiente caché de prompt esos tokens repetidos salen mucho más baratos, y la corrida completa igual termina costando menos.
Un router de producción tiene que aproximar esta decisión sin ver el resultado de ambos modelos de antemano. Así se ve el flujo simplificado del enrutamiento de modelos que describe Fireworks:
flowchart TD
A["Tarea entrante"] --> B["Router de clasificacion"]
B -->|"terminal, symbolic math, dev tooling"| C["Kimi K3 (abierto)"]
B -->|"web, multi-lenguaje, datos"| D["Fable 5 (cerrado)"]
C --> E["Respuesta y costo por token"]
D --> E
Cómo probarlo hoy en Fireworks
Kimi K3 y Fable 5 se sirven en Fireworks bajo la misma API compatible con OpenAI, así que podés reproducir el enrutamiento de modelos con el SDK que ya tenés instalado.
Instalación del cliente, según tu sistema operativo:
# Linux / macOS
pip install openai
# Windows (PowerShell)
py -m pip install openai
Con el paquete instalado, esta es la llamada mínima contra Kimi K3 usando el endpoint de Fireworks:
from openai import OpenAI
client = OpenAI(
api_key="TU_FIREWORKS_API_KEY",
base_url="https://api.fireworks.ai/inference/v1",
)
respuesta = client.chat.completions.create(
model="accounts/fireworks/models/kimi-k3",
messages=[{"role": "user", "content": "Explica que es una race condition"}],
)
print(respuesta.choices[0].message.content)
Ese primer bloque solo confirma que la clave de API funciona y que el modelo responde. Para acercarte al experimento de Fireworks necesitás un router mínimo que mande cada categoría de tarea al modelo que mejor le fue en el benchmark:
import time
from openai import OpenAI
client = OpenAI(api_key="TU_FIREWORKS_API_KEY", base_url="https://api.fireworks.ai/inference/v1")
MODELO_POR_CATEGORIA = {
"terminal": "accounts/fireworks/models/kimi-k3",
"symbolic_math": "accounts/fireworks/models/kimi-k3",
"web_frontend": "accounts/fireworks/models/fable-5",
"multi_lenguaje": "accounts/fireworks/models/fable-5",
}
def enrutar_tarea(categoria, prompt):
modelo = MODELO_POR_CATEGORIA.get(categoria, "accounts/fireworks/models/kimi-k3")
inicio = time.time()
respuesta = client.chat.completions.create(
model=modelo,
messages=[{"role": "user", "content": prompt}],
)
duracion = time.time() - inicio
print(f"modelo={modelo} tiempo={duracion:.2f}s tokens={respuesta.usage.total_tokens}")
return respuesta.choices[0].message.content
enrutar_tarea("terminal", "Encuentra la vulnerabilidad en este script bash: ...")
Para verificar que el enrutamiento de modelos realmente está bajando el costo, no alcanza con mirar la respuesta: hay que registrar respuesta.usage.total_tokens de cada llamada, multiplicarlo por el precio por token publicado en el dashboard de Fireworks, y comparar el total contra lo que hubiera costado mandar todo a un solo modelo. Ese log por tarea es la única forma confiable de confirmar el ahorro en tu propio tráfico, en vez de asumir el número que reportó Fireworks.
Impacto y análisis
El hallazgo central sobre el enrutamiento de modelos no es que K3 sea mejor o peor que Fable 5: es que dos modelos con precisión promedio casi idéntica pueden tener errores en lugares distintos, y que esa distancia es explotable. Fireworks lo resume con una frase directa: si mandás cada tarea a quien mejor la resuelve, no terminás en un punto intermedio entre los dos modelos, terminás por encima de los dos.
Eso tiene una lectura práctica para equipos que hoy pagan un único proveedor de LLM para todo su pipeline agéntico: correr una tarea larga de terminal contra un modelo que tiende a espiralizar (como Fable 5 en este benchmark, con 64 turnos y 1,5 millones de tokens) puede salir más caro que resolverla con un modelo abierto más metódico en ese dominio.
⚠️ Ojo: el 93% de precisión y el ahorro de hasta 50 veces se midieron con enrutamiento oracle, el techo teórico donde ya sabés qué modelo acertó. Un router real en producción hace una predicción antes de ver el resultado, así que el número que vas a obtener con un router entrenado hoy va a estar por debajo de ese techo.
También hay una contrapartida de latencia: correr más turnos significa más tiempo de reloj por tarea. Si necesitás una respuesta en segundos, ese detalle importa tanto como el costo. Si estás corriendo agentes en background a escala, un costo que es una fracción del original pesa mucho más que unos turnos extra.
Qué sigue
Fireworks plantea que un router casi perfecto es alcanzable, pero que va a necesitar un orden de magnitud más de datos de enrutamiento y pruebas en tráfico real para confirmarlo. El estudio actual usó enrutamiento oracle para medir el techo, no todavía un router entrenado en producción.
Para Moonshot AI, el resultado es una validación externa de que K3 compite de igual a igual con un modelo cerrado de frontera en la mitad de las categorías evaluadas. Para Anthropic, la lectura es distinta: Fable 5 sigue ganando en amplitud de lenguajes y en tareas web, el tipo de trabajo que más volumen tiene en productos de consumo.
📖 Resumen en Telegram: Ver resumen
Probalo vos: creá una cuenta en Fireworks, generá una API key y corré el segundo bloque de código contra una tarea real de tu backlog para ver a qué modelo la manda tu propio router.
Preguntas frecuentes
¿Qué es el enrutamiento oracle?
Es un método de medición, no un producto: corre la misma tarea contra los dos modelos y se queda con la respuesta correcta más barata. Sirve para calcular el techo teórico de rendimiento del enrutamiento de modelos, no es algo que puedas desplegar en producción tal cual.
¿Kimi K3 es gratis por ser un modelo abierto?
No. Ser un modelo abierto significa que los pesos son descargables y podés correrlo en tu propia infraestructura, pero servirlo en una plataforma como Fireworks tiene un precio por token igual que cualquier modelo cerrado. Lo que cambia es que también podés hostearlo vos mismo si tenés el hardware.
¿En qué tareas conviene mandar trabajo a Kimi K3 en vez de a Fable 5?
Según el benchmark de Fireworks, K3 tiene ventaja en matemática simbólica, herramientas de desarrollo y en tareas de terminal relacionadas con seguridad y criptografía. Fable 5 gana en trabajo web, visualización de datos y en la amplitud de lenguajes de programación soportados.
¿Cómo puede K3 ser más barato si en SWE consume diez veces más tokens que Fable 5?
Gran parte de esos tokens extra son repetidos entre turnos y caen en la caché de prompts, que se factura mucho más barato que un token nuevo. Fireworks reporta que incluso leyendo diez veces más tokens, las corridas de K3 en SWE terminan costando menos que las de Fable 5.
¿Necesito cambiar mi código si ya uso la API de Fireworks?
No. Kimi K3 y Fable 5 se sirven bajo la misma API compatible con OpenAI, así que enrutar entre los dos es cuestión de cambiar el string del parámetro model en cada llamada, no de reescribir el cliente HTTP.
¿Qué benchmark usó Fireworks para esta comparación?
Un harness propio de aproximadamente 1.030 tareas agénticas reales, repartidas en cinco familias: reparación de bugs estilo SWE-bench, sesiones largas de terminal, problemas algorítmicos, implementación en seis lenguajes y un benchmark legal calificado por abogados.
Referencias
- Fireworks AI: Kimi K3 is competitive with Fable; Kimi K3 + Fable is SoTA: el post original con la metodología completa y los gráficos del benchmark.
- Moonshot AI: sitio oficial de la startup china que desarrolla la familia de modelos Kimi, incluido K3.
- Moonshot AI en GitHub: repositorios abiertos relacionados con los modelos Kimi.
- Anthropic: sitio oficial del laboratorio que desarrolla Fable 5, el modelo cerrado usado en la comparación.
- Fireworks AI: plataforma de inferencia usada para servir ambos modelos bajo una API compatible con OpenAI.
📱 ¿Te gusta este contenido? Únete a nuestro canal de Telegram @programacion donde publicamos a diario lo más relevante de tecnología, IA y desarrollo. Resúmenes rápidos, contenido fresco todos los días.
0 Comentarios