Usar um único modelo para tudo já não faz mais sentido. Agentes de código como o Claude Code e o Codex gastam a maior parte dos seus tokens em etapas repetitivas e mecânicas — ler arquivos, rodar testes, corrigir lints — enquanto apenas uma fração das chamadas realmente exige raciocínio de fronteira. É exatamente essa incompatibilidade que a NVIDIA atacou em 11 de agosto com um lançamento em duas partes: Nemotron 3.5 Lightning, um modelo MoE open-weight de 30B (3B ativos por token) ajustado para trabalho de agentes em alto volume, e o NeMo Switchyard, um proxy e biblioteca em Rust sob licença Apache-2.0 que roteia o tráfego de LLMs entre modelos e provedores.
O Switchyard é a peça para experimentar primeiro. Ele fica entre o seu agente e os seus backends de modelo e faz três coisas:
- Tradução de protocolos — converte entre os formatos OpenAI Chat, OpenAI Responses e Anthropic Messages, de modo que o Claude Code continue falando com sua API nativa enquanto a requisição é atendida pelo vLLM, NVIDIA NIM, Ollama ou qualquer endpoint compatível com OpenAI.
- Algoritmos de roteamento tipados — LLM-como-classificador, roteamento por estágio orientado a sinais, escalonamento (escalation), divisões A/B aleatórias ou um algoritmo personalizado escrito por você.
- Métricas operacionais — métricas Prometheus cobrindo requisições, erros, latência, tokens e overhead de roteamento.
O começo mais rápido: caminho do launcher
Se você quer o Claude Code, o Codex ou o OpenClaw rodando através de uma rota inteligente em dois minutos:
curl -LsSf https://astral.sh/uv/install.sh | sh
source "$HOME/.local/bin/env"
uv tool install --python 3.12 "nemo-switchyard[cli]"
export OPENROUTER_API_KEY="your-key"
switchyard launch claude --model switchyard
# ou: switchyard launch codex --model switchyard
# ou: switchyard launch openclaw --model switchyardO deployment empacotado expõe um ID de rota chamado switchyard. O launcher inicia o servidor nativo em Rust e aponta o agente para ele — não é preciso arquivo de configuração nesse caminho.
Roteamento personalizado: servidor standalone
Quando você quiser seus próprios níveis de modelo, execute o servidor diretamente. Instale-o e depois escreva um routes.toml:
cargo install --locked switchyard-serverschema_version = 1
[llm_clients.openrouter]
format = "openai_chat"
base_url = "https://openrouter.ai/api/v1"
api_key_env = "OPENROUTER_API_KEY"
[targets.weak]
id = "openai/gpt-4o-mini"
llm_client = "openrouter"
[targets.strong]
id = "openai/gpt-4o"
llm_client = "openrouter"
[routes.smart]
id = "switchyard"
type = "llm_classifier"
mode = "capability"
classifier_target = "weak"
strong_target = "strong"
weak_target = "weak"
base_threshold = 0.5Isso declara dois targets e uma rota: um modelo classificador decide, requisição por requisição, se o modelo fraco ou o forte deve responder. Segredos ficam em variáveis de ambiente via api_key_env — nunca no TOML. Valide e inicie:
export OPENROUTER_API_KEY="your-key"
switchyard-server --config routes.toml --dry-run
switchyard-server --config routes.toml --host 127.0.0.1 --port 4000Qualquer cliente que fale OpenAI Chat, Anthropic Messages ou OpenAI Responses pode se conectar. O id da rota é o nome do modelo que os clientes usam:
curl http://localhost:4000/health
curl http://localhost:4000/v1/chat/completions \
-H "Content-Type: application/json" \
-d '{"model":"switchyard","messages":[{"role":"user","content":"hello"}]}'Qual algoritmo de roteamento?
| Estratégia | Use quando |
|---|---|
random | Você precisa de uma divisão ponderada fixa para testes A/B ou linhas de base de custo. |
llm_classifier | O conteúdo da requisição deve decidir entre o nível fraco e o forte. |
llm_classifier + mode = "escalation" | Cada turno roda primeiro no nível fraco; um avaliador reexecuta a mesma requisição no nível forte apenas quando a resposta for fraca. |
stage_router | Sinais já presentes na conversa (resultados de ferramentas, erros) devem rotear a maioria dos turnos sem uma chamada extra de modelo. |
Para loops de agentes, o stage_router é o mais interessante: a maioria dos passos é “a ferramenta funcionou? continue” — decisões baratas que não precisam de um modelo de fronteira.
Não é teoria — os números
- LangChain: em 145 tarefas multi-turno com DeepAgents, apenas 7% das chamadas foram para modelos de fronteira → redução de custo de 74% com um custo de precisão de 6%.
- Ramp: paridade com modelos de fronteira no RampSWE-Bench, com custo 58% menor e 33% menos tempo de execução.
- Cognition: a integração com o DevinDesktop relata custo médio ~28% menor do que rodar um único modelo de fronteira.
- Boomi: 100% de precisão no roteamento de domínio, enviando 59% do tráfego para um modelo fine-tuned 5× mais rápido, com latência 21% menor nos turnos seguintes.
A Kong também integrou o Switchyard ao seu AI Gateway, de modo que o roteamento pode viver na sua camada de gateway em vez de dentro do agente.
Dicas práticas
- Rode
--dry-runantes de iniciar: ele valida o schema, as consultas de variáveis de ambiente e a construção das rotas sem ocupar uma porta. - A telemetria é um único header
X-Switchyard-Versionnas chamadas de saída (sem conteúdo). Para desativar, useexport SWITCHYARD_TELEMETRY_OPT_OUT=1. - O Switchyard está em pré-alpha — a API vai mudar antes da v1.0. Fixe versões para qualquer uso sério.
- Incorpore o roteamento no seu próprio serviço Rust com o
switchyard-libsy: os algoritmos apenas tomam decisões e devolvem as chamadas de modelo para você, então ele se encaixa num gateway existente sem precisar de uma stack HTTP própria. - Quer um nível barato self-hosted? Combine-o com o Nemotron 3.5 Lightning — 30B no total / 3B ativos, contexto de 1M, roda em um único DGX Spark (GB10) ou H100, com checkpoints NVFP4 e BF16 sob a licença permissiva OpenMDW-1.1.
Recursos
- GitHub: github.com/NVIDIA-NeMo/Switchyard
- Como começar: docs/getting_started.md
- Blog da NVIDIA: Route AI Agent Workloads Across Models with NVIDIA NeMo Switchyard
- Nemotron 3.5 Lightning: huggingface.co/nvidia/NVIDIA-Nemotron-3.5-Lightning-30B-A3B-NVFP4
