Qwen3.8-Flash-Next-Uncensored-NVFP4: A Blackwell Serving Runbook

Qwen3.8-Flash-Next-Uncensored-NVFP4 runs on exactly one family of GPUs: Blackwell. NVFP4 executes on hardware FP4 tensor cores, and Hopper (H100/H200) and anything older simply do not have them. If you are on Hopper, stop here — the Qwen3.8-Flash-Next-Uncensored-FP8 build is the one you want. Everything below assumes Blackwell (B100, B200, GB200, or an RTX 50-series card), a recent vLLM build with qwen4_exp support, and transformers ≥ 5.16.

This is the NVFP4 quantization of the abliterated (refusal-removed) build of Qw​en's Qw​en/Qwen3.8-Flash-Next, cut from 330 GB in BF16 to 178 GB on disk. OrcaRouter published it to Hugging Face on August 27, 2026 as orcarouter/Qwen3.8-Flash-Next-Uncensored-NVFP4. The repo is gated: you must be logged in to Hugging Face and have accepted the repo's terms, or hf download and vllm serve orcarouter/Qwen3.8-Flash-Next-Uncensored-NVFP4 both fail with an authentication error before a byte moves. This page is a serving runbook, not launch coverage — the build is two days old, and the questions people actually hit are hardware, flags, and which build to pick.

And before the numbers start: Qwen3.8-Flash-Next-Uncensored is not Qwen3.8-27B-Uncensored. They are two different models that share a family name and an abliteration technique — different base weights, different architectures, different Hugging Face collections. Flash-Next is abliterated from Qw​en/Qwen3.8-Flash-Next, a routed mixture-of-experts preview of the Qwen4 architecture (qwen4_exp): 512 experts with ten routed plus one shared active, hybrid attention (Gated DeltaNet linear layers alongside full-attention layers), Hyper-Connections, a PLE n-gram embedding, a native vision and video tower, and an MTP speculative-decoding head. The 27B is abliterated from Qw​en/Qwen3.8-27B, a different dense base entirely. Nothing from a 27B page's serving numbers transfers to this model; where a 27B page is genuinely useful — the abliteration primer, the general quant-picking math — it is linked below with what does and does not carry over.

What this build is, precision by precision

Qwen3.8-Flash-Next is a routed MoE: every token activates 10 of 512 experts plus one shared expert, and only a few billion parameters are live per token even though the stored model is far larger. The NVFP4 build is a mixed-precision compressed-tensors quant of that stack, and the split is the whole story:

• MoE expert weights — NVFP4 (4-bit, NVIDIA FP4 E2M1, group-16 with FP8 block scales).

• Attention (self_attn.{q,k,v,o}), the linear_attn projections, the shared expert, and lm_head — FP8 (8-bit).

• PLE n-gram embedding, token and vision embeddings, Hyper-Connections, the QSA indexer, Gated-DeltaNet conv/dt, all norms, and the entire vision tower — BF16, kept at full precision.

Three properties of the conversion matter more than the precision split itself. First, it is weight-only: activations are quantized dynamically at runtime, there is no static calibration, and the weights are derived directly from the BF16 checkpoint (the card calls the derivation data-free). Second, the abliteration edit is baked into the weights, so refusal removal survives the quantization — a 4-bit conversion is a precision change, not a safety intervention. Third, the KV cache is not quantized; it stays BF16 at runtime. That last one is easy to miss and it matters at the model's native 262,144-token context, where the KV cache is a real memory line item alongside the weights.

On-disk size is dominated by one tensor. The card describes the PLE n-gram embedding as a single ~66B-parameter tensor kept in BF16 by design; it is the largest shard and the reason the build is 178 GB rather than a leaner number. One discrepancy to flag rather than paper over: the FP8 sibling card calls the same table the 51B-param PLE n-gram, and this card's W4A4 note refers to it as ~100 GB. The two cards state different figures for the same table, so treat each as its own card's number — and when you size a deployment, assume the table is large in BF16 and plan around it.

The hardware precondition, spelled out

