Ce que révèle un pic de 2 122 tokens par seconde — et ce qu’il ne dit pas

Le 27 septembre, NaiveAI a publié son article technique sur Naive-N0.5-Flash. Selon ses chiffres, NaiveRT, optimisé pour le décodage d’un flux unique dans les rollouts d’apprentissage par renforcement, atteint 2 122 tokens par seconde grâce à un modèle d’ébauche DFlash fusionné utilisé pour le décodage spéculatif. Les conditions annoncées comptent : huit GPU, la meilleure fenêtre d’une seconde parmi 41 requêtes HTML/SVG, le mode de réflexion désactivé et le préremplissage (prefill) exclu. Il s’agit d’une mesure du développeur lui-même, que SlateMoth n’a pas reproduite de manière indépendante. [1]

La question utile est de savoir quelle part de l’attente réelle de l’utilisateur couvre cette mesure. Un débit de décodage maximal ne décrit qu’une partie d’une requête. Il ne dit pas directement combien de temps prend l’achèvement d’une modification de code, d’un rapport ou d’une tâche confiée à un agent. Pour les équipes qui évaluent des modèles, distinguer ces questions permet d’apprécier équitablement un résultat d’ingénierie prometteur.

Nous proposons trois horloges. La première va de l’envoi de la requête à la première sortie exploitable, en comptant l’attente et le traitement de l’entrée perçus par la personne qui l’a envoyée. La deuxième mesure le temps de génération restant, de cette première sortie à la fin de la réponse. La troisième suit la tâche entière, de son lancement à son acceptation, avec les appels d’outils, les tests et les nouvelles tentatives nécessaires. Améliorer une partie de cette chronologie ne réduit pas forcément le temps total dans la même proportion.

Prenons une tâche hypothétique de modification de code : charger le projet et obtenir la première sortie prend 12 secondes, la génération en prend 8 et les tests, 40. Même si la génération devient quatre fois plus rapide, le total ne passe que de 60 à 54 secondes, soit un gain de 10 %. Ces chiffres sont illustratifs et ne proviennent pas de mesures de NaiveAI. Il faut d’abord mesurer où passe le temps avant d’appliquer à tout le flux de travail une accélération mise en avant.

Un pic bref ne montre pas non plus si la génération garde cette vitesse tout au long d’une réponse longue ou lorsque plusieurs requêtes arrivent en même temps. Demandez le temps des réponses complètes et la distribution des latences à la charge prévue par votre équipe. Distinguez la vitesse d’une requête isolée du débit global : traiter davantage de requêtes par seconde et terminer plus tôt la tâche d’une personne répondent à des besoins différents.

La fiche du modèle indique 309 milliards de paramètres au total et 15,5 milliards de paramètres actifs. Ses indications pour un déploiement en FP8 précisent que les poids occupent environ 315 Go et que l’inférence demande de la mémoire GPU supplémentaire. Elles précisent aussi que la conception à attention parcimonieuse conserve l’intégralité du cache KV. Ces détails évitent un contresens fréquent : le nombre de paramètres actifs ne signifie pas que le modèle complet tient dans la mémoire nécessaire à un modèle dense de cette taille. [2]

Pour décider d’un déploiement, consignez les poids et la précision réellement utilisés, le matériel et ses interconnexions, la version du moteur d’exécution, la longueur de contexte et le nombre de requêtes simultanées. Mesurez ensuite l’usage de la mémoire et les échecs sur cette configuration. Réduire le nombre de paramètres mobilisés pour le calcul peut être utile sans rendre chaque déploiement léger. La quantification, le déchargement vers une autre mémoire ou un autre moteur de service doivent être évalués comme des configurations distinctes ; leurs performances ne peuvent pas être déduites du pic initial.

Une limite liée à la publication doit rester visible. L’article technique présente NaiveRT comme un logiciel open source, mais indique également que le contenu du code source mentionné sera disponible au plus tard le 12 octobre. Lors de notre vérification, le 28 septembre, le dépôt NaiveRT indiqué renvoyait une erreur 404. Nous n’avons donc pas pu examiner à cette adresse le moteur d’exécution ni ses scripts de mesure des performances. Cela ne prouve ni que le résultat est faux ni qu’aucun poids du modèle n’est disponible. Cela limite ce que nous pouvons vérifier aujourd’hui. [1] [3]

Tant que les documents pertinents ne peuvent pas être examinés et l’expérience répétée, il faut traiter cette vitesse comme un résultat annoncé par le développeur dans des conditions précises. Désactiver le mode de réflexion pour ce test de vitesse ne démontre pas non plus les performances sur des tâches qui exigent un raisonnement prolongé. La qualité et le temps doivent être mesurés ensemble dans le mode réellement employé pour la tâche.

Commencez par un petit ensemble de tâches représentatives et définissez la réussite avant de les lancer. Pour une modification de code, cela peut signifier que le comportement demandé fonctionne, que les contrôles de régression réussissent et qu’aucun fichier sans rapport n’est modifié. Pour un document, cela peut vouloir dire que les faits requis sont présents et que les citations les étayent. Mesurez la tentative entière, avec ses échecs et ses reprises, au lieu de ne retenir que la réalisation la plus impressionnante.

Gardez le même ensemble de tâches, les mêmes autorisations d’outils et les mêmes critères d’acceptation lorsque vous changez de modèle ou de configuration de service. Relevez le délai avant la première sortie, le temps total écoulé, le taux de tâches acceptées et le coût par tâche acceptée. Incluez des entrées courtes et longues, la concurrence habituelle et des essais répétés. Un échantillon rapide peut justifier de poursuivre l’examen ; il ne décrit pas l’expérience de tous les utilisateurs.

Le cas le plus favorable à un décodage plus rapide est une charge de travail où la génération représente vraiment l’essentiel de l’attente. Une génération longue et surtout séquentielle peut en profiter sensiblement si la qualité se maintient. Un flux de travail dominé par la recherche d’informations, des outils lents ou la révision humaine peut en profiter moins. Ces deux constats n’enlèvent rien au travail d’ingénierie ; ils indiquent où le tester d’abord.

Le rapport de NaiveAI donne aux équipes une hypothèse concrète à vérifier : une autre conception de l’inférence pourrait raccourcir les tâches dominées par la génération. Nous avons lu sa méthodologie publiée, mais n’avons ni exécuté le modèle ni reproduit le pic. Les prochaines preuves à rechercher sont un code du moteur d’exécution accessible, une configuration reproductible et des résultats sur des tâches représentatives. Une décision d’adoption utile repose sur la rapidité avec laquelle un système livre un résultat acceptable pour votre charge de travail.