Il benchmark di Qwen3.8 Basalt riporta 153 token al secondo su 16GB di VRAM

I risultati del benchmark Qwen3.8 Basalt, pubblicati il 25 ottobre, riportano 153 token al secondo su una RTX 5080, nonostante il limite di 16GB di memoria grafica. La workstation utilizzava inoltre 54,1GB di memoria di sistema. Il titolo del post evidenzia una generazione superiore a 250 token al secondo, ma questa cifra descrive un breve picco anziché un output sostenuto.

La distinzione è importante per gli sviluppatori che valutano assistenti di coding locali. Secondo l'autore del post, la sessione ha gestito 103 richieste, mentre un test separato ha elaborato prompt nuovi con diverse lunghezze di contesto. Questi carichi di lavoro forniscono indicazioni utili sulla reattività, sebbene nessuno dei due dimostri l'accuratezza nel coding o prestazioni verificate in modo indipendente.

La questione centrale riguarda l'inserimento di un modello di grandi dimensioni in una workstation preservando velocità utile e output accettabile. Basalt, un motore di inferenza specializzato, compete per questo carico di lavoro insieme a Strata e ad alternative più generiche come llama.cpp. Questo rapporto giustifica un esame più approfondito di tale approccio, anziché un'affermazione generale secondo cui la capacità della memoria grafica non conta più.

Il benchmark Qwen3.8 Basalt distingue i picchi dalla velocità sostenuta

I dati di generazione più utili sono le medie riportate: 153,0 token al secondo durante il coding e 154,9 durante la scansione del contesto.

Un token è un'unità di testo elaborata o prodotta da un modello linguistico. I token al secondo misurano il throughput, ma non indicano direttamente se il codice generato funziona. La distinzione dell'autore tra output medio e di picco merita di accompagnare ogni sintesi di questi risultati.

Il benchmark RTX 5080 identifica la configurazione del modello come Qwen3.8-Flash-Next IQ3_S. IQ3_S è un formato di quantizzazione, ossia rappresenta i pesi del modello con precisione numerica ridotta. Tale configurazione è parte dell'identità del risultato, non un dettaglio intercambiabile.

La workstation riportata abbinava una RTX 5080 a un processore Core Ultra 9 285K e 62GB di memoria DDR5-6800. Il consumo di memoria grafica ha raggiunto 15,7GB. Secondo quanto riportato, il motore occupava 54,1GB di memoria di sistema, lasciando 5,2GB liberi durante il coding e 5,1GB durante la scansione.

La sessione di coding ha utilizzato opencode, un'interfaccia per agenti di coding, in 103 richieste e ha raggiunto circa 130.000 token di contesto. Il contesto è l'insieme di informazioni disponibili al modello quando produce una risposta. La fonte riporta una capacità configurata di circa 262.000 token, superiore alla profondità osservata nella sessione di coding.

La generazione ha registrato una media di 153,0 token al secondo sui token generati e sul tempo di decodifica, secondo l'autore del post. Il tempo di decodifica è il periodo dedicato alla produzione dei token di output. Il picco riportato di 262 token/s cattura il miglior singolo secondo, anziché una richiesta o sessione completa.

La scansione separata ha utilizzato prompt nuovi compresi tra circa 15.000 e 207.000 token. La sua media di generazione ha raggiunto 154,9 token al secondo, con un picco di 186,6. L'autore descrive queste misurazioni come medie per richiesta, usando risposte di 384 token, temperatura di campionamento pari a 0,7 e due esecuzioni per profondità.

Queste definizioni evitano un'interpretazione fuorviante. Un massimo di un singolo secondo e una media a livello di richiesta descrivono osservazioni diverse. Nessuno dei due dovrebbe sostituire l'altro solo perché entrambi usano i token al secondo.

I dati sostenuti rendono inoltre il rapporto più interessante di quanto suggerisca il solo titolo. Un flusso di lavoro di coding richiede risposte coerenti attraverso interazioni ripetute. Un breve picco aiuta a caratterizzare il sistema, ma gli sviluppatori sperimentano in definitiva richieste complete, interruzioni, esecuzione di strumenti e correzioni.

Queste restano misurazioni auto-riportate. Le evidenze disponibili stabiliscono ciò che l'autore ha riportato e spiegano le categorie di misurazione. Non dimostrano che un'altra workstation riprodurrà i risultati né che ogni richiesta abbia mantenuto la media aggregata.

Il riutilizzo della cache cambia il significato del tempo di risposta

