Qwen3.8-Flash-Next-Uncensored-NVFP4: Een Blackwell Serving-draaiboek

Qwen3.8-Flash-Next-Uncensored-NVFP4 draait op precies één GPU-familie: Blackwell. NVFP4 draait op hardware-FP4-tensorcores, en Hopper (H100/H200) en alles ouder heeft ze simpelweg niet. Als je op Hopper zit, stop hier — de Qwen3.8-Flash-Next-Uncensored-FP8 build is degene die je wilt. Alles hieronder gaat uit van Blackwell (B100, B200, GB200, of een RTX 50-serie kaart), een recente vLLM-build met qwen4_exp-ondersteuning, en transformers ≥ 5.16.

Dit is de NVFP4-kwantificatie van de abliterated (zonder weigeringen) build van Qw​en's Qw​en/Qwen3.8-Flash-Next, teruggebracht van 330 GB in BF16 naar 178 GB op schijf. OrcaRouter publiceerde het op Hugging Face op 27 augustus 2026 als orcarouter/Qwen3.8-Flash-Next-Uncensored-NVFP4. De repo is gated: je moet ingelogd zijn op Hugging Face en de voorwaarden van de repo hebben geaccepteerd, anders hf download en vllm serve orcarouter/Qwen3.8-Flash-Next-Uncensored-NVFP4 mislukken beide met een authenticatiefout voordat er één byte wordt overgedragen. Deze pagina is een serving-runbook, geen launch-verslaggeving — de build is twee dagen oud, en de vragen waar mensen daadwerkelijk tegenaan lopen zijn hardware, flags, en welke build je moet kiezen.

En voordat de cijfers beginnen: Qwen3.8-Flash-Next-Uncensored is niet Qwen3.8-27B-Uncensored. Het zijn twee verschillende modellen die een familienaam en een abliteratietechniek delen — verschillende basisgewichten, verschillende architecturen, verschillende Hugging Face-collecties. Flash-Next is een abliteratie van Qw​en/Qwen3.8-Flash-Next, een routed mixture-of-experts-preview van de Qwen4-architectuur (qwen4_exp): 512 experts, waarvan er tien routed en één shared actief zijn, hybride aandacht (Gated DeltaNet-lineaire lagen naast full-attention-lagen), Hyper-Connections, een PLE n-gram-embedding, een native vision- en videotoren, en een MTP speculative-decoding-head. De 27B is een abliteratie van Qw​en/Qwen3.8-27B, een totaal ander dense basismodel. Niets van de servingcijfers van een 27B-pagina is van toepassing op dit model; waar een 27B-pagina echt nuttig is — de inleiding over abliteratie, de algemene wiskunde achter het kiezen van quants — is die hieronder gelinkt, met wat wel en niet overdraagbaar is.

Wat deze build is, precisie voor precisie.

Qwen3.8-Flash-Next is een gerouteerde MoE: elk token activeert 10 van de 512 experts plus één gedeelde expert, en slechts een paar miljard parameters zijn live per token, ook al is het opgeslagen model veel groter. De NVFP4-build is een mixed-precision compressed-tensors quant van die stack, en de splitsing is het hele verhaal:

• MoE-expertgewichten — NVFP4 (4-bits, NVIDIA FP4 E2M1, groep-16 met FP8-blokschalen).

• Attention (self_attn.{q,k,v,o}), de linear_attn-projecties, de gedeelde expert en lm_head — FP8 (8-bit).

• PLE n-gram embedding, token- en vision-embeddings, Hyper-Connections, de QSA-indexer, Gated-DeltaNet conv/dt, alle normen, en de volledige vision-toren — BF16, op volledige precisie gehouden.

Drie eigenschappen van de conversie zijn belangrijker dan de precisieverdeling zelf. Ten eerste betreft het uitsluitend gewichten: activaties worden tijdens runtime dynamisch gekwantiseerd, er is geen statische kalibratie, en de gewichten worden rechtstreeks afgeleid van de BF16-checkpoint (de kaart noemt de afleiding data-vrij). Ten tweede is de abliteratie-bewerking in de gewichten verwerkt, zodat het verwijderen van weigeringen de kwantisatie overleeft — een 4-bit-conversie is een precisiewijziging, geen veiligheidsinterventie. Ten derde wordt de KV-cache niet gekwantiseerd; die blijft tijdens runtime BF16. Dat laatste is gemakkelijk te missen en het is van belang bij de native context van 262.144 tokens van het model, waar de KV-cache een echte geheugenpost is naast de gewichten.