This is the shortest, most important section of the page. NVFP4 is a Blackwell format: the fast path is a native FP4 GEMM on the fifth-generation tensor cores, and without that hardware the format has nothing to run on. The card's own requirement line is explicit — a Blackwell GPU (B100 / B200 / GB200 / RTX 50-series), because NVFP4 uses the hardware FP4 tensor cores, and it will not run on Hopper (H100/H200) or older, which lack FP4 compute.

The redirects, in one place:

• On Hopper (H100/H200) — serve Qwen3.8-Flash-Next-Uncensored-FP8 instead. It is the same weights at 8-bit, it runs on Hopper and Blackwell, and it is the build this blog's FP8 runbook covers.

• On a consumer NVIDIA GPU or a CPU box — the GGUF build, with its 13 llama.cpp quants, is the local path.

• On Apple Silicon — the MLX build, in 4/6/8-bit tiers, is the native Metal path.

The runtime requirement is as binding as the silicon. qwen4_exp is a brand-new architecture, so stock vLLM builds that predate it will refuse to load the checkpoint. You need a recent vLLM with qwen4_exp support plus the compressed-tensors NVFP4 reader (the format is detected from config.json, not hand-selected), and transformers ≥ 5.16. Multimodal input additionally requires the runtime's Qw​en vision stack; text-only serving works without it.

The card's serve command, flag by flag

The model card's own invocation is a good starting point, and it is worth understanding what each flag is for rather than copy-pasting blindly:

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 — the weights are ~178 GB on disk, so the card splits them across four GPUs. This is the shape the build is sized for; do not read it as a suggestion.

• --trust-remote-code — required for a custom architecture. qwen4_exp's modeling code is not in the standard transformers registry yet, so vLLM loads the architecture code from the repo. You are trusting that code, which is a normal but real decision for a brand-new architecture.

• --enable-expert-parallel — shards the experts across the tensor-parallel ranks instead of replicating them, which is what makes a 512-expert MoE tractable at TP4. The FP8 sibling card states the sharper reason on that build: without it, the MoE intermediate width divided by TP is not divisible by the FP8 block size. Treat it as required, not optional.

• --enable-auto-tool-choice and --tool-call-parser qwen3_coder — together they turn on function calling. The auto flag lets the model decide whether to call a tool, and the qwen3_coder parser decodes its tool-call format, the same parser family Qwen3.8-27B and Qwen3.8-Flash-Next serve with.

Once it is up, the OpenAI-compatible endpoint at /v1/chat/completions carries the full feature set through the runtime's Qwen4 stack: tool calling as above, reasoning via chat_template_kwargs.enable_thinking, and vision through image_url content parts. You do not need a separate server for multimodal; it is the same endpoint.

One structural note from the card: there is no fully static W4A4 variant of this build, and there is not going to be one cheaply. A static W4A4 conversion needs an activation-calibration forward pass, and that pass must hold the ~100 GB n-gram embedding on a single GPU. That is the same reason the PLE table dominates the file listing, and it is why this build stays weight-only with dynamic activations.

Community field reports — what serving this actually looks like

No throughput or latency numbers are published for this exact repo, and this page will not invent them. What does exist is a growing set of field reports from practitioners serving the base Qwen3.8-Flash-Next NVFP4 builds — the same architecture, same NVFP4/FP8/BF16 precision split, minus the abliteration edit — and the serving behaviour carries over directly. These are community findings, not vendor guidance, and the people who reported them were on Blackwell hardware with the same quantization scheme.

• MTP speculative decoding is the single biggest performance lever. The model ships a multi-token-prediction draft head, and on one RTX PRO 6000 (96 GB, SM120) the MTP module loads quantized to NVFP4 for about 0.51 GB of VRAM — the report measured an accept length of 2.3–3.9 out of a maximum 4 and an accept rate of 0.86–0.96. The same report measured median single-stream decode of 180–226 tok/s (216.9 on coding, 225.8 on an agent tool-call workload, 136.6 on reasoning) against a roughly 105 tok/s baseline, and answered a 216,685-token prompt in 8.4 seconds. Treat the numbers as one person's rig, not a spec.