L'avvio mediano della risposta di 0,2 secondi riportato appartiene a una sessione con il 99,5% di riutilizzo della cache dei token del prompt.

Il caching dei prompt riutilizza informazioni calcolate in precedenza da un input antecedente, anziché elaborare nuovamente lo stesso materiale. Questo comportamento è importante nelle sessioni di coding perché le richieste successive spesso condividono cronologia della conversazione, materiale del repository e istruzioni. Riutilizzare questo lavoro può far sembrare una sessione in corso sostanzialmente più reattiva.

L'autore riporta che il 99,5% dei token del prompt proveniva dalla cache del prompt. Il tempo mediano al primo token ha raggiunto 0,2 secondi. Il tempo al primo token misura il ritardo prima dell'inizio dell'output, non il tempo necessario per completare una risposta.

Considerate insieme, queste misurazioni descrivono un carico di lavoro favorevole basato su interazioni ripetute. Non dimostrano che il motore possa leggere un prompt lungo e interamente sconosciuto di un repository e iniziare a rispondere con lo stesso ritardo. Una richiesta nuova deve essere valutata separatamente.

La fonte affronta in parte questa distinzione tramite le misurazioni dell'elaborazione non memorizzata nella cache. Per la sessione di coding, l'elaborazione del prompt ha registrato una media di 5.011 token al secondo e un picco di 5.118. L'autore afferma che tali dati rappresentano due letture non memorizzate nella cache di dimensioni rilevanti, contenenti circa 10.700 e 8.000 nuovi token.

L'elaborazione del prompt è il calcolo necessario per acquisire l'input prima di generare una risposta. Il suo throughput differisce da quello della generazione perché il modello svolge operazioni diverse in queste fasi. Unirli in un'unica affermazione sulla velocità nasconde informazioni necessarie ai lettori.

La scansione dei prompt nuovi ha riportato un throughput di elaborazione dei prompt con una media di 5.475 token al secondo, e un picco di 5.662. Ciò offre un'osservazione distinta della gestione dell'input. Dovrebbe accompagnare i risultati di coding fortemente basati sulla cache ogni volta che qualcuno caratterizza la reattività del motore.

Per gli sviluppatori, l'implicazione dipende da come il loro lavoro accumula contesto. Un assistente che torna ripetutamente sullo stesso progetto può beneficiare del calcolo conservato. Un flusso di lavoro che sostituisce spesso documenti o cambia repository presenta un carico di lavoro differente.

Si consideri un agente che legge un progetto, propone una modifica, riceve un errore del compilatore e revisiona la patch. Gran parte delle informazioni circostanti resta rilevante tra questi passaggi. Il comportamento della cache può quindi influenzare l'esperienza anche quando la velocità di generazione sottostante del modello rimane invariata.

Si consideri ora un analista che apre raccolte di documenti non correlate nel corso della giornata. Il materiale ripetuto potrebbe essere meno esteso. Applicare il ritardo mediano della risposta della sessione di coding a quel flusso di lavoro richiederebbe evidenze che il post non fornisce.

Il caching è pertanto una componente sostanziale del risultato riportato. Spiega perché gli utenti dovrebbero esaminare i propri schemi di richiesta prima di considerare un benchmark una previsione. La domanda decisiva è quanta elaborazione la loro applicazione possa realmente riutilizzare.

La memoria di sistema sostiene il compromesso della workstation

Una scheda grafica da 16GB è alla base di questa configurazione, ma il carico di lavoro riportato dipende anche da 54,1GB di memoria di sistema.

La VRAM è la memoria collegata al processore grafico, mentre la RAM di sistema serve l'intero computer. Il rapporto utilizza entrambe. Descrivere il risultato solo attraverso la scheda grafica sottostima le risorse della macchina coinvolte e oscura il vincolo pratico per i potenziali utenti.

Il progetto della memoria degli esperti descrive Basalt come un fork di Strata destinato all'hardware NVIDIA Blackwell. Esegue un modello mixture-of-experts, che seleziona componenti specializzati del modello per il calcolo. Gli esperti che superano la capacità della memoria grafica possono risiedere nella RAM di sistema.

Questo design spiega l'approccio generale senza validare in modo indipendente questo benchmark specifico. La documentazione del progetto stabilisce che l'uso della memoria di sistema è intenzionale. Le misurazioni di Reddit forniscono la velocità e il consumo di memoria riportati per la workstation specificata.