De omvang op schijf wordt gedomineerd door één tensor. De kaart beschrijft het PLE n-gram-embedding als een enkele tensor met ~66B parameters die volgens ontwerp in BF16 wordt gehouden; het is de grootste shard en de reden dat de build 178 GB is in plaats van een lager getal. Eén discrepantie om aan te kaarten in plaats van te verdoezelen: de zusterkaart met FP8 noemt dezelfde tabel het PLE n-gram met 51B parameters, en de W4A4-notitie van deze kaart verwijst ernaar als ~100 GB. De twee kaarten geven verschillende cijfers voor dezelfde tabel; behandel dus elk getal als dat van de eigen kaart — en wanneer je een deployment dimensionert, ga er dan van uit dat de tabel in BF16 groot is en plan eromheen.

De hardwarevoorwaarde, uitgeschreven

Dit is het kortste, belangrijkste onderdeel van de pagina. NVFP4 is een Blackwell-formaat: het snelle pad is een native FP4 GEMM op de vijfde generatie tensor-kernen, en zonder die hardware heeft het formaat niets om op te draaien. De eigen vereistenregel van de kaart is expliciet — een Blackwell GPU (B100 / B200 / GB200 / RTX 50-serie), omdat NVFP4 de hardware-FP4-tensorkernen gebruikt, en het zal niet draaien op Hopper (H100/H200) of ouder, die FP4-rekenkracht missen.

De doorverwijzingen, op één plek:

• Op Hopper (H100/H200) — serveer in plaats daarvan Qwen3.8-Flash-Next-Uncensored-FP8. Het zijn dezelfde gewichten op 8-bit, het draait op Hopper en Blackwell, en het is de build die het FP8-runbook van deze blog behandelt.

• Op een NVIDIA-GPU voor consumenten of een CPU-box — de GGUF-build, met zijn 13 llama.cpp-quants, is de lokale oplossing.

• Op Apple Silicon — de MLX-build, in 4/6/8-bit niveaus, is het native Metal-pad.

De runtime-eis is net zo bindend als het silicium. qwen4_exp is een gloednieuwe architectuur, dus standaard vLLM-builds van vóór qwen4_exp weigeren het checkpoint te laden. Je hebt een recente vLLM nodig met ondersteuning voor qwen4_exp, plus de compressed-tensors NVFP4-reader (het formaat wordt gedetecteerd via config.json, niet handmatig geselecteerd), en transformers ≥ 5.16. Multimodale invoer vereist bovendien de Qw​en vision-stack van de runtime; text-only serving werkt zonder deze stack.

Het serve-commando van de kaart, flag voor flag

De aanroep van de modelkaart zelf is een goed startpunt, en het is de moeite waard om te begrijpen waar elke vlag voor dient in plaats van blindelings te kopiëren en te plakken:

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 — de gewichten zijn ~178 GB op schijf, dus de kaart verdeelt ze over vier GPU's. Dit is de vorm waar de build op is afgestemd; zie het niet als een suggestie.

• --trust-remote-code — vereist voor een aangepaste architectuur. De modelcode van qwen4_exp staat nog niet in de standaard transformers-registry, dus vLLM laadt de architectuurcode uit de repository. Je vertrouwt die code, wat een normale maar reële beslissing is voor een gloednieuwe architectuur.

• --enable-expert-parallel — verdeelt de experts over de tensor-parallel-ranks in plaats van ze te repliceren, wat een MoE met 512 experts haalbaar maakt op TP4. De FP8-zusterkaart vermeldt de preciezere reden voor die build: zonder deze optie is de MoE-tussenbreedte gedeeld door TP niet deelbaar door de FP8-blokgrootte. Behandel het als vereist, niet als optioneel.

• --enable-auto-tool-choice en --tool-call-parser qwen3_coder — samen schakelen ze functieaanroep in. De auto-vlag laat het model beslissen of het een tool aanroept, en de qwen3_coder-parser decodeert het toolaanroepformaat, dezelfde parserfamilie die Qwen3.8-27B en Qwen3.8-Flash-Next gebruiken.

Zodra deze actief is, biedt het OpenAI-compatibele endpoint op /v1/chat/completions de volledige functionaliteit via de Qwen4-stack van de runtime: tool calling zoals hierboven, redeneren via chat_template_kwargs.enable_thinking, en vision via image_url-contentonderdelen. U hebt geen aparte server nodig voor multimodaal; het is hetzelfde endpoint.

