Réduire le coût des LLM : confier chaque tâche au bon modèle

Le coût vient autant de l’organisation que du modèle

Une facture LLM dépend du volume de tokens en entrée, de la longueur de la réponse, du prix du modèle et du nombre de reprises. Un prompt qui transmet des milliers de lignes inutiles peut coûter davantage qu’un mauvais choix de fournisseur. Avant de router les requêtes, il faut donc mesurer ce qui est envoyé, ce qui est réellement utile et ce qui pourrait être préparé localement.

Le coût total inclut aussi la latence, les échecs et le temps humain consacré à corriger les sorties. Un petit modèle qui produit souvent un résultat inexploitable n’est pas économique. À l’inverse, un modèle puissant utilisé pour une extraction déterministe gaspille sa capacité. La bonne unité de décision est le coût d’un résultat acceptable, pas le prix isolé d’un appel.

• Mesurer les tokens par type de tâche.
• Suivre le taux de réussite sans correction humaine.
• Comparer coût, latence et qualité sur un même jeu d’évaluation.

Penser comme une équipe de chantier

Sur un chantier, l’ingénieur définit les contraintes, vérifie les calculs critiques et arbitre les situations inhabituelles. Le chef d’équipe transforme ces décisions en séquences de travail. Les maçons et manœuvres exécutent ensuite les opérations répétables selon des règles précises. Aucun rôle n’est inutile ; chacun intervient au niveau où sa compétence produit le plus de valeur.

Une architecture de modèles peut suivre le même principe. Le modèle superviseur décompose le problème, choisit les critères d’acceptation et valide le résultat. Un modèle worker résume des documents, classe des éléments, prépare des tests ou transforme un format. Si le worker détecte une ambiguïté, échoue à une validation ou dépasse un seuil, la tâche remonte vers le superviseur.

Construire une matrice de routage

Il n’est pas nécessaire de commencer par entraîner un routeur complexe. Une matrice explicite peut associer les tâches répétitives à un petit modèle, les tâches spécialisées à un modèle intermédiaire et les décisions à fort impact à un modèle plus robuste. Les règles considèrent la sensibilité des données, la longueur du contexte, la vérifiabilité et le coût d’une erreur.

RouteLLM et FrugalGPT montrent que le routage et les cascades peuvent améliorer le compromis coût-qualité. Leurs résultats restent liés à leurs modèles, données et protocoles : ils ne constituent pas une promesse universelle. Ils fournissent surtout une méthode utile — comparer plusieurs politiques sur les mêmes requêtes et observer leur frontière coût-qualité.

• Petit modèle : extraction, classification et reformattage.
• Modèle intermédiaire : génération structurée et analyse de lots.
• Grand modèle : planification, arbitrage et contexte ambigu.

L’escalade est plus importante que le premier choix

Un bon système suppose que son premier choix peut être mauvais. Le worker produit une sortie structurée, signale ses hypothèses et fournit les éléments nécessaires à une vérification. Un schéma JSON, une compilation, des tests, une règle métier ou un contrôle de citations peuvent décider d’accepter la sortie ou de l’escalader.

L’escalade reste bornée. Sans limite, un modèle peut consommer davantage en tentatives qu’un appel direct au modèle puissant. On définit un nombre maximal de reprises, un budget et une condition d’arrêt. Lorsque ces limites sont atteintes, le système rend un état explicite plutôt que d’inventer une réussite.

Évaluer avec des tâches réelles

Le routeur doit être testé sur un corpus représentatif : petites demandes, contextes longs, ambiguïtés et cas où une erreur serait coûteuse. Les métriques incluent le coût moyen, la latence, le taux d’escalade et la proportion de sorties acceptées sans retouche.

La politique optimale évolue lorsque les modèles, les prix ou les besoins changent. Il faut versionner les règles et rejouer régulièrement les évaluations. L’objectif n’est pas de prouver qu’un petit modèle remplace toujours un grand, mais d’éviter que la puissance maximale devienne un choix automatique et invisible.

Déployer progressivement plutôt que basculer d’un coup

La première version peut fonctionner en mode observation : le routeur propose un modèle, mais le système continue d’utiliser la politique existante. On compare ensuite les deux décisions sans risquer la production. Lorsque les résultats deviennent stables, une petite fraction du trafic passe par la nouvelle politique, avec un groupe témoin et un retour automatique vers le modèle de référence en cas de dérive.

Cette progression rend les économies attribuables. Elle évite de confondre un changement de modèle avec une variation du trafic, une nouvelle interface ou un autre prompt. Les équipes peuvent fixer un budget par fonctionnalité et non seulement un budget global : une recherche exploratoire tolère davantage de coût qu’une classification exécutée des milliers de fois.

Une checklist avant de router en production

Le routage devient une capacité du produit, avec un propriétaire, des évaluations et une procédure d’incident. Les journaux ne doivent pas conserver inutilement des données sensibles. Ils enregistrent surtout la catégorie de tâche, le modèle choisi, le coût estimé, la latence, la validation et la raison d’une escalade.

Enfin, une économie n’est réelle que si la qualité reste acceptable et si la complexité ajoutée reste inférieure au gain. Pour un faible volume, un seul modèle bien configuré peut être le choix le plus rationnel. Le routeur devient pertinent lorsque les tâches sont suffisamment diverses et répétées pour amortir son exploitation.

• Définir une qualité minimale par tâche.
• Plafonner reprises, tokens et durée.
• Prévoir un modèle de secours et un arrêt explicite.
• Recalculer régulièrement le coût d’un résultat accepté.