La pressione pratica ricade sugli sviluppatori che decidono se la loro macchina esistente possa supportare un assistente locale. La sola capacità della memoria grafica fornisce una risposta incompleta. La memoria di sistema disponibile, le altre applicazioni e i requisiti di contesto del carico di lavoro devono far parte della stessa valutazione.

I dati sulla memoria libera riportati meritano particolare attenzione. Lasciare 5,2GB disponibili durante il coding non dimostra instabilità, ma descrive una capacità di riserva limitata su quella macchina di test. Un editor, un browser, un processo di build o un altro servizio locale introducono domanda aggiuntiva.

Ciò non significa che ogni workstation comparabile fallirà durante lo sviluppo ordinario. Significa che il benchmark non può garantire un multitasking confortevole. Gli utenti necessitano di misurazioni raccolte mentre il loro effettivo ambiente di sviluppo è in esecuzione, anziché mentre il motore di inferenza opera in isolamento.

Lo stesso ragionamento vale per la lettura della memoria grafica. L'uso riportato di 15,7GB si avvicina alla capacità di 16GB della scheda indicata. Questa osservazione dovrebbe scoraggiare ipotesi su un ampio margine libero per carichi grafici non correlati o impostazioni differenti del motore.

È qui che l'attrattiva del titolo incontra il compromesso operativo. Il rapporto descrive una strategia di allocazione che fa rientrare il carico di lavoro nelle risorse disponibili. Non descrive un modello che opera interamente entro un modesto budget di memoria grafica.

Una decisione di acquisto dovrebbe quindi partire dalla workstation completa. Aggiungere una scheda grafica compatibile a una macchina altrimenti limitata non ricrea l'ambiente riportato. Né eguagliare la capacità di memoria riproduce necessariamente il comportamento del processore, le impostazioni software o il throughput sostenuto.

Le applicazioni ad alta intensità di conoscenza aggiungono un'altra considerazione: organizzare il materiale sorgente resta distinto dall'esecuzione del modello. Una base di conoscenza ricercabile riguarda l'accesso ai documenti, mentre questo benchmark riguarda il calcolo dopo che gli input raggiungono un motore.

La conclusione utile è concreta. Gli sviluppatori che valutano la configurazione dovrebbero prevedere memoria sia per l'inferenza sia per gli strumenti circostanti. La velocità riportata rende utile tale valutazione, ma il requisito di memoria di sistema resta centrale per il risultato.

Strata e llama.cpp richiedono confronti equivalenti

Questo rapporto sulla workstation non stabilisce una classifica controllata delle prestazioni tra Basalt, Strata e llama.cpp.

Il titolo nomina insieme Strata e Basalt, ma la descrizione del carico di lavoro fornita identifica Basalt come il motore utilizzato. I lettori dovrebbero mantenere questa distinzione. I risultati di un fork non dovrebbero trasformarsi automaticamente in affermazioni sulle prestazioni del progetto madre.

Strata fornisce la discendenza alla base di Basalt, mentre llama.cpp offre un altro punto di riferimento rilevante per l'inferenza locale. La loro presenza definisce il contesto competitivo. Non giustifica la dichiarazione di un vincitore senza file del modello, impostazioni, hardware e sequenze di richieste equivalenti.

La documentazione del benchmark di inferenza separa l'elaborazione del prompt dalla generazione del testo e supporta test a profondità di contesto specificate. Registra inoltre misurazioni ripetute. Queste categorie illustrano perché un confronto richiede più del semplice affiancamento dei dati di throughput riportati nei titoli.

Un confronto adeguato manterrebbe riconoscibile il carico di lavoro tra i vari motori. Gli stessi prompt, le stesse lunghezze delle risposte, la stessa rappresentazione del modello e le stesse condizioni di contesto dovrebbero costituire la base dell’esercizio. Altrimenti, un apparente vantaggio del software può includere differenze in altri elementi della configurazione.

Le condizioni della cache meritano pari trattamento. Confrontare una sessione di programmazione con cache calda con un prompt non familiare svantaggia quest’ultimo prima ancora che inizi la generazione. Entrambi gli scenari sono utili, ma rispondono a domande operative diverse e dovrebbero comparire come risultati separati.

Anche la configurazione hardware deve rimanere fissa quando si attribuiscono le differenze a un motore. La scheda più veloce o il maggiore budget di memoria di un altro utente introducono una variabile aggiuntiva. Queste informazioni possono orientare l’esplorazione, senza dimostrare cosa apporti il solo software.

