Fireworks defiende enrutar cada consulta al modelo de IA más adecuado para ahorrar

Fireworks AI quiere convencer a las empresas de que el problema no es elegir el mejor modelo, sino dejar de depender de uno solo. En una entrevista con The Register, el vicepresidente de la compañía, Rob Ferguson, defendió que un enrutador capaz de evaluar cada consulta y enviarla al modelo más adecuado reduce el coste por tarea y mejora la calidad. Su tesis: “El estado del arte para todo el mundo es tener un portfolio de modelos”.

La afirmación es atractiva, pero conviene situarla: Fireworks vende inferencia gestionada y enrutamiento de modelos, así que su interés comercial coincide con la conclusión. Las cifras que cita proceden de su experiencia con clientes y no de una auditoría independiente. Aun así, el debate que plantea es útil para cualquier empresa que esté pagando facturas de IA sin saber con precisión qué modelo resuelve cada tarea.

Qué propone Fireworks

Fireworks AI es un proveedor de inferencia gestionada que compite con Together AI, Baseten y DeepInfra, entre otros. Su producto Nexus y su API reciben las consultas y las dirigen al modelo, suscripción de frontera o API que mejor encaje. No se trata de un simple gateway que reparte carga: según Ferguson, la compañía construye enrutadores personalizados que clasifican la dificultad de la tarea y detectan afinidades entre modelos. Un ejemplo que cita es que Kimi puede ser algo mejor en JavaScript que en Python.

El directivo también admite que Fireworks puede desplegar modelos en centros de datos propios, pero que empuja a los clientes hacia la nube porque la economía del hardware es implacable: 10.000 GPU representan alrededor de mil millones de dólares de capital, y si no se mantienen ocupadas, el coste se dispara. Para cargas especialmente sensibles ofrece Sovereign, un servicio con socios como Microsoft, aunque sostiene que la mayoría de las tareas de inferencia no necesitan ese nivel de aislamiento.

El argumento del coste por tarea

El núcleo del argumento es que el precio por token no es el precio real. Ferguson asegura que una empresa puede estar pagando menos por token y, aun así, gastar más porque el modelo falla, repite trabajo o no acierta a la primera. “Con IA, el retrabajo es de lejos tu mayor coste”, afirma. Por eso recomienda medir el coste por tarea completada, no solo el coste por millón de tokens.

El ejemplo que pone es el de una empresa de ciencia de datos que, con el enrutamiento de Fireworks, cacheaba alrededor del 90% de las tareas. En su comparación, Anthropic Opus cacheaba el 30% y “hacía retrabajo de IA constantemente”. Son cifras del propio Ferguson, no de un estudio independiente, y dependen del tipo de carga, de la longitud de las consultas y de la política de caché de cada proveedor. La conclusión práctica —medir la tasa de acierto de caché y el coste por tarea— es válida aunque no se acepten sus números.

Fireworks promete una factura “al menos un 50% menor” y habla de “seis a ocho veces más barato” en algunos casos. Ferguson matiza que la garantía del 50% se aplica cuando el cliente combina modelos abiertos y cerrados; a partir de ahí, el ahorro depende de cuántas tareas puedan migrar a modelos más pequeños o especializados. Es una promesa comercial, no una garantía contractual universal, y conviene pedir una prueba con las cargas reales antes de aceptarla.

Datos, caché y confianza

Otro punto del discurso de Fireworks es la retención de datos. La compañía afirma tener una política de retención cero y critica a los proveedores que usan las consultas de los clientes para entrenar. Ferguson sostiene que las empresas deberían cobrar por sus datos si van a servir para mejorar modelos ajenos. Es una postura razonable para cargas sensibles, pero también es un argumento de venta: la política concreta debe verificarse en el contrato y en la documentación del proveedor, no solo en una entrevista.

La velocidad es el otro beneficio que destaca. Asegura que muchos clientes no saben que pueden pedir respuestas más rápidas y que eso cambia la forma de trabajar. En la práctica, la latencia importa tanto como el coste en aplicaciones interactivas, pero optimizarla no siempre es gratis: puede exigir modelos más pequeños, menos razonamiento o una infraestructura más cercana al usuario.

Qué debería evaluar una empresa

La propuesta de Fireworks se puede resumir en una idea útil: tratar los modelos como un portfolio y medir el resultado por tarea. Para llevarlo a cabo hacen falta datos propios, un conjunto de evaluación representativo y la capacidad de detectar regresiones cuando el enrutador cambia de modelo. También hace falta observabilidad: saber qué modelo respondió, cuánto costó, cuánto tardó y si la respuesta fue aceptada o requirió corrección.

El enrutamiento añade complejidad. Un solo modelo es más fácil de auditar, de explicar y de mantener; varios modelos introducen dependencias, cuotas, versiones y comportamientos distintos. La pregunta correcta no es si el enrutamiento es mejor en abstracto, sino si la empresa tiene el volumen, la variedad de tareas y la instrumentación necesarias para que el ahorro compense esa complejidad. Para un equipo pequeño con una carga homogénea, un único modelo puede seguir siendo la opción más sensata.

La entrevista de The Register deja una conclusión sobria: la competencia entre modelos ha convertido la elección del modelo en una decisión operativa y económica, no solo técnica. Fireworks tiene un producto que vender, pero el marco de análisis —coste por tarea, caché, especialización y retención de datos— es aplicable incluso a quien decida no contratar sus servicios.