Il benchmark di QEngine RTX 5090 riporta 504 tok/s, con un vantaggio legato alla cache

Il benchmark di QEngine RTX 5090 riporta 504 token al secondo per Qwen3.8-Flash-Next, ma quel picco dipende da condizioni che modificano il quadro competitivo. Un utente di LocalLLaMA ha testato QEngine 1.3.1 su due schede RTX 5090 e ha segnalato un vantaggio sostanziale nella decodifica a flusso singolo, cioè nella velocità di generazione di una conversazione. Lo stesso confronto colloca QEngine più o meno allo stesso livello di Strata in un test di latenza dei prompt per agenti, mentre Strata elabora più rapidamente il prompt di benchmark più lungo.

Il tester, che pubblica come Relative-Ant-9249, attribuisce il merito allo sviluppatore bpx03 e afferma esplicitamente che QEngine è il progetto di un'altra persona. Il suo benchmark di inferenza locale confronta diversi motori sulla stessa workstation. Questo rende il resoconto utile, anche se resta un confronto eseguito da un utente senza replica indipendente.

Il compromesso centrale è già evidente: il flusso di output più rapido non garantisce automaticamente l'attesa più breve durante un'intera conversazione. I prompt ripetuti favoriscono la cache adattiva di QEngine, gli input lunghi favoriscono Strata nel test riportato e il mantenimento delle conversazioni inattive modifica nuovamente la latenza. Gli sviluppatori che scelgono tra questi motori devono identificare quale ritardo interrompe effettivamente il loro lavoro.

Cosa ha effettivamente misurato il benchmark di QEngine RTX 5090

Il risultato di 504 tok/s appartiene a uno specifico carico di lavoro, a una configurazione di memoria e a una versione software. Non rappresenta né una media dell'intero confronto né una garanzia per ogni risposta.

La workstation contiene due schede RTX 5090, ciascuna con 32 GB di memoria video, affiancate da un processore Threadripper PRO 3975WX. Il tester riporta 251 GB di RAM di sistema e un contesto configurato di circa 262.000 token. I token sono le unità di testo che un modello elabora e genera, non un conteggio diretto delle parole.

QEngine ha usato la build INT4 AutoRound di Flash-Next, una rappresentazione compressa del modello basata su pesi interi a quattro bit. Il tester afferma di aver modificato il target di compilazione CUDA dall'architettura 86 alla 120, usando nvcc 13.3 e g++-13. Non riporta altre modifiche al sorgente e indica un intervallo di 53 secondi tra l'avvio e la disponibilità delle richieste.

Si tratta di un incoraggiante resoconto sulla portabilità, anche se una compilazione riuscita non dimostra un supporto hardware generalizzato. Dimostra che questo utente ha eseguito questa build su questa macchina. Non dimostra un comportamento equivalente su schede madri, driver, configurazioni di memoria o ambienti operativi diversi.

Il test separa l'output narrativo da quello di codice, e questa distinzione è rilevante in tutti i risultati. Con la configurazione predefinita, QEngine avrebbe generato testo narrativo a 370 tok/s e codice a 439 tok/s. Spostando la cache delle conversazioni nella RAM di sistema, tali misurazioni sono salite rispettivamente a 406 e 504 tok/s.

La configurazione ISTA IQ3_S di Strata avrebbe raggiunto 214 tok/s per l'output narrativo e 293 tok/s per il codice. La sua configurazione UD-IQ4_XS ha restituito 180 e 239 tok/s. Si tratta di build compresse del modello differenti, il che impedisce di considerare il confronto come una pura misurazione dell'implementazione del motore.

La configurazione bucko vLLM ottimizzata ha restituito 135 tok/s per l'output narrativo e 141 tok/s per il codice. La configurazione distribuita ha misurato 120 e 118 tok/s. Il tester elenca inoltre una configurazione Infernix a 14–18 tok/s, senza una corrispondente misurazione dell'elaborazione dei prompt.

Queste cifre mostrano una sostanziale differenza riportata su questa workstation. Definiscono anche i limiti del titolo: 504 tok/s è il più alto risultato elencato per la generazione di codice. Il risultato narrativo dello stesso motore è inferiore e la sua configurazione di memoria predefinita è più lenta della configurazione RAM.

