Att servera Qwen3.8-Flash-Next-Uncensored-FP8: en vLLM-runbook för block-FP8-bygget

Qwen3.8-Flash-Next-Uncensored-FP8 — block-FP8-bygget av den abliterade Flash-Next — är den artefakt du faktiskt laddar ner när du serverar den här modellen på datacenter-hårdvara, och den är den sista i samlingen som får en egen runbook. Den ligger på orcarouter/Qwen3.8-Flash-Next-Uncensored-FP8 på Hugging Face: vägransriktningen borttagen från Qw​en:s Qwen3.8-Flash-Next, sedan omkvantiserad offline till exakt samma FP8-schema som den officiella Qwen3.8-Flash-Next-FP8, så att vLLM serverar den på samma kernel-path. Det är den version som alla som kör den här modellen på Hopper-klass och nyare GPU:er kommer att använda, och serveringsvägen har en flagga som är lätt att ställa in fel och svår att diagnostisera när den är fel.

Först, gränsen, eftersom läsare suddar ut den och det ändrar allt nedanför. Qwen3.8-Flash-Next-Uncensored och Qwen3.8-27B-Uncensored är två olika modeller, inte två byggen av en modell. Olika basvikter — Qwen3.8-Flash-Next mot Qwen3.8-27B — olika arkitekturer, olika viktborttagningar, olika Hugging Face-samlingar. De delar en abliterationsteknik och ett familjenamn; det är allt. Inga av en 27B-sidas siffror överförs till den här modellen, och om du kom hit från en 27B-sökning, så är 27B:ns egen lokala runbook en separat sida med en separat uppsättning beslut.

Den här sidan är Flash-Next FP8:s serveringssida och inget annat. GGUF/MLX-runboken täcker abliterationsförklaringen för den här modellen och de två bygglinjerna för konsumenthårdvara; tekniken bakom hela familjen förklaras i abliterationsprimern och den bredare uncensored-LLM-förklararen; och Qwen3.8-27B-Uncensored-FP8, syskonmodellen du kanske blivit hänvisad till, har sin egen FP8-runbook. Här håller vi oss till en fråga: hur du serverar block-FP8-bygget, vad som går sönder när du gör det fel, och vad kortets egna siffror gör och inte gör för att berätta för dig.

Innan du börjar: grinden och körningsmiljön

Två saker är grindar för detta repo, och båda ger upphov till fel som ser ut som något annat.

Det första är åtkomst. Repositoriet är spärrat: du måste vara inloggad på Hugging Face och ha accepterat repots användarvillkor innan någon nedladdning fungerar. Själva modellsidan är läsbar utan konto — hela korttexten är offentlig — men vikterna är det inte. Helt enkelt, utan en inloggad session som har accepterat villkoren, misslyckas både hf download och vllm serve orcarouter/Qwen3.8-Flash-Next-Uncensored-FP8 med ett autentiseringsfel, inte ett vänligt “du måste klicka på Agree.” Gör det engångsklicket först, och hämta sedan de ~186 GB med hf CLI eller låt vLLM lösa repot vid första körningen.

Det andra är runtime. Checkpointen registreras under arkitekturen qwen4_exp (Qwen4ExpForConditionalGeneration), som standard-vLLM och standard-Transformers inte kan läsa in. Du behöver day-0-vLLM-avbildningen och transformers 5.16+. Detta är det enskilt vanligaste ”det läses inte in”-felet i communityns runbooks den här veckan — inte en korrupt nedladdning, utan en runtime som är äldre än arkitekturen. Avbildningen är inte valfri; den är vägen.

Hardware, så du kan planera innan du drar ut något: kortets anrop riktar sig mot en nod med 8 GPU:er, och vägledningen från det officiella vLLM-receptet för FP8-kontrollpunkten gäller här eftersom byggena matchar tensor för tensor — i storleksordningen 265 GB GPU-VRAM för en fullnodsdistribution, med TP2 behandlad som minimum på GB300-klass och TEP4/TEP8 som de validerade full-tray-konfigurationerna.

