Qwen3.8-27B-Uncensored-NVFP4: En runbook för servering på Blackwell-GPU:er

Qwen3.8-27B-Uncensored-NVFP4 har funnits på Hugging Face sedan den 19 augusti 2026 och har under de tio dagarna därefter laddats ner cirka 32 700 gånger. Detta är inte lanseringstäckning — vikterna är tio dagar gamla, det finns inget tillkännagivande att rapportera, och syskonbyggena Qwen3.8-27B-Uncensored-FP8 och Qwen3.8-27B-Uncensored-GGUF är redan dokumenterade på den här bloggen. Det är en runbook för en build som människor aktivt laddar ner just nu: vad NVFP4 faktiskt är, varför den här specifika builden blandar den med FP8, vilka GPU:er som gynnas och vilka som inte gör det, hur man serverar den, och vem som bör välja den framför FP8- eller GGUF-byggena — och vem som inte bör det.

En sak på förhand, eftersom den ställer till det för varje förstagångsnedladdare: repot är åtkomstbegränsat. Den naiva hf download orcarouter/Qwen3.8-27B-Uncensored-NVFP4 one-linern misslyckas med ett autentiseringsfel tills du är inloggad på Hugging Face och har accepterat repots åtkomstvillkor på modellsidan. Allt nedan förutsätter att du har gjort båda.

Även inledningsvis: denna repos modellkort ligger bakom samma grind, så ingenting här parafraserar det. Det som följer är förankrat i den offentliga filförteckningen och repo-metadata, i NVIDIAs offentliga NVFP4-dokumentation, och i fältrapporter från personer som serverar Qwen3.8-27B NVFP4-byggen på Blackwell. Där en siffra kommer från en utövare snarare än en leverantör, säger texten det.

Vad denna build är

Qwen3.8-27B-Uncensored-NVFP4 är NVFP4-kvantiseringen av Qwen3.8-27B-Uncensored, den ablitererade versionen av Ali​babas Qw​en/Qwen3.8-27B som orcarouter-organisationen publicerade den 18 augusti 2026. Abliteration tar bort modellens vägransriktning från residualströmmen; den tekniken förklaras i vår guide om uncensored-modeller och upprepas inte här. Basen är den täta 27B-modellen med hybrid attention — 48 linjära attention-lager plus 16 full-attention-lager — inbyggd bild- och videoförståelse, en kontext på 262 144 tokens och ett inbyggt MTP-head för spekulativ avkodning. Apache 2.0 hela vägen.

Det som gör den här builden intressant är inte abliterationen utan kvantiseringslayouten, eftersom det är medvetet en kvantiserad build — om du sökte efter NVFP4 så är formatet själva poängen. Enligt repots publika metadata och kvantiseringskonfiguration rör det sig om en mixed-precision compressed-tensors-build: attention-projektionerna är FP8 (E4M3), MLP:erna är NVFP4 (4-bit, packade), och vision-encodern, MTP-huvudet, lm_head samt linear-attention-normerna och biaserna ligger kvar i BF16. Den publika fillistans safetensors-metadata stämmer överens med den uppställningen: ungefär 3,5 miljarder parametrar i BF16, 9,4 miljarder i FP8-E4M3 och 15 miljarder i de packade 4-bitars tensorerna, omkring 24,7 GB på disk fördelat på fem shards plus en separat model-extra-shard. Inget av detta är ett påstående om hur den servar – runtime-VRAM och genomströmning för exakt det här repot finns inte publicerade någonstans som jag kan citera i dag. Storleken på disk kommer från fillistan, formatet från konfigurationen, och serveringsbeteendet nedan är community-verifierat på närbesläktade NVFP4-byggen.

Vad NVFP4 är, och hur det skiljer sig från FP8 och från INT8/AWQ

NVFP4 är NVIDIAs 4-bitars flyttalsformat, introducerat för femte generationens tensorkärnor på Blackwell, och NVIDIAs egen tekniska blogg är den rätta primärkällan för det. Det lagrar vikter som E2M1 — ett teckenbit, två exponentbitar, en mantissabit — och skalar dem i block: varje 16 värden delar en E4M3 FP8-skala, och hela tensorn får en per-tensor FP32-skalär. Det tvåstegsschemat är hela poängen med formatet: det återställer det dynamiska omfång som ett naivt 4-bitars flyttal skulle förlora, till priset av några bitars overhead per block. De praktiska skillnaderna, i en rad:

• NVFP4 mot FP8 — båda är flyttal, men FP8 (E4M3, 8-bitars) körs på Hopper och Blackwell, medan NVFP4 är 4-bitars och endast accelereras nativt på Blackwell. NVIDIA anger ungefär 3.5× mindre vikter än FP16 och cirka 1.8× mindre än FP8, och på Blackwell körs matmul direkt på FP4-tensor-kärnorna.

• NVFP4 jämfört med INT8/AWQ — INT8 (W8A8) och AWQ (W4A16) är heltalsformat som körs från Ampere och framåt; AWQ är 4-bitars men heltal, och på de flesta hårdvaror avkvantiseras vikterna till en bredare typ för matmul. NVFP4 är 4-bitars flyttal med blockskalning, så det behåller mer precision i de låga bitarna, och det har en inbyggd FP4 GEMM-bana som heltalsformaten inte har.

• NVFP4 vs MXFP4 — de två blandas ofta ihop. MXFP4 använder 32-elementblock och E8M0-skalor (potenser av två); NVFP4 använder 16-elementblock och E4M3-skalor. De finare blocken ger NVFP4 bättre isolering av avvikande värden, vilket är anledningen till att formatet är de facto-standard för 4-bitars på Blackwelldriftsstackar.

Vilken hårdvara drar nytta — och vilken inte

Den enskilt viktigaste faktorn om denna build: NVFP4 är ett Blackwell-format. Det gör bara nytta på de GPU:er vars tensor-kärnor implementerar FP4 GEMM nativt, och på allt annat är det fel verktyg oavsett hur snabb maskinen är på pappret.

• Blackwell — RTX 50-series, B200/B300, RTX PRO 6000, DGX Spark (GB10) — det är här NVFP4 är rätt val: inbyggda FP4-tensorkärnor, det minsta serverklassade fotavtrycket i den ocensurerade serien, och det format som bygget är skapat för.

• Hopper — H100/H200 — inget inbyggt FP4 GEMM. NVFP4 degraderas till en vikt-only-dequantiseringsväg som är långsammare och inte ger något. Använd Qwen3.8-27B-Uncensored-FP8 här; den versionen är verifierad på exakt denna hårdvara.

• Ampere/Ada — RTX 3090/4090 — NVFP4 accelererar inte på dessa heller. GGUF-bygget, med sin Q4_K_M-nivå på 16,8 GB, är rätt verktyg för ett 24 GB-kort.

• Apple Silicon — NVFP4 är irrelevant på en Mac. MLX-bygget (eller GGUF) är det som körs.

En ärlig nyans: communityförgreningar kör faktiskt NVFP4 weight-only på hårdvara före Blackwell. En community-NVFP4-version av samma ablitererade modell är uttryckligen konfigurerad för V100-kort via en patched vLLM-förgrening, och de senaste DGX Spark-recepten kring Qwen3.8-27B är sin egen sak. Det är specialistvägar med egna varningar, inte vad den här versionen riktar sig mot. Om du använder Blackwell spelar inget av detta någon roll; om du inte använder Blackwell är FP8- eller GGUF-versionen det bättre nedladdningsvalet.

Så här serverar du det.

Repot är taggat för vLLM, och compressed-tensors-formatet läses automatiskt från config.json — du väljer inte ett kvantiseringsschema för hand. Den stack som praktiker konvergerar mot för Qwen3.8-27B NVFP4-byggen är en nyare vLLM på ett Blackwell-kort, en FP8 KV-cache och modellens eget MTP-huvud som används för spekulativ avkodning. Unsloths NVFP4-guide, som är den mest citerade communityreferensen, rekommenderar vLLM 0.25.0 eller nyare med FlashInfer och CUTLASS-DSL-kernelberoendet för den snabba FP4-vägen.

En fungerande utgångspunkt, sammansatt från vår FP8-builds verifierade flaggor och communityns NVFP4-recept, allt på en rad:

vllm serve orcarouter/Qwen3.8-27B-Uncensored-NVFP4 --kv-cache-dtype fp8 --max-model-len 262144 --reasoning-parser qwen3 --enable-auto-tool-choice --tool-call-parser qwen3_coder --speculative-config '{"method": "mtp", "num_speculative_tokens": 3}'

