Qwen3.8-27B-Uncensored-NVFP4: A Serving Runbook for Blackwell GPUs

Qwen3.8-27B-Uncensored-NVFP4 has been on Hugging Face since August 19, 2026, and in the ten days since it has been pulled roughly 32,700 times. This is not launch coverage — the weights are ten days old, there is no announcement to report, and the sibling builds Qwen3.8-27B-Uncensored-FP8 and Qwen3.8-27B-Uncensored-GGUF are already documented on this blog. It is a runbook for a build people are actively downloading right now: what NVFP4 actually is, why this specific build mixes it with FP8, which GPUs benefit and which do not, how to serve it, and who should pick it over the FP8 or GGUF builds — and who should not.

One thing up front, because it trips up every first-time downloader: the repo is gated. The naive hf download orcarouter/Qwen3.8-27B-Uncensored-NVFP4 one-liner fails with an authentication error until you are logged into Hugging Face and have accepted the repo's access terms on the model page. Everything below assumes you have done both.

Also up front: this repo's model card is behind that same gate, so nothing here paraphrases it. What follows is anchored on the public file listing and repo metadata, on NVIDIA's public NVFP4 documentation, and on field reports from people serving Qwen3.8-27B NVFP4 builds on Blackwell. Where a number comes from a practitioner rather than a vendor, the text says so.

What this build is

Qwen3.8-27B-Uncensored-NVFP4 is the NVFP4 quantization of Qwen3.8-27B-Uncensored, the abliterated version of Ali​baba's Qw​en/Qwen3.8-27B that the orcarouter org published on 2026-08-18. Abliteration removes the model's refusal direction from the residual stream; that technique is explained in our uncensored-model explainer and is not re-explained here. The base is the dense 27B with hybrid attention — 48 linear-attention layers plus 16 full-attention layers — native image and video understanding, a 262,144-token context, and a built-in MTP speculative-decoding head. Apache 2.0 end to end.

What makes this build interesting is not the abliteration but the quantization layout, because it is deliberately a quantized build — if you searched for NVFP4, the format is the point. Per the repo's public metadata and quantization config, it is a mixed-precision compressed-tensors build: the attention projections are FP8 (E4M3), the MLPs are NVFP4 (4-bit, packed), and the vision encoder, the MTP head, the lm_head and the linear-attention norms and biases are left in BF16. The public file listing's safetensors metadata lines up with that scheme: roughly 3.5 billion parameters in BF16, 9.4 billion in FP8-E4M3, and 15 billion in the packed 4-bit tensors, about 24.7 GB on disk across five shards plus a separate model-extra shard. None of that is a claim about how it serves — runtime VRAM and throughput for this exact repo are not published anywhere I can cite today. The on-disk size is from the file listing, the format is from the config, and the serving behaviour below is community-verified on closely related NVFP4 builds.

What NVFP4 is, and how it differs from FP8 and from INT8/AWQ

NVFP4 is NVIDIA's 4-bit floating-point format, introduced for the fifth-generation tensor cores on Blackwell, and NVIDIA's own technical blog is the right primary source for it. It stores weights as E2M1 — one sign bit, two exponent bits, one mantissa bit — and scales them in blocks: every 16 values share an E4M3 FP8 scale, and the whole tensor gets a per-tensor FP32 scalar. That two-level scheme is the format's whole point: it recovers the dynamic range a naive 4-bit float would lose, at the cost of a few bits of overhead per block. The practical differences, in one-line form:

• NVFP4 vs FP8 — both are floating-point, but FP8 (E4M3, 8-bit) runs on Hopper and Blackwell, while NVFP4 is 4-bit and is only accelerated natively on Blackwell. NVIDIA cites roughly 3.5× smaller weights than FP16 and about 1.8× smaller than FP8, and on Blackwell the matmul runs directly on the FP4 tensor cores.

• NVFP4 vs INT8/AWQ — INT8 (W8A8) and AWQ (W4A16) are integer formats that run from Ampere onward; AWQ is 4-bit but integer, and on most hardware the weights are dequantised to a wider type for the matmul. NVFP4 is 4-bit float with block scaling, so it keeps more precision in the low bits, and it has a native FP4 GEMM path that the integer formats do not.

