A maioria dos agentes de IA utiliza um único modelo para tudo. A etapa de planejamento, as chamadas de ferramentas, a sumarização, a recuperação de erros. Isso funciona para demonstrações. Em produção, é um desperdício.
Uma etapa de planejamento que exige raciocínio profundo não precisa do mesmo modelo que uma etapa de extração de JSON. Uma tarefa de geração de código tem requisitos diferentes de uma tarefa de classificação. Usar o Claude Opus 4.6 ($25/1M output tokens) para formatar uma string de data é como contratar um arquiteto sênior para pintar uma parede.
Veja como construir agentes que roteiam cada etapa para o modelo ideal.
Se você estiver trabalhando na camada de API em vez da camada de agente, leia Design de API Agent-First e Por que as Equipes Mudam de APIs de Modelos Diretos para uma API de IA Unificada junto com esta página. Agentes multi-modelo funcionam melhor quando a superfície da API subjacente é estável o suficiente para trocar modelos sem reescrever o código de orquestração.
A Arquitetura de Agente Multi-Modelo
User Request
│
▼
┌─────────────┐
│ Router │ ← Classifica a complexidade da tarefa
│ (fast model)│
└──────┬──────┘
│
┌───┴───┐
▼ ▼
┌──────┐ ┌──────┐
│Simple│ │Complex│
│Model │ │Model │
└──┬───┘ └──┬───┘
│ │
▼ ▼
┌─────────────┐
│ Aggregator │ ← Combina os resultados
│ (fast model)│
└─────────────┘
Três componentes:
- Um roteador que classifica as tarefas recebidas por complexidade
- Um pool de modelos correspondentes a diferentes tipos de tarefas
- Um agregador que combina os resultados quando necessário
Na prática, agentes em produção geralmente precisam de mais duas peças:
- Uma política de fallback para quando o modelo preferido falha ou fica lento
- Uma camada de telemetria que registra a escolha do modelo, latência e custo por etapa
Sem esses dois, um agente multi-modelo rapidamente se transforma em uma caixa preta com comportamento imprevisível.
Implementação com OpenAI SDK
Usando uma única chave de API através de um agregador, você pode acessar todos os modelos sem gerenciar múltiplos SDKs:
from openai import OpenAI
client = OpenAI(
api_key="sk-lemon-xxx",
base_url="https://api.lemondata.cc/v1"
)
# Model pool with cost/capability tiers
MODELS = {
"router": "gpt-4.1-mini", # $0.40/1M in - fast classification
"simple": "gpt-4.1-mini", # $0.40/1M in - extraction, formatting
"reasoning": "claude-sonnet-4-6", # $3.00/1M in - planning, analysis
"complex": "gpt-4.1", # $2.00/1M in - code gen, multi-step
"budget": "deepseek-chat", # $0.28/1M in - bulk processing
}
def route_task(task: str) -> str:
"""Use a cheap model to classify task complexity."""
response = client.chat.completions.create(
model=MODELS["router"],
messages=[
{"role": "system", "content": """Classify this task into one category:
- simple: data extraction, formatting, translation
- reasoning: analysis, planning, comparison
- complex: code generation, multi-step problem solving
- budget: bulk processing, non-critical tasks
Reply with just the category name."""},
{"role": "user", "content": task}
],
max_tokens=10
)
category = response.choices[0].message.content.strip().lower()
return MODELS.get(category, MODELS["simple"])
def execute_task(task: str, context: str = "") -> str:
"""Route task to appropriate model and execute."""
model = route_task(task)
messages = []
if context:
messages.append({"role": "system", "content": context})
messages.append({"role": "user", "content": task})
response = client.chat.completions.create(
model=model,
messages=messages
)
return response.choices[0].message.content
Agente do Mundo Real: Pipeline de Code Review
Aqui está um agente multi-modelo prático que revisa pull requests:
def review_pr(diff: str) -> dict:
"""Multi-model PR review pipeline."""
# Step 1: Classify changes (cheap model)
classification = client.chat.completions.create(
model="gpt-4.1-mini",
messages=[{
"role": "user",
"content": f"Classify these code changes: {diff[:2000]}\n"
"Categories: bugfix, feature, refactor, docs, test"
}],
max_tokens=20
).choices[0].message.content
# Step 2: Security scan (reasoning model)
security = client.chat.completions.create(
model="claude-sonnet-4-6",
messages=[{
"role": "system",
"content": "You are a security reviewer. Check for: "
"SQL injection, XSS, auth bypass, secrets in code, "
"unsafe deserialization. Be specific about line numbers."
}, {
"role": "user",
"content": f"Review this diff for security issues:\n{diff}"
}]
).choices[0].message.content
# Step 3: Code quality (general model)
quality = client.chat.completions.create(
model="gpt-4.1",
messages=[{
"role": "user",
"content": f"Review code quality: naming, structure, "
f"error handling, test coverage.\n{diff}"
}]
).choices[0].message.content
# Step 4: Summary (cheap model)
summary = client.chat.completions.create(
model="gpt-4.1-mini",
messages=[{
"role": "user",
"content": f"Summarize this PR review in 3 bullet points:\n"
f"Type: {classification}\n"
f"Security: {security[:500]}\n"
f"Quality: {quality[:500]}"
}]
).choices[0].message.content
return {
"classification": classification,
"security": security,
"quality": quality,
"summary": summary
}
Detalhamento de custos para uma revisão de PR típica (diff de 2K tokens):
| Etapa | Modelo | Tokens de Entrada | Custo |
|---|---|---|---|
| Classificar | GPT-4.1-mini | ~2.100 | $0.0008 |
| Segurança | Claude Sonnet 4.6 | ~2.500 | $0.0075 |
| Qualidade | GPT-4.1 | ~2.500 | $0.0050 |
| Resumo | GPT-4.1-mini | ~1.200 | $0.0005 |
| Total | ~$0.014 |
Usar o Claude Sonnet 4.6 para todas as quatro etapas custaria ~$0.028. A abordagem multi-modelo reduz os custos em 50%, utilizando o modelo mais forte onde ele é mais importante (revisão de segurança).
Roteamento por Capacidade, não Apenas por Preço
Muitas equipes começam o roteamento multi-modelo com uma regra simples: tarefas caras vão para modelos caros, tarefas baratas vão para modelos baratos.
Esse é um bom primeiro passo, mas não é suficiente.
Uma política de roteamento mais robusta analisa quatro dimensões:
- profundidade de raciocínio
- tamanho do contexto
- confiabilidade no uso de ferramentas (tool-use)
- sensibilidade à latência
Isso leva a regras melhores:
- planejamento e decomposição vão para um modelo focado em raciocínio
- extração e formatação vão para um modelo barato e rápido
- revisão de código vai para o modelo com o melhor comportamento de detecção de bugs
- análise de todo o repositório vai para o modelo com a maior janela de contexto
Esta é a mesma razão pela qual a comparação de modelos de codificação e a comparação de preços devem informar seu roteador, em vez de ficarem em uma pasta de pesquisa separada.
Integração com LangChain
from langchain_openai import ChatOpenAI
# Create model instances with different configs
fast = ChatOpenAI(
model="gpt-4.1-mini",
api_key="sk-lemon-xxx",
base_url="https://api.lemondata.cc/v1"
)
reasoning = ChatOpenAI(
model="claude-sonnet-4-6",
api_key="sk-lemon-xxx",
base_url="https://api.lemondata.cc/v1"
)
# Use in LangChain chains
from langchain_core.prompts import ChatPromptTemplate
classify_chain = ChatPromptTemplate.from_template(
"Classify: {input}"
) | fast
analyze_chain = ChatPromptTemplate.from_template(
"Analyze in depth: {input}"
) | reasoning
Quando Usar Agentes Multi-Modelo
O roteamento multi-modelo adiciona complexidade. Vale a pena quando:
- Seu agente lida com diversos tipos de tarefas (não apenas chat)
- Os custos mensais de API excedem $100 (a economia torna-se significativa)
- Você precisa de pontos fortes específicos de modelos (Claude para código, Gemini para contexto longo, GPT para velocidade)
- A latência é importante para algumas etapas, mas não para outras
Para chatbots simples ou agentes de propósito único, um único modelo é suficiente. O custo fixo de roteamento não se justifica quando cada solicitação precisa da mesma capacidade.
O ponto de virada geralmente é um destes:
- você está pagando por raciocínio de alto nível em tarefas de baixo valor
- as interrupções de um único provedor agora representam um risco real para o negócio
- as necessidades de contexto variam drasticamente ao longo do workflow
- você precisa de estágios mais baratos de revisão / extração / sumarização em torno de um estágio central caro
Se nada disso for verdade, um único modelo ainda é a resposta certa.
Modos de Falha Comuns
Sistemas multi-modelo falham de maneiras previsíveis:
1. O roteador é "esperto" demais
Se o prompt do roteador se tornar um exercício gigante de taxonomia, você gastará demais apenas decidindo o que fazer. Mantenha o roteador simples e direto.
2. Desvio nos contratos de saída (Output contracts)
Um modelo retorna JSON limpo, outro retorna texto com um bloco JSON, e seu parser downstream quebra. Use esquemas explícitos e validação em cada transferência.
3. O fallback altera a qualidade silenciosamente
Roteiar para um modelo mais barato durante uma sobrecarga do provedor pode fazer o agente parecer instável se o usuário perceber um perfil de qualidade totalmente diferente. É por isso que a estratégia de rate limiting deve fazer parte do design, não ser um pensamento tardio.
4. Falta de relatórios de custos
Se você não registrar a escolha do modelo, o custo e a latência por etapa, não poderá dizer se o design multi-modelo está realmente economizando dinheiro.
Um Loop de Avaliação Mínimo
Você não precisa de uma plataforma de avaliação gigante para operar um agente multi-modelo de forma responsável.
Comece com uma planilha ou uma tabela de banco de dados por execução:
- categoria da tarefa do usuário
- decisão do roteador
- modelo final usado por etapa
- latência por etapa
- custo total de tokens
- se o fallback foi acionado
- se o usuário aceitou a resposta
Isso fornece sinal suficiente para responder às perguntas que importam:
- O roteador está escolhendo o modelo caro correto com frequência suficiente?
- Qual etapa está consumindo a maior parte do orçamento?
- Os fallbacks estão salvando as execuções ou apenas escondendo a instabilidade?
- O caminho barato é bom o suficiente para tarefas repetitivas?
É também por isso que um gateway unificado ajuda. Quando o uso do modelo é distribuído entre muitos provedores, é mais difícil montar um registro de execução comparável. Quando tudo passa por uma única camada de API, o fardo da instrumentação diminui.
Mantenha a Arquitetura "Sem Graça" (Boring)
Os melhores agentes multi-modelo não parecem exóticos. Eles parecem operacionalmente estáveis e previsíveis.
Isso significa:
- um formato de solicitação estável em sua camada de orquestração
- um único lugar para definir regras de roteamento
- um único lugar para inspecionar custo e latência
- uma política de fallback por família de tarefas
- uma única fonte de verdade para allowlists de modelos
Se o gráfico do seu agente parece inteligente, mas seus operadores não conseguem explicar por que uma solicitação foi para um modelo em vez de outro, o design não está finalizado.
Quando Não Usar um Agente Multi-Modelo
Também existem casos claros onde o design mais simples vence.
Não adicione roteamento apenas porque o catálogo de modelos é grande.
Atenha-se a um único modelo quando:
- o produto realiza uma tarefa estreita repetidamente
- as diferenças de qualidade entre os modelos são irrelevantes para o usuário
- seu tráfego é muito baixo para que a otimização de custos importe
- sua superfície de operações já carece de instrumentação
- você ainda não tem avaliações (evals) fortes o suficiente para dizer se o roteamento ajudou ou prejudicou
Um único modelo bem escolhido com boas tentativas (retries), higiene de prompt e observabilidade muitas vezes supera um gráfico multi-modelo chamativo em que ninguém confia.
A pergunta certa não é "podemos rotear?". É "o roteamento produz melhor qualidade, menor custo ou um comportamento de falha mais seguro para este workflow?".
Se a resposta for vaga, mantenha a arquitetura simples até que o próprio workflow se torne mais diversificado.
Principais Conclusões
- Use o modelo mais barato que lide bem com cada etapa
- Reserve modelos caros para tarefas que genuinamente precisam deles
- As etapas de classificação/roteamento devem sempre usar o modelo mais barato disponível
- Meça o custo real por execução do agente, não apenas o preço por token
- Um agregador de API com uma única chave simplifica significativamente o acesso multi-modelo
Agentes multi-modelo não são inerentemente melhores. Eles são melhores quando o workflow contém genuinamente diferentes tipos de trabalho.
Acesse todos os modelos através de uma única API: LemonData fornece mais de 300 modelos com uma única chave de API. Construa agentes multi-modelo sem gerenciar múltiplas contas de provedores ou reinventar o roteamento para cada par de provedores.