Tokens par seconde : mesurer la vitesse réelle d’un LLM

Que mesure le débit en tokens par seconde ?

Le débit de sortie en tokens par seconde mesure la vitesse à laquelle un LLM transmet les tokens générés après l’arrivée du premier token. Un grand modèle de langage, ou LLM, traite le texte sous forme de tokens : des unités qui peuvent correspondre à des mots, à des fragments de mots ou à des signes de ponctuation. Compter les tokens ne revient donc pas à compter les mots selon une règle universelle. La définition de Cerebras souligne cette distinction.

Imaginez que vous allez chercher plusieurs livres dans une bibliothèque. Le temps passé à attendre l’ouverture de la porte et le rythme auquel on vous remet les livres sont deux choses différentes. Tous deux déterminent quand vous pourrez repartir avec ce qu’il vous faut. Une remise rapide des livres n’efface pas une longue attente devant la porte.

Pour une application, distinguez les mesures suivantes :

Ces bornes reprennent les définitions des métriques d’Artificial Analysis. Le premier token de raisonnement peut arriver avant le premier token de réponse : ces délais doivent donc porter des noms distincts.

La latence de bout en bout de votre application commence à l’action de l’utilisateur et se termine lorsqu’il obtient un résultat utile. Pour un assistant vocal, ce résultat peut être une réponse audible ; pour un agent, une action accomplie. La recherche d’informations, l’exécution d’outils, la synthèse vocale et la mise à jour de l’interface peuvent se dérouler en dehors de la requête au modèle. Instrumentez aussi ce parcours complet.

Les étapes sous-jacentes sont le prefill, qui traite le prompt, et le decode, qui génère la suite. Le guide de l’inférence des LLM suit ces opérations dans le système qui exécute le modèle.

Pourquoi un seul chiffre ne suffit-il pas à décrire la vitesse ?

Un résultat de vitesse décrit une charge de travail sur un point d’accès donné. Ce n’est pas une propriété du modèle valable en toutes circonstances. Dès que le travail demandé ou les conditions d’exécution changent, la comparaison change aussi.

Longueur du prompt et contexte en cache

Une courte question posée à un assistant de support ne représente pas le même travail que cette question accompagnée d’un long historique et de documents internes récupérés pour y répondre. Un volume d’entrée plus important modifie le travail à effectuer avant la réponse. Dans son guide de la latence, Groq cite la taille de l’entrée parmi les facteurs qui influencent le TTFT.

Consignez la longueur du prompt et l’état du cache dans vos résultats de test. Le guide du cache KV explique l’état d’attention conservé pendant la génération et le lien entre réutilisation des prompts et mise en cache. Un prompt répété dont le cache est déjà alimenté ne doit pas se substituer sans le dire à une nouvelle conversation client.

Le raisonnement avant la réponse

Un modèle de raisonnement peut produire des tokens intermédiaires avant de livrer sa réponse. Une génération rapide ne dit rien de la quantité de raisonnement qu’il effectuera. Vérifiez si la vitesse annoncée inclut ce flux et si le chronomètre du premier token s’arrête sur le raisonnement ou sur le texte de la réponse.

Pour un assistant de réservation, l’événement utile est une réponse exploitable ou un appel d’outil. Un indicateur de réflexion peut signaler que la demande a bien été reçue, mais il ne finalise pas la réservation.

Traitement par lots et requêtes simultanées

Le traitement par lots regroupe des tâches pour mieux utiliser le matériel. Le débit global additionne la sortie de plusieurs requêtes ; la vitesse par utilisateur décrit le flux reçu pour une requête donnée. Cerebras précise que le traitement par lots peut augmenter le débit tout en ajoutant du temps d’attente. Source : explication du débit par Cerebras.

La question à se poser en exploitation est simple : chaque conversation continue-t-elle d’avancer quand d’autres arrivent ? Mesurez un trafic simultané représentatif, en incluant les requêtes en échec et les nouvelles tentatives. Un bon résultat obtenu sur un point d’accès par ailleurs inactif ne répond pas à cette question.

