LLM Router: Roteie Requisições e Corte Custos em 60% [2026]

LLM Router: Roteie Requisições e Corte Custos em 60% [2026]

Um LLM router é uma camada fina entre o seu app e vários modelos de linguagem que escolhe qual modelo atende cada requisição. Ele inspeciona a requisição (tipo de tarefa, complexidade, orçamento de tokens), encaminha para o modelo mais adequado e, se esse modelo falhar, recorre a um backup. O objetivo: respostas na medida certa pelo menor custo por token.

Pagar um modelo de fronteira para responder "qual é a política de reembolso?" é assim que as faturas explodem. A AWS mediu a alternativa em abril de 2025: um router com classificador adiciona 0,53 segundo de latência, um router semântico adiciona 0,10 segundo e até 30% de desconto na fatura ao rotear dentro de uma única família de modelos. Refaça essa conta entre provedores com os preços de tabela de julho de 2026, como fazemos abaixo, e o corte chega a 70%. A maior parte da economia vem de uma única decisão, tomada antes de um único token ser gerado.

Principais Conclusões

• Um LLM router decide qual modelo atende cada requisição, com base no tipo de tarefa, no custo ou na qualidade medida.
• Existem cinco estratégias: baseada em regras, sensível a custo, sensível a latência, semântica (embeddings) e roteamento com classificador LLM.
• O roteamento por regras adiciona ~0 ms e US$ 0; o roteamento com classificador adiciona 300-800 ms mais o custo dos tokens do classificador por requisição.
• O roteamento pode cortar o gasto com tokens em até 60% quando a maior parte do tráfego simples vai para um modelo 10-20x mais barato.
• Provedor único, menos de 10 mil requisições por dia, sem pressão de custo? Pule o router. Fallbacks simples bastam.

O Que um LLM Router Realmente Faz?

Um LLM router executa um pequeno passo de decisão antes de cada chamada de modelo: lê a requisição, pontua contra uma regra de roteamento, escolhe um modelo, envia a chamada e tenta de novo em um fallback se o primeiro modelo falhar. Nada mais muda no seu app. Você continua fazendo uma requisição e recebendo uma resposta.

O ciclo de vida da requisição, em ordem:

1. A requisição chega ao endpoint do router, exatamente como chegaria à API de um modelo.
2. Análise. O router inspeciona o prompt: palavras-chave, contagem de tokens, um embedding ou a pontuação de um classificador.
3. Seleção. A estratégia de roteamento mapeia esse sinal para uma camada de modelo (barato, intermediário, fronteira ou local).
4. Encaminhamento. A chamada vai para o modelo escolhido por uma API compatível com OpenAI.
5. Fallback. Em caso de timeout, limite de taxa ou erro, a requisição tenta de novo na próxima camada da cadeia.

As pessoas buscam "llm gateway vs router" porque a documentação dos fornecedores embaralha os termos. Uma frase resolve: o gateway é o cano; o router é a decisão. São camadas, não rivais, e a maioria dos gateways traz um router embutido.

Segundo a documentação do LiteLLM, o mesmo proxy que guarda as suas chaves virtuais também executa o router. Quer comparar especificamente as ferramentas do nível do cano? Nosso ranking das melhores ferramentas de gateway LLM classifica dez.

Você Realmente Precisa de um LLM Router?

A maioria dos apps pequenos não precisa. Um router se paga quando o tráfego se divide em tipos de tarefa claramente diferentes, quando a fatura de tokens é o seu maior custo de infraestrutura ou quando você usa mais de um provedor e precisa de failover. Abaixo desses limites, retentativas simples mais um modelo de backup garantem a confiabilidade sem a peça móvel extra.

Vamos ser diretos, porque ninguém mais nesse espaço vai ser: se você usa um provedor único com menos de 10 mil requisições por dia, um router é sobrecarga desnecessária. Fallbacks simples ganham.

Por que ser tão direto? Cada rota é uma afirmação ("esta classe de tarefa é segura no modelo barato") que se degrada conforme os modelos, os preços e o seu produto mudam. Só compre esse custo de manutenção quando a economia claramente o superar.

As 5 Estratégias de Roteamento LLM (E Quando Usar Cada Uma)

