Budget API LLM : compter le coût d’une tâche entière

Choisir la bonne unité : une tâche livrée

Prenons un traitement qui transforme un compte rendu en note de synthèse. Une première requête extrait les décisions ; une deuxième rédige la note ; une troisième peut vérifier les incohérences. Le prix de la dernière réponse ne décrit donc pas le coût du travail entier. Définissez une tâche comme un résultat vérifiable, avec un nombre d’étapes prévu et une politique explicite pour les reprises.

Évitez de comparer deux modèles avec des entrées ou des critères différents. Si un modèle produit une réponse exploitable en une étape et un autre exige deux corrections, la comparaison pertinente porte sur le résultat accepté. Conservez le nombre de requêtes, les usages disponibles et le temps humain de vérification. Ce sont des mesures de votre propre essai, pas un classement universel.

Séparer entrée ordinaire, cache et sortie

Pour un tarif exprimé en dollars par million de tokens, le calcul textuel est : ((entrée totale − entrée en cache) × tarif entrée + entrée en cache × tarif cache + sortie × tarif sortie) / 1 000 000. L’entrée en cache est incluse dans l’entrée totale ; l’additionner une seconde fois surestime la quantité. Appliquer le tarif cache à une entrée dont le cache n’est pas confirmé la sous-estime.

Relevez les tarifs applicables au moment de l’opération. Le catalogue authentifié avec votre clé décrit votre accès ; un exemple public ne doit pas remplacer un tarif personnel. Les historiques peuvent conserver des conditions antérieures. Ne recalculez pas toutes les dépenses passées avec le tarif du jour et ne présentez pas une estimation locale comme une écriture comptable du service.

Faire un calcul local avant toute requête

Le programme ci-dessous utilise des tarifs purement illustratifs : 2 dollars pour l’entrée, 0,20 dollar pour le cache et 6 dollars pour la sortie, par million de tokens. Il ne choisit aucun modèle et ne contacte aucun serveur. Remplacez ces valeurs par les tarifs effectivement applicables. Avec 2 000 tokens d’entrée, dont 500 en cache, et 300 de sortie, le résultat de cet exemple est 0,0049 dollar.

Les nombres de tokens sont ici des hypothèses de planification. Le nombre de caractères ou de mots ne permet pas de connaître exactement la tokenisation d’un modèle. Après une requête terminée, comparez l’estimation à l’usage disponible. Si l’usage manque ou que l’issue reste inconnue, conservez cet état au lieu de fabriquer un total exact.

from decimal import Decimal

def estimate(total_in, cached_in, output, rate_in, rate_cache, rate_out):
    counts = (total_in, cached_in, output)
    if any(type(n) is not int or n < 0 for n in counts):
        raise ValueError("non-negative integer counts required")
    if cached_in > total_in:
        raise ValueError("cache exceeds total input")
    rates = tuple(Decimal(str(r)) for r in (rate_in, rate_cache, rate_out))
    if any(not r.is_finite() or r < 0 for r in rates):
        raise ValueError("finite non-negative rates required")
    a, b, c = rates
    return ((total_in - cached_in) * a + cached_in * b + output * c) / Decimal(1_000_000)

print(estimate(2000, 500, 300, "2", "0.20", "6"))

Ajouter les étapes annexes sans inventer une précision

Préparez un tableau par tâche : extraction, rédaction, contrôle, puis reprises décidées manuellement. Pour chaque ligne, indiquez un scénario courant et un scénario haut. Le second n’est pas une promesse de plafond : il exprime les hypothèses de votre application. Si une entrée est plus longue que prévu ou si le nombre d’étapes augmente, le budget doit être réévalué avant le prochain envoi.

Les images, les outils et les parcours en plusieurs appels ne se réduisent pas toujours à votre formule textuelle initiale. Dans le navigateur Dikaya, le texte des sources trouvées peut rejoindre le contexte de génération. Une transformation d’image ou une autre étape séparée doit également être prise en compte lorsqu’elle s’applique. Consultez les conditions actuelles plutôt que d’extrapoler un prix à partir d’une seule réponse courte.

• Lister toutes les requêtes prévues pour une tâche.
• Séparer hypothèse de tokens et usage constaté.
• Définir qui autorise une étape ou une reprise supplémentaire.
• Tester le scénario haut avec un serveur local avant de financer un traitement réel.

Ne pas confondre réserve, solde et dépense finale

Un système prépayé peut réserver des fonds avant la génération pour éviter de consommer un service sans budget disponible. Cette réserve n’est pas nécessairement la dépense finale. Une réponse comptabilisée, une annulation connue et une issue réseau inconnue n’ont pas le même traitement. Le bouton Arrêter ne signifie donc pas « tout est remboursé ».

Dans Dikaya, chat et API partagent le solde du compte. Ne créez pas votre budget en supposant deux portefeuilles indépendants. Les crédits promotionnels, budgets d’activation ou conditions personnelles ne doivent pas être reconstruits par une simple multiplication côté client. Pour une opération contestée, transmettez à l’assistance l’heure, le modèle et les informations utiles, jamais votre clé secrète.

Fixer un critère d’arrêt pour votre propre application

Avant un lot de documents, limitez le nombre de tâches autorisées et le nombre d’étapes par tâche. Faites contrôler le budget par le serveur de votre application, pas uniquement par un bouton désactivé dans le navigateur. Distinguez les opérations en attente des opérations confirmées pour ne pas libérer trop tôt un budget après une perte de connexion.

Commencez par quelques cas représentatifs dont vous pouvez lire le résultat intégral. Mesurez les écarts entre estimation et usage disponible, puis ajustez vos hypothèses. Un budget API utile est un mécanisme de décision : il vous dit quand poursuivre, quand demander une validation et quand enquêter sur une issue inconnue.

Questions et réponses

Puis-je déduire le coût exact du nombre de mots ?

Non. Les tokens dépendent du texte et du modèle ; les mots ne sont pas une unité de facturation exacte. Utilisez une estimation avant l’envoi et l’usage disponible après une réponse terminée. Gardez les images et les appels supplémentaires dans le budget global de la tâche.

Le cache est-il garanti pour une entrée répétée ?

Il ne faut pas le supposer. Le calcul doit utiliser la quantité effectivement reconnue comme mise en cache. Pour une estimation prudente, prévoyez le tarif ordinaire lorsque cette information est inconnue. Ne soustrayez pas une remise imaginaire à toutes les requêtes répétées.

Une limite de tokens suffit-elle à fixer ma dépense totale ?

Elle borne une partie de la requête, pas l’ensemble du parcours. L’entrée, les étapes séparées et les nouvelles tentatives comptent aussi. Définissez un budget par tâche dans votre application et contrôlez explicitement toute opération supplémentaire.

Sources

Contenu préparé avec l’aide de l’IA. Les exemples sont illustratifs, pas des réponses réelles ni des tests comparatifs. Les sources externes ne remplacent pas les conditions du service.

• Python : calcul décimal avec Decimal
  docs.python.org
• OpenAI Python : nouvelles tentatives automatiques
  github.com