Varför FP8-bygget finns — och varför ”identisk kernel-sökväg” är hela poängen.

De abliterade BF16-vikterna är den slutgiltiga källan; detta repo är den modellen omkvantiserad offline, medvetet efterliknande det officiella Qwen3.8-Flash-Next-FP8-receptet. Kvantiseraren rör endast de 512 routeade expert-projektionerna — experts.{e}.down/gate/up_proj — och frigör dem från BF16-byggets 3D-layout, för att lagra var och en som float8_e4m3fn-vikter plus BF16-vikt_skala_inv-skalor i 128×128-block. Aktiveringarna är per-token dynamisk FP8; det finns ingen kalibreringsuppsättning. Allt annat förblir BF16: attention och linear_attn, den delade experten, MoE-routern (mlp.gate), Hyper-Connection-mixrarna, embeddings, lm_head, MTP:s spekulativa avkodningshuvud och hela vision-tornet.

Raden om ”identisk kernel-sökväg” är mer än marknadsföring, och den förtjänar en mening. Bygget verifierades mot den officiella FP8-checkpointen: blockskalor återges exakt (scale_relerr = 0) och FP8-koderna matchar med sub-ULP-avrundning. Det är därför vLLM kör den med samma blockskalade FP8-kernlar och samma MTP-spekulativa avkodning som den officiella releasen — tensorerna är i praktiken samma tensorer, minus vägransriktningen.

Konkret ger det dig ~186 GB över 131 shards (152 089 tensors, varav 75 264 i FP8), 262 144 tokens i nativ kontext, vision- och videotornet bevarat byte-för-byte (333 visual.*-tensorer) och MTP-huvudet intakt. Vikterna abliterades först — en enskild refusal-riktning skattad vid lager 24 och ortogonaliserad bort från 149 residualskrivande tensorer i float32, enligt Arditi et al. (2024) — och MTP-huvudets residualskrivare redigerades konsekvent, så spekulativ avkodning fortsätter att fungera. Den sistnämnda detaljen är inte självklar, och det är skillnaden mellan ett huvud som påskyndar avkodning och ett som tyst försämrar den.

Den enda flaggan som avgör inläsningen.

Servera denna build utan --enable-expert-parallel och du får ett fel som ser ut som ett formfel, inte ett konfigurationsmisstag. Det är det mest rapporterade serveringsfelet för den här kontrollpunkten, och det är helt deterministiskt.

Här är aritmetiken. De routade experternas fusionerade gate+up-projektion har en mellanstorlek på 640. Block-FP8 kvantiserar i 128 breda block. Med vanlig tensor-parallellism delas 640 över ranks — 640 ÷ TP — och för de vanliga TP-graderna (2, 4, 8) är per-rank-slicen inte delbar med 128: TP8 ger 80, TP4 ger 160, TP2 ger 320. vLLM vägrar då att ladda vikterna med ett fel som ser ut som en formfelmatchning: The output_size of gate's and up's weight = 80 is not divisible by weight quantization block_n = 128.

Expertparallellism löser det genom att dela upp expertvikterna över expertparallella ranker i stället för tensorparallella ranker, vilket bevarar FP8-blockgränserna. Det är därför flaggan är obligatorisk för den här builden: med `--enable-expert-parallel` blir TP8 en fungerande TEP8. (Den är ofarlig för BF16-builden, där det inte finns några FP8-block att bevara.) Det officiella vLLM-receptet är explicit med att vanlig TP8 är inkompatibel med checkpointens 128-breda kvantiseringsblock, och en vLLM-issue som lämnades in två dagar efter att vikterna publicerades dokumenterar samma fel på en 8×L40s-nod vid TP2, TP4 och TP8. Om en inläsning kraschar med ett shape-liknande fel, kontrollera flaggan innan du kontrollerar nedladdningen.

Det exakta kommandot.

Här är kortets docker-anrop, troget återgivet:

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

