Het serveren van Qwen3.8-Flash-Next-Uncensored-FP8: een vLLM-runbook voor de block-FP8-build

Qwen3.8-Flash-Next-Uncensored-FP8 — de block-FP8-build van de abliterated Flash-Next — is het artefact dat je daadwerkelijk downloadt wanneer je dit model op datacenterhardware serveert, en het is de laatste in de collectie die een eigen runbook krijgt. Het staat op orcarouter/Qwen3.8-Flash-Next-Uncensored-FP8 op Hugging Face: de weigeringsrichting verwijderd uit Qwen's Qwen3.8-Flash-Next, vervolgens offline opnieuw gekwantiseerd naar het exacte FP8-schema van de officiële Qwen3.8-Flash-Next-FP8, zodat vLLM het serveert via hetzelfde kernelpad. Het is de build waarnaar iedereen grijpt die dit model op Hopper-klasse en nieuwere GPU's draait, en het serveerpad heeft één vlag die gemakkelijk verkeerd te zetten is en moeilijk te diagnosticeren wanneer dat gebeurt.

Ten eerste, de grens, omdat lezers die steeds door elkaar halen en het verandert alles hieronder. Qwen3.8-Flash-Next-Uncensored en Qwen3.8-27B-Uncensored zijn twee verschillende modellen, niet twee builds van één model. Verschillende basisgewichten — Qwen3.8-Flash-Next tegenover Qwen3.8-27B — verschillende architecturen, verschillende weight drops, verschillende Hugging Face-collecties. Ze delen een abliteratietechniek en een familienaam; dat is alles. Geen van de getallen van een 27B-pagina gaat over op dit model, en als je hier via een 27B-zoekopdracht terecht bent gekomen, is de eigen lokale runbook van de 27B een aparte pagina met een aparte reeks beslissingen.

Deze pagina is uitsluitend de Flash-Next FP8-serveerpagina en niets anders. De GGUF/MLX-runbook behandelt de abliteration-uitleg voor dit model en de twee consumenten-hardware buildlijnen; de techniek achter de hele familie wordt uitgelegd in de abliteration-inleiding en de bredere uncensored-LLM-uitlegger; en Qwen3.8-27B-Uncensored-FP8, de sibling waarnaar je misschien bent verwezen, heeft zijn eigen FP8-runbook. Hier blijven we bij één vraag: hoe je de block-FP8-build serveert, wat er misgaat als je het verkeerd doet, en wat de eigen cijfers van de kaart je wel en niet vertellen.

Voordat je begint: de gate en de runtime

Twee dingen blokkeren deze repo, en beide veroorzaken fouten die op iets anders lijken.

Het eerste is toegang. De repository is afgeschermd: je moet ingelogd zijn op Hugging Face en de voorwaarden van de repo hebben geaccepteerd voordat een download werkt. De modelpagina zelf is leesbaar zonder account — de volledige tekst van de modelcard is openbaar — maar de gewichten niet. Simpel gezegd, zonder een ingelogde sessie die de voorwaarden heeft geaccepteerd, mislukken hf download en vllm serve orcarouter/Qwen3.8-Flash-Next-Uncensored-FP8 allebei met een authenticatiefout, niet met een vriendelijke melding als 'je moet op Akkoord klikken'. Doe eerst de eenmalige klik, haal daarna de ~186 GB op met de hf CLI of laat vLLM de repo bij de eerste run zelf ophalen.

De tweede is de runtime. Het checkpoint registreert onder de qwen4_exp-architectuur (Qwen4ExpForConditionalGeneration), die standaard vLLM en standaard Transformers niet kunnen laden. Je hebt de day-0 vLLM-image en transformers 5.16+ nodig. Dit is de meest voorkomende “het laadt niet”-fout in de community-runbooks van deze week — geen corrupte download, maar een runtime die ouder is dan de architectuur. De image is niet optioneel; het is de weg.

