Mettere un Large Language Model da 35 miliardi di parametri (sia pure in versione Mixture-of-Experts) su una scheda video da gaming e fargli generare oltre 500 token al secondo per testi lunghissimi: fino a ieri sembrava fantascienza. E invece NInfer, un motore di inference costruito interamente da zero in C++ e CUDA, ci riesce, portando Qwen3.6-35B-A3B a 543 tok/s su una singola RTX 5090, su una finestra di decodifica di 65.536 token. Non si tratta di un benchmark spot: il progetto open source, pubblicato su GitHub, è pensato per spremere fino all’ultima goccia di prestazioni da due checkpoint molto precisi, i modelli Qwen3.6-27B (denso) e Qwen3.6-35B-A3B (MoE).

NInfer è l’antitesi dei motori di serving generici. Non supporta decine di architetture, non aggiunge continuous batching, non promette flessibilità estrema. Al contrario, è un coltello svizzero affilato per un solo compito: far correre quei due modelli su una RTX 5090 (o, con qualche accorgimento, su una RTX PRO 6000). Il segreto sta in una pipeline di ottimizzazione end-to-end che parte dalla quantization custom (5,03 bpw per il 27B, 4,97 bpw per il 35B-A3B, per un ingombro di 16,29 e 20,84 GiB rispettivamente) e arriva al layout dei pesi, ai kernel per singola operazione, al kernel fusion, fino a un percorso di draft dedicato per il modulo LM-head. Il risultato è che i due modelli entrano comodamente nei 32 GB di VRAM della RTX 5090 e, con cache KV in INT8, raggiungono l’intera finestra di contesto nativa di 262.144 token.

I numeri parlano da soli. Su prompt di ragionamento lungo, con finestra di draft Multi-Token Prediction (MTP) a 3 e il percorso di draft ottimizzato, NInfer sostiene 542,8 ± 12,5 tok/s per 65.536 token di completamento, con tassi di accettazione MTP del 73%. Su sequenze più brevi (8.675 token) sale a 634 tok/s con l’82,7% di accettazione. Anche su carichi misti – codice, traduzione, storie e output strutturati – la velocità rimane elevata (da 396 tok/s per lo storytelling fino a 661 tok/s per output strutturati). Il modello denso da 27B non è da meno, con 174 tok/s su reasoning lungo e 189 tok/s su output strutturati, sempre con MTP attivo. I punteggi di capacità, misurati su AIME25, AIME26 e GPQA-Diamond, confermano che la compressione non sacrifica la qualità: il 35B-A3B ottiene 27/30 su AIME25 e 169/198 su GPQA, in linea con modelli non quantizzati.

C’è un messaggio strutturale forte in questa dimostrazione, che va oltre l’impresa ingegneristica. NInfer segnala che la barriera hardware per l’inference di modelli di frontiera si sta spostando verso il basso, fino alle GPU consumer. Una RTX 5090 costa meno di un decimo di un’A100 o di un H100, consuma molto meno, non richiede raffreddamento da data center e può stare sotto una scrivania. Per chi ha esigenze di privacy, conformità GDPR o semplicemente vuole evitare i costi ricorrenti del cloud, un motore iperspecializzato come questo rende praticabile il self-hosting anche per modelli da decine di miliardi di parametri, con latenze bassissime e throughput che fino a poco tempo fa richiedevano infrastrutture ben più costose.

Il rovescio della medaglia è l’estrema specializzazione. NInfer non supporta altri modelli, non fa batching di richieste contemporanee e funziona solo su GPU con compute capability sm_120a. È il classico trade-off tra flessibilità e prestazioni pure: se il tuo carico di lavoro è servire un singolo modello a bassa latenza, perdere la generalità può essere un affare. Se invece hai bisogno di scalare su più utenti o di cambiare modello ogni settimana, restano preferibili motori come vLLM o TensorRT-LLM, che però su questo specifico binomio hardware-modello restano indietro. L’autore stesso lancia la sfida: vedere un altro motore battere queste cifre, con lo stesso livello di quantization, sulla stessa scheda.

Non è solo un record fine a se stesso. È la dimostrazione che l’ottimizzazione verticale, quella che intreccia algoritmo, kernel e hardware, può ancora strappare fattori di miglioramento significativi, e che il mercato dei LLM on-premise ha bisogno di soluzioni cucite addosso tanto quanto di piattaforme universali. Per i team che valutano deployment locali, il caso NInfer suggerisce di guardare con più attenzione a progetti di nicchia, spesso open source, che possono ridurre il Total Cost of Ownership anche di un ordine di grandezza rispetto alle opzioni cloud. E, più in generale, ricorda a tutti che la corsa all’efficienza non è finita: anzi, sui PC di fascia alta è appena cominciata.