Tokens d’entrée
Tokens d’entrée désignent le contenu fourni pour une requête. Cela peut inclure les instructions système et développeur, le dernier message de l’utilisateur, les tours précédents de la conversation, les documents récupérés, les définitions d’outils, les résultats d’outils et les images ou fichiers audio encodés lorsque le modèle les accepte.
« Entrée » décrit la direction des données, et non l’identité de leur auteur. Un utilisateur peut saisir une seule phrase courte tandis que l’application envoie discrètement une requête beaucoup plus volumineuse autour de celle-ci.
Une entrée mise en cache reste une entrée. La mise en cache peut modifier son prix ou la manière dont elle apparaît dans un rapport d’utilisation, mais elle ne transforme pas le contenu en sortie et ne le retire pas du contexte de travail du modèle.
Tokens de sortie
Tokens de sortie sont générés pendant la réponse. Le texte visible et le code sont des sorties, mais les structures générées telles que les appels d’outils le sont également. Selon la terminologie du fournisseur, le total de sortie indiqué peut aussi inclure le raisonnement interne et d’autres tokens générés non visibles.
C’est pourquoi le texte affiché à l’écran ne constitue pas un compteur fiable de tokens. La réponse peut afficher 180 tokens de texte tandis que le relevé d’utilisation indique un total généré beaucoup plus élevé.
Tokens de raisonnement
Tokens de raisonnement, parfois appelés tokens de réflexion, sont générés en interne lorsqu’un modèle de raisonnement planifie, vérifie ou traite une tâche. Ils ne constituent pas du contenu supplémentaire de l’invite et ne vous sont pas nécessairement affichés.
Un fournisseur peut masquer le raisonnement, l’omettre ou renvoyer un résumé. Un résumé est une présentation du processus, et non la preuve que vous avez reçu chaque token de raisonnement interne. Les documentations actuelles d’OpenAI, d’Anthropic, et de Google mesurent toutes le travail interne complet, même lorsque l’intégralité du texte n’est pas renvoyée.
Tous les modèles ou toutes les API n’exposent pas un décompte des tokens de raisonnement. Certains modèles génèrent une réponse sans phase de raisonnement indiquée séparément. D’autres prennent en charge des contrôles qui influencent l’effort de raisonnement, mais ces contrôles ne garantissent pas une quantité exacte de réflexion, sauf indication explicite du fournisseur.
La distinction réelle
Les trois libellés répondent à des questions différentes :
| Token type | Defining question | Typical contents | Usually visible? | Accounting relationship |
|---|---|---|---|---|
| Input | What did this request send to the model? | Instructions, messages, context, tools, files | Mostly, though applications can add content | A top-level request category; cached input may be a priced subset |
| Output | What did the model generate? | Answer text, code, tool calls, and sometimes internal generated work | Partly | Can be an inclusive total or an answer-only field, depending on the API |
| Reasoning | What internal generated work helped produce the answer? | Planning, intermediate work, checks | Often hidden or summarized | Commonly a subset of generated output for billing, but sometimes reported beside output |
L’entrée et la sortie générée sont les deux faces opposées d’une requête. Le raisonnement est une forme d’activité générée. Il ne constitue donc pas une troisième catégorie universelle aux côtés de l’entrée et de la sortie.
Cette distinction est importante lorsque vous comparez les tableaux de bord des fournisseurs. OpenAI documente le raisonnement comme un détail inclus dans le décompte total de sortie. Anthropic décrit également les tokens de réflexion comme faisant partie de son total de sortie de référence. Google expose séparément la sortie du candidat et le décompte des pensées, et précise que la tarification de la réponse les combine. Les noms des champs diffèrent, mais les trois fournisseurs considèrent le raisonnement comme un travail généré.
Exemple d’utilisation détaillé
Considérez la requête simplifiée suivante :
- Les instructions, le message de l’utilisateur, l’historique et le contexte joint totalisent 1 200 tokens d’entrée.
- Le modèle génère 620 tokens de raisonnement.
- Il génère ensuite une réponse visible de 180 tokens.
Une API pourrait indiquer :
input_tokens: 1200
output_tokens: 800
output_details.reasoning_tokens: 620Ici, output_tokens est inclusif. N’ajoutez pas à nouveau les 620 tokens. La réponse de 180 tokens constitue la partie hors raisonnement des 800 tokens générés.
Une autre API pourrait indiquer :
input_tokens: 1200
output_tokens: 180
thought_tokens: 620
total_tokens: 2000Ici, la sortie de la réponse et les tokens de pensée sont des champs distincts. Vous devez inclure les deux pour évaluer l’utilisation générée. Les deux rapports décrivent le même déroulement simplifié :
1,200 input + 620 reasoning + 180 visible answer = 2,000 total tokensSi tous les tokens générés utilisent le tarif de sortie du fournisseur, le calcul simplifié du coût est :
(1,200 × input rate) + (800 × output rate)Les factures réelles peuvent appliquer des tarifs distincts pour les entrées mises en cache, les écritures de cache, les traitements par lots, les outils ou d’autres fonctionnalités. Utilisez le schéma d’utilisation et les règles tarifaires de l’API plutôt que de supposer que tous les champs sont additifs.
Quand chaque type de token compte
Les tokens d’entrée comptent lorsque les requêtes transportent beaucoup de contexte.Les longs historiques, les documents, les définitions d’outils et les instructions répétées peuvent dominer l’utilisation, même lorsque le dernier message de l’utilisateur est court. Les décomptes d’entrée indiquent également la capacité restante dans la fenêtre de contexte.
Les tokens de sortie comptent lorsque les réponses sont longues ou générées de manière répétée.La génération s’effectue étape par étape ; la sortie présente donc généralement des caractéristiques de performance et de tarification différentes de celles de l’entrée. Un flux de travail qui attribue une seule étiquette à un document n’a pas le même profil d’utilisation qu’un flux qui rédige un rapport.
Les tokens de raisonnement comptent lorsque la tâche exige un travail interne.Une réponse finale courte peut faire suite à une longue trace de raisonnement. Cela peut accroître le coût et le délai avant l’affichage de la réponse, et consommer la capacité en tokens générés sans allonger la réponse affichée.
Pour les modèles de raisonnement, une limite de sortie peut couvrir à la fois le raisonnement interne et la réponse visible. Si le raisonnement consomme d’abord cette limite, le modèle peut renvoyer une réponse courte ou incomplète. Consultez la documentation du point d’accès avant de considérer une limite de sortie comme une longueur de réponse garantie.
Les confusions courantes
Les tokens de raisonnement ne sont pas une entrée supplémentaire
Le modèle crée les tokens de raisonnement pendant la génération. Ils peuvent devenir des tokens d’entrée lors d’un tour ultérieur si l’application renvoie le contenu de réflexion conservé, mais il s’agit alors d’une nouvelle requête avec une nouvelle limite de mesure.
Les tokens de raisonnement ne sont pas toujours distincts des tokens de sortie
Si un objet d’utilisation indique que le raisonnement est un détail inclus dans la sortie, additionner les deux champs entraîne un double comptage. S’il indique les pensées à côté de la sortie de la réponse, ignorer le champ des pensées entraîne un sous-comptage. Lisez le schéma avant d’effectuer les calculs.
Les tokens de sortie ne sont pas toujours des mots visibles
Les tokens ne correspondent pas aux mots, et l’utilisation générée ne se limite pas au texte affiché. Les arguments d’appel d’outils, le raisonnement masqué et le formatage géré par le fournisseur peuvent tous creuser l’écart entre ce que vous voyez et ce que le compteur enregistre.
Une réponse courte n’est pas nécessairement une réponse peu coûteuse
La longueur visible ne représente qu’une partie de l’utilisation. Une requête peut comporter une entrée volumineuse, un raisonnement interne important, ou les deux. Le relevé d’utilisation de la réponse constitue une meilleure base de mesure que la taille de la réponse affichée.
Pour aller plus loin
Lisez Que sont les tokens d’entrée ? pour comprendre ce que les applications placent dans une requête. Lisez Que sont les tokens de sortie ? pour en savoir plus sur les réponses générées et les limites. Lisez Que sont les tokens de raisonnement ? pour comprendre la couche de réflexion dépendante du fournisseur.