Cerebras sert Qwen 3.8 27B à 1500 tokens/s, et l'agent n'attend plus

La doc affiche 1500 tokens par seconde

Relevé le 3 septembre 2026 sur la page « Models » de la documentation d’inférence Cerebras, le tableau des modèles publics tient en deux lignes. Qwen 3.8 27B, identifiant qwen-3.8-27b, 27 milliards de paramètres, une fenêtre de contexte de 64 k tokens en offre gratuite et 128 k en payant, vitesse annoncée à environ 1500 tokens par seconde. Juste au-dessus, gpt-oss-120b : 120 milliards de paramètres, 65 k / 131 k, et environ 3000 tokens par seconde. Le modèle quatre fois plus gros va deux fois plus vite, ce qui vous dit assez clairement que ce chiffre ne décrit pas le modèle, mais la machine qui le sert.

Ce que ça change quand c’est un agent qui lit

Sur un chatbot, la vitesse est un confort : vous lisez à quelques dizaines de tokens par seconde, tout ce qui dépasse tombe par terre. Sur une boucle agentique, personne ne lit. Le modèle produit un appel d’outil, encaisse le résultat, repart pour un tour, et recommence dix ou quinze fois avant de rendre quoi que ce soit d’utile. Chaque tour est du texte jeté aussitôt qu’écrit, et l’attente s’additionne à chaque itération.

À 1500 tokens par seconde, une étape de 2000 tokens sort en un peu plus d’une seconde. La différence entre un agent qui met trois minutes et un agent qui en met vingt n’est pas cosmétique : dans le premier cas vous restez devant, dans le second vous ouvrez un autre onglet et l’outil a perdu.

Un modèle servi entier, ce qui mérite d’être dit

La même page consacre une section entière à l’état de compression des modèles, et c’est peut-être l’information la plus utile pour qui compare des fournisseurs. Cerebras y déclare ne servir sur ses points d’accès publics que les versions originales, non élaguées. La quantification est décrite comme appliquée aux poids seulement et au stockage, en 16, 8 ou 4 bits, les couches sensibles restant en pleine précision avec déquantification à la volée ; activations, attention et cache KV restent non quantifiés.

Ses modèles élagués par la technique REAP existent, mais sur Hugging Face, pour la recherche, et pas derrière l’API. La page s’engage aussi à ne pas modifier l’architecture d’un modèle existant sans prévenir, et à nommer explicitement d’éventuels futurs points d’accès élagués. C’est le genre de promesse qu’on ne peut vérifier qu’après coup, mais elle a le mérite d’être écrite.

Ce que la page ne dit pas

Rien sur le GPU d’en face. Aucun comparatif, aucun protocole de mesure, aucune précision sur ce qui est chronométré — les deux chiffres portent un tilde, ce qui est déjà une forme d’honnêteté. Rien non plus sur la latence du premier token, qui compte autant que le débit dans une boucle d’agent, ni sur la qualité des réponses, qu’aucun tokens/seconde ne mesure. Et rien sur le silicium : la doc vend un débit, pas une architecture. Les deux modèles sont accessibles en essai gratuit et à l’usage, sous réserve de limites de débit et de tarification ; le reste passe par des points d’accès dédiés, c’est-à-dire par un commercial.

Reste la question que la documentation ne pose pas : un agent deux fois plus rapide vous fait gagner du temps, ou vous fait juste atteindre deux fois plus vite la conclusion que le prompt était mauvais.