Le benchmark Qwen3.8 Basalt rapporte 153 tokens par seconde avec 16 Go de VRAM

Des résultats du benchmark Qwen3.8 Basalt publiés le 25 octobre font état de 153 tokens par seconde sur une RTX 5080, malgré sa limite de 16 Go de mémoire graphique. La station de travail utilisait également 54,1 Go de mémoire système. Le titre du post met en avant une génération supérieure à 250 tokens par seconde, mais ce chiffre décrit un bref pic plutôt qu’un débit soutenu.

Cette distinction compte pour les développeurs qui envisagent des assistants de programmation locaux. Selon l’auteur du post, la session a traité 103 requêtes, tandis qu’un test distinct a utilisé de nouveaux prompts à différentes longueurs de contexte. Ces charges de travail apportent des éléments utiles sur la réactivité, même si aucune ne permet d’établir la précision en programmation ni des performances vérifiées indépendamment.

La question centrale consiste à faire tenir un grand modèle dans une station de travail tout en préservant une vitesse utile et une qualité de sortie acceptable. Basalt, un moteur d’inférence spécialisé, est en concurrence sur cette charge de travail avec Strata et des alternatives plus généralistes telles que llama.cpp. Ce rapport justifie un examen plus approfondi de cette approche, plutôt qu’une affirmation générale selon laquelle la capacité de mémoire graphique n’a plus d’importance.

Le benchmark Qwen3.8 Basalt distingue les pics de la vitesse soutenue

Les chiffres de génération les plus utiles sont les moyennes rapportées : 153,0 tokens par seconde durant la programmation et 154,9 lors du balayage de contexte.

Un token est une unité de texte traitée ou produite par un modèle de langage. Les tokens par seconde mesurent le débit, mais ne mesurent pas directement si le code généré fonctionne. La distinction établie par l’auteur entre débit moyen et débit de pointe mérite d’accompagner chaque résumé de ces résultats.

Le benchmark RTX 5080 identifie la configuration du modèle comme Qwen3.8-Flash-Next IQ3_S. IQ3_S est un format de quantification, ce qui signifie qu’il représente les poids du modèle avec une précision numérique réduite. Cette configuration fait partie de l’identité du résultat, et n’est pas un détail interchangeable.

La station de travail rapportée associait une RTX 5080 à un processeur Core Ultra 9 285K et 62 Go de mémoire DDR5-6800. La consommation de mémoire graphique a atteint 15,7 Go. Le moteur aurait occupé 54,1 Go de mémoire système, laissant 5,2 Go libres pendant la programmation et 5,1 Go pendant le balayage.

La session de programmation utilisait opencode, une interface d’agent de programmation, sur 103 requêtes et a atteint environ 130 000 tokens de contexte. Le contexte correspond aux informations dont dispose le modèle lorsqu’il produit une réponse. La source fait état d’une capacité configurée d’environ 262 000 tokens, supérieure à la profondeur observée lors de la session de programmation.

Selon l’auteur du post, la génération a atteint en moyenne 153,0 tokens par seconde, calculés sur les tokens générés et le temps de décodage. Le temps de décodage est la période consacrée à la production des tokens de sortie. Le pic rapporté de 262 tokens par seconde correspond à la meilleure seconde individuelle, plutôt qu’à une requête ou une session complète.

Le balayage distinct utilisait de nouveaux prompts allant d’environ 15 000 à 207 000 tokens. Sa moyenne de génération a atteint 154,9 tokens par seconde, avec un pic de 186,6. L’auteur décrit ces mesures comme des moyennes par requête, avec des réponses de 384 tokens, une température d’échantillonnage de 0,7 et deux exécutions par profondeur.

Ces définitions évitent une interprétation trompeuse. Un maximum sur une seule seconde et une moyenne au niveau d’une requête décrivent des observations différentes. Aucun ne doit remplacer l’autre simplement parce que tous deux utilisent les tokens par seconde.

Les chiffres soutenus rendent également ce rapport plus intéressant que son seul titre ne le suggère. Un flux de travail de programmation nécessite des réponses cohérentes au fil d’interactions répétées. Une brève accélération aide à caractériser le système, mais les développeurs font en définitive l’expérience de requêtes complètes, d’interruptions, d’exécution d’outils et de corrections.

