Il benchmark LLM locale Llmspeed rende tangibile la velocità hardware, ma le stime non sono l’ultima parola

Llmspeed ha lanciato un simulatore di benchmark per LLM locali che rende visibile una metrica ostinata: quanto tempo potrebbero farvi aspettare un determinato modello e una determinata macchina. Invece di presentare l’ennesimo foglio di calcolo, trasmette in streaming una risposta campione alla velocità prevista. Simula anche la pausa prima della comparsa del primo token.

Il progetto arriva mentre gli acquirenti di AI locale affrontano una scelta insolitamente complessa. Un modello può entrare in memoria ma risultare comunque lento con prompt lunghi. Un altro può produrre testo rapidamente, ma perdere quel vantaggio quando un agente carica migliaia di token di codice.

È questa la tensione centrale attorno al benchmark LLM locale Llmspeed. Offre un punto di partenza più chiaro dei post sparsi sui forum, ma la sua simulazione accessibile può apparire più definitiva di quanto consentano le prove sottostanti. La risposta su Hacker News è diventata rapidamente un test pubblico di questa distinzione.

Llmspeed trasforma i numeri dei benchmark in un’esperienza di attesa

L’idea utile di Llmspeed non è una nuova metrica delle prestazioni. È un modo più intuitivo per sperimentare metriche già note prima di acquistare l’hardware.

Il simulatore live chiede agli utenti di selezionare hardware, modello e livello di quantizzazione. La quantizzazione riduce la precisione numerica dei pesi del modello, di solito abbassando il consumo di memoria a fronte di un certo costo per la qualità dell’output.

Llmspeed presenta quindi una risposta simulata usando la velocità di generazione stimata. Include anche il tempo al primo token, o TTFT, che misura il ritardo prima dell’avvio dell’output in streaming. Questo ritardo può contare più della velocità di generazione pura quando un prompt contiene un documento di grandi dimensioni o una codebase.

Una modalità gara affianca due configurazioni. Trasforma il confronto da un’astratta cifra di token al secondo in qualcosa di più simile a una dimostrazione di prodotto. Gli utenti possono osservare una configurazione iniziare a rispondere mentre l’altra sta ancora elaborando il prompt.

Il sito descrive attualmente il supporto per 30 GPU, Mac e configurazioni CPU attraverso 15 modelli. L’elenco comprende backend CUDA, Metal, ROCm, Vulkan e CPU. L’hardware disponibile include schede grafiche consumer, sistemi Apple Silicon, dispositivi workstation e acceleratori cloud.

L’elenco dei modelli include architetture dense e mixture-of-experts, o MoE. Un modello MoE attiva solo una parte del proprio insieme totale di parametri per ciascun token. Questo design può migliorare la velocità di generazione, anche se il modello completo può comunque richiedere molta memoria.

L’allocazione in memoria è un’altra componente importante dell’interfaccia. Llmspeed stima se un modello entra interamente nel dispositivo selezionato, richiede un offloading parziale nella memoria di sistema oppure non può essere eseguito secondo le sue ipotesi di modellazione.

Questa distinzione è importante perché “funziona” e “funziona interamente nella memoria video” sono affermazioni diverse. Strumenti come llama.cpp possono suddividere i layer del modello tra un processore grafico e la memoria di sistema. La configurazione risultante può funzionare, ma la sua velocità dipende dalla suddivisione e dalla larghezza di banda tra i componenti.

La metodologia pubblicata di Llmspeed divide i risultati in tre categorie di confidenza. “Measured” rappresenta lo stesso hardware, modello e quantizzazione. “Derived” interpola misurazioni simili, mentre “projected” usa specifiche hardware per configurazioni prive di risultati diretti.

Questa etichettatura è una scelta progettuale responsabile. Comunica agli utenti che un’animazione rifinita può comunque basarsi su una stima. La domanda cruciale è se gli utenti notino l’etichetta prima di trattare l’output come una previsione d’acquisto.