Il resoconto afferma che tutti i motori hanno usato lo stesso script di benchmark e gli stessi prompt. Le ricette della community per il serving collegate forniscono un contesto per l'ecosistema di test, anche se il collegamento a un progetto di benchmark non convalida indipendentemente un risultato inviato.

La descrizione più difendibile è quindi specifica. QEngine 1.3.1 ha guidato le configurazioni testate da questo utente nella generazione a flusso singolo, con il suo tasso più alto riportato sul codice. Affermazioni più ampie sul motore più veloce disponibile richiedono un campo più completo e test indipendenti ripetibili.

I prompt ripetuti rendono più difficile generalizzare il vantaggio di generazione

Il vantaggio riportato di QEngine è significativo, ma il benchmark premia anche un comportamento che il traffico ordinario potrebbe non riprodurre. Il tester identifica direttamente questa limitazione, rendendola centrale per interpretare il risultato.

Secondo il post, la cache degli esperti di QEngine si adatta all'uso recente. Una cache degli esperti conserva le porzioni del modello richieste più di frequente, affinché il motore possa accedervi senza recuperarle ripetutamente altrove. Ripetere gli stessi prompt offre a questo meccanismo un carico di lavoro favorevole.

Questo è importante perché il benchmark ripete i prompt tra le esecuzioni. L'uso recente diventa quindi un utile indicatore dell'uso futuro, il che può ridurre lo spostamento dei dati del modello. Il tasso di generazione risultante descrive una condizione operativa favorevole, non ogni possibile conversazione.

Il tester contrappone questo comportamento alla cache di Strata, che a suo dire trattiene già circa il 99,5% della massa degli esperti instradati. Nel suo resoconto, ripetere un prompt offre quindi un beneficio aggiuntivo minore a Strata. Questa spiegazione proviene dal tester e non è stata qui stabilita indipendentemente.

Il post fornisce anche un'osservazione precedente su traffico vario: circa 300–400 tok/s per un singolo flusso. Le richieste tramite il carico di lavoro agent del tester avrebbero oscillato tra 330–470 tok/s. Questi valori restano rapidi, ma fanno apparire il titolo da 504 tok/s più come un caso favorevole che come un'aspettativa tipica.

Il titolo descrive un vantaggio di circa 1,5–1,9 volte rispetto al secondo miglior motore testato. Il corpo usa una stima leggermente più ampia, approssimativamente 1,4–1,9 volte Strata dopo aver considerato le differenze di carico di lavoro. Nessuno dei due intervalli dovrebbe diventare un moltiplicatore universale applicato a hardware o prompt non correlati.

È qui che QEngine vs Strata diventa una questione di carico di lavoro. Uno sviluppatore che genera ripetutamente codice simile potrebbe beneficiare di un diverso schema di cache rispetto a chi alterna documenti non correlati. La fonte non stabilisce per quanto tempo ciascun modello debba persistere prima che il vantaggio misurato cambi.

Un utile confronto indipendente conserverebbe entrambe le condizioni. I prompt ripetuti rivelano ciò che il motore può fare quando l'attività recente predice la domanda futura. I prompt vari rivelano quanto bene gestisca una sequenza di richieste meno cooperativa.

Nessuna delle due condizioni merita una preferenza automatica in ogni valutazione. La ripetizione può rappresentare un'applicazione reale con istruzioni condivise e attività ricorrenti. La diversità può rappresentare un assistente personale che passa tra programmazione, ricerca, revisione di documenti e progetti sconosciuti.

Il problema pratico sorge quando una condizione favorevole scompare dal titolo. Un lettore che vede soltanto 504 tok/s potrebbe aspettarsi quel tasso subito dopo aver cambiato attività. Le prove disponibili non supportano tale aspettativa.

Il benchmark di QEngine RTX 5090 spinge quindi i motori concorrenti a spiegare il proprio comportamento in condizioni di cache comparabili. Spinge inoltre gli autori dei benchmark a rendere tali condizioni chiaramente visibili. Senza questa divulgazione, una classifica delle prestazioni può nascondere il motivo della sua esistenza.

