La nouvelle facture des LLMs, comprendre les coûts cachés

La simplicité des débuts est terminée. La nouvelle grille tarifaire de l’un des plus grands fournisseurs de LLM, effective depuis cet été, a mis fin à l’ère du simple comptage de tokens. Le prix d’un appel API dépend maintenant d’une combinaison de facteurs : non seulement le nombre de tokens en entrée et en sortie, mais aussi la taille du contexte, l’utilisation d’outils (function calling), et même le niveau de “garantie de cohérence” demandé. Cette complexité n’est pas un caprice ; elle reflète le coût réel du calcul pour le fournisseur. Pour les entreprises, c’est un signal clair : l’optimisation des appels LLM n’est plus une option, c’est une nécessité pour survivre.

l’anatomie de la nouvelle facture

Le coût d’un appel n’est plus linéaire. Il est la somme de plusieurs composantes, chacune avec son propre prix.

stratégies d’adaptation immédiates

Face à cette nouvelle réalité, nous avons dû adapter nos applications. Voici les trois leviers qui ont eu le plus d’impact.

1. agresser le contexte

Le coût supplémentaire pour les contextes longs nous a forcés à devenir impitoyables sur ce que nous envoyons au modèle.

Pré-filtrage RAG plus strict: Au lieu d’envoyer les 10 “chunks” les plus pertinents, nous n’en envoyons plus que 3 à 5, après une étape de “reranking” pour éliminer la redondance.
Résumé de l’historique: Pour les chatbots, nous ne gardons plus tout l’historique de la conversation. Un appel LLM séparé (avec un modèle plus petit et moins cher) résume la conversation tous les 4 messages.

2. optimiser les appels d’outils

Chaque “tool call” est maintenant facturé. Le regroupement devient essentiel.

Regroupement des appels: Au lieu de demander au LLM d’appeler une API pour chaque information manquante, nous avons modifié nos prompts pour qu’il liste d’abord toutes les informations dont il a besoin. Un seul appel d’outil peut alors récupérer toutes ces informations en parallèle.
Outils plus intelligents: Nous avons créé des “méta-outils” qui effectuent plusieurs actions atomiques en un seul appel, réduisant le nombre d’allers-retours avec le LLM.

3. router les requêtes intelligemment

Tous les appels ne se valent pas. Une tâche simple ne justifie plus l’utilisation d’un modèle de pointe.

Le “routeur” de modèles: Nous avons mis en place un classifieur simple en amont qui analyse l’intention de la requête. Les questions simples sont dirigées vers un petit modèle open source auto-hébergé, bien moins cher. Seules les tâches complexes (synthèse, planification) sont envoyées vers le modèle propriétaire coûteux.

# Pseudo-code d'un calculateur de coût prédictif
def estimate_cost(input_tokens, output_tokens, tool_calls=0, context_size=0):
    # Tarifs fictifs pour l'exemple
    cost = (input_tokens * 0.001 / 1000) + (output_tokens * 0.003 / 1000)
    cost += tool_calls * 0.005 # Coût par appel d'outil
    if context_size > 16000:
        cost += 0.01 # Supplément contexte long
    return cost

erreurs à ne pas commettre

L’optimisation prématurée à l’extrême: Avant de passer des semaines à réduire le nombre de tokens d’un prompt, analysez vos logs. Concentrez-vous sur les 20% de types d’appels qui génèrent 80% de votre facture.
Ignorer le coût du cache: Mettre en cache des réponses est une bonne pratique, mais le coût de stockage et de lecture de ce cache (ex: Redis) n’est pas nul. Il faut le prendre en compte dans le calcul global.
Ne pas communiquer sur les changements: Vos utilisateurs internes et externes doivent comprendre pourquoi la performance ou le comportement de l’application peut changer. Expliquez les arbitrages que vous faites entre coût, latence et qualité.

faq

Pourquoi les fournisseurs de LLM complexifient-ils leur tarification ? Pour aligner le prix sur le coût réel. Une requête avec un long contexte ou qui nécessite des appels d’outils mobilise beaucoup plus de ressources de calcul qu’une simple question. Cette nouvelle tarification est plus “juste” du point de vue du fournisseur.
Est-ce le bon moment pour basculer massivement vers des modèles open source auto-hébergés ? C’est une question d’échelle. Auto-héberger un modèle puissant a un coût fixe important (GPU, infrastructure, MLOps). Calculez le point de bascule où le coût de l’auto-hébergement devient inférieur à votre facture mensuelle d’API. Pour beaucoup, un modèle hybride (petit modèle open source pour les tâches simples, API propriétaire pour les tâches complexes) est le meilleur compromis.
Comment puis-je suivre ces coûts de manière fiable ? Ne vous fiez pas uniquement à la facture du fournisseur. Mettez en place votre propre système de journalisation (logging) qui enregistre, pour chaque appel, le nombre de tokens, les outils utilisés et le coût estimé. Cela vous donnera une vision bien plus granulaire et en temps réel.

Menu