Il s’agit toujours de mesures autodéclarées. Les éléments disponibles établissent ce que l’auteur a rapporté et expliquent les catégories de mesure. Ils n’établissent pas qu’une autre station de travail reproduira les résultats ni que chaque requête a maintenu la moyenne agrégée.

La réutilisation du cache modifie la signification du temps de réponse

Le démarrage médian de réponse de 0,2 seconde rapporté concerne une session où 99,5 % des tokens de prompt provenaient du cache.

Le cache de prompts réutilise des informations déjà calculées à partir d’une entrée antérieure, au lieu de retraiter ce même contenu. Ce comportement est important dans les sessions de programmation, car les requêtes successives partagent souvent l’historique de conversation, le contenu du dépôt et les instructions. Réutiliser ce travail peut rendre une session en cours sensiblement plus réactive.

L’auteur indique que 99,5 % des tokens de prompt provenaient du cache de prompts. Le délai médian jusqu’au premier token a atteint 0,2 seconde. Le délai jusqu’au premier token mesure le retard avant le début de la sortie, plutôt que le temps nécessaire pour terminer une réponse.

Considérées ensemble, ces mesures décrivent une charge de travail favorable aux interactions répétées. Elles ne montrent pas que le moteur peut lire un long prompt de dépôt entièrement inconnu et commencer à répondre avec le même délai. Une requête nouvelle doit être évaluée séparément.

La source aborde en partie cette distinction grâce à ses mesures de traitement non mis en cache. Pour la session de programmation, le traitement des prompts a atteint en moyenne 5 011 tokens par seconde, avec un pic de 5 118. L’auteur indique que ces chiffres représentent deux lectures substantielles non mises en cache, contenant environ 10 700 et 8 000 nouveaux tokens.

Le traitement des prompts est le calcul nécessaire pour ingérer une entrée avant de générer une réponse. Son débit diffère du débit de génération, car le modèle effectue un travail différent pendant ces étapes. Les fusionner dans une seule affirmation de vitesse masque des informations dont les lecteurs ont besoin.

Le balayage de nouveaux prompts a fait état d’un débit de traitement des prompts moyen de 5 475 tokens par seconde, avec un pic de 5 662. Cela fournit une observation distincte du traitement des entrées. Elle devrait accompagner les résultats de programmation fortement dépendants du cache chaque fois que quelqu’un caractérise la réactivité du moteur.

Pour les développeurs, l’implication dépend de la façon dont leur travail accumule le contexte. Un assistant qui revisite régulièrement le même projet peut bénéficier de calculs conservés. Un flux de travail qui remplace fréquemment ses documents ou change de dépôts présente une charge différente.

Prenons un agent qui lit un projet, propose une modification, reçoit une erreur du compilateur et révise le correctif. Une grande partie des informations environnantes reste pertinente au fil de ces tours. Le comportement du cache peut donc influer sur l’expérience même lorsque le débit de génération sous-jacent du modèle reste inchangé.

Considérons maintenant un analyste qui ouvre des collections de documents sans rapport tout au long de la journée. Le contenu répété peut être moins important. Appliquer à ce flux de travail le délai médian de réponse de la session de programmation nécessiterait des preuves que le post ne fournit pas.

Le cache constitue donc une part substantielle du résultat rapporté. Il explique pourquoi les utilisateurs devraient examiner leurs propres schémas de requêtes avant de considérer un benchmark comme une prévision. La question décisive est de savoir quelle part du calcul leur application peut réellement réutiliser.

La mémoire système porte le compromis de la station de travail

Une carte graphique de 16 Go est au cœur de cette configuration, mais la charge de travail rapportée dépend également de 54,1 Go de mémoire système.

La VRAM est la mémoire attachée au processeur graphique, tandis que la RAM système sert l’ensemble de l’ordinateur. Le rapport utilise les deux. Décrire le résultat uniquement à travers la carte graphique sous-estime les ressources machine mobilisées et masque la contrainte pratique pour les utilisateurs potentiels.

La conception mémoire experte décrit Basalt comme un fork de Strata ciblant le matériel NVIDIA Blackwell. Il exécute un modèle de type mixture-of-experts, qui sélectionne des composants spécialisés du modèle pour les calculs. Les experts qui dépassent la capacité de la mémoire graphique peuvent résider en RAM système.

Cette conception explique l’approche générale sans valider indépendamment ce benchmark particulier. La documentation du projet établit que l’utilisation de mémoire système est intentionnelle. Les mesures Reddit fournissent la vitesse et la consommation mémoire rapportées pour la station de travail spécifiée.

