Model Routing em Produção: Como Escolher o Modelo Certo Para Cada Requisição e Cortar Até 85% do Custo de IA

Em junho de 2026, a conta de API de IA de uma empresa SaaS de médio porte processava 50 milhões de tokens por dia. O modelo escolhido para toda requisição era um frontier model a $5 por milhão de tokens de input e $15 por milhão de output. A fatura mensal ultrapassava $200.000. Quando a equipe auditou o tráfego, descobriu que 72% das requisições eram tarefas rotineiras: classificação de intenção, sumarização de tickets, extração de entidades e geração de respostas de confirmação. Tarefas que um modelo de 8 bilhões de parâmetros rodando localmente a $0,24 por milhão de tokens resolve com qualidade equivalente. O custo de 72% do tráfego era 100 vezes maior do que precisava ser.

Este cenário não é exceção. É o padrão. Uma pesquisa conduzida pela Zylos Research em 2026 com equipes de desenvolvimento de IA descobriu que mais de 75% das equipes usam múltiplos modelos em produção ou desenvolvimento (Zylos Research, 2026). O problema é que a maioria não roteia. Envia tudo para o modelo mais capaz, independentemente da complexidade da requisição. O paper RouteLLM, publicado no ICLR 2025 por Ong et al. (2024; arXiv:2406.18665), demonstrou que um router treinado com dados de preferência humana reduz o custo em 85% no benchmark MT Bench mantendo 95% da qualidade do GPT-4 Turbo, necessitando do modelo forte em apenas 14% das queries. Em produção real, equipes reportam reduções de 40% a 85% na fatura de inferência após implementar routing (Digital Applied, 2026; Inworld AI, 2026).

Este artigo decompõe o que é model routing, quais estratégias existem, quais ferramentas estão production-ready em 2026, como arquiteturas híbridas cloud-on-prem amplificam a economia e como isso se conecta com soberania de dados e IA brasileira. Não é sobre cortar custo por cortar. É sobre gastar o token certo no problema certo.

O problema: por que um modelo único é sempre o modelo errado

O custo de inferência de LLMs em 2026 varia por um fator de aproximadamente 100 vezes entre o modelo mais barato utilizável e o frontier model mais capaz. O GPT-4.1 custa $2,00 por milhão de tokens de input e $8,00 por milhão de output. O GPT-4.1 Nano custa $0,10 por milhão de input e $0,40 por milhão de output (PE Collective, 2026). Um modelo open-source de 8 bilhões de parâmetros auto-hospedado custa aproximadamente $0,24 por milhão de tokens considerando energia e depreciação de hardware (RouteLLM cost analysis, Ong et al., 2024). A diferença de preço entre o topo e a base do catálogo é duas ordens de magnitude.

A intuição de que "modelo mais caro é modelo melhor" é estruturalmente falsa em produção. O que os benchmarks mostram é que a qualidade de resposta é assimétrica: um frontier model显著 supera um SLM em raciocínio multi-passo, planejamento complexo e geração criativa, mas a diferença colapsa para quase zero em tarefas de classificação, extração, sumarização e respostas templateadas. O paper RouteLLM quantifica essa assimetria: no MT Bench, o router mantém 95% da qualidade do GPT-4 Turbo enviando apenas 14% das queries para o modelo forte. No MMLU, mantém 92% da qualidade com 41% de economia de custo (Ong et al., 2024, Table 6).

A maioria do tráfego de produção é rotineira. A Inworld AI Consumer AI Stack Report 2026 estima que 70% a 80% dos sub-tasks em um turno conversacional podem ser handleados por small models (Inworld AI, 2026). Pagar preço de frontier model em tarefa que small model resolve é puro desperdício. Não é otimização. É erro de arquitetura.

As quatro estratégias de routing que funcionam em produção

1. Routing baseado em regras (rule-based)

A estratégia mais simples e a primeira que toda equipe deveria implementar. Regras determinísticas classificam a requisição antes de qualquer inferência. Exemplos: se a query matcha um template conhecido, vai para o SLM. Se contém palavras-chave de complexidade ("analise", "compare", "planeje"), vai para o frontier model. Se a intenção detectada é classificação de sentimento, vai para o modelo mais barato.

A vantagem é zero overhead de inferência no router. A desvantagem é rigidez: regras não capturam nuances e precisam de manutenção manual. Em workloads com distribuição de complexidade estável, contudo, rule-based routing resolve 60% a 70% da economia total sem qualquer componente de ML (Khimananda, 2026).

2. Routing por classificador (BERT ou similar)

