Le benchmark QEngine RTX 5090 affiche 504 tok/s, avec une avance façonnée par le cache

Le benchmark QEngine RTX 5090 annonce 504 tokens par seconde pour Qwen3.8-Flash-Next, mais ce pic s’accompagne de conditions qui modifient la comparaison concurrentielle. Un utilisateur de LocalLLaMA a testé QEngine 1.3.1 sur deux cartes RTX 5090 et signalé une avance substantielle en décodage mono-flux, c’est-à-dire la vitesse de génération d’une seule conversation. La même comparaison place QEngine approximativement au niveau de Strata lors d’un test de latence des prompts d’agent, tandis que Strata traite plus rapidement le prompt de benchmark le plus long.

Le testeur, qui publie sous le nom de Relative-Ant-9249, crédite le développeur bpx03 et précise explicitement que QEngine est le projet de quelqu’un d’autre. Son benchmark d’inférence locale compare plusieurs moteurs sur la même station de travail. Cela rend le rapport utile, même s’il reste une comparaison menée par un utilisateur sans réplication indépendante.

Le compromis central apparaît déjà clairement : le flux de sortie le plus rapide ne garantit pas automatiquement le délai d’attente le plus court sur l’ensemble d’une conversation. Les prompts répétés favorisent le cache adaptatif de QEngine, les longues entrées favorisent Strata dans le test rapporté, et la conservation des conversations inactives modifie à nouveau la latence. Les développeurs qui choisissent entre ces moteurs doivent identifier quel délai interrompt réellement leur travail.

Ce que le benchmark QEngine RTX 5090 a réellement mesuré

Le résultat de 504 tok/s correspond à une charge de travail, une configuration mémoire et une version logicielle précises. Il ne s’agit ni d’une moyenne sur l’ensemble de la comparaison ni d’une garantie pour chaque réponse.

La station de travail comprend deux cartes RTX 5090, chacune dotée de 32 Go de mémoire vidéo, ainsi qu’un processeur Threadripper PRO 3975WX. Le testeur indique disposer de 251 Go de RAM système et d’un contexte configuré à environ 262 000 tokens. Les tokens sont les unités de texte qu’un modèle traite et génère, et ne correspondent pas directement à un nombre de mots.

QEngine utilisait sa version INT4 AutoRound de Flash-Next, une représentation compressée du modèle reposant sur des poids entiers de quatre bits. Le testeur indique avoir modifié la cible de compilation CUDA, de l’architecture 86 à 120, avec nvcc 13.3 et g++-13. Il ne signale aucune autre modification des sources et un délai de 53 secondes entre le lancement et le traitement des requêtes.

Il s’agit d’un rapport encourageant sur la portabilité, même si une compilation réussie ne prouve pas une prise en charge matérielle générale. Il démontre que cet utilisateur a fait fonctionner cette version sur cette machine. Il ne démontre pas un comportement équivalent sur d’autres cartes mères, pilotes, configurations mémoire ou environnements d’exploitation.

Le test distingue la sortie narrative de la sortie de code, et cette distinction est importante dans tous les résultats. Avec la configuration par défaut, QEngine aurait généré du texte narratif à 370 tok/s et du code à 439 tok/s. Le déplacement de son cache de conversation vers la RAM système aurait porté ces mesures à 406 et 504 tok/s, respectivement.

La configuration ISTA IQ3_S de Strata aurait atteint 214 tok/s pour la sortie narrative et 293 tok/s pour le code. Sa configuration UD-IQ4_XS aurait produit 180 et 239 tok/s. Il s’agit de versions compressées différentes du modèle, ce qui empêche de considérer cette comparaison comme une mesure pure de l’implémentation des moteurs.

La configuration bucko vLLM optimisée a produit 135 tok/s pour la sortie narrative et 141 tok/s pour le code. Sa configuration fournie atteignait 120 et 118 tok/s. Le testeur mentionne également une configuration Infernix à 14–18 tok/s, sans mesure correspondante du traitement des prompts.

Ces chiffres établissent un écart substantiel rapporté sur cette station de travail. Ils établissent aussi les limites du titre : 504 tok/s est le meilleur résultat de génération de code répertorié. Le résultat narratif du même moteur est inférieur, et sa configuration mémoire par défaut est plus lente que sa configuration utilisant la RAM.

