Qwen3.8-27B-Uncensored-NVFP4: Un Runbook di Serving per GPU Blackwell

Qwen3.8-27B-Uncensored-NVFP4 è su Hugging Face dal 19 agosto 2026 e nei dieci giorni successivi è stata scaricata circa 32.700 volte. Non è un resoconto di lancio: i pesi hanno dieci giorni, non c'è alcun annuncio da riportare, e le build sorelle Qwen3.8-27B-Uncensored-FP8 e Qwen3.8-27B-Uncensored-GGUF sono già documentate su questo blog. È un runbook per una build che le persone stanno scaricando attivamente in questo momento: cosa sia realmente NVFP4, perché questa build specifica lo mescola con FP8, quali GPU ne traggono beneficio e quali no, come servirla, e chi dovrebbe sceglierla rispetto alle build FP8 o GGUF — e chi non dovrebbe.

Una cosa subito, perché è un ostacolo per chiunque scarichi per la prima volta: il repository è ad accesso limitato. Il semplice hf download orcarouter/Qwen3.8-27B-Uncensored-NVFP4 one-liner fallisce con un errore di autenticazione finché non hai effettuato l'accesso a Hugging Face e accettato i termini di accesso del repository nella pagina del modello. Tutto ciò che segue presuppone che tu abbia fatto entrambe le cose.

Anche in premessa: la model card di questa repo è dietro quello stesso gate, quindi nulla qui la parafrasa. Ciò che segue si basa sull'elenco pubblico dei file e sui metadati della repo, sulla documentazione pubblica NVFP4 di NVIDIA e su resoconti sul campo di persone che servono build NVFP4 di Qwen3.8-27B su Blackwell. Quando un numero proviene da un operatore piuttosto che da un fornitore, il testo lo dice.

Cos'è questa build

Qwen3.8-27B-Uncensored-NVFP4 è la quantizzazione NVFP4 di Qwen3.8-27B-Uncensored, la versione abliterata di Ali​baba Qw​en/Qwen3.8-27Bche l'organizzazione orcarouter ha pubblicato il 2026-08-18. L'abliterazione rimuove la direzione di rifiuto del modello dal flusso residuo; questa tecnica è spiegata nella nostra guida ai modelli non censurati e non verrà rispiegata qui. La base è il modello denso 27B con attenzione ibrida — 48 layer di attenzione lineare più 16 layer di attenzione completa — comprensione nativa di immagini e video, un contesto di 262.144 token e una testa di decodifica speculativa MTP integrata. Apache 2.0 dall'inizio alla fine.

Ciò che rende interessante questa build non è l'abliteration ma il layout di quantizzazione, perché è volutamente una build quantizzata — se hai cercato NVFP4, il formato è il punto. Secondo i metadati pubblici della repo e la configurazione di quantizzazione, si tratta di una build compressed-tensors a precisione mista: le proiezioni dell'attention sono in FP8 (E4M3), le MLP in NVFP4 (4-bit, impacchettate), mentre l'encoder visivo, la testa MTP, la lm_head e le norme e i bias dell'attention lineare sono lasciati in BF16. I metadati safetensors dell'elenco file pubblico sono in linea con questo schema: circa 3,5 miliardi di parametri in BF16, 9,4 miliardi in FP8-E4M3 e 15 miliardi nei tensori 4-bit impacchettati, per circa 24,7 GB su disco ripartiti su cinque shard più uno shard model-extra separato. Niente di tutto ciò è un'affermazione su come si comporta in fase di serving — la VRAM a runtime e il throughput per questa esatta repo non sono pubblicati da nessuna parte che io possa citare oggi. La dimensione su disco proviene dall'elenco file, il formato dalla configurazione, e il comportamento di serving qui sotto è verificato dalla community su build NVFP4 strettamente correlate.

Che cos'è NVFP4 e in cosa differisce da FP8 e da INT8/AWQ

NVFP4 è il formato a virgola mobile a 4 bit di NVIDIA, introdotto per i tensor core di quinta generazione su Blackwell, e il blog tecnico ufficiale di NVIDIA è la fonte primaria corretta per esso. Memorizza i pesi come E2M1 — un bit di segno, due bit di esponente, un bit di mantissa — e li scala a blocchi: ogni 16 valori condividono una scala E4M3 FP8, e l'intero tensore riceve uno scalare FP32 per tensore. Questo schema a due livelli è il punto centrale del formato: recupera la gamma dinamica che un float a 4 bit ingenuo perderebbe, al costo di qualche bit di overhead per blocco. Le differenze pratiche, in forma sintetica:

• NVFP4 vs FP8 — entrambi sono a virgola mobile, ma FP8 (E4M3, 8 bit) gira su Hopper e Blackwell, mentre NVFP4 è a 4 bit ed è accelerato nativamente solo su Blackwell. NVIDIA cita pesi circa 3,5× più piccoli di FP16 e circa 1,8× più piccoli di FP8, e su Blackwell il matmul gira direttamente sui tensor core FP4.

• NVFP4 vs INT8/AWQ — INT8 (W8A8) e AWQ (W4A16) sono formati interi che funzionano da Ampere in poi; AWQ è a 4 bit ma intero, e sulla maggior parte dell'hardware i pesi vengono dequantizzati a un tipo più ampio per la moltiplicazione di matrici. NVFP4 è un float a 4 bit con scaling a blocchi, quindi mantiene più precisione nei bit bassi, e ha un percorso GEMM FP4 nativo che i formati interi non hanno.

• NVFP4 vs MXFP4 — i due vengono spesso confusi. MXFP4 usa blocchi di 32 elementi e scale E8M0 (potenze di due); NVFP4 usa blocchi di 16 elementi e scale E4M3. I blocchi più fini danno a NVFP4 un migliore isolamento dei valori anomali, motivo per cui il formato è lo standard de facto a 4 bit negli stack di servizio Blackwell.

Quale hardware ne trae beneficio — e quale no

Il fatto più importante di questa build: NVFP4 è un formato Blackwell. Dà il suo meglio solo sulle GPU i cui tensor core implementano FP4 GEMM nativamente, e su qualsiasi altra cosa è lo strumento sbagliato, non importa quanto veloce sia la macchina sulla carta.

• Blackwell — RTX 50-series, B200/B300, RTX PRO 6000, DGX Spark (GB10) — è qui che NVFP4 è la scelta giusta: core Tensor nativi FP4, il più piccolo ingombro di livello server nella linea non censurata, e il formato per cui la build è stata creata.

• Hopper — H100/H200 — nessun GEMM FP4 nativo. NVFP4 degrada a un percorso di dequantizzazione solo-pesi che è più lento e non porta alcun vantaggio. Usa Qwen3.8-27B-Uncensored-FP8 qui; quella build è verificata su esattamente questo hardware.

• Ampere/Ada — RTX 3090/4090 — NVFP4 non accelera neanche su queste. La build GGUF, con il suo livello Q4_K_M a 16,8 GB, è lo strumento giusto per una scheda da 24 GB.

• Apple Silicon — NVFP4 è irrilevante su un Mac. La build MLX (o GGUF) è quella che funziona.

Una sfumatura onesta: i fork della community eseguono NVFP4 weight-only su hardware pre-Blackwell. Una build NVFP4 della community dello stesso modello abliterato è esplicitamente configurata per le schede di classe V100 tramite un fork vLLM patchato, e le recenti ricette DGX Spark su Qwen3.8-27B sono un'altra cosa. Quelli sono percorsi specialistici con le loro avvertenze, non ciò a cui questa build è destinata. Se sei su Blackwell, nulla di tutto ciò ha importanza; se non sei su Blackwell, la build FP8 o GGUF è il download migliore.

Come servirlo

Il repository è taggato per vLLM e il formato compressed-tensors viene letto automaticamente da config.json — non si seleziona manualmente uno schema di quantizzazione. Lo stack su cui i professionisti convergono per le build Qwen3.8-27B NVFP4 è una versione recente di vLLM su una scheda Blackwell, una cache KV FP8 e la testa MTP del modello stesso utilizzata per il decoding speculativo. La guida NVFP4 di Unsloth, che è il riferimento comunitario più citato, raccomanda vLLM 0.25.0 o successiva con FlashInfer e la dipendenza kernel CUTLASS-DSL per il percorso FP4 veloce.

Un punto di partenza funzionante, assemblato dai flag verificati della nostra build FP8 e dalle ricette NVFP4 della community, tutto su una riga:

vllm serve orcarouter/Qwen3.8-27B-Uncensored-NVFP4 --kv-cache-dtype fp8 --max-model-len 262144 --reasoning-parser qwen3 --enable-auto-tool-choice --tool-call-parser qwen3_coder --speculative-config '{"method": "mtp", "num_speculative_tokens": 3}'