Il comportamento dell’output presenta un’ulteriore complicazione. La decodifica speculativa utilizza token preliminari che un modello verifica prima di accettare l’output. Qualsiasi confronto che coinvolga tale accelerazione dovrebbe dichiararne le impostazioni e verificare quale comportamento venga mantenuto dalla configurazione misurata.

Lo standard pertinente è la trasparenza sull’esecuzione esatta. I lettori dovrebbero poter identificare l’artefatto del modello, la revisione del software, la configurazione e il metodo di misurazione. Un nome di modello familiare non garantisce rappresentazioni numeriche identiche né output identici.

La stessa cautela vale per le affermazioni sulla sostituzione dei servizi di programmazione ospitati. Questo rapporto misura il comportamento dell’inferenza locale durante una sessione di programmazione. Non fornisce una valutazione comparabile di attività completate, intervento degli sviluppatori, affidabilità del servizio o sforzo di integrazione rispetto a un’alternativa ospitata.

Per i manutentori dei motori, la pressione competitiva resta comunque reale in un senso più circoscritto. Un promettente rapporto su una workstation dà agli utenti un motivo per esaminare implementazioni specializzate. La risposta rilevante è un’evidenza riproducibile che mostri dove ciascun motore offre buone prestazioni.

Per gli sviluppatori, una rosa ristretta è più difendibile di una classifica. Basalt merita di essere testato su hardware compatibile perché le velocità sostenute riportate sono rilevanti per il lavoro interattivo. Strata e llama.cpp restano candidati al confronto il cui comportamento richiede misurazioni nelle stesse condizioni.

La generazione rapida non dimostra la qualità della programmazione

L’anello mancante è la prestazione nei compiti: il rapporto misura la velocità di output senza stabilire con quale affidabilità il codice generato risolva i problemi.

Una sessione di programmazione fornisce un carico di lavoro più riconoscibile della generazione di testo isolata. Mostra che un’interfaccia agente ha emesso richieste ripetute. Tuttavia, il solo numero di richieste non rivela modifiche riuscite, test superati, tentativi ripetuti superflui o correzioni umane.

Questa distinzione diventa particolarmente importante con la quantizzazione. Ridurre la precisione numerica modifica la rappresentazione del modello effettivamente eseguita. Una configurazione più veloce o più piccola necessita comunque di una valutazione sui compiti che gli utenti intendono assegnarle.

La valutazione del modello quantizzato pubblicata offre evidenze limitate sulla qualità usando frammenti di testo e un riferimento a precisione superiore. Questo confronto aiuta a caratterizzare il comportamento del modello. Non stabilisce l’accuratezza nella riparazione dei repository, l’uso affidabile degli strumenti o il successo nella programmazione con contesti lunghi.

I contesti lunghi creano una lacuna di verifica correlata. Un sistema può accettare un prompt esteso senza applicare in modo affidabile ogni dettaglio rilevante. La capacità di elaborazione e l’accuratezza nel recupero delle informazioni all’interno di quell’input sono proprietà diverse, anche quando entrambe incidono sulla stessa esperienza utente.

La scansione del contesto supporta quindi un’interpretazione circoscritta. Riporta il throughput su prompt nuovi di lunghezze differenti. Non stabilisce che il modello abbia individuato con coerenza un requisito nascosto, conciliato istruzioni in conflitto o preservato i vincoli del progetto durante la modifica del codice.

Le velocità aggregate di generazione lasciano inoltre poco chiara la distribuzione delle esperienze. Una media può riassumere una sessione nascondendo al contempo le richieste più lente. Uno sviluppatore che attende una modifica difficile potrebbe interessarsi più a tali ritardi che al picco migliore.

La stessa limitazione si applica al valore mediano di avvio della risposta. Una mediana descrive l’osservazione centrale. Non stabilisce le attese più lunghe, il comportamento dopo un mancato accesso alla cache o il tempo necessario per ricevere una patch completa e utilizzabile.

Anche la concorrenza, ovvero le richieste simultanee, aggiunge un altro limite. Il riepilogo indica concorrenza pari a uno. Ciò rende il risultato rilevante per un singolo flusso, ma non fornisce basi per stimare la capacità di un team condiviso o le prestazioni con richieste sovrapposte degli agenti.

Queste lacune dovrebbero orientare l’interpretazione senza cancellare il risultato riportato. La fonte fornisce definizioni esplicite delle misurazioni e separa i tipi di carico di lavoro. Questi dettagli rendono le affermazioni più valutabili di uno screenshot non spiegato che mostri soltanto una velocità massima.

