Combien coûtent réellement les jetons LLM et comment en payer moins
Chaque facture d'API pour un modèle de langage est une facture pour des jetons, et presque personne n'a l'intuition du nombre de jetons que représente un morceau de texte donné. Le résultat est la même surprise deux fois par mois : une fonctionnalité qui semblait bon marché lors des tests coûte quarante fois plus cher en production, ou une fenêtre contextuelle qui « devrait s'adapter » rejette la demande. Les deux sont des problèmes arithmétiques, et l’arithmétique vaut la peine d’être apprise une fois.
Un jeton n'est pas un mot
Les modèles ne lisent ni les caractères ni les mots. Ils lisent des jetons, des morceaux produits par un encodeur de paires d'octets qui a appris, au cours de l'entraînement, quelles séquences se produisent suffisamment souvent pour mériter leur propre symbole. Les mots anglais courants en sont un signe. Les rares se sont divisés. Donc token est un et tokenization est trois, alors qu'une chaîne aléatoire comme x7Qp2 peut coûter cinq.
Les règles empiriques à suivre :
- Prose anglaise : environ quatre caractères par jeton, soit environ 0,75 jeton par mot. Un article de mille mots représente environ 1 300 jetons.
- Code: considérablement pire. L'indentation, la ponctuation et les identifiants camelCase sont tous fragmentés. Prévoyez un budget plus proche de trois caractères par jeton et traitez le code minifié comme son propre désastre – il est mal symbolisé précisément parce qu'il est inhabituel.
- Écritures non latines : encore pire. Le chinois, le japonais et le coréen génèrent généralement près d'un jeton pour un ou deux caractères, de sorte que le même contenu en japonais peut coûter plusieurs fois ce que coûte la version anglaise. Le cyrillique et le grec se situent entre les deux.
- JSON : la ponctuation est de l'argent réel. Chaque guillemet, accolade, deux-points et virgule constitue au moins une partie d'un jeton, et les structures profondément imbriquées avec des noms de clé longs peuvent dépenser plus en syntaxe qu'en valeurs.
Les règles empiriques servent à l’estimation. Quand c'est important, comptez : le Jeton LLM et calculateur de coûts symbolise ce que vous collez et imprime le décompte, et il peut également afficher le texte avec les limites des jetons marquées, ce qui est le moyen le plus rapide de comprendre pourquoi l'une de vos invites est étonnamment chère. Voir vos propres noms d’identifiant se briser en quatre morceaux chacun explique beaucoup de choses.
La production coûte plusieurs fois plus que l’entrée
Le détail des prix manque aux gens : les fournisseurs facturent séparément les jetons que vous envoyez et les jetons générés par le modèle, et le débit est généralement quatre à huit fois supérieur au débit d'entrée. Une invite avec 10 000 jetons de contexte et une réponse de 200 jetons est dominée par l'entrée. Une invite contenant 500 jetons d'instruction qui produit un essai de 4 000 jetons est dominée – fortement – par le résultat.
Cela inverse de nombreux instincts d’optimisation. Réduire une invite système de 900 à 600 jetons permet d'économiser très peu si le modèle écrit de longues réponses à chaque appel. Dire au modèle de répondre en trois phrases au lieu de trois paragraphes permet d'économiser beaucoup. Demandez-vous sur quel côté de la transaction repose réellement votre charge de travail avant d’optimiser le mauvais.
La calculatrice évalue le même texte pour chaque modèle de son tableau aux taux d'entrée et de sortie, de sorte que vous pouvez comparer un modèle bon marché faisant tout le travail à un modèle coûteux qui en fait une partie. Les prix de référence sont stockés localement et vérifiés périodiquement par rapport aux pages du fournisseur. Considérez-les comme une aide à la planification et confirmez-les par rapport à la propre page de tarification du fournisseur avant de vous engager sur un budget, car les tarifs évoluent.
Le chat est quadratique, et c'est là que les budgets meurent
Un appel API unique coûte ce qu’il coûte. Une conversation renvoie l'historique complet à chaque tour, donc une conversation de vingt tours ne coûte pas vingt fois un tour - elle coûte à peu près la somme d'une série croissante. Le vingtième tour paie à nouveau les tours un à dix-neuf.
Deux conséquences. Premièrement, les boucles d’agents de longue durée constituent la forme d’utilisation du LLM la plus coûteuse et la plus susceptible d’être prototypée sans mesure. Deuxièmement, la mise en cache des invites est plus importante que tout changement de formulation : les fournisseurs réduisent les jetons qui répètent un préfixe qu'ils ont déjà vu, ce qui signifie placer votre contenu stable - l'invite système, le schéma, les exemples - au tout début et la partie variable à la fin. Réorganisez la même invite de sorte qu'un horodatage changeant se trouve en haut et que vous ayez invalidé le cache à chaque appel sans rien changer d'autre.
Réduire une invite avant de l'envoyer
La plupart des invites surdimensionnées le sont pour des raisons ennuyeuses : quelqu'un a collé un fichier entier alors que trois fonctions étaient pertinentes, et le fichier est constitué de moitié de commentaires et de lignes vides. Le Compresseur de contexte LLM cible exactement cela : il supprime les commentaires de code, réduit les séries de lignes vides, enfonce et supprime les mots de remplissage de la prose, puis indique le nombre de jetons enregistrés par la garniture. Sur un fichier source réel qui exécute régulièrement 20 à 40 % sans toucher à ce dont le modèle a besoin.
Les coupes manuelles qui valent la peine d'être faites avant cela :
- Envoyez des extraits, pas des fichiers. L’attention des modèles n’est pas non plus gratuite ; un contexte non pertinent dégrade considérablement les réponses et coûte de l’argent.
- Supprimez les journaux de la région défaillante. Dix mille lignes de résultats de démarrage réussis ne contribuent en rien à un diagnostic.
- Abandonnez le passe-partout répété. En-têtes de licence, importations générées, même clause de non-responsabilité sur chaque enregistrement.
- Résumez au lieu de renvoyer. Dans une longue conversation, remplacer les tours un à quinze par un paragraphe d’état constitue la plus grande économie disponible.
Lorsque l’entrée ne correspond vraiment pas
Les fenêtres contextuelles sont désormais grandes, mais « grandes » est toujours limitée, et un livre, une année de journaux ou une transcription complète en dépassera une. Le fractionnement est la réponse standard, et l'endroit où vous divisez compte : couper au milieu d'une phrase ou au milieu d'une fonction produit des morceaux que le modèle doit deviner. Le diviseur rapide divise le texte en morceaux d'une taille que vous choisissez tout en respectant les limites, et numérote les parties afin que vous puissiez les alimenter en séquence avec une instruction cohérente attachée à chacune.
Une note sur les unités : les jetons ne sont pas des octets. Le Compteur d'octets UTF-8 répond à une question différente – combien d'espace le texte occupe sur le fil ou dans une colonne de base de données – et les deux nombres divergent fortement pour le texte non latin, où les octets par caractère augmentent en même temps que les caractères par jeton diminuent. Utilisez des octets pour les limites de stockage et des jetons pour les limites du modèle, et ne remplacez jamais l'un par l'autre.
Un exemple concret
Supposons que vous répondiez à vingt questions sur un document de trente pages. Trente pages représentent environ 15 000 mots, soit environ 20 000 jetons. Naïvement, vous envoyez le document avec chaque question : 20 × 20 000 = 400 000 jetons d'entrée, plus peut-être 20 × 300 jetons de sortie.
Placez le document en premier et conservez-le en octets identiques lors des appels, et la plupart des fournisseurs diffusent le préfixe répété du cache à une fraction du tarif. Coupez d'abord le document en passe-partout et la base rétrécit également. Lot de cinq questions par appel au lieu d'une et vous envoyez le document quatre fois au lieu de vingt. La même tâche, le même modèle, et un ordre de grandeur entre la version imprudente et la version prudente — c'est tout l'intérêt de compter avant d'envoyer.
Le compteur et le compresseur fonctionnent entièrement dans votre navigateur : l'invite que vous évaluez n'est téléchargée nulle part pour être mesurée.
Créateur de TextArray : création d'outils gratuits axés sur la confidentialité qui s'exécutent entièrement dans votre navigateur.