Un modèle mental utile
Considérez les jetons de sortie à la fois comme les éléments de la réponse et comme les étapes nécessaires à sa production.
Un modèle de texte n’écrit pas une réponse complète en arrière-plan avant de la diviser en jetons. Il construit la réponse un jeton à la fois. Après chaque jeton, la séquence en cours de construction devient une partie des informations utilisées pour choisir le suivant.
Cette différence explique pourquoi une réponse longue prend plus de temps à générer qu’une réponse courte. Chaque jeton de sortie supplémentaire nécessite une étape de génération supplémentaire.
Comment les jetons de sortie sont générés
Après avoir traité l’entrée, le modèle attribue un score à chaque jeton susceptible de venir ensuite. Les paramètres de génération déterminent comment l’une de ces possibilités est choisie. Le jeton sélectionné est ajouté à la séquence, puis le modèle répète le processus.
process the input
|
v
score possible next tokens
|
v
choose one output token ----+
| |
v |
append it to the sequence --+
|
v
stop when a stopping condition is metLa boucle peut se terminer parce que :
- le modèle atteint une fin naturelle ;
- il génère une séquence d’arrêt configurée ;
- il atteint une limite de jetons de sortie ;
- il passe à une action telle qu’un appel d’outil ; ou
- le service applique une autre condition d’arrêt propre au modèle ou à ses politiques.
Le nombre exact de jetons dépend du tokenizer du modèle. Un mot court peut correspondre à un seul jeton. Un mot plus long ou moins courant peut en contenir plusieurs. Les espaces, la ponctuation, le code et les textes non anglais peuvent également être segmentés différemment. C’est pourquoi le nombre de caractères et le nombre de mots peuvent estimer la longueur de sortie, mais ne peuvent pas la déterminer exactement.
Ce qui compte comme jeton de sortie
Dans une réponse textuelle ordinaire, la réponse visible est formée de jetons de sortie générés. Le JSON généré et les arguments d’appel d’outil sont également des sorties du modèle, même lorsqu’une application les affiche comme une action de l’interface au lieu de montrer le texte brut.
Les catégories d’utilisation définies par les fournisseurs ajoutent un second niveau. « Jetons de sortie » peut désigner soit la séquence générée visible, soit un total mesuré. Ces totaux ne sont pas standardisés :
- Certaines API appellent les jetons générés des jetons de complétion.
- Certaines incluent le raisonnement masqué dans le total de sortie et fournissent une ventilation distincte.
- Certaines signalent séparément les jetons de candidats visibles et les jetons de réflexion.
- Les types de sortie particuliers peuvent avoir leurs propres détails ou règles de facturation.
La source fiable pour une requête est constituée des données d’utilisation renvoyées par le fournisseur et le point de terminaison concernés. N’inférez pas la sortie facturée en copiant simplement la réponse visible dans un tokenizer. Les documentations actuelles d’OpenAI, d’Anthropic et de Google l’illustrent : leurs libellés et leurs ventilations diffèrent.
Un exemple détaillé
Imaginez une requête API avec un maximum de 100 jetons de sortie.
Le modèle génère une réponse complète et s’arrête après 24 jetons. Les données d’utilisation indiquent :
{
"input_tokens": 18,
"output_tokens": 24,
"total_tokens": 42
}Le nombre de jetons de sortie est de 24. Le paramètre de 100 jetons n’était qu’une limite supérieure. Il n’a pas obligé le modèle à produire 100 jetons et ne signifie pas à lui seul que 100 jetons ont été facturés.
Supposons maintenant que le modèle continue jusqu’à atteindre la limite de 100 jetons. La requête peut tout de même renvoyer une réponse API techniquement réussie, mais la réponse peut se terminer au milieu d’une phrase ou d’une structure. Une application de production doit vérifier la raison d’arrêt de la réponse plutôt que de supposer que le texte renvoyé est complet.
Il existe une autre nuance. Un modèle de raisonnement peut générer un raisonnement interne avant la réponse visible. Selon le fournisseur, l’utilisation peut inclure ces jetons masqués dans output_tokens ou les signaler dans un champ de réflexion distinct. La réponse visible et la sortie mesurée peuvent donc avoir des nombres de jetons différents.
Pourquoi les jetons de sortie sont importants
Coût
Les services dont la tarification est fondée sur les jetons mesurent généralement séparément l’entrée et la sortie, avec des tarifs qui peuvent différer. L’utilisation réelle de la sortie, et pas seulement la limite demandée, fait donc partie du coût de chaque requête. Les systèmes de quotas propres aux fournisseurs peuvent réserver temporairement de la capacité en fonction de la limite, même lorsque la facturation repose sur la génération réelle.
Temps de réponse
Les jetons de sortie sont générés séquentiellement. Une sortie plus longue implique généralement davantage d’étapes de génération et une attente plus longue avant de recevoir la réponse complète. La diffusion en continu peut afficher plus rapidement une partie de la sortie, mais elle ne supprime pas le travail nécessaire pour générer les jetons restants.
Complétude
Une limite de sortie aide à contrôler la longueur, mais une limite trop basse peut tronquer de la prose, du code, du JSON ou des arguments d’outil. Vérifiez la raison d’arrêt dès que la complétude est importante.
Contexte disponible
L’entrée et la sortie utilisent toutes deux de l’espace dans la fenêtre de contexte d’un modèle. Une requête qui utilise la majeure partie de l’espace disponible pour l’entrée peut laisser moins de place à la génération, selon les limites et les règles de comptabilisation du modèle et du point de terminaison.
Idées reçues courantes
« Les jetons de sortie sont identiques aux mots »
Ce n’est pas le cas. Les jetons peuvent être des mots entiers, des parties de mots, des signes de ponctuation, des espaces ou d’autres unités. Une même phrase peut avoir des nombres de jetons différents selon les tokenizers.
« Le paramètre de sortie maximal correspond à la sortie attendue »
Il s’agit d’une limite supérieure. Le modèle peut s’arrêter avant de l’atteindre. Les fournisseurs peuvent également appliquer une limite de modèle inférieure ou un budget partagé incluant le raisonnement interne.
« Si l’API a renvoyé du texte, la réponse est complète »
Pas nécessairement. Atteindre la limite de sortie peut renvoyer un texte partiel avec une raison d’arrêt liée à la longueur. Cela est particulièrement important pour le code et les données structurées, où l’absence d’un seul caractère de fermeture peut rendre le résultat inutilisable.
« La réponse visible correspond à la sortie facturée »
Souvent, mais pas toujours. Le raisonnement masqué, plusieurs candidats générés ou la comptabilisation propre à un point de terminaison peuvent rendre l’utilisation supérieure au texte que vous voyez. Considérez les champs d’utilisation renvoyés comme faisant autorité pour ce service.
« La longueur de sortie est fixée par le prompt »
Le prompt influence la longueur, mais la génération reste conditionnelle. Le comportement du modèle, les paramètres d’échantillonnage, les séquences d’arrêt, l’utilisation d’outils et le comportement de sécurité peuvent tous modifier le point où la sortie se termine.
Comment les jetons de sortie s’intègrent dans une requête de modèle
Une requête commence par des jetons d’entrée. Le modèle génère ensuite des jetons de sortie. Les modèles de raisonnement peuvent également utiliser des jetons de raisonnement, dont la présentation et le traitement en matière de facturation varient selon le fournisseur.
La distinction est plus facile à observer côte à côte dans Jetons d’entrée vs. de sortie vs. de raisonnement. Si vous mesurez le comportement du service, la génération de sortie est également directement liée aux jetons par seconde et à la latence d’inférence.
La règle pratique est simple : définissez une limite de sortie raisonnable, consultez l’utilisation réelle et examinez la raison d’arrêt avant de considérer la réponse comme complète.