Qwen3.8-Flash-Next-Uncensored-NVFP4: Un Runbook di Servizio per Blackwell

Qwen3.8-Flash-Next-Uncensored-NVFP4 funziona su un'unica famiglia di GPU: Blackwell. NVFP4 gira su tensor core FP4 hardware, e Hopper (H100/H200) e qualsiasi cosa più vecchia semplicemente non li hanno. Se sei su Hopper, fermati qui — la Qwen3.8-Flash-Next-Uncensored-FP8 build è quella che vuoi. Tutto ciò che segue presuppone Blackwell (B100, B200, GB200, o una scheda della serie RTX 50), una build vLLM recente con supporto a qwen4_exp, e transformers ≥ 5.16.

Questa è la quantizzazione NVFP4 della build abliterata (senza rifiuto) di Qw​en Qw​en/Qwen3.8-Flash-Next, ridotta da 330 GB in BF16 a 178 GB su disco. OrcaRouter l'ha pubblicata su Hugging Face il 27 agosto 2026 come orcarouter/Qwen3.8-Flash-Next-Uncensored-NVFP4. Il repository è soggetto a gating: devi avere effettuato l'accesso a Hugging Face e accettato i termini del repository, altrimenti hf download e vllm serve orcarouter/Qwen3.8-Flash-Next-Uncensored-NVFP4 falliscono entrambi con un errore di autenticazione prima che venga trasferito un byte. Questa pagina è un runbook di servizio, non una copertura del lancio — la build ha due giorni e le domande che le persone realmente si pongono sono hardware, flag e quale build scegliere.

E prima che inizino i numeri: Qwen3.8-Flash-Next-Uncensored non è Qwen3.8-27B-Uncensored. Sono due modelli diversi che condividono un nome di famiglia e una tecnica di abliteration — pesi base diversi, architetture diverse, collezioni Hugging Face diverse. Flash-Next deriva dall'abliterazione di Qw​en/Qwen3.8-Flash-Next, un'anteprima mixture-of-experts instradata dell'architettura Qwen4 (qwen4_exp): 512 esperti, di cui dieci instradati più uno condiviso attivo, attenzione ibrida (layer lineari Gated DeltaNet accanto a layer full-attention), Hyper-Connections, un embedding n-gram PLE, una torre nativa per visione e video, e una testa MTP di decodifica speculativa. Il 27B deriva dall'abliterazione di Qw​en/Qwen3.8-27B, una base densa completamente diversa. Nessuna metrica di serving di una pagina del 27B si trasferisce a questo modello; dove una pagina del 27B è davvero utile — il primer sull'abliteration, la matematica generale per la selezione dei quant — è linkata qui sotto con ciò che si trasferisce e ciò che non si trasferisce.

Cos'è questa build, precisione per precisione.

Qwen3.8-Flash-Next è un MoE instradato: ogni token attiva 10 dei 512 esperti più un esperto condiviso, e solo pochi miliardi di parametri sono attivi per token, anche se il modello memorizzato è molto più grande. La build NVFP4 è una quantizzazione a precisione mista basata su compressed-tensors di quello stack, e la suddivisione è il punto chiave:

• Pesi degli esperti MoE — NVFP4 (4 bit, NVIDIA FP4 E2M1, gruppo di 16 con scale a blocchi FP8).

• Attenzione (self_attn.{q,k,v,o}), le proiezioni linear_attn, l'esperto condiviso e lm_head — FP8 (8-bit).

PLE n-gram embedding, token e vision embeddings, Hyper-Connections, l'indexer QSA, Gated-DeltaNet conv/dt, tutte le norme e l'intera vision tower — BF16, mantenuti a piena precisione.

Tre proprietà della conversione contano più della suddivisione di precisione in sé. Primo, è solo pesi: le attivazioni vengono quantizzate dinamicamente in fase di esecuzione, non c'è calibrazione statica, e i pesi derivano direttamente dal checkpoint BF16 (la scheda la definisce data-free). Secondo, la modifica di abliteration è incorporata nei pesi, quindi la rimozione del rifiuto sopravvive alla quantizzazione — una conversione a 4 bit è un cambiamento di precisione, non un intervento di sicurezza. Terzo, la cache KV non è quantizzata; rimane BF16 in fase di esecuzione. Quest'ultima è facile da trascurare ed è rilevante nel contesto nativo di 262.144 token del modello, dove la cache KV è una voce di memoria reale accanto ai pesi.