Toda estratégia de roteamento LLM responde a uma pergunta: em qual sinal você confia o suficiente para escolher um modelo? Regras confiam em palavras-chave. O roteamento por custo confia no orçamento de tokens. O roteamento por latência confia em um cronômetro. O roteamento semântico confia em embeddings. O roteamento com classificador confia em outro LLM. O trade-off tem sempre a mesma forma: mais qualidade de sinal, mais latência e custo adicionados por requisição.

O autocompletar sugere variações como "llm routing strategies", "llm task routing", "llm intent routing" e "llm dynamic routing". Elas se encaixam em cinco padrões:

Um padrão atravessa os cinco: a cascata, também chamada de hierarquia de modelos. Comece barato e escale só em caso de falha ou confiança baixa. Um bot de suporte responde com um modelo de US$ 0,25 por milhão de tokens; se a confiança cair abaixo de 0,7, a mesma requisição tenta de novo em um modelo de fronteira. Você paga por inteligência só quando a camada barata admite que travou.

Para profundidade acadêmica, a biblioteca LLMRouter do ulab-uiuc cataloga mais de 16 algoritmos de roteamento pesquisados (KNN, SVM, MLP, fatoração de matriz, Elo, grafo e estilo BERT). Se o roteamento semântico for a sua escolha, os embeddings exemplares decidem quase tudo; nosso guia dos melhores modelos de embedding mostra quais se sustentam em corpora reais.

Como Construir um LLM Router em Python?

Você constrói um com cerca de 80 linhas de Python puro contra qualquer endpoint compatível com OpenAI. Sem framework obrigatório. Os quatro routers abaixo escalam em sofisticação: regras de palavras-chave, um limite de custo, similaridade de embeddings e um modelo classificador com failover. Cada um imprime o modelo que escolheu, para você ver a decisão acontecendo.

Se você já buscou "how to build an llm router" e só achou stacks de AWS CDK e repositórios acadêmicos, esta seção é a resposta direta. A implementação de referência da AWS é sólida, mas soldada ao Bedrock, ao Lambda e ao CDK. A nossa roda em qualquer lugar para onde o cliente OpenAI aponta: OpenAI, Anthropic por proxy, Ollama em um notebook, vLLM em uma máquina com GPU. Aqui está o router que esboçamos primeiro para clientes.

Passo 1: Router baseado em regras (palavras-chave para modelos)

A linha de base de latência zero. Um mapa de regex decide; tudo que não casar vai para a camada de fronteira.

import re
from openai import OpenAI

client = OpenAI()  # works with OpenAI, Ollama, vLLM, or a LiteLLM proxy

def ask(model: str, prompt: str) -> str:
    r = client.chat.completions.create(
        model=model,
        messages=[{"role": "user", "content": prompt}],
    )
    return r.choices[0].message.content

ROUTES = [
    (re.compile(r"\b(refund|cancel|invoice|password|hours)\b", re.I), "gpt-5-mini"),
    (re.compile(r"\b(summarize|translate|rewrite)\b", re.I), "gpt-5-mini"),
]
FRONTIER = "gpt-5"

def rule_router(prompt: str) -> str:
    for pattern, model in ROUTES:
        if pattern.search(prompt):
            return model
    return FRONTIER

prompt = "How do I cancel my subscription?"
model = rule_router(prompt)
print(model)  # gpt-5-mini: regex hit on "cancel"
print(ask(model, prompt))

Entrada: uma pergunta de suporte. Decisão: regex casou com "cancel". Modelo escolhido: gpt-5-mini. Nenhuma chamada de API é necessária para rotear, e é por isso que esse continua sendo o padrão.

Passo 2: Router sensível a custo (limite de orçamento de tokens)

Mesma ideia, mas o sinal é o tamanho da requisição em vez de palavras-chave. Prompts curtos com orçamento de saída pequeno vão para o barato; todo o resto vai para o fronteira.

def cost_router(prompt: str, max_output_tokens: int = 500) -> str:
    word_count = len(prompt.split())
    if word_count < 60 and max_output_tokens <= 300:
        return "gpt-5-mini"  # $0.25 in / $2 out per M tokens
    return "gpt-5"           # $1.25 in / $10 out per M tokens

prompt = "Write a two-line product description for a ceramic mug."
model = cost_router(prompt, max_output_tokens=120)
print(model)  # gpt-5-mini: short prompt, small output budget