Um classificador leve, tipicamente um BERT-small ou DeBERTa, é treinado para prever qual modelo deve handle a requisição. O classificador lê o prompt e emite uma probabilidade de que o modelo forte é necessário. Se a probabilidade está abaixo de um threshold, a requisição vai para o SLM. Acima, vai para o frontier model.

O RouteLLM treinou quatro tipos de router com dados de preferência humana do Chatbot Arena: matrix factorization, BERT classifier, causal LLM classifier e similarity-weighted ranking. O BERT classifier atingiu 45% de economia no MMLU com qualidade comparável ao GPT-4, enquanto a matrix factorization atingiu 85% no MT Bench (Ong et al., 2024). O overhead do router é da ordem de milissegundos, negligible comparado à latência da inferência (Digital Applied, 2026).

3. Cascade (tentativa-e-escalação)

A requisição vai primeiro para o SLM. O SLM gera uma resposta. Um verificador avalia a resposta: score de confiança, validade estrutural, consistência com o contexto. Se a resposta passa, é entregue. Se falha, a requisição é escalada para o frontier model.

O cascade é a estratégia que pode bater um frontier model único em ambos custo e qualidade simultaneamente, porque gasta tokens do modelo forte apenas nas requisições que provavelmente precisam dele. O verificador adiciona custo e complexidade, mas o ganho líquido é significativo. Equipes que implementam cascade reportam que o SLM resolve 60% a 80% das requisições sem escalada (Princeton IT Services, 2026).

4. Routing semântico (embedding-based)

Um modelo de embedding converte a requisição em um vetor. O router compara o vetor com representações pré-computadas de exemplos rotulados para cada modelo. A requisição vai para o modelo cujos exemplos são mais similares semanticamente.

O framework open-source Semantic Router implementa essa abordagem com latência sub-millisecond, pois o routing não envolve nenhuma chamada de LLM: é puramente uma operação de similaridade vetorial (AY Automate, 2026). É ideal para intent classification e guardrails, onde a decisão de routing é por tipo de tarefa e não por complexidade.

A matemática que ninguém publica: quanto você economiza

A tabela abaixo mostra a economia de custo em um workload realista de 1 milhão de requisições por mês, assumindo distribuição de complexidade típica: 70% rotineiras, 20% intermediárias, 10% complexas.

Cenário	Modelo	% do tráfego	Custo por 1M tokens (input/output)	Custo mensal (1M req, ~500 tokens/req)
Sem routing	Frontier model único	100%	$2,00/$8,00	~$5.000
Rule-based	SLM para 70%, frontier para 30%	70/30	$0,24/$0,24 (SLM) + $2,00/$8,00 (frontier)	~$1.580
BERT classifier	SLM para 86%, frontier para 14%	86/14	$0,24/$0,24 (SLM) + $2,00/$8,00 (frontier)	~$820
Cascade	SLM resolve 75%, 25% escala para frontier	75/25	$0,24/$0,24 (SLM) + $2,00/$8,00 (frontier) + verificador	~$1.400

Os números são ilustrativos e assumem 500 tokens por requisição (média de input + output). O ponto é a ordem de magnitude: rule-based routing corta 68% do custo, BERT classifier corta 84% e cascade corta 72%. O BERT classifier atinge economia próxima ao teto teórico do RouteLLM porque envia apenas 14% do tráfego para o modelo caro, espelhando o resultado benchmark do paper.

Em escala, a diferença é dramática. A Inworld AI reporta que entre 100.000 e 500.000 usuários ativos diários, a diferença entre routing e não routing é de $200.000 a $400.000 por mês (Inworld AI, 2026). Acima de 500.000 DAU, routing não é otimização: é a diferença entre um negócio viável e um que perde dinheiro a cada requisição.

Cinco ferramentas production-ready em 2026

Ferramenta	Tipo	Routing strategy	Open-source	Melhor para
LiteLLM	Gateway	Rule-based + cost-based	Sim	Times que querem um gateway unificado com fallback, retry e caching integrados
Portkey Gateway	Gateway	Rule-based + caching + observabilidade	Não (managed)	Times que querem observabilidade integrada sem bolt-on
RouteLLM	Router	MF, BERT, causal LLM, SW ranking	Sim	Times que querem o router acadêmico validado por peer review
Semantic Router	Router	Embedding-based	Sim	Intent classification e guardrails com latência sub-ms
OpenRouter	Managed	Multi-provider routing	Não	Times que querem rotear entre providers sem self-host