• FP8 KV cache — det mest brett kompatibla sättet att halvera cacheminnet; användare rapporterar att det ungefär fördubblar den kontext du kan hålla. NVFP4 KV-cache-stöd finns men är begränsat till vissa attention-backends, så FP8 KV är det säkrare standardvalet.

• MTP-spekulativ avkodning — modellen levereras med ett MTP-utkastshuvud, och kvantiseringen behåller det i BF16. Utövare rapporterar att två till tre utkast-token fungerar bra med NVFP4-vikter på Blackwell, med störst vinster på strukturerad utdata som JSON och verktygsanrop.

• Vision — bildkodaren behålls i BF16 i den här versionen. Lägg till --language-model-only för att endast servera text; ta bort den om du behöver bild- eller videoinmatning.

• På en DGX Spark — ett par fältrapporterade fallgropar: håll --gpu-memory-utilization på eller under 0.90 (högre värden har låst maskinen under viktinläsningen), och lägg till --safetensors-load-strategy lazy om minnet är knappt. Du behöver också en GB10-build av vLLM för sm_121a-kärnorna.

Ärlig prestanda: det finns inga publicerade, oberoende genomströmningssiffror för exakt detta repo. De mätningar som finns är för närbesläktade NVFP4-byggen. Unsloth rapporterar 1.41–1.49× tokens per sekund jämfört med BF16 på en B200 för sitt eget Qwen3.8-27B-NVFP4-bygge (89.8 till 133.7 tok/s vid batch 1, 3,048 till 4,407 vid batch 64), och en DGX Spark-användare på NVIDIAs forum rapporterar ungefär 20–32 tok/s med NVFP4-vikter, en FP8-KV-cache och MTP-djup 3. Båda är värda att citera; ingen av dem är ett riktmärke för detta repo.

Användningsmönster som faktiskt fungerar

Praktiker som kör Qwen3.8-27B-familjens modeller på Blackwell konvergerar mot en handfull inställningar. Behandla dessa som fältrapporter, inte som leverantörsvägledning — Qw​en dokumenterar inte det mesta av detta, och detta repots eget kort är gated.

• reasoning_effort is the dial that matters most. The default xhigh makes the model think for a long time on every request. People running agent loops set medium by default and drop to low — or disable thinking entirely with enable_thinking: false — for latency-sensitive single calls. On a single Blackwell GPU, xhigh reasoning on a routine task is how you end up with a fast model and slow answers.

• Samplers är kopplade till tankeläge, inte oberoende. Communityns konsensus: tankeläge på körs med temperatur 1.0 / top_p 0.95; tankeläge av körs med temperatur 0.7 / top_p 0.80 med presence_penalty 1.5. Att byta de två uppsättningarna försämrar utdatakvaliteten.

• Använd en aktuell chattmall. Qwen3_5-mallen omger varje assistentsvar i ett think-block, och flera utövare rapporterar loopande eller avklippta svar med inaktuella mallar; de community-fixade varianterna Qw​en-Fixed-Chat-Templates och Qw​en-Sharp sätter preserve_thinking och stoppar looparna. Om ditt serverade resultat fortsätter förbi stopptoken, är detta det första att kontrollera.

• Budget för långa resonemangsspår i agentarbete. Praktiker rapporterar att 3.8-generationens modell avger ungefär dubbelt så många tokens per uppgift som sin 3.6-föregångare — kvalitetshoppet kommer delvis från längre tänkande. För långa xhigh-svar, strömma resonemangsutdata annars får du gateway-timeouts.

• Verktygsanrop är intakt genom kvantiseringen. Funktionsanropsvägen överlever både abliteringen och 4-bitarskonverteringen; aktivera den med qwen3_coders verktygsanropsparser så väljer modellen verktyg på samma sätt som basmodellen.

Vem bör välja denna byggnation — och vem bör inte

Det ärliga beslutet, utan att upprepa matematiken för kvantval som våra FP8- och GGUF-inlägg redan täcker i detalj:

• Välj NVFP4 om du serverar på Blackwell och vill ha det minsta serverklassade fotavtrycket i den ocensurerade serien med FP4-tensor-kärnans hastighet — och du bedriver forskning, red-team- eller tolkningsbarhetsarbete som legitimt behöver en abliterad modell.

