Tokens et facturation de l'API de LLM : estimation, lecture, budget et exemples

Ce qu'est un token et comment le facturer

Le token est l'unité minimale de traitement du texte par le modèle ; ce n'est ni un caractère ni un mot, mais un « fragment » intermédiaire. Imaginez-le comme une graduation sur un compteur d'eau : plus vous utilisez, plus les graduations avancent vite. La facturation se divise en deux parties :

Notez que le prix des tokens de sortie est quatre fois celui des tokens d'entrée. Il est souvent plus économique de demander au modèle de « moins divaguer » que de « réduire le contexte », bien que les conversations accumulent l'historique et nécessitent une gestion des deux côtés. Le mode de paiement est un solde prépayé, non un abonnement ; le solde n'expire jamais. Les nouveaux comptes reçoivent un crédit d'essai gratuit de $0.50, valable 7 jours.

Précision importante : les tokens de sortie correspondent au nombre de tokens réellement générés par le modèle, et non à votre valeur max_tokens. max_tokens est juste un plafond ; si le modèle répond en 200 mots, vous ne payez que pour les tokens correspondants. Pour vos prévisions budgétaires, calculez sur le plafond pour couvrir les cas longs inattendus.

Estimation préalable : comment estimer grossièrement le chinois et l'anglais

Avant la requête, seule l'estimation est possible. Valeurs approximatives ci-dessous, variables selon le contenu :

L'usage correct de l'estimation est de faire une « estimation de l'ordre de grandeur » : cet article fait-il environ 10 000 ou 100 000 tokens ? Dépassera-t-il la fenêtre de contexte de 100 000 ? Combien coûtera une requête ? Pour être précis, lisez le champ usage. Une bonne pratique consiste à faire tourner des échantillons par scénario et à utiliser la moyenne de l'usage réel à la place des valeurs empiriques.

Exemple combinant estimation et mesure réelle. Supposons que vous traitiez des retours clients en chinois d'environ 2 000 caractères. En estimant à 1.3 token par caractère, une requête fait environ 2 600 tokens. Ajoutez 200 tokens pour l'instruction : l'entrée est d'environ 2 800 tokens. Exécutez 30 requêtes, lisez le champ usage et prenez la moyenne. Si la moyenne mesurée est de 2 500, ajustez votre coefficient à environ 1.15. Utilisez ce coefficient corrigé pour le budget du lot entier pour réduire l'erreur. Ces chiffres servent d'hypothèse de méthode ; vos données auront leurs propres valeurs.

Lire usage : la vraie « lecture de compteur »

Chaque réponse réussie inclut usage avec prompt_tokens, completion_tokens et total_tokens. Le streaming n'a pas besoin de paramètres supplémentaires ; un bloc de données contenant usage est ajouté automatiquement à la fin. Le code ci-dessous montre comment lire les deux modes et convertir les lectures en dollars :

复制import os
from openai import OpenAI

client = OpenAI(base_url="https://api.apidamoxing.com/v1", api_key=os.environ["API_KEY"])
PRICE_IN, PRICE_OUT = 0.25, 1.00     # 美元 / 百万 token

def cost(u):
    return (u.prompt_tokens * PRICE_IN + u.completion_tokens * PRICE_OUT) / 1_000_000

# 非流式：usage 在响应对象上
r = client.chat.completions.create(
    model="uncensored", max_tokens=200,
    messages=[{"role": "user", "content": "用三句话解释什么是通货膨胀。"}],
)
print(r.usage.prompt_tokens, r.usage.completion_tokens, f"${cost(r.usage):.6f}")

# 流式：最后一个数据块带 usage，其余块的 usage 为空
usage_last = None
stream = client.chat.completions.create(
    model="uncensored", max_tokens=200, stream=True,
    messages=[{"role": "user", "content": "再用三句话解释什么是通货紧缩。"}],
)
for chunk in stream:
    if chunk.usage:
        usage_last = chunk.usage
    if chunk.choices and chunk.choices[0].delta.content:
        print(chunk.choices[0].delta.content, end="", flush=True)
print()
if usage_last:
    print(usage_last.prompt_tokens, usage_last.completion_tokens, f"${cost(usage_last):.6f}")

En streaming, seul le dernier bloc contient usage ; les précédents sont vides. Utilisez if chunk.usage pour vérifier. Notez chaque lecture dans les logs ou la base de données pour la facturation mensuelle, le débogage et le calcul du coût par utilisateur.

Autre bonne pratique : étiquetez chaque fonctionnalité métier et notez les coûts par étiquette. Par exemple, séparez « résumé », « service client » et « traduction ». En fin de mois, vous saurez quelle fonction coûte le plus et si vous devez optimiser le prompt, tronquer l'historique ou baisser max_tokens. Sans étiquettes, un total unique rend l'optimisation difficile.

Trois exemples (les hypothèses sont précisées)

Exemple 1 : Réponses aux questions du service client

Hypothèse : 800 tokens en entrée par requête (incluant le prompt système et les extraits de connaissances), 200 tokens en sortie ; 10 000 requêtes par jour.

