Roteamento de modelos de IA: como escolher o modelo certo pra cada tarefa automaticamente

Usar GPT-4o pra tudo é como pegar um avião pra ir na padaria. Funciona, mas custa 150x mais que ir a pé.

Em junho de 2026, a diferença de preço entre modelos é brutal: GPT-4o custa $5/M tokens de input. GPT-4.1 Nano custa $0.10/M. Haiku 4.5 custa $1/M. Mesma tarefa simples, 50x de diferença no custo.

Roteamento dinâmico resolve isso: analisa cada chamada e envia pro modelo mais barato que dá conta da tarefa. Automático. Sem regra fixa. Sem mudar código.

Relacionado: Como reduzir custo de API OpenAI | FinOps para IA: guia completo

Por que usar um modelo só pra tudo é desperdício

A maioria das aplicações de IA tem tarefas de complexidade variada:

Tarefa	Complexidade	Modelo ideal	Custo/M tokens
Classificar sentimento	Baixa	Haiku 4.5	$1
Extrair campo de JSON	Baixa	GPT-4.1 Nano	$0.10
Resumir documento	Média	Sonnet 4.6	$3
Análise estratégica	Alta	GPT-4o	$5
Raciocínio complexo	Muito alta	o3	$15

Se todas essas tarefas passam pelo GPT-4o, você paga $5/M em tudo — inclusive nas tarefas que um modelo de $0.10 resolvia perfeitamente.

Em uma aplicação típica, 60-70% das chamadas são de baixa/média complexidade. Roteando corretamente, essas chamadas custam 10-50x menos.

Como funciona o roteamento dinâmico

O roteamento analisa cada prompt antes de enviar pro modelo e decide qual usar. Três abordagens:

1. Roteamento por regra (simples, limitado)

Regras fixas baseadas em padrão:

if prompt.includes("classificar") → Haiku
if prompt.includes("analisar") → GPT-4o
if tokens < 100 → Nano

Funciona pra casos simples, mas quebra com prompts ambíguos. Não escala.

2. Roteamento por classificação (melhor)

Um modelo leve (Nano ou Haiku) classifica a complexidade do prompt antes de rotear:

Prompt → Classificador (Haiku, ~$0.001) → "complexidade: baixa" → Haiku processa
Prompt → Classificador (Haiku, ~$0.001) → "complexidade: alta" → GPT-4o processa

O custo do classificador é irrelevante ($0.001 por chamada). O benefício é 50x de economia nas chamadas de baixa complexidade.

3. Roteamento por proxy (ideal)

Um proxy inteligente entre o código e a API faz tudo automaticamente: classifica, roteia, e ainda aplica compressão e cache. Sem mudar nada no código — só troca a baseURL do SDK.

É a abordagem que plataformas como Veltrix usam: cada chamada passa pelo proxy, que decide modelo, comprime o prompt e verifica o cache antes de enviar.

Economia real com roteamento

Dados de produção de uma aplicação com 10.000 chamadas/dia:

Antes do roteamento (tudo no GPT-4o)

Chamadas/dia	Tokens médios	Custo/dia	Custo/mês
10.000	2.000	$100	$3.000

Depois do roteamento dinâmico

Complexidade	% chamadas	Modelo	Custo/dia
Baixa (60%)	6.000	Haiku 4.5	$12
Média (25%)	2.500	Sonnet 4.6	$15
Alta (15%)	1.500	GPT-4o	$15
Total	10.000	mix	$42/dia

Economia: 58% — de $3.000/mês pra $1.260/mês. Sem perda de qualidade nas respostas, porque cada tarefa recebe o modelo adequado.

Quando o roteamento faz diferença (e quando não faz)

Faz diferença quando:

Mix de complexidades: se sua aplicação tem tarefas simples e complexas misturadas
Volume alto: acima de 1.000 chamadas/dia, a economia justifica qualquer overhead
Múltiplos casos de uso: chatbot + RAG + classificação na mesma aplicação
Custo é gargalo: quando a fatura de API compromete a margem do produto

Não faz diferença quando:

Tudo é complexo: se 100% das chamadas precisam do modelo mais capaz, não tem o que rotear
Volume muito baixo: abaixo de 100 chamadas/dia, a economia absoluta é pequena
Modelo único obrigatório: quando o cliente exige um modelo específico por compliance

Como implementar

Opção 1: Manual (código próprio)

Criar um router no backend que classifica e despacha:

def route_model(prompt: str) -> str:
    complexity = classify_complexity(prompt)  # chamada rápida ao Haiku
    if complexity == "low":
        return "claude-haiku-4-5"
    elif complexity == "medium":
        return "claude-sonnet-4-6"
    else:
        return "gpt-4o"

Funciona, mas você precisa manter o classificador, atualizar quando novos modelos lançam, e lidar com fallbacks.

Opção 2: Proxy inteligente

Trocar a baseURL do SDK por um proxy que faz o roteamento automaticamente. O Veltrix, por exemplo, combina roteamento com compressão semântica e cache — três otimizações numa única integração.

A vantagem: zero manutenção. Quando um modelo novo lança (como o MAI-Code-1-Flash da Microsoft ou o Gemini 3.5 Flash do Google), o proxy atualiza as rotas automaticamente.

Conclusão

Roteamento dinâmico é a otimização com melhor relação esforço/resultado pra quem usa múltiplos modelos ou tem mix de complexidade nas chamadas.

30-50% de economia sem perda de qualidade
Funciona com qualquer SDK (troca de baseURL)
Combina com compressão e cache pra 60%+ de economia total

Se você ainda manda tudo pro GPT-4o, tá pagando avião pra ir na padaria.

Próximo passo: Cache semântico explicado — a segunda alavanca que mais reduz custos.