Een structurele opmerking uit de kaart: er is geen volledig statische W4A4-variant van deze build, en die zal er niet goedkoop komen. Een statische W4A4-conversie vereist een forward pass voor activatie-calibratie, en die pass moet de ~100 GB n-gram-embedding op één enkele GPU vasthouden. Dat is dezelfde reden dat de PLE-tabel het bestandsoverzicht domineert, en het is de reden waarom deze build weight-only blijft met dynamische activaties.

Veldrapporten uit de gemeenschap — wat het in de praktijk inhoudt om dit te bedienen

Er zijn geen doorvoer- of latentiecijfers gepubliceerd voor deze exacte repo, en deze pagina zal ze niet verzinnen. Wat er wel is, is een groeiende verzameling veldrapporten van beoefenaars die de basis-Qwen3.8-Flash-Next NVFP4-builds bedienen — dezelfde architectuur, dezelfde NVFP4/FP8/BF16-precisieverdeling, minus de abliteration-bewerking — en het serving-gedrag draagt direct over. Dit zijn community-bevindingen, geen leveranciersrichtlijnen, en de mensen die ze rapporteerden werkten op Blackwell-hardware met hetzelfde kwantiseringsschema.

• MTP-speculatieve decodering is de grootste prestatiehefboom. Het model wordt geleverd met een draftkop voor multi-tokenvoorspelling, en op één RTX PRO 6000 (96 GB, SM120) neemt de MTP-module, gekwantificeerd naar NVFP4, ongeveer 0,51 GB VRAM in — het rapport mat een acceptlengte van 2,3–3,9 van maximaal 4 en een acceptatiegraad van 0,86–0,96. Hetzelfde rapport mat een mediane single-stream-decode van 180–226 tok/s (216,9 bij coderen, 225,8 bij een agent-tool-call-workload, 136,6 bij redeneren) tegenover een baseline van ongeveer 105 tok/s, en beantwoordde een prompt van 216.685 tokens in 8,4 seconden. Beschouw de cijfers als de opstelling van één persoon, niet als een specificatie.

• Verplaats de PLE n-gram-embedding naar het host-RAM. Omdat de tabel enorm is en zelden het doorvoerknelpunt vormt, zetten community-recepten op enkele Blackwell-kaarten het vast in het hostgeheugen (~50 GiB aan vrij host-RAM in het RTX PRO 6000-rapport) en mappen het vanaf NVMe, waarbij wat latentie wordt ingeruild om het model überhaupt te kunnen laden. Verwacht dat je iets dergelijks moet doen, tenzij je een zeer ruim VRAM-budget hebt.

• Zet het contextvenster expliciet vast.Met BF16 KV-cache en MTP actief zwol een automatisch gedimensioneerde KV-pool op tot voorbij de kaartcapaciteit en leidde tot OOM-fouten tijdens lange prefill; het vastzetten van max-model-len / max-total-tokens op 262144 herstelde de headroom. Bij een context van 262K is de KV-cache een post die je begroot, geen standaardwaarde.

• Een FlashInfer-autotune-bug beschadigt stilletjes de uitvoer. De belangrijkste faalmodus in de praktijk: autotune selecteert fused-MoE-kerneltactieken alleen op basis van latentie en controleert nooit de numerieke resultaten, dus bij bepaalde vormen ontaardt decode tot een herhaald token. Het RTX PRO 6000-rapport reproduceerde dit als 36 van de 36 gegenereerde uitvoer beschadigd met autotune aan, en 0 van de 36 met autotune uit — de oplossing is om FlashInfer-autotune uit te schakelen (in vLLM: --no-enable-flashinfer-autotune; in SGLang: --disable-flashinfer-autotune). Als de uitvoer die je serveert plotseling degenereert, controleer dit dan voordat je iets anders aanraakt.

• DGX Spark (GB10, SM121) heeft zijn eigen patches nodig. De NVFP4-gewichten (~126 GiB in de community-build) passen niet in één 128 GB Spark, dus de SGLang-recipes draaien tensor-parallel 2 over twee nodes via RoCE, en de QSA sparse-decode-resolver zet de snelle FlashInfer-kernel achter een is_sm100_supported()-controle die op SM121 faalt, met terugval naar een pad dat tijdens de warmup crasht — de oplossing is een kleine patch plus PLE-offload. Verwacht een decode-snelheid van ~47–50 tok/s, die met MTP4 en CUDA-graphs rond 70 piekt, en controleer of je kernel daadwerkelijk op SM121 draait voordat je een benchmark belooft.

Redeneren, toolaanroeping en beeldherkenning via de Qwen4-stack

De community-consensus over de Qwen3.8-generatie geldt ook voor dit model, met de gebruikelijke kanttekening dat het veldpraktijk is, geen richtlijn van de leverancier.