Arbeta igenom de flaggor som inte är uppenbara:

• vllm/vllm-openai:qwen38-flash-next-x86_64-cu130 — day-0-avbildningen för qwen4_exp. Detta är inte en generisk vLLM; det är den arkitekturspecifika avbildningen, och standardavbildningar som är äldre än qwen4_exp kan inte alls läsa in checkpointen.

• --trust-remote-code — laddar qwen4_exp-modellkoden som medföljer repot. Utan den vägrar laddaren av princip.

• --max-model-len 262144 — matchar det inbyggda kontextfönstret. Du vill ha det explicit här istället för att lämna det åt ett standardvärde.

• --enable-expert-parallel — krävs för FP8-bygget, av skälen i avsnittet ovan. Kortet noterar att det är ofarligt för BF16.

• --enable-auto-tool-choice --tool-call-parser qwen3_coder — aktiverar verktygs- och funktionsanrop med Qwen3-Coder XML-formatet. Om de är avstängda kan modellen fortfarande chatta, men agentisk verktygsanvändning är avstängd.

• --tensor-parallel-size 8 — kortets anrop förutsätter en nod med 8 GPU:er (8× Hopper-klass). Med --enable-expert-parallel är det en TEP8-distribution.

När containern är igång är slutpunkten OpenAI-kompatibel på :8000/v1. Ställ in --served-model-name på vad dina klienter förväntar sig; kortet använder Qwen3.8-Flash-Next-Uncensored.

Alternativ, allt i kortet eller bekräftat av praktiker denna vecka: vllm serve orcarouter/Qwen3.8-Flash-Next-Uncensored-FP8 direkt när din HF-session är autentiserad; SGLang via lmsysorgs/sglang:qwen38flashnext-image med --tp 8 --ep 8 — samma krav på expert-parallellism, samma anledning; och Transformers med pipeline("image-text-to-text", ...) på transformers 5.16+ om du vill skripta mot modellen snarare än att servera den.

Vad som faktiskt fungerar när du serverar det.

Mönstren i detta avsnitt är community-rön från praktikers runbooks och forumtrådar den här veckan, inte vägledning från leverantörer. Där mer än en installation rapporterar samma beteende, är det värt att betrakta som verkligt:

• MTP spekulativ avkodning fungerar. Lägg till --speculative-config '{"method":"mtp","num_speculative_tokens":3}' så använder vLLM det bevarade MTP-huvudet. Flera runbooks rapporterar att MTP är anledningen till att denna modells avkodning förblir användbar trots dess storlek.

• OOM vid inläsning? Avlasta n-gram-tabellen. 51B-parametrars PLE n-gram-inbäddning är minnesöverraskningen i denna arkitektur. VLLM_PLE_CPU_OFFLOAD=1 flyttar den till värd-RAM — ge den minst ~51 GB där. Det officiella receptet och communityns multi-nod-runbooks använder båda denna flagga.

• Vision är verklig, inte rudimentär. Vision- och videotornet bevaras byte för byte, så detta förblir en fullvärdig visionspråkmodell. Skicka en image_url-innehållsdel i en chattkomplettering och samma endpoint levererar bildförståelse; communityns OCR-tester på denna build rapporterar godkända resultat.

• Resonemang är på som standard — och det förändrar säkerhetsbilden. Chattmallen aktiverar tänkande om du inte anger något annat. Växla per förfrågan med chat_template_kwargs={"enable_thinking": true|false}, och lägg till en resonemangsparser om du vill att tanketexten ska separeras från svaret. På grund av denna standard serverar du nästan alltid modellen med tänkande på, om du inte uttryckligen stänger av det.

• 262K nativ, 1M med en rope override.Nativ kontext är 262 144 token. För att nå 1M krävs en explicit YaRN rope-scaling override plus en miljövariabel som lyfter vLLM:s max-model-len-tak – och du bör regressionstesta kortare kontextkvalitet först, eftersom blind 4×-utökning är där långkontextkvaliteten vanligtvis försämras.

