Fugu Ultra: Cómo un modelo orquestador de IA desafía a GPT y Claude
Explica cómo Fugu Ultra v2 de Sakana AI distribuye las tareas entre modelos especializados en lugar de utilizar un único LLM gigantesco, y cómo se compara en pruebas de rendimiento, precios y transparencia.
Fuentes: This AI Model Beats GPT-6 and Claude Opus 5 — Without Even Using Them
Lo que importa aquí no es la puntuación en una tabla de clasificación. Es el razonamiento detrás de cómo se obtuvo esa puntuación.
Al seguir de cerca los lanzamientos de modelos de IA del último año, uno comienza a notar un patrón.
Más parámetros.
Ventanas de contexto más grandes.
Unos pocos puntos adicionales en pruebas de rendimiento.
Tokens más económicos.
Otro “modelo más capaz hasta ahora”.
Luego, el 11 de septiembre, Sakana AI presentó Fugu Ultra v2.0, y algo en este anuncio en particular rompió ese patrón.
No fueron las puntuaciones de las pruebas de rendimiento las que llamaron la atención.
Lo que captó la atención fue el mecanismo que generaba esas puntuaciones.
Fugu Ultra no pretende ser el modelo de IA más inteligente del planeta.
En lugar de eso, aborda una pregunta completamente diferente:
¿Y si la configuración de IA más potente no fuera un modelo único, sino un sistema lo suficientemente inteligente como para saber qué modelo debe manejar cada parte de un problema?
Esa pregunta podría ser más importante a largo plazo que cualquier victoria en pruebas de rendimiento individuales.
Entonces, ¿qué es exactamente Fugu Ultra?
Aquí está el primer detalle que diferencia a Fugu del resto.
Fugu Ultra no funciona como un modelo estándar al estilo de GPT o Claude.
Sakana lo presenta como un controlador, o capa de orquestación.
Imágineselo como un gerente de ingeniería experimentado que supervisa a un equipo.
Le entregas una solicitud compleja.
En lugar de intentar manejar por sí mismo cada parte de esa solicitud, el controlador puede:
- Analizar lo que se solicita
- Dividir la solicitud en subtareas más pequeñas
Imaginemos que envías una solicitud como esta:
"Analiza el informe financiero de esta empresa, genera un gráfico, marca cualquier anomalía y resume los hallazgos."
Un modelo convencional intentaría completar toda la solicitud utilizando un único conjunto de habilidades.
Un sistema orquestado trata la misma solicitud más bien como un proyecto asignado a un equipo:
Análisis de documentos → modelo especializado Interpretación de datos → otro especialista Razonamiento sobre el gráfico → especialista en visión o datos Escribir código → especialista en programación Integrarlo todo → el controlador
Desde tu punto de vista, sigue pareciendo una sola llamada a la API.
Pero detrás de escena, en realidad estás interactuando con una lista de modelos de IA coordinados por otro sistema de IA.
Se dice que el conjunto de modelos de Sakana combina modelos de código abierto con modelos especializados, entre ellos la línea Nemotron de NVIDIA.
Aquí es donde las cosas se vuelven realmente interesantes.
Los números de los benchmarks
Según las cifras proporcionadas por Sakana, Fugu Ultra v2.0 obtuvo resultados sólidos en varias categorías de benchmarks.
La empresa afirma que Fugu fue el mejor o empató como mejor en 5 de los 8 benchmarks, y quedó entre los dos primeros en 7 de los 8.
Una cifra que llama la atención de inmediato es DeepSWE: 74.3.
DeepSWE merece atención porque mide la capacidad de ingeniería de software en lugar de probar sencillas pruebas de programación.
Fugu también mostró resultados sólidos en Chartography, SWEFish, GDP.pdf y Toolathon.
Fugu Ultra v2 frente a otros modelos de Frontier
Según las comparaciones presentadas, Fugu Ultra v2 superó a varios sistemas bien conocidos, entre ellos:
- Claude Opus 4.8
- GPT-5.5
- Gemini 3.1 Pro
También se afirma que destaca especialmente en Chartography, una prueba de rendimiento basada en la interpretación de gráficos y otros datos visuales estructurados.
He aquí la condición clave:
Estas son las cifras que Sakana informó sobre su propio sistema.
Hasta la fecha de los informes aquí presentados, ningún laboratorio independiente ha reproducido estos resultados.
Esa distinción es importante.
Una prueba de rendimiento publicada por la empresa que desarrolló el modelo puede parecer impresionante, pero aún necesita verificación externa antes de poder considerarse completamente fiable.
Por lo tanto, la forma justa de tratar estos resultados es:
Realmente interesante. Vale la pena investigar más a fondo. Todavía no hay una conclusión definitiva.
La imagen general de los benchmarks
Se podría argumentar que la cifra más reveladora aquí no es ninguna puntuación en particular, sino el porcentaje de 5 de 8.
¿Por qué eso es más importante?
Porque ganar un benchmark específico a menudo solo significa que el modelo fue ajustado para esa tarea concreta.
Posicionarse cerca de la cima en una variedad de tipos de tareas es una señal mucho más significativa.
Aun así, vale la pena repetirlo: estos son resultados autoinformados, no confirmados de forma independiente.
La comparación más interesante: cómo piensan estos sistemas
La verdadera diferencia aquí probablemente no sea la puntuación en sí.
Sino la arquitectura subyacente.
Modelo tradicional de frontera
User
↓
One large model
↓
Answer
GPT, Claude y Gemini siguen en gran medida este diseño, aunque sus productos actuales incorporan cada vez más lógica de enrutamiento, uso de herramientas y comportamientos similares a los de un agente propios.
Enfoque de Fugu
┌── Coding specialist
│
User → Controller├── Vision specialist
│
├── Reasoning specialist
│
└── Other models
↓
Final answer
Esto replantea todo el desafío de la optimización.
En lugar de preguntarse:
"¿Cómo construimos un único modelo que sea mejor en todo?"
Sakana, en esencia, se pregunta:
"¿Cómo podemos mejorar para elegir el modelo adecuado para cada problema específico?"
Esa es una apuesta fundamentalmente diferente.
Fugu vs Claude vs GPT vs Gemini vs DeepSeek
¿Entonces, cómo se compara Fugu con los sistemas que normalmente se consideran al elegir un proveedor de IA?
Claude
Claude sigue siendo una de las opciones preferidas para tareas que requieren razonamiento complejo, programación y redacción extensa.
Su principal ventaja es que se obtiene un modelo de propósito general altamente capaz directamente desde el paquete.
No hay necesidad de preocuparse por coordinar múltiples modelos por uno mismo.
Fugu adopta una postura opuesta: la orquestación en sí misma es el producto.
GPT
OpenAI se ha centrado en general en mejorar las capacidades de los modelos de propósito general, añadiendo herramientas y características de tipo agente.
La filosofía de Fugu va casi en dirección opuesta:
En lugar de forzar a un único modelo a manejar todo,
crea un sistema diseñado para coordinar varios modelos al mismo tiempo.
Esa diferencia cobra cada vez más importancia a medida que aumenta el número de modelos disponibles.
Gemini
Gemini tiende a destacar cuando la entrada multimodal, las ventanas de contexto muy grandes o la integración con el ecosistema más amplio de Google son prioridades.
Lo que diferencia a Fugu no es el soporte multimodal ni la longitud del contexto por sí solos.
Se trata de la capa de enrutamiento que se encuentra sobre varios modelos subyacentes.
DeepSeek
DeepSeek ofrece otro enfoque que merece ser considerado.
Su atractivo para muchos desarrolladores se reduce a algo simple:
un rendimiento sólido a un precio competitivo.
Fugu persigue un objetivo completamente diferente.
En lugar de preguntarse:
"¿Cuál es el modelo más económico capaz de manejar esto?"
su controlador pregunta:
"¿Cuál es el modelo más adecuado para esta parte específica de la tarea?"
Esos son dos problemas de optimización distintos.
Y luego está la fijación de precios
La fijación de precios es donde las cosas se vuelven aún más interesantes.
Aparentemente, Sakana ha dividido a Fugu en dos niveles de precios.
Fugu Max
Entrada: $2 por millón de tokens
Salida: $6 por millón de tokens
Según las cifras presentadas, este precio es aproximadamente un 40 a un 60 por ciento más barato que varios modelos competidores mencionados en el anuncio.
Fugu Ultra v2
Entrada: $5 por millón de tokens
Salida: $30 por millón de tokens
Para solicitudes que superan los 272,000 tokens de contexto, las tarifas indicadas ascienden a:
Entrada: $10 por millón de tokens
Salida: $45 por millón de tokens.
Se dice también que la categoría Ultra incluye una ventana de contexto de 1 millón de tokens, además de un corte de conocimiento en agosto de 2026.
Comparación de precios
Las cifras anteriores (medidas por millón de tokens) provienen del material original; debe verificarlas con los precios actuales publicados por cada proveedor antes de tomar cualquier decisión de compra.
Pero hay un problema
Este es, sin duda, el aspecto más interesante de toda la historia de Fugu.
La orquestación no es gratuita.
Cada vez que el sistema debe:
- dividir una tarea en partes
- dirigir esas partes
- llamar a otro modelo
- esperar la respuesta de ese modelo
- verificar la calidad del resultado
- y unir todo de nuevo
se genera una carga adicional.
Esa carga puede manifestarse como latencia adicional.
Considere una solicitud como esta:
"Escribe un tuit sobre el café."
Casi con certeza no necesita una capa de coordinación que gestione varios modelos especializados para algo tan sencillo.
Eso sería como llamar a toda una firma de consultoría solo para arreglar un grifo suelto.
Ahora compare eso con una solicitud mucho más compleja, algo como ingresar un extenso documento técnico, que el sistema analice la base de código correspondiente, identifique defectos en el diseño, evalúe múltiples soluciones posibles entre sí y luego genere un plan concreto para implementar el enfoque más adecuado.
Aquí, contar con una capa de orquestación comienza a ser de gran utilidad.
El problema oculto: la caja negra
Existe un segundo problema que podría ser incluso más importante que la velocidad.
Por lo general, no tiene forma de saber qué modelo subyacente procesó realmente cada parte de su solicitud.
Para el uso cotidiano por parte de los consumidores, eso no representa un gran problema.
Pero en el ámbito empresarial, puede convertirse en un verdadero obstáculo.
Piense en organizaciones que manejan:
- código fuente confidencial
- registros financieros
- información de clientes
- documentos propietarios
- datos regulados
Si la capa de enrutamiento elige silenciosamente entre diferentes modelos en segundo plano, las empresas razonablemente querrán respuestas a preguntas como:
¿Qué modelo tocó realmente mis datos? ¿Dónde fueron procesados? ¿Qué se envió exactamente a cada modelo? ¿Es posible auditar la decisión de enrutamiento? ¿Se pueden asignar ciertas cargas de trabajo únicamente a modelos aprobados?
Estas no son preocupaciones hipotéticas.
En entornos empresariales, la capacidad de observar y gestionar el sistema puede ser tan importante como la inteligencia del modelo en sí.
Cualquier plataforma de orquestación que quiera considerarse como infraestructura fundamental, y no solo como otro envoltorio de API, eventualmente tendrá que abordar estas deficiencias en la gobernanza.
Por qué esto podría ser más importante que el lanzamiento de un solo modelo
He aquí la idea que sigue destacando.
Supongamos que un competidor lanza el próximo mes un modelo de codificación significativamente mejor.
Un proveedor tradicional de modelos tendría que volver a entrenar, evaluar y lanzar una versión completamente nueva.
Por el contrario, un sistema basado en orquestación podría simplemente integrar ese nuevo modelo en su conjunto actual de opciones.
El controlador obtiene así un especialista más al que recurrir.
Eso representa una ventaja significativa.
La estructura resultante se parece más o menos a esto:
AI Model A
│
AI Model B
│
User → Controller → AI Model C
│
AI Model D
│
AI Model E
Bajo este modelo, la capacidad de todo el sistema puede aumentar simplemente porque el ecosistema de modelos circundante sigue mejorando.
El controlador en sí no necesariamente tiene que volverse drásticamente más inteligente con cada iteración.
Lo que necesita es seguir mejorando en la toma de decisiones.
Ese cambio en el énfasis podría resultar ser una dirección importante para el futuro de la IA agente.
La carrera por la IA más avanzada podría estar cambiando
Durante mucho tiempo, el patrón detrás del progreso de la IA fue bastante predecible: hacer que el modelo fuera más grande, proporcionarle más datos de entrenamiento, mejorar su capacidad de razonamiento, invertir más recursos computacionales y repetir el ciclo. Esa fórmula comienza a parecer incompleta.
Generación 1
Un único modelo que maneja todas las tareas por sí solo.
Generación 2
Un único modelo combinado con herramientas externas.
Generación 3
Un agente que coordina múltiples herramientas y modelos.
¿Generación 4?
Un sistema que reúne de forma dinámica un equipo personalizado de modelos, adaptado a cualquier problema al que se enfrente.
Parece que esta última etapa es exactamente lo que busca Fugu.
Si esa estrategia funciona, el producto de IA más valioso en el futuro podría no ser el modelo con las puntuaciones de razonamiento más altas. Podría tratarse, en cambio, del sistema lo suficientemente inteligente como para reconocer cuándo un modelo específico no debería usarse en absoluto.
¿Deberías usar realmente Fugu?
Aquí tienes un análisis práctico.
Para tareas sencillas al estilo API
Probablemente sea mejor evitarlo.
Si tu caso de uso implica cosas como:
- resúmenes breves
- tareas simples de clasificación
- generación rutinaria de contenido
- preguntas factuales rápidas
Luego, es probable que la capa adicional de coordinación no compense por la complejidad añadida.
Para sistemas de agentes sofisticados
Aquí es donde las cosas se vuelven interesantes.
Especialmente para trabajos que involucran:
- desarrollo de software
- tareas de investigación
- análisis de documentos densos
- procesos intensivos en datos
- cadenas de razonamiento multietapa
- comportamiento de agentes autónomos
- problemas que requieren varios tipos distintos de expertise
Este es precisamente el ámbito en el que la redirección entre modelos comienza a ser beneficiosa.
Reflexiones finales
Sería prematuro considerar a Fugu Ultra como el sucesor definitivo de GPT o Claude. Las cifras de los benchmarks parecen sólidas, pero actualmente provienen del propio proveedor, y se necesita una verificación independiente antes de sacar conclusiones firmes.
Aun así, considerar esto como solo otra entrada en las guerras de pruebas de rendimiento pasaría por alto el verdadero propósito. La historia real aquí es arquitectónica, no numérica.
OpenAI, Anthropic y Google han invertido recursos masivos para hacer que sus modelos individuales sean lo más capaces posible. Sakana parece estar probando una hipótesis diferente:
Tal vez el objetivo no sea crear un modelo impecable, sino desarrollar un excelente coordinador para un conjunto de modelos imperfectos.
Se trata de un pequeño cambio conceptual, pero no trivial. Si se demuestra su validez, podría transformar la forma en que se creen las aplicaciones de inteligencia artificial en el futuro.
El sistema de IA que termina ganando podría no ser aquel que cuente con la mayor cantidad de parámetros, la ventana de contexto más larga o la puntuación más alta en cualquier lista de clasificación. Simplemente podría ser el que sea capaz de analizar una tarea y concluir que este modelo en particular es el adecuado para ese trabajo específico.
Esa es la parte de Fugu Ultra v2.0 a la que merece la pena prestar atención. No la tabla de clasificación.