Roteamento inteligente de modelos pode cortar custos de LLM em 10x
Aplicações que usam LLM costumam escolher o modelo mais capaz e mandar todas as requisições a ele. Isso simplifica a implementação, mas pode ficar caro: classificar um ticket de suporte não exige o mesmo raciocínio de investigar por que registros financeiros não batem. O roteamento de modelos propõe escolher um modelo para cada requisição, enviando trabalho simples a modelos menores e baratos e trabalho difícil a modelos mais capazes. O texto afirma que isso pode reduzir o custo total em torno de 10 vezes, sem queda perceptível de qualidade, mas ressalva que a economia não é garantida: depende do tipo de requisição, da diferença de preço entre modelos e do desempenho do roteador.
Por que o custo sobe
O custo de uma API de LLM normalmente depende dos tokens processados. Tokens de entrada incluem mensagem do usuário, instruções, histórico e documentos; tokens de saída são os gerados na resposta. Modelos maiores e mais capazes custam mais porque exigem mais recursos e podem gastar computação extra para raciocinar. Essa capacidade é importante para problemas complexos, mas desperdiçada em tarefas simples. O texto compara isso a contratar um arquiteto sênior para renomear arquivos, ordenar tickets e formatar datas.
O que é roteamento e onde economiza
O roteador fica diante de vários modelos - pequeno, médio e muito capaz - e examina cada pedido para enviá-lo ao mais adequado. É semelhante a balanceamento de carga, mas o balanceador distribui tráfego entre servidores equivalentes, enquanto o roteador escolhe entre modelos com capacidades e custos muito distintos. Também é diferente de MoE, em que o roteamento ocorre dentro de um único modelo; aqui ele acontece no nível da aplicação. Um exemplo numérico: se o modelo poderoso custa 1 centavo por requisição média e a aplicação processa 1 milhão de requisições, usá-lo em tudo custaria cerca de US$ 10 mil. Se o pequeno custa 1/20 do poderoso, o médio custa 1/5, e 85% das requisições podem ir ao pequeno, 10% ao médio e 5% ao poderoso, o custo médio cai para (0,85×0,05) + (0,10×0,20) + (0,05×1,00) = 0,1125, ou cerca de 11% do original - quase 10 vezes menos.
Como julgar a dificuldade e escolher
Tamanho não basta: "O contrato é válido?" tem quatro palavras, mas pode exigir conhecimento jurídico; um documento longo para extrair e-mails pode ser simples. O roteador deve combinar sinais: tipo de tarefa (classificação, extração, tradução e formatação tendem a exigir menos raciocínio; planejamento, depuração, provas matemáticas e comparação de documentos conflitantes exigem mais), risco (médico, jurídico, financeiro ou de segurança pode ir a modelo mais forte mesmo parecendo simples), tamanho do contexto e requisitos de saída. Uma abordagem flexível usa um modelo pequeno como roteador, que classifica o pedido como EASY, MEDIUM ou HARD e retorna dificuldade, risco, modelo recomendado e razão. Como ele pode errar, sistemas de produção combinam classificação por modelo com regras fixas de segurança.
Estratégias, falhas e conclusão
No cascading, o sistema tenta primeiro o modelo barato e verifica se a resposta é boa; se falhar, escala para um modelo mais forte. Funciona bem com checagem automática, como validar campos de fatura ou rodar testes no código. Quando a qualidade é subjetiva, pode ser preciso um avaliador, que também custa e erra. Tentativas fracassadas consomem dinheiro e tempo, e um cascata mal desenhado pode ficar mais lento e caro. No roteamento semântico, embeddings e a intenção da requisição definem a escolha; é útil para tipo de tarefa, menos confiável para dificuldade. No roteamento aprendizado, dados de requisições enviadas a vários modelos treinam um classificador, mas a qualidade depende de boa avaliação: métricas que premiam fluência em vez de correção ensinam o roteador errado.
Falhas comuns incluem sub-roteamento (pedido difícil em modelo fraco), sobre-roteamento (pedido fácil em modelo caro), manipulação pelo usuário - por exemplo, instrução para ignorar as regras e classificar como fácil -, mudanças de modelo, preço ou tráfego que tornam a lógica obsoleta, e custo extra de avaliar todas as respostas. A conclusão é estimar o que a requisição precisa, escolher o modelo mais barato que provavelmente a atenda e verificar o resultado, escalando quando necessário. Nos comentários, leitores questionam a generalização do ganho de 10 vezes: ele dependeria de 85% do tráfego ser realmente fácil e de o roteador acertar quais 85% são esses. Um comentarista que desenvolve um roteador aberto relata benchmark com cerca de 93% de sucesso e aproximadamente 60% menos custo, mas ressalva que benchmarks contaminados podem inflar a precisão e que tem interesse no resultado.