La pression pratique concerne les développeurs qui cherchent à savoir si leur machine existante peut prendre en charge un assistant local. La capacité de mémoire graphique seule donne une réponse incomplète. La mémoire système disponible, les autres applications et les besoins de contexte de la charge de travail doivent faire partie de la même évaluation.

Les chiffres de mémoire libre rapportés méritent une attention particulière. Laisser 5,2 Go disponibles pendant la programmation n’établit pas une instabilité, mais décrit une faible marge sur cette machine de test. Un éditeur, un navigateur, un processus de build ou un autre service local ajoute une demande supplémentaire.

Cela ne signifie pas que chaque station de travail comparable échouera lors d’un développement ordinaire. Cela signifie que le benchmark ne peut pas garantir un multitâche confortable. Les utilisateurs ont besoin de mesures prises pendant que leur environnement de développement réel fonctionne, plutôt que lorsque le moteur d’inférence opère isolément.

Le même raisonnement s’applique à la lecture de la mémoire graphique. L’utilisation rapportée de 15,7 Go se rapproche de la capacité de 16 Go de la carte citée. Cette observation devrait décourager les hypothèses concernant une marge généreuse pour des charges graphiques non liées ou des réglages de moteur différents.

C’est là que l’attrait du titre rencontre le compromis opérationnel. Le rapport décrit une stratégie d’allocation qui permet à la charge de travail de tenir dans les ressources disponibles. Il ne décrit pas un modèle fonctionnant entièrement dans un budget modeste de mémoire graphique.

Une décision d’achat devrait donc commencer par la station de travail complète. Ajouter une carte graphique compatible à une machine par ailleurs limitée ne recrée pas l’environnement rapporté. De même, faire correspondre la capacité mémoire ne reproduit pas nécessairement le comportement du processeur, les réglages logiciels ou le débit soutenu.

Les applications riches en connaissances ajoutent une autre considération : l’organisation des sources reste distincte de l’exécution du modèle. Une base de connaissances consultable répond à l’accès aux documents, tandis que ce benchmark concerne le calcul une fois les entrées parvenues à un moteur.

L’enseignement utile est concret. Les développeurs qui évaluent cette configuration devraient prévoir de la mémoire à la fois pour l’inférence et leurs outils environnants. La vitesse rapportée rend cette évaluation intéressante, mais l’exigence de mémoire système reste centrale dans le résultat.

Strata et llama.cpp nécessitent des comparaisons équivalentes

Ce rapport sur une station de travail n’établit pas un classement contrôlé des performances entre Basalt, Strata et llama.cpp.

Le titre cite Strata et Basalt ensemble, mais la description de la charge de travail fournie identifie Basalt comme le moteur utilisé. Les lecteurs devraient préserver cette distinction. Les résultats d’un fork ne doivent pas automatiquement devenir des affirmations de performances pour son projet parent.

Strata fournit la lignée à l’origine de Basalt, tandis que llama.cpp constitue un autre point de référence pertinent pour l’inférence locale. Leur présence établit le contexte concurrentiel. Elle ne justifie pas de déclarer un vainqueur sans fichiers de modèle, réglages, matériel et séquences de requêtes équivalents.

La documentation du benchmark d’inférence distingue le traitement des prompts de la génération de texte et permet des tests à des profondeurs de contexte spécifiées. Elle enregistre également des mesures répétées. Ces catégories illustrent pourquoi une comparaison exige davantage que de placer côte à côte des chiffres de débit mis en avant dans les titres.

Une comparaison équitable conserverait une charge de travail reconnaissable d’un moteur à l’autre. Les mêmes invites, longueurs de réponse, représentations de modèle et conditions de contexte devraient servir de base à l’exercice. Sinon, un avantage logiciel apparent peut inclure des différences ailleurs dans la configuration.

Les conditions de cache méritent un traitement équivalent. Comparer une session de codage avec cache chaud à une invite inconnue désavantage cette dernière avant même le début de la génération. Les deux scénarios sont utiles, mais répondent à des questions opérationnelles différentes et devraient apparaître comme des résultats distincts.

La configuration matérielle doit également rester fixe lorsque l’on attribue des différences à un moteur. La carte plus rapide ou le budget mémoire plus élevé d’un autre utilisateur ajoute une variable supplémentaire. Ces informations peuvent orienter l’exploration sans prouver ce que le logiciel apporte à lui seul.

