Tokenisation : éviter les erreurs de comptage

Le nombre de jetons influe sur les limites de contexte, la latence et le coût, sans être leur seul déterminant. Un jeton est une unité du vocabulaire du modèle, pas nécessairement un mot ou un caractère entier. Utilisez le tokeniseur et la révision du déploiement, et distinguez une estimation locale du texte de l’utilisation de la requête complète côté serveur.

Consignez le modèle, le tokeniseur et le format de requête utilisés par l’application. Vérifiez les estimations et l’utilisation observée avec des entrées représentatives.

Essayer Compute : lancez un point de terminaison vLLM sur Compute. Choisissez le modèle utilisé en production et mesurez les jetons d’entrée et de sortie avec le streaming activé. Conservez le point de terminaison dans la région choisie et définissez une limite de sortie adaptée pour chaque route.

Présentation de la tokenisation

La tokenisation est au cœur du fonctionnement des modèles linguistiques. Lorsque vous envoyez du texte à un modèle, celui-ci ne peut pas lire les mots comme vous le faites. Il doit d'abord diviser votre saisie en éléments plus petits appelés jetons. Considérez la tokenisation comme le pont entre le langage humain et ce que la machine peut réellement traiter. Ces jetons peuvent être des mots entiers, des parties de mots ou même des caractères uniques, selon la configuration du système.

BPE et WordPiece sont des algorithmes de tokenisation. SentencePiece est une boîte à outils qui prend en charge BPE et les modèles unigrammes, pas un algorithme opposé à BPE. Le vocabulaire, la normalisation et les jetons spéciaux influent aussi sur le résultat ; utilisez le tokeniseur fourni pour le modèle préentraîné.

Comprendre comment le texte devient des jetons aide à examiner les comptes inattendus et à définir les budgets des requêtes. Cela ne garantit pas à lui seul de meilleures invites ni la réponse souhaitée.

Pourquoi le nombre de jetons dérive

• Différents tokeniseurs. Deux tokeniseurs peuvent produire des comptes différents même s’ils utilisent tous deux BPE. Relevez le modèle, la révision du tokeniseur, le vocabulaire et la configuration, sans les déduire du seul nom de la famille de modèles.
• Caractères invisibles. Les espaces insécables (NBSP), les caractères de liaison sans chasse, les guillemets typographiques et les fins de ligne mixtes peuvent modifier le nombre de jetons.
• Assemblage des invites. Les clients peuvent dupliquer ou reformater les instructions système et les exemples. L’assemblage des composants peut donc modifier le nombre de jetons.
• Sérialisation de la requête. Les rôles des messages, les définitions d’outils et les autres éléments structurés peuvent contribuer au nombre de jetons. Leur mise en forme peut se faire côté client ou serveur ; compter le texte visible de l’invite ne couvre pas toute la requête.
• Particularités linguistiques. Mots composés en allemand ou en néerlandais, signes diacritiques en français ou en espagnol, clitiques en arabe ou en espagnol, segmentation du chinois, du japonais et du coréen : ces caractéristiques peuvent modifier le nombre de jetons.

Pièges courants et solutions rapides

Différences entre les modèles et les SDK

• Vérifiez la génération exacte du modèle. Llama 3 utilise un tokeniseur BPE fondé sur tiktoken. La règle « GPT utilise BPE, Llama utilise SentencePiece » n’est donc pas fiable. Consultez les fichiers et la configuration du tokeniseur du modèle.
• Modèles de conversation. Utilisez le chat template attendu par le modèle déployé. Si vous le rendez localement, évitez d’ajouter ses jetons spéciaux une seconde fois. Une invite brute et des messages structurés ne constituent pas nécessairement la même entrée.
• Séquences d’arrêt. Lorsque l’API les prend en charge, elles s’appliquent à la sortie générée. Leur seule présence dans l’invite ne déclenche pas l’arrêt. Vérifiez leur prise en charge pour le modèle et le point de terminaison utilisés.

Vérifier le prétraitement avant le comptage