Il progetto ha guadagnato visibilità attraverso un post Show HN il 18 ottobre 2026. Entro il 20 ottobre, la discussione era cresciuta ben oltre i conteggi iniziali registrati dal feed di notizie. Questa crescita rifletteva un interesse reale per un problema che gli utenti di AI locale incontrano ripetutamente.

Il risultato è meglio inteso come uno strumento interattivo di pianificazione. Fornisce ad acquirenti e sviluppatori un linguaggio comune per confrontare possibili configurazioni. Non sostituisce il test del carico di lavoro effettivo che intendono eseguire.

Perché i confronti hardware per LLM locali sono diventati così difficili

L’hardware è solo una variabile, mentre lo stack software determina sempre più spesso se la stessa macchina risulta lenta, accettabile o sorprendentemente veloce.

La risposta visibile di un modello locale ha almeno due fasi prestazionali. L’elaborazione del prompt, spesso chiamata prefill, legge l’input e prepara lo stato interno del modello. Il decode genera poi i token di output uno dopo l’altro.

Queste fasi sollecitano l’hardware in modo diverso. Llmspeed modella la generazione come vincolata in larga misura dalla larghezza di banda della memoria, poiché i pesi attivi devono essere consultati ripetutamente. Considera l’elaborazione del prompt più dipendente dal throughput computazionale.

Questa suddivisione semplificata offre un utile punto di partenza. Tuttavia, i motori di inferenza reali aggiungono caching, batching, speculative decoding, ottimizzazioni dei kernel e percorsi specifici per l’architettura. Ogni ottimizzazione può modificare il risultato osservato senza cambiare l’etichetta dell’hardware.

Il progetto calibra le proprie stime usando benchmark raccolti e coefficienti di efficienza dei backend. Applica inoltre un rallentamento al crescere del contesto. Per l’offloading parziale, modella i pesi residenti sulla GPU e quelli nella memoria di sistema con diverse larghezze di banda effettive.

Le stime di memoria includono i pesi del modello, la cache key-value e l’overhead di runtime. La cache key-value memorizza i dati di attenzione dei token precedenti affinché il modello non ricalcoli tutto durante la generazione.

Llmspeed afferma che i suoi calcoli riservano circa il 75 percento della memoria unificata sui Mac e il 93 percento della memoria GPU discreta per il carico di lavoro modellato. Si tratta di ipotesi pratiche, non di limiti operativi universali.

Altre applicazioni, display, driver e impostazioni di inferenza possono modificare la memoria disponibile. I contesti lunghi espandono la cache key-value. Richieste parallele possono moltiplicare la pressione sulla memoria o costringere un server di inferenza a dividere le proprie risorse.

Il progetto richiede misurazioni contribuite tramite l’affermato benchmark harness incluso con llama.cpp. Il comando suggerito usa un prompt di 512 token e genera 128 token.

Ciò rende i risultati più facili da confrontare, ma definisce anche un carico di lavoro ristretto. Un breve benchmark non può rappresentare pienamente un agente che carica un grande repository, chiama strumenti e mantiene una lunga conversazione.

La documentazione di llama-bench aggiunge un’altra importante precisazione. Le sue misurazioni escludono il tempo di tokenizzazione e campionamento. Queste omissioni sono ragionevoli per isolare il throughput del modello, ma gli utenti sperimentano l’intero percorso applicativo.

Un assistente di programmazione include anche costruzione del prompt, recupero dal repository, output degli strumenti, servizi in rete e ritardi dell’interfaccia. Un benchmark può misurare correttamente l’inferenza senza riuscire a prevedere l’interazione completa.

Ecco perché il benchmark LLM locale Llmspeed mette sotto pressione le recensioni hardware convenzionali. Un singolo punteggio di throughput massimo non risponde più alla domanda che gli acquirenti pongono realmente. Vogliono sapere come si comporterà un modello durante un compito specifico.

Le suite di benchmark tradizionali risolvono un problema diverso. MLPerf Inference enfatizza confronti standardizzati e riproducibili per sistemi e scenari definiti. Llmspeed privilegia accessibilità e reattività percepita tra le scelte dei consumatori.

