Rotear entre modelos economiza dinheiro, e o que você realmente compra é o plano de saída

Em julho de 2023, Lingjiao Chen, Matei Zaharia e James Zou publicaram um artigo cujo título era também um alerta: "How is ChatGPT's behavior changing over time?". Eles submeteram as versões de março e de junho do GPT-4 a algumas tarefas. Em uma delas, decidir se um número é primo, a acurácia caiu de 84% para 51%. O artigo relatou outras mudanças, como mais erros de formatação em código gerado e menor disposição para responder a perguntas de opinião. Os autores concluíram que um mesmo modelo hospedado pode mudar bastante em poucos meses, e que aplicações construídas sobre ele precisam de monitoramento contínuo.

Em poucos dias, Arvind Narayanan e Sayash Kapoor publicaram uma resposta. O teste de números primos havia usado 500 números, todos primos, de modo que a resposta certa para toda pergunta era "sim". Um modelo que sempre diz "primo" tira nota máxima, e o modelo de março dizia "primo" na maioria das vezes, enquanto o de junho dizia "composto". Quando os críticos acrescentaram 500 números compostos, todos os modelos foram mal. O argumento deles era que o artigo havia medido uma mudança de comportamento, moldada pelo ajuste fino, e não uma perda de capacidade, que vem do pré-treinamento e se move devagar.

Os dois lados têm razão em algo que importa a quem entrega um produto. A capacidade pode estar intacta e a sua aplicação pode quebrar do mesmo jeito, porque aquilo que uma API serve é um alvo em movimento. O comportamento muda sob um nome de modelo estável, os tokenizadores diferem entre provedores, modelos aposentados somem num calendário publicado e os preços mudam. Um projeto que presume um único provedor para sempre aposta que nada disso vai acontecer. A alternativa é um projeto com uma pequena interface interna na frente do modelo, um conjunto de casos de avaliação que define o comportamento aceitável e pelo menos uma alternativa testada. O roteamento, no sentido estrito de mandar requisições diferentes para modelos diferentes, vem quase como subproduto, e também pode se pagar sozinho.

O que os artigos sobre roteadores mostram

O argumento de custo vem de duas linhas de pesquisa. O FrugalGPT, de Chen, Zaharia e Zou (2023), propôs cascatas: tentar primeiro um modelo barato, verificar se a resposta é confiável com um avaliador aprendido e escalar para um modelo mais caro só quando não for. Eles relataram igualar o desempenho do GPT-4 nas tarefas testadas com custo até 98% menor, ou melhorar a acurácia em 4% sobre o GPT-4 pelo mesmo custo. O RouteLLM, artigo de 2024 de pesquisadores ligados ao grupo LMSYS (entre os autores estão Isaac Ong, Ion Stoica e Joseph Gonzalez), treinou roteadores com dados de preferência humana para escolher, a cada consulta, entre um modelo forte e um fraco. No texto de divulgação do projeto, o roteamento reduziu o custo em relação ao GPT-4 sozinho em mais de 85% no MT-Bench, 45% no MMLU e 35% no GSM8K, mantendo 95% da qualidade do GPT-4.

A variação nesses números é a parte interessante. A economia é limitada pela fração do tráfego que é fácil. Minha leitura é que os benchmarks diferem na quantidade de perguntas que exigem o modelo maior: os prompts abertos do MT-Bench dão a um modelo mais fraco espaço para pontuar bem, enquanto o MMLU e o GSM8K têm respostas certas e erradas que ele perde com mais frequência. Nenhum dos artigos é uma promessa sobre a sua carga de trabalho, e os dois mediram pares de modelos de 2023 e 2024, cujas diferenças de preço e de qualidade se moveram desde então. O que se transfere é o formato do argumento.

Vale fazer a aritmética para o seu caso. Suponha que um modelo pequeno custe 5% de um grande por requisição e que 70% das suas requisições sejam as que ele resolve corretamente. Numa cascata, toda requisição tenta primeiro o modelo pequeno, que custa 0,05 por requisição, e os 30% que escalam pagam 1,00 por cima. O custo esperado é 0,05 + 0,3 = 0,35 do que se gastaria só com o grande, uma economia de 65%. Um roteador que escolhe o modelo de antemão, sem a primeira tentativa perdida, custaria 0,7 × 0,05 + 0,3 × 1,00 = 0,335. Nenhum dos dois consegue economizar mais do que a parcela fácil, que aqui é 70%, e ambos sofrem quando o sinal de escalonamento está errado. Uma consulta difícil enviada ao modelo pequeno gera uma resposta ruim. Uma consulta fácil enviada ao grande desperdiça dinheiro, que é o erro menor. As cascatas também acrescentam latência nas requisições escaladas, porque o usuário espera pela tentativa do modelo pequeno antes de o grande começar. Se o pequeno responde em 1,5 segundo e o grande em 6, as 70% das requisições que ficam no pequeno terminam quatro vezes mais rápido, e as 30% que escalam levam 7,5 segundos em vez de 6. A média cai para 3,3 segundos enquanto o percentil 95 piora, e qual desses números importa depende do produto.