Le rapport indique que tous les moteurs ont utilisé le même script de benchmark et les mêmes prompts. Les recettes de serving communautaires liées apportent du contexte sur l’écosystème de test, bien que le lien vers un projet de benchmark ne valide pas indépendamment un résultat soumis.

La description la plus défendable est donc précise. QEngine 1.3.1 a dominé les configurations testées par cet utilisateur pour la génération mono-flux, son débit le plus élevé ayant été observé sur le code. Des affirmations plus larges sur le moteur disponible le plus rapide exigent un champ de comparaison plus complet et des exécutions indépendantes reproductibles.

Les prompts répétés rendent l’avance de génération plus difficile à généraliser

L’avantage rapporté de QEngine est significatif, mais le benchmark récompense aussi un comportement que le trafic ordinaire ne reproduira peut-être pas. Le testeur identifie directement cette limite, ce qui en fait un élément central de l’interprétation du résultat.

Selon la publication, le cache d’experts de QEngine s’adapte à l’usage récent. Un cache d’experts conserve les parties fréquemment nécessaires d’un modèle afin que le moteur puisse y accéder sans devoir les récupérer à répétition ailleurs. Répéter les mêmes prompts offre à ce mécanisme une charge de travail favorable.

Cela importe car le benchmark répète ses prompts entre les exécutions. L’usage récent devient alors un indicateur utile de la demande future, ce qui peut réduire les déplacements de données du modèle. Le débit de génération obtenu décrit une condition de fonctionnement favorable plutôt que toutes les conversations possibles.

Le testeur oppose ce comportement au cache de Strata, qui contiendrait déjà environ 99,5 % de la masse d’experts acheminés. Selon son explication, répéter un prompt apporte donc moins de bénéfice supplémentaire à Strata. Cette explication provient du testeur et n’a pas été établie indépendamment ici.

La publication fournit aussi une observation antérieure sur un trafic varié : environ 300–400 tok/s pour un flux unique. Les requêtes via la charge de travail d’agent du testeur auraient atteint 330–470 tok/s. Ces chiffres restent rapides, mais ils font davantage apparaître le titre à 504 tok/s comme un cas favorable que comme une attente typique.

Le titre décrit un avantage d’environ 1,5 à 1,9 fois par rapport au deuxième moteur testé. Le corps du texte utilise une estimation un peu plus large d’environ 1,4 à 1,9 fois Strata après prise en compte des différences de charge de travail. Aucune de ces plages ne doit devenir un multiplicateur universel appliqué à du matériel ou à des prompts sans rapport.

C’est ici que QEngine vs Strata devient une question de charge de travail. Un développeur générant de manière répétée un code similaire pourrait bénéficier d’un schéma de cache différent de celui d’une personne alternant entre des documents sans lien. La source n’établit pas combien de temps l’un ou l’autre schéma doit persister avant que l’avantage mesuré ne change.

Une comparaison indépendante utile préserverait les deux conditions. Les prompts répétés révèlent ce que le moteur peut faire lorsque l’activité récente prédit la demande future. Les prompts variés montrent dans quelle mesure il gère une séquence de requêtes moins coopérative.

Aucune de ces conditions ne mérite automatiquement d’être privilégiée dans chaque évaluation. La répétition peut représenter une application réelle avec des instructions partagées et des tâches récurrentes. La diversité peut représenter un assistant personnel qui passe du codage à la recherche, à la révision de documents et à des projets inconnus.

Le problème pratique survient lorsqu’une condition favorable disparaît du titre. Un lecteur qui ne voit que 504 tok/s pourrait s’attendre à ce débit immédiatement après avoir changé de tâche. Les éléments disponibles ne soutiennent pas cette attente.

Le benchmark QEngine RTX 5090 pousse donc les moteurs concurrents à expliquer leur comportement dans des conditions de cache comparables. Il pousse aussi les auteurs de benchmarks à exposer clairement ces conditions. Sans cette divulgation, un classement de performances peut dissimuler la raison même de ce classement.

