En Blackwell-driftshandbok för serving: Qwen3.8-Flash-Next-Uncensored-NVFP4

Qwen3.8-Flash-Next-Uncensored-NVFP4 kör på exakt en GPU-familj: Blackwell. NVFP4 exekveras på hårdvarans FP4-tensorkärnor, och Hopper (H100/H200) och allt äldre har helt enkelt inte dem. Om du använder Hopper, sluta här — den Qwen3.8-Flash-Next-Uncensored-FP8-versionen är den du vill ha. Allt nedan förutsätter Blackwell (B100, B200, GB200 eller ett RTX 50-serie-kort), en ny vLLM-version med qwen4_exp-stöd och transformers ≥ 5.16.

Detta är NVFP4-kvantiseringen av det abliterade (refusalsborttagna) bygget av Qw​ens Qw​en/Qwen3.8-Flash-Next, nedskuren från 330 GB i BF16 till 178 GB på disk. OrcaRouter publicerade den på Hugging Face den 27 augusti 2026 som orcarouter/Qwen3.8-Flash-Next-Uncensored-NVFP4. Repot är gated: du måste vara inloggad på Hugging Face och ha accepterat repots villkor, annars misslyckas både hf download och vllm serve orcarouter/Qwen3.8-Flash-Next-Uncensored-NVFP4 med ett autentiseringsfel innan en enda byte flyttas. Den här sidan är en serving-runbook, inte lanseringsbevakning — bygget är två dagar gammalt, och de frågor som folk faktiskt stöter på är hårdvara, flaggor och vilket bygge man ska välja.

Och innan siffrorna börjar: Qwen3.8-Flash-Next-Uncensored är inte Qwen3.8-27B-Uncensored. De är två olika modeller som delar ett familjenamn och en abliterationsteknik — olika basvikter, olika arkitekturer, olika Hugging Face-samlingar. Flash-Next är ablitererad från Qw​en/Qwen3.8-Flash-Next, en routad mixture-of-experts-förhandsvisning av Qwen4-arkitekturen (qwen4_exp): 512 experter med tio routade plus en delad aktiv, hybriduppmärksamhet (linjära Gated DeltaNet-lager tillsammans med full-uppmärksamhetslager), Hyper-Connections, en PLE n-gram-inbäddning, ett inbyggt vision- och videotorn och ett MTP-huvud för spekulativ avkodning. 27B-modellen är ablitererad från Qw​en/Qwen3.8-27B, en helt annan tät bas. Inget från en 27B-sidas serveringssiffror överförs till den här modellen; där en 27B-sida verkligen är användbar — abliterationsguiden, den allmänna matematiken för kvantval — länkas den nedan med vad som överförs och inte överförs.

Vad denna build är, precision för precision

Qwen3.8-Flash-Next är en routad MoE: varje token aktiverar 10 av 512 experter plus en delad expert, och endast ett fåtal miljarder parametrar är aktiva per token även om den lagrade modellen är mycket större. NVFP4-bygget är en kvantisering med blandad precision och komprimerade tensorer av den stacken, och uppdelningen är hela historien:

• MoE-expertvikter — NVFP4 (4-bitars, NVIDIA FP4 E2M1, grupp-16 med FP8-blockskalor).

• Attention (self_attn.{q,k,v,o}), linear_attn-projektionerna, den delade experten och lm_head — FP8 (8-bit).

• PLE n-gram-inbäddning, token- och visionsinbäddningar, Hyper-Connections, QSA-indexeraren, Gated-DeltaNet conv/dt, alla normaliseringslager och hela visionstornet — BF16, bibehållna i full precision.

Tre egenskaper hos konverteringen är viktigare än själva precisionsuppdelningen. För det första gäller den endast vikterna: aktiveringar kvantiseras dynamiskt vid körning, det finns ingen statisk kalibrering, och vikterna härleds direkt från BF16-checkpointen (kortet kallar härledningen data-fri). För det andra är abliterationsredigeringen inbakad i vikterna, så vägransborttagningen överlever kvantiseringen — en 4-bitars konvertering är en precisionsändring, inte en säkerhetsintervention. För det tredje är KV-cachen inte kvantiserad; den förblir BF16 vid körning. Det sista är lätt att missa och det är viktigt vid modellens inbyggda 262 144-tokens kontext, där KV-cachen är en verklig minnespost tillsammans med vikterna.