Nessuno dei due approcci elimina l’altro. Le suite standardizzate offrono controlli più rigorosi, mentre un simulatore interattivo aiuta gli utenti a interpretare la latenza. Il divario emerge quando una stima accessibile viene scambiata per una validazione di livello laboratoriale.

Questo divario cresce perché il software cambia più rapidamente della maggior parte dei cicli di recensione hardware. Una nuova release del backend può migliorare kernel, caching o offloading del modello. Un dispositivo precedentemente poco attraente può diventare utilizzabile senza alcun aggiornamento fisico.

Anche l’architettura del modello complica il confronto. Due modelli con conteggi di parametri totali simili possono attivare numeri di parametri per token molto diversi. Le loro necessità di memoria, velocità e qualità dell’output possono divergere nettamente.

La quantizzazione introduce un altro compromesso. Pesi con meno bit riducono la memoria e possono aumentare la velocità, ma l’impatto sulla qualità varia in base al modello e al compito. Una configurazione con la più alta velocità in token può produrre risultati che richiedono più correzioni.

I confronti hardware per LLM locali richiedono quindi più del nome di una GPU e del nome di un modello. Richiedono una versione dell’engine, backend, quantizzazione, lunghezza del contesto, formato della cache, piano di offloading e descrizione del carico di lavoro.

Llmspeed mette in evidenza diverse di queste dimensioni. La sua popolarità mostra quanto gli utenti desiderino un unico luogo per confrontarle. I suoi critici mostrano perché comprimerle in un’unica esperienza resti difficile.

Il benchmark LLM locale Llmspeed di fronte ai carichi di lavoro reali

La critica più incisiva non è che Llmspeed usi stime. È che le stime brevi e su singolo dispositivo possano non cogliere le configurazioni che gli utenti più seri adottano realmente.

La discussione di lancio ha prodotto due reazioni simultanee. Alcuni utenti hanno accolto con favore un modo per confrontare sistemi senza scaricare diverse varianti del modello. Altri hanno segnalato grandi differenze tra il simulatore e le loro configurazioni funzionanti.

Diversi commentatori hanno descritto schede grafiche più vecchie o più piccole in grado di eseguire modelli che i controlli convenzionali sulla memoria potrebbero scartare. Le loro configurazioni usavano quantizzazione aggressiva, offloading su CPU, fork specializzati o tecniche di inferenza più recenti.

Questi resoconti sono aneddotici e non stabiliscono un contro-benchmark controllato. Rivelano comunque una debolezza di fondo di qualsiasi stimatore statico. L’inferenza locale presenta molte configurazioni valide, comprese combinazioni che il simulatore non rappresenta.

Llmspeed elenca esplicitamente il supporto per singolo dispositivo come una limitazione. Non simula ancora la suddivisione dei tensori o dei layer tra più processori grafici. Il creatore ha dichiarato che il supporto multi-GPU dipende dall’ottenimento di un numero sufficiente di misurazioni affidabili.

Questa limitazione è rilevante perché i sistemi multi-GPU sono comuni tra gli appassionati che eseguono modelli più grandi. L’interconnessione, la generazione PCIe, la strategia di suddivisione e il layout di memoria possono tutti modificare le prestazioni.

L’inferenza ibrida crea un problema simile. Un modello che supera la memoria GPU può collocare alcuni layer nella memoria di sistema. Dire che il modello non entra nella GPU è corretto, ma dire che non può funzionare sarebbe fuorviante.

Un utente di Hacker News ha evidenziato proprio questa distinzione. Il modello selezionato superava la memoria video del dispositivo, eppure llama.cpp poteva eseguire l’offloading dei layer ed eseguirlo. L’esperienza sarebbe stata più lenta, ma non impossibile.

Un’altra fonte di disaccordo è stata lo speculative decoding. Questa tecnica usa un processo draft più piccolo o un altro metodo di previsione per proporre token. Il modello principale verifica quindi insieme diversi candidati, aumentando potenzialmente la velocità di generazione visibile.

