Servire Qwen3.8-Flash-Next-Uncensored-FP8: un runbook vLLM per la build block-FP8

Qwen3.8-Flash-Next-Uncensored-FP8 — la build block-FP8 del Flash-Next abliterato — è l'artefatto che si scarica effettivamente quando si serve questo modello su hardware da datacenter, ed è l'ultimo della collezione ad avere un runbook dedicato. Si trova su Hugging Face all'indirizzo orcarouter/Qwen3.8-Flash-Next-Uncensored-FP8: si tratta del Qwen3.8-Flash-Next di Qw​en con la direzione di rifiuto rimossa, ri-quantizzato offline secondo lo schema FP8 esatto del Qwen3.8-Flash-Next-FP8 ufficiale, così vLLM lo serve sullo stesso percorso kernel. È la build a cui chiunque esegua questo modello su GPU di classe Hopper o successive farà riferimento, e il percorso di serving ha un flag che è facile sbagliare e difficile diagnosticare quando lo è.

Innanzitutto, il confine, perché i lettori continuano a confonderlo e questo cambia tutto ciò che segue. Qwen3.8-Flash-Next-Uncensored e Qwen3.8-27B-Uncensored sono due modelli diversi, non due build dello stesso modello. Pesi di base diversi — Qwen3.8-Flash-Next rispetto a Qwen3.8-27B — architetture diverse, rilasci di pesi diversi, collection Hugging Face diverse. Condividono una tecnica di abliterazione e un nome di famiglia; tutto qui. Nessuno dei valori della pagina 27B si applica a questo modello, e se sei arrivato qui da una ricerca sulla 27B, il runbook locale della 27B è una pagina separata con un insieme separato di decisioni.

Questa pagina è la pagina di serving Flash-Next FP8 e nient'altro. Il runbook GGUF/MLX copre la spiegazione dell'abliteration per questo modello e le due linee di build per hardware consumer; la tecnica alla base dell'intera famiglia è spiegata nel primer sull'abliteration e nell'explainer più ampio sugli LLM non censurati; e Qwen3.8-27B-Uncensored-FP8, il modello gemello a cui potresti essere stato indirizzato, ha il suo runbook FP8. Qui ci concentriamo su una sola domanda: come servire la build block-FP8, cosa si rompe se lo si fa male, e cosa i numeri della scheda dicono e non dicono.

Prima di iniziare: il gate e il runtime

Due cose controllano l'accesso a questo repository, ed entrambe producono errori che sembrano qualcos'altro.

Il primo è l'accesso. Il repository è protetto: devi aver effettuato l'accesso a Hugging Face e aver accettato i termini del repository prima che qualsiasi download funzioni. La pagina del modello in sé è leggibile senza account — l'intera scheda descrittiva è pubblica — ma i pesi non lo sono. In parole povere, senza una sessione autenticata che abbia accettato i termini, sia hf download che vllm serve orcarouter/Qwen3.8-Flash-Next-Uncensored-FP8 falliscono con un errore di autenticazione, non con un amichevole "devi cliccare su Accetta". Completa prima il click-through una tantum, poi scarica i ~186 GB con la CLI di hf oppure lascia che vLLM risolva il repository al primo avvio.

Il secondo è il runtime. Il checkpoint si registra sotto l'architettura qwen4_exp (Qwen4ExpForConditionalGeneration), che la vLLM stock e Transformers stock non possono caricare. Servono l'immagine vLLM day-0 e transformers 5.16+. Questo è l'errore "non si carica" più comune in assoluto nei runbook della community di questa settimana — non un download corrotto, ma un runtime che precede l'architettura. L'immagine non è opzionale; è la via.

Hardware, così puoi pianificare prima di tirare fuori qualsiasi cosa: l'invocazione della scheda punta a un nodo a 8 GPU, e le indicazioni della ricetta ufficiale vLLM per il checkpoint FP8 si applicano qui poiché le build corrispondono tensor-per-tensor — circa 265 GB di VRAM GPU per una distribuzione su nodo completo, con TP2 trattato come minimo sulle classi GB300 e TEP4/TEP8 come configurazioni validate per l'intero tray.