Le comportement de sortie présente une autre complication. Le décodage spéculatif utilise des jetons provisoires qu’un modèle vérifie avant d’accepter la sortie. Toute comparaison impliquant cette accélération devrait divulguer ses paramètres et vérifier quel comportement la configuration mesurée préserve.

La norme pertinente est la transparence sur l’exécution exacte. Les lecteurs devraient pouvoir identifier l’artefact du modèle, la révision logicielle, la configuration et la méthode de mesure. Un nom de modèle familier ne garantit pas des représentations numériques ni des sorties identiques.

La même prudence s’applique aux affirmations sur le remplacement des services de codage hébergés. Ce rapport mesure le comportement de l’inférence locale lors d’une session de codage. Il ne fournit aucune évaluation comparative des tâches terminées, de l’intervention des développeurs, de la fiabilité du service ou de l’effort d’intégration face à une alternative hébergée.

Pour les mainteneurs de moteurs, la pression concurrentielle reste réelle dans un sens plus restreint. Un rapport prometteur sur une station de travail donne aux utilisateurs une raison d’étudier des implémentations spécialisées. La réponse qui compte est une preuve reproductible montrant où chaque moteur fonctionne bien.

Pour les développeurs, une liste restreinte est plus défendable qu’un classement. Basalt mérite d’être testé sur du matériel compatible, car les débits soutenus rapportés sont pertinents pour le travail interactif. Strata et llama.cpp restent des candidats de comparaison dont le comportement doit être mesuré dans les mêmes conditions.

Une génération rapide n’établit pas la qualité du codage

Le chaînon manquant est la performance sur les tâches : le rapport mesure la vitesse de sortie sans établir avec quelle fiabilité le code généré résout les problèmes.

Une session de codage fournit une charge de travail plus reconnaissable que la génération de texte isolée. Elle montre qu’une interface d’agent a émis des requêtes répétées. Toutefois, le seul nombre de requêtes ne révèle ni les modifications réussies, ni les tests validés, ni les nouvelles tentatives inutiles, ni les corrections humaines.

Cette distinction devient particulièrement importante avec la quantification. Réduire la précision numérique modifie la représentation du modèle exécuté. Une configuration plus rapide ou plus compacte doit toujours être évaluée sur les tâches que les utilisateurs comptent lui attribuer.

L’évaluation publiée du modèle quantifié offre des éléments de preuve limités sur la qualité à l’aide de segments de texte et d’une référence de précision supérieure. Cette comparaison aide à caractériser le comportement du modèle. Elle n’établit ni la précision de réparation d’un dépôt, ni l’usage fiable des outils, ni la réussite du codage à long contexte.

Le long contexte crée une lacune de vérification connexe. Un système peut accepter une longue invite sans appliquer de manière fiable chaque détail pertinent. La capacité de traitement et l’exactitude de récupération au sein de cette entrée sont des propriétés différentes, même lorsqu’elles affectent la même expérience utilisateur.

L’exploration du contexte soutient donc une interprétation circonscrite. Elle rapporte le débit sur des invites nouvelles de longueurs différentes. Elle n’établit pas que le modèle a systématiquement localisé une exigence enfouie, concilié des instructions contradictoires ou préservé les contraintes du projet lors de la modification du code.

Les débits de génération agrégés laissent également la répartition des expériences peu claire. Une moyenne peut résumer une session tout en masquant des requêtes plus lentes. Un développeur attendant une modification difficile peut accorder davantage d’importance à ces délais qu’à la meilleure pointe.

La même limite s’applique au chiffre médian de démarrage de réponse. Une médiane décrit l’observation centrale. Elle n’établit ni les attentes les plus longues, ni le comportement après un défaut de cache, ni le temps nécessaire pour recevoir un correctif complet et exploitable.

La concurrence, c’est-à-dire les requêtes simultanées, ajoute une autre limite. Le document indique une concurrence de un. Cela rend le résultat pertinent pour un flux individuel, mais ne fournit aucune base pour estimer la capacité d’une équipe partagée ou les performances sous des requêtes d’agents qui se chevauchent.

Ces lacunes devraient orienter l’interprétation sans effacer l’accomplissement rapporté. La source fournit des définitions de mesure explicites et sépare les types de charge de travail. Ces détails rendent les affirmations plus évaluables qu’une capture d’écran inexpliquée ne montrant qu’une vitesse maximale.