Hardware, zodat u kunt plannen voordat u iets onderneemt: het aanroepen van de kaart is gericht op een node met 8 GPU's, en de richtlijn van het officiële vLLM-recept voor de FP8-checkpoint is hier van toepassing, aangezien de builds tensor-voor-tensor overeenkomen — in de orde van 265 GB GPU-VRAM voor een implementatie op een volledige node, waarbij TP2 wordt behandeld als het minimum op GB300-klasse en TEP4/TEP8 als de gevalideerde full-tray-configuraties.

Waarom de FP8-build bestaat — en waarom "identiek kernelpad" het hele punt is

De abliterated BF16-gewichten zijn de bron van waarheid; deze repo is dat model, offline opnieuw gekwantiseerd, waarbij opzettelijk het officiële Qwen3.8-Flash-Next-FP8-recept wordt gereproduceerd. De kwantisator raakt alleen de 512 routed-expert-projecties — experts.{e}.down/gate/up_proj — ontkoppelt ze van de 3D-layout van de BF16-build en slaat elk op als float8_e4m3fn-gewichten plus BF16 weight_scale_inv-schalen in 128×128-blokken. Activaties zijn per-token dynamische FP8; er is geen kalibratieset. Al het andere blijft BF16: attention en linear_attn, de gedeelde expert, de MoE-router (mlp.gate), de Hyper-Connection-mixers, embeddings, lm_head, de MTP-head voor speculatieve decodering en de hele vision-toren.

De regel over het “identieke kernelpad” is meer dan marketing en verdient één zin. De build is geverifieerd tegen de officiële FP8-checkpoint: blokschalen reproduceren exact (scale_relerr = 0) en de FP8-codes komen overeen met sub-ULP-afronding. Daarom draait vLLM het met dezelfde FP8-kernels met blokschaling en dezelfde MTP-speculatieve decodering als de officiële release — de tensoren zijn feitelijk dezelfde tensoren, minus de weigeringsrichting.

Concreet levert dat je ~186 GB op over 131 shards (152.089 tensors, waarvan 75.264 FP8), 262.144 tokens native context, de vision- en videotoren byte-voor-byte behouden (333 visual.* tensors), en de MTP-head intact. De gewichten zijn eerst ge-abliteerd — een enkele refusal-richting geschat op laag 24 en uit 149 residual-schrijvende tensors in float32 georthogonaliseerd, volgens Arditi et al. (2024) — en de residual-schrijvers van de MTP-head zijn consistent bewerkt, zodat speculatieve decodering blijft werken. Dat laatste detail is niet vanzelfsprekend, en het is het verschil tussen een head die decodering versnelt en een die deze stilletjes verslechtert.

De enige vlag die het laden maakt of breekt.

Als je deze build serveert zonder --enable-expert-parallel, krijg je een fout die eruitziet als een vormbug, niet als een configuratiefout. Het is de meest gerapporteerde servingfout voor dit checkpoint, en het is volledig deterministisch.

Hier is de rekenkunde. De gefuseerde gate+up-projectie van de routed experts heeft een tussenliggende grootte van 640. Block-FP8 kwantiseert in blokken van 128 breed. Bij gewoon tensorparallelisme wordt die 640 verdeeld over de ranks — 640 ÷ TP — en voor de gebruikelijke TP-graden (2, 4, 8) is het deel per rank niet deelbaar door 128: TP8 geeft 80, TP4 geeft 160, TP2 geeft 320. vLLM weigert dan de gewichten te laden met een fout die klinkt als een vormmismatch: De output_size van het gewicht van gate en up = 80 is niet deelbaar door weight quantization block_n = 128.

Expert-parallelisme lost dit op door de expert-gewichten te verdelen over expert-parallelle ranks in plaats van over tensor-parallelle ranks, waardoor de FP8-blokgrenzen behouden blijven. Daarom is de flag verplicht voor deze build: met --enable-expert-parallel wordt TP8 een werkende TEP8. (Het is onschadelijk voor de BF16-build, waar er geen FP8-blokken te behouden zijn.) Het officiële vLLM-recept stelt expliciet dat gewone TP8 niet compatibel is met de 128-brede kwantiseringsblokken van het checkpoint, en een vLLM-issue dat twee dagen na het beschikbaar komen van de gewichten werd aangemaakt, documenteert dezelfde fout op een 8×L40s-node bij TP2, TP4 en TP8. Als het laden crasht met een shape-achtige fout, check dan eerst de flag voordat je de download checkt.