O roteador é um problema de ML com os seus dados

Os artigos treinam seus roteadores com dados públicos de preferência. Um roteador de produção treinado assim sabe o que usuários de chat em geral preferiram e nada sobre se as suas notas fiscais foram extraídas corretamente. Os rótulos que dizem quais requisições um modelo pequeno consegue tratar são os seus próprios casos de avaliação, pontuados por modelo: para cada caso, o modelo pequeno passou? Com algumas centenas deles, um classificador simples, ou até uma regra (entrada curta, modelo de documento conhecido, extração com alta confiança), consegue dividir o tráfego com proveito, e você mede com que frequência erra.

Sem os casos, o roteamento é palpite com painel. Uma equipe que recorre ao roteamento porque a fatura está alta, e não tem esses rótulos, pode ver as reclamações de qualidade subirem e concluir que roteamento não funciona, quando o que falhou foi a ausência de medição. O mesmo conjunto rotulado que barra lançamentos é o que torna um roteador seguro de implantar, e ele avisará cedo se a economia vem com uma perda de qualidade que você não pode aceitar.

Prompts não portam

Trocar de provedor parece fácil num diagrama: mude o endpoint, mude a chave. Na prática, cada família de modelos tem seus hábitos. Instruções que um modelo segue ao pé da letra, outro lê de forma frouxa. Prompts de sistema, esquemas de chamada de ferramentas, modos de saída estruturada e comportamento de parada diferem. Os tokenizadores diferem, então o mesmo documento custa um número diferente de tokens em cada fornecedor, o que faz do preço por milhão de tokens uma base pouco confiável de comparação. A única comparação que se sustenta é o custo por tarefa concluída com sucesso, medido nos seus casos.

A abordagem sensata é tratar prompts como artefatos que pertencem a um modelo, versionados e testados juntos. Uma interface interna fina recebe mensagens, definições de ferramentas e o esquema de saída desejado, e adaptadores traduzem para cada provedor. Recursos que existem só em um fornecedor podem ser usados, mas num lugar cujo custo você conhece: atrás do adaptador, com um comportamento alternativo documentado. Cache de prompt, endpoints em lote e ajuste fino são específicos de fornecedor, e todos valem o uso. Cada um aumenta a conta da migração, e essa conta deve estar escrita.

Mesmo uma abstração cuidadosa vaza. Um modelo reserva fará a tarefa de modo um pouco diferente, e a suíte mostra a diferença. Um modelo reserva que pontua seis pontos abaixo do principal nos seus casos continua sendo um modelo reserva, desde que alguém tenha decidido que seis pontos são suportáveis durante uma queda e tenha registrado a decisão.

Fixe a versão e vigie a deriva

O episódio de 2023 traz uma lição prática sobre como consumir um modelo hospedado. Onde o provedor oferece versões datadas, fixe uma, já que um alias que aponta para "o mais recente" deixa o fornecedor mudar o comportamento da sua aplicação no calendário dele. Depois rode a suíte de avaliação contra o endpoint de produção toda noite, com a taxa de aprovação e seu intervalo desenhadas ao longo do tempo. Uma versão que deveria estar congelada e mesmo assim deriva aparece como um degrau na linha. Uma atualização planejada aparece como um degrau que você escolheu.

A execução noturna custa pouco. Duzentos casos de alguns milhares de tokens cada somam algumas centenas de milhares de tokens por dia, o que, a preços de tabela de modelos intermediários, dá um dólar ou dois por dia. O que ela compra é a capacidade de dizer, quando um cliente relata respostas estranhas, se o modelo mudou na quinta-feira ou se o problema está em outro lugar.

Risco de concentração já é pergunta de auditoria

Resiliência é um tema que reguladores de alguns setores puseram por escrito. A Lei de Resiliência Operacional Digital da UE (DORA), que cobre entidades financeiras, exige no artigo 28(8) que as empresas mantenham estratégias de saída para serviços de TIC que sustentam funções críticas ou importantes. As estratégias devem ser documentadas e testadas, devem considerar falhas do prestador e devem permitir a saída sem interromper o negócio nem reduzir a qualidade do serviço aos clientes. O regulamento não trata de IA, mas um banco que usa um modelo hospedado dentro de um processo crítico está usando um serviço de TIC, e um auditor pode pedir para ver o plano e o teste.

Um plano que não pode ser testado é uma frase num documento. Para uma dependência de modelo, o teste é concreto: aponte a aplicação para o modelo reserva num ambiente de homologação, rode a suíte de avaliação e registre a diferença de qualidade, a diferença de custo, a latência adicional e os passos manuais que foram necessários. Qualquer empresa pode fazer esse exercício, regulada ou não.