• FP8 KV cache — il modo più ampiamente compatibile per dimezzare la memoria cache; gli operatori riportano che raddoppia circa il contesto che puoi mantenere. Il supporto per la cache KV NVFP4 esiste ma è limitato ad alcuni backend di attenzione, quindi FP8 KV è l'impostazione predefinita più sicura.

• Decodifica speculativa MTP — il modello include una testa di draft MTP e la quantizzazione la mantiene in BF16. I professionisti riportano che due o tre token di draft funzionano bene con pesi NVFP4 su Blackwell, con i maggiori vantaggi nell'output strutturato come JSON e nelle chiamate di strumenti.

• Vision — l'encoder di visione è mantenuto in BF16 in questa build. Aggiungi --language-model-only per servire solo testo; rimuovilo se hai bisogno di input di immagini o video.

• Su un DGX Spark — un paio di problemi segnalati sul campo: tieni --gpu-memory-utilization a 0.90 o inferiore (valori più alti hanno bloccato la macchina durante il caricamento dei pesi), e aggiungi --safetensors-load-strategy lazy se la memoria è limitata. Hai anche bisogno di una build GB10 di vLLM per i kernel sm_121a.

Prestazioni oneste: non esistono numeri di throughput indipendenti e pubblicati per questo repository esatto. Le misurazioni che esistono riguardano build NVFP4 strettamente correlate. Unsloth riporta 1,41–1,49× i token al secondo di BF16 su una B200 per la propria build Qwen3.8-27B-NVFP4 (da 89,8 a 133,7 tok/s con batch 1, da 3.048 a 4.407 con batch 64), e un utente di DGX Spark sui forum NVIDIA riporta circa 20–32 tok/s con pesi NVFP4, una cache KV FP8 e profondità MTP 3. Entrambi sono degni di citazione; nessuno dei due è un benchmark di questo repository.

Modelli di utilizzo che funzionano davvero

I professionisti che eseguono i modelli della famiglia Qwen3.8-27B su Blackwell convergono su un pugno di impostazioni. Trattate questi come resoconti sul campo, non come indicazioni del fornitore — Qw​en non documenta gran parte di ciò, e la scheda di questo repository è ad accesso limitato.

• reasoning_effort è la manopola che conta di più.Il valore xhigh predefinito fa sì che il modello pensi a lungo a ogni richiesta. Chi esegue loop di agenti imposta medium come predefinito e passa a low — o disabilita completamente il pensiero con enable_thinking: false — per chiamate singole sensibili alla latenza. Su una singola GPU Blackwell, usare il ragionamento xhigh per un compito di routine è il modo per ritrovarsi con un modello veloce e risposte lente.

• I sampler sono abbinati alla modalità di pensiero, non indipendenti.Consenso della community: con thinking attivo si usa temperatura 1.0 / top_p 0.95; con thinking disattivato si usa temperatura 0.7 / top_p 0.80 con presence_penalty 1.5. Scambiare i due set degrada la qualità dell'output.

• Usa un template di chat aggiornato. Il template qwen3_5 avvolge ogni turno dell'assistente in un blocco di pensiero e molti operatori segnalano risposte in loop o troncate con template obsoleti; le varianti Qw​en-Fixed-Chat-Templates e Qw​en-Sharp corrette dalla community impostano preserve_thinking e fermano i loop. Se l'output servito continua oltre il token di stop, è la prima cosa da controllare.

• Prevedi un budget per le tracce di ragionamento lunghe nel lavoro degli agenti. Gli operatori segnalano che il modello della generazione 3.8 emette circa il doppio dei token per compito rispetto al suo predecessore 3.6 — il salto di qualità deriva in parte da un ragionamento più lungo. Per le risposte xhigh lunghe, trasmetti in streaming l'output del ragionamento o andrai incontro a timeout del gateway.

• La chiamata degli strumenti rimane intatta attraverso la quantizzazione.Il percorso di chiamata delle funzioni sopravvive sia all'abliterazione che alla conversione a 4 bit; attivalo con il parser di tool-call di qwen3_coder e il modello sceglie gli strumenti allo stesso modo del modello base.

Chi dovrebbe scegliere questa build — e chi no

La decisione onesta, senza ripetere la matematica di selezione della quantizzazione che i nostri post su FP8 e GGUF già trattano in dettaglio:

• Scegli NVFP4 se stai servendo su Blackwell e vuoi la minima impronta di livello server nella linea senza censura con velocità FP4-tensor-core — e stai facendo ricerca, lavoro red-team o di interpretabilità che legittimamente necessita di un modello abliterato.