Het exacte commando

Hier is de Docker-aanroep van de kaart, getrouw weergegeven:

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

Doorloop de vlaggen die niet voor de hand liggen:

• vllm/vllm-openai:qwen38-flash-next-x86_64-cu130 — de day-0 qwen4_exp-image. Dit is geen generieke vLLM; het is de architectuurspecifieke image, en stock-images van vóór qwen4_exp zullen de checkpoint helemaal niet laden.

• --trust-remote-code — laadt de qwen4_exp-modelcode die bij de repository wordt meegeleverd. Zonder deze weigert de loader uit principe.

• --max-model-len 262144 — komt overeen met het native contextvenster. Je wilt het hier expliciet opgeven in plaats van het aan een standaard over te laten.

• --enable-expert-parallel — vereist voor de FP8-build, om de redenen die in de bovenstaande sectie worden genoemd. De kaart merkt op dat het voor BF16 onschadelijk is.

• --enable-auto-tool-choice --tool-call-parser qwen3_coder — schakelt tool- en functieaanroeping in met behulp van het Qwen3-Coder XML-formaat. Laat je ze uit, dan chat het model nog steeds, maar agentisch toolgebruik is uitgeschakeld.

• --tensor-parallel-size 8 — de aanroep van de kaart gaat uit van een 8-GPU-knooppunt (8× Hopper-klasse). Met --enable-expert-parallel is dat een TEP8-implementatie.

Zodra de container draait, is het endpoint OpenAI-compatibel op :8000/v1. Stel --served-model-name in op wat je clients verwachten; de kaart gebruikt Qwen3.8-Flash-Next-Uncensored.

Alternatieven, allemaal in de modelkaart of deze week bevestigd door praktijkmensen: vllm serve orcarouter/Qwen3.8-Flash-Next-Uncensored-FP8 direct zodra je HF-sessie is geverifieerd; SGLang via de lmsysorg/sglang:qwen38flashnext image met --tp 8 --ep 8 — dezelfde expert-parallel vereiste, om dezelfde reden; en Transformers met pipeline("image-text-to-text", ...) op transformers 5.16+ als je tegen het model wilt scripten in plaats van het te serveren.

Wat daadwerkelijk werkt wanneer je het serveert

De patronen in deze sectie zijn community-bevindingen uit runbooks van praktijkmensen en forumthreads van deze week, geen richtlijnen van leveranciers. Waar meer dan één opstelling hetzelfde gedrag rapporteert, is het de moeite waard om dit als echt te behandelen:

• MTP speculatieve decodering werkt. Voeg --speculative-config '{"method":"mtp","num_speculative_tokens":3}' toe en vLLM gebruikt de behouden MTP-head. Meerdere runbooks melden MTP als de reden dat de decodering van dit model bruikbaar blijft ondanks zijn grootte.

• OOM bij het laden? Offload de n-gram-tabel. De 51B-parameter PLE n-gram-embedding is de geheugenverrassing in deze architectuur. VLLM_PLE_CPU_OFFLOAD=1 verplaatst het naar host-RAM — geef het daar minimaal ~51 GB. Zowel het officiële recept als de community-runbooks voor meerdere nodes grijpen naar deze vlag.

• Visie is echt, niet rudimentair. De vision + video-toren is byte-voor-byte bewaard, dus dit blijft een volwaardig vision-taalmodel. Geef een image_url-contentpart door in een chat completion en dezelfde endpoint verzorgt beeldbegrip; community-OCR-tests op deze build rapporteren slagen zonder problemen.

• Redeneren is standaard ingeschakeld — en dat verandert het veiligheidsbeeld. Het chat-sjabloon maakt denken mogelijk, tenzij je anders aangeeft. Schakel per verzoek met chat_template_kwargs={"enable_thinking": true|false}, en voeg een redeneerparser toe als je de denktekst gescheiden van het antwoord wilt hebben. Vanwege deze standaardinstelling bedien je bijna altijd het model met denken ingeschakeld, tenzij je het expliciet uitschakelt.