Simplista? Sim. Eficaz? Também, porque o volume de tokens correlaciona com o tamanho da tarefa melhor do que a maioria espera. Essa é a estratégia inteira por trás de vários produtos pagos de "cheap llm router".

Passo 3: Router semântico (embeddings para exemplares)

Para entradas de usuário imprecisas que escapam das palavras-chave, faça o embedding do prompt e compare com embeddings de prompts exemplares. O cluster mais próximo fica com a requisição.

import numpy as np

EXEMPLARS = {
    "gpt-5-mini": [
        "classify this support ticket into a category",
        "extract the shipping address from this email",
    ],
    "gpt-5": [
        "debug this race condition in our worker pool",
        "design a multi-tenant billing schema",
    ],
}

def embed(texts: list[str]) -> np.ndarray:
    r = client.embeddings.create(model="text-embedding-3-small", input=texts)
    return np.array([d.embedding for d in r.data])

CENTROIDS = {m: embed(xs).mean(axis=0) for m, xs in EXEMPLARS.items()}

def semantic_router(prompt: str) -> str:
    v = embed([prompt])[0]
    scores = {
        m: float(np.dot(v, c) / (np.linalg.norm(v) * np.linalg.norm(c)))
        for m, c in CENTROIDS.items()
    }
    return max(scores, key=scores.get)

print(semantic_router("pull the tracking number out of this message"))
# gpt-5-mini: closest to the extraction exemplars

A chamada de roteamento custa um embedding (algumas centenas de tokens) e 50-150 ms. Pré-calcule os centroides na inicialização, não por requisição.

Passo 4: Router com classificador LLM e fallback

O sinal mais forte: um modelo barato lê o prompt e pontua a dificuldade. Essa é a estratégia que a AWS mediu em 0,53 segundo de latência adicionada, então a embrulhamos em uma cadeia de fallback.

def classify_router(prompt: str) -> str:
    verdict = client.chat.completions.create(
        model="gpt-5-mini",
        messages=[{"role": "user", "content":
            "Reply HARD or EASY only. Task: " + prompt}],
        max_tokens=5,
    ).choices[0].message.content.strip().upper()
    return "gpt-5" if verdict.startswith("HARD") else "gpt-5-mini"

def route_and_call(prompt: str) -> str:
    model = classify_router(prompt)
    try:
        return ask(model, prompt)
    except Exception:
        backup = "gpt-5-mini" if model == "gpt-5" else "gpt-5"
        return ask(backup, prompt)  # fallback tier catches the failure

print(route_and_call("Prove this greedy algorithm is optimal."))
# classifier says HARD, so gpt-5 answers

Esse é o exemplo completo de LLM router: quatro funções, um cliente, nenhuma infraestrutura além do que você já roda. Endurecimento para produção é a próxima seção.

Quanto o Roteamento LLM Realmente Economiza?

A AWS mediu o overhead do router em US$ 107,90-US$ 188,90 por mês para cada 100 mil perguntas por dia, com o roteamento por classificador adicionando 0,53 segundo por requisição e o semântico, 0,10 segundo. O lado da economia empequena esse overhead. Nosso exemplo calculado abaixo, construído sobre os preços de tabela de julho de 2026, chega a uma redução de 70,7% no gasto. A pegadinha é o mix de tráfego: você precisa que a maioria das requisições se qualifique para a camada barata.

Duas tabelas. Primeiro, o que o próprio router custa por 1.000 requisições:

O post da AWS de abril de 2025 é o único conjunto de medições publicado de forma independente nesse espaço, então ancoramos nele e rotulamos nossas extensões como estimativas, não números que rodamos. O Bedrock Intelligent Prompt Routing cortou o custo dentro da família em até 30%, segundo a AWS.

Segundo, o exemplo de economia calculado que sustenta o nosso título:

Premissas, rotuladas: 100 mil requisições por mês; 800 tokens de entrada mais 200 de saída por requisição em média; divisão de 80% simples / 20% complexo; preços de tabela da página de preços da Anthropic e da página de preços da OpenAI em julho de 2026, com a tabela completa de tarifas na nossa comparação de preços de APIs LLM. Conta por requisição: o Sonnet 4 custa 800 x US$ 3/M + 200 x US$ 15/M = US$ 0,0054; o GPT-5 mini custa 800 x US$ 0,25/M + 200 x US$ 2/M = US$ 0,0006.

