A maior parte do tráfego de LLM em produção não é difícil. É classificação, extração, reescritas curtas e roteamento, o tipo de trabalho que um modelo pequeno e rápido faz corretamente e por barato. Ainda assim, o padrão comum é conectar toda chamada ao maior modelo disponível, porque "simplesmente funciona", e depois se perguntar por que a conta e a latência estão altas. No Amazon Bedrock, o Claude Haiku 4.5 e o Claude Opus 4.5 estão ambos disponíveis, e a vitória de engenharia não é escolher um, é rotear por classe de tarefa para que o modelo barato cuide da maioria e o caro seja um caminho de escalonamento, não um default.

O reenquadramento: escolha de modelo é uma decisão por tarefa, não uma decisão para o projeto inteiro. Dimensionar toda requisição para a sua requisição mais difícil é o mesmo erro que rodar toda carga de trabalho no seu maior tipo de instância. Right-sizing significa casar o modelo com a dificuldade da chamada específica, e para uma grande fatia das chamadas o tamanho certo é pequeno.

Por que o modelo grande é o default errado

Usar o modelo de fronteira como default parece seguro e é caro em duas dimensões. Modelos classe Opus custam várias vezes mais por token do que os classe Haiku, então uma carga de trabalho que é 90 por cento mecânica está pagando preços de fronteira por um trabalho que um modelo pequeno faz perfeitamente. Eles também são mais lentos, porque modelos mais capazes geralmente demoram mais para responder, então você infla a latência exatamente nas chamadas simples de alto volume onde os usuários mais notam a velocidade.

O custo escondido é que um modelo grande em uma tarefa simples raramente produz um resultado melhor. Extrair uma data de um email ou classificar um ticket em um de seis grupos não melhora quando você joga mais capacidade nele. Você paga mais e espera mais por uma resposta que um modelo menor teria acertado.

Roteie por classe de tarefa

O design que funciona é classificar a requisição por dificuldade e enviá-la ao modelo que se encaixa. Não por usuário, não por feature, por classe de tarefa:

  • Trabalho mecânico vai para o Haiku. Classificação, extração, conversão de formato, resumos curtos, construção de argumentos de ferramentas e decisões de roteamento. Alto volume, baixa ambiguidade, e um modelo pequeno é mais barato e mais rápido sem perda de qualidade.
  • Trabalho de julgamento vai para o Opus. Raciocínio em múltiplos passos, instruções ambíguas, síntese de contexto longo, e qualquer coisa em que uma resposta errada é cara. Volume mais baixo, e vale o prêmio porque a capacidade realmente muda o resultado.
  • O roteador em si é barato. Uma heurística sobre comprimento de entrada e tipo de tarefa, ou uma única chamada de modelo pequeno, decide a classe. O custo do roteamento é um erro de arredondamento diante do que você economiza ao não usar o topo como default para tudo.

Modelo grande como caminho de escalonamento

O padrão mais confiável é tornar o modelo de fronteira um escalonamento, não uma porta de entrada. Tente o modelo pequeno primeiro. Se ele tiver sucesso, e para a maioria mecânica ele vai, você termina a uma fração do custo e da latência. Se ele falhar em uma checagem, baixa confiança, uma saída inválida contra o schema, um "não tenho certeza" explícito, escale essa requisição individual para o modelo maior.

result = invoke(HAIKU, task)
if not passes_check(result):
    result = invoke(OPUS, task)   # escalate only the hard cases
return result

Isso inverte a economia. Em vez de pagar preços de Opus em toda requisição para cobrir a rara requisição difícil, você paga preços de Haiku no caso comum e só recorre ao Opus quando a tentativa barata visivelmente ficou aquém. A troca é uma chamada extra na minoria de requisições que precisam dela, contra uma grande economia na maioria que não precisa.

Meça antes de assumir a divisão

O lugar onde os times erram é chutar a mistura de tarefas em vez de medi-la. Antes de rotear, amostre tráfego real e rotule quanto dele é genuinamente mecânico versus genuinamente difícil. O número é quase sempre mais mecânico do que o time espera, e é exatamente por isso que usar o modelo grande como default desperdiça tanto. Isso também te diz onde ajustar o gatilho de escalonamento: se o modelo pequeno cuida de 92 por cento do tráfego de forma limpa, sua taxa de escalonamento deveria ficar perto de 8 por cento, e uma taxa muito mais alta significa que sua checagem está rígida demais ou seu roteamento está mal calibrado.

A conclusão

Tanto o Haiku quanto o Opus estão no Bedrock há meses, e o ponto não é escolher entre eles, é usar cada um onde ele se encaixa. Roteie por classe de tarefa: envie a maioria mecânica para o modelo pequeno e rápido e reserve o modelo de fronteira para a minoria que exige julgamento, idealmente como um caminho de escalonamento acionado por uma checagem falha em vez de um default. Meça sua mistura de tarefas real antes de ajustar a divisão. Right-sizing de modelo é a mesma disciplina que right-sizing de instância, e o sistema mais rápido e barato é aquele que para de pagar preços de fronteira por um trabalho que um modelo pequeno faz corretamente.

Leia isso a seguir

Para o lado de plataforma de roteamento e capacidade entre modelos, as notas de campo de cloud estão em ercan.cloud, e o hub fica em ercanermis.com.