I risultati ottenuti usando lo speculative decoding non sono direttamente comparabili con le normali misurazioni di decode. Dipendono dai tassi di accettazione, dalla compatibilità dei modelli, dalle impostazioni del draft e dal tipo di testo generato.

Alcuni commentatori hanno inoltre sottolineato la lunghezza del contesto. Un prompt breve può produrre un numero di decode impressionante, mentre un ampio contesto di programmazione può ridurre il throughput e creare un lungo ritardo di prefill.

Un professionista ha descritto carichi di lavoro di produzione con prompt che raggiungono decine di migliaia di token. La sua esperienza riportata era che il throughput di decode reale poteva scendere molto al di sotto dei risultati dei benchmark a contesto breve.

Questa osservazione si inserisce nel più ampio meccanismo tecnico, anche se il rallentamento esatto varia. Contesti lunghi consumano più memoria cache e aumentano il lavoro di attenzione. Possono anche imporre decisioni di offloading diverse.

Il lavoro parallelo aggiunge un’ulteriore complicazione. Una singola chat con un contesto in cache non equivale a più agenti che lavorano contemporaneamente. Il throughput complessivo può aumentare mentre ogni utente riceve token più lentamente.

Uno sviluppatore che sceglie hardware per un’interfaccia chat personale potrebbe accettare questo compromesso. Un team che serve molti ingegneri necessita di misurazioni di concorrenza, latenza di coda, comportamento della cache e isolamento delle risorse.

La qualità resta al di fuori della principale promessa di Llmspeed. Il simulatore mostra quanto rapidamente apparirebbe una risposta già preparata. Non sostiene che un modello quantizzato più veloce risolverà correttamente un’attività di programmazione, ragionamento o recupero delle informazioni.

Questa distinzione dovrebbe orientare le decisioni d’acquisto. Un modello più piccolo che genera rapidamente può comunque richiedere più tempo nel complesso se gli utenti devono riprovare i prompt o correggere output errati.

Lo stesso vale per i flussi di lavoro con agenti. Un agente può trascorrere la maggior parte del tempo elaborando risultati degli strumenti e ricostruendo il contesto. La sola velocità di decoding non può rivelare se l’intera attività si concluda prima.

Llmspeed riconosce che i risultati reali possono variare dal 10 al 30 percento a causa di driver, versioni del motore, flash attention, limiti di potenza e temperature. Le segnalazioni della comunità suggeriscono che i casi limite ottimizzati possano divergere ancora di più.

Questo non rende inutile il simulatore. Ne definisce il limite di valore. Llmspeed è più efficace quando aiuta gli utenti a scartare configurazioni palesemente non adatte o a confrontare ampie classi di prestazioni.

È meno efficace quando un utente necessita di una previsione di livello procurement per un carico di produzione ottimizzato. A quel punto, il simulatore dovrebbe condurre ai test, non sostituirli.

La domanda d’acquisto migliore è quale carico di lavoro debba sembrare veloce

Una decisione hardware utile parte dall’interazione che deve restare reattiva, non dal valore di token più elevato in una pagina di confronto.

Per le chat ordinarie, la velocità di generazione ha un peso emotivo immediato. Un output lento interrompe il ritmo della conversazione. Un flusso costante a una velocità di lettura confortevole può contare più di un throughput di picco estremo.

L’analisi dei documenti sposta l’attenzione sul prefill. Il sistema deve assimilare il prompt prima di produrre una risposta utile. Un lungo rapporto o una specifica tecnica può rendere il TTFT il ritardo dominante.

Gli agenti di coding creano un profilo più impegnativo. Possono caricare mappe del repository, file sorgente, istruzioni degli strumenti, output dei test e decisioni precedenti. Questo contesto può superare di gran lunga la risposta finale.

Questi flussi di lavoro alternano inoltre inferenza e strumenti. Un modello locale potrebbe generare rapidamente, poi attendere build, ricerche o suite di test. Il tempo complessivo dell’attività diventa più informativo della velocità di decoding.

