Roteamento SLM→LLM: A Arquitetura que Manda 80% do Tráfego para o Modelo Pequeno

Na quarta-feira eu abri o dashboard de custo de inferência do nosso produto com uma pergunta específica na cabeça: quanto do gasto está indo para requisição que realmente precisava do modelo caro. Não era curiosidade acadêmica, era um pedido do financeiro depois de três meses seguidos de crescimento de linha.

A resposta foi constrangedora. A maior fatia do gasto vinha de chamadas que qualquer pessoa olhando a transcrição classificaria como triviais: extrair três campos de um texto, decidir se um ticket é de cobrança ou de suporte técnico, reescrever uma frase em tom mais formal. Coisa que um modelo de 3 bilhões de parâmetros rodando na nossa própria GPU resolveria sem suar. Estávamos pagando preço de raciocínio de fronteira para fazer classificação de intenção.

O incômodo não é novo e a solução também não. O que mudou em 2026 é que ela deixou de ser um truque de quem tinha time de infra sobrando e virou o padrão default de arquitetura em produto de IA. A ideia é simples de descrever e chata de executar: colocar um roteador leve na frente de tudo, classificar cada requisição, mandar a maior parte para um modelo pequeno e escalar para o modelo grande só na cauda longa que de fato precisa.

Vou destrinchar isso hoje: a anatomia da arquitetura, como calibrar a política sem chutar número, as duas escolas de roteamento que disputam espaço, onde a coisa quebra em produção e quando simplesmente não vale a pena montar essa máquina toda.

A Anatomia De Um Roteador SLM→LLM

O roteador tem três peças e a maioria das implementações que vi só cuidou bem de uma delas. A primeira é o classificador: o componente que olha a requisição e produz um sinal sobre a dificuldade dela. A segunda é a política de escalonamento: a regra que transforma esse sinal numa decisão de qual modelo chamar. A terceira, a que quase todo mundo trata como detalhe, é o fallback: o que acontece quando o próprio roteador falha, fica lento ou devolve algo inesperado.

Uma coisa que surpreende quem está montando isso pela primeira vez é que o classificador quase sempre é ele mesmo um modelo pequeno. Não precisa ser generativo. Um encoder de algumas centenas de milhões de parâmetros com uma cabeça de classificação em cima resolve, e resolve com uma latência que é ordem de grandeza menor que qualquer geração de texto. O ponto crítico é que a inferência do roteador precisa ser desprezível perto do que ele economiza, senão você acabou de inventar um imposto sobre cada requisição.

A política de escalonamento é onde mora o design real. Ela pode agir antes da geração, decidindo pelo modelo com base só na entrada, ou depois, deixando o SLM tentar e escalando se o resultado não passar num teste barato. As duas coisas convivem bem, e o padrão que mais tem me convencido combina as duas: um corte grosso a priori que manda o óbvio para cada lado, e um segundo corte a posteriori que resolve a zona cinza.

O fallback é o que separa protótipo de produção. Se o classificador ficar indisponível, o comportamento seguro é mandar tudo para o modelo grande e deixar o custo subir naquele intervalo, não travar a requisição. Se o SLM retornar JSON malformado para o mesmo esquema, isso é sinal de escalonamento, não de retry infinito.

Na prática o esqueleto fica parecido com isto:

THRESHOLD = 0.62          # calibrado por replay, nao chutado
MIN_CONFIDENCE = 0.55     # limiar de incerteza do proprio SLM

def route(req):
    try:
        p_slm_ok = router.score(req)      # o roteador e ele mesmo um modelo pequeno
    except RouterError:
        # fallback conservador: na duvida, paga caro e nao derruba
        return llm.generate(req, motivo="router_indisponivel")

    if p_slm_ok < THRESHOLD:
        return llm.generate(req, motivo="escalonamento_a_priori")

    resp = slm.generate(req)

    # escalonamento a posteriori: o pequeno pede ajuda
    if resp.uncertainty > (1 - MIN_CONFIDENCE) or not resp.valida_schema():
        return llm.generate(req, motivo="escalonamento_a_posteriori")

    return resp

Repare que cada saída carrega um motivo. Isso não é enfeite. Sem rotular por que cada requisição foi para onde foi, você não consegue nem depurar a política nem explicar a conta no fim do mês, e vai acabar mexendo em threshold no escuro.

O Que O Número De 10 A 30 Vezes Realmente Diz

A justificativa econômica dessa arquitetura vem de uma assimetria grande demais para ignorar. No position paper "Small Language Models are the Future of Agentic AI", pesquisadores da NVIDIA estimam que servir um SLM de 7 bilhões de parâmetros é de 10 a 30 vezes mais barato que servir um modelo de 70 a 175 bilhões. Vale ler o que está entre parênteses no paper: essa comparação é em latência, consumo de energia e FLOPs, não em preço de tabela de API.