O resultado é uma redução de 70,7%, de onde vêm os 60% do nosso título, com folga. Ressalvas honestas: este é um exemplo calculado, não um benchmark que rodamos. Ele assume que a sua camada barata é 10-20x mais barata e que 80% do tráfego realmente se qualifica. O roteamento dentro da família, o cenário da AWS, fica perto de 30%. E o roteamento é uma alavanca entre muitas; prompt caching e trimming frequentemente se pagam mais rápido, e nosso guia de formas de reduzir custos de APIs LLM classifica todas as doze.

Padrões de Roteamento em Produção

Um router de brinquedo escolhe um modelo. Um router de produção também tenta de novo, balanceia carga, faz cache de repetições e isola chaves de API por equipe. Acima de alguns milhares de requisições por dia, pare de escrever isso à mão e rode um gateway que embute um router.

Os quatro padrões que importam:

• Cadeias de fallback. Camada barata primeiro, fronteira em caso de erro ou timeout. O padrão de maior valor; a maior parte da sua confiabilidade vem só disso.
• Balanceamento de carga. Distribua chamadas entre deploys ou chaves de API duplicados para fugir dos limites de taxa por chave.
• Cache de respostas. Prompts idênticos retornam respostas em cache. Tráfego de suporte se repete mais do que você acredita; taxas de acerto de 10-30% são comuns.
• Chaves virtuais e orçamentos. Emita chaves por equipe com tetos mensais para que um loop desgovernado não queime a fatura inteira.

Isso é próximo da configuração que rodamos na nossa stack de agentes de staging (arquivo: litellm-router.yaml, montado no container do proxy LiteLLM):

model_list:
  - model_name: cheap
    litellm_params:
      model: openai/gpt-5-mini
  - model_name: frontier
    litellm_params:
      model: anthropic/claude-opus-5

router_settings:
  routing_strategy: simple-shuffle
  fallbacks: [{"cheap": ["frontier"]}]
  num_retries: 2
  timeout: 30

Onde cada ferramenta se encaixa, com opinião:

• LiteLLM. Escolha se você quer self-hosted e open source e já roda Docker. Nosso guia de setup do proxy LiteLLM cobre o deploy completo, com chaves e orçamentos inclusos.
• OpenRouter. Escolha se você quer centenas de modelos atrás de uma chave e zero operação. A página de rankings deles serve também como dado de throughput.
• Portkey. Escolha se requisitos enterprise (SSO, logs de auditoria, relatórios de compliance) guiam a decisão.
• Código próprio deste post. Escolha se você está abaixo de ~50 mil requisições por dia e quer zero infraestrutura nova.

Seja qual for a escolha, o ranking de ferramentas de gateway LLM compara dez delas lado a lado.

É Possível Rotear Entre Modelos Locais e APIs Hospedadas?

Sim, e a conta de tokens é sedutora: um modelo local cobra US$ 0 por token, então cada requisição que o Ollama ou o vLLM responde é economia pura. O trade-off é latência e qualidade por watt. O local vence para tarefas simples de alto volume em hardware que você já tem; a API hospedada pega tudo que precisa de um cérebro de fronteira.

A mecânica é anticlimática, e esse é o ponto. O Ollama expõe um endpoint compatível com OpenAI em localhost:11434/v1, e o vLLM serve o mesmo formato. Então todo router acima funciona sem mudanças: aponte base_url para o servidor local, coloque qwen3:8b no slot barato e mantenha gpt-5 como camada de fallback. Para uma caixa de router self-hosted, o LiteLLM vem como imagem Docker, que é o setup de "llm router docker" que as pessoas buscam.

Duas notas de honestidade. Um modelo de 70B em uma A100 serve cerca de 30-40 tokens por segundo; APIs hospedadas ganham disso em throughput de pico, então o roteamento local combina melhor com tráfego de fundo constante do que com chat volátil voltado ao usuário. E modelos locais de 8B tropeçam em chamadas de ferramentas multi-etapas, então mantenha as rotas difíceis apontadas para a nuvem. Se você está escolhendo o próprio motor de serving, vLLM vs SGLang faz o benchmark dos dois.