La dimensione su disco è dominata da un singolo tensore. La scheda descrive l'embedding n-gram PLE come un unico tensore con ~66 miliardi di parametri, mantenuto in BF16 per scelta progettuale; è lo shard più grande e il motivo per cui la build è di 178 GB anziché una cifra più contenuta. Una discrepanza da segnalare piuttosto che nascondere: la scheda gemella FP8 definisce la stessa tabella come PLE n-gram da 51 miliardi di parametri, mentre la nota W4A4 di questa scheda la indica come ~100 GB. Le due schede riportano cifre diverse per la stessa tabella; tratta quindi ciascuna come il numero della propria scheda — e quando dimensioni un deployment, presupponi che la tabella sia grande in BF16 e pianifica di conseguenza.

Il prerequisito hardware, esplicitato

Questa è la sezione più breve e più importante della pagina. NVFP4 è un formato Blackwell: il percorso veloce è un GEMM FP4 nativo sui tensor core di quinta generazione, e senza quell'hardware il formato non ha nulla su cui girare. La riga dei requisiti della scheda è esplicita — una GPU Blackwell (B100 / B200 / GB200 / serie RTX 50), perché NVFP4 usa i tensor core FP4 hardware, e non funzionerà su Hopper (H100/H200) o precedenti, che non dispongono di calcolo FP4.

I redirect, in un unico posto:

• Su Hopper (H100/H200) — servi invece Qwen3.8-Flash-Next-Uncensored-FP8. Sono gli stessi pesi a 8 bit, funziona su Hopper e Blackwell, ed è la build coperta dal runbook FP8 di questo blog.

• Su una GPU NVIDIA consumer o su una macchina con CPU — la build GGUF, con i suoi 13 quants di llama.cpp, è il percorso locale.

• Su Apple Silicon — la build MLX, nei livelli a 4/6/8 bit, è il percorso Metal nativo.

Il requisito di runtime è vincolante quanto il silicio. qwen4_exp è un'architettura nuovissima, quindi le build stock di vLLM antecedenti a essa rifiuteranno di caricare il checkpoint. È necessario un vLLM recente con supporto per qwen4_exp, oltre al lettore NVFP4 di compressed-tensors (il formato viene rilevato da config.json, non selezionato manualmente), e transformers ≥ 5.16. L'input multimodale richiede inoltre lo stack di visione Qw​en del runtime; il servizio solo testo funziona senza di esso.

Il comando serve della scheda, flag per flag.

L'invocazione della scheda del modello stessa è un buon punto di partenza, e vale la pena capire a cosa serve ogni flag piuttosto che copiare e incollare alla cieca:

vllm serve orcarouter/Qwen3.8-Flash-Next-Uncensored-NVFP4 --tensor-parallel-size 4 --trust-remote-code --enable-expert-parallel --enable-auto-tool-choice --tool-call-parser qwen3_coder

• --tensor-parallel-size 4 — i pesi occupano circa 178 GB su disco, quindi la scheda li distribuisce su quattro GPU. Questa è la configurazione per cui la build è dimensionata; non interpretarla come un suggerimento.

• --trust-remote-code — richiesto per un'architettura personalizzata. Il codice di modellazione di qwen4_exp non è ancora nel registro standard di transformers, quindi vLLM carica il codice dell'architettura dal repository. Ti stai fidando di quel codice, una decisione normale ma reale per un'architettura completamente nuova.

• --enable-expert-parallel — suddivide gli esperti tra i ranghi tensor-parallel invece di replicarli, ed è ciò che rende un MoE a 512 esperti trattabile su TP4. La scheda gemella FP8 indica la ragione più precisa in quella configurazione: senza di essa, la larghezza intermedia del MoE divisa per TP non è divisibile per la dimensione del blocco FP8. Trattalo come obbligatorio, non opzionale.

• --enable-auto-tool-choice e --tool-call-parser qwen3_coder — insieme attivano il function calling. Il flag auto permette al modello di decidere se chiamare uno strumento, e il parser qwen3_coder decodifica il suo formato di chiamata degli strumenti, la stessa famiglia di parser utilizzata da Qwen3.8-27B e Qwen3.8-Flash-Next.

Una volta avviato, l'endpoint compatibile OpenAI su /v1/chat/completions offre l'intera gamma di funzionalità tramite lo stack Qwen4 del runtime: tool calling come sopra, reasoning tramite chat_template_kwargs.enable_thinking e vision attraverso le parti di contenuto image_url. Non è necessario un server separato per il multimodale; è lo stesso endpoint.

