Optimiser les coûts d'inférence LLM : quantification, distillation et caching
Une méthode technique pour réduire le coût réel des LLM en production sans sacrifier fiabilité, latence ni gouvernance.
Les coûts d'inférence LLM ne se résument pas au prix affiché par million de tokens. En production, la facture dépend du choix du modèle, de la longueur du contexte, du taux de cache, de la concurrence, de la latence cible, des appels outils, des retries, des logs et de la qualité des réponses. Une architecture mal calibrée peut donc coûter cher même avec un modèle économique à l'unité.
Optimiser ne signifie pas seulement prendre un modèle plus petit. Il faut décider quelles tâches méritent un modèle avancé, quelles tâches peuvent être routées vers un modèle plus léger, quelles parties du prompt sont réutilisables, et quels résultats peuvent être mis en cache. Le sujet devient un problème d'ingénierie système autant qu'un problème de modèle.
1. Mesurer avant d'optimiser
La première erreur consiste à optimiser sans observation fine. Il faut suivre les tokens entrants, tokens sortants, taux de cache, latence, erreurs, coût par tâche et qualité mesurée. Un assistant juridique, un extracteur de factures et un agent support n'ont pas le même profil. L'un consomme beaucoup de contexte, l'autre beaucoup d'appels courts, le troisième beaucoup d'outils.
Le bon indicateur est le coût par résultat utile: ticket résolu, document traité, réponse validée, extraction correcte. Sans cette métrique métier, l'équipe risque de réduire le coût unitaire tout en dégradant la qualité ou en augmentant les reprises humaines.
2. Réduire le contexte inutile
Le contexte long est confortable, mais il peut devenir une dette. Beaucoup de prompts accumulent règles, exemples, historique et documents sans distinguer ce qui est nécessaire pour la tâche. Une stratégie RAG propre, des instructions compactes et une mémoire sélective réduisent le volume de tokens sans réduire la qualité.
Le cache de prompt est un autre levier. Les fournisseurs d'API proposent des mécanismes où les préfixes récurrents peuvent être facturés différemment ou traités plus efficacement. Cela pousse à structurer les prompts: instructions stables au début, données variables ensuite, contexte réutilisable clairement séparé.
3. Quantifier avec prudence
La quantification réduit la précision numérique des poids ou activations pour diminuer mémoire et coût d'exécution. Les documentations comme bitsandbytes dans l'écosystème Transformers montrent l'intérêt de formats 8-bit ou 4-bit selon les cas. Mais la quantification n'est pas magique: elle peut affecter la qualité, la robustesse ou certains comportements rares.
En production, elle doit être validée sur un jeu d'évaluation métier: cas fréquents, cas longs, cas sensibles, refus, extraction, raisonnement, langues et formats. Le bon compromis n'est pas le plus compressé, mais celui qui respecte le seuil de qualité avec une marge opérationnelle.
4. Distiller et router
La distillation consiste à transférer une partie du comportement d'un modèle plus puissant vers un modèle plus léger, souvent via des exemples. Elle est utile lorsque la tâche est stable: classification, extraction, reformulation, génération dans un format contraint. Elle est moins adaptée quand la réponse dépend d'une connaissance très mouvante.
Le routage complète la distillation. Une architecture mature ne demande pas tout au même modèle. Elle route les tâches simples vers un modèle économique, les tâches sensibles vers un modèle plus robuste, et les cas incertains vers validation humaine. Cette logique réduit les coûts sans rendre le système aveugle au risque.
5. Optimiser l'infrastructure
Pour les modèles hébergés en propre, les leviers incluent batching, gestion du KV cache, parallélisme, quantification et moteurs d'inférence spécialisés comme TensorRT-LLM. Ces choix sont puissants, mais ils déplacent la complexité vers l'exploitation: GPU, mémoire, scalabilité, observabilité, mises à jour et sécurité.
La décision build versus API doit donc être économique et organisationnelle. Héberger peut être pertinent pour des volumes élevés, des contraintes de données ou une latence particulière. Utiliser une API reste souvent plus rationnel pour démarrer, tester et absorber rapidement l'évolution des modèles.
6. Feuille de route d'optimisation
La réduction des coûts doit commencer par une baseline: coût par tâche, latence, qualité, taux de cache et volume de tokens. Ensuite seulement, l'équipe teste les leviers un par un: réduction du contexte, prompt caching, routage vers modèles plus petits, batching, quantification ou distillation.
Chaque expérimentation doit conserver une mesure de qualité. Une économie qui augmente les erreurs, les reprises humaines ou les refus injustifiés n'est pas une économie. Le pilotage doit donc réunir finance, produit, data et exploitation autour d'un tableau de bord commun.
Conclusion
Réduire les coûts LLM exige une discipline de production: mesurer, limiter le contexte, utiliser le cache, choisir le bon modèle, router les tâches et valider la qualité. L'économie ne vient pas d'un seul levier, mais d'une architecture où chaque token, chaque appel et chaque modèle ont une raison d'être.
