Roteamento de LLMs: como enviar cada tarefa ao modelo certo

Por que você ainda está chamando o modelo mais caro para tudo

Roteamento de LLMs é o que acontece quando você decide que não faz sentido usar o mesmo modelo para "resuma esse parágrafo" e "analise esse contrato de 50 páginas com implicações regulatórias".

A maioria dos projetos começa com um modelo só. Faz sentido: você ainda está validando se o caso de uso funciona, não quer adicionar complexidade desnecessária, e o custo inicial é tolerável. O problema aparece quando o uso escala.

Quando você processa dezenas de milhares de requisições por dia, a diferença de custo entre um modelo grande e um menor pode ser absurda. E olha, na maioria dessas requisições, você provavelmente não precisava do modelo grande.

O que é roteamento de LLMs

Roteamento de LLMs é a prática de direcionar cada requisição para o modelo mais adequado com base em critérios que você define: complexidade da tarefa, latência necessária, custo por request, ou sensibilidade dos dados envolvidos.

Não é mágica. É uma camada de decisão colocada antes das chamadas de API, que avalia cada requisição e decide qual modelo vai processá-la.

O que torna isso relevante agora é que o ecossistema de modelos ficou muito mais rico. Antes, a escolha era basicamente entre um modelo forte e um modelo barato de qualidade duvidosa. Hoje existem modelos de todos os tamanhos e especializações, muitos bons o suficiente para tarefas específicas a uma fração do custo dos modelos maiores.

Plataformas como o OpenRouter foram construídas exatamente com esse objetivo: agregar múltiplos modelos de diferentes provedores e facilitar a troca entre eles sem reescrever toda a integração.

Sinais de que você precisa de roteamento

Alguns cenários onde ignorar roteamento começa a doer de verdade:

• Sua aplicação tem tarefas com complexidade muito variada (classificação simples ao lado de geração de relatórios longos)
• O custo mensal de API cresce mais rápido do que o crescimento real de uso
• Você tem requisições onde latência importa (tempo real) e outras onde não importa (processamento em background)
• Parte dos dados que você processa é sensível e não pode sair da sua infraestrutura

Quando pelo menos dois desses cenários se aplicam, a conversa sobre roteamento deixa de ser teórica.

Como funciona o roteamento de LLMs na prática

Complexidade da tarefa como primeiro critério

O critério mais óbvio é a complexidade. Acontece que a maioria das aplicações tem uma distribuição de tarefas onde uma parcela pequena exige raciocínio sofisticado e a maioria são operações repetitivas e bem definidas.

Classificar um ticket de suporte em uma de cinco categorias é diferente de redigir uma resposta personalizada para uma reclamação com múltiplas implicações. O primeiro precisa de consistência e velocidade. O segundo precisa de capacidade real de geração.

A pergunta prática aqui é: como você operacionaliza "complexidade"? Não tem resposta universal, mas algumas abordagens que funcionam. Tamanho do input como proxy (textos longos tendem a exigir mais raciocínio). Presença de palavras-chave que indicam análise mais profunda. Ou uma classificação prévia feita por um modelo pequeno e barato, antes de decidir qual modelo processa de verdade.

Latência como critério secundário

Tem requisições onde o usuário está esperando resposta em tempo real. E tem requisições que rodam em background e podem esperar alguns segundos ou minutos.

Modelos menores são geralmente mais rápidos. Se uma tarefa tolera latência maior, você tem mais liberdade para enviar a um modelo mais pesado quando for necessário. Se latência é crítica, o modelo menor entra mesmo que a tarefa pudesse se beneficiar de um modelo maior.

Detalhe importante: "mais rápido" não é sempre verdade em termos absolutos quando se considera fila de requisições e capacidade do provedor. Mas como regra geral, modelos menores geram resposta mais rápido.

Privacidade e sensibilidade dos dados

Esse critério é frequentemente ignorado nos exemplos de roteamento técnico, mas é o que mais importa em contextos regulatórios.

Pois é, às vezes o roteamento é menos sobre otimizar custo e mais sobre onde o dado pode ir. Se você tem dados que por compliance não podem ser enviados para APIs externas, a decisão não é "qual modelo é melhor para isso", mas sim "qual modelo eu posso usar aqui". Dado sensível vai para o modelo que roda na sua infraestrutura. Dado não sensível pode ir para APIs externas.

Para implementar essa lógica sem reescrever cada integração do zero, um gateway unificado como o LiteLLM funciona como a camada que centraliza as chamadas e aplica o roteamento de forma transparente para o restante da aplicação.

O que acontece quando o roteamento dá errado

Tem dois erros principais.

O primeiro é rotear para o modelo pequeno demais. A qualidade cai, você não percebe imediatamente, e o produto começa a entregar resultados ruins. É o erro mais arriscado porque é silencioso, especialmente se você não tem avaliação de qualidade no pipeline.

O segundo é rotear para o modelo grande demais. O custo cresce desnecessariamente, mas a qualidade está ok. Você não percebe o desperdício até olhar para a fatura.

Spoiler: os dois erros são evitáveis com métricas. Sem monitoramento de qualidade e custo por tipo de tarefa, você não tem como saber qual dos dois está acontecendo no seu sistema agora.