Pour les acheteurs et les développeurs, la question pertinente est de savoir à quelle fréquence leur travail réel ressemble au benchmark répété. La réponse détermine le poids à accorder au pic. Un débit légèrement inférieur au comportement cohérent peut mieux servir certains flux de travail qu’un débit plus élevé assorti de variations plus importantes.

Strata reste compétitif avant le début de la réponse

L’avance de QEngine en génération ne se traduit pas par une avance claire sur l’ensemble de la requête. Les résultats rapportés pour le traitement des prompts donnent à Strata une position plus solide à mesure que les entrées s’allongent.

Le préremplissage consiste à traiter l’entrée avant que le modèle ne commence à générer sa réponse. À environ 10 000 tokens d’entrée, la configuration par défaut de QEngine aurait traité près de 5 700 tok/s. Sa configuration avec cache en RAM aurait atteint environ 6 200 tok/s à cette longueur d’entrée.

La configuration ISTA IQ3_S de Strata aurait traité environ 5 100 tok/s avec l’entrée plus courte. À environ 90 000 tokens, elle aurait toutefois atteint près de 10 000 tok/s. La configuration par défaut de QEngine aurait mesuré environ 7 300 tok/s avec cette entrée plus longue.

La publication ne fournit pas de chiffre de préremplissage correspondant à 90 000 tokens pour la configuration RAM de QEngine. Ce résultat manquant doit rester manquant plutôt que d’être déduit de ses performances sur des entrées plus courtes. Les mesures disponibles étayent un résultat partagé : QEngine est en tête sur le prompt court, tandis que Strata est en tête sur le plus long.

Cette distinction a une application directe aux assistants de programmation. Un assistant travaillant à partir d’un petit échange récent consacre une part différente de son temps à la lecture de celle d’un assistant examinant le contexte d’un vaste dépôt. Une génération plus rapide aide les deux, mais n’efface pas le temps consacré au traitement de leurs entrées.

Le test d’agent ajoute une autre limite importante. Il couvre une séquence d’utilisation d’outils en 12 tours, avec un contexte atteignant environ 35 000 tokens. Avec le cache de préfixe actif, QEngine 1.3.1 aurait lu le prompt du dernier tour en 1,75 seconde.

Le cache de préfixe consiste à réutiliser les calculs relatifs au début inchangé d’un prompt. Le résultat correspondant de Strata se situait entre 1,7 et 1,9 seconde, plaçant QEngine dans cette plage rapportée. Le testeur décrit à juste titre les deux moteurs comme étant au même niveau sur cette mesure.

La configuration bucko optimisée a nécessité 4,36 secondes dans cette même comparaison rapportée. Cela établit une différence entre ces configurations testées, mais pas un résultat pour chaque déploiement vLLM. La configuration, la représentation du modèle et la charge de travail restent partie intégrante de la comparaison.

Il importe aussi que le chiffre rapporté mesure une étape de lecture du prompt. Il ne mesure pas le temps complet nécessaire pour exécuter des outils, examiner les résultats, générer les instructions suivantes et terminer une tâche. Une étape rapide peut améliorer un agent sans déterminer son temps global d’achèvement.

QEngine vs Strata n’a donc pas de vainqueur unique parmi les mesures divulguées. QEngine domine la génération, tandis que Strata reste compétitif sur les prompts d’agent mis en cache et plus performant sur le test rapporté de préremplissage sur longue entrée. C’est une conclusion plus utile que de tout réduire aux tokens de sortie par seconde.

Pour les équipes qui maintiennent des assistants locaux, la pression est opérationnelle. Elles doivent déterminer si les utilisateurs attendent principalement le traitement des entrées, la génération des réponses ou les outils externes. Un changement de moteur ne concerne que les parties de ce temps d’attente que le moteur contrôle réellement.

Le résultat remet également en question la manière dont les démonstrations d’inférence locale sont présentées. Un flux de code qui apparaît rapidement est facile à montrer et à comprendre. Le délai plus discret avant le début de ce flux peut compter tout autant lors d’interactions répétées avec des outils.

Conserver les conversations inactives en RAM modifie un autre délai

Le résultat le plus pratique pourrait être la récupération d’anciennes conversations, plutôt que le débit de génération le plus élevé. La configuration RAM de QEngine aurait préservé un état utile malgré le trafic intermédiaire.

