D2 · Model Selection and Optimization

Ce domaine représente environ 9 items sur 53. Il vérifie que vous savez choisir le modèle le moins cher qui atteint le niveau de qualité, puis faire baisser coût et latence avec le caching, le batching, le routage et le contrôle de sortie – tout en épinglant les versions et en gérant les changements incompatibles entre versions. Attendez-vous à des scénarios de calcul de coût et à des questions d’arbitrage « quel modèle / quel levier ».

Objectifs d’apprentissage

À la fin de cette page, vous devriez être capable de :

1. Expliquer les fondamentaux des LLM : tokens, coût de tokenisation, fenêtre de contexte, échantillonnage et non-déterminisme.
2. Configurer les options de modèle : fast mode, thinking étendu/adaptatif, niveaux d’effort, et où budget_tokens s’applique encore.
3. Comparer les paliers de modèles (Haiku 4.5, Sonnet 5, Opus 5, Fable 5.1) sur la capacité, le prix et la latence, et effectuer des calculs de coût détaillés.
4. Identifier les changements incompatibles entre versions et planifier l’épinglage et la migration.
5. Appliquer les leviers de coût : budgétisation des tokens, prompt caching, batching, et routage/cascade.
6. Appliquer les leviers de latence : streaming, modèles plus petits, sortie plus courte, caching.

2.1 LLM fundamentals

• Les tokens sont des unités sous-lexicales ; la facturation et les limites sont en tokens, pas en caractères. Environ 1 token ≈ 4 caractères ≈ 0,75 mot en anglais.
• Coût de tokenisation : l’entrée comme la sortie sont mesurées en tokens ; des prompts et des sorties plus longs coûtent plus cher et ajoutent de la latence.
• La fenêtre de contexte est le total de tokens (entrée + sortie) que le modèle peut prendre en compte dans une requête – 1M sur Fable 5.1 / Opus 5 / Sonnet 5, 200k sur Haiku 4.5. max_tokens plafonne la sortie dans cette fenêtre.
• Échantillonnage : le modèle produit une distribution de probabilité ; temperature et top_p contrôlent la façon dont elle est échantillonnée. Plus bas = plus déterministe.
• Non-déterminisme : même à temperature: 0, les sorties ne sont pas garanties identiques octet par octet entre exécutions ou versions de modèle. Concevez en conséquence – validez la sortie, ne supposez pas de répétitions exactes.

2.2 Model options: thinking, effort and fast mode

• Utilisez l’effort xhigh uniquement pour les travaux de code/agentiques les plus ardus (Opus 5 / Fable 5.1) – il coûte plus de tokens de thinking et ajoute de la latence.
• budget_tokens renvoie 400 sur Fable 5.x / Opus 5 / Sonnet 5. Seul Haiku 4.5 l’accepte encore, et Haiku n’a aucun paramètre effort.
• Fable 5.1 raisonne toujours ; vous ne pouvez pas le désactiver.

2.3 Model tiers, pricing and trade-offs

Règle générale : commencez à Sonnet 5 ; descendez à Haiku 4.5 pour le travail simple à fort volume ; passez à Opus 5 pour les tâches de code/agentiques difficiles ; réservez Fable 5.1 au raisonnement le plus exigeant (en acceptant ses contraintes et sa rétention de 30 jours).

Worked cost calculation

Une tâche envoie 3 000 tokens d’entrée et génère 500 tokens de sortie, 20 000 fois/jour.

Si Haiku 4.5 atteint la qualité, il est 5× moins cher qu’Opus 5 ici. Ne prenez jamais par défaut le modèle le plus capable pour un travail simple à fort volume.

2.4 Breaking changes across releases

2.5 Pinning and migration