• NVFP4 vs MXFP4 — the two are constantly confused. MXFP4 uses 32-element blocks and E8M0 (power-of-two) scales; NVFP4 uses 16-element blocks and E4M3 scales. The finer blocks give NVFP4 better outlier isolation, which is why the format is the de-facto 4-bit standard on Blackwell serving stacks.

Which hardware benefits — and which does not

The single most important fact about this build: NVFP4 is a Blackwell format. It earns its keep only on the GPUs whose tensor cores implement FP4 GEMM natively, and on anything else it is the wrong tool no matter how fast the machine is on paper.

• Blackwell — RTX 50-series, B200/B300, RTX PRO 6000, DGX Spark (GB10) — this is where NVFP4 is the right call: native FP4 tensor cores, the smallest server-grade footprint in the uncensored line, and the format the build was made for.

• Hopper — H100/H200 — no native FP4 GEMM. NVFP4 degrades to a weight-only dequant path that is slower and buys nothing. Use Qwen3.8-27B-Uncensored-FP8 here; that build is verified on exactly this hardware.

• Ampere/Ada — RTX 3090/4090 — NVFP4 does not accelerate on these either. The GGUF build, with its Q4_K_M tier at 16.8 GB, is the right tool for a 24 GB card.

• Apple Silicon — NVFP4 is irrelevant on a Mac. The MLX build (or GGUF) is the one that runs.

One honest nuance: community forks do run NVFP4 weight-only on pre-Blackwell hardware. A community NVFP4 build of the same abliterated model is explicitly set up for V100-class cards through a patched vLLM fork, and the recent DGX Spark recipes around Qwen3.8-27B are their own thing. Those are specialist paths with their own caveats, not what this build targets. If you are on Blackwell, none of that matters; if you are not on Blackwell, the FP8 or GGUF build is the better download.

How to serve it

The repo is tagged for vLLM, and the compressed-tensors format is read automatically from config.json — you do not hand-select a quantization scheme. The stack practitioners converge on for Qwen3.8-27B NVFP4 builds is a recent vLLM on a Blackwell card, an FP8 KV cache, and the model's own MTP head used for speculative decoding. Unsloth's NVFP4 guide, which is the most widely cited community reference, recommends vLLM 0.25.0 or newer with FlashInfer and the CUTLASS-DSL kernel dependency for the fast FP4 path.

A working starting point, assembled from our FP8 build's verified flags and the community NVFP4 recipes, all on one line:

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 — the most broadly compatible way to halve cache memory; practitioners report it roughly doubles the context you can hold. NVFP4 KV-cache support exists but is limited to some attention backends, so FP8 KV is the safer default.

• MTP speculative decoding — the model ships an MTP draft head, and the quant keeps it in BF16. Practitioners report two to three draft tokens working well with NVFP4 weights on Blackwell, with the biggest wins on structured output such as JSON and tool calls.

• Vision — the vision encoder is preserved in BF16 in this build. Add --language-model-only to serve text-only; drop it if you need image or video input.

• On a DGX Spark — a couple of field-reported gotchas: keep --gpu-memory-utilization at or below 0.90 (higher values have wedged the machine during weight load), and add --safetensors-load-strategy lazy if memory is tight. You also need a GB10 build of vLLM for the sm_121a kernels.

Honest performance: there are no published, independent throughput numbers for this exact repo. The measurements that exist are for closely related NVFP4 builds. Unsloth reports 1.41–1.49× the tokens-per-second of BF16 on a B200 for its own Qwen3.8-27B-NVFP4 build (89.8 to 133.7 tok/s at batch 1, 3,048 to 4,407 at batch 64), and one DGX Spark user on the NVIDIA forums reports roughly 20–32 tok/s with NVFP4 weights, an FP8 KV cache and MTP depth 3. Both are worth citing; neither is a benchmark of this repo.

Usage patterns that actually work

Practitioners running Qwen3.8-27B-family models on Blackwell converge on a handful of settings. Treat these as field reports, not vendor guidance — Qw​en does not document most of this, and this repo's own card is 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 are paired with thinking mode, not independent. Community consensus: thinking on runs at temperature 1.0 / top_p 0.95; thinking off runs at temperature 0.7 / top_p 0.80 with presence_penalty 1.5. Swapping the two sets degrades output quality.