Un cache KV stocke les clés et valeurs liées à l’attention, permettant à un modèle de réutiliser des calculs effectués pour des tokens précédents. Dans ce test, QEngine pouvait conserver ce cache dans la RAM système verrouillée, c’est-à-dire une mémoire hôte réservée à des transferts prévisibles. Le testeur indique un pool de 13,5 Go représentant environ un million de tokens de capacité de cache agrégée.

La taille de ce pool est distincte de la limite de contexte configurée pour une conversation individuelle. La capacité agrégée décrit la quantité d’état conversationnel que le pool peut conserver entre les sessions. Cela ne signifie pas que le benchmark a testé une conversation unique contenant un million de tokens.

L’expérience sur les sessions inactives a commencé avec huit conversations d’environ 58 000 tokens chacune. Le testeur a ensuite envoyé environ 400 000 tokens d’un autre trafic avant de revenir aux conversations d’origine. Cette séquence examine si le travail antérieur reste prêt une fois que la machine a servi autre chose.

Avec le cache en RAM, les huit conversations seraient toutes restées chaudes, ce qui signifie que leur état conservé restait réutilisable. Leur délai avant la première réponse allait de 1,56 à 2,01 secondes. Cela mesure le temps d’attente auquel les utilisateurs font face lorsqu’ils rouvrent un travail, plutôt que la vitesse finale du flux de sortie.

Avec le cache en mémoire vidéo, seules deux conversations seraient restées chaudes. Les six autres ont nécessité un nouveau traitement de l’entrée, prenant 8,7 à 9,4 secondes. Le testeur indique une référence de démarrage à froid de 8,85 secondes, ce qui rend la conséquence pratique facile à observer.

Un développeur passant d’un projet en cours à un autre reconnaîtrait ce schéma. Une conversation contient une enquête de débogage, une autre une revue d’implémentation, et une autre le suivi d’une fonctionnalité distincte. L’avantage pertinent consiste à préserver le travail déjà traité pendant que l’attention se porte ailleurs.

La même distinction importe dans une base de connaissances consultable. Trouver le bon contenu et reprendre le calcul antérieur d’un modèle sont des problèmes distincts, même s’ils influencent tous deux la rapidité avec laquelle une personne revient à un travail utile.

La source indique que les réponses sont restées correctes lorsque la configuration en mémoire vidéo a dû traiter de nouveau l’ancienne entrée. La pénalité observée concernait la latence, plutôt qu’une perte documentée de correction des réponses. Cette distinction évite de traiter chaque absence de cache comme un échec de raisonnement.

Il existe également un compromis en matière de concurrence, où la concurrence désigne le service simultané de plusieurs flux. Avec huit flux simultanés utilisant des contextes de 64 000 tokens, la configuration RAM aurait produit 124 tok/s par flux. La configuration en mémoire vidéo a atteint 139 tok/s par flux.

Le testeur résume cela comme étant environ 10 % plus lent sous cette charge de travail concurrente, malgré une amélioration d’environ 10 % sur un flux unique. Il précise également avoir effectué un démarrage par mode et un seul passage. C’est suffisant pour identifier un compromis qui mérite d’être examiné, mais insuffisant pour établir sa distribution complète.

Le problème technique plus large dépasse ce moteur. La documentation du cache hybride décrit une gestion propre à Flash-Next et limite sa validation déclarée à la génération de texte. La prise en charge des modèles, la conservation de l’état et la couverture des charges de travail exigent une attention explicite plutôt que des hypothèses fondées sur un nom de produit.

Pour un assistant individuel, préserver le travail inactif pourrait l’emporter sur une vitesse de sortie simultanée plus faible. Pour un service partagé, l’équilibre pourrait s’inverser. Les résultats rapportés rendent les deux possibilités dignes d’évaluation sans établir aucune des deux comme choix par défaut.

Les contrôles qualité et les moteurs concurrents limitent la prétention à la victoire

Le rapport justifie des tests supplémentaires de QEngine, et non une déclaration selon laquelle il produit de meilleures réponses ou surpasse toutes les alternatives. Ses propres contrôles qualité et le fil de discussion établissent ces limites.

