Sélection de modèles et maîtrise des coûts : du « tout avec le plus puissant » à la hiérarchisation par tâche

Pourquoi « utiliser toujours le modèle le plus puissant » est un piège de coût

Les capacités des modèles sont stratifiées : les modèles phares excellent dans le raisonnement à longue chaîne, le code complexe et les instructions à contraintes multiples ; les modèles légers suffisent souvent pour la classification, l'extraction, la conversion de format et les questions-réponses courtes. Or l'écart de prix unitaire entre les deux peut atteindre dix fois ou plus.

La page tarifaire actuelle d'Anthropic et l'[API pricing](https://developers.openai.com/api/docs/pricing) d'OpenAI classent tous deux leurs modèles en plusieurs niveaux ; en prenant l'exemple de la [pricing](https://claude.com/pricing) publiée par Anthropic, les trois niveaux Opus, Sonnet et Haiku ciblent des tâches d'intensité différente, avec des écarts de prix unitaire marqués. Confier chaque jour des centaines de milliers de classifications simples au modèle phare est le gaspillage le plus facile à négliger.

Intégrer la hiérarchisation des tâches dans le code

1. Lister les appels LLM du système par « type de tâche » (classification / extraction / résumé / génération / raisonnement / code).
2. Choisir un niveau par défaut pour chaque type de tâche et l'inscrire dans la configuration, plutôt que des noms de modèles éparpillés un peu partout.
3. Préparer 50 à 200 échantillons d'évaluation fixes par type de tâche, incluant des cas difficiles typiques.
4. Exécuter d'abord une baseline avec le niveau par défaut, puis tenter une rétrogradation en comparant le taux d'exactitude et le taux de conformité au format.
5. Ne conserver la rétrogradation que si la perte de qualité est inférieure au seuil ; sinon revenir au niveau précédent.

Routage par paliers : d'abord le moins cher, ensuite le plus cher

Un schéma pratique consiste à « commencer par le moins cher, puis passer au plus cher » : traiter d'abord avec le modèle léger, puis passer au modèle phare lorsque les signaux suivants apparaissent —

• La sortie est impossible à parser (JSON cassé, champs manquants).
• Le modèle déclare lui-même une incertitude, ou la confiance est inférieure au seuil.
• Une validation qualité côté métier est déclenchée (par exemple, le SQL généré ne s'exécute pas).
• Un indicateur de complexité de la requête dépasse le seuil (longueur d'entrée, nombre de documents cités).

Ainsi, la majorité du trafic reste sur le niveau bon marché, et seule la partie réellement difficile est facturée au niveau phare. Veillez à intégrer le nombre de montées en niveau au monitoring : un taux de montée durablement élevé indique qu'il faut réévaluer la sélection de modèles.

Points à vérifier avant de changer de fournisseur

Les différents fournisseurs ne sont pas cohérents sur le style de sortie, le format d'appel d'outils ou la politique de refus pour une même tâche. Avant de faire passer un type de tâche du fournisseur A au fournisseur B, il faut au minimum vérifier :

• Sortie structurée : le niveau de support du JSON mode / schéma strict est-il identique.
• Format d'appel d'outils : structure des paramètres, appels parallèles, mode de retour d'erreur.
• Longueur de contexte et comportement de troncature : une entrée trop longue provoque-t-elle une erreur ou une troncature silencieuse.
• Différences de politique de contenu : un même extrait d'entrée est refusé par un modèle et accepté par un autre.

Hiérarchiser au sein d'une même passerelle

Admesh conserve en externe le protocole compatible OpenAI, et expose les modèles sous la forme namespace/model (par exemple anthropic/…, openai/…, deepseek/…). Cela signifie que la hiérarchisation des tâches se résume à maintenir une table de correspondance « type de tâche → modèle » dans la configuration, le code ne modifiant toujours que le paramètre model.

Comme le routage s'effectue uniquement au sein du pool de canaux d'un même public_model, votre anthropic/xxx ne sera pas silencieusement remplacé par le modèle d'un autre fournisseur — la hiérarchisation est votre choix explicite, pas une décision de la passerelle à votre place.

Voir l'API de liste des modèles →