Perché esiste la build FP8 — e perché “percorso kernel identico” è il punto centrale

I pesi BF16 abliterati sono la fonte di verità; questa repo contiene quel modello riquantizzato offline, riproducendo deliberatamente la ricetta ufficiale di Qwen3.8-Flash-Next-FP8. Il quantizzatore tocca solo le 512 proiezioni degli esperti instradati — experts.{e}.down/gate/up_proj — separandole dal layout 3D della build BF16 e memorizzandole come pesi float8_e4m3fn con scale weight_scale_inv BF16 in blocchi da 128×128. Le attivazioni sono FP8 dinamiche per-token; non esiste un set di calibrazione. Tutto il resto rimane in BF16: attention e linear_attn, l'esperto condiviso, il router MoE (mlp.gate), i mixer Hyper-Connection, gli embedding, lm_head, la testa di decodifica speculativa MTP e l'intera torre visiva.

La riga del “percorso kernel identico” è più che marketing, e merita una frase. La build è stata verificata rispetto al checkpoint FP8 ufficiale: le scale dei blocchi si riproducono esattamente (scale_relerr = 0) e i codici FP8 corrispondono con arrotondamento sub-ULP. Ecco perché vLLM la esegue con gli stessi kernel FP8 a scala di blocco e la stessa decodifica speculativa MTP della versione ufficiale — i tensori sono effettivamente gli stessi tensori, meno la direzione di rifiuto.

Concretamente, questo ti dà circa 186 GB su 131 shard (152.089 tensori, di cui 75.264 in FP8), 262.144 token di contesto nativo, la torre visione + video preservata byte per byte (333 tensori visual.*) e la testa MTP intatta. I pesi sono stati prima abliterati — una singola direzione di rifiuto stimata al layer 24 ed eliminata tramite ortogonalizzazione da 149 tensori di scrittura residuale in float32, seguendo Arditi et al. (2024) — e i writer residuali della testa MTP sono stati modificati coerentemente, così la decodifica speculativa continua a funzionare. Quest'ultimo dettaglio non è scontato, ed è la differenza tra una testa che accelera la decodifica e una che la degrada silenziosamente.

L'unico flag che determina il successo o il fallimento del caricamento.

Servi questa build senza --enable-expert-parallel e ottieni un errore che sembra un bug di shape, non un errore di configurazione. È l'errore di serving più segnalato per questo checkpoint, ed è interamente deterministico.

Ecco il calcolo. La proiezione fusa gate+up degli esperti instradati ha una dimensione intermedia di 640. Block-FP8 quantizza in blocchi larghi 128. Con il parallelismo tensoriale semplice, quel 640 viene diviso tra i rank — 640 ÷ TP — e per i gradi di TP comuni (2, 4, 8) la fetta per rank non è divisibile per 128: TP8 dà 80, TP4 dà 160, TP2 dà 320. vLLM quindi rifiuta di caricare i pesi con un errore che assomiglia a una mancata corrispondenza di forma: la output_size del peso di gate e up = 80 non è divisibile per la block_n di quantizzazione del peso = 128.

Il parallelismo esperto lo risolve suddividendo i pesi degli esperti tra i ranghi expert-parallel invece che tra i ranghi tensor-parallel, il che preserva i confini dei blocchi FP8. Ecco perché il flag è obbligatorio per questa build: con --enable-expert-parallel, TP8 diventa un TEP8 funzionante. (È innocuo per la build BF16, dove non ci sono blocchi FP8 da preservare.) La ricetta ufficiale di vLLM è esplicita: la TP8 semplice è incompatibile con i blocchi di quantizzazione a 128 del checkpoint, e una issue vLLM aperta due giorni dopo la pubblicazione dei pesi documenta lo stesso identico errore su un nodo 8×L40s con TP2, TP4 e TP8. Se un caricamento fallisce con un errore che sembra di forma, controlla il flag prima di controllare il download.

Il comando esatto

Ecco l'invocazione docker della card, riprodotta fedelmente:

docker run -d --name flashnext --gpus all --ipc host -p 8000:8000 -v /path/to/Qwen3.8-Flash-Next-Uncensored-FP8:/model vllm/vllm-openai:qwen38-flash-next-x86_64-cu130 --model /model --served-model-name Qwen3.8-Flash-Next-Uncensored --tensor-parallel-size 8 --trust-remote-code --max-model-len 262144 --enable-expert-parallel --enable-auto-tool-choice --tool-call-parser qwen3_coder

Esamina le bandiere che non sono ovvie:

• vllm/vllm-openai:qwen38-flash-next-x86_64-cu130 — l'immagine day-0 di qwen4_exp. Non si tratta di una vLLM generica; è l'immagine specifica per l'architettura, e le immagini standard precedenti a qwen4_exp non riusciranno affatto a caricare il checkpoint.

• --trust-remote-code— carica il codice di modellazione qwen4_exp incluso nel repository. Senza di esso, il loader si rifiuta per principio.

• --max-model-len 262144 — corrisponde alla finestra di contesto nativa. È meglio specificarlo esplicitamente qui piuttosto che lasciarlo a un valore predefinito.

• --enable-expert-parallel — richiesto per la build FP8, per i motivi indicati nella sezione precedente. La scheda nota che è innocuo per BF16.

• --enable-auto-tool-choice --tool-call-parser qwen3_coder — attiva la chiamata di strumenti e funzioni utilizzando il formato XML Qwen3-Coder. Se si lasciano disattivati, il modello continua a chattare, ma l'uso agentico degli strumenti è disattivato.

• --tensor-parallel-size 8 — l'invocazione della scheda presuppone un nodo a 8 GPU (8× classe Hopper). Con --enable-expert-parallel si tratta di un deployment TEP8.

Una volta che il container è in esecuzione, l'endpoint è compatibile con OpenAI su :8000/v1. Imposta --served-model-name su qualsiasi cosa i tuoi client si aspettino; la scheda usa Qwen3.8-Flash-Next-Uncensored.

Alternative, tutte nella scheda o confermate dai professionisti questa settimana: eseguire vllm serve orcarouter/Qwen3.8-Flash-Next-Uncensored-FP8 direttamente una volta autenticata la tua sessione HF; usare SGLang tramite l'immagine lmsysorg/sglang:qwen38flashnext con --tp 8 --ep 8 — stesso requisito di parallelismo esperto, stessa ragione; e usare Transformers con pipeline("image-text-to-text", ...) su transformers 5.16+ se vuoi scrivere script per interagire con il modello piuttosto che servirlo.

Cosa funziona davvero quando lo servi

I pattern in questa sezione sono risultati della community, emersi da runbook di professionisti e thread di forum di questa settimana, non indicazioni del fornitore. Quando più di una configurazione riporta lo stesso comportamento, vale la pena trattarlo come reale:

• La decodifica speculativa MTP funziona. Aggiungi --speculative-config '{"method":"mtp","num_speculative_tokens":3}' e vLLM utilizza la testa MTP conservata. Diversi runbook riportano che MTP è il motivo per cui la decodifica di questo modello rimane utilizzabile nonostante le sue dimensioni.

• OOM al caricamento? Sposta la tabella n-gram.L'embedding n-gram PLE da 51 miliardi di parametri è la sorpresa di memoria in questa architettura. VLLM_PLE_CPU_OFFLOAD=1 lo sposta nella RAM host — dagli almeno ~51 GB lì. La ricetta ufficiale e i runbook multi-nodo della community fanno entrambi ricorso a questo flag.

• La visione è reale, non vestigiale. La torre visione + video è preservata byte per byte, quindi questo rimane un modello visione-linguaggio completo. Passa una parte di contenuto image_url in un completamento di chat e lo stesso endpoint fornisce la comprensione delle immagini; i test OCR della community su questa build riportano superamenti puliti.

