Due RTX 3090 collegate via PCIe Gen4 senza NVLink, un modello Qwen3.8-27B con quantization AutoRound INT4 e un vLLM modificato ad hoc: il risultato è 218 token al secondo su singola richiesta. Il test, pubblicato su Reddit e misurato con la suite benchmark Club-3090, non si limita a un numero da esibire. È una fotografia dei compromessi concreti che oggi regolano l'inference self-hosted di modelli di fascia media.
Il setup è bare-metal: due RTX 3090 con VRAM di picco a 22,3 GB per scheda, alimentazione limitata a 220 e 250 W, PCIe Gen4 x16 su entrambe le porte, niente NVLink ma P2P patchato. Sopra gira vLLM 0.26.1rc1 con quantization AutoRound INT4 (group 128) e un modello draft DFlash2 per la decodifica speculativa. Il contesto massimo raggiunto è di 131k token; il drafter da solo occupa circa 13,5 GB di VRAM.
Guardare soltanto ai 218 token/s sarebbe fuorviante. Il dato più prezioso è il costo del drafter. Per accelerare la generazione il sistema deve ospitare due modelli, non uno: il modello principale quantizzato e il draft che propone i token. Il prezzo è una quota rilevante di memoria e una riduzione del contesto utile. Senza DFlash2 il soffitto di contesto sarebbe più alto, ma la velocità di decodifica probabilmente crollerebbe. È il funzionamento classico della decodifica speculativa: si spende VRAM extra per proporre più token in parallelo, confidando che il modello principale ne validi una parte sufficiente. In questo caso i numeri dicono che su 7 token proposti ne vengono accettati in media 3,35, con un tasso di accettazione del 47,8%. Non è un rendimento perfetto, ma basta a portare il throughput reale sopra i 200 token/s.
Le misure complete distinguono uno scenario narrativo e uno code. Nel primo la decodifica viaggia a 120,1 token/s, nel secondo a 218,3; il throughput di parete scende leggermente a 117,7 e 204,8 token/s. Il tempo al primo token resta contenuto: 168 ms nel narrativo e 178 ms nel code. Sono valori da uso interattivo, non da batch: parliamo di singola richiesta, non di servizi concorrenti. Chi cerca un sostituto di un endpoint cloud per conversazioni o assistenza al codice ha una base solida; chi deve servire decine di utenti in parallelo deve ragionare su altro.
Non è una prestazione arrivata per caso. L'autore dice di aver assemblato il tutto in modo artigianale e di aver usato Kimi K3 per le correzioni a vLLM, incluse modifiche che servono a far partire il sistema in modo pulito. È proprio questo il punto che cambia gli incentivi per chi valuta un deployment on-premise. Il risparmio sulle GPU è reale, ma il TCO non si esaurisce nell'acquisto dell'hardware: servono competenze di serving, quantization, debug di runtime e probabilmente manutenzione continua. Per un team che ha già queste capacità, due RTX 3090 diventano una piattaforma di inference locale molto interessante. Per chi invece parte da zero, il costo nascosto di integrazione può superare il risparmio rispetto al cloud.
La notizia si inserisce in una dinamica più ampia. L'abbassamento dei costi di inference per modelli da 27 miliardi di parametri passa ormai da due leve: quantization aggressiva e decodifica speculativa. Non si tratta più di aumentare la potenza di calcolo, ma di ridurre l'impronta di memoria e sfruttare meglio i token già generati. Su hardware consumer senza NVLink il limite non è il throughput di picco, ma la capacità di tenere insieme modello principale, drafter e contesto. Questo sposta il vantaggio verso chi può mettere mano al codice e alla configurazione, non verso chi compra semplicemente più GPU.
Per chi valuta deployment on-premise, AI-RADAR offre framework analitici su /llm-onpremise per leggere questi trade-off senza ridurre la scelta a un singolo benchmark. L'autore lascia intendere che ci sia probabilmente altro margine di prestazione: il setup è stato assemblato in modo rapido, con correzioni custom. È un invito a non fermarsi al numero, ma a leggerlo come punto di partenza.
💬 Commenti (0)
🔒 Accedi o registrati per commentare gli articoli.
Nessun commento ancora. Sii il primo a commentare!