Como você escolhe o nível de modelo certo dados os compromissos de custo e latência?

Question

Accepted Answer

Modelos dentro de uma família trocam **capacidade contra custo e latência**: modelos menores são mais rápidos e mais baratos, mas menos capazes; modelos maiores raciocinam melhor em problemas difíceis, mas custam mais e respondem mais lentamente. A habilidade é alinhar o modelo com a dificuldade da tarefa, não sempre optar pelo maior.

## Os níveis (Portfólio do Anthropic)

Usando a família Claude do Anthropic como exemplo (geração mais recente: **Opus 4.8**, **Sonnet 4.6**, **Haiku 4.5**):

```text
Haiku   → smallest, fastest, cheapest
          → high-volume / simple tasks: classification, extraction, quick edits
Sonnet  → balanced cost/quality
          → everyday coding and general work (the sensible default)
Opus    → most capable, highest cost & latency
          → hardest multi-step reasoning, architecture, tricky debugging
```

A ordem é relativa: **Haiku < Sonnet < Opus** tanto em preço quanto em latência, e a mesma ordem em capacidade bruta.

## Como escolher

- **Comece com algo mais barato.** Opte por Haiku ou Sonnet primeiro; a maioria das tarefas não precisa do nível superior.
- **Escale apenas quando a qualidade exigir.** Se a saída de um modelo mais barato é errada, superficial ou continua perdendo o objetivo em um problema genuinamente difícil, mude para Opus.
- **Pense sobre volume.** Uma tarefa que você executa milhões de vezes (tagação, roteamento) deve estar em Haiku, mesmo que Opus seja um pouco melhor — o custo e a latência se multiplicam.

```text
Classify 1M support tickets   → Haiku   (volume dominates; task is simple)
Implement a feature           → Sonnet  (balanced everyday coding)
Debug a subtle race condition → Opus    (hard reasoning justifies the cost)
```

## Por que isso importa

Optar por padrão pelo modelo maior desperdiça dinheiro e adiciona latência em tarefas que um nível mais barato gerencia bem; optar por padrão pelo menor produz resultados ruins em trabalho genuinamente difícil. Escolher deliberadamente — comece mais barato, escale apenas quando a qualidade exigir — mantém os sistemas rápidos e acessíveis em escala enquanto ainda leva o modelo pesado para os problemas que realmente o precisam.