Région d’hébergement et acheminement du flux

La localisation de votre application et du point d’accès qui exécute le modèle influe sur le délai réseau. Dans ses conseils d’analyse du réseau, Groq distingue les durées mesurées côté serveur de la latence vécue côté client.

Effectuez vos mesures depuis la région où tourne votre backend. Si votre application relaie le flux vers un navigateur, ajoutez une mesure dans le navigateur : la mise en tampon entre ces deux points peut transformer une réponse régulière en amont en arrivées par à-coups. Corriger ce trajet peut compter davantage que changer de modèle.

Combien de tokens par seconde pour un GPU ?

Un GPU, l’accélérateur qui exécute l’inférence, n’a pas de vitesse en tokens par seconde qui soit pertinente indépendamment du modèle et de la charge de travail. Pour comparer du matériel, il faut accompagner le résultat du modèle utilisé, de la précision numérique, du contexte, de la configuration d’exécution et de la charge simultanée.

La quantification réduit la précision numérique pour économiser de la mémoire ; ses compromis entre vitesse et qualité dépendent de l’implémentation. Cerebras documente cette distinction dans son explication de la compression des modèles. Consultez le guide de la quantification des LLM pour comparer des déploiements compressés, et conservez un contrôle de la qualité des réponses à côté des mesures de temps.

Comment lire les vitesses annoncées par les fournisseurs ?

Traitez les vitesses publiées comme des affirmations attribuées à leur source, associées à un modèle et à une date. Les pages des fournisseurs ci-dessous ont été vérifiées le 24 octobre 2026. Il s’agit de leurs chiffres, et non de mesures réalisées pour cet article.

Cerebras : une vitesse annoncée à replacer dans son offre

Cerebras, fournisseur de services d’inférence, affiche « ~3000 tokens/s » pour OpenAI GPT-OSS 120B dans son tableau Developer. La même page précise que les performances varient selon le modèle et la configuration, et présente l’accès Developer comme destiné à l’évaluation plutôt qu’à la production. Source : tarifs de Cerebras.

Ce qui compte, c’est de savoir si le déploiement que vous pouvez acheter traite votre charge de travail avec la réactivité et la capacité nécessaires. Le tableau seul ne permet pas de le déterminer.

Groq : lire le débit à la ligne du modèle concerné

Groq, fournisseur de services d’inférence, indique « 500 » dans la colonne « SPEED (T/SEC) » pour OpenAI GPT-OSS 120B dans son tableau des modèles pris en charge. C’est le chiffre publié par Groq pour cette ligne. Source : modèles pris en charge par Groq.

Ces tableaux ne permettent pas d’établir un rapport de vitesse entre les fournisseurs pour votre application. Avant de l’affirmer, il faut encore aligner les prompts, les réglages du raisonnement, le comptage des tokens, la charge et les bornes de mesure.

Pour arbitrer entre vitesse et coût, comparez le prix d’une tâche réussie et la capacité dont vous avez besoin à l’aide du guide des tarifs de Cerebras et du guide des tarifs de Groq.

Où trouver des mesures indépendantes ?

Artificial Analysis, service indépendant de benchmarks, constitue un point de départ utile pour comparer modèles et fournisseurs d’inférence. Ouvrez son classement des fournisseurs, puis examinez le point d’accès et la charge de travail derrière chaque résultat.

Sa méthodologie de mesure des performances précise actuellement les éléments suivants :

• Une charge de travail par défaut d’environ 10 000 tokens en entrée et d’au moins 1 500 tokens de réponse.
• Des résultats correspondant à la médiane des 72 dernières heures pour les charges de travail habituelles.
• Un serveur de test principal dans la zone us-central1-a de Google Cloud.
• Un comptage des tokens normalisé avec o200k_base, plutôt qu’avec le tokenizer propre à chaque modèle.

Vous disposez ainsi d’un repère commun, pas d’une promesse de résultat pour votre application. Avant de comparer, vérifiez la taille du prompt, le point d’accès, le mode de raisonnement et la date. Des prompts plus longs peuvent modifier à la fois le délai avant le premier token et la vitesse de sortie.

