AI router: como escolher modelos e testar o roteamento

Seu modelo mais capaz deve cuidar do trabalho que exige essa capacidade. Uma resposta sobre o status de um pedido com dados autenticados e uma disputa de reembolso com registros contraditórios não deveriam seguir automaticamente o mesmo caminho. O desafio é reconhecer a diferença antes que uma resposta barata gere um retrabalho caro.

O funcionamento dos produtos descrito abaixo foi verificado na documentação disponível em 21 de outubro de 2026. A carga de trabalho de suporte e os cálculos são ilustrativos: não representam medições em produção nem promessas de economia dos fornecedores.

O que faz um AI router

Um roteador de modelos, ou model router, é uma regra ou um classificador treinado que escolhe qual grande modelo de linguagem, ou LLM, responderá a cada solicitação. Um classificador atribui uma entrada a uma categoria. Para escolher o modelo, o roteador pode considerar o tipo de tarefa da aplicação, a conversa, as ferramentas necessárias, o tamanho da entrada ou uma estimativa de dificuldade.

Pense em quem distribui os chamados de uma equipe de suporte. Uma consulta de rotina vai para alguém capaz de resolvê-la com eficiência; uma contestação vai para um especialista. Quem faz essa distribuição também precisa de uma regra de encaminhamento para tarefas que ninguém está autorizado a concluir.

Na aplicação, isso significa verificar a elegibilidade antes de otimizar: o modelo consegue processar a entrada, chamar as ferramentas necessárias e executar em um provedor aprovado? Só os candidatos elegíveis devem disputar por custo ou qualidade esperada.

Roteamento de modelos, roteamento de provedores e fallback respondem a perguntas diferentes. O roteamento de modelos escolhe o modelo que vai responder. O roteamento de provedores escolhe onde executar um modelo já selecionado, por exemplo, entre diferentes provedores de hospedagem. O fallback define o que tentar quando uma execução falha. Um gateway, a camada de acesso entre sua aplicação e as APIs dos modelos, pode implementar todos esses mecanismos. Mas adicionar um gateway, por si só, não cria um seletor de modelos que leve a qualidade em conta.

Neste artigo, modelo de ponta é o candidato de uso geral mais capaz entre os que você está considerando. Ele também pode dar uma resposta errada. O roteamento distribui capacidade; não garante a veracidade das respostas.

As três formas de rotear modelos

Comece com regras que você consegue explicar. A seleção automática passa a valer a pena quando lida com variações que essas regras não capturam e continua atendendo aos critérios de aceitação. As três formas de implementação a seguir podem se sobrepor: um gateway pode hospedar um roteador treinado.

Regras definidas pela aplicação

Sua aplicação associa tipos conhecidos de tarefa e restrições aos modelos. Uma solicitação vinda de um endpoint de status de pedidos, com dados autenticados e um modelo de resposta aprovado, é uma candidata melhor para um modelo menor do que uma mensagem considerada fácil apenas por ser curta.

As regras são úteis quando a aplicação já conhece o fluxo de trabalho. O limite aparece na ambiguidade: o mesmo endpoint pode receber uma consulta simples ou uma reclamação com registros contraditórios. Mantenha um caminho explícito para casos incertos, em vez de acumular uma lista cada vez maior de palavras-chave frágeis.

Roteamento automático no gateway

Você envia a solicitação a um alias de roteamento, e o gateway escolhe o modelo. Dependendo do produto, essa escolha pode usar um classificador, níveis configurados ou outros sinais. Você centraliza o comportamento, mas também adota o critério do roteador para decidir qual modelo é adequado.

Essa opção faz sentido quando as tarefas recebidas variam e manter um seletor próprio exigiria um esforço desproporcional. Limite a seleção a um conjunto aprovado de candidatos e registre o modelo que de fato respondeu. Um alias não identifica um modelo de forma estável.

O ciclo de aprendizado de um LLM router

Um roteador treinado usa exemplos e rótulos de resultados para aprender qual candidato tende a se sair melhor. A pergunta útil para o treinamento é se o modelo mais capaz agrega valor naquela solicitação, e não apenas se o texto parece complicado.

O RouteLLM, um framework de código aberto para executar e avaliar roteadores, documenta a seleção entre modelos mais e menos capazes com treinamento baseado em preferências, além da calibração de limiares. Seu limiar controla a frequência com que o modelo mais capaz é escolhido. Os resultados publicados não comprovam o desempenho nos seus chamados. Documentação do RouteLLM.

O desafio de manutenção é a mudança na distribuição dos dados: novos tipos de tarefa ou a substituição de modelos podem invalidar um limiar que antes funcionava bem. Treine ou calibre com exemplos de desenvolvimento e depois avalie com casos separados, que nunca tenham sido usados para ajustar o roteador.