1. Conservez les fins de ligne d’origine sauf si votre application les convertit délibérément. Comptez le texte qui sera réellement envoyé.
2. Ne supprimez pas systématiquement ZWJ/ZWNJ et ne remplacez pas NBSP pour économiser des jetons. Ces caractères peuvent avoir un rôle linguistique ou typographique.
3. Conservez les espaces répétés et les tabulations dans le code, les données structurées et les citations. Testez toute transformation volontaire des espaces sur ces cas.
4. Ne convertissez pas les guillemets et les apostrophes en ASCII uniquement pour réduire le nombre de jetons. Préservez la langue et le texte source exact lorsque cela est nécessaire.
5. Conservez les délimiteurs Markdown et les espaces de fin de ligne significatifs. Leur suppression doit être une transformation voulue par l’application, pas un raccourci automatique de comptage.
6. Conservez une source unique et versionnée pour les instructions système.
7. Indiquez la langue de sortie souhaitée dans les instructions système.
8. Enregistrez les catégories d’utilisation en entrée et en sortie fournies par le serveur, avec l’estimation locale et la révision du modèle. Évitez de journaliser inutilement le contenu sensible des invites.

Le prétraitement doit être un choix explicite et testé de l’application. La normalisation Unicode peut changer la représentation ; la normalisation de compatibilité peut supprimer des distinctions. Le comptage seul ne justifie pas de réécrire chaque phrase.

Tester sur une instance compatible

Vérifiez la configuration d’instance disponible et la documentation produit actuelle avant un essai. Mesurez le comportement de votre propre modèle et de votre charge de travail.

Essayer Compute

Exemples de test pour comparer les tokeniseurs

Conservez une référence de tokenisation pour chaque modèle et révision. Les exemples ci-dessous comparent des comptes locaux de texte brut ; ils ne comptent pas une requête de conversation complète et ne démontrent pas un comportement équivalent entre modèles. Ajoutez des tests représentatifs avant de les utiliser en intégration continue.

Portée des exemples : Python charge explicitement cl100k_base et un fichier SentencePiece local nommé llama.model ; ce fichier est requis et ne convient pas à toutes les générations de Llama. L’exemple JavaScript choisit gpt-4o-mini, dont l’encodage documenté est o200k_base, avec des textes différents. Ce n’est pas une comparaison Python/JavaScript à entrées identiques. Alignez le tokeniseur et les entrées avant de comparer les résultats ; aucun de ces exemples n’a été testé à l’exécution pour cet article.

Python : exemple à adapter

# pip install tiktoken sentencepiece
import tiktoken
import sentencepiece as spm

# Chargez l’encodage et le fichier SentencePiece exacts du modèle à comparer.
enc_gpt = tiktoken.get_encoding("cl100k_base")
sp = spm.SentencePieceProcessor(model_file="llama.model") # fichier local requis ; uniquement pour un modèle compatible SentencePiece

# Conservez ces textes multilingues identiques pour comparer les tokeniseurs.
TEXTS = [
"l’été dernier à Zürich — café & résumé",
"Schadenfreude und Lebensversicherung",
"اللغة العربية جميلة جدًا",
"I typed :shrug: and got 🤷🏽‍♂️",
"""```


print('big code block that should be truncated...')
```"""
]

for s in TEXTS:
# Comptez les jetons avec chaque bibliothèque.
gpt_tokens = len(enc_gpt.encode(s))
sp_tokens = len(sp.encode(s))
print({"text": s[:32] + "…", "gpt": gpt_tokens, "spm": sp_tokens})


Node.js : exemple à adapter

// npm i js-tiktoken
import { encodingForModel } from "js-tiktoken";
// Chargez le tokeniseur du modèle choisi.
const enc = encodingForModel("gpt-4o-mini");
// Conservez ces exemples identiques pour les comparaisons.
const samples = [
"l’été à Paris",
"Schweizer Rückversicherung",
"emoji 🤷🏽‍♂️",
];
for (const s of samples) {
// Affichez le nombre de jetons pour chaque exemple.
console.log(s.slice(0,24)+"…", enc.encode(s).length);
}


Gestion du contexte dans les applications

Pour créer des applications LLM efficaces, il ne suffit pas d'insérer du texte dans un modèle. Il s'agit également de comprendre le contexte et la manière dont il influe sur la qualité et la rapidité des résultats. Le développement tenant compte du contexte implique la conception de systèmes qui utilisent les points forts de votre modèle tout en gérant les véritables défis liés aux limites de jetons et aux fenêtres contextuelles.