Il lavoro della conoscenza aggiunge un ulteriore livello. La migliore configurazione locale può dipendere dall’efficienza con cui un’applicazione recupera materiale pertinente prima di inviarlo al modello. Un recupero migliore può ridurre la dimensione del contesto e migliorare sia la latenza sia il focus della risposta.

Gli sviluppatori possono usare una base di conoscenza ricercabile per restringere il materiale fornito a un modello. Ciò può ridurre l’elaborazione non necessaria dei prompt, anche se l’effetto dipende dal sistema di recupero e dall’attività.

La privacy può inoltre giustificare l’inferenza locale anche quando l’hardware è più lento. I documenti sensibili restano su macchine controllate, soggetti alla progettazione e alla configurazione di sicurezza dell’applicazione.

Anche la disponibilità offre un altro motivo. Un assistente locale può continuare a lavorare senza dipendere da un servizio remoto. Tuttavia, gli utenti si assumono allora la responsabilità di aggiornamenti, archiviazione, selezione dei modelli e manutenzione del sistema.

La valutazione corretta dovrebbe quindi definire un prompt rappresentativo. Uno sviluppatore potrebbe selezionare diversi file, un log di build e una richiesta di refactoring. Un ricercatore potrebbe usare un rapporto con un insieme fisso di domande.

Il test dovrebbe registrare il tempo al primo token, il tasso di generazione, il tempo totale dell’attività, il picco di memoria e l’utilità dell’output. Ripeterlo dopo un avvio a freddo può rivelare gli effetti del caricamento del modello e della cache.

I dettagli del motore devono restare fissi durante il confronto. Passare da un runtime a un altro può modificare kernel, quantizzazioni supportate e utilizzo del dispositivo. Altrimenti, il test confronta due stack software anziché due processori.

Anche la lunghezza del contesto deve corrispondere al carico di lavoro previsto. Un sistema testato con 512 token di prompt non può sostenere conclusioni su un agente che elabora regolarmente 64.000 token.

Gli utenti dovrebbero testare almeno una quantizzazione che rientri comodamente nella memoria e una che spinga al limite la memoria disponibile. Questo rivela se una precisione più elevata migliori abbastanza i risultati da giustificare una velocità inferiore o una capacità di contesto ridotta.

Il comportamento termico merita attenzione su laptop e sistemi compatti. Un’esecuzione breve può concludersi prima che il calore sostenuto modifichi le prestazioni. Test più lunghi possono evidenziare throttling che un benchmark rapido non rileva.

La concorrenza dovrebbe corrispondere al numero previsto di utenti o agenti. Una workstation personale richiede evidenze diverse rispetto a un servizio interno che supporta un team di sviluppo.

Llmspeed può guidare questo processo restringendo l’elenco dei candidati. La sua simulazione visiva aiuta gli utenti a individuare differenze sufficientemente grandi da essere rilevanti. Introduce inoltre TTFT e compatibilità della memoria prima che gli acquirenti si concentrino solo sul decoding.

Il simulatore non dovrebbe determinare da solo la scelta finale. Noleggiare o prendere in prestito hardware comparabile per un test controllato resta più affidabile quando la decisione comporta conseguenze operative.

La lezione più ampia si applica oltre questo progetto. L’hardware AI per consumatori necessita di una valutazione incentrata sul carico di lavoro. I token al secondo di picco sono facili da confrontare, ma non descrivono se un’attività reale sembri reattiva.

Llmspeed ha successo quando sposta gli utenti dalle specifiche dei componenti alla latenza percepita. Diventerà più utile man mano che le sue stime integreranno carichi di lavoro più ricchi e una maggiore chiarezza sull’incertezza.

Tre segnali mostreranno se Llmspeed diventerà un riferimento affidabile

La prossima fase di Llmspeed dipende da una migliore copertura delle evidenze, dal supporto per sistemi complessi e da una validazione visibile rispetto ai carichi di lavoro reali degli utenti.