• Scegli Qwen3.8-27B-Uncensored-FP8 se sei su Hopper, oppure vuoi il percorso vLLM più ampiamente verificato — sono gli stessi pesi a 8 bit, verificati su un H200, con un minimo di circa 40 GB di VRAM.

• Scegli Qwen3.8-27B-Uncensored-GGUF se sei su una GPU consumer o un Mac, oppure vuoi llama.cpp invece di vLLM — il livello Q4_K_M è il punto giusto per l'uso locale.

• Non scegliere nessuno dei due se vuoi la massima fedeltà, se stai costruendo qualsiasi cosa rivolta all'utente (vedi il limite di sicurezza qui sotto), o se non vuoi affatto fare self-hosting — la stessa linea senza censura viene servita tramite OrcaRouter riservata ai ricercatori, quindi non è richiesta una GPU.

Il confine di sicurezza — solo ricerca

Questo è un modello abliterato, e la quantizzazione non ripristina le protezioni. La direzione di rifiuto è stata rimossa dal flusso residuo di Qwen/Qwen3.8-27B, e NVFP4 è un cambiamento di precisione, non un intervento di sicurezza — il modello soddisferà richieste che il modello base rifiuta, e questa build non ha moderazione integrata. È rilasciato per la ricerca sull'interpretabilità, la sicurezza dell'IA e il red-team sotto Apache 2.0, e la responsabilità è vostra.

Due note di valutazione che emergono troppo raramente nello spazio dei modelli non censurati. Primo, un singolo jailbreak probe che passa banalmente non è una valutazione di sicurezza superata — i modelli abliterati falliscono quei test di proposito. Misura ciò che ti interessa davvero con le batterie appropriate (AdvBench, HarmBench e StrongREJECT per la dannosità; XSTest-safe per l'eccessivo rifiuto) e confronta i tassi di rifiuto prima e dopo l'intervento. Secondo, valuta il quantizzato, non solo il modello base: una build a 4 bit può cambiare il comportamento sui casi limite anche quando i punteggi aggregati sembrano a posto. Non distribuire questo prodotto agli utenti finali senza i tuoi strati di moderazione e prevenzione degli abusi.

Dove si inserisce OrcaRouter

Una build quantizzata di dieci giorni è il caso da manuale per il routing piuttosto che per il cablaggio fisso. Puoi attivare una route che punta alla build NVFP4 che esegui tu stesso e passare a un modello hosted se la build si comporta male sotto carico: un'unica interfaccia, nessun ricollegamento tra provider quando cambi. OrcaRouter trasmette il prezzo di listino del provider senza alcun ricarico, quindi se il prezzo del modello sottostante cambia, il tuo endpoint lo riflette lo stesso giorno anziché nel tuo ciclo di fatturazione.

E se il punto è evitare del tutto di eseguire una GPU: la stessa linea non censurata è disponibile tramite OrcaRouter, limitata a ricercatori di sicurezza e red team, con failover automatico tra i provider. Che tu auto-ospiti questa build NVFP4 o utilizzi la linea ospitata, in entrambi i casi è sufficiente una sola chiave API.

La conclusione

Qwen3.8-27B-Uncensored-NVFP4 è il download giusto se stai servendo il modello abliterato su Blackwell e vuoi l'impronta più piccola con la velocità dei tensor core FP4. È il download sbagliato su Hopper (usa la build FP8), su una GPU consumer o Apple (usa la build GGUF o MLX), o se hai bisogno della massima fedeltà. Non è nuovo — è scaricabile dal 19 agosto 2026 — ma viene scaricato in volume, e ora sai in cosa ti stai imbarcando prima di accettare il gate.

Non un'altra build di questo modello — Qwen3.8-Flash-Next-Uncensored è un rilascio separato: abliterato da Qwen3.8-Flash-Next, un'anteprima mixture-of-experts da 176B memorizzati / 6B attivi dell'architettura Qwen4. Stessa tecnica di abliterazione, pesi diversi, una propria collezione.

Tutte e sei le build 27B — BF16, GGUF, MLX, FP8, INT8 e NVFP4 — sono raccolte nella collezione Qwen3.8-27B-Uncensored su Hugging Face.

Questi pesi sono progettati per essere solo locali. Per una baseline ospitata con cui confrontare la build abliterata, Qwen3.8-27B è servito su OrcaRouter al prezzo di listino del provider con markup 0% — il modello standard, con l'allineamento della sicurezza intatto.