Le test d’assistant aurait renvoyé 44 tâches réussies sur 44 avec QEngine 1.3.1. Les exécutions antérieures de la version 1.3 avaient renvoyé 42 sur 44 avec un faible niveau d’effort. Le testeur traite cette faible différence avec prudence plutôt que de la présenter comme une amélioration de qualité établie.

La comparaison de codage exige une attribution de version encore plus prudente. Une version candidate a renvoyé 26 tâches réussies sur 30 dans l’ensemble de tests de codage du testeur. Les configurations Strata ont renvoyé 24 et 25, tandis que les résultats répétés pour une configuration allaient de 24 à 26.

Le testeur affirme explicitement que le contrôle de codage n’avait pas été relancé sur la version 1.3.1. Il ne peut donc pas servir de certification directe de la qualité pour la version exacte derrière le titre. Il fournit un contexte sur une version antérieure et sur la variabilité observée de la comparaison.

La conclusion raisonnable est que ces contrôles limités n’ont pas révélé de désavantage évident pour le modèle compressé de QEngine en matière de codage. Ils n’établissent pas une qualité égale pour toutes les tâches. Ils ne montrent pas non plus qu’une amélioration de la vitesse de génération préserve chaque comportement dont une application de production a besoin.

La quantification, c’est-à-dire la compression des poids numériques du modèle, complique encore la comparaison des moteurs. Différentes versions compressées peuvent modifier à la fois les performances et les sorties. Un benchmark comparant des configurations de déploiement complètes répond à une question pratique, mais n’isole pas toutes les causes contributives.

Le paysage concurrentiel est également incomplet. Dans la discussion, le développeur de Basalt suggère de tester un moteur conçu spécifiquement pour le matériel NVIDIA Blackwell. Le développeur indique des performances provenant d’une autre machine et d’un autre benchmark ; ces chiffres ne peuvent donc pas être intégrés au classement d’origine.

Néanmoins, l’existence d’une prise en charge de l’inférence Blackwell importe lorsqu’on interprète l’expression « moteur le plus rapide ». QEngine a dominé les configurations mesurées par l’auteur du message. Une alternative non testée reste non testée, même si son développeur rapporte ailleurs des chiffres prometteurs.

Le fil source contient également des réactions enthousiastes d’utilisateurs et des demandes d’aide à la configuration. Ces réponses signalent un intérêt, mais ni l’enthousiasme ni une anecdote ne reproduisent indépendamment le benchmark. Une deuxième station de travail nécessite un test documenté avant que l’expérience de son propriétaire puisse étayer la même affirmation de performance.

L’évolution des versions crée un autre problème de vérification. Au moment de la vérification, le dépôt de code source QEngine décrit la version 1.3.2 et des fonctionnalités Flash-Next supplémentaires. Ces descriptions actuelles ne devraient pas être rétroactivement attribuées à la version 1.3.1 testée.

Le dépôt qualifie le projet de source-available et documente une priorité accordée au matériel RTX 3090. Ses notes de compilation identifient toujours l’architecture 86 et décrivent les autres modèles de GPU comme non testés. Cela fait de la compilation sur 5090 de l’auteur du message une preuve utile d’un résultat individuel, plutôt qu’un engagement général de compatibilité.

Une reproduction indépendante devrait donc conserver la révision logicielle effective, les fichiers de modèle, les choix de compilateur et la configuration de lancement. Mettre à jour l’ensemble vers la version la plus récente pourrait produire un résultat intéressant, mais répondrait à une autre question. La reproductibilité dépend de la conservation de ce qui a été mesuré.

La pression qui s’exerce désormais sur QEngine consiste à transformer un rapport utilisateur prometteur en mode de fonctionnement fiable. La pression sur les concurrents consiste à répondre avec des charges de travail comparables et des configurations transparentes. Aucune de ces tâches n’est satisfaite en publiant un chiffre plus élevé issu d’un matériel sans rapport.

Trois résultats rendraient la prochaine comparaison plus utile

La prochaine preuve utile est une comparaison plus reproductible entre différentes charges de travail, plutôt qu’un nouveau pic isolé. Trois signaux précis renforceraient ou affaibliraient l’interprétation de ce rapport.