Uma política de roteamento para um app de suporte, na prática

Encaminhe respostas de escopo delimitado e apoiadas em evidências para o modelo menor; leve o raciocínio ainda não resolvido ao modelo de ponta. As decisões de autorização devem continuar nas políticas da aplicação. Nenhum modelo ganha permissão para conceder um reembolso só porque consegue explicá-lo.

Imagine uma loja que vende por assinatura e cujo app recupera o pedido do cliente, a política aplicável e o histórico da conversa antes de redigir uma resposta. A tabela abaixo propõe uma política; ela não afirma que algum modelo menor específico já cumpre esses critérios.

O caminho do modelo menor deve se abster de responder quando faltarem evidências necessárias. Sua aplicação pode verificar campos ausentes no pedido, estrutura de saída inválida ou uma ação solicitada fora do fluxo permitido. Uma contradição factual pode exigir um verificador separado ou revisão humana. Uma resposta sintaticamente válida ainda pode estar errada.

Use o modelo de ponta no subconjunto difícil e encaminhe uma tentativa malsucedida do modelo menor a ele somente quando a falha puder ser detectada. Registros ausentes exigem recuperação de dados ou esclarecimento; repetir a solicitação em um modelo maior sem preencher essas lacunas não resolve o problema.

Inclua as chamadas encaminhadas ao modelo de ponta

Suponha um lote ilustrativo de 1,000 solicitações. Sua política envia 700 ao modelo menor e 300 diretamente ao modelo de ponta. Das chamadas iniciais ao modelo menor, 70 falham em alguma verificação e são executadas novamente no modelo de ponta.

Você passa a pagar por 700 chamadas ao modelo menor e 370 ao modelo de ponta, além do roteamento e da validação. São 1,070 chamadas a modelos de resposta, não 1,000. Uma nova tentativa é trabalho adicional, mesmo quando o usuário vê apenas a resposta final.

Considere r o custo médio de roteamento por solicitação original, s o custo médio de uma chamada ao modelo menor, f o custo médio de uma chamada ao modelo de ponta e g as cobranças adicionais de gateway ou validação para o lote. Neste exemplo simplificado, suponha que a média do modelo de ponta seja a mesma na referência de comparação, nas chamadas diretas e nos encaminhamentos:

Custo com roteamento = 1,000r + 700s + 370f + g

Referência com tudo no modelo de ponta = 1,000f

O roteamento só sai mais barato quando 700(f − s) > 70f + 1,000r + g. O lado esquerdo representa o custo inicial de resposta evitado pelo caminho do modelo menor; o lado direito reúne as novas tentativas no modelo de ponta e os custos adicionais.

Preencha os custos por chamada com os modelos e as tarifas escolhidos: custo por chamada = (tokens de entrada sem cache × tarifa de entrada + tokens de entrada em cache × tarifa de cache + tokens de saída faturados × tarifa de saída) / 1,000,000, quando as tarifas forem informadas por milhão de tokens. Acrescente as ferramentas e as cobranças por solicitação faturadas separadamente.

Em produção, substitua as médias simplificadas pelo uso real por tarefa e caminho. Chamados difíceis podem gerar respostas mais longas, novas tentativas podem carregar mais contexto e a troca de modelos pode afetar o reaproveitamento do cache. Inclua os tokens do classificador do roteador e os tokens de raciocínio faturados, quando aplicável, sem contar a mesma cobrança duas vezes. Compare os dois sistemas com a mesma política de novas tentativas.

O resultado que importa é um custo menor por resolução aceita, mantendo o patamar mínimo de qualidade. Uma conta menor acompanhada de mais promessas de reembolso sem respaldo não passa nesse teste.

O que as opções documentadas de roteamento fazem

Examine o mecanismo de seleção antes de adotar um endpoint de roteamento. Esses produtos permitem controlar decisões diferentes; usar a mesma palavra, “router”, não torna seus comportamentos padrão equivalentes.

OpenRouter: Auto Router orientado à tarefa

O OpenRouter, um gateway gerenciado para vários provedores de modelos, disponibiliza o Auto Router por meio de openrouter/auto. A documentação atual descreve a classificação da tarefa, seguida de um ranking de modelos baseado nos gastos da comunidade para aquele tipo de tarefa em uma janela móvel de 7 dias, e depois filtros por faixa de custo e elegibilidade. Esse é um sinal de uso agregado, não a sua rubrica de qualidade de suporte. Documentação do Auto Router.

