Calculer et prévoir les coûts de l’API

À grande échelle, les coûts d'API des applications utilisant des LLM peuvent être étonnamment élevés. Une seule requête qui semble peu coûteuse à 0,002 $ atteint 200 $ lorsqu'elle est exécutée 100 000 fois. Sans prévision ni suivi des coûts, les fonctionnalités d'IA peuvent générer des factures cloud imprévues qui dépassent largement toutes vos dépenses d'infrastructure.

La bonne nouvelle est que les coûts des LLM sont entièrement prévisibles avant l'envoi d'une requête : vous connaissez le modèle, vous pouvez compter les jetons d'entrée avec tiktoken et vous pouvez estimer les jetons de sortie à partir de votre réglage max_tokens ou de moyennes historiques. Intégrer la prévision des coûts à votre application dès le premier jour permet d'éviter les mauvaises surprises de facturation.

OpenAI facture séparément les jetons d'entrée et les jetons de sortie, ces derniers coûtant généralement 3 à 4 fois plus cher. Les prix varient selon le modèle. À titre indicatif pour 2025, vérifiez toujours la page tarifaire actuelle, car les prix évoluent :

• gpt-4o-mini : environ 0,15 $ par million de jetons d'entrée, environ 0,60 $ par million de jetons de sortie
• gpt-4o : environ 2,50 $ par million de jetons d'entrée, environ 10,00 $ par million de jetons de sortie
• text-embedding-3-small : environ 0,02 $ par million de jetons

La différence de coût entre les modèles est énorme : gpt-4o est environ 17 fois plus cher que gpt-4o-mini par jeton d'entrée. Le choix du modèle est votre principal levier de maîtrise des coûts : commencez toujours par le modèle le moins cher qui répond à vos exigences de qualité.

Créez un estimateur de coûts que vous appelez avant d'envoyer chaque requête. Il compte les jetons d'entrée avec tiktoken, estime les jetons de sortie à partir de votre paramètre max_tokens, recherche le tarif correspondant au modèle et renvoie le coût estimé en dollars. Appelez-le pendant le développement et consignez les résultats afin de vous familiariser avec le coût des différents types de requêtes.

Après chaque appel d'API, l'objet de réponse contient le nombre réel de jetons utilisés. Extrayez ces données pour consigner les coûts réels et les comparer à vos estimations. Au fil du temps, l'écart entre les nombres de jetons de sortie estimés et réels vous indique la précision de vos prévisions d'utilisation, tandis que les journaux vous fournissent une ventilation des coûts par fonctionnalité ou segment d'utilisateurs.

Une fois que vous connaissez le coût moyen par requête et le volume de requêtes prévu, la prévision des coûts mensuels est simple. Créez un tableur de modélisation des coûts ou un script Python simple qui vous permet de tester différentes hypothèses : que se passe-t-il si le nombre d'utilisateurs actifs quotidiens double ? Que se passe-t-il si nous ajoutons une fonctionnalité qui effectue 3 appels d'API par action de l'utilisateur au lieu d'un seul ?

Le principal levier de réduction des coûts consiste à utiliser le modèle le moins cher qui répond à vos exigences de qualité. Pour de nombreuses tâches, gpt-4o-mini offre des performances comparables à celles de gpt-4o, mais pour un coût environ 17 fois inférieur. Avant d'utiliser par défaut le modèle le plus puissant, évaluez le modèle moins cher sur votre tâche spécifique et passez au modèle plus coûteux uniquement si la qualité descend sous votre seuil.

Une stratégie d'orientation par niveaux est encore plus efficace : classez les requêtes entrantes selon leur complexité et orientez les requêtes simples vers des modèles peu coûteux et les requêtes complexes vers des modèles coûteux. Même en orientant 70 % du trafic vers le modèle peu coûteux et 30 % vers le modèle coûteux, vous économisez environ 70 % de vos coûts d'IA.

Chaque jeton de votre invite coûte de l'argent. Une invite système verbeuse qui pourrait être condensée sans perte de sens augmente directement votre facture d'API à chaque requête. Mesurez le nombre de jetons de vos invites et cherchez à resserrer leur formulation. De même, les longs exemples à quelques coups peuvent souvent être remplacés par des équivalents plus courts sans sacrifier la précision.