• Offload the PLE n-gram embedding to host RAM. Because the table is huge and rarely the throughput bottleneck, community recipes on single Blackwell cards pin it to the host (~50 GiB of free host RAM in the RTX PRO 6000 report) and mmap it from NVMe, trading a little latency for fitting the model at all. Expect to do something like this unless you are on a very large VRAM budget.

• Pin the context window explicitly. With BF16 KV cache and MTP active, an auto-sized KV pool ballooned past what the card could hold and OOM'd on long prefill; pinning max-model-len / max-total-tokens to 262144 restored headroom. At 262K context the KV cache is a line item you budget for, not a default.

• A FlashInfer autotune bug silently corrupts output. The most important failure mode in the field: autotune selects fused-MoE kernel tactics by latency only and never checks numerics, so under some shapes decode collapses into a repeated token. The RTX PRO 6000 report reproduced it as 36 of 36 generations corrupted with autotune on, and 0 of 36 with it off — the workaround is to disable FlashInfer autotune (in vLLM, --no-enable-flashinfer-autotune; in SGLang, --disable-flashinfer-autotune). If your served output suddenly degenerates, check this before touching anything else.

• DGX Spark (GB10, SM121) needs its own patches. The NVFP4 weights (~126 GiB on the community build) do not fit one 128 GB Spark, so the SGLang recipes run tensor-parallel 2 across two nodes over RoCE, and the QSA sparse-decode resolver gates the fast FlashInfer kernel behind an is_sm100_supported() check that fails on SM121, falling back to a path that dies in warmup — the fix is a small patch plus PLE offload. Expect ~47–50 tok/s decode, peaking near 70 with MTP4 and CUDA graphs, and verify your kernel actually runs on SM121 before promising a benchmark.

Reasoning, tool calling, and vision through the Qwen4 stack

Community consensus on the Qwen3.8 generation carries over to this model with the usual caveat that it is field practice, not vendor guidance.

• reasoning_effort is the dial that matters most. The chat template defaults to xhigh, which makes the model think at length on every request. Agent-loop operators set medium by default and drop to low for latency-sensitive calls; enable_thinking false disables reasoning entirely when you do not need it. On a single Blackwell card, leaving xhigh on for routine calls is how a fast model produces slow answers.

• Pair samplers with thinking mode. Practitioners converge on temperature 1.0 / top-p 0.95 when thinking is on, and temperature 0.7 / top-p 0.80 with a presence penalty around 1.5 when it is off. Mixing the two sets degrades output quality.

• Tool calling survives both the abliteration and the 4-bit conversion. The function-calling path is intact, which is what the qwen3_coder parser and auto-tool-choice flags wire up. For a red team this is a double-edged fact, since it means agentic misuse is fully operational on an unaligned model — covered below.

• Vision is preserved, and that widens the attack surface. The vision tower was never touched by the abliteration and stays in BF16, so image input works through image_url content parts. Practitioners evaluating the uncensored line treat the multimodal path as a first-class eval target: prompt injection carried in an image lands on a model with no refusal behaviour to hit.

Which build should you serve

The Flash-Next collection has five builds — BF16, GGUF, MLX, FP8, and this NVFP4 one — and the honest picking logic is about hardware and trade-offs, not a ranking.

• NVFP4 (this build, ~178 GB on disk) — the Blackwell pick. FP4 tensor cores, 4-bit experts, the newest build in the collection and the smallest of its vLLM server builds, and the one this page is about.

• FP8 (~186 GB on disk) — the Hopper pick, and equally at home on Blackwell. The same weights at 8-bit, which is the more broadly verified vLLM path and the one with the clearer expert-parallel requirement.

• GGUF (13 quants, IQ2_XXS ~52 GB to Q5_K_M ~125 GB) — the llama.cpp pick for consumer NVIDIA, AMD, or CPU boxes. No Blackwell needed, no vLLM needed.

• MLX (4/6/8-bit tiers, roughly 163–221 GB) — the Apple Silicon pick, native Metal, MTP head included.

