Les tokens par seconde (tokens/s) mesurent la vitesse de génération d’une IA. C’est un indicateur de confort, pas une note de qualité. Voici comment le lire, ce qui le fait chuter, et comment en parler sans faux tableaux universels ni chiffres magiques inventés pour toutes les machines et tous les usages.
Définition
Un token est une unité de découpage du texte (morceau de mot, ponctuation, etc.). Les tokens par seconde mesurent le débit de génération : combien de ces unités sortent chaque seconde pendant la réponse. Les outils locaux (Ollama, LM Studio, etc.) affichent souvent ce chiffre après une génération. Il résume une partie du ressenti « mon IA est rapide » ou « elle rampe ».
Ce que le mot ne désigne pas : ce n’est pas la qualité factuelle, ni la taille du modèle, ni la VRAM elle-même. Un modèle lent peut être juste ; un modèle rapide peut halluciner. Ce n’est pas non plus le temps avant le premier token (latence au démarrage de la réponse), même si les deux affectent le confort. Distinguez débit de génération et délai d’attente initial.
Le chiffre dépend du moteur, du modèle, de la quantification, du contexte déjà rempli, du batch, et du matériel. Un ordre de grandeur « confortable pour discuter » se situe souvent dans une zone où le texte apparaît de façon fluide à l’écran — mais il n’existe pas de seuil universel honnête pour tous les usages. Mesurez chez vous, sur votre tâche. Notez aussi le matériel et la version du moteur : un même fichier peut afficher des débits différents selon l’offload CPU/GPU.
Un exemple du quotidien
Pensez à la vitesse de frappe d’un collègue qui dicte à voix haute ce qu’il écrit. Si les mots arrivent trop lentement, la conversation devient pénible même si le contenu est bon. Les tokens/s jouent ce rôle de débit de parole de l’IA. Pour un mail court, une vitesse modeste suffit. Pour itérer dix reformulations, le débit devient un vrai critère de productivité.
À l’inverse, un débit très élevé sur une mauvaise réponse ne sauve rien : vous relisez plus vite du texte à corriger. D’où la règle IAHDF : mesurez d’abord l’utilité sur la tâche, puis la vitesse. Optimiser les tokens/s sans regarder la justesse, c’est régler le volume d’une radio qui diffuse la mauvaise station.
Un exemple en Hauts-de-France
À Liévin, une graphiste freelance fait tourner un petit modèle local pour reformuler des briefs clients. Sur son portable, elle note les tokens/s affichés par l’outil après chaque essai de quantification. Un fichier un peu plus compressé reste assez bon sur le style et défile plus agréablement. Elle documente le choix : « confort de frappe » avant « plus gros modèle théorique ».
À Wasquehal, une TPE de services compare un cloud rapide et un poste local. Le cloud gagne souvent en débit perçu ; le local gagne en maîtrise des données. L’équipe décide selon le type de texte (sensible ou non). La métrique tokens/s sert d’argument factuel dans la discussion, pas de totem. On croise avec le matériel avant tout achat impulsif.
On confond souvent
Première confusion : comparer des tokens/s trouvés sur Internet comme des records sportifs. Sans le même modèle, la même quantification, le même contexte et le même GPU, la comparaison est fragile. Préférez vos mesures locales. Méfiez-vous des captures d’écran sans méthode.
Deuxième confusion : croire que monter les tokens/s améliore toujours le raisonnement. Un modèle de raisonnement peut paraître plus lent justement parce qu’il génère davantage avant la réponse utile. Autre mélange : confondre tokens/s et bande passante réseau. En local pur, le réseau compte peu ; en API cloud, la latence réseau s’ajoute.
En pratique, que faire avec ce mot
Quand vous choisissez un outil ou un modèle, fixez un protocole simple : même prompt, même longueur de sortie cible, trois essais, notez tokens/s et ressenti. Changez une seule variable à la fois (quantification, taille, contexte). Gardez la config la plus fluide qui reste assez juste sur vos textes.
Si le débit s’effondre, regardez d’abord le contexte trop long, la VRAM saturée, un modèle trop gros, ou d’autres apps GPU. Croisez VRAM, quantification et inférence locale. Pour un serveur multi-utilisateurs, d’autres moteurs comme vLLM optimisent le débit agrégé — ce n’est pas le même problème qu’un PC solo.
Pour comparer deux machines ou deux modèles, notez les tokens par seconde sur la même invite, à contexte comparable, après un premier échauffement. Une mesure unique trompe ; trois essais donnent déjà une tendance. Partagez le protocole dans l’équipe pour éviter les débats fondés sur une sensation de fluidité un jour de charge système différente. La vitesse sert le confort ; elle ne valide pas le fond des réponses.
Termes voisins
| Terme | Rôle utile |
|---|---|
| Token | Unité de texte découpée par le modèle ; base du débit. |
| Latence TTFT | Temps jusqu’au premier token ; distinct du débit moyen. |
| VRAM | Mémoire GPU ; saturation = chute fréquente du débit. Voir VRAM. |
| Contexte | Plus il est rempli, plus le calcul peut ralentir. Voir contexte long. |
Pour aller plus loin
Pour dimensionner la machine, lisez le matériel et l’inférence locale. Rencontres IAHDF : l’agenda. Pour rejoindre la communauté : l’inscription.
Questions fréquentes
Mon IA locale est-elle assez rapide ?
Assez rapide signifie : vous restez productif sur vos tâches sans impatience constante. Il n’y a pas de chiffre unique universel. Pour du chat de reformulation, un débit qui fait défiler le texte de façon lisible suffit souvent. Pour de très longues générations fréquentes, vous serez plus exigeant. Mesurez sur vos prompts réels, pas sur un benchmark anonymisé de forum. Notez le choix, testez sur vos textes, et faites relire un humain avant tout envoi engageant.
Quel est un bon nombre de tokens par seconde ?
Tout chiffre présenté comme universel est suspect. Le confort dépend de la langue, de la longueur des réponses, et de votre tolérance. Certains usages restent acceptables à bas débit ; d’autres demandent plus de fluidité. Préférez des ordres de grandeur personnels : notez ce qui vous paraît fluide sur votre machine, puis visez à ne pas redescendre sous ce ressenti après un changement de modèle. Notez le choix, testez sur vos textes, et faites relire un humain avant tout envoi engageant.
Pourquoi les tokens/s chutent en cours de conversation ?
Souvent parce que le contexte grossit : plus d’historique à prendre en compte, plus de calcul. Un contexte long, des images, ou un mode raisonnement allongent aussi le travail. Réinitialiser le fil, résumer l’historique, ou réduire la fenêtre aide parfois. Vérifiez aussi que la mémoire GPU n’est pas au bord du swap. Notez le choix, testez sur vos textes, et faites relire un humain avant tout envoi engageant. Conservez la version d’outil et du modèle pour pouvoir expliquer la décision à un collègue.
Tokens/s plus élevés = meilleur modèle ?
Non. Un petit modèle quantifié peut être très rapide et limité sur des tâches complexes. Un grand modèle plus lent peut être plus utile — s’il tient correctement. Optimisez d’abord la pertinence, puis la vitesse. Sinon vous choisirez le perroquet le plus véloce. Notez le choix, testez sur vos textes, et faites relire un humain avant tout envoi engageant. Conservez la version d’outil et du modèle pour pouvoir expliquer la décision à un collègue.
Comment mesurer correctement chez moi ?
Utilisez le compteur de votre outil s’il existe. Lancez le même prompt plusieurs fois après un warm-up (premier run parfois plus lent). Notez modèle, quantification, longueur de contexte, et apps ouvertes. Gardez une petite feuille de route dans votre documentation interne. C’est plus honnête qu’un tableau internet non sourcé. Notez le choix, testez sur vos textes, et faites relire un humain avant tout envoi engageant. Conservez la version d’outil et du modèle pour pouvoir expliquer la décision à un collègue.