• Use a current chat template. The qwen3_5 template wraps every assistant turn in a think block, and multiple practitioners report looping or clipped answers with stale templates; the community-fixed Qw​en-Fixed-Chat-Templates and Qw​en-Sharp variants set preserve_thinking and stop the loops. If your served output rambles past the stop token, this is the first thing to check.

• Budget for long reasoning traces in agent work. Practitioners report the 3.8-generation model emits roughly twice the tokens per task of its 3.6 predecessor — the quality jump comes partly from longer thinking. For long xhigh answers, stream the reasoning output or you will hit gateway timeouts.

• Tool calling is intact through the quant. The function-calling path survives both the abliteration and the 4-bit conversion; enable it with the qwen3_coder tool-call parser and the model picks tools the same way the base does.

Who should pick this build — and who should not

The honest decision, without repeating the quant-picking math our FP8 and GGUF posts already cover in detail:

• Pick NVFP4 if you are serving on Blackwell and want the smallest server-grade footprint in the uncensored line with FP4-tensor-core speed — and you are doing research, red-team or interpretability work that legitimately needs an abliterated model.

• Pick Qwen3.8-27B-Uncensored-FP8 if you are on Hopper, or you want the most broadly verified vLLM path — it is the same weights at 8-bit, verified on an H200, with roughly a 40 GB VRAM floor.

• Pick Qwen3.8-27B-Uncensored-GGUF if you are on a consumer GPU or a Mac, or you want llama.cpp rather than vLLM — the Q4_K_M tier is the local sweet spot.

• Pick neither if you want maximum fidelity, you are building anything user-facing (see the safety boundary below), or you do not want to self-host at all — the same uncensored line is served through OrcaRouter gated to researchers, so no GPU is required.

The safety boundary — research only

This is an abliterated model, and the quant does not put the guardrails back. The refusal direction was removed from Qw​en/Qwen3.8-27B's residual stream, and NVFP4 is a precision change, not a safety intervention — the model will comply with requests the base model refuses, and this build has no built-in moderation. It is released for interpretability, AI-safety and red-team research under Apache 2.0, and the responsibility is yours.

Two evaluation notes that come up too rarely in the uncensored-model space. First, a single jailbreak probe that passes trivially is not a passing safety evaluation — abliterated models fail those on purpose. Measure what you actually care about with the proper batteries (AdvBench, HarmBench and StrongREJECT for harmfulness; XSTest-safe for over-refusal) and compare refusal rates before and after the intervention. Second, evaluate the quant, not just the base: a 4-bit build can change behaviour on edge cases even when aggregate scores look fine. Do not deploy this to end users without your own moderation and abuse-prevention layers.

Where OrcaRouter fits

A ten-day-old quantized build is the textbook case for routing rather than hardwiring. You can stand up a route that points at the NVFP4 build you run yourself and fail over to a hosted model if the build misbehaves under load — one interface, no rewiring between providers when you switch. OrcaRouter passes the provider list price through at 0% markup, so if the underlying model's price moves, your endpoint reflects it the same day rather than on your billing cycle.

And if the whole point is to avoid running a GPU at all: the same uncensored line is available through OrcaRouter, gated to security researchers and red teams, with automatic failover across providers. Whether you self-host this NVFP4 build or call the hosted line, it is one API key either way.

The bottom line

Qwen3.8-27B-Uncensored-NVFP4 is the right download if you are serving the abliterated model on Blackwell and want the smallest footprint with FP4-tensor-core speed. It is the wrong download on Hopper (use the FP8 build), on a consumer or Apple GPU (use the GGUF or MLX build), or if you need maximum fidelity. It is not new — it has been downloadable since August 19, 2026 — but it is being downloaded in volume, and now you know what you are getting into before you accept the gate.

Not another build of this model — Qwen3.8-Flash-Next-Uncensored is a separate release: abliterated from Qwen3.8-Flash-Next, a 176B-stored / 6B-active mixture-of-experts preview of the Qwen4 architecture. Same abliteration technique, different weights, its own collection.

All six 27B builds — BF16, GGUF, MLX, FP8, INT8 and NVFP4 — are collected in the Qwen3.8-27B-Uncensored collection on Hugging Face.

These weights are local-only by design. For a hosted baseline to measure the abliterated build against, Qwen3.8-27B is served on OrcaRouter at provider list price with 0% markup — the stock model, safety alignment intact.