Por que seu melhor modelo são dois modelos: roteando entre Kimi K3 e Claude

Por que isso importa agora

Um desenvolvedor abriu a fatura de inferência no mês passado e não conseguiu explicar por que corrigir um erro de digitação em um arquivo de configuração custou quase o mesmo que a feature que levou a tarde inteira para construir. As duas requisições passaram pelo mesmo agente de código e pelo mesmo modelo. Essa é a lógica de quem configura um sistema com um modelo, uma chave de API, um preço por token — não importa se a tarefa é trivial ou genuinamente difícil.

Ninguém decide isso de propósito. Acontece porque escolher um modelo só é fácil, e construir algo mais inteligente exige um trabalho que a maioria dos times adia. O resultado: consultas rápidas e resumos curtos pagando preço de modelo de fronteira por tarefas que um modelo barato resolveria igual. Multiplique por um agente fazendo centenas de chamadas de ferramenta — ou uma dúzia de agentes rodando ao mesmo tempo — e o desperdício empilha rápido.

O lançamento do Kimi K3 (Moonshot AI, julho de 2026) tornou esse dilema concreto. Um modelo aberto de 2,8 trilhões de parâmetros que compete com os melhores em tarefas de código e agênticas, mas custa bem menos para servir. Colocá-lo ao lado do Claude não é rivalidade: é parceria. E é nesse vão de preço e especialidade que o roteamento de modelos passa a valer a pena.

✅ O que você ganha

• Redução de custo: tarefas leves deixam de pagar preço de fronteira; a economia aparece direto na fatura.
• Modelo certo para cada tarefa: profundidade quando precisa, volume barato quando não.
• Desacoplamento da aplicação: trocar ou adicionar modelos vira mudança de configuração, não de código.
• Decisão em ~200 ms: um roteador especializado decide mais rápido (e mais barato) do que um LLM de propósito geral classificando cada chamada.
• Visibilidade: você vê para onde o tráfego está indo e corrige descrições de tarefa, em vez de adivinhar.

⚠️ O que você NÃO ganha

• Mágica: se as descrições de tarefa forem ruins, o roteador manda trabalho para o lugar errado.
• Gratuidade: existe custo de configuração, aprendizado e manutenção das políticas.
• Independência do fornecedor: o exemplo usa o Inference Router da DigitalOcean; rotear fora dela exige outra solução.

Requisitos

Por que o roteamento “na mão” quebra

A solução óbvia é construir a lógica você mesmo: um if/else no tamanho do prompt, uma checagem de palavra-chave, ou um chamado a um LLM que decide para onde mandar a requisição. É nessa última opção que a maioria dos times trava.

Se você usa um modelo pequeno (como o Haiku) para classificar cada requisição antes de encaminhar, agora paga duas chamadas em vez de uma, em toda requisição, para sempre. E um modelo de propósito geral fazendo classificação “de bico” não é bom nisso: fica menos preciso conforme o tráfego muda, e quem precisa notar e corrigir é você. Você acabou de construir uma segunda aplicação cujo único trabalho é decidir qual modelo cuida da primeira.

O que se sustenta é o roteamento na camada de infraestrutura: algo que lê a requisição, decide qual modelo ela precisa e envia — sem que o código da sua aplicação precise saber ou se importar.

Dois modelos, dois trabalhos

Claude é um modelo fechado. A Anthropic constrói, serve e ajusta de ponta a ponta, e você paga por isso: comportamento estável, raciocínio forte e uso de ferramentas confiável em tarefas longas e complicadas.

Kimi K3 é outro tipo de ferramenta. É aberto, com 2,78 trilhões de parâmetros totais, 896 especialistas roteados, uma mistura de Kimi Delta Attention e Gated Multi-head Latent Attention, e janela de contexto de até 1 milhão de tokens com suporte nativo a visão. A Moonshot o construiu para rodar por horas: codificação autônoma, pesquisa em múltiplas etapas e trabalho agêntico que sobrevive a centenas de chamadas de ferramenta sem perder o fio da meada.