Uma opção reduz o risco sem tocar nos prompts: chegar ao mesmo modelo por outro canal. Vários modelos de fronteira são vendidos diretamente pelo desenvolvedor e também pelas grandes plataformas de nuvem. A página de preços da Anthropic, por exemplo, indica que alguns modelos aposentados continuam disponíveis no Amazon Bedrock e no Google Cloud. Uma equipe que tem o tráfego principal na API do desenvolvedor e uma rota reserva num marketplace de nuvem se protegeu contra uma queda de um dos lados mantendo o comportamento que testou. Não se protegeu contra a aposentadoria do modelo em todos os lugares nem contra um problema de qualidade do próprio modelo, que é para o que serve uma segunda família de modelos. As duas proteções tratam falhas diferentes, e um plano deve dizer qual cobre qual.

Os riscos que ele cobre são comuns. Um provedor pode ter uma queda, aposentar um modelo em calendário (a documentação de preços da Anthropic lista vários modelos como aposentados em outubro de 2026), mudar um preço, mudar seus termos ou alterar o comportamento em silêncio, como Chen e colegas observaram. A pergunta para cada um é quanto tempo leva para estar rodando em outra coisa.

O argumento a favor de ficar com um só

Existe uma visão contrária respeitável: escolha um único provedor, aprenda-o a fundo e gaste o tempo de engenharia no produto. A profundidade tem retorno real. Uma equipe que se compromete com um fornecedor pode projetar em torno das suas regras de cache, dos descontos de lote, das opções de ajuste fino e das convenções de uso de ferramentas, e evita a armadilha do menor denominador comum de escrever apenas para os recursos que todos os provedores compartilham. Manter dois conjuntos de prompts, dois de adaptadores e duas linhas de base de avaliação é trabalho real que não entrega funcionalidades.

Concordo com a maior parte disso, e não acho que o argumento defenda um único fornecedor sem saída. Ele defende proporção. Um provedor principal carrega o tráfego. Existe um reserva testado, exercitado em calendário e mantido no mínimo necessário para sobreviver a uma queda ou a uma descontinuação. Um roteador só aparece quando uma medição mostra que ele vai se pagar. O ponto de equilíbrio é simples de enunciar. Se o seu gasto mensal com modelos é de US$ 40.000 e um roteador economizaria plausivelmente metade disso no tráfego fácil, são US$ 20.000 por mês. Se construir e manter o roteador, seus casos de avaliação e seu monitoramento custa o equivalente a um terço de um engenheiro a US$ 15.000 mensais de custo total, a economia é cerca de quatro vezes o custo. Com US$ 4.000 por mês de gasto, a mesma conta aponta no sentido oposto. Esses valores são marcadores de posição, e o método é pôr os seus na fórmula antes de construir qualquer coisa. Há ainda um benefício que a fórmula deixa de fora. Uma equipe que consegue mostrar, com os próprios casos, que o modelo de outro provedor passa em quase tantos deles por uma fração do preço negocia de uma posição diferente da de uma equipe que apenas prefere o fornecedor atual.

Faça o simulado

Uma estratégia escrita para deixar um provedor não é um plano de saída enquanto ninguém a tiver ensaiado. O ensaio leva uma tarde. Encaminhe uma cópia do tráfego de homologação para o reserva, rode a suíte de avaliação completa contra ele e anote o que quebrou: os prompts que precisam ser reescritos, as ferramentas cujos esquemas diferem, os formatos de saída que deixaram de ser interpretados, o percentil de latência que se moveu. Faça isso uma vez por trimestre, já que os modelos dos dois lados mudam nesse intervalo.

A primeira execução provavelmente vai mal, e esse é o motivo de fazê-la numa terça à tarde e não durante uma queda. O que o simulado quebrar vira o backlog de migração, e o tamanho desse backlog é uma medida honesta da sua dependência.

Fontes

Chen, L., Zaharia, M., Zou, J. (2023). How is ChatGPT's behavior changing over time? arXiv:2307.09009.
Narayanan, A., Kapoor, S. (2023). Is GPT-4 getting worse over time? AI Snake Oil / Normal Tech. normaltech.ai/p/is-gpt-4-getting-worse-over-time.
Chen, L., Zaharia, M., Zou, J. (2023). FrugalGPT: How to Use Large Language Models While Reducing Cost and Improving Performance. arXiv:2305.05176.
Ong, I., Almahairi, A., Wu, V., et al. (2024). RouteLLM: Learning to Route LLMs with Preference Data. arXiv:2406.18665; e LMSYS (1 de julho de 2024), texto de divulgação do RouteLLM, lmsys.org/blog/2024-07-01-routellm.
Regulamento (UE) 2022/2554 sobre resiliência operacional digital do setor financeiro (DORA), artigo 28(8), Jornal Oficial L 333, 27.12.2022.
Anthropic. Pricing, documentação para desenvolvedores do Claude (modelos aposentados em outubro de 2026). platform.claude.com/docs/en/about-claude/pricing.