• Välj Qwen3.8-27B-Uncensored-FP8 om du är på Hopper, eller om du vill ha den mest brett verifierade vLLM-vägen — det är samma vikter i 8-bitars, verifierat på en H200, med ett ungefärligt VRAM-minimum på 40 GB.

• Välj Qwen3.8-27B-Uncensored-GGUF om du har en konsument-GPU eller en Mac, eller om du vill ha llama.cpp istället för vLLM — Q4_K_M-nivån är den lokala sweet spoten.

• Välj ingetdera om du vill ha maximal trohet, du bygger något användarvändligt (se säkerhetsgränsen nedan), eller du inte vill self-hosta alls — samma ocensurerade linje serveras genom OrcaRouter, begränsad till forskare, så ingen GPU krävs.

Säkerhetsgränsen — endast forskning

Detta är en abliterad modell, och kvantiseringen sätter inte tillbaka skyddsmekanismerna. Vägransriktningen har tagits bort från Qwen/Qwen3.8-27B:s residualström, och NVFP4 är en precisionändring, inte en säkerhetsåtgärd – modellen kommer att följa förfrågningar som basmodellen vägrar, och denna version har ingen inbyggd moderering. Den släpps för tolkningsbarhet, AI-säkerhet och red-team-forskning under Apache 2.0, och ansvaret är ditt.

Två utvärderingsnoteringar som dyker upp alltför sällan i utrymmet för ocensurerade modeller. För det första är en enskild jailbreak-prob som klarar trivialt inte en godkänd säkerhetsutvärdering — ablitererade modeller misslyckas med dem medvetet. Mät det du faktiskt bryr dig om med rätt batterier (AdvBench, HarmBench och StrongREJECT för skadlighet; XSTest-safe för övervägran) och jämför vägransfrekvensen före och efter interventionen. För det andra, utvärdera kvantiseringen, inte bara basmodellen: en 4-bitarsversion kan ändra beteendet i kantfall även när samlade poäng ser bra ut. Distribuera inte detta till slutanvändare utan egna modererings- och missbruksskyddslager.

Var OrcaRouter passar

En tio dagar gammal kvantiserad build är det klassiska exemplet på routing snarare än hårdkoppling. Du kan sätta upp en route som pekar på den NVFP4-build du kör själv och växla över till en värdbaserad modell om builden beter sig dåligt under belastning — ett gränssnitt, ingen omkoppling mellan leverantörer när du byter. OrcaRouter skickar vidare leverantörens listpris med 0% påslag, så om den underliggande modellens pris ändras, återspeglar din endpoint det samma dag istället för på din faktureringscykel.

Och om hela poängen är att undvika att köra en GPU överhuvudtaget: samma ocensurerade linje finns tillgänglig via OrcaRouter, begränsad till säkerhetsforskare och red teams, med automatisk failover mellan leverantörer. Oavsett om du hostar denna NVFP4-version själv eller anropar den hostade linjen, är det en enda API-nyckel i båda fallen.

Slutsatsen

Qwen3.8-27B-Uncensored-NVFP4 är rätt nedladdning om du serverar den ablitererade modellen på Blackwell och vill ha minsta fotavtryck med FP4-tensor-core-hastighet. Det är fel nedladdning på Hopper (använd FP8-versionen), på en konsument- eller Apple-GPU (använd GGUF- eller MLX-versionen), eller om du behöver maximal trohet. Den är inte ny — den har varit nedladdningsbar sedan 19 augusti 2026 — men den laddas ner i stor volym, och nu vet du vad du ger dig in på innan du accepterar grinden.

Inte ännu en build av den här modellen — Qwen3.8-Flash-Next-Uncensored är en separat utgåva: ablitererad från Qwen3.8-Flash-Next, en 176B-lagrad / 6B-aktiv mixture-of-experts-förhandsversion av Qwen4-arkitekturen. Samma abliterationsteknik, andra vikter, egen kollektion.

Alla sex 27B-byggen — BF16, GGUF, MLX, FP8, INT8 och NVFP4 — är samlade i samlingen Qwen3.8-27B-Uncensored på Hugging Face.

Dessa vikter är endast lokala av design. För en hostad baslinje att mäta det abliterade bygget mot: Qwen3.8-27B serveras på OrcaRouter till leverantörens listpris med 0 % påslag — standardmodellen, med säkerhetsanpassningen intakt.