Two honest notes before you pick. First, the NVFP4 and FP8 builds are only about eight GB apart on disk, because both keep the large n-gram table in BF16 — the 4-bit saving is concentrated in the expert weights, not the total footprint. The real NVFP4 advantage on Blackwell is FP4-tensor-core speed on those experts, not a dramatically smaller file. Second, the card describes NVFP4 as a deterministic weight derivation that inherits the abliteration evaluation with a small additional quality trade-off from 4-bit experts, and it does not quantify that trade-off. It is unquantified — treat it as a real but unspecified cost of the smaller experts, not as negligible.

The evaluation, read correctly

The card reports abliteration measured on the BF16 build served with vLLM against the official Qw​en/Qwen3.8-Flash-Next: harmful-prompt refusal collapsing from 64–100% to roughly 0–3.3%, benign over-refusal staying near zero, and capability within ±2 points of the base. Three things to get right about those numbers. They are measurements on the BF16 build, inherited by this 4-bit build by argument rather than measured on it. They are the vendor's own figures, produced with a rule-based opening-phrase classifier that the collection's cards describe as indicative rather than publication-grade — an internal measurement of its own edit, not an independent audit. And they say nothing about the NVFP4 quality trade-off above, which the card does not quantify.

The safety boundary — research only

The card's disclaimer is blunt, and it is the part of this page that must not read like boilerplate. This model has had its safety alignment substantially removed: the refusal direction was orthogonalized out of the residual stream, and the model will comply with harmful, unethical, or illegal requests that the original Qwen3.8-Flash-Next would refuse. It is released strictly for legitimate research — interpretability, AI-safety and refusal-mechanism study, red-teaming, and robustness evaluation — and the authors accept no liability for misuse. You assume full responsibility for what it generates, and you add your own safety and moderation layers before anything touches a user. Apache 2.0 is the floor; the research-purpose gate sits above it.

Two things the uncensored-model discourse gets wrong, and this card makes them impossible to miss. First, a jailbreak probe that succeeds against this model is not a passing safety evaluation — it is the advertised behaviour. An abliterated model fails those probes on purpose; measuring it with a single "can you jailbreak it" test is measuring that the edit worked, not that a guardrail is strong. Second, the preserved vision tower and the intact tool-calling path widen the real attack surface beyond text: image-input prompt injection and agentic tool misuse are both fully operational, which is precisely why the red-team framing treats this as a capability probe, not a chatbot candidate. If your use case is shipping a user-facing assistant, this is not your model, and that is by design.

Where OrcaRouter fits

A two-day-old, gated, self-host-only build is the textbook case for routing rather than hardwiring. When you run this NVFP4 build yourself, you can stand up a route that points at it and fails over to a hosted model if the build misbehaves under load — one interface, no rewiring between providers when you switch. For eval work specifically, the censored served baseline is the comparison you want, and it is a one-key hop away: the catalogue carries Ali​baba's Qwen3.8-Flash at $0.15 per million input and $0.47 per million output, passed through at provider list price with 0% markup, so a red-team harness can move between the hosted censored base and your local uncensored build without a second contract, and any vendor price move lands on your endpoint the same day.

Who should download this — and who should not

Download orcarouter/Qwen3.8-Flash-Next-Uncensored-NVFP4 if you are on Blackwell, you want the smallest server footprint in the Flash-Next collection with FP4-tensor-core speed, and you are doing the research work this line exists for. Download Qwen3.8-Flash-Next-Uncensored-FP8 if you are on Hopper or you want the more broadly verified path. Download the GGUF build if you are on a consumer GPU or a CPU box, the MLX build if you are on Apple Silicon, and nothing at all if the goal is a user-facing deployment. Read the gate and the disclaimer before you accept either — they are the terms of the model, not a formality.

All five Flash-Next builds — BF16, GGUF, MLX, FP8 and NVFP4 — are collected in the Qwen3.8-Flash-Next-Uncensored collection on Hugging Face.

A different model, not another build of this one: Qwen3.8-27B-Uncensored is abliterated from a different base and has its own collection and its own runbooks.

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