Une reproduction indépendante devrait ajouter les résultats des tâches aux catégories de débit existantes. Une évaluation de codage utile enregistrerait si les tests réussissent, si les modifications satisfont la demande et à quelle fréquence une personne intervient. Elle devrait conserver les échecs plutôt que de ne rapporter que les exécutions réussies.

Pour le benchmark Qwen3.8 Basalt, la question non résolue est de savoir si la réactivité rapportée s’accompagne d’un travail fiable. Jusqu’à l’apparition de preuves comparatives sur les tâches, la vitesse reste une preuve concernant l’exécution, plutôt qu’une preuve que la configuration fournit un meilleur assistant de codage.

Trois signaux détermineront jusqu’où le résultat se propage

Les prochaines preuves devraient établir la reproductibilité, la fiabilité du codage et les performances dans des conditions d’exploitation moins favorables, dans cet ordre.

Le premier signal est une reproduction indépendante sur une station de travail RTX 5080 comparable. La publication utile inclurait l’artefact exact du modèle, la révision du moteur, la configuration, la séquence de requêtes et les relevés de temps bruts. Des exécutions répétées devraient distinguer les sessions fortement dépendantes du cache des entrées nouvelles.

Une reproduction proche renforcerait l’argument selon lequel cette configuration offre une option reproductible aux développeurs individuels. Un écart important exigerait une enquête avant de l’attribuer au matériel, au logiciel ou à la charge de travail. Dans les deux cas, les éléments de preuve disponibles pour les utilisateurs s’amélioreraient.

La reproduction devrait conserver les distinctions de mesure d’origine. La génération moyenne de session, la génération moyenne par requête et les pics d’une seconde devraient rester distincts. Ne reproduire que la plus forte pointe observée laisserait sans réponse l’affirmation la plus importante concernant les performances soutenues.

Le deuxième signal est une évaluation de codage utilisant la même configuration quantifiée. Sa valeur viendrait des tâches terminées et des corrections enregistrées, plutôt que d’un autre graphique de vitesse de génération. L’évaluation devrait inclure le contexte de projet dont un agent a réellement besoin.

De solides résultats sur les tâches rendraient le rapport de débit plus conséquent pour le développement logiciel. Des échecs fréquents en limiteraient l’intérêt, même si la génération restait rapide. Produire plus vite un correctif inutilisable ne réduit pas le travail nécessaire pour terminer une tâche.

Le troisième signal concerne les performances dans un ensemble plus large de conditions d’exploitation. Les preuves pertinentes incluent des invites longues inconnues, des sorties plus longues, des applications de développement ordinaires exécutées parallèlement à l’inférence et des requêtes qui se chevauchent. Chaque condition teste si l’expérience rapportée résiste à un changement de charge de travail.

Un comportement stable renforcerait l’argument en faveur de l’utilisation de cette configuration au-delà d’une session individuelle soigneusement observée. La pression mémoire, des attentes plus longues ou une sortie dégradée en identifieraient les limites pratiques. Ces limites aideraient les utilisateurs à sélectionner des charges de travail plutôt qu’à écarter le moteur d’emblée.

Aucun de ces signaux n’exige d’inventer une date de sortie ou de prédire un vainqueur inévitable. Ce sont des formes concrètes de preuves que les mainteneurs et les utilisateurs indépendants peuvent publier au cours des prochains mois. La publication actuelle constitue un point de départ utile pour ce travail.

L’implication plus large reste précise. Une station de travail dotée de 16GB de mémoire graphique aurait maintenu une génération interactive en engageant également une quantité substantielle de mémoire système. Cela rend l’évaluation de l’ensemble du système plus pertinente que le jugement de l’inférence locale sur la seule capacité de mémoire graphique.

Avant de modifier votre configuration, comparez le benchmark Qwen3.8 Basalt à une session issue de votre propre travail. Conservez les invites, notez ce que le cache réutilise et enregistrez si les modifications obtenues passent vos vérifications. Incluez les applications que vous laissez habituellement ouvertes, car la machine rapportée disposait de peu de mémoire système libre. Distinguez le délai de démarrage de réponse du temps de finalisation, et comparez une sortie soutenue à une sortie soutenue. La décision devrait dépendre du travail utile accompli dans vos conditions. Une exécution reproductible peut-elle fournir des modifications correctes, des délais acceptables et suffisamment de mémoire disponible pour le reste de votre environnement de développement ?