Per acquirenti e sviluppatori, la domanda rilevante è quanto spesso il loro lavoro effettivo assomigli al benchmark ripetuto. La risposta determina quanto peso attribuire al picco. Un tasso leggermente inferiore con un comportamento costante potrebbe servire alcuni flussi di lavoro meglio di un tasso più elevato con oscillazioni maggiori.

Strata resta competitiva prima che inizi la risposta

Il vantaggio di QEngine nella generazione non si traduce in un chiaro vantaggio sull'intera richiesta. I risultati riportati sull'elaborazione dei prompt offrono a Strata una posizione più forte man mano che gli input si allungano.

Prefill significa elaborare l'input prima che il modello inizi a generare la risposta. Con circa 10.000 token di input, la configurazione predefinita di QEngine avrebbe elaborato circa 5.700 tok/s. La configurazione con cache RAM ha raggiunto circa 6.200 tok/s a quella lunghezza di input.

La configurazione ISTA IQ3_S di Strata avrebbe elaborato circa 5.100 tok/s sull'input più breve. Con circa 90.000 token, tuttavia, ha raggiunto circa 10.000 tok/s. La configurazione predefinita di QEngine ha misurato circa 7.300 tok/s su quell'input più lungo.

Il post non fornisce un valore di prefill corrispondente a 90.000 token per la configurazione RAM di QEngine. Questo risultato mancante dovrebbe restare tale, invece di essere dedotto dalle sue prestazioni sugli input più brevi. Le misurazioni disponibili supportano un risultato diviso: QEngine in vantaggio sul prompt più breve e Strata in vantaggio su quello più lungo.

Questa distinzione ha un'applicazione diretta negli assistenti di programmazione. Un assistente che lavora su un piccolo scambio recente trascorre una quota di tempo in lettura diversa da uno che esamina il contesto di un grande repository. Una generazione più rapida aiuta entrambi, ma non elimina il tempo necessario per elaborare gli input.

Il test agent aggiunge un altro confine importante. Copre una sequenza di utilizzo di strumenti di 12 turni con un contesto che cresce fino a circa 35.000 token. Con la cache dei prefissi funzionante, QEngine 1.3.1 avrebbe letto il prompt dell'ultimo turno in 1,75 secondi.

La cache dei prefissi consiste nel riutilizzare il calcolo per l'inizio invariato di un prompt. Il risultato corrispondente di Strata era di 1,7–1,9 secondi, collocando QEngine all'interno di tale intervallo riportato. Il tester descrive opportunamente i due motori come allo stesso livello su questa misurazione.

La configurazione bucko ottimizzata ha impiegato 4,36 secondi nello stesso confronto riportato. Ciò stabilisce una differenza tra le configurazioni testate, ma non un risultato per ogni deployment vLLM. Configurazione, rappresentazione del modello e carico di lavoro restano parte del confronto.

È inoltre importante che il numero riportato misuri una fase di lettura del prompt. Non misura il tempo completo necessario per eseguire gli strumenti, ispezionare i risultati, generare istruzioni successive e completare un'attività. Una fase rapida può migliorare un agent senza determinare il tempo complessivo di completamento dell'agent.

QEngine vs Strata non ha quindi un singolo vincitore nelle misurazioni divulgate. QEngine guida la generazione, mentre Strata rimane competitiva sui prompt agent memorizzati nella cache e più forte nel test riportato di prefill con input lunghi. È una conclusione più utile rispetto al ridurre tutto ai token di output al secondo.

Per i team che gestiscono assistenti locali, la pressione è operativa. Devono stabilire se gli utenti aspettano soprattutto l'elaborazione degli input, la generazione delle risposte o gli strumenti esterni. Un cambio di motore interviene solo sulle porzioni di quel tempo di attesa che il motore controlla effettivamente.

Il risultato mette anche in discussione il modo in cui vengono presentate le dimostrazioni di inferenza locale. Un flusso di codice che appare rapidamente è facile da mostrare e da comprendere. Il ritardo più discreto prima dell'inizio di quel flusso può contare altrettanto nelle interazioni ripetute con gli strumenti.

Mantenere le conversazioni inattive nella RAM modifica un diverso tempo di attesa

Il risultato più pratico potrebbe essere il recupero delle conversazioni precedenti, anziché il più alto tasso di generazione. La configurazione RAM di QEngine avrebbe preservato uno stato utile nonostante il traffico intervenuto.

