Un singolo sviluppatore, un banco di prova domestico e una scheda professionale che costa quanto un'auto di fascia media: a volte bastano questi ingredienti per illuminare le scelte di chi fa inference on-premise. Nei giorni scorsi, un utente di Reddit ha condiviso i risultati dettagliati delle performance di Qwen 3.6 27B—l'ultimo modello della famiglia Qwen—servito con vLLM su un sistema equipaggiato con una RTX 6000 Pro Blackwell da 96 GB, processore Intel 270K Plus e 96 GB di RAM DDR5.

L'analisi ha messo a confronto tre livelli di quantization: BF16 (riferimento), FP8 e NVFP4 (la compressione a 4 bit firmata da NVIDIA, disponibile solo sui chip Blackwell). I numeri raccontano una storia chiara. L'NVFP4 è un razzo nella generazione di token: 169 token al secondo da contesto pulito, quasi tre volte più veloce del BF16 (59 t/s), con un incremento che regge anche a contesti di 65k token. Ma quando lo stesso modello viene usato in modalità agente—per esempio, come assistente di coding—emergono comportamenti anomali: risposte meno approfondite e, scrive il tester, «problemi di looping in copilot che non vedo con BF16». La compressione spinta penalizza la fedeltà semantica quando il modello deve scegliere strumenti e concatenare azioni.

Sul fronte opposto, il BF16 garantisce la massima qualità ma si muove con lentezza, soprattutto durante il prefill. Elaborare 2048 token di prompt a 32k di contesto richiede 1.317 t/s, contro i 1.504 t/s dell'FP8. Il distacco diventa abissale quando si misura il tempo al primo token: a 65k contesto l'FP8 impiega 16,4 secondi, mentre BF16 supera i 21,7 secondi, con un vantaggio di quasi il 25%.

L'FP8 emerge come il punto di equilibrio. Sfrutta i Tensor Core nativi delle GPU Blackwell senza overhead di dequantization durante il prefill, offrendo velocità di ingestion superiori del 20% rispetto a BF16 e una generazione di token circa un 60% più rapida (oltre 100 t/s nei test). Soprattutto, non manifesta le instabilità dell'NVFP4 nei carichi interattivi. «FP8 sembra essere la scelta giusta», commenta il progettista, che usa il modello per attività di sviluppo software e ha già abbandonato llama.cpp in favore di vLLM per via dell'attenzione paginata, che nella pratica si traduce in meno errori casuali e maggiore stabilità.

Il sistema usato è un esempio emblematico di deployment on-premise moderno: una workstation con singola GPU professionale, memoria ECC attivata e un software stack interamente locale (Ubuntu 26.04, CUDA 13.2, vLLM 0.24.0 con backend FLASHINFER e speculative decoding a due token). Nessun cloud, nessuna dipendenza da API esterne. In questo scenario, la scelta della quantization non è solo una questione di velocità: è una leva che incide direttamente sulla qualità delle risposte, sulla latenza percepita e sulla robustezza del servizio self-hosted.

I dati confermano che l'FP8, quando supportato nativamente dall'hardware, rappresenta oggi il formato più sensato per modelli sotto i 30 miliardi di parametri, specie se destinati a compiti conversazionali o di coding assistito. Lo spazio VRAM contenuto—96 GB per una scheda sola—permette di tenere l'intero modello a precisione ridotta senza dover ricorrere a tecniche di offloading, mantenendo la latenza al primo token sotto soglie accettabili anche per contesti lunghi. Il tutto con un TCO prevedibile, perché non ci sono costi di consumo cloud e la scheda lavora in un ambiente domestico con consumi controllati.

Per chi valuta deployment on-premise di LLM, questi benchmark offrono una conferma: la corsa verso bit sempre più bassi non è a costo zero. NVFP4 abbatte il trasferimento di dati su bus PCIe e moltiplica i token al secondo, ma può introdurre regressioni comportamentali difficili da diagnosticare in produzione. L'FP8, invece, si candida come lo standard di fatto per l'inference locale su architetture Blackwell, unendo la spinta dei Tensor Core a una qualità di risposta ancora indistinguibile dal BF16 nella maggior parte dei casi d'uso reali.