Dans quel ordre optimiser les coûts des LLM ?

Activez le cache des prompts, raccourcissez le prompt système, supprimez les définitions d'outils inutiles, routez selon la tâche puis traitez par lots le trafic hors production. Réservez le fine-tuning pour la fin.

Pourquoi éviter de commencer par le fine-tuning ?

Un retour d'expérience de septembre 2026 décrit une maintenance lourde et une qualité en baisse pour un modèle ajusté sur des tâches répétitives. Le gain visé portait sur 15 % du volume et 2 % de la dépense.

Combien le cache de prompts peut-il économiser ?

Pour Opus 5.5, le million de tokens lus du cache coûte 0,20 $ contre 4,00 $ pour une entrée nouvelle : 95 % de remise sur ces tokens. Si un préfixe se répète, la baisse totale estimée peut atteindre 40–70 %.

Faut-il retirer les définitions d'outils rarement utilisés ?

Oui, si ces outils ne sont pas nécessaires. Chaque définition occupe du contexte à chaque requête, même sans appel de l'outil. La retirer évite d'envoyer ces tokens superflus.

L'ordre des optimisations de coûts LLM

Mis à jour September 27, 2026 · première publication September 27, 2026

En septembre 2026, une discussion sur r/LLMDevs demandait comment les équipes maîtrisent réellement les coûts des LLM en production et ce qu'elles feraient si le temps d'ingénierie ne les limitait pas. La réponse la mieux notée donnait un conseil plus utile qu'un guide commercial : l'ordre compte bien plus qu'on ne l'admet. L'équipe a commencé par mettre les prompts en cache et réduire fortement les prompts système. Son essai de fine-tuning d'un petit modèle pour les tâches répétitives a échoué : maintenance pénible et qualité qui se dégradait.

L'ordre qui fonctionne

Mettre les prompts en cache. C'est une heure d'ingénierie particulièrement rentable. Pour Opus 5.5, un million de tokens lus depuis le cache coûte 0,20 $ contre 4,00 $ pour une entrée nouvelle, soit 95 % de remise sur cette catégorie. Si le prompt système, les définitions d'outils ou le contexte récupéré se répètent, commencez ici.
Raccourcir le prompt système. La même réponse insistait sur ce point. Les instructions trop longues sont facturées à chaque appel. Il s'agit d'abord d'un travail de rédaction.
Supprimer les outils inutilisés. Chaque définition est envoyée dans le contexte de chaque requête, même si l'outil n'est jamais appelé. C'est le même surcoût que celui des définitions d'outils MCP. Retirer un outil peut ne demander qu'une ligne de configuration et produire un effet durable.
Router selon la tâche. C'est seulement à ce stade que le routage entre modèles devient intéressant. Un routeur construit après la mise en cache bénéficie déjà d'un coût inférieur avant même le premier changement de modèle.
Traiter par lots ou différer. Une API batch offre une réduction directe pour le travail qui n'attend pas une réponse immédiate. Dans la mesure du possible, le trafic hors production devrait utiliser ce mode dès le départ.
Garder le fine-tuning pour la fin, si nécessaire. C'est souvent le premier réflexe des équipes et celui qui a échoué ici. Maintenance et dérive de qualité créent une charge permanente pour un gain peut-être déjà obtenu par le cache et le routage.

Pourquoi cet ordre est décisif

Chaque étape modifie le nombre de tokens et les coûts auxquels s'applique la suivante. Un prompt système raccourci avant le routage permet au modèle moins cher de traiter davantage de trafic avec la même logique. Avec le cache activé avant un fine-tuning, seuls les défauts de cache restent à justifier dans son budget. Dans le mauvais ordre, on paie deux fois : un modèle ajusté qu'une réécriture du prompt aurait rendu superflu, ou un routeur qui confie 60 000 tokens d'instructions à un modèle économique inadapté.

Le piège du fine-tuning précoce

Dans la discussion, le petit modèle ajusté devait prendre en charge un travail répétitif. L'économie visée était plausible, mais chaque évolution du travail imposait un nouvel entraînement. Sa qualité s'éloignait de celle du modèle de base au fil des mises à jour, et la charge d'exploitation rendait la solution difficile à maintenir. Ce travail ne représentait probablement que 15 % du volume et 2 % de la dépense : un gain limité assorti d'un coût récurrent élevé.

Tester la séquence sur une requête

Prenez une requête représentative. Appliquez chaque étape dans l'ordre et relevez les tokens facturés ainsi que le coût :

Étape	Ce qui change	Baisse typique indiquée
Cache activé	Le préfixe répété devient une lecture du cache	40–70 %
Prompt système raccourci	Moins de tokens non mis en cache à chaque appel	10–25 %
Outils inutilisés retirés	Bloc de définitions plus court	5–15 %
Routage	Modèle moins cher pour la plupart des requêtes	30–60 %
Lots hors production	Tarif réduit	25–50 % pour ce trafic

Ces effets se cumulent. Dans cet exemple, la même requête peut revenir 80–90 % moins cher. En commençant par le fine-tuning, on risque au contraire de l'appliquer à 15 % du volume tout en conservant un routeur qui ne s'amortit jamais. Les chiffres relatifs au cache et au routage sont des économies de coût : le routage seul ne réduit pas le nombre de tokens.

À retenir

Cache, prompts plus courts et suppression des outils inutilisés sont des mesures peu coûteuses, cumulatives et relativement peu risquées. Routage et traitement par lots suivent. Le fine-tuning vient en dernier, s'il est encore utile. La difficulté tient à la séquence, pas à la liste.