• Épinglez un snapshot en production pour que le comportement ne change pas sous vos pieds. Les ID de modèle à partir de 4.6 sont sans date mais restent des snapshots épinglés.
• Stockez l’ID de modèle en un seul endroit piloté par env pour qu’une migration soit un changement unique.
• Checklist de migration : relancez le jeu d’éval de référence sur le nouveau modèle ; vérifiez les paramètres retirés (budget_tokens), le comportement modifié de tool_choice, les écarts de latence et de coût ; déployez derrière un flag.
• Utilisez client.models.list() / .retrieve(id) pour les limites et la disponibilité en direct.

import os
MODEL = os.environ.get("CLAUDE_MODEL", "claude-sonnet-5")   # épinglé, un seul endroit

2.6 Token budgeting

Contrôlez les tokens des deux côtés :

• Entrée : élaguez le contexte, mettez en cache les préfixes stables, purgez les anciens résultats d’outils, résumez les historiques longs.
• Sortie : réglez un max_tokens réaliste, demandez une sortie concise/structurée, arrêtez tôt avec stop_sequences.
• Thinking : adaptatif par défaut ; utilisez les niveaux d’effort plutôt que de payer xhigh partout.

Chaque token dans la fenêtre de contexte est facturé à chaque tour, donc les longues conversations deviennent coûteuses – budgétez avec caching, édition et compaction (Domaine 4).

2.7 Cost levers: caching, batching, routing

Request ─► Haiku 4.5 (cheap, fast)
             │
             ├─ confident / simple ─► return
             └─ hard / low-confidence ─► Sonnet 5 ─► (rare) Opus 5

2.8 Latency levers

2.9 Worked cost comparison: a 10k-document job

Considérez un job d’extraction par batch sur 10 000 documents. Chaque requête envoie un préfixe partagé de 2 000 tokens (system + schéma + instructions) plus 1 000 tokens de texte de document unique (3 000 tokens d’entrée au total) et génère 500 tokens de sortie. Voici l’arithmétique pour chaque palier, d’abord synchrone et sans cache, puis avec caching, puis via la Batches API.

Baseline (synchronous, no caching)

Coût par requête = (tokens d’entrée × prix d’entrée + tokens de sortie × prix de sortie) ÷ 1 000 000, multiplié par 10 000 documents.

With prompt caching on the 2,000-token shared prefix

Le préfixe de 2 000 tokens est écrit en cache une fois (≈1,25× le prix d’entrée de base pour le TTL de 5 minutes) et lu à ≈0,1× ensuite. Les 1 000 tokens uniques par document ne sont jamais mis en cache. Pour Sonnet 5 :

• Écriture de cache (première requête) : 2 000 × $2 × 1.25 / 1e6 = $0.005 (une fois, négligeable).
• Lectures de cache du préfixe (9 999 requêtes restantes) : ≈2 000 × 10k × $2 × 0.1 / 1e6 = $4 (contre $40 sans cache pour la portion du préfixe).
• Entrée unique (jamais mise en cache) : 1 000 × 10k × $2 / 1e6 = $20.
• Sortie inchangée : $50.
• Sonnet 5 avec caching ≈ $74 contre $110 — le préfixe partagé passe de $40 à environ $4.

With the Message Batches API (50% off input and output)

Le batching divise par deux chaque ligne ci-dessus et renvoie les résultats en 24 heures — idéal car ce job est tolérant à la latence.

2.10 Latency levers in depth

La latence totale a deux parties visibles : le time-to-first-token (TTFT) et le temps de génération total. Différents leviers déplacent différentes parties. Les confondre est un piège d’examen classique.

Request ──► [cache read prefix] ──► [thinking effort] ──► [generate output]
   │              (caching)            (effort/fast)         (max_tokens)
   └── stream deltas to user as soon as generation starts (perceived latency)

2.11 Pinning and migration checklists for breaking changes

Épinglez un snapshot en production et pilotez l’ID de modèle depuis une unique constante adossée à une variable d’env. Lorsque vous migrez — ou lorsqu’une version livre un changement incompatible — suivez une checklist plutôt que d’échanger les ID à l’aveugle.

General migration checklist

1. Changez l’unique constante de modèle derrière un feature flag (ne modifiez pas les ID dans de nombreux fichiers).