Il primo segnale è la provenienza dei benchmark. Ogni risultato dovrebbe rendere facili da verificare la fonte, la versione del motore, la quantizzazione, la lunghezza del prompt e la categoria di confidenza.

Il repository accetta già invii con questi campi. Ampliare il dataset misurato ridurrebbe la dipendenza da interpolazione e proiezioni hardware.

Questo è particolarmente importante per le coppie hardware-modello più diffuse. Un risultato misurato direttamente può ancorare le stime vicine, mentre diverse esecuzioni indipendenti possono rivelare la variabilità ordinaria.

Il secondo segnale è il supporto per contesti lunghi e inferenza ottimizzata. Gli utenti desiderano controlli per lunghezza del contesto, precisione della cache, speculative decoding e funzionalità pertinenti del motore.

Aggiungere ogni possibile opzione renderebbe l’interfaccia difficile da usare. Un design pratico potrebbe offrire preset chiari per chat, analisi dei documenti e coding agentico.

Ogni preset dovrebbe rendere esplicite le proprie ipotesi. Gli utenti potrebbero così comprendere perché lo stesso hardware produca stime diverse di TTFT e generazione tra i vari carichi di lavoro.

I sistemi multi-GPU e ibridi rientrano in questo secondo segnale. Sono tecnicamente più difficili da modellare perché topologia e strategia di suddivisione contano. Anche un supporto limitato colmerebbe una lacuna significativa emersa dalla discussione.

Il terzo segnale è la validazione esterna. Llmspeed necessita di confronti ripetuti tra prestazioni previste e osservate in configurazioni controllate.

Una vista di validazione potrebbe mostrare valori previsti, misurazioni inviate, intervalli di errore e versioni software coinvolte. Questo trasformerebbe i disaccordi in dati anziché in commenti isolati.

La struttura open source del progetto rende questo possibile. I suoi dati di benchmark e calcoli possono essere ispezionati, messi in discussione e migliorati tramite contributi pubblici.

Tuttavia, l’apertura non garantisce automaticamente l’accuratezza. Il progetto necessita comunque di standard di invio coerenti, gestione dei duplicati e un modo per identificare ottimizzazioni insolite.

I benchmark della comunità spesso favoriscono gli appassionati che ottimizzano in modo aggressivo. Le installazioni predefinite possono comportarsi diversamente. Entrambi i risultati sono utili se l’interfaccia li mantiene distinti.

Gli utenti dovrebbero inoltre osservare quanto rapidamente invecchiano le voci. Aggiornamenti dei driver, nuovi kernel, revisioni dei modelli e release dei motori di inferenza possono modificare le prestazioni. Un risultato con data e ora è più informativo di un numero presentato come senza tempo.

Se Llmspeed amplia la copertura delle misurazioni, le sue etichette di confidenza diventeranno più significative. Se arriveranno preset per contesti lunghi, il simulatore rifletterà meglio i moderni carichi di lavoro con agenti.

Se le previsioni seguiranno costantemente le misurazioni reali, lo strumento potrà diventare una prima tappa credibile per la ricerca hardware. Se persistono ampie lacune inspiegate, resterà una dimostrazione coinvolgente anziché una previsione affidabile.

L’attuale benchmark locale LLM di Llmspeed chiarisce già un’idea importante: la latenza è un’esperienza, non soltanto una riga in un grafico. La sua animazione rende visibile il costo dell’attesa prima che un utente si impegni nell’acquisto di una macchina.

La sfida rimanente è rendere la simulazione tanto trasparente quanto intuitiva. Gli acquirenti dovrebbero usarla per creare una rosa di candidati, ispezionare l’etichetta di confidenza e testare il proprio carico di lavoro rappresentativo.

Prima di scegliere hardware AI locale, chiediti quale ritardo interromperebbe davvero il tuo lavoro. Poi confronta TTFT, comportamento con contesti lunghi, compatibilità della memoria e qualità dell’output insieme alla velocità di generazione. Questo processo durerà più di qualsiasi singola classifica e rivelerà se la stima di Llmspeed corrisponde al lavoro che devi completare.