La plupart du trafic LLM en production n'est pas difficile. C'est de la classification, de l'extraction, des réécritures courtes et du routage, le genre de travail qu'un petit modèle rapide fait correctement et à moindre coût. Pourtant, le pattern courant consiste à câbler chaque appel vers le plus gros modèle disponible, parce que « ça marche tout simplement », puis à se demander pourquoi la facture et la latence sont toutes les deux élevées. Sur Amazon Bedrock, Claude Haiku 4.5 et Claude Opus 4.5 sont tous les deux disponibles, et le gain d'ingénierie n'est pas d'en choisir un, c'est de router par classe de tâche pour que le modèle bon marché gère la majorité et que le modèle coûteux soit un chemin d'escalade, pas un défaut.

Le recadrage : le choix de modèle est une décision par tâche, pas une décision valable pour tout le projet. Dimensionner chaque requête sur votre requête la plus difficile est la même erreur que de faire tourner chaque charge de travail sur votre plus gros type d'instance. Le bon dimensionnement, c'est faire correspondre le modèle à la difficulté de l'appel spécifique, et pour une large part des appels, la bonne taille est petite.

Pourquoi le gros modèle est le mauvais défaut

Prendre par défaut le modèle de pointe semble prudent et coûte cher sur deux dimensions. Les modèles de classe Opus coûtent plusieurs fois plus par token que ceux de classe Haiku, donc une charge de travail mécanique à 90 pour cent paie des prix de pointe pour un travail qu'un petit modèle fait parfaitement. Ils sont aussi plus lents, car les modèles plus capables mettent généralement plus de temps à répondre, ce qui gonfle la latence exactement sur les appels à fort volume et simples où les utilisateurs remarquent le plus la vitesse.

Le coût caché, c'est qu'un gros modèle sur une tâche simple produit rarement un meilleur résultat. Extraire une date d'un email ou classer un ticket dans l'un de six casiers ne s'améliore pas quand vous y jetez plus de capacité. Vous payez plus et attendez plus longtemps pour une réponse qu'un modèle plus petit aurait obtenue correctement.

Router par classe de tâche

La conception qui fonctionne, c'est de classer la requête par difficulté et de l'envoyer au modèle qui convient. Pas par utilisateur, pas par fonctionnalité, par classe de tâche :

  • Le travail mécanique va vers Haiku. Classification, extraction, conversion de format, résumés courts, construction d'arguments d'outils et décisions de routage. Fort volume, faible ambiguïté, et un petit modèle est à la fois moins cher et plus rapide sans perte de qualité.
  • Le travail de jugement va vers Opus. Raisonnement multi-étapes, instructions ambiguës, synthèse de long contexte, et tout ce où une mauvaise réponse coûte cher. Volume plus faible, et ça vaut la prime parce que la capacité change réellement le résultat.
  • Le routeur lui-même est bon marché. Une heuristique sur la longueur d'entrée et le type de tâche, ou un simple appel à un petit modèle, décide de la classe. Le coût de routage est une erreur d'arrondi face à ce que vous économisez en ne mettant pas tout par défaut sur le haut de gamme.

Le gros modèle comme chemin d'escalade

Le pattern le plus fiable consiste à faire du modèle de pointe une escalade, pas une porte d'entrée. Essayez d'abord le petit modèle. S'il réussit, et pour la majorité mécanique il réussira, vous en avez fini pour une fraction du coût et de la latence. S'il échoue à un contrôle, faible confiance, sortie invalide par rapport au schéma, un « je ne suis pas sûr » explicite, escaladez cette requête unique vers le plus gros modèle.

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

Ça inverse l'économie. Au lieu de payer les prix d'Opus sur chaque requête pour couvrir le rare cas difficile, vous payez les prix de Haiku sur le cas courant et ne sollicitez Opus que quand la tentative bon marché a visiblement échoué. L'échange, c'est un appel supplémentaire sur la minorité de requêtes qui en ont besoin, contre une grosse économie sur la majorité qui n'en a pas besoin.

Mesurez avant de supposer la répartition

L'endroit où les équipes se trompent, c'est de deviner le mélange de tâches au lieu de le mesurer. Avant de router, échantillonnez le trafic réel et étiquetez la part réellement mécanique contre la part réellement difficile. Le chiffre est presque toujours plus mécanique que l'équipe ne l'attend, ce qui explique exactement pourquoi prendre le gros modèle par défaut gaspille autant. Ça vous dit aussi où fixer le déclencheur d'escalade : si le petit modèle gère 92 pour cent du trafic proprement, votre taux d'escalade devrait être proche de 8 pour cent, et un taux bien plus élevé signifie que votre contrôle est trop strict ou que votre routage est mal calibré.

À retenir

Haiku et Opus sont tous les deux sur Bedrock depuis des mois, et l'enjeu n'est pas de choisir entre les deux, c'est d'utiliser chacun là où il convient. Routez par classe de tâche : envoyez la majorité mécanique vers le petit modèle rapide et réservez le modèle de pointe à la minorité qui exige du jugement, idéalement comme chemin d'escalade déclenché par un contrôle échoué plutôt que comme défaut. Mesurez votre mélange de tâches réel avant d'ajuster la répartition. Le bon dimensionnement de modèle est la même discipline que le bon dimensionnement d'instance, et le système le plus rapide et le moins cher est celui qui arrête de payer des prix de pointe pour un travail qu'un petit modèle fait correctement.

À lire ensuite

Pour le côté plateforme du routage et de la capacité entre modèles, les notes de terrain cloud vivent sur ercan.cloud, et le hub est sur ercanermis.com.