Una riproduzione indipendente dovrebbe aggiungere gli esiti dei compiti alle categorie di throughput esistenti. Una valutazione utile della programmazione registrerebbe se i test vengono superati, se le modifiche soddisfano la richiesta e con quale frequenza interviene una persona. Dovrebbe conservare i fallimenti anziché riportare solo le esecuzioni riuscite.

Per il benchmark Qwen3.8 Basalt, la questione irrisolta è se la reattività riportata accompagni un lavoro affidabile. Finché non emergeranno evidenze comparabili sui compiti, la velocità resterà un’indicazione sull’esecuzione, anziché una prova che la configurazione offra un assistente di programmazione migliore.

Tre segnali determineranno quanto lontano arriverà il risultato

Le prossime evidenze dovrebbero stabilire riproducibilità, affidabilità nella programmazione e prestazioni in condizioni operative meno favorevoli, in quest’ordine.

Il primo segnale è una riproduzione indipendente su una workstation RTX 5080 comparabile. La pubblicazione utile includerebbe l’artefatto esatto del modello, la revisione del motore, la configurazione, la sequenza delle richieste e i dati grezzi di temporizzazione. Esecuzioni ripetute dovrebbero distinguere le sessioni ad alta dipendenza dalla cache dagli input nuovi.

Una riproduzione ravvicinata rafforzerebbe l’argomento secondo cui questa configurazione offre un’opzione ripetibile per i singoli sviluppatori. Uno scarto sostanziale richiederebbe indagini prima di attribuirlo all’hardware, al software o al carico di lavoro. Entrambi gli esiti migliorerebbero le evidenze disponibili per gli utenti.

La riproduzione dovrebbe mantenere le distinzioni di misurazione originali. La generazione media della sessione, la generazione media per richiesta e i picchi di un singolo secondo dovrebbero restare separati. Replicare soltanto il picco massimo osservato lascerebbe irrisolta l’affermazione più importante sulle prestazioni sostenute.

Il secondo segnale è una valutazione della programmazione usando la stessa configurazione quantizzata. Il suo valore deriverebbe dai compiti completati e dalle correzioni registrate, anziché da un altro grafico della velocità di generazione. La valutazione dovrebbe includere il contesto di progetto di cui un agente ha effettivamente bisogno.

Risultati solidi nei compiti renderebbero il rapporto sul throughput più significativo per lo sviluppo software. Fallimenti frequenti ne restringerebbero l’attrattiva, anche se la generazione restasse rapida. Produrre più velocemente una patch inutilizzabile non riduce il lavoro necessario per completare un compito.

Il terzo segnale è la prestazione in un insieme più ampio di condizioni operative. Le evidenze rilevanti comprendono prompt lunghi non familiari, output più lunghi, normali applicazioni di sviluppo in esecuzione accanto all’inferenza e richieste sovrapposte. Ogni condizione verifica se l’esperienza riportata resiste a un cambiamento del carico di lavoro.

Un comportamento stabile rafforzerebbe il motivo per usare la configurazione oltre una sessione individuale attentamente osservata. Pressione sulla memoria, attese più lunghe o output degradato ne identificherebbero i limiti pratici. Tali limiti aiuterebbero gli utenti a scegliere i carichi di lavoro, anziché liquidare il motore in blocco.

Nessuno di questi segnali richiede di inventare una data di rilascio o prevedere un vincitore inevitabile. Sono forme concrete di evidenza che manutentori e utenti indipendenti possono pubblicare nei prossimi mesi. Il post attuale fornisce un utile punto di partenza per quel lavoro.

L’implicazione più ampia resta specifica. Una workstation con 16GB di memoria grafica avrebbe sostenuto una generazione interattiva impegnando anche una notevole quantità di memoria di sistema. Ciò rende la valutazione dell’intero sistema più rilevante che giudicare l’inferenza locale esclusivamente in base alla capacità della memoria grafica.

Prima di modificare la configurazione, confronta il benchmark Qwen3.8 Basalt con una sessione tratta dal tuo lavoro. Conserva i prompt, annota cosa riutilizza la cache e registra se le modifiche risultanti superano le tue verifiche. Includi le applicazioni che normalmente tieni aperte, perché la macchina riportata disponeva di poca memoria di sistema libera. Tieni separato il ritardo di avvio della risposta dal tempo di completamento e confronta output sostenuto con output sostenuto. La decisione dovrebbe basarsi sul lavoro utile completato nelle tue condizioni. Un’esecuzione riproducibile può fornire modifiche corrette, attese accettabili e memoria libera sufficiente per il resto del tuo ambiente di sviluppo?