Una cache KV memorizza chiavi e valori relativi all’attenzione, consentendo a un modello di riutilizzare calcoli eseguiti su token precedenti. In questo test, QEngine poteva mantenere quella cache nella RAM di sistema bloccata, ovvero memoria host riservata per trasferimenti prevedibili. Il tester segnala un pool da 13,5 GB che rappresenta circa un milione di token di capacità cache complessiva.

La dimensione del pool è distinta dal limite di contesto configurato per una singola conversazione. La capacità complessiva descrive quanta memoria di conversazione il pool può conservare tra sessioni diverse. Non significa che il benchmark abbia testato una singola conversazione contenente un milione di token.

L’esperimento sulle sessioni inattive è iniziato con otto conversazioni da circa 58.000 token ciascuna. Il tester ha quindi inviato circa 400.000 token di altro traffico prima di tornare alle conversazioni originali. Questa sequenza verifica se il lavoro precedente rimane pronto dopo che la macchina ha servito altro.

Con la cache nella RAM, secondo quanto riportato, tutte e otto le conversazioni sono tornate warm, ossia con il loro stato conservato ancora riutilizzabile. Il tempo alla prima risposta variava da 1,56 a 2,01 secondi. Questo misura il ritardo che gli utenti incontrano quando riaprono un lavoro, anziché la velocità finale del flusso in uscita.

Con la cache nella memoria video, secondo quanto riportato, solo due conversazioni sono rimaste warm. Le altre sei hanno richiesto nuovamente l’elaborazione dell’input, impiegando 8,7–9,4 secondi. Il tester riporta un riferimento di avvio a freddo di 8,85 secondi, rendendo facile cogliere la conseguenza pratica.

Uno sviluppatore che passa da un progetto in corso a un altro riconoscerebbe questo schema. Una conversazione contiene un’indagine di debugging, un’altra una revisione dell’implementazione e un’altra ancora tiene traccia di una funzionalità distinta. Il vantaggio rilevante consiste nel preservare il lavoro già elaborato mentre l’attenzione si sposta altrove.

La stessa distinzione conta in una base di conoscenza ricercabile. Trovare il materiale giusto e riprendere il calcolo precedente di un modello sono problemi separati, anche se entrambi incidono sulla rapidità con cui qualcuno torna a un lavoro utile.

La fonte riporta che le risposte sono rimaste corrette quando la configurazione con memoria video ha dovuto elaborare di nuovo il vecchio input. La penalità osservata riguardava la latenza, anziché una perdita documentata di correttezza delle risposte. Questa distinzione evita di trattare ogni cache miss come un fallimento del ragionamento.

Esiste anche un compromesso relativo alla concorrenza, dove per concorrenza si intende servire più flussi contemporaneamente. Con otto flussi concorrenti e contesti da 64.000 token, la configurazione RAM ha prodotto, secondo quanto riportato, 124 tok/s per flusso. La configurazione con memoria video ha raggiunto 139 tok/s per flusso.

Il tester sintetizza il dato come circa il 10% più lento sotto questo carico concorrente, nonostante un miglioramento di circa il 10% su un singolo flusso. Dichiara inoltre un avvio per modalità e un solo passaggio. È sufficiente per individuare un compromesso che merita esame, ma insufficiente per stabilirne l’intera distribuzione.

La questione tecnica più ampia si estende oltre questo motore. La documentazione della cache ibrida descrive una gestione specifica per Flash-Next e limita la propria convalida dichiarata alla generazione di testo. Il supporto dei modelli, la conservazione dello stato e la copertura dei carichi di lavoro richiedono attenzione esplicita, anziché supposizioni basate sul nome di un prodotto.

Per un assistente individuale, preservare il lavoro inattivo potrebbe contare più di una minore velocità di output concorrente. Per un servizio condiviso, l’equilibrio potrebbe invertirsi. I risultati riportati rendono entrambe le possibilità degne di valutazione, senza stabilire nessuna delle due come scelta predefinita.

I controlli di qualità e i motori concorrenti limitano la pretesa di vittoria

Il rapporto sostiene ulteriori test di QEngine, non una dichiarazione secondo cui produca risposte migliori o superi ogni alternativa. I suoi stessi controlli di qualità e il thread di discussione stabiliscono questi limiti.