Vad kortets siffror säger — och vad de inte säger

Dessa är leverantörens egna mätningar på dess egen redigering, publicerade i modellkortet och mätta på dessa exakta vikter som serveras med vLLM mot den officiella basen under identiska skript och inställningar. Rapportera dem som vad de är: indikativa, och inte en oberoende granskning.

Rubriken är vägranskollapsen med tänkandet avstängt. På kortets skadliga prompt-svit (n från 50 till 150 per riktmärke) ligger basvägran på 64–100% och denna version på 0–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%, och en anpassad kinesisk/engelsk sond 63.6%→0.0%.

Nu den ärliga hälften. Basmodellens egen vägransfrekvens kollapsar när tänkande är aktiverat — AdvBench sjunker från 100 % på basen till 7,0 % med resonerande aktiverat — så jämförelsen med tänkande aktiverat är mycket mindre dramatisk: den här versionen ligger på 0,0 % över samma svit, men den drar av ett litet tal från ett tal som basen redan reducerat. Citera bara siffrorna med tänkande avstängt och du presenterar den smickrande hälften av historien, och det är precis den hälften en säkerhetsutvärdering inte får förlita sig på.

Övervägran på benigna prompts (XSTest-safe, n=250) sjunker från 9,6 % på basmodellen till 1,2 % på denna version med tanke avstängt – en verklig förbättring, eftersom en modell som vägrar benigna prompts är det tystare feltillståndet. Bevarande av förmåga på MMLU / MMLU-Pro / GSM8K / CMMLU visar deltan på −2,0, −1,2, −1,3 respektive −0,6 poäng, vilket överensstämmer med påståendet att ortogonalisering av en riktning kostar nästan ingen generell förmåga. Verktygsanrop, vision/OCR och resonerande rapporteras alla fungera på denna version.

Två förbehåll vilar över allt ovanstående. Avvisningsmåttet kommer från en regelbaserad klassificerare av öppningsfraser, som kortet själv kallar indikativt snarare än en LLM-domare eller en publiceringsklar siffra — en mänsklig panel eller en domarmodell kommer inte att återge dessa exakta siffror. Och förbehållskolumnen spelar roll: i testsviten med tänkande avstängt inleds fortfarande ungefär hälften till tre fjärdedelar av denna bygges utdata med en kort friskrivning innan de följer instruktionen. Modellen vägrar sällan; den garderar sig. ”Okänsurerad” här betyder att den svarar, inte att den svarar utan inledning.

Säkerhetssektionen är inte en formalitet.

Läs detta innan du drar vikterna, inte efter.

{{1}}Denna modell har väsentligen fått sin säkerhetsanpassning borttagen, och mekanismen är specifik:{{/1}} {{2}}En enskild refuseringsriktning uppskattades i residualströmmen och ortogonaliserades bort från varje residualskrivande matris — 149 stycken — beräknade i float32.{{/2}} {{3}}Konsekvensen är utannonserad, inte oavsiktlig. Modellkortet säger rakt ut att modellen kommer att följa skadliga, oetiska, stötande eller olagliga förfrågningar som basmodellen Qwen3.8-Flash-Next skulle vägra, och att den inte har några meningsfulla inbyggda skyddsräcken.{{/3}} {{4}}Den släpps strikt för legitim forskning — tolkningsbarhet, AI-säkerhet och studier av refuseringsmekanismer, red-teaming, robusthetsutvärdering och kontrollerade experiment — och användaren tar på sig fullt ansvar och skadeståndsansvar för vad den genererar.{{/4}} {{5}}Apache 2.0 styr vad du får göra med vikterna.{{/5}}

Två saker att få exakt rätt, eftersom den här builden gör dem lätta att få fel.