2. Relancez le jeu d’éval de référence sur le modèle candidat ; comparez qualité, latence p50/p95, et coût par tâche.

3. Analysez la charge utile de la requête pour repérer les paramètres retirés (voir ci-dessous) et les comportements modifiés (tool_choice, liaison du thinking).

4. Déployez sur une petite tranche de trafic, surveillez les taux d’erreur (les pics de 400 signalent un paramètre rejeté), puis montez en charge.

Breaking-change specifics

2.12 A routing / cascade implementation

Le routage garde la majorité du trafic sur un modèle bon marché et n’escalade que la queue difficile. La décision d’escalader doit venir d’un signal structuré (un label de classifieur, un échec de validation, ou un refusal/résultat d’outil à faible confiance) — jamais du parsing de prose.

import os
from anthropic import Anthropic

client = Anthropic()

CHEAP = "claude-haiku-4-5"
MID = "claude-sonnet-5"
HARD = "claude-opus-5"

def answer(messages, tools=None):
    """Cascade : essayer bon marché, escalader sur refusal/faible confiance ou échec de validation."""
    resp = client.messages.create(model=CHEAP, max_tokens=1024, messages=messages, tools=tools or [])
    if resp.stop_reason == "refusal" or not passes_quality_gate(resp):
        resp = client.messages.create(model=MID, max_tokens=2048, messages=messages, tools=tools or [])
        if resp.stop_reason == "refusal" or not passes_quality_gate(resp):
            resp = client.messages.create(model=HARD, max_tokens=4096, messages=messages, tools=tools or [])
    return resp

def passes_quality_gate(resp) -> bool:
    """Contrôle programmatique : validité du schéma, champs requis présents, réponse non vide.
    NE PAS utiliser la confiance auto-déclarée du modèle (anti-pattern #4)."""
    text = "".join(b.text for b in resp.content if getattr(b, "type", None) == "text")
    return len(text.strip()) > 0 and "I cannot" not in text

Request ─► Haiku 4.5 ──(gate passes)──► return
              │
              └─(refusal / gate fails)─► Sonnet 5 ──(gate passes)──► return
                                            │
                                            └─(rare)─► Opus 5 ──► return

2.13 A cost model you can compute in your head

L’examen attend une arithmétique rapide et défendable. Mémorisez les prix par MTok et les quatre multiplicateurs, puis estimez.

Prix par MTok : Haiku 4.5 $1/$5, Sonnet 5 $2/$10, Opus 5 $5/$25, Fable 5.1 $10/$50.

Exercice détaillé. 4 000 entrée + 800 sortie tokens, 30 000×/jour, sur Haiku vs Sonnet :

Haiku est exactement la moitié ici — mais ne le choisissez que s’il passe la barre de qualité. Ensuite, si la charge est tolérante à la latence, divisez encore par deux avec Batches, et réduisez la portion de préfixe partagé à ~10 % avec le caching.

2.14 Choosing thinking effort deliberately

L’effort et le mode de thinking échangent la qualité contre la latence et le coût en tokens. L’examen teste le choix du minimum qui passe la barre.

2.15 Common misconceptions

2.16 Scenario walkthrough: taming a runaway model bill

Scénario. Une équipe fait tout tourner sur Opus 5 « par sécurité ». La charge est de 95 % de classifications courtes de type FAQ et 5 % de raisonnement multi-étapes réellement difficile. La facture fait 5× le budget. La latence des classifications doit rester interactive ; les cas difficiles peuvent prendre plus de temps. Ils exécutent aussi une éval nocturne de 20 000 items sur le même Opus 5. Une proposition sur la table : « escalader vers Fable 5.1 dès qu’Opus 5 rapporte une confiance inférieure à 0,9. » Vous devez réduire le coût sans nuire aux cas difficiles ni à la fidélité de l’éval.

Trace de raisonnement d’expert.