Le RAG ajoute des documents récupérés à l’entrée et peut aider lorsque ces documents sont pertinents. Il ne garantit ni une invite plus courte, ni une latence plus faible, ni une réponse plus exacte. Mesurez ensemble la pertinence des documents, la longueur du contexte, la qualité des réponses et la latence sur des requêtes représentatives.

Lorsque vous comprenez comment le contexte, les jetons et les performances du modèle fonctionnent ensemble, vous pouvez concevoir des applications qui tirent le meilleur parti des LLM. Cela implique de choisir avec soin vos données d'entrée, de surveiller l'utilisation des jetons et d'utiliser des techniques contextuelles afin que chaque jeton apporte de la valeur à votre tâche spécifique. Le développement tenant compte du contexte revient à trouver le bon équilibre : donnez au modèle suffisamment d'informations pour comprendre ce dont vous avez besoin tout en préservant son efficacité pour une utilisation dans le monde réel.

Surveillance et alertes

• Comparez des mesures équivalentes. Séparez les estimations locales de l’utilisation déclarée par le serveur pour la requête. Appliquez les définitions de facturation du fournisseur plutôt que de traiter le compte du texte visible comme une facture.
• Calibrez les alertes d’écart. Un écart de 5 à 10 % sur une heure peut servir de seuil de diagnostic initial, pas de norme universelle. Définissez vos seuils à partir des types de requêtes observés et examinez les changements persistants.
• Tableaux de bord par route. Suivez la distribution du nombre de jetons pour chaque route de l’application et réévaluez les plafonds lorsque les requêtes les plus longues augmentent.
• Répartition des langues. Suivez la langue de chaque requête ; un changement important de cette répartition peut modifier le nombre de jetons et la latence.
• Incidents. Si les requêtes atteignent les plafonds ou si les erreurs de mémoire insuffisante (OOM) augmentent, vérifiez notamment les changements de tokeniseur ou de prétraitement.

Remarque : Il est essentiel de surveiller le nombre de jetons utilisés dans chaque demande afin d'éviter les dépassements de budget et les coûts imprévus.

Essayer Compute : exécutez un point de terminaison vLLM sur Compute avec des journaux d’utilisation en entrée et en sortie, ainsi que des mesures de TTFT et de TPS. Consignez le tokeniseur et sa révision pour chaque modèle déployé, puis vérifiez les estimations en intégration continue.

Comparer les estimations à l’utilisation observée

Suivez les révisions du tokeniseur et du modèle de conversation, le prétraitement volontaire et l’utilisation côté serveur. Retestez des langues et des tâches représentatives après chaque changement. Ces vérifications aident à expliquer les écarts ; elles ne garantissent pas la stabilité du délai avant le premier jeton (TTFT) ni des jetons par seconde.

Conclusion et orientations futures

Pour un modèle préentraîné, utilisez son tokeniseur compatible au lieu de choisir indépendamment BPE, WordPiece ou un modèle SentencePiece. Évaluez ensemble la qualité, la latence et le coût avant de modifier le déploiement.

Lors d’un changement de tokeniseur ou de modèle, comparez les mêmes entrées représentatives et conservez les versions avec les résultats. Appuyez-vous sur les écarts mesurés plutôt que de supposer qu’une option plus récente est plus efficace.

Évaluez les changements de gestion du contexte sur vos propres tâches. Davantage de documents récupérés ou un tokeniseur plus récent ne prouvent pas à eux seuls une amélioration des réponses ; conservez les mesures comparatives et la configuration exacte du modèle.

Intégrez ces vérifications aux tests de l’application et répétez-les lorsque le modèle, le traitement des entrées ou le format de requête change.

FAQ

Quel est le moyen le plus sûr de compter les jetons ?

Utilisez le tokeniseur et le modèle de conversation correspondant au modèle déployé et à sa révision. Comparez les estimations locales aux informations de comptage ou d’utilisation de la requête fournies par le service, lorsqu’elles sont disponibles.

Distinguez les jetons estimés, l’utilisation déclarée et le coût facturé. Examinez les écarts avant d’utiliser une estimation locale pour la facturation ou les alertes.