• reasoning_effort is de knop die het meest ertoe doet.De chat-template staat standaard op xhigh, waardoor het model bij elke aanvraag lang nadenkt. Agent-loop-operators zetten standaard medium en zakken naar low voor latentiegevoelige oproepen; enable_thinking false schakelt redeneren volledig uit wanneer je het niet nodig hebt. Op een enkele Blackwell-kaart zorgt het aan laten staan van xhigh bij routinematige oproepen ervoor dat een snel model langzame antwoorden levert.

• Koppel samplers aan de denkmodus. Beoefenaars komen uit op temperatuur 1.0 / top-p 0.95 wanneer denken aan staat, en temperatuur 0.7 / top-p 0.80 met een presence-straf rond 1.5 wanneer het uit staat. Het mengen van de twee sets verslechtert de outputkwaliteit.

• Tool calling overleeft zowel de abliteratie als de 4-bit-conversie. Het function-calling-pad is intact, en daar sluiten de qwen3_coder-parser en de auto-tool-choice-vlaggen op aan. Voor een red team is dit een tweesnijdend feit, aangezien het betekent dat agentisch misbruik volledig operationeel is op een niet-afgestemd model — hieronder behandeld.

• Het zicht blijft behouden, en dat vergroot het aanvalsoppervlak. De vision tower is nooit aangeraakt door de abliteration en blijft in BF16, dus beeldinvoer werkt via image_url content parts. Beoefenaars die de ongecensureerde lijn evalueren, behandelen het multimodale pad als een eersteklas evaluatiedoel: promptinjectie in een afbeelding komt terecht op een model waar geen weigeringsgedrag te raken valt.

Welke build moet je serveren

De Flash-Next-collectie heeft vijf builds — BF16, GGUF, MLX, FP8 en deze NVFP4-versie — en de eerlijke keuzelogica draait om hardware en afwegingen, niet om een rangschikking.

• NVFP4 (deze build, ~178 GB op schijf) — de Blackwell-keuze. FP4-tensorcores, 4-bits experts, de nieuwste build in de collectie en de kleinste van zijn vLLM-serverbuilds, en degene waar deze pagina over gaat.

• FP8 (~186 GB op schijf) — de Hopper-keuze, en evenzeer thuis op Blackwell. Dezelfde gewichten op 8-bit, wat het breder geverifieerde vLLM-pad is en degene met de duidelijkere expert-parallelvereiste.

• GGUF (13 quants, IQ2_XXS ~52 GB tot Q5_K_M ~125 GB) — de llama.cpp-keuze voor consumenten-NVIDIA, AMD of CPU-systemen. Geen Blackwell nodig, geen vLLM nodig.

• MLX (4/6/8-bit niveaus, ongeveer 163–221 GB) — de keuze voor Apple Silicon, native Metal, MTP-kop inbegrepen.

Twee eerlijke opmerkingen voordat je kiest. Ten eerste: de NVFP4- en FP8-builds verschillen op de schijf slechts ongeveer acht GB, omdat beide de grote n-gram-tabel in BF16 houden — de 4-bits besparing zit vooral in de expertgewichten, niet in de totale voetafdruk. Het echte voordeel van NVFP4 op Blackwell is de FP4-tensor-core-snelheid op die experts, niet een dramatisch kleiner bestand. Ten tweede: de kaart beschrijft NVFP4 als een deterministische gewichtsafleiding die de abliteration-evaluatie erft met een kleine extra kwaliteitsafweging door de 4-bits experts, en kwantificeert die afweging niet. Die is niet gekwantificeerd — behandel het als een reële maar niet-gespecificeerde kost van de kleinere experts, niet als verwaarloosbaar.

De evaluatie, correct gelezen

De kaart rapporteert abliteration gemeten op de BF16-build die met vLLM wordt geserveerd, vergeleken met de officiële Qw​en/Qwen3.8-Flash-Next: weigering van schadelijke prompts daalt van 64–100% naar ongeveer 0–3,3%, overmatige weigering van goedaardige prompts blijft dicht bij nul, en capaciteiten blijven binnen ±2 punten van de basis. Drie dingen die je over die cijfers goed moet begrijpen. Het zijn metingen aan de BF16-build, die door deze 4-bit-build worden overgenomen op basis van argumentatie in plaats van eraan te zijn gemeten. Het zijn de eigen cijfers van de leverancier, geproduceerd met een op regels gebaseerde classificator voor openingszinnen die de kaarten uit de collectie beschrijven als indicatief in plaats van publicatiewaardig — een interne meting van de eigen bewerking, geen onafhankelijke audit. En ze zeggen niets over de hierboven genoemde NVFP4-kwaliteitsafweging, die de kaart niet kwantificeert.