• Il ragionamento è attivo per impostazione predefinita — e questo cambia il quadro della sicurezza. Il template di chat abilita il pensiero a meno che non si dica diversamente. Attiva/disattiva per richiesta con chat_template_kwargs={"enable_thinking": true|false}, e aggiungi un parser di ragionamento se vuoi che il testo del pensiero sia separato dalla risposta. A causa di questa impostazione predefinita, stai quasi sempre servendo il modello con il pensiero attivo, a meno che non lo disattivi esplicitamente.

• 262K nativi, 1M con override della rope. Il contesto nativo è di 262,144 token. Per arrivare a 1M serve un override esplicito del rope-scaling YaRN più una variabile d'ambiente che alzi il limite max-model-len di vLLM — e dovresti prima eseguire test di regressione sulla qualità a contesto più breve, perché l'estensione cieca 4× è dove la qualità a contesto lungo di solito degrada.

Cosa dicono i numeri della carta — e cosa non dicono

Queste sono le misurazioni del fornitore sulla propria modifica, pubblicate nella scheda del modello e misurate su questi esatti pesi serviti con vLLM rispetto alla base ufficiale con script e impostazioni identici. Riportale per quello che sono: indicative, e non una verifica indipendente.

Il punto principale è il crollo del rifiuto con il ragionamento disattivato. Nella suite di prompt dannosi della scheda (n da 50 a 150 per benchmark), il rifiuto di base varia dal 64% al 100%, mentre questa build dallo 0% al 2,7%: AdvBench 100%→2.0%, JailbreakBench 94%→0.0%, StrongREJECT 99.3%→1.3%, HarmBench 100%→1.3%, MaliciousInstruct 98%→0.0%, SimpleSafetyTests 64%→2.0%, ForbiddenQuestions 75.3%→2.7%, e una sonda personalizzata cinese/inglese 63.6%→0.0%.

Ora la metà onesta. Il tasso di rifiuto del modello base crolla quando il pensiero è abilitato — AdvBench scende dal 100% sul modello base al 7,0% con il ragionamento attivo — quindi il confronto con il pensiero attivo è molto meno drammatico: questa build si attesta allo 0,0% sulla stessa suite, ma sta sottraendo un piccolo numero a un numero che il modello base aveva già ridotto. Citare solo i dati con il pensiero disattivato significa presentare la metà lusinghiera della storia, ed è esattamente la metà su cui una valutazione di sicurezza non deve fare affidamento.

Over-refusal su prompt benigni (XSTest-safe, n=250) scende dal 9,6% sul modello base all'1,2% su questa build con il pensiero disattivato — un vero miglioramento, poiché un modello che rifiuta prompt benigni è la modalità di fallimento più silenziosa. La ritenzione delle capacità su MMLU / MMLU-Pro / GSM8K / CMMLU mostra delta rispettivamente di −2,0, −1,2, −1,3 e −0,6 punti, coerenti con l'affermazione che ortogonalizzare una direzione costa quasi zero capacità generale. La chiamata di strumenti, la visione/OCR e il ragionamento risultano tutti funzionanti su questa build.

Due avvertenze sovrastano tutto quanto sopra. La metrica del rifiuto deriva da un classificatore basato su regole per la frase di apertura, che la scheda stessa definisce indicativa, non un giudice LLM o un numero di livello pubblicabile — un panel umano o un modello giudice non riprodurrà queste cifre esatte. E la colonna delle avvertenze conta: nella suite con pensiero disattivato, circa dalla metà ai tre quarti degli output di questa build si aprono ancora con una breve dichiarazione di non responsabilità prima di rispettare la richiesta. Il modello raramente rifiuta; piuttosto, ricorre a cautele. "Senza censura" qui significa che risponde, non che risponde senza preamboli.

La sezione sulla sicurezza non è una formalità

Leggi questo prima di tirare i pesi, non dopo.