Pour les modèles pris en charge, tiktoken permet d’estimer localement les jetons du texte brut. Le comptage d’une chaîne seule n’inclut pas toute la requête structurée.

Pourquoi les chiffres sont-ils différents entre les modèles OpenAI et ceux de la famille Llama ?

Les modèles peuvent utiliser des vocabulaires, des règles de normalisation et des jetons spéciaux différents, même avec le même algorithme de tokenisation. SentencePiece peut implémenter BPE ; ce n’est pas un algorithme opposé.

Pour comparer une phrase, passez exactement le même texte dans chaque tokeniseur nommé et chaque révision, puis relevez les identifiants des jetons et leur nombre. Ne déduisez pas le découpage des mots affichés et ne présentez pas un découpage non mesuré comme un résultat.

Remarque : Prévoyez toujours la variation du nombre de jetons entre les modèles et définissez des plafonds de jetons en conséquence.

Les caractères Unicode sont-ils vraiment importants ?

Oui. Les espaces, les caractères combinatoires, les séquences d’émojis et la ponctuation peuvent modifier le résultat, sans toujours l’augmenter. Testez la chaîne Unicode exacte avec le tokeniseur du déploiement.

Comptez après tout prétraitement volontaire de l’application et conservez le texte d’origine pour comparaison si nécessaire. Ne normalisez pas uniquement pour forcer une baisse du nombre de jetons.

Des suites de caractères Unicode différentes peuvent produire des découpages différents avec un même tokeniseur. Comparez les chaînes exactes utilisées par l’application et leur nombre de jetons.

Puis-je utiliser le nombre de mots au lieu du nombre de jetons ?

Non. Le nombre de mots n’est pas le nombre de jetons ; leur rapport varie selon la langue, le texte et le tokeniseur. Mesurez l’entrée réelle plutôt que d’appliquer une conversion fixe entre mots et jetons.

Un même mot peut correspondre à plusieurs jetons selon le texte et le tokeniseur. Une estimation fondée uniquement sur les mots peut donc différer du comptage réel.

Remarque : Utilisez toujours le nombre de jetons plutôt que le nombre de mots ou de phrases pour estimer l'utilisation ou les coûts.

Quel budget dois-je prévoir pour les applications multilingues ?

Enregistrez les balises de langue par demande pour suivre avec précision l'utilisation et gérer l'allocation des jetons. Différentes tâches, telles que la traduction, la synthèse ou la génération de dialogues, peuvent nécessiter des stratégies budgétaires différentes en fonction de leur complexité et de leur langue. Mesurez le nombre de jetons pour chaque demande afin de déterminer combien de jetons sont utilisés, en vous assurant de respecter les limites du contexte du modèle.

Définissez les budgets multilingues à partir des distributions mesurées des entrées et sorties par tâche et par langue, y compris les cas longs. L’étiquette « multilingue » ne garantit ni la même efficacité de tokenisation ni la même qualité de réponse dans chaque langue.

Mesurez le TTFT et le TPS par langue.

Le streaming modifie-t-il le nombre de jetons ?

Le streaming modifie le mode de livraison de la sortie ; il ne constitue pas une réduction du nombre de jetons facturables. Comparez l’utilisation de la requête réellement terminée ou annulée, pas la quantité de texte déjà affichée.

Un bouton Arrêter doit demander l’annulation par le mécanisme pris en charge côté client et serveur. Masquer la sortie ou fermer l’affichage ne prouve pas que la génération s’est arrêtée ; l’annulation peut arriver pendant un calcul en cours. Ne promettez pas que tout jeton suivant le clic sera non facturé.

Pour OpenAI Chat Completions, stream_options.include_usage demande un dernier événement contenant l’utilisation. Un flux interrompu peut ne pas le recevoir. Indiquez alors que l’utilisation est indisponible plutôt que de traiter l’absence de total comme zéro.

Utilisez le paramètre de limite de sortie pris en charge par le point de terminaison et le modèle, par exemple max_output_tokens ou max_completion_tokens lorsque cela s’applique. Prévoyez les catégories de sortie non visibles si nécessaire ; testez la troncature et l’annulation avant de fixer des limites serrées.

‍