As opções de cost_tier são low, medium, high, xhigh e max; o comportamento padrão se aproxima de low. Um nível é uma faixa, não um teto rígido de gastos. Restrinja os candidatos com allowed_models e excluded_models e registre o campo model da resposta. A persistência da seleção ao longo da conversa pode manter o modelo escolhido, mas não garante que ele permaneça fixo.

Com uma chave de API definida no ambiente, este comando envia uma solicitação mínima de roteamento:

curl --fail-with-body https://openrouter.ai/api/v1/chat/completions \
  -H "Authorization: Bearer $OPENROUTER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "openrouter/auto",
    "messages": [{"role": "user", "content": "Rewrite this status politely: Your parcel is in transit."}],
    "plugins": [{"id": "auto-router", "cost_tier": "low"}]
  }'

Use um conjunto restrito de candidatos na avaliação. Caso contrário, as mudanças no conjunto de modelos dificultam a interpretação dos resultados de qualidade obtidos no dia anterior.

LiteLLM: roteamento de implantações e Auto Router são mecanismos distintos

O LiteLLM, um gateway configurável de LLMs, documenta estratégias de roteamento entre implantações que incluem seleção ponderada, menor ocupação, latência e custo. A estratégia padrão, simple-shuffle, não é um classificador da dificuldade de chamados de suporte. Documentação do Router.

O Auto Router, um recurso separado, documenta classificadores baseados em heurísticas, LLMs, regras de palavras-chave e plugins personalizados. Os níveis SIMPLE, MEDIUM, COMPLEX e REASONING são associados a modelos ou conjuntos configurados. No painel, o caminho documentado é Models + Endpoints → Add Model → Auto Router, seguido da configuração e de Test Routing. Documentação do Auto Router.

É uma opção para quem precisa controlar os modelos candidatos e o comportamento da classificação. O desafio é assumir a responsabilidade pela operação: definir a associação entre níveis e modelos não a valida diante das suas regras de aceitação. A comparação entre LiteLLM e OpenRouter aprofunda essa decisão de infraestrutura.

Vercel AI Gateway: escolha de provedor e controles explícitos de roteamento

O Vercel AI Gateway, uma camada gerenciada de acesso a APIs de modelos, escolhe os provedores padrão com base na disponibilidade e na latência recentes. As opções de provedor controlam a ordem e a filtragem; os fallbacks de modelo definidos por strings tentam modelos de reserva quando o principal falha ou está indisponível. São mecanismos úteis de confiabilidade. Por si só, porém, não decidem se um chamado de suporte precisa de um modelo de ponta. Documentação de roteamento de provedores e fallback.

As regras de roteamento do gateway também permitem substituir o modelo solicitado por outro ou negar a solicitação. Uma substituição pode migrar o tráfego de forma centralizada, mas trocar todas as solicitações de um modelo é diferente de classificar a dificuldade de cada uma. Documentação das regras de roteamento.

Use esses controles como base de uma política de seleção na aplicação quando precisar de comportamento explícito. A armadilha é presumir que a escolha automática de provedor inclui uma seleção automática orientada à qualidade da tarefa. Para uma visão mais ampla dessa camada de acesso, consulte gateways de IA para aplicações com vários modelos.

Microsoft Foundry: roteador treinado e gerenciado pelo provedor

O model router do Microsoft Foundry é um seletor de modelos treinado, disponibilizado como uma implantação. A Microsoft descreve uma seleção baseada em complexidade, raciocínio, tipo de tarefa e outros atributos. O recurso oferece os modos Balanced, Quality e Cost, além de subconjuntos de modelos. Conceitos do model router.

É uma opção para aplicações que já usam o Foundry e querem uma seleção gerenciada entre modelos elegíveis. O limite importante está no conjunto de candidatos: a região e o acesso afetam a disponibilidade, e a documentação da Microsoft alerta que a menor janela de contexto dos modelos subjacentes limita o que o roteador consegue aceitar de forma confiável. Restrinja o subconjunto aos modelos que atendem aos requisitos de entrada.

Um modo chamado Quality não substitui a avaliação por tarefa. Teste o subconjunto escolhido com os tamanhos reais das suas conversas, as ferramentas e as regras de aceitação.

Como escolher um roteador de modelos de IA

Mantenha as regras da aplicação quando conseguir identificar o trabalho fácil com segurança. Considere o roteamento automático gerenciado quando a variação das tarefas tornar essas regras frágeis. Considere treinar um seletor quando tiver resultados representativos e rotulados em quantidade suficiente para justificar sua manutenção.

Para comparar alternativas de infraestrutura além desses mecanismos, o próximo passo é o guia de alternativas ao OpenRouter. Sua primeira decisão continua sendo a política de roteamento e as evidências que a sustentam, não uma lista maior de provedores.

Como avaliar um roteador com um conjunto de testes