Faço questão de sublinhar isso porque é onde muita apresentação de arquitetura escorrega. Se você serve o SLM na sua própria infra, o ganho de FLOPs vira ganho de custo de forma bem direta. Se você consome os dois via API de terceiro, o que vale é o diferencial de preço praticado, que pode ser maior ou menor que 10 vezes dependendo do par de modelos e do momento. Já escrevi em uma análise sobre por que os preços de LLM despencaram e o que isso muda no FinOps sobre como essa curva de preço se move rápido demais para você ancorar uma decisão de arquitetura num print de tabela de seis meses atrás.

Do lado da qualidade, a evidência mais citada continua sendo o RouteLLM, o framework aberto que a LMSYS publicou treinando roteadores com dados de preferência do Chatbot Arena. Os números deles são específicos e ajudam a calibrar expectativa: redução de custo acima de 85% no MT Bench, 45% no MMLU e 35% no GSM8K em comparação com usar só o GPT-4, mantendo 95% da performance do GPT-4. O detalhe mais interessante do relatório é que o melhor roteador atingiu 95% da performance do GPT-4 chamando o GPT-4 em apenas 14% das requisições, depois que o dataset de treino foi aumentado com um juiz LLM.

Guarde a diferença entre os três benchmarks, porque ela é o aviso mais honesto do estudo. Oitenta e cinco por cento de economia no MT Bench e trinta e cinco por cento no GSM8K não são o mesmo fenômeno. A economia depende inteiramente da distribuição de dificuldade do seu tráfego. Se a sua carga é majoritariamente conversa curta e extração de campo, você fica perto do primeiro número. Se é majoritariamente raciocínio matemático em várias etapas, fica perto do terceiro, ou nem isso.

Antes do RouteLLM já havia o FrugalGPT, de Stanford, que atacou o mesmo problema pela via da cascata: em vez de decidir antes, chamar modelos em ordem crescente de custo e usar um verificador para parar quando a resposta é boa o bastante. Os autores relatam ter igualado a performance do melhor LLM individual com até 98% de redução de custo, um número espetacular e por isso mesmo digno de leitura cuidadosa. Cascata só é barata quando o verificador é barato e confiável, e quando a taxa de acerto do primeiro nível é alta o suficiente para as gerações desperdiçadas não dominarem a conta.

O que eu tiro disso, ao lado do que vejo no meu próprio tráfego, é que a faixa de 70% a 90% das requisições resolvidas pelo modelo pequeno é uma meta razoável para carga de produto típica, não uma promessa. O miolo dessa faixa, algo em torno de 80% do tráfego indo para o modelo pequeno, é a ordem de grandeza para onde os estudos e os relatos de arquitetura híbrida convergem. Repare que isso é uma afirmação sobre volume de requisições, não sobre a fatura: a economia correspondente depende do par de modelos, de quanto contexto cada requisição carrega e de quantas vezes o roteador escala depois de o SLM já ter gerado. Os 85% do MT Bench e os 35% do GSM8K saíram do mesmo roteador — a diferença não está nele, está no tráfego.

Calibrar Sem Chutar: Replay De Tráfego Contra Score De Eval

Aqui está a parte que separa quem tem roteador de quem tem gambiarra: como você escolhe o THRESHOLD do código lá em cima. A resposta errada, e a mais comum, é alguém colocar 0,5 porque é o meio, rodar uma semana e ajustar no feeling quando alguém reclama.

O jeito certo custa trabalho. Você pega uma amostra representativa do tráfego real de produção, cobrindo pelo menos um ciclo semanal completo para capturar variação de dia útil e fim de semana, e roda essa amostra inteira pelos dois caminhos: só no SLM e só no LLM, guardando as duas respostas de cada requisição.

Aí você pontua as duas respostas com o seu conjunto de evals. Não com "olhômetro", com os mesmos critérios automatizados que você já deveria estar usando para medir qualidade. Isso te dá, para cada requisição, um par de scores mais o score do classificador. Com isso na mão, você desenha a curva que importa: para cada valor possível de threshold, qual a fração de tráfego que fica no SLM e qual a queda média de qualidade. É a curva de custo contra qualidade, e ela quase nunca é linear.

O formato típico dessa curva é o que torna o exercício valioso. Costuma haver uma região larga onde você desloca muito tráfego para o modelo pequeno perdendo quase nada de qualidade, e depois um joelho onde a qualidade despenca rápido. O threshold que você quer está logo antes do joelho, com uma margem. Escolher esse ponto olhando o gráfico é uma decisão de produto, não de engenharia: alguém precisa dizer quanto de queda de qualidade a régua do negócio aceita em troca de quanto de economia.