A escolha depende de três fatores. Primeiro, onde o routing acontece: se no gateway (LiteLLM, Portkey) ou no router dedicado (RouteLLM, Semantic Router). Segundo, se a equipe quer controlaer o router ou delegar ao managed (OpenRouter). Terceiro, o tipo de decisão: por custo (LiteLLM cost-based), por complexidade (RouteLLM) ou por intenção (Semantic Router).

Arquitetura híbrida: onde model routing encontra IA soberana

Model routing ganha uma dimensão adicional quando combinado com arquitetura híbrida cloud-on-prem. O routing deixa de ser apenas sobre custo e passa a ser sobre soberania de dados, latência e residência.

A arquitetura híbrida em três níveis descrita por Tian Pan (2026) funciona assim. Nível 1: o SLM roda on-device ou on-premise. Zero custo de rede, zero risco de privacidade, latência mínima. Nível 2: dados sensíveis que precisam de mais compute vão para uma nuvem privada. Nível 3: queries que precisam de frontier capability e não contêm dados sensíveis vão para a nuvem pública.

O router é o componente que decide qual nível processa cada requisição. A AT&T reportou 90% de redução de custo e 70% de redução de latência após adotar essa arquitetura (SIMO GmbH, 2026, citando AT&T). A redução de latência é o efeito de mandar 70% a 80% do tráfego para um modelo local que responde em milissegundos em vez de fazer round-trip à nuvem.

Para o contexto brasileiro, essa arquitetura é diretamente aplicável. Um órgão público que deploya um SLM on-premise para handling de 80% das requisições de cidadãos e escala para um frontier model em nuvem apenas nos 20% de casos complexos reduz custo, mantém dados sensíveis dentro do perímetro da instituição e garante latência baixa para a maioria das interações. É exatamente a arquitetura que a BaXiJen propõe com o BXat: SLM local como primeira camada, escalação controlada quando necessário.

Conexão com evals: você só roteia bem o que você mede

Model routing pressupõe que você sabe quando o SLM falha e quando o frontier model é necessário. Isso requer um pipeline de avaliação que rode continuamente em produção. Sem evals, o router opera no escuro.

O pipeline mínimo de avaliação para routing tem três componentes. Primeiro, um conjunto de avaliação de qualidade: um dataset representative do seu domínio com respostas de referência, rodado periodicamente contra o SLM e o frontier model. Segundo, um monitor de confiança: para cada resposta do SLM em produção, um score de confiança (pode ser logprob do próprio modelo, um modelo de verificação separado ou um ensemble). Terceiro, um loop de feedback: quando o SLM falha e o cascade escala, a falha é registrada e alimenta o dataset de avaliação, melhorando o router ao longo do tempo.

Sem esse loop, o router degrada. Modelos são atualizados, distribuições de query mudam, e o que era uma boa decisão de routing em janeiro pode ser subótima em junho. O data flywheel descrito por Khimananda (2026) e o conceito de continuous learning de production data apontado por Zylos Research (2026) são o complemento natural de model routing: o router aprende com o que falha e melhora continuamente.

Por que isso importa para IA brasileira

O Brasil tem uma vantagem estrutural que a maioria dos mercados não tem: o custo de mão de obra de infraestrutura é relativamente baixo, e o custo de API em dólar é relativamente alto. A combinação de câmbio desfavorável com pricing de API em USD faz com que self-hosting de SLMs seja financeiramente mais atrativo no Brasil do que nos EUA. Um cluster de 2x RTX 3060 12GB (hardware acessível, ~R$ 6.000 usado) roda um modelo de 8B parâmetros servindo 50 a 100 requisições por minuto com latência sub-segundo. O custo de API equivalente para o mesmo volume em frontier model ultrapassaria o custo do hardware em semanas.

Model routing é a peça que torna essa arquitetura viável em produção. Sem routing, você escolhe entre frontier model caro (custo proibitivo em escala) e SLM para tudo (qualidade insuficiente para casos complexos). Com routing, você obtém qualidade de frontier model no volume que precisa, custo de SLM no volume que pode, e dados sensíveis nunca saem do perímetro quando não precisam.

A BaXiJen constrói essa arquitetura desde o primeiro dia. O BXat opera com SLMs on-premise como camada primária e escala para modelos maiores apenas quando a complexidade da requisição exige. Não é uma decisão de produto. É uma decisão de arquitetura, de custo e de soberania.

Framework de decisão: quando implementar model routing