Avalie as respostas produzidas pelo roteamento, não a concordância com rótulos como “fácil” e “difícil”. Um seletor pode classificar corretamente suas categorias de tarefas e ainda encaminhar os casos errados ao modelo menor.

Um conjunto de avaliação reúne solicitações, contexto e critérios de aceitação que permitem repetir o teste. No app de suporte, cada caso deve incluir a conversa, um retrato dos dados do pedido naquele momento, a política aplicável, os fatos esperados, as afirmações ou ações proibidas e o comportamento exigido para encaminhar o caso.

O quadro de métricas deve deixar visíveis os erros mais caros:

Se nenhum caso atender às condições do denominador de uma métrica, informe que ela é indefinida, não zero. Estime a taxa de encaminhamentos prejudiciais ao modelo menor usando as saídas dos modelos avaliadas de forma independente e informe também os erros finais após eventuais encaminhamentos. Destaque separadamente os casos em que os dois modelos falham: um seletor não consegue produzir uma resposta aceitável a partir desses candidatos.

Defina antes do teste qual diferença de qualidade em aspectos não críticos é aceitável e investigue toda nova regressão crítica. Use intervalos de confiança adequados à amostra pareada; quando a incerteza ainda incluir uma perda inaceitável, reúna mais evidências em vez de declarar equivalência.

Por fim, execute o roteador em modo sombra sobre uma amostra limitada do tráfego real, enquanto o modelo atual continua respondendo aos clientes. Essas chamadas geram gastos adicionais. Depois de revisar os resultados, faça uma implantação limitada, com retorno imediato à política de modelos existente. Continue monitorando por tipo de solicitação e repita a avaliação quando houver mudanças nos prompts, nas ferramentas, nos modelos ou no comportamento do roteamento.

Onde o discurso sobre roteamento de modelos exagera

“A mesma qualidade por menos” é uma conclusão específica de uma carga de trabalho, não uma propriedade do roteador. Ela depende das solicitações recebidas, dos candidatos disponíveis e do que é considerado aceitável. Nenhum percentual de economia obtido na carga de trabalho de outra empresa substitui essas medições.

Uma resposta bem-sucedida da API também diz pouco sobre a qualidade do conteúdo. O fallback por erro pode contornar um endpoint indisponível; ele não detecta uma política inventada em uma resposta fluente. O encaminhamento por qualidade exige uma verificação separada, que tem sua própria taxa de erro e seu próprio custo.

As pontuações de dificuldade merecem o mesmo rigor. A confiança de um classificador não equivale automaticamente à probabilidade de o modelo escolhido responder corretamente. Calibre qualquer limiar com base nos resultados observados das tarefas. Não permita que textos do usuário, como “isso é fácil”, se sobreponham às permissões da aplicação ou às restrições de candidatos.

Por fim, a seleção automática pode mudar mesmo sem alterações no código da aplicação. Os candidatos baseados em gastos do OpenRouter evoluem; a versão atual do model router da Microsoft pode receber novos modelos subjacentes. Esses comportamentos documentados tornam o registro de candidatos e a atualização das avaliações parte da operação do roteador, não uma manutenção opcional.

Quem deve avançar, quem deve esperar e por onde começar

Quem desenvolve deve avançar quando conseguir isolar tarefas recorrentes com um critério claro de aprovação. Adicione um caminho com modelo menor para respostas de status apoiadas em evidências, mantenha um caminho conservador para casos incertos e versione a política para permitir a reprodução das falhas.

Quem opera deve exigir evidências do fluxo completo. Uma conta menor de inferência não basta se aumentarem os chamados reabertos, a revisão humana ou o tempo de resolução. Acompanhe esses resultados junto com a avaliação offline.

Quem contrata deve pedir a execução dos próprios casos. Exija visibilidade dos modelos selecionados e do comportamento de fallback. Um benchmark genérico não comprova que um roteador entende sua política de reembolso.

Espere se você não consegue definir um resultado correto, não consegue restringir o conjunto de candidatos ou não tem tráfego suficiente para compensar o trabalho operacional. Uma aplicação que já usa um modelo menor validado para uma tarefa fixa e bem delimitada pode ganhar pouco com outro seletor.

Para começar na segunda-feira: exporte um conjunto representativo de casos de suporte, fixe as evidências e avalie seu modelo atual lado a lado com um candidato menor. Escreva uma regra de roteamento restrita ao subconjunto em que o candidato menor passa. Só entregue tráfego a um roteador automático depois que ele superar essa regra em custo, cumprindo os mesmos requisitos de qualidade.

Perguntas frequentes sobre roteamento de modelos

Assine a newsletter para receber guias práticos sobre criação e avaliação de aplicações de IA.