Uma coisa que aprendi errando: a amostra de replay precisa incluir os casos ruins, não só o caminho feliz. Se você amostrar só requisições que terminaram com sucesso, seu threshold vai ficar otimista, porque justamente as requisições que dão problema são as que mais precisam do modelo grande. Amostre estratificado, incluindo requisições que geraram retry, reclamação ou abandono. É o mesmo cuidado de instrumentação que discuti em como medir e cortar consumo de token em produção, e sem essa base de telemetria o replay não tem de onde sair.

E recalibre com data marcada. Threshold de roteador não é constante física, é ajuste sobre uma distribuição que muda. Trimestral é o mínimo que tenho visto funcionar; mensal se o produto ainda está mudando de forma.

Incerteza Ou Classificação: Duas Escolas De Roteamento

As duas famílias de roteamento resolvem o mesmo problema por caminhos filosoficamente diferentes, e escolher entre elas é a decisão de arquitetura mais consequente do projeto.

O roteamento por classificação de tarefa olha a requisição antes de qualquer geração e responde "isso aqui é uma extração de campo, vai de SLM" ou "isso aqui é um raciocínio multi-etapa sobre dados financeiros, vai de LLM". A vantagem é que a decisão é barata e você nunca desperdiça geração. A desvantagem é que exige uma taxonomia de tarefas que seja estável e dados rotulados para treinar o classificador, e o mundo real insiste em produzir requisições que não cabem em nenhuma das suas categorias.

O roteamento por incerteza inverte a ordem: deixa o modelo pequeno tentar e usa o próprio sinal de confiança dele para decidir se vale escalar. É o que o paper "Confident or Seek Stronger", da Rice University e colaboradores, investiga a fundo, testando estratégias de roteamento baseadas em incerteza em mais de 1500 configurações. Duas conclusões deles mudaram a forma como eu olho o problema. A primeira é que o alinhamento entre incerteza e correção varia muito entre métodos de quantificação de incerteza, e é esse alinhamento, não a incerteza em si, que determina se o roteamento funciona. A segunda é mais desconfortável: a distribuição de incerteza depende mais do SLM específico e do método de quantificação escolhido do que dos dados da tarefa. Ou seja, trocar o modelo pequeno invalida a sua calibração, mesmo que a tarefa seja exatamente a mesma.

Os autores propõem um pipeline de construção de dados de calibração e liberam um conjunto de hold-out, mostrando que dá para inicializar o roteamento em cenários novos sem coletar dados daquele domínio. Isso resolve o problema do arranque a frio, que é justamente onde o roteamento por classificação sofre.

A tabela abaixo é a que uso para conversar com time sobre essa escolha:

A linha do híbrido está por último de propósito. Ele é o desenho que mais tem me convencido no papel, mas só faz sentido depois que você mediu as duas estratégias puras. Montar híbrido de saída é a receita mais rápida para ter um sistema que ninguém consegue depurar quando a conta sobe sem explicação.

Onde Isso Quebra

O primeiro modo de falha é deriva de distribuição, e é silencioso. Você calibra o threshold contra o tráfego de março, o produto lança uma funcionalidade nova em maio, e o perfil das requisições muda sem que ninguém tenha alterado uma linha do roteador. O que acontece a seguir depende do sentido da deriva: se o tráfego ficou mais difícil, a qualidade cai sem que o custo suba, porque o roteador continua mandando tudo para o pequeno com a confiança de antes. Esse é o caso perigoso, porque o alarme que você provavelmente configurou é de custo, e o custo está ótimo.

Daí uma escolha de instrumentação que precisa ser feita cedo: monitore a distribuição do score do roteador, não só a taxa de escalonamento. A taxa de escalonamento é um agregado que esconde mudança de forma. Se a média do score continua em 0,7 mas a variância dobrou, alguma coisa mudou no tráfego e você precisa saber antes do usuário. Ferramentas de monitoramento de LLM em produção já tratam deriva de entrada e de saída como sinal de primeira classe justamente por isso.

O segundo modo de falha é o custo escondido da latência do próprio roteador. Somar algumas dezenas de milissegundos em toda requisição para economizar num subconjunto pode ser péssimo negócio se o seu p95 já está apertado. E não é só o classificador: no roteamento por incerteza, toda requisição que escala pagou uma geração completa do SLM antes de pagar a geração do LLM. Se a taxa de escalonamento subir de 15% para 40% por causa de deriva, você não só perdeu a economia, como está gastando mais e demorando mais do que se nunca tivesse montado o roteador.

O terceiro modo de falha é o mais insidioso, porque não é um bug: é otimizar para a métrica errada. Se a métrica que aparece no relatório é custo por requisição, o roteador vai ser empurrado para mandar cada vez mais tráfego para o SLM, e alguém sempre vai ter o incentivo de mexer no threshold para melhorar o número da apresentação. A queda de qualidade correspondente aparece depois, distribuída em lugares que ninguém liga ao roteador: mais tickets reabertos, mais reformulações do usuário, mais abandono numa etapa específica do funil.