Una nota strutturale dalla scheda: non esiste una variante completamente statica W4A4 di questa build, e non ce ne sarà una a basso costo. Una conversione statica W4A4 richiede un forward pass di calibrazione delle attivazioni, e quel pass deve contenere l'embedding n-gram di ~100 GB su una singola GPU. È la stessa ragione per cui la tabella PLE domina l'elenco dei file, ed è il motivo per cui questa build rimane solo pesi con attivazioni dinamiche.

Report sul campo della comunità — come appare davvero servire questo

Non vengono pubblicati numeri di throughput o latenza per questo esatto repository, e questa pagina non li inventerà. Ciò che esiste è un insieme crescente di report sul campo da parte di professionisti che servono le build base Qwen3.8-Flash-Next NVFP4 — la stessa architettura, la stessa suddivisione di precisione NVFP4/FP8/BF16, a parte la modifica di abliterazione — e il comportamento di serving si trasferisce direttamente. Questi sono risultati della community, non indicazioni del fornitore, e le persone che li hanno riportati utilizzavano hardware Blackwell con lo stesso schema di quantizzazione.

• La decodifica speculativa MTP è la più grande leva di prestazioni. Il modello include una testa di draft a predizione multi-token. Su una RTX PRO 6000 (96 GB, SM120), il modulo MTP viene caricato quantizzato in NVFP4 per circa 0,51 GB di VRAM — il report ha misurato una lunghezza di accettazione di 2,3–3,9 su un massimo di 4 e un tasso di accettazione di 0,86–0,96. Lo stesso report ha misurato una decodifica mediana a flusso singolo di 180–226 tok/s (216,9 su coding, 225,8 su un workload di chiamate a strumenti di un agente, 136,6 su reasoning) rispetto a una baseline di circa 105 tok/s, e ha risposto a un prompt di 216.685 token in 8,4 secondi. Considera i numeri come la configurazione di una singola persona, non come una specifica.

• Sposta l'embedding n-gram PLE nella RAM dell'host. Poiché la tabella è enorme e raramente rappresenta un collo di bottiglia per il throughput, le ricette della community su singole schede Blackwell la collocano nell'host (~50 GiB di RAM host libera nel report RTX PRO 6000) e la mappano tramite mmap da NVMe, scambiando un po' di latenza per riuscire a caricare il modello. Aspettati di fare qualcosa di simile a meno che tu non abbia un budget VRAM molto ampio.

• Imposta esplicitamente la finestra di contesto. Con cache KV BF16 e MTP attivo, un pool KV auto-dimensionato è cresciuto oltre la capacità della scheda e ha causato un OOM durante una prefill lunga; fissando max-model-len / max-total-tokens a 262144 si è ripristinato il margine. Con un contesto di 262K, la cache KV è una voce da mettere in conto, non un default.

• Un bug dell'autotune di FlashInfer corrompe silenziosamente l'output.La modalità di guasto più importante sul campo: l'autotune seleziona le tattiche del kernel fused-MoE solo in base alla latenza e non verifica mai la correttezza numerica, quindi con alcune forme la decodifica collassa in un token ripetuto. Il report su RTX PRO 6000 lo ha riprodotto con 36 generazioni su 36 corrotte con autotune attivo, e 0 su 36 con autotune disattivato — la soluzione alternativa è disabilitare l'autotune di FlashInfer (in vLLM, --no-enable-flashinfer-autotune; in SGLang, --disable-flashinfer-autotune). Se l'output servito degenera improvvisamente, controlla questo prima di toccare qualsiasi altra cosa.

• DGX Spark (GB10, SM121) necessita di patch dedicate. I pesi NVFP4 (~126 GiB nella build della community) non entrano in un singolo Spark da 128 GB, quindi le ricette SGLang eseguono tensor-parallel 2 su due nodi tramite RoCE, e il resolver QSA sparse-decode subordina il kernel FlashInfer veloce a un controllo is_sm100_supported() che fallisce su SM121, ripiegando su un percorso che muore durante il warmup — la soluzione è una piccola patch più l'offload PLE. Aspettati ~47–50 tok/s in decode, con picchi vicini a 70 con MTP4 e CUDA graphs, e verifica che il kernel giri davvero su SM121 prima di promettere un benchmark.

Ragionamento, tool calling e visione attraverso lo stack Qwen4