De veiligheidsgrens — alleen voor onderzoek

De disclaimer van de kaart is bot, en het is het deel van deze pagina dat niet als standaardformulering mag lezen. Bij dit model is de veiligheidsalignment grotendeels verwijderd: de weigeringsrichting is georthogonaliseerd uit de residual stream, en het model zal voldoen aan schadelijke, onethische of illegale verzoeken die de originele Qwen3.8-Flash-Next zou weigeren. Het wordt uitsluitend uitgebracht voor legitiem onderzoek — interpreteerbaarheid, AI-veiligheid en onderzoek naar weigeringsmechanismen, red-teaming en robuustheidsevaluatie — en de auteurs aanvaarden geen aansprakelijkheid voor misbruik. U aanvaardt de volledige verantwoordelijkheid voor wat het genereert, en u voegt uw eigen veiligheids- en moderatielagen toe voordat iets een gebruiker bereikt. Apache 2.0 is de ondergrens; de onderzoeksdoelpoort zit daarboven.

Het discours over ongecensureerde modellen heeft het op twee punten mis, en deze kaart maakt ze onmogelijk te missen. Ten eerste is een jailbreak-probe die tegen dit model slaagt geen geslaagde veiligheidsevaluatie — het is het geadverteerde gedrag. Een abliterated model laat die probes met opzet falen; het meten met één enkele test van '{{KEEP}}can you jailbreak it{{/KEEP}}' meet dat de bewerking werkte, niet dat een guardrail sterk is. Ten tweede vergroten de behouden vision-toren en het intacte tool-calling-pad het echte aanvalsoppervlak voorbij tekst: prompt-injectie via beeldinvoer en agentisch toolmisbruik zijn beide volledig operationeel, wat precies de reden is waarom de red-team-framing dit behandelt als een capaciteitsprobe, niet als een chatbotkandidaat. Als jouw use case het uitbrengen van een gebruikersgerichte assistent is, dan is dit niet jouw model, en dat is met opzet.

Waar OrcaRouter past

Een twee dagen oude, gated, alleen zelf-gehoste build is het schoolvoorbeeld voor routing in plaats van hardwiring. Wanneer je deze NVFP4-build zelf draait, kun je een route opzetten die ernaar wijst en overgaat op een gehost model als de build zich onder belasting misdraagt — één interface, geen herbedrading tussen providers wanneer je wisselt. Voor specifiek evaluatiewerk is de gecensureerde, geserveerde baseline de vergelijking die je wilt, en die is slechts één toetsdruk verwijderd: de catalogus bevat Ali​baba's Qwen3.8-Flash voor $0,15 per miljoen input en $0,47 per miljoen output, doorberekend tegen de lijstprijs van de provider met 0% opslag, zodat een red-team-harnas kan schakelen tussen de gehoste gecensureerde basis en jouw lokale ongecensureerde build zonder een tweede contract, en elke prijswijziging van de provider belandt dezelfde dag op jouw endpoint.

Wie zou dit moeten downloaden — en wie niet

Download orcarouter/Qwen3.8-Flash-Next-Uncensored-NVFP4 als je op Blackwell zit, je de kleinste servervoetafdruk in de Flash-Next-collectie wilt met FP4-tensor-core-snelheid, en je het onderzoekswerk doet waarvoor deze lijn bestaat. Download Qwen3.8-Flash-Next-Uncensored-FP8 als je op Hopper zit of je het breder gevalideerde pad wilt. Download de GGUF-build als je op een consumenten-gpu of een cpu-machine zit, de MLX-build als je op Apple Silicon zit, en helemaal niets als het doel een gebruikersgerichte implementatie is. Lees de gate en de disclaimer voordat je een van beide accepteert — ze zijn de voorwaarden van het model, geen formaliteit.

Alle vijf Flash-Next builds — BF16, GGUF, MLX, FP8 en NVFP4 — zijn verzameld in de Qwen3.8-Flash-Next-Uncensored collectie op Hugging Face.

Een ander model, geen andere build van dit model: Qwen3.8-27B-Uncensored is ge-ablitereerd van een andere basis en heeft zijn eigen collectie en zijn eigen runbooks.

Deze gewichten zijn bewust alleen lokaal beschikbaar. Voor een gehoste basislijn om de abliterated build tegen af te meten wordt Qwen3.8-Flash op OrcaRouter aangeboden tegen de lijstprijs van de provider met 0% opslag — het standaardmodel, met intacte safety alignment.