Per molti tecnici, 0,5 token al secondo è un problema da risolvere. In un intervento su Reddit, un utente lo descrive invece come una velocità di riferimento: «0,5 tok/s è un ritmo umano». Il confronto non è con una GPU da datacenter, ma con la cadenza di un programmatore umano, al netto di pause e cancellazioni. È un cambio di prospettiva che spiega perché lasciare un'analisi dell'intera codebase o un'attività di fintech e deep research in esecuzione durante la notte non venga vissuto come un limite.

Il dato concreto citato è altrettanto indicativo. Senza LLM, l'autore stima circa tre giorni di lavoro, pari a quindici ore di programmazione attiva, per debuggare o implementare una feature. Con Qwen 27B, il tempo scende a quattro ore. Il punto non è il benchmark assoluto, ma la nuova unità di misura: il tempo umano recuperato, non il throughput del modello. In questo contesto, una pipeline lenta ma stabile può avere più valore di una risposta rapida che costringe a sessioni interattive continue.

Questa impostazione ha implicazioni di secondo ordine per chi valuta deployment on-premise. Se il carico è asincrono e tollerante alla latenza, l'hardware non deve necessariamente inseguire i requisiti della generazione interattiva. Diventa più sensato destinare risorse alla capacità di tenere più job in coda, alla gestione di context window ampi e alla quantization spinta, piuttosto che all'ottimizzazione del singolo token al secondo. Il TCO cambia perché il costo marginale non è più misurato solo per chiamata API, ma rispetto a quindici ore di lavoro umano che possono essere compresse in quattro.

C'è anche un segnale strutturale. La lentezza accettata non è un ripiego da hobbista, ma una strategia per chi lavora con dati che non possono uscire dall'infrastruttura propria, come codebase proprietarie, documenti finanziari o materiale di ricerca. Il self-hosted diventa quindi non solo una scelta di sovranità, ma un moltiplicatore del tempo disponibile, con un costo energetico e di hardware che va confrontato con il valore delle ore recuperate.

L'autore non fornisce dettagli su VRAM, GPU o livello di quantization, quindi il dato non è un benchmark trasferibile. Vale però come indizio di progettazione: quando un team definisce i requisiti, può separare i carichi interattivi da quelli batch e scegliere modelli e hardware con criteri diversi. Per chi valuta deployment on-premise, esistono trade-off tra latenza, capacità e controllo che meritano un'analisi dedicata, come quelle disponibili su AI-RADAR nella sezione /llm-onpremise.

Il parametro da osservare non è più se un modello supera una soglia di velocità, ma se il ritmo scelto consente di completare un lavoro che altrimenti verrebbe rimandato. Per alcuni carichi, 0,5 token al secondo sono sufficienti perché la risorsa scarsa non è il calcolo, ma l'attenzione.