A decisão de implementar routing depende de três fatores. O primeiro é volume: abaixo de 10.000 requisições por dia, o custo de implementar e manter um router excede a economia. Entre 10.000 e 100.000, o payback é de semanas. Acima de 100.000, routing é obrigatório. O segundo é heterogeneidade de tarefas: se 90% do seu tráfego é uma única tarefa simples, um SLM único sem router resolve. Se o tráfego mistura classificação, sumarização, raciocínio e geração criativa, routing é onde a economia acontece. O terceiro é maturidade de observabilidade: sem logging de qualidade por requisição, o router opera no escuro. Se você não consegue medir a taxa de escalonamento, o routing é uma aposta, não uma engenharia.

A recomendação prática é começar com rule-based routing. Classifique suas requisições em três buckets (simples, intermediária, complexa) com regras determinísticas. Meça a distribuição. Se 70%+ é simples, implemente cascade com um SLM local. Se a distribuição é mais espalhada, invista em um classificador BERT treinado com seus dados. O RouteLLM é open-source e pode ser adaptado para seu domínio com algumas centenas de exemplos rotulados.

Conclusão

Model routing em 2026 não é uma otimização avançada para times de IA de grande porte. É infraestrutura básica para qualquer operação que serve mais de 10.000 requisições por dia. O paper RouteLLM provou em peer review que a economia é real: 85% no benchmark, 40% a 85% em produção. As ferramentas são open-source e production-ready. A arquitetura híbrida amplifica o ganho com soberania de dados e latência reduzida.

O custo de não implementar routing é o custo de pagar 100 vezes mais do que precisa em 70% a 80% das requisições. Em escala, esse é o custo que torna IA em produção inviável. Em um mercado onde o dólar custa R$ 5,50, esse é o custo que decide quem sobrevive.

Antes de tudo, Brasileiro.

Referências

• Ong, I., Almahairi, A., Wu, V., Chiang, W.-L., Wu, T., Gonzalez, J. E., Kadous, M. W., & Stoica, I. (2024). RouteLLM: Learning to Route LLMs with Preference Data. arXiv:2406.18665. Apresentado no ICLR 2025.
• Ong, I., Almahairi, A., Wu, V., Chiang, W.-L., Wu, T., Gonzalez, J. E., Kadous, M. W., & Stoica, I. (2024). RouteLLM: An Open-Source Framework for Cost-Effective LLM Routing. LMSys Blog, 1 de julho de 2024. Disponível em: https://www.lmsys.org/blog/2024-07-01-routellm
• Digital Applied (2026). LLM Model Routing in 2026: Cost-Quality Optimization. 14 de junho de 2026. Disponível em: https://www.digitalapplied.com/blog/llm-model-routing-2026-cost-quality-optimization-engineering-guide
• Inworld AI (2026). AI Model Routing Explained: How to Cut LLM Costs with Intelligent Model Selection. 23 de julho de 2026. Disponível em: https://inworld.ai/resources/ai-model-routing-cost-reduction
• Zylos Research (2026). LLM Routing: Intelligent Model Selection for Cost and Performance Optimization. 29 de janeiro de 2026. Disponível em: https://zylos.ai/research/2026-01-29-llm-routing-intelligent-model-selection
• Khimananda, O. (2026). LLM Cost Optimization for Production Apps: 2026 Guide. Atualizado em agosto de 2026. Disponível em: https://khimananda.com/blog/llm-cost-optimization-for-production-apps
• SIMO GmbH (2026). LLM Orchestration: Why Multi-Model Strategies Determine Business Success in 2026. Disponível em: https://simo-online.com/en/blog/llm-orchestrierung-multi-modell-strategie-unternehmen-2026
• PE Collective (2026). LLM API Pricing 2026: 20+ Models Compared Per Token. Atualizado em abril de 2026. Disponível em: https://pecollective.com/blog/llm-api-pricing-comparison
• Princeton IT Services (2026). Hybrid AI Architecture, Part 2: Routing Models to Reduce Cost Without Reducing Quality. 2 de julho de 2026. Disponível em: https://princetonits.com/hybrid-ai-architecture-part-2-routing-models-to-reduce-cost-without-reducing-quality
• Pan, T. (2026). Hybrid Cloud-Edge LLM Architecture: Routing Inference Where It Actually Belongs. 10 de abril de 2026. Disponível em: https://tianpan.co/blog/2026-04-10-hybrid-cloud-edge-llm-architecture-routing-inference
• AY Automate (2026). 7 Best Open-Source LLM Orchestration and Routing Tools (2026). Disponível em: https://www.ayautomate.com/blog/open-source-llm-orchestration-tools
• LeanLM (2026). LLM Cost Optimization: How to Cut Spend 50 a 90%. Disponível em: https://leanlm.ai/blog/llm-cost-optimization