Isso conecta diretamente com o que discuti em como medir qualidade de LLM em produção: antes de implementar roteamento, você precisa ter pelo menos uma métrica de qualidade por tipo de tarefa. Caso contrário, você vai otimizar custo sem saber se quebrou qualidade no processo.

Como medir se o roteamento de LLMs está funcionando

Essa é a pergunta que importa. Três métricas para acompanhar:

• Taxa de distribuição por categoria: para cada tipo de tarefa que você definiu, qual porcentagem está indo para qual modelo? Se os critérios estão calibrados, essa distribuição deve ser estável ao longo do tempo
• Custo por tarefa por categoria: o custo médio de processar cada tipo de tarefa. Você quer ver redução nas tarefas simples sem degradação nas tarefas complexas
• Qualidade por categoria: avaliação da saída por tipo de tarefa. Pode ser um juiz LLM, avaliação humana amostral ou uma métrica de negócio como taxa de aprovação ou satisfação do usuário

Se custo caiu e qualidade se manteve, o roteamento está funcionando. Se custo caiu mas qualidade também caiu, você está roteando errado alguma categoria. A métrica te diz qual.

Roteamento vs. outras estratégias de redução de custo

Roteamento não é a única forma de reduzir custo de LLM. Vale comparar para entender quando cada abordagem faz sentido.

Prompt caching resolve o problema de pagar pelo mesmo contexto repetido. Funciona bem quando você tem um system prompt longo que aparece em toda requisição. Roteamento resolve o problema de usar o modelo errado para a tarefa. São complementares, não concorrentes.

Fine-tuning permite pegar um modelo menor e especializar para o seu caso de uso específico, o que pode tornar um modelo barato comparável a um caro no seu contexto. Roteamento sem fine-tuning ainda pode deixar o modelo pequeno abaixo do necessário para algumas tarefas. Com fine-tuning bem feito, você expande o espaço de tarefas que um modelo menor consegue cobrir com qualidade.

A lógica de combinação é essa: fine-tuning amplia o que o modelo menor consegue fazer bem, roteamento decide quando usar qual modelo, e prompt caching reduz o custo dos tokens que se repetem em todas as chamadas.

O risco de não agir

Olha, a aplicação que usa um modelo só para tudo não quebra. Ela só fica gradualmente mais cara conforme o uso cresce, e o custo alto vai parecer inevitável porque "LLM é caro mesmo".

Não é inevitável. É uma escolha implícita de não otimizar.

O ponto de inflexão onde roteamento justifica o investimento de implementação é diferente para cada caso. Mas se você roda mais de alguns milhares de chamadas por dia com tarefas de complexidade variada, a conta provavelmente fecha com folga.

Perguntas frequentes

Como definir os critérios de roteamento sem dados históricos?

Você começa com hipóteses baseadas nas tarefas que o sistema faz. Categorize manualmente uma amostra de requisições por complexidade percebida e teste os dois modelos nas mesmas amostras. Os resultados te dão uma base empírica para os critérios iniciais, que você refina com o tempo à medida que o sistema acumula dados reais.

Um modelo menor vai degradar a qualidade percebida pelos usuários?

Depende da tarefa. Para classificação, extração estruturada e respostas curtas com contexto bem definido, a diferença costuma ser imperceptível para o usuário final. Para geração de texto longa, raciocínio em múltiplas etapas ou análise de ambiguidade, a diferença aparece. A resposta certa é testar na sua tarefa específica com uma métrica de qualidade, não assumir nenhum dos dois cenários.

Preciso de infraestrutura específica para implementar roteamento?

Não necessariamente. Roteamento pode começar como uma lógica simples de decisão antes de qual API você chama. Ferramentas como LiteLLM ou OpenRouter facilitam bastante, mas você pode começar com uma lógica manual básica e ir evoluindo conforme entende os padrões de uso reais da aplicação.

O roteamento funciona com modelos que rodam localmente?

Sim, e essa é uma das combinações mais interessantes na prática. Tarefas com dados sensíveis vão para um modelo local, tarefas que precisam de mais capacidade vão para APIs externas. O critério de roteamento simplesmente inclui a variável de sensibilidade do dado ao lado das variáveis de complexidade e custo.

Como lidar com tarefas ambíguas que não se encaixam claramente em uma categoria?

Você pode estabelecer uma categoria "incerta" que sempre vai para o modelo maior por segurança, e usar o volume dessa categoria como sinal de que os critérios precisam ser refinados. O objetivo é diminuir essa faixa ao longo do tempo, à medida que você entende melhor a distribuição real das requisições.

Conclusão

Roteamento de LLMs não é complexidade pela complexidade. É a decisão de parar de tratar todas as tarefas como iguais quando claramente não são.

O início é direto: categorize as tarefas, teste dois modelos nas mesmas amostras, defina uma métrica de qualidade e acompanhe custo por categoria. A partir daí, você tem dados para refinar os critérios com base no que realmente acontece em produção.

O que faz o roteamento funcionar não é a sofisticação da lógica de decisão. É ter métricas claras o suficiente para saber quando a decisão está errada.

Se você está explorando formas de reduzir custo sem sacrificar qualidade, o próximo passo concreto é revisar como você mede qualidade por tipo de tarefa hoje. Sem essa base, qualquer otimização de custo é um tiro no escuro.

Se você ainda não tem visibilidade sobre o que cada chamada de LLM está custando por tipo de tarefa, começa por aí. Você não consegue otimizar o que não consegue enxergar.