O remédio é acoplar as duas métricas no mesmo painel e no mesmo alarme: custo por requisição sempre ao lado da taxa de retrabalho daquela requisição, nunca sozinho. A diferença entre as duas curvas é exatamente o que o roteamento agressivo demais produz, e se você só mede o que ficou mais barato, vai encontrar economia infinita.

Quando Não Vale A Pena

Nem toda carga merece essa arquitetura, e talvez essa seja a parte mais útil do post. Roteamento é uma máquina com peças móveis, e cada peça é código que alguém vai manter, calibrar e depurar às duas da manhã.

O primeiro caso onde não vale é volume baixo. Se você processa alguns milhares de requisições por dia, a economia absoluta não paga o custo de engenharia de construir, calibrar e operar o roteador, mais o custo de servir o SLM. Faça a conta antes de escrever a primeira linha: pegue a economia percentual otimista, aplique na sua fatura atual e compare com duas ou três semanas de trabalho de uma pessoa mais a manutenção recorrente. Em muitos produtos essa conta não fecha, e a resposta correta é usar um modelo médio bom para tudo e revisitar quando o volume crescer.

O segundo caso é tráfego genuinamente heterogêneo, no sentido de não ter estrutura recorrente. Roteamento funciona porque existe uma cauda longa de requisições complexas separável de um corpo grande de requisições simples. Se a distribuição de dificuldade é aproximadamente uniforme, ou se cada requisição é única o suficiente para que nenhum classificador generalize, o roteador vai acertar pouco acima do acaso e você adicionou latência e complexidade para nada. O sinal precoce disso é o classificador não passar de forma consistente do baseline aleatório no replay: se isso acontecer, pare, não ajuste o threshold.

O terceiro caso é quando a variância de qualidade é inaceitável por natureza do domínio. Em fluxo clínico, jurídico ou financeiro com consequência direta, ter 15% das respostas vindas de um modelo mensuravelmente mais fraco pode ser uma escolha que você não tem o direito de fazer, mesmo que a média fique boa. Média boa com cauda ruim é um perfil de risco diferente de qualidade uniforme, e isso é decisão de produto e de compliance, não de arquitetura.

E o roteamento não substitui as otimizações mais baratas. Cache, redução de prompt de sistema e poda de contexto costumam dar ganho grande com uma fração do esforço, e devem vir antes na fila.

Conclusão

O que me chamou atenção ao juntar essas evidências é que a discussão sobre custo de inferência amadureceu de um jeito específico: saiu de "qual modelo eu uso" para "como eu decido, requisição por requisição, qual modelo usar". É uma mudança de camada. O modelo virou commodity intercambiável e a inteligência migrou para a política que escolhe entre eles.

O que eu não faria é tratar isso como projeto de otimização isolado. O roteador é uma camada de decisão a mais no caminho crítico, com estado, calibração e prazo de validade, e ele só se paga se você tiver telemetria e eval decentes antes. Sem isso, você não vai conseguir nem escolher o threshold nem perceber quando ele parou de servir. É a mesma dependência que já apareceu quando falei sobre rodar SLMs na borda e o que muda quando o modelo sai da nuvem: o modelo pequeno é a parte fácil, a camada de decisão em volta dele é o trabalho real.

Não tenho ainda dados suficientes do meu próprio tráfego para dizer onde nosso joelho de qualidade vai cair, e vou passar as próximas semanas montando exatamente o replay que descrevi aqui antes de mexer em qualquer threshold. Na segunda pretendo puxar o fio adjacente, que é usar modelos lite como subagentes baratos dentro de uma orquestração multiagente, porque o mesmo raciocínio de escolher o menor modelo que resolve se aplica nó a nó num grafo de agentes, e lá a conta fica ainda mais interessante.

Fontes:

• NVIDIA Research — Small Language Models are the Future of Agentic AI (arXiv 2506.02153)
• LMSYS Org — RouteLLM: An Open-Source Framework for Cost-Effective LLM Routing
• arXiv 2502.04428 — Confident or Seek Stronger: Exploring Uncertainty-Based On-device LLM Routing From Benchmarking to Generalization
• arXiv 2305.05176 — FrugalGPT: How to Use Large Language Models While Reducing Cost and Improving Performance
• GenAI Protos — Hybrid SLM + LLM Orchestration: The 2026 Strategy for Cost-Effective Enterprise AI
• tanhdev — SLM Playbook: Hybrid AI Architecture & Self-Hosted vLLM
• Braintrust — What is LLM monitoring? Quality, cost, latency, and drift in production