Questo modello ha subito una rimozione sostanziale del suo allineamento di sicurezza, e il meccanismo è specifico: un'unica direzione di rifiuto è stata stimata nel flusso residuo e rimossa per ortogonalizzazione da ogni matrice di scrittura residua — 149 in tutto — con calcoli in float32. La conseguenza è dichiarata apertamente, non accidentale. La scheda del modello è categorica: il modello soddisferà richieste dannose, non etiche, offensive o illegali che il Qwen3.8-Flash-Next di base rifiuterebbe, e che non dispone di salvaguardie integrate significative. È rilasciato esclusivamente per ricerca legittima — interpretabilità, studio dell'AI-safety e dei meccanismi di rifiuto, red-teaming, valutazione della robustezza ed esperimenti controllati — e l'utente si assume la piena responsabilità, anche legale, per ciò che genera. La licenza Apache 2.0 disciplina ciò che puoi fare con i pesi.

Due cose da fare esattamente bene, perché questa build le rende facili da sbagliare.

Prima di tutto, un probe di jailbreak che “riesce” contro questo modello non è una valutazione di sicurezza superata. È il comportamento dichiarato. Se la tua valutazione afferma che “la sicurezza di questo modello è stata aggirata”, hai misurato il design, non una vulnerabilità. Ciò che costituirebbe davvero un risultato è un rifiuto che sopravvive all'abliteration, o una regressione delle capacità — e i numeri della scheda suggeriscono che entrambi sono rari.

Secondo, la superficie di attacco preservata è più ampia del solo testo. La torre di visione è intatta byte per byte e la chiamata degli strumenti funziona, quindi sia l'input delle immagini che l'uso agentico sono attivi. Un piano di red team che esplora solo prompt testuali non tiene conto delle modalità che questo modello espone realmente. E i numeri di rifiuto sopra sono un classificatore basato su regole applicato alla modifica del fornitore — non sono una verifica indipendente di alcunché, inclusa la sicurezza.

Non distribuire questo prodotto agli utenti finali o in produzione senza aggiungere i tuoi livelli di sicurezza, moderazione e prevenzione degli abusi. I termini del repository lo affermano chiaramente, e non è una formula di rito: gli output non riflettono le opinioni di chi ha caricato i file né di Qw​en / Ali​baba.

Come ottenere una baseline censurata per il confronto

Se il tuo lavoro riguarda la ricerca sui meccanismi di rifiuto o il red-teaming, vorrai quasi certamente avere affiancata la controparte censurata di questo modello — la stessa architettura senza la modifica — per misurare il delta. Questa build non censurata è progettata per essere esclusivamente locale: il repository è ad accesso controllato e non dispone di un deployment di inferenza ospitato, una scelta intenzionale affinché i payload sensibili non transitino mai attraverso un'API di terze parti.

Per la baseline ospitata, OrcaRouter instrada la linea Qwen al prezzo di listino del provider con margine zero — Qwen3.8-Flash a 0,15 $ per milione di token in input e 0,47 $ per milione in output, passati così come sono, con failover automatico e una chiave per oltre 200 modelli. Un cambio di prezzo del fornitore compare il giorno stesso. Se stai valutando se eseguire questa build, o quanto del tuo stack può sostenere, quello è il modo economico per confrontare la versione censurata senza un secondo contratto o un secondo codebase.

Inizia qui

Sommario della decisione. Ti servono: un account Hugging Face con i termini del repository accettati; un nodo di classe Hopper o più recente — il comando della scheda è pensato per 8 GPU, e circa 265 GB di VRAM GPU secondo le indicazioni della ricetta ufficiale per il checkpoint FP8 corrispondente; l'immagine vLLM day-0 e transformers 5.16+; e circa 186 GB di disco per i pesi.

Ordine di esecuzione: accetta i termini del repository → scarica i pesi → scarica l'immagine day-0 → servi con --enable-expert-parallel → verifica con una richiesta a :8000/v1/chat/completions → poi avvia le tue valutazioni. Se un caricamento fallisce con un errore che sembra di shape, controlla il flag prima di controllare il download.

E mantieni la cornice. Questo è uno strumento di ricerca, rilasciato a tale condizione. I suoi numeri sono le misurazioni indicative del fornitore sulla propria edizione. Il suo comportamento di sicurezza è il punto dell'esercizio, non un bug da aggirare. Servilo, misuralo e metti la tua moderazione tra esso e qualsiasi cosa umana.

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.