Pour les modèles qui masquent une partie de leurs tokens de raisonnement, Artificial Analysis calcule le débit de sortie à partir des 80 % de fragments de réponse reçus en dernier. Le script simple ci-dessous ne reproduit ni cette méthode ni l’ensemble de la charge du benchmark. Il mesure le flux de texte que vous observez.

Comment mesurer vous-même le flux reçu ?

Mesurez côté client, à la réception, et comptez les tokens du texte plutôt que les événements du flux. Un événement peut ne contenir aucun texte ou en regrouper tout un fragment ; compter les événements donne un nombre de fragments par seconde.

L’exemple Python suivant utilise l’API de streaming de Groq et tiktoken, un outil de tokenisation du texte. Il affiche le délai avant le premier fragment de texte, la durée entre la requête et le dernier texte reçu, le temps jusqu’à la fermeture du flux et une estimation du débit de sortie en tokens par seconde normalisés.

Installez les dépendances :

python3 -m pip install groq tiktoken

Définissez GROQ_API_KEY dans votre environnement. Affectez à GROQ_MODEL un modèle de texte sans raisonnement, accessible à votre compte et figurant dans la liste des modèles pris en charge par Groq. Placez un prompt représentatif de votre application dans prompt.txt. Enregistrez ce script dans measure_stream.py, puis lancez python3 measure_stream.py.

import os
from pathlib import Path
from time import perf_counter

import tiktoken
from groq import Groq

encoder = tiktoken.get_encoding("o200k_base")
prompt = Path("prompt.txt").read_text(encoding="utf-8")
model = os.environ["GROQ_MODEL"]
parts = []
first = last = None

with Groq(max_retries=0) as client:
    start = perf_counter()
    stream = client.chat.completions.create(
        model=model,
        messages=[{"role": "user", "content": prompt}],
        stream=True,
    )
    for event in stream:
        now = perf_counter()
        if not event.choices:
            continue
        text = event.choices[0].delta.content or ""
        if not text:
            continue
        if first is None:
            first = now
        last = now
        parts.append(text)
    end = perf_counter()

if first is None:
    raise SystemExit("No text received; no text-speed measurement.")

# Tokenize after timing; never count events as tokens.
count = lambda text: len(encoder.encode(text, disallowed_special=()))
total_tokens = count("".join(parts))
post_first_tokens = total_tokens - count(parts[0])
span = last - first

print(f"First text chunk / TTFT estimate (s): {first - start:.3f}")
print(f"Request to last text (s): {last - start:.3f}")
print(f"Stream complete (s): {end - start:.3f}")
print(f"Normalized output tokens: {total_tokens}")
if span > 0 and post_first_tokens > 0:
    print(f"Post-first output tok/s (estimate): {post_first_tokens / span:.1f}")
else:
    print("Output tok/s unavailable: insufficient text delivery intervals.")

Le SDK Groq permet de désactiver les nouvelles tentatives automatiques. Cet exemple les désactive pour éviter que l’attente liée à une nouvelle tentative soit discrètement incluse dans une mesure présentée comme réussie ; une requête en échec doit être enregistrée comme telle.

Le calcul du débit exclut le premier fragment de texte du nombre de tokens comme de l’intervalle de réception. Il suit la formule par fragments donnée dans les définitions d’Artificial Analysis. Il ignore également les métadonnées reçues en fin de flux pour repérer l’arrivée du dernier texte.

Utilisez cet exemple pour du texte simple. Un flux de raisonnement, des arguments d’appel d’outil ou de l’audio nécessitent un traitement adapté à leurs types d’événements et une définition de la première sortie utile. Pour comparer, conservez le prompt et les réglages, notez la longueur de la sortie et répétez les mesures depuis votre région de déploiement, sous une charge représentative. Gardez les résultats habituels comme les plus lents ; ne transformez pas le meilleur essai en garantie.

Que peut-on déduire d’un calculateur ou d’un simulateur ?