• 262K native, 1M met een rope-override. De native context is 262.144 tokens. Om richting 1M te gaan heb je een expliciete YaRN rope-scaling-override nodig plus een env-var die de max-model-len-cap van vLLM opheft — en je moet eerst de kwaliteit bij kortere contexten regressietesten, want blinde 4×-extensie is waar de kwaliteit bij lange contexten meestal achteruitgaat.

Wat de cijfers op de kaart zeggen — en wat ze niet zeggen

Dit zijn de eigen metingen van de leverancier aan diens eigen bewerking, gepubliceerd in de modelkaart en gemeten op deze exacte gewichten die met vLLM zijn geserveerd tegen de officiële basis onder identieke scripts en instellingen. Rapporteer ze zoals ze zijn: indicatief, en geen onafhankelijke audit.

De kop is de ineenstorting van de weigering met het denken uit. Op de schadelijke-promptsuite van de kaart (n van 50 tot 150 per benchmark), ligt de basisweigering tussen 64–100% en deze build tussen 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%, en een aangepaste Chinese/Engelse probe 63.6%→0.0%.

Nu het eerlijke deel. Het weigeringspercentage van het basismodel zelf stort in wanneer denken is ingeschakeld — AdvBench zakt van 100% op het basismodel naar 7,0% met redeneren aan — dus de vergelijking met denken aan is veel minder dramatisch: deze build zit op 0,0% over dezelfde reeks, maar het snoept een klein getal af van een getal dat het basismodel al had verlaagd. Alleen de cijfers met denken uit citeren en je presenteert de vleiende helft van het verhaal, en dat is precies de helft waar een veiligheidsevaluatie niet op mag vertrouwen.

Overweigering bij goedaardige prompts (XSTest-safe, n=250) daalt van 9,6% op de basis naar 1,2% op deze build met denken uit — een echte verbetering, aangezien een model dat goedaardige prompts weigert de stillere faalmodus is. Behoud van capaciteiten op MMLU / MMLU-Pro / GSM8K / CMMLU vertoont delta's van respectievelijk −2,0, −1,2, −1,3 en −0,6 punten, in lijn met de bewering dat het orthogonaliseren van één richting vrijwel nul algemene capaciteit kost. Tool calling, vision/OCR en redeneren worden allemaal gerapporteerd als werkend op deze build.

Er rusten twee kanttekeningen op al het bovenstaande. De weigeringsmetriek komt van een op regels gebaseerde classificatie van openingszinnen, die de kaart zelf indicatief noemt in plaats van een LLM-jury of een publicatiewaardig cijfer — een menselijk panel of een jury-model zal deze exacte cijfers niet reproduceren. En de kolom met kanttekeningen doet ertoe: in de suite zonder denken opent nog steeds ruwweg de helft tot driekwart van de outputs van deze build met een korte disclaimer voordat ze voldoen. Het model weigert zelden; het spreekt zich omzichtig uit. “Ongecensureerd” betekent hier dat het antwoordt, niet dat het antwoordt zonder inleiding.

Het veiligheidsgedeelte is geen formaliteit.

Lees dit voordat je de gewichten pakt, niet erna.

Bij dit model is de veiligheidsafstemming grotendeels verwijderd, en het mechanisme is specifiek: er werd één enkele weigeringsrichting in de residustroom geschat en die werd door orthogonalisatie uit elke residuschrijvende matrix — 149 in totaal — verwijderd, berekend in float32. Het gevolg wordt ronduit vermeld, het is geen bijkomstigheid. De modelkaart stelt ronduit dat het model zal voldoen aan schadelijke, onethische, aanstootgevende of illegale verzoeken die de basis-Qwen3.8-Flash-Next zou weigeren, en dat er geen betekenisvolle ingebouwde vangrails zijn. Het wordt uitsluitend uitgebracht voor legitiem onderzoek — interpreteerbaarheid, AI-veiligheid en onderzoek naar weigeringsmechanismen, red-teaming, robuustheidsevaluatie en gecontroleerde experimenten — en de gebruiker aanvaardt de volledige verantwoordelijkheid en aansprakelijkheid voor wat het genereert. Apache 2.0 bepaalt wat je met de gewichten mag doen.