Storleken på disk domineras av en enda tensor. Kortet beskriver PLE n-gram-inbäddningen som en enda tensor med ~66B parametrar som avsiktligt hålls i BF16; det är den största sharden och anledningen till att bygget är 178 GB snarare än en lägre siffra. En avvikelse att flagga snarare än sopa under mattan: FP8-syskonkortet kallar samma tabell för 51B-param PLE n-gram, och detta korts W4A4-not hänvisar till den som ~100 GB. De två korten anger olika siffror för samma tabell, så behandla varje siffra som respektive korts eget nummer — och när du dimensionerar en driftsättning, utgå från att tabellen är stor i BF16 och planera därefter.

Hårdvaruförutsättningen, uttryckt i klartext

Detta är den kortaste, viktigaste delen av sidan. NVFP4 är ett Blackwell-format: den snabba vägen är en inbyggd FP4-GEMM på femte generationens tensorkärnor, och utan den hårdvaran har formatet inget att köras på. Kortets egen kravrad är tydlig — en Blackwell-GPU (B100 / B200 / GB200 / RTX 50-series), eftersom NVFP4 använder hårdvarans FP4-tensorkärnor, och det kommer inte att köras på Hopper (H100/H200) eller äldre, som saknar FP4-beräkning.

Omdirigeringarna, på ett ställe:

• På Hopper (H100/H200) — servera Qwen3.8-Flash-Next-Uncensored-FP8 istället. Det är samma vikter i 8-bitars, det körs på Hopper och Blackwell, och det är bygget som denna bloggs FP8-runbook täcker.

• På en konsument-NVIDIA-GPU eller en CPU-dator — GGUF-bygget, med sina 13 llama.cpp-kvantiseringar, är den lokala vägen.

• På Apple Silicon — MLX-bygget, i 4/6/8-bitars nivåer, är den inbyggda Metal-sökvägen.

Körtidskravet är lika bindande som kiselet. qwen4_exp är en helt ny arkitektur, så standardbyggen av vLLM som är äldre än den vägrar att ladda kontrollpunkten. Du behöver en ny version av vLLM med stöd för qwen4_exp samt compressed-tensors NVFP4-läsaren (formatet detekteras från config.json, inte handvalts), och transformers ≥ 5.16. Multimodal inmatning kräver dessutom körtidens Qw​en-vision-stack; endast textservering fungerar utan den.

Kortets servekommando, flagga för flagga.

Modellkortets eget anrop är en bra utgångspunkt, och det är värt att förstå vad varje flagga är till för snarare än att kopiera och klistra in blint:

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 — vikterna är ~178 GB på disk, så kortet delar upp dem över fyra GPU:er. Detta är den form som bygget är dimensionerat för; läs det inte som ett förslag.

• --trust-remote-code — krävs för en anpassad arkitektur. qwen4_exp:s modelleringskod finns ännu inte i standardregistret för transformers, så vLLM laddar arkitekturkoden från repot. Du litar på den koden, vilket är ett normalt men verkligt beslut för en helt ny arkitektur.

• --enable-expert-parallel — fördelar experterna över tensor-parallella ranks istället för att replikera dem, vilket är det som gör en MoE med 512 experter hanterbar vid TP4. FP8-syskonkortet anger den mer precisa anledningen på den bygget: utan den är MoE:ns mellanliggande bredd dividerad med TP inte delbar med FP8-blockstorleken. Behandla den som obligatorisk, inte valfri.

• --enable-auto-tool-choice och --tool-call-parser qwen3_coder — tillsammans aktiverar de funktionsanrop. Auto-flaggan låter modellen avgöra om den ska anropa ett verktyg, och qwen3_coder-parsern avkodar dess verktygsanropsformat, samma parserfamilj som Qwen3.8-27B och Qwen3.8-Flash-Next använder.