O roteamento também alimenta setups de agentes de codificação multi-modelo. Um proxy estilo LiteLLM deixa o Claude Code falar com modelos locais e hospedados por um endpoint; veja como usar modelos diferentes no Claude Code para a fiação exata.

Como Saber Se o Roteamento Está Funcionando?

Você mede, ou está chutando. Logue qual modelo respondeu cada requisição, pontue uma amostra das saídas contra uma rubrica e realimente as pontuações nas regras de roteamento. Equipes que pulam esse passo acabam com uma configuração estática que apodrece em silêncio conforme modelos e preços mudam embaixo dela.

O arco de maturação roda regras, depois custo, depois qualidade medida:

1. Logue a rota. Guarde o modelo escolhido, a latência e as contagens de tokens por requisição como uma coluna nos seus traces existentes.
2. Pontue saídas semanalmente. Um juiz LLM ou uma amostra humana, aprovado/reprovado por classe de requisição. Cinquenta saídas avaliadas por classe bastam para guiar.
3. Reajuste. Se a camada barata passa de 95% em uma classe, alargue a regra dela para pegar mais desse tráfego. Se cair abaixo de 90%, aperte.

Aqui está a frase que repetimos para clientes: um router que você nunca reajusta é só uma configuração estática com latência extra. Logue o modelo escolhido, pontue as saídas, realimente as pontuações.

Esse loop é evals mais observabilidade aplicados ao roteamento. Nosso guia de evals de LLM cobre as rubricas de pontuação; o guia de observabilidade de IA cobre onde os traces vivem.

Para Onde Vai a Pesquisa em Roteamento LLM?

A linha acadêmica trata o roteamento como um problema de aprendizado, não um arquivo de configuração. O LLMRouter do ulab-uiuc, a biblioteca que rankeia em primeiro lugar para essa palavra-chave, implementa mais de 16 algoritmos (KNN, SVM, MLP, fatoração de matriz, Elo, grafo, BERT e routers de RL) com um pipeline de benchmark sobre 11 datasets. O paper recente mais citado, RouteLLM (Ong et al., arXiv:2406.18665), treina routers com dados de preferência humana e relata mais de 2x de redução de custo sem perda de qualidade no MMLU e no MT-Bench. A novidade mais recente: routers de ativação de prefill, a linha "prefill is all you need", que leem as ativações internas de um modelo durante o prefill para prever a dificuldade antes da geração começar. A direção é de routers que se treinam sozinhos a partir dos seus dados de eval, que é exatamente o loop de feedback da seção anterior.

Como a Techsy aborda isso: as stacks de agentes que entregamos para clientes B2B rodam exatamente esse padrão, um router de camadas de custo com cadeias de fallback ligadas no gateway, mais reajuste guiado por evals. Se você está avaliando se o roteamento cabe na sua stack, peça uma consulta gratuita e mapeamos o seu mix de tráfego com você.

Sobre o Autor

Mert Batur é cofundador da Techsy.io, onde a equipe entrega agentes de IA, sistemas de automação e pipelines de voz/SDR para clientes B2B. Ele escreve sobre a stack de ferramentas LLM que a equipe da Techsy realmente usa em produção. Conecte no LinkedIn.

Perguntas Frequentes

O que é um LLM router?

Um LLM router é uma camada entre a sua aplicação e vários modelos de linguagem que decide qual modelo atende cada requisição. Ele verifica o tipo de tarefa, o tamanho ou a dificuldade da requisição e encaminha para o modelo mais adequado, com um fallback se esse modelo falhar. Pense nele como um controlador de tráfego para as suas chamadas de API de modelos.

Como funciona o roteamento LLM?

O roteamento LLM funciona em cinco passos: a requisição chega, o router a inspeciona (palavras-chave, contagem de tokens ou um embedding), uma estratégia escolhe uma camada de modelo, a chamada é encaminhada e um modelo de fallback pega qualquer falha. A decisão inteira acontece antes da geração começar, então adiciona milissegundos, não segundos, a menos que um modelo classificador faça a pontuação.

Um LLM router é a mesma coisa que um LLM gateway?

