Chaque modèle d'IA que vous payez compte votre texte en jetons. La grille tarifaire s'exprime par million de jetons, la fenêtre de contexte (la quantité maximale de texte qu'un modèle peut traiter en un seul appel) est un nombre de jetons, et la taille des chunks dans votre recherche documentaire (la taille des morceaux en lesquels vos documents sont découpés) se règle en jetons. Aucun de ces éléments n'est une quantité fixe de texte. Un jeton, c'est ce que le tokeniseur (tokenizer) du modèle a décidé qu'il était, soit un programme distinct que le concepteur du modèle a entraîné une seule fois, avant le modèle lui-même. Personne dans votre entreprise ne l'a choisi, et il détermine ce que votre budget achète.
Ce qu'est un jeton de LLM, et pourquoi on vous facture en jetons.
Un grand modèle de langage (LLM) ne lit ni lettres ni mots. Il lit une suite de symboles numérotés, tirés d'un vocabulaire fixe, et quelque chose doit d'abord transformer votre texte en ces nombres. Ce quelque chose, c'est le tokeniseur. Il est entraîné séparément du modèle, sur son propre corpus de texte, avec sa propre méthode, et, dans la plupart des modèles actuels, cette méthode est l'encodage par paires d'octets (byte-pair encoding, BPE). Le concepteur du modèle choisit le tokeniseur tôt, le fige, puis entraîne le modèle sur cette base.
En pratique, un jeton est un court morceau de texte : souvent un mot courant en entier, parfois un fragment d'un mot plus long ou plus rare, quelques chiffres ou un signe de ponctuation. Une fois le tokeniseur figé, tous les chiffres qu'un gestionnaire suit se comptent dans ce qu'il produit.
Combien de texte représente un jeton ? Cela dépend du tokeniseur et du texte. Sur les données d'entraînement de la prépublication sur laquelle s'appuie cette note, un jeton valait en moyenne environ 4,5 octets (dans un texte ordinaire sans accents, un octet équivaut à un caractère), que les auteurs utilisent comme constante de travail pour ces données.[1] C'est une moyenne pour un mélange précis, pas une loi. Le code, les tableaux, les noms, les nombres et les autres langues se découpent chacun à leur propre rythme, ce qui explique qu'un budget écrit en jetons ne se transpose pas tel quel d'un type de contenu à un autre.
La grille tarifaire ne montre qu'un des deux nombres.
La conséquence pratique se fait sentir quand vous comparez des fournisseurs. Un modèle dont le prix par million de jetons est plus bas n'est moins cher pour vous que si son tokeniseur découpe votre texte en un nombre de jetons similaire. S'il découpe la même page en plus de morceaux, une partie du rabais disparaît avant le premier appel, et la grille tarifaire ne le montrera jamais. Notre note qui vous invite à refaire vos calculs de modèles plaide pour recalculer les coûts quand les prix bougent; le tokeniseur est une donnée de plus dans ce recalcul, et une donnée facile à oublier.
Pourquoi le français est la question ouverte.
L'encodage par paires d'octets construit son vocabulaire à partir du texte sur lequel le tokeniseur a été entraîné : il part de caractères isolés et fusionne à répétition les paires les plus fréquentes, de sorte que les chaînes courantes dans ce texte deviennent des jetons uniques et que les chaînes plus rares sont découpées en plusieurs morceaux. Ce qui compte comme courant dépend entièrement de ce que contenait le texte d'entraînement.
C'est pourquoi cette note existe pour une entreprise québécoise. Si le texte d'entraînement d'un tokeniseur contenait moins de français que d'anglais, une page en français aura tendance à se découper en plus de jetons que sa jumelle anglaise, et un budget de jetons établi sur du contenu anglais achètera moins de texte français qu'il n'y paraît. Le sens de l'écart découle du mécanisme. Son ampleur, non.
Mesurez-le sur votre propre contenu.
Vous n'avez besoin ni de nous ni de personne d'autre pour publier un ratio. Le modèle que vous payez déjà vous le dira, un appel à la fois : les réponses de l'API indiquent combien de jetons d'entrée et de sortie chaque appel a utilisés. Un petit échantillon suffit pour remplacer une règle du pouce par votre propre chiffre.
- Choisissez un échantillon de contenu réel dans chaque langue où vous servez votre clientèle.
Utilisez les pages, les courriels et les documents que vous envoyez réellement au modèle, pas des phrases de test. Si vous publiez dans les deux langues, prenez les mêmes pages en anglais et en français, de sorte que le contenu reste constant et que seule la langue change.
- Comptez les jetons avec le modèle que vous utilisez.
Faites passer chaque élément par le même modèle avec la même courte consigne, et notez le nombre de jetons d'entrée que la réponse rapporte. Envoyez ensuite la consigne seule et soustrayez son décompte, afin que vos instructions ne soient pas comptées comme du contenu. Pour mesurer la sortie, demandez la même réponse dans chaque langue et notez le nombre de jetons de sortie. Ne reprenez pas le décompte du tokeniseur d'un autre fournisseur : il mesure une autre unité.
- Divisez par quelque chose que vous contrôlez.
Gardez deux nombres par langue. Les jetons par page, mesurés sur les mêmes pages dans les deux langues, indiquent ce que coûte le traitement de ce contenu. Les jetons par millier de caractères convertissent la longueur d'un document en budget de contexte ou de chunk avant de l'envoyer. Une prévision mensuelle est alors pages par mois × jetons par page × prix par jeton, calculée séparément pour l'entrée et pour la sortie. Ces nombres, et non une conversion lue en ligne, sont ce que vos budgets de contexte, vos tailles de chunks et vos prévisions de coûts devraient utiliser.
cible : jetons par page et par millier de caractères, par langue, par modèle - Recommencez quand vous changez de modèle.
Une nouvelle famille de modèles apporte habituellement un nouveau tokeniseur, et un nouveau tokeniseur donne un décompte différent pour la même page. Ces nombres appartiennent à un couple : votre contenu et le tokeniseur du fournisseur.
Si vous faites rouler une recherche documentaire, la même mesure s'applique à vos chunks. Un chunk de 512 jetons ne contient pas la même quantité de texte en français qu'en anglais, alors la taille de chunk que vous avez réglée dans une langue n'est pas automatiquement la bonne pour l'autre. Notre note sur le chunking explique comment la régler; réglez-la par langue si votre corpus est bilingue.
Les décomptes de jetons ne voyagent pas d'un modèle à l'autre.
Comme le tokeniseur est une étape distincte et figée, il décide aussi quels modèles peuvent travailler ensemble, souvent plus que ne le fait leur qualité. Deux techniques le montrent.
La distillation, qui consiste à entraîner un petit modèle à imiter un grand, transmet normalement au petit modèle la prédiction du grand sur son vocabulaire, de sorte que les deux doivent partager ce vocabulaire. Lever cette hypothèse demande un outillage supplémentaire, ce que la prépublication sur laquelle nous nous appuyons cherche justement à construire.[1]
Le décodage spéculatif, une façon courante d'accélérer les réponses d'un grand modèle, fait rédiger quelques jetons d'avance par un petit modèle, puis le grand modèle les vérifie. Le texte explicatif que nous citons énonce la contrainte sans détour :
En français : la compatibilité des tokeniseurs contraint le jumelage plus étroitement que la qualité des modèles. Un petit modèle plus performant, mais doté d'un vocabulaire différent, est inutilisable comme source de brouillon sans outillage supplémentaire.
La plupart des entreprises ne touchent à aucune de ces deux techniques. La version qui les rejoint est plus simple : chaque limite que vous avez écrite en jetons est liée à un seul tokeniseur. Changez de fournisseur ou de famille de modèles, et les tailles de chunks, les budgets de contexte, les plafonds par appel et les quotas mensuels de jetons sont tous à remesurer, puisque les mêmes documents produisent maintenant des décomptes différents. Traitez un changement de modèle comme un changement d'unité, pas seulement comme un changement de prix.
La taille du vocabulaire est aussi une facture.
La taille du vocabulaire d'un tokeniseur se paie en paramètres et en stockage, et la prépublication sur laquelle nous nous appuyons chiffre les deux, calculs à l'appui.[1] Cette section compte surtout pour les équipes qui entraînent ou distillent des modèles; pour tous les autres, elle explique pourquoi les choix de vocabulaire sont faits par ceux qui en paient le prix.
vocabulaire ≈ 100 k
≈ 260 symboles
Deux choses dans la figure relèvent de l'arithmétique plutôt que de résultats, et c'est ce qui les rend dignes d'être répétées. Avec environ 1,28 milliard de paramètres dans les couches du modèle, un vocabulaire d'environ 100 000 jetons en ajoute à peu près un demi-milliard de plus, seulement pour convertir les jetons à l'entrée et à la sortie. Et conserver les prédictions complètes d'un modèle enseignant pour une distillation hors ligne est impraticable à cette taille de vocabulaire, c'est pourquoi les équipes les tronquent aux quelques centaines de meilleurs scores; un vocabulaire d'octets n'exige aucune troncature.
Les modèles qui se passent du tokeniseur et lisent des octets bruts forment une piste de recherche active. Les données à leur sujet ne sont pas prêtes pour un budget : les comparaisons phares de la prépublication sont asymptotiques, soit les limites de courbes ajustées plutôt que les scores de modèles entraînés, et les auteurs affirment que leurs modèles à octets « remain significantly expensive at inference time » (en anglais dans l'original; autrement dit, ils demeurent nettement coûteux au moment de l'inférence), parce qu'ils émettent plusieurs symboles pour chaque jeton qu'émet un modèle à jetons.[1] Pour l'instant, ils ne changent rien à un budget.
La leçon la plus utile de la prépublication pour un gestionnaire est une leçon négative. Ses modèles à octets battent le modèle à jetons sur la perte de validation, la courbe que les chercheurs surveillent pendant l'entraînement, tout en obtenant de moins bons résultats aux tests de référence en aval.[1] Une métrique de substitution peu coûteuse et continue a cessé de suivre la qualité dès que les modèles comparés étaient tokenisés différemment. La même défaillance apparaît chaque fois qu'on compare un score commode entre des choses de structure différente, ce qui est l'argument de notre note sur les juges IA : vérifiez la métrique de substitution contre le résultat réel avant de vous y fier d'un contexte à l'autre.
Ce que cette note ne prétend pas.
Aucun ratio français-anglais. Le mécanisme dit que le français peut coûter plus de jetons avec des tokeniseurs entraînés surtout sur de l'anglais. Nous n'avons pas mesuré de combien, sur quels modèles ni pour quel contenu. Une mesure sur notre propre corpus en français est prévue; d'ici là, le chiffre obtenu avec la méthode ci-dessus est le seul qui mérite votre confiance.
Une seule source universitaire, non vérifiée par nous. Les chiffres de paramètres et de stockage viennent d'une seule prépublication, dont les chiffres sont ceux des auteurs. Ce sont des calculs sur des tailles de vocabulaire, d'où notre choix de les utiliser, et nous ne reprenons pas ses résultats phares de précision, qui sont asymptotiques.
Nous n'entraînons rien. Acceleratech bâtit ses solutions sur des modèles hébergés et à poids ouverts; nous ne les entraînons ni ne les distillons. La section sur le vocabulaire explique l'économie de ceux qui le font, parce que leurs choix deviennent votre unité.
Si votre équipe budgétise des travaux d'IA dans deux langues, ou compare des fournisseurs sur le prix, le formulaire de contact est la voie la plus rapide. Dites-nous ce que vous faites rouler, et nous vous enverrons gratuitement un avis écrit sur l'origine réelle de vos coûts en jetons.