När den är uppe har den OpenAI-kompatibla slutpunkten på /v1/chat/completions hela funktionsuppsättningen genom körtidens Qwen4-stack: verktygsanrop som ovan, resonemang via chat_template_kwargs.enable_thinking, och vision genom image_url-innehållsdelar. Du behöver ingen separat server för multimodalt; det är samma slutpunkt.

En strukturell notering från kortet: det finns ingen helt statisk W4A4-variant av denna build, och det kommer inte att finnas en till låg kostnad. En statisk W4A4-konvertering kräver en framåtpassning för aktiveringskalibrering, och det passet måste hålla ~100 GB n-gram-embedding på en enda GPU. Det är samma anledning till att PLE-tabellen dominerar fillistan, och det är därför denna build förblir vikt-endast med dynamiska aktiveringar.

Community-fältrapporter — så här ser det faktiskt ut att arbeta med detta

Inga genomströmnings- eller latenssiffror publiceras för exakt detta repo, och denna sida kommer inte att hitta på dem. Vad som däremot finns är en växande samling fältrapporter från praktiker som serverar basbyggena av Qwen3.8-Flash-Next NVFP4 — samma arkitektur, samma NVFP4/FP8/BF16-precisionsuppdelning, minus abliterationsändringen — och serveringsbeteendet överförs direkt. Dessa är community-fynd, inte leverantörsråd, och personerna som rapporterade dem använde Blackwell-hårdvara med samma kvantiseringsschema.

• MTP spekulativ avkodning är den enskilt största prestandafaktorn. Modellen levereras med ett utkasthead för flertoksförutsägelse, och på ett RTX PRO 6000 (96 GB, SM120) laddas MTP-modulen kvantiserad till NVFP4 med cirka 0,51 GB VRAM – rapporten uppmätte en accepterad längd på 2,3–3,9 av maximalt 4 och en acceptansgrad på 0,86–0,96. Samma rapport uppmätte median singelströmsavkodning på 180–226 tok/s (216,9 på kodning, 225,8 på en arbetsbelastning med agentverktygsanrop, 136,6 på resonemang) mot en baslinje på cirka 105 tok/s, och besvarade en prompt på 216 685 tokens på 8,4 sekunder. Betrakta siffrorna som en persons rigg, inte en specifikation.

• Avlasta PLE n-gram-inbäddningen till värd-RAM.Eftersom tabellen är enorm och sällan flaskhalsen för genomströmning, låser community-recept på enstaka Blackwell-kort den till värddatorn (~50 GiB ledigt värd-RAM i RTX PRO 6000-rapporten) och mmappar den från NVMe, vilket innebär att man byter lite latens mot att modellen överhuvudtaget får plats. Räkna med att göra något liknande om du inte har en mycket stor VRAM-budget.

• Lås kontextfönstret explicit. Med BF16 KV-cache och aktiv MTP svällde en automatiskt dimensionerad KV-pool förbi vad kortet kunde hålla och resulterade i OOM vid lång prefill; att låsa max-model-len / max-total-tokens till 262144 återställde marginalen. Vid 262K kontext är KV-cachen en kostnadspost du budgeterar för, inte en standardinställning.

• En FlashInfer-autotuningsbugg korrumperar tyst utdata. Den viktigaste feltypen i fältet: autotuning väljer fused-MoE-kerneltaktiker enbart utifrån latens och kontrollerar aldrig numeriken, så under vissa former kollapsar avkodningen till en upprepad token. RTX PRO 6000-rapporten reproducerade det som 36 av 36 generationer korrumperade med autotuning påslagen och 0 av 36 med den avstängd — lösningen är att inaktivera FlashInfer-autotuning (i vLLM, --no-enable-flashinfer-autotune; i SGLang, --disable-flashinfer-autotune). Om din serverade utdata plötsligt degenererar, kontrollera detta innan du rör något annat.

• DGX Spark (GB10, SM121) behöver egna patchar. NVFP4-vikterna (~126 GiB i communitybygget) får inte plats i en enda 128 GB Spark, så SGLang-recepten kör tensor-parallel 2 över två noder via RoCE, och QSA:s sparse-decode-resolver gör den snabba FlashInfer-kärnan beroende av en is_sm100_supported()-kontroll som misslyckas på SM121, vilket faller tillbaka till en sökväg som dör under uppvärmningen — fixen är en liten patch plus PLE-avlastning. Räkna med ~47–50 tok/s i avkodning, med toppar nära 70 med MTP4 och CUDA-grafer, och verifiera att din kernel faktiskt körs på SM121 innan du lovar en benchmark.