1. Séparez le trafic par difficulté. 95 % est trivial → déplacez-le vers Haiku 4.5 (le moins cher, assez rapide pour rester interactif). Gardez un chemin vers un modèle plus grand pour les 5 %. Faire tout tourner sur Opus 5 est le défaut aveugle aux contraintes qui a causé le dépassement.
2. Concevez correctement le contrôle d’escalade. Escaladez sur un signal programmatique — un label de classifieur, un échec de validation de schéma, ou un refusal — pas sur la confiance auto-déclarée du modèle (anti-pattern nº 4). Le contrôle proposé à 0,9 de confiance est la mauvaise conception.
3. Choisissez la cible d’escalade selon le besoin, pas le prestige. La plupart des cas difficiles passent sur Sonnet 5 ; réservez Opus 5 à la rare queue la plus ardue. Sauter directement à Fable 5.1 est sur-dimensionné et ajoute ici ses contraintes de rétention à 30 jours et d’append-only sans bénéfice.
4. Traitez l’éval nocturne séparément. Elle est tolérante à la latence et en masse → exécutez-la via la Batches API (50 % de moins) sur le modèle le moins cher qui passe la barre de qualité de l’éval. Ne confondez pas le modèle de l’éval avec celui du classifieur de production.
5. Vérifiez par l’arithmétique. Si les 95 % passent d’Opus ($5/$25) à Haiku ($1/$5), le coût en masse baisse d’environ 5× ; seule la queue de 5 % paie les tarifs Sonnet/Opus. Cela seul ramène probablement la facture dans le budget.
6. Rejetez les alternatives tentantes. « Garder Opus 5 mais baisser max_tokens » — n’élague que la sortie, pas le dépassement lié au palier de modèle. « Utiliser Fable 5.1 pour les cas difficiles car il est le plus capable » — sur-dimensionné et ajoute des contraintes de rétention/append-only. « Escalader sur la confiance » — recours à l’auto-déclaration.

Décision correcte. Cascade Haiku 4.5 → Sonnet 5 → (rare) Opus 5 avec un contrôle d’escalade programmatique ; exécutez l’éval nocturne sur le modèle adéquat le moins cher via Batches. Épinglez les snapshots et validez le changement derrière le jeu d’éval de référence avant le déploiement.

Pièges de l’examen dans ce domaine

Questions d’entraînement

À retenir

• Les tokens déterminent coût, latence et limites ; la fenêtre de contexte contient entrée + sortie, max_tokens ne plafonne que la sortie.
• temperature: 0 réduit la variance mais n’est pas déterministe octet par octet ; épinglez un snapshot pour la reproductibilité.
• Commencez à Sonnet 5 ; Haiku 4.5 pour le fort volume bon marché, Opus 5 pour le travail agentique difficile, Fable 5.1 pour le plus ardu.
• budget_tokens est propre à Haiku 4.5 ; les niveaux d’effort s’appliquent à Opus 5 / Sonnet 5 / Fable 5.1.
• Connaissez les changements incompatibles : retrait de budget_tokens, tool_choice/liaison-du-thinking/append-only de Fable 5.1, retrait d’Opus 4.1.
• Leviers de coût : caching (~10 % sur les hits), batching (50 % de moins), routage/cascade bon marché→cher.
• Leviers de latence : streaming (perçue), modèle plus petit / sortie plus courte (réelle), caching, fast mode.
• Calculez le coût de tête : input×price + output×price, puis ×0.5 pour Batches et ×0.1 pour les hits de préfixe mis en cache ; le modèle adéquat le moins cher l’emporte.
• Choisissez l’effort de thinking minimum qui passe la barre ; xhigh est réservé au travail le plus ardu, budget_tokens est propre à Haiku 4.5, et « Haiku + effort » est invalide.
• Les limites de débit portent sur le volume de tokens/requêtes — corrigez-les avec caching, élagage, batching ou un palier supérieur, pas en changeant le palier de modèle.
• Traitez un choix de modèle de production et le choix de modèle d’une éval hors ligne comme des décisions indépendantes ; les évals sont tolérantes à la latence, donc utilisez le modèle adéquat le moins cher via Batches.