Comment choisir le bon tier de modèle en fonction des compromis entre coût et latence ?

Question

Accepted Answer

Les modèles au sein d'une famille échangent capacité contre coût et latence : les modèles plus petits sont plus rapides et moins chers mais moins capables ; les plus grands raisonnent mieux sur les problèmes difficiles mais coûtent plus cher et répondent plus lentement. L'habileté consiste à adapter le modèle à la difficulté de la tâche, et non à toujours choisir le plus grand.

Les tiers (la gamme d'Anthropic)

En utilisant la famille Claude d'Anthropic comme exemple (dernière génération : , , ) :

## Les tiers (la gamme d'Anthropic)

En utilisant la famille Claude d'Anthropic comme exemple (dernière génération : **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
```

L'ordre est relatif : **Haiku < Sonnet < Opus** en prix et latence, et le même ordre en capacité brute.

## Comment choisir

- **Commencez moins cher.** Optez d'abord pour Haiku ou Sonnet ; la plupart des tâches ne nécessitent pas le tier supérieur.
- **Escaladez uniquement si la qualité l'exige.** Si la sortie d'un modèle moins cher est erronée, superficielle, ou manque constamment l'objectif sur un problème véritablement difficile, montez à Opus.
- **Pensez au volume.** Une tâche que vous exécutez des millions de fois (étiquetage, routage) devrait être sur Haiku même si Opus est légèrement meilleur — le coût et la latence se multiplient.

```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)
```

## Pourquoi c'est important

Par défaut, utiliser le plus grand modèle gaspille de l'argent et ajoute de la latence sur des tâches qu'un tier moins cher gère bien ; par défaut, utiliser le plus petit donne de mauvais résultats sur un travail véritablement difficile. Choisir délibérément — commencer moins cher, escalader uniquement si la qualité l'exige — maintient les systèmes rapides et abordables à grande échelle tout en apportant le modèle puissant aux problèmes qui en ont réellement besoin.