Il test dell’assistente avrebbe restituito 44 attività riuscite su 44 con QEngine 1.3.1. Le precedenti esecuzioni 1.3 ne hanno restituite 42 su 44 con impegno ridotto. Il tester tratta cautamente la piccola differenza, anziché presentarla come un miglioramento della qualità accertato.

Il confronto di coding richiede un’attribuzione delle versioni ancora più attenta. Una build release candidate ha restituito 26 attività riuscite su 30 nel set di coding del tester. Le configurazioni Strata hanno restituito 24 e 25, mentre i risultati ripetuti per una configurazione variavano da 24 a 26.

Il tester afferma esplicitamente che il controllo di coding non era stato rieseguito su 1.3.1. Non può quindi fungere da certificazione diretta della qualità per la versione esatta alla base del titolo. Fornisce contesto su una build precedente e sulla variabilità osservata nel confronto.

La conclusione ragionevole è che questi controlli limitati non hanno rivelato uno svantaggio evidente nel coding per il modello compresso di QEngine. Non dimostrano una qualità equivalente in tutte le attività. Né mostrano che un miglioramento della velocità di generazione preservi ogni comportamento necessario a un’applicazione in produzione.

La quantizzazione, ovvero la compressione dei pesi numerici del modello, complica ulteriormente il confronto tra motori. Build compresse differenti possono modificare sia le prestazioni sia gli output. Un benchmark che confronta configurazioni di deployment complete risponde a una domanda pratica, ma non isola ogni causa contribuente.

Anche il panorama competitivo è incompleto. Nella discussione, lo sviluppatore di Basalt suggerisce di testare un motore progettato specificamente per l’hardware NVIDIA Blackwell. Lo sviluppatore riporta prestazioni ottenute con una macchina e un benchmark diversi, perciò tali valori non possono essere inseriti nella classifica originale.

Tuttavia, l’esistenza del supporto all’inferenza Blackwell conta nell’interpretazione dell’espressione “motore più veloce”. QEngine era in testa tra le configurazioni misurate dall’autore del post. Un’alternativa non testata resta non testata, indipendentemente dal fatto che il suo sviluppatore riporti altrove numeri promettenti.

Il thread della fonte contiene anche reazioni entusiaste degli utenti e richieste di aiuto per la configurazione. Queste risposte indicano interesse, ma né l’entusiasmo né un aneddoto riproducono autonomamente il benchmark. Una seconda workstation necessita di un test documentato prima che l’esperienza del suo proprietario possa corroborare la medesima affermazione sulle prestazioni.

La deriva delle versioni crea un ulteriore problema di verifica. Al momento della verifica, il repository del codice sorgente di QEngine descrive la versione 1.3.2 e funzionalità Flash-Next aggiuntive. Queste descrizioni attuali non dovrebbero essere attribuite retroattivamente alla build 1.3.1 testata.

Il repository definisce il progetto source-available e documenta un focus sull’hardware RTX 3090. Le note di build identificano ancora l’architettura 86 e descrivono gli altri modelli GPU come non testati. Ciò rende la compilazione del poster per 5090 una prova utile di un risultato individuale, anziché un impegno generale di compatibilità.

Una riproduzione indipendente dovrebbe quindi preservare la revisione software effettiva, i file del modello, le scelte del compilatore e la configurazione di avvio. Aggiornare tutto alla versione più recente potrebbe produrre un risultato interessante, ma risponderebbe a una domanda diversa. La riproducibilità dipende dal mantenimento di ciò che è stato misurato.

La pressione su QEngine ora è trasformare un promettente rapporto di un utente in un modello operativo affidabile. La pressione sui concorrenti è rispondere con carichi di lavoro comparabili e configurazioni trasparenti. Nessuno dei due compiti viene soddisfatto pubblicando un numero più grande ottenuto su hardware non correlato.

Tre risultati renderebbero più utile il prossimo confronto

La prossima evidenza utile è un confronto più riproducibile tra carichi di lavoro, anziché un altro picco isolato. Tre segnali specifici rafforzerebbero o indebolirebbero l’interpretazione di questo rapporto.