Un outil de planification peut illustrer une hypothèse de durée ; il ne peut pas découvrir la latence de votre point d’accès.

À quoi sert un simulateur de tokens par seconde ?

Utilisez un simulateur pour décider si une interface de chat doit afficher le texte à mesure qu’il arrive ou attendre un objet complet. Validez ensuite ce choix avec un flux réellement observé. Un débit simulé constant ne permet pas de savoir si votre réponse réelle marque des pauses, arrive par à-coups ou attend un outil.

Pour une réponse textuelle terminée, le calcul est simple : la durée entre la requête et le dernier texte reçu est égale à l’attente initiale plus l’intervalle entre le premier et le dernier texte. Le script mesure ces deux intervalles au lieu de les déduire d’un débit annoncé.

Quel débit en tokens par seconde faut-il viser ?

La bonne cible dépend des moments où la tâche impose d’attendre. Définissez-la en répondant à des questions sur l’expérience que vous construisez.

Pour un assistant vocal : combien de temps la personne attend-elle entre la fin de sa phrase et une réponse audible et utile ? La synthèse vocale peut-elle commencer avant que la réponse entière soit rédigée ? Le tampon audio se vide-t-il ? La personne peut-elle interrompre l’assistant ? Si le silence précède l’arrivée du texte, un décodage plus rapide risque de ne rien changer au problème principal.

Pour une interface de chat : l’utilisateur attend-il la première phrase utile, l’explication complète ou un résultat structuré valide ? L’interface peut-elle afficher une sortie partielle ? Une réponse de support et un rapport exportable n’ont pas le même critère de fin. Mesurez l’événement dont votre interface a besoin.

Pour l’exploitation d’un agent : quelle part de la tâche relève de la génération du modèle, et quelle part de l’exécution d’outils ? Une réponse plus rapide préserve-t-elle la justesse des arguments transmis aux outils et la réussite de la tâche ? L’étape suivante attend-elle la sortie entière ? Accélérer le mauvais intervalle peut laisser la durée totale du workflow presque inchangée.

Pour le choix d’un fournisseur : le déploiement proposé peut-il maintenir l’expérience attendue avec votre trafic, depuis votre région et avec vos prompts ? Le résultat annoncé est-il représentatif de ce déploiement ? Que se passe-t-il quand des requêtes échouent ou que la capacité est occupée ?

Agissez dès que les traces montrent que les utilisateurs attendent la génération ou la première réponse utile. Reportez une migration de fournisseur tant que le délai dominant n’a pas été isolé. Pour une tâche en arrière-plan qui respecte déjà son échéance, une vitesse annoncée plus élevée change peu de choses, sauf si le débit global ou le coût d’une tâche réussie modifie la décision.

Quelles promesses exagère-t-on sur la vitesse des LLM ?

L’exagération principale consiste à faire du débit de sortie le plus élevé le critère qui désigne le meilleur point d’accès pour une application. La vitesse ne prouve ni la qualité des réponses, ni la validité des sorties, ni la bonne utilisation des outils.

Même le point d’accès le plus rapide se heurte aux limites de l’application qui l’entoure. Générer du texte plus vite ne corrige ni un appel lent à une base de données, ni un raisonnement inutilement long, ni une réponse qui échoue à la validation. À l’inverse, un excellent délai avant le premier token peut masquer un flux qui se bloque avant de fournir quoi que ce soit d’utile.

Gardez la vitesse parmi vos critères d’évaluation, mais fixez la ligne d’arrivée à un résultat correct et exploitable.

Questions fréquentes

La prochaine étape pour votre application

Pour votre prochaine itération, choisissez un exemple représentatif : un échange vocal, un prompt de chat ou une tâche d’agent. Définissez ensuite ce qui rend son résultat exploitable. Instrumentez cet événement, ainsi que la première sortie et la fin du flux. Comparez les points d’accès envisagés sur la même tâche, examinez les échecs et optimisez l’intervalle qui fait attendre votre utilisateur.

Pour recevoir des guides pratiques sur la création d’applications d’IA utiles, abonnez-vous à la newsletter.