Sakana Fugu funciona como un único “modelo virtual”, aunque en su interior hay un conjunto completo de diferentes LLM escondidos.
El usuario envía una solicitud a
un punto final
, y luego Fugu decide por sí misma:
- qué modelo utilizar;
- ¿Vale la pena dividir la tarea en varias partes?
- qué subtareas asignar a los diferentes modelos;
- cómo recuperar las respuestas;
- donde se puede reducir el costo sin perder calidad.
La arquitectura consta de dos niveles:
Modelo de conductor → Grupo de modelos
Piscina modelo
realiza tareas reales, y
Modelo de conductor
actúa como conductor y decide a quién y qué delegar.
Inicialmente, el grupo modelo se hace reemplazable.
Es decir, el sistema no debe estar vinculado para siempre a GPT, Claude, Gemini u otros LLM específicos. Puede actualizar el conjunto de modelos manteniendo la capa de orquestación común.
En la nueva versión, Sakana fue aún más lejos: el modelo director fue entrenado sobre la base de un nuevo sistema abierto.
gema 4
.
Según estimaciones internas de la empresa, el nuevo conductor no muestra un rendimiento peor que la versión anterior y, al mismo tiempo, reduce el coste de funcionamiento del sistema.
La idea aquí es más importante que el modelo específico:
el valor cambia gradualmente de "¿qué LLM es el más fuerte?" hasta "quién es más capaz de combinar varios modelos para una tarea específica".
El siguiente paso para Sakana son sus propios modelos e infraestructura de conductores, que pueden adaptarse a los requisitos de la soberanía de la IA.
Si este enfoque se amplía, en el futuro puede que al desarrollador no le importe qué modelo hay bajo el capó.
Accederá a una API y la propia capa de orquestación decidirá qué combinación de modelos dará el mejor resultado en términos de precio, velocidad y calidad.