Pour les systèmes RAG, le contexte récupéré constitue souvent la plus grande partie de l'invite. Renvoyer 10 grands segments alors que 3 segments plus petits et bien choisis suffiraient gaspille des jetons à chaque requête. Ajustez votre récupération afin de réduire le contexte redondant tout en maximisant la pertinence.

OpenAI propose une API Batch qui traite les requêtes de manière asynchrone avec une remise de 50 % par rapport au tarif standard. Si votre cas d'utilisation n'est pas sensible à la latence — traitement de documents, tâches d'analyse nocturnes, génération de contenu en masse — l'API Batch peut diviser vos coûts par deux avec un minimum de modifications du code.

Les requêtes groupées sont envoyées sous forme de fichiers JSONL, traitées dans les 24 heures, puis les résultats sont récupérés depuis l'API. Cette solution est idéale pour les chaînes de prétraitement exécutées selon un calendrier et qui n'ont pas besoin de réponses en temps réel.

Configurez toujours des limites de dépenses afin d'éviter une envolée incontrôlée des coûts. Dans le tableau de bord OpenAI, vous pouvez définir des plafonds de dépenses mensuels qui désactivent l'accès à l'API lorsque la limite est atteinte. Définissez une limite stricte correspondant au montant maximal acceptable et une limite souple à 80 % de cette valeur afin de recevoir un avertissement par e-mail avant d'atteindre le plafond strict.

Dans le code de votre application, mettez en place un budget par utilisateur ou par fonctionnalité, suivi dans votre base de données. Vérifiez le budget avant chaque appel d'API et renvoyez une erreur s'il est épuisé. Cela empêche un utilisateur incontrôlable ou un bug dans une tâche groupée de consommer votre quota mensuel entier en quelques heures.

L'appel d'API le moins coûteux est celui que vous n'effectuez jamais. Mettez en place une mise en cache au niveau de l'application afin de servir les requêtes identiques depuis le cache plutôt que d'appeler à nouveau l'API. Même un simple cache Redis indexé par la valeur de hachage SHA256 de l'invite peut éliminer une part importante des appels redondants dans une application en production.

Pour les plongements, la mise en cache est particulièrement efficace : un même texte ne devrait être plongé qu'une seule fois. Stockez les plongements dans votre base de données vectorielle en utilisant le texte original comme clé, et vérifiez si un plongement existe déjà avant d'appeler l'API de plongement. Dans une chaîne RAG, les plongements des documents sont calculés une fois lors de l'indexation, puis réutilisés pour chaque requête qui les récupère.

En production, vous devez disposer d'une visibilité sur vos coûts d'IA, ventilés par fonctionnalité, utilisateur et modèle. Créez un tableau de bord des coûts en enregistrant, pour chaque appel d'API, le nombre de jetons et les métadonnées associées (ID utilisateur, nom de la fonctionnalité, modèle) dans une base de données de séries temporelles. Agrégez ensuite ces données pour répondre à des questions telles que : quelle fonctionnalité entraîne les dépenses les plus élevées ? Les utilisateurs intensifs génèrent-ils des coûts disproportionnés ? Le coût par requête augmente-t-il après une modification de l'invite ?

Cette visibilité est essentielle pour prendre des décisions d'optimisation fondées sur les données plutôt que de deviner où réduire les coûts. La plupart des entreprises découvrent que 20 % de leurs fonctionnalités représentent 80 % de leurs dépenses d'IA, et que l'optimisation de ces fonctionnalités a un impact disproportionné.

Dans cette leçon, vous avez appris que : les coûts d'API peuvent être prévus avant l'envoi en comptant les jetons d'entrée avec tiktoken et en estimant les jetons de sortie, le choix du modèle est le principal levier de réduction des coûts — gpt-4o-mini peut coûter 17 fois moins cher que gpt-4o pour les tâches appropriées, et la mise en cache, le regroupement des requêtes et les limites de dépenses empêchent une envolée incontrôlée des coûts en production. Nous allons maintenant explorer des stratégies pour gérer les conversations longues qui dépassent la fenêtre de contexte.