Premièrement, surveillez une reproduction indépendante sur une autre station de travail RTX 5090 à deux cartes. Un résultat utile identifierait la révision exacte de QEngine et la version du modèle, puis rapporterait à la fois des prompts répétés et variés. Reproduire une avance matérielle en génération dans les deux conditions renforcerait l’idée que l’avantage dépasse la machine d’origine.

Un avantage moindre sur des prompts variés nuancerait cette conclusion sans rendre la mesure d’origine dénuée de sens. Cela montrerait que l’historique récent de la charge de travail explique une plus grande part du résultat observé. Ces informations aideraient les utilisateurs à choisir un moteur selon leur propre trafic.

Les tests indépendants devraient également préserver la distinction entre la sortie narrative et la sortie de code. Les combiner dans une moyenne masquerait une différence déjà révélée par le rapport d’origine. Présenter leurs résultats séparément donne aux lecteurs une meilleure chance d’adapter le benchmark à leur application.

Deuxièmement, surveillez une comparaison sur la même machine incluant une alternative axée sur Blackwell telle que Basalt. Le résultat de l’auteur initial n’établit pas la position de ce moteur dans le classement. Le tester dans les mêmes conditions comblerait une lacune concrète soulevée dans la discussion.

Une comparaison crédible devrait divulguer les différences entre les versions compressées des modèles et les paramètres de qualité. Elle devrait également inclure la latence de traitement des prompts et le comportement des sessions reprises, en plus de la vitesse de génération. Sinon, un nouveau vainqueur hériterait de la même ambiguïté que l’ancien titre.

Si QEngine conserve son avance dans ce champ élargi, l’affirmation concurrentielle devient plus solide. Si un autre moteur égale la génération tout en améliorant la latence des longues entrées ou des sessions reprises, le choix devient davantage dépendant du comportement de l’application. Dans les deux cas, le résultat serait plus informatif que la comparaison de captures d’écran incompatibles.

Troisièmement, surveillez des tests répétés de charges mixtes concernant la conservation des sessions inactives et la génération simultanée. Le résultat RAM rapporté est attrayant parce qu’il traite de l’interruption entre les sessions de travail. Son ralentissement en concurrence montre pourquoi cet avantage doit être évalué en usage soutenu.

Des exécutions répétées révéleraient si la récupération de sessions chaudes reste cohérente à mesure que les conversations s’accumulent et que l’activité change. Elles montreraient également à quelle fréquence le moteur traite de nouveau l’ancienne entrée, rencontre des échecs ou réduit la vitesse par flux. Ces mesures testeraient la valeur pratique derrière la configuration mémoire.

Une récupération cohérente avec des performances concurrentes acceptables renforcerait l’argument en faveur d’un état conversationnel soutenu par la RAM. Une variabilité fréquente ou un ralentissement plus important limiterait son attrait aux charges de travail plus légères. Aucun de ces résultats n’exige de prétendre que chaque assistant local répond au même schéma de requêtes.

Pour les développeurs envisageant un changement, le benchmark QEngine RTX 5090 fournit une raison crédible d’enquêter, accompagnée de limites inhabituellement explicites. Sa contribution la plus forte consiste à montrer que la vitesse de génération, la latence des prompts et la récupération de conversation peuvent évoluer dans des directions différentes.

Avant de remplacer un moteur existant, comparez les attentes réellement vécues par vos utilisateurs. Conservez une longue conversation représentative, introduisez du trafic sans rapport et mesurez ce qui se produit lorsque le travail d’origine reprend. Incluez des tâches variées en plus de prompts répétés, et conservez des contrôles qualité reflétant le travail que vous devez accomplir. Consignez la version et la configuration testées afin que les mises à jour ultérieures n’effacent pas le sens de la comparaison. Le benchmark QEngine RTX 5090 plaide de manière convaincante pour cette évaluation, tout en laissant le choix final dépendre des preuves issues de votre charge de travail. Votre assistant passe-t-il davantage de temps à générer une réponse, à lire un prompt qui s’allonge ou à récupérer une conversation dont vous attendiez qu’il se souvienne ?