Como funciona um roteador de inferência

O roteador fica na frente do catálogo de modelos e envia cada requisição para o modelo de melhor ajuste dentro de um pool que você define, com base em custo, latência ou qualquer política configurada. A mudança no código é mínima: em vez de nomear um modelo, você nomeia um roteador (prefixo router:) e o roteador escolhe por você.

O detalhe importante: a decisão de para onde vai a requisição não passa por um LLM de propósito geral. Passa por um modelo treinado especificamente para rotear — no caso da DigitalOcean, o Plano-Orchestrator, com versões de 4B e 30B parâmetros. Nos testes da empresa com quase 2.000 mensagens e 605 conversas, a versão 30B alcançou 87,84% de precisão média, à frente do GPT-5.1 (86,93%) e do Claude Sonnet 4.5 (86,11%), decidindo em cerca de 200 milissegundos. Você não paga preço de fronteira só para descobrir qual modelo deveria responder.

Passo a passo: montando um roteador Kimi K3 + Claude

1. Defina as tarefas

Um roteador é feito de tarefas. Cada tarefa tem um nome, uma descrição em linguagem natural que o modelo de roteamento compara com a conversa, um pool de modelos permitidos e uma política (cheapest, fastest ou uma ordem fixa). O que não casar com nenhuma tarefa cai nos modelos de fallback, tentados em ordem — assim nenhuma requisição fica presa.

curl -X POST "https://api.digitalocean.com/v2/gen-ai/models/routers" \
  -H "Authorization: Bearer $DIGITALOCEAN_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "kimi-claude-router",
    "description": "Roteia consultas rápidas e trabalho agêntico longo entre Kimi K3 e Claude",
    "policies": [
      {
        "custom_task": {
          "name": "quick_turnaround",
          "description": "Perguntas curtas, resumos, consultas rápidas ou respostas de etapa única"
        },
        "models": ["kimi-k3", "anthropic-claude-sonnet-4.6"],
        "selection_policy": { "prefer": "cheapest" }
      },
      {
        "custom_task": {
          "name": "agentic_coding",
          "description": "Tarefas de código em múltiplas etapas, uso longo de ferramentas ou análise profunda de codebase"
        },
        "models": ["anthropic-claude-opus-4.6", "kimi-k3"],
        "selection_policy": { "prefer": "fastest" }
      }
    ],
    "fallback_models": ["kimi-k3"]
  }'

O nome e a descrição da tarefa não são rótulos decorativos — são o que o modelo de roteamento lê para decidir onde a requisição pertence. Escreva uma descrição ampla demais (“cuide de código”) e ela captura tudo; estreita demais, e perde requisições que deveria pegar.

2. Use o roteador na chamada

Depois que o roteador existe, usá-lo é uma mudança de uma linha em qualquer chamada que você já faz:

curl https://inference.do-ai.run/v1/chat/completions \
  -H "Authorization: Bearer $MODEL_ACCESS_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "router:kimi-claude-router",
    "messages": [
      {"role": "user", "content": "O que significa KeyError em Python?"}
    ]
  }'

A pergunta é curta e de etapa única, então cai em quick_turnaround e vai para o mais barato entre Kimi K3 e Claude Sonnet naquele momento — o custo é checado ao vivo, não fixado uma vez. A resposta informa o que aconteceu: o campo model mostra qual modelo respondeu, e o header x-model-router-selected-route mostra qual tarefa casou.

3. Mantenha a afinidade de sessão