Não. Um gateway é o cano: chaves de API, limites de taxa, orçamentos e logs. Um router é a decisão: qual modelo responde. São camadas, não rivais, e a maioria dos gateways (LiteLLM, Portkey, OpenRouter) embute um router. Você pode rodar um router sem gateway, mas em produção geralmente quer os dois juntos.

O roteamento de modelos realmente economiza dinheiro?

Sim, quando a maior parte do seu tráfego se qualifica para uma camada muito mais barata. Nosso exemplo calculado move 80% das requisições de um modelo de US$ 3/US$ 15 por milhão de tokens para um de US$ 0,25/US$ 2 e corta a fatura em 70,7%. A AWS relatou até 30% para roteamento dentro de uma família de modelos. Se o seu tráfego é uniformemente complexo, a economia encolhe para perto de zero.

Qual é o melhor LLM router open source?

Para produção, LiteLLM: self-hosted, mantido ativamente e combina um gateway com um router. Para algoritmos de nível acadêmico, o LLMRouter do ulab-uiuc implementa mais de 16 estratégias de roteamento da literatura. O RouteLLM é o router mais forte em qualidade por dólar treinado com dados de preferência. A maioria das equipes deve começar com o LiteLLM e só buscar as bibliotecas de pesquisa se precisar de pontuação customizada.

Como construo um LLM router em Python?

Comece com o cliente OpenAI e cerca de 80 linhas de código: um mapa de regras de palavras-chave para modelos, um limite de custo sobre contagens de tokens, similaridade de embeddings com prompts exemplares ou um modelo classificador barato que pontua a dificuldade. Os quatro padrões estão na seção de construção acima, prontos para rodar contra OpenAI, Ollama ou vLLM sem mudanças.

Posso rotear entre modelos locais e APIs na nuvem?

Sim. O Ollama (localhost:11434/v1) e o vLLM expõem endpoints compatíveis com OpenAI, então o mesmo código de router aponta para um modelo local para tráfego barato e uma API hospedada para tráfego difícil. Tokens locais custam US$ 0, mas o hardware e a latência são seus. Esse é o padrão por trás da maioria dos setups multi-modelo do Claude Code.

O que é roteamento semântico?

O roteamento semântico faz o embedding de cada prompt que chega e compara com embeddings de prompts exemplares, enviando a requisição para o modelo dono do cluster de exemplares mais próximo. Ele lida com entradas de usuário imprecisas e parafraseadas que as regras de palavras-chave perdem, ao custo de 50-150 ms mais tokens de embedding por requisição. A AWS mediu 0,10 segundo de latência adicionada.

Quanta latência um router com classificador LLM adiciona?

A AWS mediu 0,53 segundo de latência adicionada para classificação assistida por LLM, contra 0,10 segundo do roteamento semântico. O roteamento baseado em regras e o sensível a custo adicionam aproximadamente zero, porque são caminhos de código puro. Se o seu produto tem um SLA de tempo de resposta apertado, prefira regras, limites de custo ou embeddings, e reserve o classificador para cargas offline ou em fila.

Fontes

• Seifi, N. e Chugh, M. (2025-04-09). "Multi-LLM routing strategies for generative AI applications on AWS." AWS Machine Learning Blog. https://aws.amazon.com/blogs/machine-learning/multi-llm-routing-strategies-for-generative-ai-applications-on-aws/ (acessado em 30 de julho de 2026)
• Código de exemplo da AWS: sample-multi-llm-dynamic-prompt-routing. https://github.com/aws-samples/sample-multi-llm-dynamic-prompt-routing (acessado em 30 de julho de 2026)
• Documentação do LiteLLM. https://docs.litellm.ai (acessado em 30 de julho de 2026)
• Preços da Anthropic. https://www.anthropic.com/pricing (acessado em 30 de julho de 2026)
• Preços da API da OpenAI. https://openai.com/api/pricing (acessado em 30 de julho de 2026)
• LLMRouter do ulab-uiuc. https://github.com/ulab-uiuc/LLMRouter (acessado em 30 de julho de 2026)
• Ong, I. et al. (2024). "RouteLLM: Learning to Route LLMs with Preference Data." arXiv:2406.18665. https://arxiv.org/abs/2406.18665 (acessado em 30 de julho de 2026)
• Rankings do OpenRouter. https://openrouter.ai/rankings (acessado em 30 de julho de 2026)