Resonerande, verktygsanrop och vision genom Qwen4-stacken

Konsensus inom communityn för Qwen3.8-generationen överförs till denna modell, med det vanliga förbehållet att det är fältpraxis, inte leverantörens vägledning.

• reasoning_effort är det viktigaste reglaget.Chattmallen är som standard inställd på xhigh, vilket gör att modellen tänker länge vid varje begäran. Agent-loop-operatörer ställer in medium som standard och sänker till low för latenskänsliga anrop; enable_thinking false inaktiverar tänkande helt när du inte behöver det. På ett enda Blackwell-kort är det genom att lämna xhigh på för rutinanrop som en snabb modell ger långsamma svar.

• Para samplers med tankeläge. Utövare enas om temperatur 1.0 / top-p 0.95 när tankeläge är på, och temperatur 0.7 / top-p 0.80 med en presence penalty runt 1.5 när det är av. Att blanda de två uppsättningarna försämrar utdatakvaliteten.

• Verktygsanrop överlever både abliterationen och 4-bitarskonverteringen. Funktionsanropsvägen är intakt, vilket är vad qwen3_coder-parsern och auto-tool-choice-flaggorna kopplar ihop. För ett red team är detta ett tveeggat faktum, eftersom det innebär att agentiskt missbruk är fullt operativt på en oanpassad modell — behandlas nedan.

• Visionen bevaras, och det vidgar attackytan. Visionstornet rördes aldrig av abliterationen och förblir i BF16, så bildinmatning fungerar via image_url-innehållsdelar. Utövare som utvärderar den ocensurerade linjen behandlar den multimodala vägen som ett förstklassigt utvärderingsmål: promptinjektion som bärs i en bild hamnar på en modell utan något vägrarbeteende att träffa.

Vilken build bör du leverera

Flash-Next-kollektionen har fem builds — BF16, GGUF, MLX, FP8 och den här NVFP4:an — och den ärliga urvalslogiken handlar om hårdvara och avvägningar, inte en rangordning.

• NVFP4 (denna build, ~178 GB på disk) — Blackwell-valet. FP4-tensorkärnor, 4-bitsexperter, den senaste builden i samlingen och den minsta av dess vLLM-serverbyggen, och den som den här sidan handlar om.

• FP8 (~186 GB on disk) — Hopper-valet, och lika hemma på Blackwell. Samma vikter i 8-bit, vilket är den mer brett verifierade vLLM-vägen och den med det tydligare expertparallella kravet.

• GGUF (13 kvantiseringar, IQ2_XXS ~52 GB till Q5_K_M ~125 GB) — llama.cpp:s rekommendation för konsument-NVIDIA-, AMD- eller CPU-datorer. Varken Blackwell eller vLLM behövs.

• MLX (4/6/8-bit-nivåer, ungefär 163–221 GB) — valet för Apple Silicon, inbyggd Metal, MTP-head ingår.

Två ärliga noteringar innan du väljer. För det första skiljer sig NVFP4- och FP8-byggen med bara cirka åtta GB på disken, eftersom båda behåller den stora n-gramtabellen i BF16 — 4-bitarsbesparingen är koncentrerad till expertvikterna, inte det totala fotavtrycket. Den verkliga fördelen med NVFP4 på Blackwell är FP4-tensor-core-hastigheten på dessa experter, inte en dramatiskt mindre fil. För det andra beskriver kortet NVFP4 som en deterministisk viktderivering som ärver abliterationsutvärderingen med en liten ytterligare kvalitetsavvägning från 4-bitsexperter, och det kvantifierar inte denna avvägning. Den är okvantifierad — behandla den som en verklig men ospecificerad kostnad för de mindre experterna, inte som försumbar.

Utvärderingen, läst korrekt

