« Tokens du prompt » signifie généralement la même chose. Cette appellation peut toutefois être trompeuse, car le prompt peut inclure du contenu ajouté par l’application ou l’API.
Toute la requête, pas seulement votre message
Imaginez que vous saisissiez « Résume le dernier rapport » dans une boîte de dialogue. Cette phrase constitue une partie de l’entrée. L’application peut également envoyer :
- des instructions qui définissent le rôle et le comportement de l’assistant ;
- les messages précédents de l’utilisateur et de l’assistant ;
- le rapport lui-même ou des passages qui en ont été extraits ;
- les définitions des outils que le modèle peut appeler ;
- les résultats renvoyés par un outil ; et
- des marqueurs qui identifient les rôles, les limites entre les messages ou le point où la génération doit commencer.
Toutes ces parties peuvent devenir des tokens d’entrée. L’ensemble exact dépend de l’application, de l’API, du modèle et des fonctionnalités activées.
Cela donne aux tokens d’entrée une limite précise : ils sont définis par leur rôle dans une requête donnée. Le texte que le modèle a généré comme sortie lors d’un tour peut devenir une entrée au tour suivant lorsque l’application le renvoie comme historique de conversation.
Comment une requête devient des tokens d’entrée
Le parcours d’une interface à un modèle se présente ainsi :
system instructions ─┐
conversation history ├─> request formatting ─> tokenizer ─> input token IDs ─> model
documents and tools ┤
current message ─────┘Tout d’abord, l’application assemble le contexte de la requête. Un appel d’API minimal peut ne contenir qu’un seul prompt. Un assistant en production peut ajouter des instructions, l’historique, des documents récupérés, des schémas d’outils et d’autres contenus.
Ensuite, le service formate ce contenu pour le modèle sélectionné. Les modèles conversationnels ne reçoivent pas une transcription visuelle avec des bulles de messages colorées. Ils reçoivent une séquence construite à l’aide d’un modèle de conversation ou d’un format interne équivalent. La documentation de l’API conversationnelle de vLLM rend cette étape explicite : les messages structurés sont convertis en prompt textuel avec le modèle de conversation du modèle.
Puis, un tokenizer convertit la séquence formatée en identifiants de tokens. Comme l’indique la référence des tokenizers de Hugging Face, cette opération peut inclure la normalisation, le découpage du texte en segments, l’association de ces segments à des identifiants et l’ajout de tokens spéciaux. Comme les modèles peuvent utiliser des tokenizers et des modèles de conversation différents, un même texte visible ne garantit pas le même nombre de tokens d’entrée.
Enfin, le modèle traite cette séquence de tokens et commence à générer. Les métadonnées d’utilisation de la réponse indiquent la manière dont le fournisseur a comptabilisé la requête.
Exemple détaillé
Supposons qu’une application signale le relevé illustratif suivant pour une requête :
- Instructions système : 36 tokens
- Définitions des outils : 74 tokens
- Historique de la conversation : 160 tokens
- Message actuel de l’utilisateur : 12 tokens
- Formatage des messages et tokens spéciaux : 15 tokens
La requête contient 297 tokens d’entrée, même si le message actuel n’en contient que 12.
Supposons maintenant que la réponse contienne 60 tokens générés. Ces 60 tokens sont les tokens de sortie de cette requête. Au tour suivant, l’application peut inclure cette réponse dans l’historique. Le même texte contribue alors au décompte des tokens d’entrée de la requête suivante.
La mise en cache modifie le traitement et le prix des entrées répétées, mais pas leur rôle conceptuel. Si 200 des 297 tokens d’entrée proviennent d’un préfixe réutilisable, un fournisseur peut déclarer ou facturer ces 200 tokens séparément en tant qu’entrées mises en cache. Ils restent du contexte fourni au modèle. Anthropic, par exemple, répartit les requêtes mises en cache entre plusieurs champs d’utilisation, tandis qu’OpenAI expose les entrées mises en cache comme une catégorie d’entrée distincte. Consultez toujours la définition actuelle des champs au lieu de supposer qu’un champ nommé input_tokens constitue le total complet.
Comment compter les tokens d’entrée
Pour une première estimation, un tokenizer adapté au modèle peut estimer le nombre de tokens d’un texte brut. Il ne peut pas reproduire de manière fiable le décompte complet de l’API s’il n’applique pas également le même modèle de conversation, le même formatage des outils, les mêmes tokens spéciaux, le même encodage des médias et les mêmes ajouts effectués par le fournisseur.
Pour une requête complète, utilisez le point de terminaison de comptage des tokens du fournisseur lorsqu’il est disponible. Le point de terminaison de comptage des tokens d’Anthropic accepte les messages, les prompts système, les outils, les images et les PDF. Le guide des tokens de Google distingue également les décomptes d’entrée effectués avant l’appel des données d’utilisation renvoyées après la génération. Les recommandations d’OpenAI sur le comptage des tokens indiquent que la structure de la requête et les entrées non textuelles peuvent avoir une incidence sur le décompte complet.
Considérez un décompte préalable comme une estimation de la capacité et du coût. Après la requête, conservez la réponse d’utilisation du fournisseur comme trace de la manière dont cet appel a effectivement été comptabilisé et facturé.
Pourquoi les tokens d’entrée sont importants
Coût
De nombreuses API facturent séparément les entrées, les entrées mises en cache et les sorties. Un relevé de coûts utile est le suivant :
input cost =
uncached input tokens × uncached input rate
+ cached input tokens × cached input rateLes tarifs et les catégories évoluent ; utilisez donc la page tarifaire actuelle du fournisseur plutôt que de recopier un prix dans la logique de l’application. De longues instructions système, des définitions d’outils répétées, de nombreux passages récupérés et un historique de conversation qui s’allonge peuvent faire des entrées la composante la plus importante d’une charge de travail.
Contexte disponible
Les tokens d’entrée occupent de l’espace dans le contexte du modèle. Une quantité d’entrée plus importante peut laisser moins de place à la réponse, selon le modèle et les règles de limite de l’API. Envoyer du contexte supplémentaire ne fournit donc pas une capacité gratuite : il entre en concurrence avec les autres instructions, éléments probants et tours de conversation pour attirer l’attention du modèle et utiliser le budget de tokens.
Temps de réponse
Le modèle doit traiter l’entrée avant de pouvoir produire le premier token de sortie. Les entrées volumineuses nécessitent généralement davantage de traitement du prompt. La réutilisation d’un préfixe mis en cache et admissible peut réduire ce travail, mais le comportement et les avantages du cache dépendent du fournisseur.
Mesure
Les décomptes de tokens d’entrée permettent de comparer les requêtes à un niveau plus utile que les caractères ou les mots. Ils peuvent révéler un schéma d’outil trop volumineux, un système de récupération qui envoie trop de passages ou un historique de conversation qui s’allonge à chaque tour.
Idées reçues courantes
« Les tokens d’entrée sont les mots que j’ai saisis »
Vos mots ne constituent que la partie visible. La requête destinée au modèle peut également contenir des instructions, un historique, des documents, des outils, des médias et du formatage.
« Un mot équivaut à un token d’entrée »
Un token peut être un mot, une partie de mot, un signe de ponctuation ou une autre unité propre au modèle. Les limites entre les tokens varient selon le tokenizer. L’article Qu’est-ce qu’un token en IA ? présente cette unité fondamentale.
« Les tokens mis en cache ne sont plus des tokens d’entrée »
Les tokens mis en cache sont des entrées réutilisées. La mise en cache peut modifier la quantité de calcul, le prix et les champs d’utilisation, mais le préfixe mis en cache contribue toujours au contexte de la requête.
« Les messages de l’assistant sont toujours des tokens de sortie »
Ils sont des sorties lorsqu’ils sont générés. Si un message de l’assistant est inclus dans l’historique d’une requête ultérieure, il constitue une entrée pour cette requête ultérieure. Entrée et sortie décrivent les deux côtés d’une requête, et non des types permanents de texte.
« Un tokenizer local donne le décompte utilisé pour la facturation »
Il peut fournir un décompte proche pour le texte. Il peut omettre les marqueurs du modèle de conversation, les schémas d’outils, les pièces jointes et le formatage effectué par le fournisseur. Utilisez les données d’utilisation renvoyées par l’API après la requête pour les relevés de facturation.
Comment les tokens d’entrée s’intègrent au système global
Les tokens d’entrée constituent la séquence initiale du modèle pour une requête. Les tokens de sortie sont générés après cette séquence, tandis que les tokens d’entrée mis en cache sont une subdivision des entrées liée au traitement et à la facturation. Ensemble, ces catégories expliquent la majeure partie du relevé de tokens affiché dans les réponses des API et les pages tarifaires.
L’habitude importante consiste à mesurer la requête assemblée. Lorsqu’un message utilisateur court produit un décompte étonnamment élevé, examinez les instructions système, l’historique, le contenu récupéré, les outils et le formatage avant d’accuser le tokenizer.
Pour aller plus loin
Examinez une réponse réelle d’API et identifiez chaque champ d’utilisation qui contribue au total des entrées. Exécutez ensuite le compteur préalable du fournisseur sur la même requête et comparez l’estimation avec les données d’utilisation finales. Si les limites entre les tokens ne sont pas claires, commencez par Qu’est-ce qu’un token en IA ?. Poursuivez avec Que sont les tokens de sortie ?, puis utilisez Tokens d’entrée vs tokens de sortie vs tokens de raisonnement pour comparer les trois catégories de comptabilisation.