Jetons et demandes expliqués

Une requête et un jeton ne sont pas la même chose

Un Requête API est un appel au point final. Jetons sont les unités de texte à l'intérieur de cet appel. Une requête peut contenir une poignée de jetons ou des centaines de milliers. Les fournisseurs LLM facturent par jetons ; de nombreuses autres API (paiements, cartes, SMS) facturent par requête ou par action. Mélanger les deux est l’erreur budgétaire la plus courante.

Où chaque modèle s’applique

Comment estimer avant de construire

Pour une fonctionnalité LLM, estimez : jetons par appel × appels par utilisateur × utilisateurs. Une réponse de chat peut contenir environ 500 jetons d'entrée + environ 300 jetons de sortie ; multipliez par les conversations mensuelles pour obtenir le volume de jetons, puis évaluez-le. C'est beaucoup plus précis que de deviner "par requête", car le nombre de jetons par requête varie énormément. Gardez les entrées et les sorties séparées tout au long du processus : les fournisseurs les évaluent différemment, souvent 3 à 5 fois plus loin, de sorte qu'une estimation mixte du "jeton moyen" peut être considérablement erronée.

La même répartition apparaît à nouveau dans les limites de taux

La plupart des fournisseurs LLM limitent l'utilisation à les deux axes à la fois : un plafond de requêtes par minute (RPM) et un plafond de jetons par minute (TPM). Celui que vous appuyez en premier dépend entièrement du nombre de jetons que contient votre appel moyen – le nombre exact sur lequel porte cette page.

• Appels courts, haute fréquence (par exemple, un classificateur se déclenchant à chaque frappe) ont tendance à toucher le RPM cap first – chaque appel est bon marché en jetons mais il y en a beaucoup.
• Appels longs, fréquence inférieure (par exemple, un point de terminaison de résumé de document avec un contexte de 20 000 jetons) a tendance à atteindre le TPM plafond en premier – une poignée d’appels peuvent déjà saturer le budget symbolique.

Savoir quelle limite vous atteindrez modifie le correctif : une charge de travail liée au RPM bénéficie de mise en lots plusieurs petits appels en une seule requête plus importante (moins de requêtes, même nombre total de jetons), tandis qu'une charge de travail liée au TPM bénéficie de garniture contexte ou la longueur de sortie plutôt que de réduire la fréquence des appels. Voir Explication des limites de débit de l'API pour les niveaux RPM/TPM concrets par fournisseur.

Exemple concret : dimensionner une fonctionnalité de chatbot

Supposons que vous envisagez un chatbot d'assistance pour 5 000 utilisateurs actifs mensuels, chacun faisant la moyenne 2 séances/mois de 3 tours chacun. Chaque tour porte à peu près 900 jetons d'entrée (invite du système + historique des conversations récentes + message de l'utilisateur) et 250 jetons de sortie.

• Jetons par tour : 900 + 250 = 1,150
• Tours par utilisateur/mois : 3 × 2 = 6
• Jetons par utilisateur/mois : 1 150 × 6 = 6,900 (≈4 900 entrées / 1 500 sorties)
• Total des jetons mensuels : 6 900 × 5 000 = 34,5 millions (≈24,5 M d'entrée / ~ 10 M de sortie)

Exécutez les totaux d'entrée et de sortie via un calculateur de coût de jeton séparément pour le modèle que vous avez choisi. Étant donné que le prix de sortie est plus élevé, les jetons de sortie de 10 millions peuvent coûter autant que les jetons d'entrée de 24,5 millions, même s'ils représentent un tiers du volume.

Erreurs courantes qui font exploser une estimation

• Mélanger les entrées et les sorties en un seul prix. Les jetons de sortie représentent généralement 3 à 5 fois le taux d’entrée – estimer les deux au prix d’entrée sous-estime la facture.
• Oublier l'histoire du ressentiment. Le chat multi-tours qui renvoie les messages précédents à chaque appel signifie que le nombre de jetons par tour augmente au cours d'une session, et pas seulement par message.
• Estimation par caractères, pas par jetons. Le nombre de jetons par caractère varie selon la langue et le contenu : le code, le JSON et le texte non anglais utilisent généralement plus de jetons par caractère que l'anglais simple.
• Ignorer les tentatives. Un appel échoué qui est réessayé consomme toujours du quota de requêtes, et souvent aussi des jetons, de sorte que les intégrations sujettes aux erreurs coûtent plus cher que ne le suggèrent les calculs du chemin heureux.
• Sauter le reste du pipeline. Une fonctionnalité RAG ou agent ajoute généralement des requêtes d'intégration, des appels de recherche vectorielle et parfois un modèle de routage plus petit, chacun étant facturé séparément, séparément des jetons du modèle principal.

Continuer à apprendre

Questions fréquemment posées

Quelle est la différence entre un token et une requête API ?

Une requête API est un appel unique au point de terminaison ; les jetons sont les unités de texte à l'intérieur. Une requête peut contenir très peu de jetons, voire des centaines de milliers. Les LLM facturent par jeton, tandis que de nombreuses autres API facturent par requête.

Combien de jetons représente un message de chatbot typique ?

Un court message utilisateur plus une invite système représentent souvent quelques centaines de jetons d'entrée et une réponse quelques centaines de jetons de sortie - environ 500 à 1 000 jetons par échange, bien que cela varie en fonction de la longueur de l'invite et de la verbosité de la réponse.

Comment puis-je estimer mon utilisation mensuelle de tokens ?

Multipliez les jetons par appel par les appels par utilisateur par le nombre d'utilisateurs. Estimez les jetons d'entrée et de sortie séparément, car leur prix est différent, puis exécutez le total via un calculateur de coût de jeton pour le modèle que vous avez choisi.

Un token coûte-t-il le même prix, qu’il soit en entrée ou en sortie ?

Non : le prix des jetons de sortie est généralement plus élevé que celui des jetons d'entrée pour le même modèle, souvent 3 à 5 fois plus. En séparant les totaux des entrées et des sorties, plutôt que de les fusionner en une seule moyenne, on obtient une estimation des coûts beaucoup plus précise.

À part les jetons du modèle principal, que dois-je prévoir dans mon budget ?

Dans un pipeline RAG ou d'agent, le budget pour l'intégration des requêtes, les requêtes de base de données vectorielles et tout appel de modèle de routage ou de classification plus petit — chacun est facturé séparément des jetons du modèle principal et peut s'additionner sur une fonctionnalité à volume élevé.

Les limites de débit prennent-elles en compte les requêtes ou les jetons ?

Habituellement, les deux à la fois : les fournisseurs fixent un plafond de requêtes par minute (RPM) et un plafond de jetons par minute (TPM) distincts, et vous atteignez celui que votre modèle de trafic sature en premier. Les appels courts à haute fréquence ont tendance à atteindre le RPM en premier ; les appels à basse fréquence et à contexte long ont tendance à atteindre le TPM en premier.