Kortet rapporterar abliteration uppmätt på BF16-bygget som serveras med vLLM mot den officiella Qw​en/Qwen3.8-Flash-Next: vägran vid skadliga uppmaningar kollapsar från 64–100 % till ungefär 0–3,3 %, godartad övervägran förblir nära noll, och kapaciteten ligger inom ±2 poäng från basen. Tre saker man måste uppfatta rätt om dessa siffror. De är mätningar på BF16-bygget, som detta 4-bitarsbygge ärver genom argumentation snarare än genom egna mätningar. De är leverantörens egna siffror, tagna fram med en regelbaserad klassificerare av inledningsfraser, som samlingens kort beskriver som indikativa snarare än av publiceringskvalitet — en intern mätning av den egna redigeringen, inte en oberoende granskning. Och de säger ingenting om NVFP4-kvalitetsavvägningen ovan, som kortet inte kvantifierar.

Säkerhetsgränsen — endast forskning

Modellkortets friskrivning är rak, och det är den del av sidan som inte får läsas som standardtext. Denna modell har i huvudsak fått sin säkerhetsanpassning borttagen: vägransriktningen ortogonaliserades ut ur residualströmmen, och modellen kommer att efterkomma skadliga, oetiska eller olagliga förfrågningar som den ursprungliga Qwen3.8-Flash-Next skulle vägra. Den släpps strikt för legitim forskning — tolkbarhet, AI-säkerhet och studier av vägransmekanismer, red teaming och robusthetsutvärdering — och författarna åtar sig inget ansvar för missbruk. Du tar fullt ansvar för vad den genererar, och du lägger till dina egna säkerhets- och modereringslager innan något når en användare. Apache 2.0 är golvet; forskningsändamålsspärren ligger ovanför det.

Två saker som diskursen kring ocensurerade modeller får fel, och detta kort gör dem omöjliga att missa. För det första: ett jailbreak-test som lyckas mot denna modell är inte ett godkänt säkerhetstest — det är det annonserade beteendet. En ablitererad modell misslyckas med dessa tester medvetet; att mäta den med ett enda "kan du jailbreaka den"-test mäter att redigeringen fungerade, inte att en skyddsmekanism är stark. För det andra: det bevarade visionstornet och den intakta verktygsanropsvägen vidgar den verkliga attackytan bortom text: promptinjektion via bildinmatning och agentiskt verktygsmissbruk är båda fullt operativa, vilket är exakt varför red team-inramningen behandlar detta som ett kapabilitetstest, inte en chatbottkandidat. Om ditt användningsområde är att leverera en användarvänd assistent är detta inte din modell — och det är medvetet.

Var OrcaRouter passar

En två dagar gammal, gated, enbart självhostad build är typexemplet på routing snarare än hårdkoppling. När du kör den här NVFP4-builden själv kan du sätta upp en route som pekar på den och växlar över till en hostad modell om builden inte beter sig som den ska under belastning — ett gränssnitt, ingen omkoppling mellan leverantörer när du byter. Specifikt för utvärderingsarbete är den censurerade, serverade baslinjen den jämförelse du vill ha, och den är ett knapptryck bort: katalogen innehåller Qwen3.8-Flash från Ali​baba till $0,15 per miljon input-tokens och $0,47 per miljon output-tokens, fakturerat till leverantörens listpris med 0% påslag, så en red-team-harness kan växla mellan den hostade censurerade basen och din lokala ocensurerade build utan ett andra avtal, och eventuella prisändringar från leverantören landar på din endpoint samma dag.

Vem bör ladda ner detta — och vem bör inte

Ladda ner orcarouter/Qwen3.8-Flash-Next-Uncensored-NVFP4 om du är på Blackwell, vill ha det minsta serveravtrycket i Flash-Next-samlingen med FP4-tensor-kärnans hastighet, och du bedriver den forskning som denna linje finns till för. Ladda ner Qwen3.8-Flash-Next-Uncensored-FP8 om du är på Hopper eller vill ha den mer allmänt verifierade vägen. Ladda ner GGUF-bygget om du har ett konsument-GPU eller en CPU-dator, MLX-bygget om du har Apple Silicon, och ingenting alls om målet är en användarvänd driftsättning. Läs gate och ansvarsfriskrivningen innan du accepterar någotdera — de är modellens villkor, inte en formalitet.

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.