A Sakana AI lançou a 11 de setembro o Fugu Max e o Fugu Ultra v2, duas novas variantes do seu sistema de orquestração de modelos. A aplicação continua a falar com uma API compatível com a da OpenAI, mas o pedido pode ser tratado por vários modelos nos bastidores. O Max procura reduzir o custo dessa combinação; o Ultra v2 foi concebido para tarefas em que a qualidade tem prioridade.
Para uma equipa de engenharia, a alteração relevante não é apenas mais uma tabela de resultados. A Sakana passa a assumir uma parte do trabalho que muitas organizações fazem nos seus próprios sistemas: decidir que modelo deve receber cada tarefa. Isso simplifica a integração, mas também concentra mais decisões técnicas no fornecedor da camada de orquestração.
Um preço fixo para uma escolha de modelos que continua dinâmica
O Fugu Max custa 2 dólares por milhão de tokens de entrada, 6 dólares por milhão de tokens de saída e 0,25 dólar por milhão de tokens de entrada em cache. A Sakana afirma ter alargado o conjunto de modelos usados pelo serviço, incluindo mais modelos abertos e especializados, entre eles modelos da família Nemotron da NVIDIA.
Nos testes publicados pela própria empresa, o Max obtém o melhor resultado global em seis benchmarks e melhora a relação entre custo e desempenho em sete dos dez testes apresentados. Estes números são medições da Sakana, não uma validação independente. Um dos testes, SWEFish, representa ainda desafios de programação internos da própria empresa.
Para quem já mantém um sistema que distribui pedidos por vários fornecedores, o preço é talvez a novidade mais prática. Em vez de calcular o custo de cada decisão de encaminhamento, a equipa recebe uma tarifa única para o Fugu Max. A conta fica mais previsível, embora a lógica que determina quais os modelos utilizados passe a ficar menos visível.
O Ultra v2 procura elevar a qualidade nas tarefas difíceis
O Fugu Ultra v2 custa 5 dólares por milhão de tokens de entrada e 30 dólares por milhão de tokens de saída. Os valores aumentam quando o contexto ultrapassa 272 mil tokens. A Sakana reporta 48,3 pontos no Chartography e 74,3 no DeepSWE, além de vantagens sobre alguns modelos de referência noutros testes. Também aqui, os resultados devem ser entendidos como avaliações do fornecedor.
O Fugu não funciona como um único modelo convencional. Existe um modelo coordenador que decide que outros modelos deve chamar e de que forma os deve pôr a trabalhar em conjunto. O relatório técnico descreve um processo de treino que combina afinação, métodos evolutivos e aprendizagem por reforço.
Por isso, o nome de uma versão não descreve sozinho tudo o que está em produção. Uma aplicação pode chamar fugu-max-v1.0 ou fugu-ultra-v2.0, mas o comportamento depende também do coordenador e do conjunto de modelos disponível nesse momento. A Sakana diz que pretende voltar a treinar e avaliar o Fugu quando surgirem novos modelos de topo.
A dependência muda de lugar, não desaparece
A análise da Aipolix é que o Fugu reduz a dependência direta de um único modelo, mas cria uma dependência mais forte da camada de orquestração. A aplicação fica sujeita às regras de encaminhamento da Sakana, à composição do conjunto de modelos, à forma como os preços são calculados e ao processo usado para atualizar esse conjunto.
Isto é especialmente relevante para governação de dados. Uma organização que precisa de saber que fornecedor pode receber determinada informação, onde o processamento pode ocorrer ou que modelos estão autorizados não resolve essas questões por ter apenas um endereço de API. Pode, pelo contrário, perder visibilidade. No Fugu normal, a Sakana permite excluir determinados agentes por motivos de privacidade e conformidade; a documentação do Ultra descreve um conjunto fixo de modelos para preservar o desempenho.
A reprodutibilidade também muda. Se o coordenador ou o conjunto de modelos for alterado, uma execução futura pode deixar de reproduzir exatamente aquilo que foi avaliado anteriormente. Numa utilização controlada, a configuração da orquestração deve fazer parte da identidade da versão implantada.
Em Portugal, a disponibilidade continua bloqueada
A página oficial do produto afirma que o Fugu ainda não está disponível na União Europeia nem no Espaço Económico Europeu enquanto a Sakana trabalha nos requisitos do RGPD e noutras regras regionais. Para equipas e empresas portuguesas, esta limitação impede por agora uma adoção normal do serviço.
A restrição está diretamente ligada ao tipo de arquitetura. Quando um pedido pode passar por vários modelos, torna-se essencial saber onde os dados são tratados, que fornecedores participam e que regras se aplicam à sua circulação. Para uma organização portuguesa, o ponto decisivo não é apenas o preço por milhão de tokens. É também o nível de controlo e transparência que a Sakana conseguirá oferecer quando disponibilizar o produto na Europa.
O que deve ser verificado antes de uma adoção
O Fugu Max torna mais simples consumir uma arquitetura com vários modelos, e isso é uma melhoria real para quem não quer manter um sistema de encaminhamento próprio. Ainda assim, a avaliação deve abranger toda a camada de orquestração: que modelos podem receber dados, como são versionadas as alterações ao conjunto, que decisões de encaminhamento ficam visíveis, como é contabilizado o custo e o que acontece quando um modelo é removido.
A Sakana disponibiliza uma API funcional e documentação técnica sobre a arquitetura Fugu, pelo que não se trata apenas de uma demonstração. A questão que fica em aberto é se os controlos operacionais e de conformidade vão evoluir ao mesmo ritmo que as alegações de desempenho e de redução de custos.