Méthodologie des tokens IA

Le compteur de tokens estime combien de tokens un texte utilisera pour une API de grand modèle de langage donné, et multiplie par les tarifs publiés actuels pour estimer le coût. Les deux parties de cette phrase ont des limites de précision significatives.

Estimation des tokens : heuristique, pas exacte

Chaque LLM moderne utilise un tokeniseur — généralement BPE (Byte Pair Encoding) pour GPT et Claude, SentencePiece pour Gemini et Llama — qui convertit le texte en une séquence d’identifiants de tokens entiers. Le mappage exact est spécifique au modèle et propriétaire ; l’exécution du tokeniseur réel nécessite le fichier de modèle de tokeniseur (généralement 1-5 Mo) intégré dans le client.

Nous n’intégrons pas les tokeniseurs parce qu’ils se mettent à jour avec les sorties de modèles et la taille du bundle s’accumule sur 4+ fournisseurs. Nous utilisons plutôt les ratios caractères/token publiés dans la documentation de chaque fournisseur :

• GPT-3.5/4/5 : ~4 chars par token pour l’anglais ; plus pour le code ; moins pour les scripts non latins.
• Claude 3/4 : ~3,5 chars par token. Le tokeniseur Claude est légèrement plus agressif que celui de GPT.
• Gemini : ~4 chars par token pour l’anglais.
• Llama 3/4 : ~4 chars par token.

Ces ratios sont à ~10 % du vrai comptage de tokens pour la prose anglaise typique. Ils dévient davantage pour le code (qui se tokenise en plus de morceaux à cause des divisions d’identifiants), les scripts non latins (chinois, japonais, arabe — parfois 2-3× plus de tokens par caractère) et les données structurées (JSON, XML — quelque part entre l’anglais et le code).

Tarification : exacte mais périmée

Chaque modèle a une tarification publiée par token pour l’entrée et (séparément) pour les tokens de sortie. Nous codons ces prix en dur dans un registre que nous actualisons manuellement quand les fournisseurs mettent à jour leurs tarifs (généralement tous les 1 à 3 mois à mesure que de nouveaux modèles arrivent et que les anciens sont retarifés).

Les tarifs dans le registre sont corrects à partir du déploiement le plus récent. Pour la prévision réelle des coûts en production, vérifiez contre la page tarifaire du fournisseur — et prévoyez 15-30 % de marge car le coût réel dépend de la longueur de sortie, qui est non déterministe.

Ce que nous modélisons

Pour chaque modèle, le calculateur estime :

• Tokens d’entrée (depuis l’invite de l’utilisateur).
• Tokens de sortie (depuis une estimation fournie par l’utilisateur ou une valeur par défaut du fournisseur).
• Coût = tokens_entrée × prix_entrée + tokens_sortie × prix_sortie.
• Le total en USD avec 6 décimales.

Ce que nous ne modélisons pas

• Tarification des entrées mises en cache. Plusieurs fournisseurs (OpenAI, Anthropic) offrent des tarifs réduits pour les tokens d’entrée qui correspondent à un préfixe d’invite récemment vu. À connaître ; non modélisé ici.
• Remises API par lot. Les points de terminaison de batch asynchrones offrent souvent 50 % de réduction ; non modélisé.
• Entrées image/audio/vidéo. Les coûts de tokens multimodaux varient selon le modèle et sont calculés différemment du texte. Dans la feuille de route.
• Tarification des modèles affinés. Les fournisseurs tarifent les modèles affinés différemment des modèles de base.

Détails de l’algorithme : la boucle de fusion BPE

Les tokeniseurs GPT et Claude sont tous deux des variantes de Byte Pair Encoding. La procédure d’entraînement (Sennrich et al., 2016) part d’un vocabulaire de base d’octets individuels et applique répétitivement la fusion :trouver la paire adjacente la plus fréquente (a, b) dans le corpus, ajouter un nouveau token “ab” au vocabulaire, remplacer chaque occurrence de (a, b) par celui-ci. La procédure s’arrête quand le vocabulaire atteint la taille cible — 100 277 pour le cl100k_basede GPT-4o, ~128k pour Llama 3, ~256k pour Gemini. Au moment de l’inférence, le tokeniseur applique avidement la liste de fusions sauvegardée à l’entrée.

Notre heuristique de ratio de caractères ignore complètement la boucle de fusion. Pour un texte de N caractères et un ratio moyen observé tokens-par-caractère r : tokens ≈ ⌈N × r⌉. Les constantes que nous utilisons :

Calcul du coût : étant donné les tokens d’entrée T_in, les tokens de sortie T_out, et les tarifs par million de tokens du fournisseur p_in et p_out, coût total en USD = (T_in × p_in + T_out × p_out) / 1 000 000. Nous arrondissons à six décimales pour préserver la précision inférieure au centime pour les courtes invites.

Sources & références

Les heuristiques de cette page sont calibrées contre le tokeniseur de référence tiktoken d’OpenAI sur un corpus de 100k échantillons de Wikipédia en anglais. L’algorithme BPE est documenté dans Sennrich, Haddow & Birch (2016) ; SentencePiece, utilisé par Gemini et Llama, dans Kudo & Richardson (2018). Voir le bloc Sources & références ci-dessous pour les citations primaires et les pages tarifaires des fournisseurs que nous reproduisons.

Hypothèses & limites

• Calibrage uniquement sur la prose anglaise. Les constantes tokens-par-caractère sont ajustées sur le texte de Wikipédia en anglais. Le code, JSON, chinois, japonais, arabe et autres scripts non latins peuvent dévier de 30 à 300 % (le chinois utilise typiquement 2-3× plus de tokens par caractère).
• Aucun support pour la tarification des entrées mises en cache. OpenAI et Anthropic offrent tous deux des remises de 50 à 90 % sur les tokens de préfixe réutilisés. L’estimation de coût utilise la tarification complète non mise en cache.
• Aucune remise API par lot. Les points de terminaison de batch asynchrones divisent généralement le coût par token par deux ; non reflété ici.
• La longueur de sortie est fournie par l’utilisateur. Nous ne pouvons pas prédire la longueur de la réponse ; ±50 % sur T_outest typique selon l’invite.
• Entrées visuelles et audio non modélisées. Chaque fournisseur compte les tokens non textuels différemment (tuiles d’image pour GPT-4o, secondes audio pour Gemini, etc.).
• La tarification est un instantané. Le registre se met à jour mensuellement ; les changements de prix des fournisseurs en cours de mois ne sont pas reflétés avant le prochain déploiement.
• Les tarifs des modèles affinés et à capacité réservée diffèrent.L’estimation utilise uniquement les tarifs à la demande standard.

Quelle est vraiment la précision de l’estimation ?

Pour la prose anglaise typique à longueur modeste (50 à 5000 caractères), notre comptage de tokens est à moins de 10 % du vrai comptage et notre estimation de coût est à moins de 10-15 % de la facture API réelle. C’est largement suffisant pour un dimensionnement approximatif — “cette invite coûte-t-elle 1 centime ou 1 dollar ?” — et insuffisant pour une facturation précise au centime. Pour ce dernier cas, utilisez le tokeniseur officiel du fournisseur ; pour tout le reste, le nôtre est une vérification utile.