Il consenso della comunità sulla generazione Qwen3.8 si applica a questo modello con la solita avvertenza che si tratta di pratica sul campo, non di indicazioni del fornitore.

• reasoning_effort è la manopola che conta di più. Il template di chat ha come default xhigh, che fa pensare a lungo il modello a ogni richiesta. Gli operatori dell'agent-loop impostano medium come predefinito e scendono a low per chiamate sensibili alla latenza; enable_thinking false disabilita completamente il ragionamento quando non serve. Su una singola scheda Blackwell, lasciare xhigh attivo per chiamate di routine è il modo in cui un modello veloce produce risposte lente.

• Abbina i sampler alla modalità di pensiero. I professionisti concordano su temperatura 1.0 / top-p 0.95 quando il pensiero è attivo, e temperatura 0.7 / top-p 0.80 con una penalità di presenza intorno a 1.5 quando è disattivato. Mescolare i due set degrada la qualità dell'output.

• La chiamata degli strumenti sopravvive sia all'abliterazione che alla conversione a 4 bit. Il percorso di chiamata delle funzioni è intatto, che è ciò che il parser qwen3_coder e i flag auto-tool-choice configurano. Per un red team questo è un fatto a doppio taglio, poiché significa che l'abuso agentico è pienamente operativo su un modello non allineato — trattato di seguito.

• La visione è preservata, e questo amplia la superficie d'attacco. Il vision tower non è mai stato toccato dall'abliteration e rimane in BF16, quindi l'input delle immagini funziona tramite le parti di contenuto image_url. I professionisti che valutano la linea non censurata trattano il percorso multimodale come obiettivo di valutazione di prima classe: l'iniezione di prompt trasportata in un'immagine arriva su un modello privo di comportamenti di rifiuto da aggirare.

Quale build dovresti servire

La collezione Flash-Next ha cinque build — BF16, GGUF, MLX, FP8 e questa NVFP4 — e la logica di scelta onesta è basata su hardware e compromessi, non su una classifica.

• NVFP4 (questa build, ~178 GB su disco) — la scelta Blackwell. Tensor Core FP4, esperti a 4 bit, la build più recente della collezione e la più piccola delle sue build del server vLLM, e quella di cui parla questa pagina.

• FP8 (~186 GB su disco) — la scelta per Hopper, e altrettanto a suo agio su Blackwell. Gli stessi pesi a 8 bit, che è il percorso vLLM più ampiamente verificato e quello con il requisito di parallelismo esperto più chiaro.

• GGUF (13 quants, IQ2_XXS ~52 GB to Q5_K_M ~125 GB) — la scelta di llama.cpp per macchine consumer NVIDIA, AMD o CPU. Non serve Blackwell, non serve vLLM.

• MLX (livelli da 4/6/8 bit, circa 163–221 GB) — la scelta per Apple Silicon, Metal nativo, testa MTP inclusa.

Due note oneste prima che tu scelga. In primo luogo, le versioni NVFP4 e FP8 distano solo circa otto GB su disco, perché entrambe mantengono la grande tabella n-gram in BF16 — il risparmio a 4 bit è concentrato nei pesi degli esperti, non nell'ingombro totale. Il vero vantaggio di NVFP4 su Blackwell è la velocità dei tensor core FP4 su quegli esperti, non un file drasticamente più piccolo. In secondo luogo, la scheda descrive NVFP4 come una derivazione deterministica dei pesi che eredita la valutazione di abliteration con un piccolo trade-off aggiuntivo di qualità dagli esperti a 4 bit, e non quantifica quel trade-off. Non è quantificato — trattalo come un costo reale ma non specificato degli esperti più piccoli, non come trascurabile.

La valutazione, letta correttamente

La scheda riporta l'abliteration misurata sulla build BF16 servita con vLLM rispetto al Qw​en/Qwen3.8-Flash-Next ufficiale: il tasso di rifiuto dei prompt dannosi che crolla dal 64–100% a circa 0–3,3%, l'eccessivo rifiuto dei prompt benigni che rimane vicino allo zero e la capacità che resta entro ±2 punti dalla base. Tre cose da capire bene su questi numeri. Sono misurazioni effettuate sulla build BF16, che questa build a 4 bit eredita per deduzione piuttosto che per misurazione diretta. Sono cifre del fornitore stesso, prodotte con un classificatore della frase iniziale basato su regole, che le schede della collezione descrivono come indicativo piuttosto che di livello pubblicabile — una misurazione interna della propria modifica, non una verifica indipendente. E non dicono nulla sul compromesso di qualità NVFP4 di cui sopra, che la scheda non quantifica.