Em sessões de agente com múltiplos turnos, você normalmente quer o mesmo modelo cuidando da tarefa do início ao fim. Provedores como a Anthropic fazem cache das partes anteriores da conversa, mas esse cache está vinculado ao modelo que o construiu. Trocar de modelo no meio da conversa joga o cache fora. Um header estável de afinidade (como X-Model-Affinity, com um ID de sessão ou tarefa que sua aplicação já rastreia) mantém o trabalho em um modelo só. Se você ainda quiser permitir troca no meio quando os números claramente favorecerem, o header X-Routing-Max-Switch-Spend-Pct limita quanto o roteador pode gastar a mais para fazer essa troca — por padrão, 20% acima do custo de ficar onde está.

Verificando se está funcionando de verdade

Antes de confiar em produção, compare o roteador contra um modelo único nos mesmos prompts (custo e latência lado a lado). Depois, rode avaliações contra um dataset rotulado para obter pontuações de corretude e completude — para saber se o roteamento segura a qualidade antes de entrar no ar, não depois. Com o roteador no ar, um painel mostra o que realmente acontece: com que frequência as requisições casam com uma tarefa versus caem no fallback, como o tráfego se divide entre Kimi K3 e Claude, e a latência por modelo e tarefa.

Se as requisições de agentic_coding insistirem em cair no Claude 90% do tempo mesmo com o Kimi K3 no pool, você verá isso no gráfico de distribuição. Em geral, é sinal de que a descrição da tarefa precisa de ajuste — não de que o Kimi K3 não dá conta.

Deixe rodar uma ou duas semanas antes de declarar vitória. Preço e latência se movem: o tempo de resposta de um provedor pode dobrar ou triplicar em um único dia. É por isso que o roteador consulta dados ao vivo em vez de seguir uma regra fixada uma vez.

Casos de uso reais

• Suporte ao cliente: perguntas de FAQ vão para o modelo barato; casos complexos que exigem raciocínio vão para o modelo de fronteira.
• Agentes de código: tarefas de lint e refatoração simples no modelo aberto; design de arquitetura e bugs difíceis no modelo fechado.
• Classificação e extração em lote: milhares de documentos processados pelo modelo barato sem degradar a qualidade.
• Assistentes internos de empresa: buscas simples no modelo rápido; relatórios e análises no modelo forte.

Comparação de custo (referência)

Troubleshooting

• ❌ Tráfego caindo 90% em um modelo só → Descrição da tarefa ampla ou vaga demais; refine a descrição para distinguir as tarefas.
• ❌ Taxa de fallback subindo → Nenhuma tarefa casando; revise nomes/descrições ou o pool de modelos.
• ❌ Custo não caiu → Verifique se a política cheapest está realmente aplicada e se o modelo barato está no pool.
• ❌ Latência piorou → Cache de conversa perdido por troca de modelo no meio da sessão; adicione header de afinidade.
• ❌ Qualidade caiu em tarefas críticas → Rode avaliações contra dataset rotulado antes de liberar; ajuste a divisão de tarefas.

FAQ

• Preciso usar a DigitalOcean? Não. O padrão (rotear entre um modelo aberto barato e um fechado caro) é agnóstico de fornecedor; dá para replicar com proxies abertos como Plano ou LiteLLM.
• Um roteador substitui o LLM principal? Não. Ele só decide para onde encaminhar; quem responde continua sendo o modelo escolhido.
• Quantos modelos posso colocar no pool? Vários, mas cada tarefa declara o subconjunto permitido e a política de seleção.
• Como sei que está funcionando? Veja o campo model da resposta e o header de rota selecionada, além do painel de distribuição.
• Vale para times pequenos? Sim — é especialmente útil para quem não tem equipe de dados dedicada para otimizar custos manualmente.

O que vem por aí

O roteamento de modelos segue o mesmo caminho de outras camadas de infraestrutura: sair do código da aplicação e virar serviço. À medida que mais modelos abertos competitivos chegam ao mercado e a diferença de preço entre aberto e fechado se mantém, a pergunta deixa de ser “qual modelo é melhor” e passa a ser “por que escolher um só?”. A configuração do roteador vira o novo ponto de ajuste — e o time que domina isso compra desempenho de fronteira só onde ele paga a própria conta.