Concepts
Token
Unité de découpage d'un texte en fragments de quelques caractères, sur laquelle le modèle calcule et que le fournisseur compte pour facturer l'entrée comme la sortie.
Un découpage, pas des lettres
Les modèles ne lisent ni des lettres ni des mots entiers. Un tokeniseur, entraîné sur un corpus, découpe le texte en fragments récurrents : un mot courant forme souvent un seul token, un terme rare ou un nom propre est scindé en plusieurs morceaux. Le même contenu exprimé en anglais et en français ne produit pas le même nombre de tokens, car les corpus d'entraînement ne donnent pas la même place à chaque langue. Le créole, comme beaucoup de langues peu représentées, se découpe davantage, ce qui renchérit mécaniquement le traitement.
Ce découpage explique une partie des écarts de qualité observés entre langues. Un modèle qui a vu peu de textes en français doit reconstituer un mot à partir de fragments, et perd des nuances au passage. Cela ne condamne pas l'usage du français, mais invite à relire les sorties avec attention sur les termes métier, les noms de lieux et les références locales. Un lexique interne ajouté au contexte réduit souvent ces approximations mieux qu'un changement de modèle, et coûte beaucoup moins cher à mettre en place.
Ce que la facturation mesure
Les fournisseurs facturent à l'unité de token, avec un prix distinct pour ce qui entre dans le modèle et pour ce qui en sort. Une consigne longue, un document joint, un historique de conversation conservé augmentent la part d'entrée. Une réponse verbeuse augmente la part de sortie, généralement la plus chère des deux. Deux applications qui rendent le même service peuvent donc afficher des coûts très différents selon la longueur des consignes et la discipline de format imposée au modèle.
La fenêtre de contexte se mesure elle aussi en tokens, pas en pages. Un mémoire technique, un contrat ou un rapport annuel peuvent dépasser la capacité d'un modèle donné, ou consommer une part importante de cette capacité avant même que la question ne soit posée. Découper le document en sections, résumer les parties secondaires, ou interroger un index documentaire plutôt que tout charger devient alors une décision d'architecture, pas un détail de réglage à ajuster en fin de projet.
Ce que la conception doit anticiper
Les formats structurés coûtent plus cher qu'ils n'en ont l'air. Faire produire du JSON détaillé, avec des clés explicites et des guillemets à chaque valeur, multiplie les tokens de sortie pour une information parfois redondante. Pour un traitement en volume, une trame courte, un séparateur simple et un nombre limité de valeurs autorisées réduisent la dépense sans dégrader le résultat. Ce type d'arbitrage se mesure sur un échantillon réel avant d'être généralisé au flux complet.
Compter en tokens, plutôt qu'en caractères ou en pages, aide à dimensionner une offre, à comparer deux fournisseurs et à expliquer un écart de facture à un client. Les bibliothèques de tokenisation permettent de faire ce calcul hors ligne, sur vos propres documents, sans envoyer une seule ligne à un service distant. Un test sur quelques dizaines de pièces donne un ordre de grandeur fiable, à réévaluer si le fournisseur change de modèle ou de tokeniseur.
En pratique
- Mesurer le nombre de tokens d'un document type avant de choisir un modèle ou une formule tarifaire.
- Séparer dans le devis la part d'entrée et la part de sortie : ce sont deux prix différents.
- Éviter les consignes redondantes et les formats verbeux sur les traitements en volume.
- Garder un lexique métier court dans le contexte pour compenser les découpages approximatifs du français.
Voir aussi
- LLMUn grand modèle de langage : un réseau entraîné à prédire le mot suivant sur des milliards de phrases.
- Coût par usageLe prix réel d'une réponse, d'un document ou d'un dossier traité, modèles et hébergement compris.
- Fenêtre de contexteLa quantité de texte qu'un modèle peut garder en tête pendant une conversation ou un traitement.