Primo, osservare una riproduzione indipendente su un’altra workstation RTX 5090 a due schede. Un risultato utile identificherebbe la revisione esatta di QEngine e la build del modello, quindi riporterebbe prompt sia ripetuti sia variati. Riprodurre un vantaggio materiale nella generazione in entrambe le condizioni rafforzerebbe l’ipotesi che il vantaggio si estenda oltre la macchina originale.

Un vantaggio minore con prompt variati restringerebbe tale ipotesi senza rendere priva di significato la misurazione originale. Mostrerebbe che la recente cronologia del carico di lavoro spiega una parte maggiore del risultato osservato. Questa informazione aiuterebbe gli utenti a scegliere un motore in base al proprio traffico.

I test indipendenti dovrebbero inoltre preservare la distinzione tra output narrativo e output di codice. Riunirli in un’unica media nasconderebbe una differenza che il rapporto originale già mette in evidenza. Riportarne i risultati separatamente offre ai lettori maggiori possibilità di abbinare il benchmark alla propria applicazione.

Secondo, osservare un confronto sulla stessa macchina che includa un’alternativa focalizzata su Blackwell come Basalt. Il risultato dell’autore del post originale non stabilisce dove quel motore si collochi in classifica. Testarlo alle stesse condizioni affronterebbe una lacuna concreta sollevata nella discussione.

Un confronto credibile dovrebbe dichiarare le differenze nelle build compresse dei modelli e nelle impostazioni di qualità. Dovrebbe inoltre includere la latenza di elaborazione dei prompt e il comportamento delle sessioni riprese, accanto alla velocità di generazione. Altrimenti, un nuovo vincitore erediterebbe la stessa ambiguità del vecchio titolo.

Se QEngine manterrà il vantaggio in questo campo ampliato, l’affermazione competitiva diventerà più forte. Se un altro motore eguaglierà la generazione migliorando al contempo la latenza su input lunghi o sessioni riprese, la scelta dipenderà maggiormente dal comportamento dell’applicazione. Entrambi gli esiti sarebbero più informativi del confronto tra screenshot incompatibili.

Terzo, osservare test ripetuti con carichi di lavoro misti sulla conservazione delle sessioni inattive e sulla generazione concorrente. Il risultato RAM riportato è interessante perché affronta l’interruzione tra sessioni di lavoro. Il suo rallentamento in concorrenza mostra perché tale vantaggio richiede valutazione durante un uso sostenuto.

Esecuzioni ripetute rivelerebbero se il recupero delle sessioni warm rimane coerente man mano che le conversazioni si accumulano e l’attività cambia. Mostrerebbero inoltre quanto spesso il motore elabora di nuovo input vecchi, incontra errori o riduce la velocità per flusso. Queste misurazioni verificherebbero il valore pratico alla base della configurazione di memoria.

Un recupero coerente con prestazioni concorrenti accettabili rafforzerebbe l’argomento a favore di uno stato della conversazione supportato dalla RAM. Variabilità frequente o un rallentamento maggiore ne restringerebbero l’attrattiva ai carichi di lavoro più leggeri. Nessuno dei due esiti richiede di fingere che ogni assistente locale serva lo stesso schema di richieste.

Per gli sviluppatori che stanno considerando un cambiamento, il benchmark QEngine RTX 5090 offre una ragione credibile per approfondire, insieme a limitazioni insolitamente esplicite. Il suo contributo più forte è mostrare che velocità di generazione, latenza dei prompt e recupero delle conversazioni possono muoversi in direzioni diverse.

Prima di sostituire un motore esistente, confrontate le attese che i vostri utenti sperimentano realmente. Conservate una conversazione lunga e rappresentativa, introducete traffico non correlato e misurate cosa accade quando il lavoro originale riprende. Includete attività variate accanto a prompt ripetuti e mantenete controlli di qualità che riflettano il lavoro che dovete completare. Registrate la versione e la configurazione testate, affinché aggiornamenti successivi non cancellino il significato del confronto. Il benchmark QEngine RTX 5090 presenta un caso persuasivo per questa valutazione, lasciando però la scelta finale dipendente dalle evidenze del vostro carico di lavoro. Il vostro assistente trascorre più tempo a generare una risposta, a leggere un prompt in crescita o a recuperare una conversazione che vi aspettavate ricordasse?