För det första, en jailbreak-probe som ”lyckas” mot den här modellen är inte en godkänd säkerhetsutvärdering. Det är det annonserade beteendet. Om din utvärdering påstår att ”den här modellens säkerhet kringgicks,” har du mätt designen, inte en sårbarhet. Vad som faktiskt skulle vara ett fynd är en vägran som överlever abliterationen, eller en kapacitetsförsämring — och kortets siffror tyder på att båda är sällsynta.

För det andra är den bevarade angreppsytan bredare än text. Visionstornet är intakt byte-för-byte och verktygsanrop fungerar, så både bildinmatning och agentlik användning är aktiva. En red-team-plan som bara testar textprompter missar de modaliteter som den här modellen faktiskt exponerar. Och siffrorna för nekanden ovan kommer från en regelbaserad klassificerare i leverantörens egen ändring – de är inte en oberoende granskning av någonting, inte heller av säkerheten.

Distribuera inte detta till slutanvändare eller till produktion utan att lägga till egna lager för säkerhet, moderering och förebyggande av missbruk. Repots villkor säger det tydligt, och det är inte standardtext: utdata återspeglar inte uppladdarnas eller Qw​en / Ali​baba:s åsikter.

Hur man får en censurerad baslinje för jämförelse

Om ditt arbete är forskning om vägransmekanismer eller red-teaming vill du nästan säkert ha den censurerade motsvarigheten till den här modellen sida vid sida — samma arkitektur utan redigeringen — för att mäta skillnaden. Den här ocensurerade versionen är avsiktligt endast lokal: repo:t är åtkomstbegränsat och har ingen värdbaserad inferensdistribution, vilket är avsiktligt så att känsliga nyttolaster aldrig passerar via ett tredjeparts-API.

För den hanterade baslinjen dirigerar OrcaRouter Qw​en-linjen till leverantörens listpris utan påslag — Qwen3.8-Flash till 0,15 USD per miljon inmatningstokens och 0,47 USD per miljon utmatning, vidarebefordrat som det är, med automatisk failover och en nyckel för 200+ modeller. En prisändring från leverantören visas samma dag. Om du väger för och nackdelar med att köra den här builden överhuvudtaget, eller hur mycket av din stack den kan bära, är det det billiga sättet att hålla den censurerade versionen mot den utan ett andra avtal eller en andra kodbas.

Börja här

Beslutsammanfattning. Du behöver: ett Hugging Face-konto med accepterade villkor för repot; en nod av Hopper-klass eller nyare – kortets kommando riktar sig till 8 GPU:er, och i storleksordningen 265 GB GPU-VRAM enligt den officiella receptets vägledning för den matchande FP8-checkpointen; day-0-vLLM-avbildningen och transformers 5.16+; och ungefär 186 GB diskutrymme för vikterna.

Körordning: acceptera repovillkoren → ladda ner vikterna → hämta dag-0-avbilden → serva med --enable-expert-parallel → verifiera med en förfrågan mot :8000/v1/chat/completions → påbörja sedan dina utvärderingar. Om en inläsning misslyckas med ett formliknande fel, kontrollera flaggan innan du kontrollerar nedladdningen.

Och behåll ramen. Detta är ett forskningsinstrument, släppt på det villkoret. Dess siffror är leverantörens egna indikativa mätningar på sin egen version. Dess säkerhetsbeteende är själva poängen med övningen, inte en bugg att kringgå. Servera det, mät det, och lägg din egen moderering mellan det och allt mänskligt.

Alla fem Flash-Next-versioner — BF16, GGUF, MLX, FP8 och NVFP4 — finns samlade i samlingen Qwen3.8-Flash-Next-Uncensored på Hugging Face.

En annan modell, inte en annan build av den här: Qwen3.8-27B-Uncensored är ablitererad från en annan bas och har sin egen samling och sina egna runbooks.

Dessa vikter är avsiktligt endast lokala. För en hostad baslinje att mäta den abliterade versionen mot är det Qwen3.8-Flash som serveras på OrcaRouter till leverantörens listpris med 0 % påslag — standardmodellen med säkerhetsanpassningen intakt.