Sixième article de la série « Production Engineering, Evals & Security avec Claude ».
Choisir un modèle Claude en production n’est pas seulement une décision technique. C’est un arbitrage entre qualité, coût et latence.
Le document Production Engineering, Evals & Security présente le choix du modèle comme un levier fondamental : le coût et la latence d’un système dépendent d’abord du modèle choisi, avant même les optimisations de prompt, de cache ou d’architecture.
Le principe : choisir le modèle le moins coûteux qui atteint la qualité attendue
Le bon raisonnement n’est pas :
prendre le modèle le plus puissantmais plutôt :
prendre le modèle le moins coûteux
qui atteint le quality bar défini par les evalsC’est une différence importante.
Un modèle plus performant peut être justifié si :
- la tâche est complexe ;
- le coût d’une erreur est élevé ;
- les evals montrent qu’un modèle plus petit échoue sur des cas critiques.
Mais si un modèle plus rapide et moins coûteux atteint déjà la qualité requise, utiliser un modèle supérieur n’apporte pas forcément de valeur.
Les trois tiers présentés dans le module
Le document raisonne principalement avec :
Haiku
Sonnet
Opuset décrit leurs rôles relatifs ainsi.
| Modèle | Positionnement |
|---|---|
| Haiku | Vitesse et coût |
| Sonnet | Équilibre qualité / coût / latence |
| Opus | Tâches exigeantes nécessitant davantage de capacité |
Le document mentionne également un tier nommé Fable, décrit comme le plus capable pour les tâches les plus exigeantes, mais les exercices du module se concentrent ensuite surtout sur Haiku, Sonnet et Opus. Je conserve ici la structure du document source sans extrapoler au-delà.
Sonnet comme point de départ
Le module propose un principe pratique :
start with Sonnetpuis :
evalSi Sonnet atteint la qualité attendue :
keep SonnetSi Sonnet échoue sur les cas les plus difficiles :
consider OpusSi une tâche simple peut être correctement réalisée par Haiku :
consider HaikuLe choix doit donc être piloté par les evals, pas par intuition.
Monter de tier : quand passer à Opus ?
Le document recommande de monter de tier lorsque :
current model
↓
fails eval
↓
on hardest caseset que le coût d’une erreur est significatif.
Exemple :
multi-step agent
→ dépendances entre étapes
→ erreur initiale coûteuseSi les evals montrent que Sonnet échoue sur les cas difficiles :
Opusdevient le meilleur choix.
La contrainte qui décide ici n’est pas simplement :
latencyou :
costmais :
quality on hard reasoning
+
high downstream cost of mistakesDescendre de tier : quand choisir Haiku ?
Haiku devient pertinent lorsque :
high volume
+
simple task
+
eval confirms qualityLe document donne comme scénario une classification de millions de messages courts.
Si les evals montrent que Haiku tient le niveau de qualité attendu :
Haikuest le bon choix.
La contrainte dominante devient :
cost-at-volumeExemple : classification à très grande échelle
Supposons :
10 millions de messages / jourTâche :
classify:
billing
technical
salesSi :
Haiku eval score = acceptablealors utiliser Opus serait probablement inutile.
Le surcoût serait multiplié par le volume.
Le document place donc clairement Haiku comme choix naturel lorsque :
quality bar holds
+
volume is highLe coût d’une erreur fait partie du calcul
Le document rappelle qu’une économie sur le coût API peut être une fausse économie.
Exemple :
small model
→ économise 20 %mais :
error rate
→ augmenteet les erreurs déclenchent :
support
manual correction
wrong actions
customer impactAlors le coût réel peut devenir supérieur.
Le choix du modèle doit donc intégrer :
API cost
+
latency
+
quality
+
cost of mistakesUn modèle plus puissant peut parfois être plus économique
Le document nuance aussi une idée fréquente :
Un modèle plus cher par token n’est pas toujours plus cher par tâche.
Pourquoi ?
Parce qu’un modèle plus performant peut :
reason faster
need fewer tokens
require fewer retries
make fewer tool callsUne tâche peut donc parfois coûter moins cher globalement avec un modèle supérieur s’il atteint rapidement une bonne solution.
Il faut mesurer :
cost per successful tasket pas seulement :
price per tokenRouting : ne pas utiliser le même modèle pour toutes les requêtes
Un système peut utiliser plusieurs modèles.
Architecture :
Incoming request
↓
Router
↓
┌────┴───────┐
↓ ↓
simple complex
↓ ↓
Haiku Opus
or SonnetLe document décrit cela comme :
un modèle par défaut + un override basé sur un signal de tâche.
Quels signaux utiliser pour le routing ?
Le module cite notamment :
task type
input length
difficulty classificationPar exemple :
def route(request):
difficulty = classify(request)
if difficulty == "complex":
return call_opus(request)
return call_sonnet(request)L’idée est de réserver le modèle le plus coûteux aux cas qui en ont besoin.
Exemple : trafic mixte
Supposons :
80 % = simple lookup
20 % = complex synthesisUne architecture naïve :
Opus for everythinggarantit un coût élevé.
Une autre :
Haiku for everythingrisque de perdre trop de qualité sur les tâches difficiles.
La solution proposée par le module est :
default:
Sonnet or Haiku
override:
Opus for complex requestsavec les evals pour valider le seuil de routing.
Quand ne pas utiliser de routeur ?
Le routing ajoute lui-même :
- une classification ;
- une branche supplémentaire ;
- un modèle supplémentaire à maintenir ;
- des tests supplémentaires ;
- une nouvelle source potentielle d’erreurs.
Si tout le trafic est homogène :
same task
same difficulty
same quality barle document recommande :
pin one modelet éviter le routeur.
La décision doit toujours passer par les evals
Le pattern général devient :
candidate model
↓
run eval
↓
quality >= threshold?
┌────┴────┐
│ │
No Yes
│ │
↓ ↓
step up consider cost/latencyEt dans l’autre sens :
cheaper model
↓
run eval
↓
quality still acceptable?
┌────┴────┐
│ │
No Yes
│ │
keep downgrade
currentLe choix du modèle est donc une décision expérimentale.
Comparer les modèles sur le même dataset
Il faut garder :
same eval dataset
same prompt
same tools
same expected behaviorpuis modifier uniquement :
modelExemple :
| Model | Eval score | Latency | Cost |
|---|---|---|---|
| Haiku | 8.1 | faible | faible |
| Sonnet | 9.2 | moyen | moyen |
| Opus | 9.5 | élevé | élevé |
Supposons :
quality bar = 9.0Le meilleur choix est :
SonnetOpus est meilleur, mais cette amélioration ne justifie peut-être pas son coût.
Haiku est moins cher mais échoue au seuil.
Le quality bar doit être défini avant
Encore une fois, le design document joue un rôle.
Avant de choisir le modèle, il faut définir :
minimum quality score
latency target
cost ceilingSinon l’équipe risque de rationaliser le choix après coup.
Exemple :
Eval score >= 9
Latency < 2 s
Cost/request < XLe modèle choisi doit respecter les trois contraintes.
Exemple de décision
Supposons :
Haiku
quality = 8.4
latency = 400 ms
cost = lowSonnet
quality = 9.2
latency = 800 ms
cost = mediumOpus
quality = 9.4
latency = 1.8 s
cost = highRequirements :
quality >= 9
latency < 1 sRésultat :
SonnetC’est le seul modèle qui respecte les deux contraintes.
Ne pas optimiser une seule métrique
Le mauvais raisonnement :
cheapest model winsou :
best quality winsou :
fastest winsLe bon raisonnement :
quality
cost
latency
reliabilitydoivent être considérés ensemble.
Model routing et reliability
Un routeur est lui-même un composant.
Il doit donc être testé.
Exemples :
simple lookup
→ small/default model
complex synthesis
→ stronger modelIl faut créer des eval cases où le routing correct est connu.
Sinon le système peut parfaitement avoir deux bons modèles mais les utiliser au mauvais moment.
Exemple de tests de routing
def test_simple_lookup_routes_to_default():
assert route("What is the refund deadline?") == "default"
def test_complex_synthesis_routes_to_opus():
assert route(
"Compare five policies and derive a recommendation."
) == "opus"Puis un E2E peut vérifier que le résultat final satisfait toujours l’eval.
Le modèle n’est qu’un levier parmi plusieurs
Une baisse de qualité ne signifie pas toujours :
need bigger modelLe problème peut venir de :
bad prompt
missing context
poor retrieval
tool errors
wrong architectureAvant de monter de tier, il faut lire les résultats de l’eval.
Exemple :
failure only on retrieved factspeut indiquer :
retrieval problemet non un problème de capacité du modèle.
C’est pourquoi :
eval
+
tracesont importants avant toute modification de modèle.
Le piège du « plus gros modèle par défaut »
Le document décrit ce choix comme une erreur de production fréquente et coûteuse.
Pourquoi ?
Parce qu’on paye :
premium capabilitysur toutes les requêtes, même celles qui n’en ont pas besoin.
Exemple :
simple classification
→ Opusest rarement une bonne architecture si Haiku tient parfaitement l’eval.
Le piège inverse : réduire les coûts sans mesurer
Supposons :
Sonnet
→ Haikusimplement pour économiser.
Si aucune eval n’est exécutée, on ignore :
quality regressionLe coût baisse immédiatement.
Les erreurs peuvent apparaître progressivement en production.
Le document insiste donc sur le fait qu’une descente de tier doit elle aussi être validée par l’eval.
Architecture simple
Pour une tâche homogène :
User
↓
Sonnet
↓
AnswerC’est souvent préférable.
Architecture avec routing
Pour un trafic mixte :
Request
│
↓
cheap classifier
│
┌───────┴────────┐
│ │
simple complex
│ │
↓ ↓
Haiku/Sonnet Opus
│ │
└───────┬────────┘
↓
Output
Le routeur doit « gagner son coût ».
S’il n’évite jamais d’appels coûteux, il ne sert à rien.
Ce qu’il faut retenir pour la certification
Haiku
À privilégier lorsque :
high volume
+
speed/cost critical
+
eval proves qualitySonnet
Le document le présente comme le :
balanced defaultpour de nombreux workloads de production.
Opus
À choisir lorsque :
hard reasoning
+
current model misses eval bar
+
mistake cost is highRouting
Pertinent lorsque :
traffic is mixedPar exemple :
simple requests
+
few complex requestsAlors :
default cheaper model
+
Opus overridepeut être approprié.
Pas de routing si le trafic est uniforme
uniform workload
→ single pinned modelLa solution la plus simple est souvent préférable.
Pièges d’examen
Scénario : une classification traite des millions de messages et Haiku atteint le seuil des evals.
→ Haiku, car le coût à grande échelle est la contrainte dominante.
Scénario : un agent effectue une refactorisation complexe, les étapes sont dépendantes, et Sonnet échoue sur les cas les plus difficiles.
→ Opus, car la qualité sur le raisonnement difficile et le coût d’une erreur sont les contraintes principales.
Scénario : 90 % des requêtes sont simples et 10 % nécessitent une synthèse complexe.
→ Routing, avec un modèle par défaut moins coûteux et un modèle supérieur pour les cas difficiles.
Scénario : toutes les requêtes ont exactement la même difficulté.
→ Ne pas ajouter de routeur inutilement.
Scénario : vous voulez passer de Sonnet à Haiku pour économiser.
→ Exécuter les evals avant de promouvoir le changement.
Scénario : Haiku échoue uniquement lorsque le retrieval ne renvoie pas les bons documents.
→ Ne pas conclure immédiatement qu’il faut un modèle plus puissant ; diagnostiquer d’abord le retrieval.
À retenir en une phrase
Le bon modèle n’est ni le plus puissant ni le moins cher : c’est le modèle le moins coûteux qui satisfait le niveau de qualité, de latence et de fiabilité défini par les evals.