Coût unique : 800 × 0,25 ÷ 1 000 000 = $0,0002 ; sortie 200 × 1,00 ÷ 1 000 000 = $0,0002 ; total $0,0004. 4,00 $ par jour, 120 $ sur 30 jours. Avec ce rythme, le crédit d'essai gratuit de $0.50 soutient environ 1 250 appels de ce type.

Exemple 2 : Résumé d'articles longs

Hypothèse : 20 000 tokens en entrée par article, 600 tokens en sortie pour le résumé ; 500 articles au total.

Par article : 20 000 × 0,25 $ ÷ 1 000 000 = 0,005 $, plus 600 × 1,00 $ ÷ 1 000 000 = 0,0006 $, total 0,0056 $. 500 articles coûtent 2,80 $. Il est clair que les tâches avec une entrée longue et une sortie courte sont peu coûteuses.

Exemple 3 : Conversations multi-tours et réduction de l'historique

Hypothèse : 100 tokens pour le prompt système ; 60 tokens d'entrée utilisateur par tour, 150 tokens de réponse ; 20 tours par conversation.

L'entrée du plan « historique complet » est : 20 × (100 + 60) + 210 × (0 + 1 + … + 19) = 3 200 + 39 900 = 43 100. Les trois premières étapes du plan « élagué » sont 160, 370 et 580 ; les étapes 4 à 20 sont de 790 chacune, soit un total de 14 540. Le coût est divisé par deux environ, et l'écart s'agrandit avec le nombre d'étapes, car l'entrée du plan « historique complet » croît au carré du nombre d'étapes.

Ces trois exemples permettent de dégager une formule empirique : le coût est principalement déterminé par le « nombre de requêtes × volume d'entrée/sortie par requête », et dans le volume d'entrée, l'historique et les documents joints sont les leviers les plus efficaces. Réduire la taille des extraits de connaissances dans le scénario client, tronquer l'historique dans les conversations, ou traiter par blocs en parallèle dans le scénario de résumé, relèvent tous du même principe : ne pas payer pour des tokens inutiles. Il est important de noter que les chiffres de ces exemples proviennent exclusivement des hypothèses indiquées ci-dessus ; vos données réelles doivent être vérifiées via l'usage.

Considérons un calcul inverse : si votre budget mensuel est de 30 $ et que vous souhaitez savoir combien de conversations de 20 itérations votre produit de chat peut supporter par mois. Avec le plan « seules les 3 dernières itérations » de l'exemple 3, chaque conversation coûte environ 0,0066 $, soit 30 $ ÷ 0,0066 ≈ 4 545 conversations. Avec le même budget, le plan « historique complet » coûte 0,0138 $ par conversation, ce qui permet seulement environ 2 174 conversations. C'est la différence concrète apportée par l'élagage de l'historique.

Contrôle du budget : installer des vannes dans votre programme

L'estimation n'est qu'une prédiction, les vannes sont une assurance. Voici une classe de budget journalier comptabilisé en dollars : prévision du « pire cas » avant la requête (sortie utilisant le max_tokens), et comptabilisation réelle après la requête.

复制class Budget:
    """按美元计的日预算。超出时拒绝新请求。"""
    def __init__(self, daily_usd):
        self.limit = daily_usd
        self.spent = 0.0

    def check(self, est_prompt_tokens, max_tokens):
        # 最坏情况：输出用满 max_tokens
        worst = (est_prompt_tokens * 0.25 + max_tokens * 1.00) / 1_000_000
        if self.spent + worst > self.limit:
            raise RuntimeError(f"预算不足：已用 ${self.spent:.4f}，本次最坏 ${worst:.4f}，上限 ${self.limit}")

    def record(self, usage):
        self.spent += (usage.prompt_tokens * 0.25 + usage.completion_tokens * 1.00) / 1_000_000

budget = Budget(daily_usd=5.0)
budget.check(est_prompt_tokens=1200, max_tokens=500)   # 请求前
# ……发请求……
# budget.record(response.usage)                        # 请求后

Outre les vannes dans le programme, il existe trois leviers au niveau de la configuration :

1. Définissez max_tokens en fonction de la tâche, ne le mettez pas systématiquement au maximum (par défaut 2048, maximum 32 000) ;
2. Définissez une limite de longueur pour l'historique des conversations, voir la méthode dans Création d'un chatbot ;
3. Ne rechargez sur votre compte que le montant que vous prévoyez d'utiliser, et rechargez ensuite si nécessaire ; le mode prépayé constitue naturellement un plafond dur.

Les tarifs et les règles de solde sont ceux de la page des prix, les détails de l'interface se trouvent dans Détail des paramètres.

Résumons cela sous forme de liste de contrôle : avant, estimer l'ampleur, définir max_tokens, vérifier la longueur de l'historique ; pendant, surveiller l'usage du dernier bloc lors du streaming ; après, comptabiliser, regrouper par fonctionnalité et comparer au budget. En trois étapes, la facture est claire.