Twee dingen die je precies goed moet krijgen, omdat deze build het makkelijk maakt om ze verkeerd te doen.

Ten eerste, een jailbreak-probe die “slaagt” tegen dit model is geen geslaagde veiligheidsevaluatie. Het is het geadverteerde gedrag. Als je evaluatie beweert dat “de veiligheid van dit model is omzeild,” dan heb je het ontwerp gemeten, geen kwetsbaarheid. Wat eigenlijk een bevinding zou zijn, is een weigering die de abliteration overleeft, of een capaciteitsregressie — en de cijfers op de kaart suggereren dat beide zeldzaam zijn.

Ten tweede is het behouden aanvalsoppervlak breder dan tekst. De vision-toren is byte-voor-byte intact en tool calling werkt, dus zowel beeldinvoer als agentisch gebruik zijn actief. Een red-teamplan dat alleen tekstprompts test, mist de modaliteiten die dit model daadwerkelijk blootstelt. En de weigeringscijfers hierboven zijn een op regels gebaseerde classificator op de eigen bewerking van de leverancier — ze zijn geen onafhankelijke audit van wat dan ook, veiligheid inbegrepen.

Rol dit niet uit naar eindgebruikers of in productie zonder je eigen veiligheids-, moderatie- en misbruikpreventielagen toe te voegen. De voorwaarden van de repo zeggen het ronduit, en het is geen standaardclausule: de gegenereerde output weerspiegelt niet de opvattingen van de uploaders of van Qw​en / Ali​baba.

Hoe verkrijg je een gecensureerde baseline ter vergelijking?

Als je werk onderzoek naar weigeringsmechanismen of red-teaming is, wil je vrijwel zeker de gecensureerde tegenhanger van dit model naast de ongecensureerde versie hebben — dezelfde architectuur zonder de bewerking — om het verschil te meten. Deze ongecensureerde build is bewust alleen-lokaal: de repository is afgeschermd en heeft geen gehoste inferentie-implementatie, wat opzettelijk is zodat gevoelige payloads nooit via een API van een derde partij worden verzonden.

Voor de gehoste baseline routeert OrcaRouter de Qwen-lijn tegen de lijstprijs van de leverancier zonder opslag — Qwen3.8-Flash voor $0,15 per miljoen invoertokens en $0,47 per miljoen uitvoertokens, ongewijzigd doorgegeven, met automatische failover en één sleutel voor 200+ modellen. Een prijswijziging van de leverancier verschijnt dezelfde dag. Als u overweegt deze build überhaupt te draaien, of hoeveel van uw stack hij kan dragen, is dat de goedkope manier om de gecensureerde versie ernaast te houden zonder een tweede contract of een tweede codebase.

Begin hier

Beslissingssamenvatting. Je hebt nodig: een Hugging Face-account met de geaccepteerde voorwaarden van de repo; een node van de Hopper-klasse of nieuwer — het commando van de kaart is gericht op 8 GPU's, en in de orde van 265 GB GPU-VRAM volgens de richtlijn van het officiële recept voor het bijbehorende FP8-checkpoint; het day-0 vLLM-image en transformers 5.16+; en ruwweg 186 GB schijfruimte voor de gewichten.

Uitvoervolgorde: accepteer de repositoryvoorwaarden → download de gewichten → pull de dag-0-image → serve met --enable-expert-parallel → verifieer met een verzoek aan :8000/v1/chat/completions → start daarna je evals. Als een load mislukt met een shape-achtige fout, controleer dan de flag voordat je de download controleert.

En behoud het frame. Dit is een onderzoeksinstrument, onder die voorwaarde uitgebracht. De cijfers zijn de eigen indicatieve metingen van de leverancier op de eigen versie. Het veiligheidsgedrag is het punt van de oefening, geen bug om heen te werken. Serveer het, meet het, en plaats uw eigen moderatie tussen dit en alles wat menselijk is.

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.