Il confine di sicurezza — solo ricerca

La dichiarazione di non responsabilità della scheda è netta, ed è la parte di questa pagina che non deve suonare come una formula preconfezionata. Questo modello ha subito una rimozione sostanziale dell'allineamento alla sicurezza: la direzione di rifiuto è stata rimossa per ortogonalizzazione dal flusso residuo, e il modello soddisferà richieste dannose, non etiche o illegali che l'originale Qwen3.8-Flash-Next avrebbe rifiutato. È rilasciato esclusivamente per ricerca legittima — interpretabilità, studio dell'IA sicura e dei meccanismi di rifiuto, red-teaming e valutazione della robustezza — e gli autori non accettano alcuna responsabilità per un uso improprio. Ti assumi la piena responsabilità di ciò che genera e aggiungi i tuoi strati di sicurezza e moderazione prima che qualsiasi cosa raggiunga un utente. Apache 2.0 è il livello minimo; il vincolo dello scopo di ricerca si colloca al di sopra.

Due cose che il discorso sui modelli non censurati sbaglia, e questa scheda le rende impossibili da ignorare. Primo, una sonda di jailbreak che ha successo contro questo modello non è una valutazione di sicurezza superata — è il comportamento pubblicizzato. Un modello abliterato fallisce quelle sonde apposta; misurarlo con un singolo test "can you jailbreak it" significa misurare che la modifica ha funzionato, non che un guardrail sia solido. Secondo, la torre visiva preservata e il percorso di chiamata degli strumenti intatto ampliano la superficie d'attacco reale oltre il testo: l'iniezione di prompt tramite input immagine e l'uso improprio degli strumenti agentici sono entrambi pienamente operativi, ed è proprio per questo che l'impostazione red-team lo tratta come una sonda di capacità, non come un candidato chatbot. Se il tuo caso d'uso è distribuire un assistente rivolto all'utente, questo non è il tuo modello, e questo è voluto.

Dove si inserisce OrcaRouter

Un build di due giorni, con gate, solo self-host è il caso da manuale per il routing piuttosto che per il cablaggio fisso. Quando esegui tu stesso questo build NVFP4, puoi attivare una rotta che punta a esso e che fa failover su un modello hosted se il build si comporta male sotto carico — un'unica interfaccia, nessun ricablaggio tra provider quando cambi. Per il lavoro di valutazione in particolare, la baseline servita censurata è il confronto che vuoi, ed è a un solo tasto di distanza: il catalogo include Qwen3.8-Flash di Ali​baba a $0,15 per milione di input e $0,47 per milione di output, passato al prezzo di listino del provider con markup 0%, così un harness red-team può passare dalla base hosted censurata al tuo build locale non censurato senza un secondo contratto, e qualsiasi variazione di prezzo del fornitore arriva sul tuo endpoint lo stesso giorno.

Chi dovrebbe scaricarlo — e chi no

Scarica orcarouter/Qwen3.8-Flash-Next-Uncensored-NVFP4 se sei su Blackwell, vuoi la footprint server più piccola nella collezione Flash-Next con la velocità dei tensor-core FP4 e stai facendo il lavoro di ricerca per cui questa linea esiste. Scarica Qwen3.8-Flash-Next-Uncensored-FP8 se sei su Hopper o vuoi il percorso più ampiamente verificato. Scarica la build GGUF se hai una GPU consumer o una macchina con CPU, la build MLX se hai Apple Silicon e nulla se l'obiettivo è una distribuzione rivolta all'utente finale. Leggi il gate e il disclaimer prima di accettare l'uno o l'altro: sono i termini del modello, non una formalità.

Tutte e cinque le build Flash-Next — BF16, GGUF, MLX, FP8 e NVFP4 — sono raccolte nella collezione Qwen3.8-Flash-Next-Uncensored su Hugging Face.

Un modello diverso, non un'altra build di questo: Qwen3.8-27B-Uncensored è abliterato da una base diversa e ha la propria collezione e i propri runbooks.

Questi pesi sono solo locali per progettazione. Per una baseline hosted con cui confrontare la build abliterata, Qwen3.8-Flash è servito su OrcaRouter al prezzo di listino del provider con markup 0% — il modello stock, con l'allineamento di sicurezza intatto.