Una GeForce RTX 5070 da 12 GB, un Ryzen 5 7600, 64 GB di RAM DDR5 e Windows. È un desktop, non una macchina da inference. Eppure, secondo i dati diffusi sul repository GitHub di Strata, basta per portare Qwen3.8-Flash-Next a 65,1 token/s in output e 543 token/s nell’elaborazione del prompt su contesti da 128K. Il merito non è della GPU da sola, ma di un motore di inference scritto su misura per questo modello e per questa classe di hardware: installazione one-click, supporto solo CUDA, modello pubblicato su Hugging Face da ISTA-DASLab.
Il confronto con il passato recente dà la misura del salto. Con llama.cpp e la quantization IQ3_XXS, l’autore registrava 15 token/s in output e 100-120 token/s nell’elaborazione del prompt. Con il nuovo motore, la IQ3_XXS arriva a 44,8 token/s, la IQ2_XS a 52,0 e la Q2_0 a 65,1. L’elaborazione del prompt passa a 414, 472 e 543 token/s rispettivamente. Le versioni a 2 bit, ottenute con RCO-GSQ, girano più veloci di quelle più pesanti: occupano meno spazio e, in questo contesto, battono sul piano della velocità anche la IQ3_XXS. Il repository le etichetta come equivalenti a unsloth Q3, Q4 e Q5, un riferimento utile per chi già conosce quelle precisioni numeriche. È un dettaglio controintuitivo per chi associa un uso aggressivo della riduzione di precisione solo a perdita di qualità, perché qui il vincolo non è il modello ma la memoria disponibile.
I requisiti minimi combinati tra RAM e VRAM raccontano il tipo di esecuzione: 37,6 GB per Q2_0, 39,2 GB per IQ2_XS, 47 GB per IQ3_XXS, più 0,91 GB per l’encoder visivo. La scheda da 12 GB non contiene tutto; la RAM di sistema diventa parte attiva dell’esecuzione. Il punto non è magia, ma orchestrazione: kernel CUDA specializzati, gestione della memoria e un modello pensato per essere tirato fino all’estremo.
La storia non è un benchmark isolato. È la dimostrazione che per carichi locali e contesti lunghi, un runtime specializzato su un singolo modello può superare un framework generalista come llama.cpp, se il target hardware è definito. Strata non è una piattaforma universale: funziona su CUDA, per questo modello, con un percorso di installazione semplificato ma comunque vincolato. Chi lo usa non compra versatilità; compra efficienza su un perimetro ristretto. Per un team tecnico che deve servire un caso d’uso specifico su hardware già presente, il risparmio potenziale non sta nell’acquisto di una GPU più grande, ma nel costo-opportunità di riusare un desktop. Per un fornitore di framework generalisti, invece, è un segnale: l’ultimo miglio dell’ottimizzazione può finire in progetti ad hoc, difficili da replicare ma difficili da ignorare quando il guadagno moltiplica per tre o quattro la velocità di output sulla stessa scheda.
Infine, il tema della sovranità dei dati. Se un modello con encoder visivo e contesto da 128K può girare su una macchina da ufficio, diminuisce la spinta a inviare documenti e prompt a un’API esterna. Non sparisce il bisogno di competenze per mantenere il runtime, ma il costo di restare on-premise cambia qualitativamente. Il self-hosted smette di essere una scelta per soli data center e diventa una questione di ingegneria del software, precisione numerica e tolleranza al rischio. Per chi valuta deployment on-premise, AI-RADAR offre framework analitici su /llm-onpremise per valutare questi trade-off senza trasformare una demo in una raccomandazione universale. Il prossimo confine non è la scheda, ma quanto il software può spremere prima che la qualità del modello diventi il vero collo di bottiglia.
💬 Commenti (0)
🔒 Accedi o registrati per commentare gli articoli.
Nessun commento ancora. Sii il primo a commentare!