base_model: orcarouter/Qwen3.8-Flash-Next-Uncensored
base_model_relation: quantized
library_name: mlx
pipeline_tag: image-text-to-text
license: other
license_name: qwen-community-1.0
license_link: LICENSE
language:

• en
• zh
  tags:
• mlx
• tensorfold
• qwen4
• mtp
• uncensored
• abliterated
• not-for-all-audiences

Qwen3.8 Flash Next Uncensored for TensorFold (4-bit experts, 6-bit attention, MTP)

Not an official release. Not from Qwen, orcarouter, jedisct1 or mlx-community.

This pack serves orcarouter's uncensored Qwen3.8 Flash Next on TensorFold 1.2.0 on Apple Silicon. It combines two published quantizations of the same uncensored weights: the experts from
jedisct1/Qwen3.8-Flash-Next-Uncensored-oQ4e-100K-MTP
(revision 7d92e74f3e1d), regrouped to 4-bit group size 32 so TensorFold can use its fast path, and the attention
and other non-expert weights copied byte for byte from
mlx-community/Qwen3.8-Flash-Next-Uncensored-oQ6e-mtp
(revision 97509cce). It does not apply a new refusal edit; the refusal behaviour is orcarouter's abliteration.
Both sources quantize orcarouter's uncensored model; mlx-community does not publish which orcarouter revision it used.
A weight-difference analysis between the two found no sign of a different refusal edit (it catches a planted edit
reliably at about 2% of the weight norm, marginally at 1%), and this pack opens no harmful-set reply with a refusal (see Measured). Vision, video
and the MTP head are kept.

About 136 tok/s median decode writing code, single stream, 2k–193k context, on an M3 Ultra. Against the
all-4-bit layout of the same experts, measured in the same session, it is about 5% slower (136 vs 142 tok/s) and
scores higher on tool calling (BFCL simple 92.3% vs 88.0%, p = 0.03), with maths and knowledge scores tied. See
Measured.

This model is uncensored. Its refusal behaviour was removed upstream and it will answer requests the original
Qwen model declines. You are responsible for how you deploy it, including any filtering your use needs. It is not
suitable for unsupervised public-facing products. orcarouter released the uncensored weights for legitimate research,
red-teaming and safety evaluation; the same intended use applies here. Read the
source model card's disclaimer before use, and comply
with the laws that apply to you.

Lineage and credit

The calibrated quantizations are jedisct1's and timteh673's, both made with oMLX by
jundot. This release regroups, combines and, in two places, requantizes them, as the table shows.

What is in this pack

Every exact regroup was checked tensor by tensor with mx.array_equal on the dequantized values. config.json
holds this pack's per-module bits and group sizes. quantization_provenance.source-oQ4e.json is jedisct1's
provenance file for the oQ4e source, kept unchanged for its calibration record; its quantization table describes
that source's layout, not this pack. The shard names follow the build: 22 model-000NN-of-00022 shards and two
model-graft-* shards holding the copied modules; model.safetensors.index.json maps every tensor. Loaders that read
the index handle this; a tool that guesses the shard list from the -of-00022 names would miss the two graft shards.

TensorFold's fast kernels want group size 32 for the experts: on this model a uniform 4-bit pack measured 122 tok/s at
group size 64 against 152 at group size 32, and a pack that kept the shared experts at 8-bit measured 126 vs 148 tok/s,
which is why the experts are regrouped and the shared experts requantized.

Measured

Mac Studio M3 Ultra, 256 GB, stock TensorFold 1.2.0 serve single-reply (no --parallel), thinking off, greedy.

Speed. 384-token replies to a code-writing task (a new Python module with tests) after a growing prefix of real
source code; mean of two runs, alternated with the all-4-bit layout of the same experts:

Median over all points: 135.5 vs 142.1 tok/s. Single runs of the same pack varied by up to 9% at a given depth. The
server ran with --prompt-cache-gib 0, so each time to first token is a cold prefill.
MTP draft acceptance over these runs was 80.4%. Prose decodes slower than code (fewer drafts are accepted); for the
all-4-bit layout a 1,000-token prose reply measured 117 tok/s against 159 for a 1,500-token code reply, and the
prose speed of this pack was not measured. About 133 GiB in memory once loaded.

Capability. Same server, same questions for each pack, greedy, thinking off. A reply that hit the token cap
counts as wrong.

• BFCL: this pack vs the all-4-bit layout p = 0.033, vs the original pack p = 0.076 (exact McNemar on the same
  items). Most failures are answering in text instead of calling the tool: 20 here (none hit the cap), against 40
  for the all-4-bit layout (11 of them cut off at 512 tokens) and 33 for the original (7 cut off), so part of the
  gap is replies that ran on. The checker is our re-implementation of BFCL's AST check (function name, required
  parameters, each value among the possible answers), not the official harness.
• MMLU-Pro: this pack vs the all-4-bit layout p = 0.83 (a tie); vs the original p = 0.002, but that gap comes mostly
  from the original's longer reasoning hitting the cap: 47 of its 280 replies were cut off, against 18 here and 29
  for the all-4-bit layout. On the 224 questions all three finished, the scores are 87.1%, 90.2% and 87.5%; that
  subset is self-selected, so do not rank the packs on it.
• GSM8K: all within noise (147, 147 and 143 correct; p ≥ 0.125 for every pair).

Fidelity against a higher-precision pack. No full-precision comparison was run. Next-token KL against
mlx-community/Qwen3.8-Flash-Next-Uncensored-oQ6e-mtp (6.7 bits per weight), measured in oMLX's mlx_vlm, full
248,320-way distribution, 4,096 positions each. The code text is Python standard-library source; the prose text is
English model-card and licence text from local model folders, which includes the reference pack's own README.

The same-pack noise floor (64 positions, two sequence lengths) is 0.004 for this pack and 0.002 for the all-4-bit
layout, so the code KL of 0.011 is about 3× this pack's floor. This pack shares its attention and other non-expert
weights with the reference, so part of its lower KL is by construction; read the table as "closer to the 6.7-bit
pack", not as distance to the full-precision model. The benchmark scores above are the independent evidence. The
remaining prose gap is probably the 4-bit experts and the two lossy steps (shared experts, lm_head); that split was
not measured for this pack.

Behaviour: 13/13 on a small benign check (arithmetic, facts, code reading/writing, instruction format, JSON,
Arabic translation, a needle at 30k tokens).

Vision (server started with --vision; a smoke test, not a benchmark): two generated pictures with known text
and shapes. Shapes and colours correct in both; the text read exactly in one ("TENSORFOLD 4291"), misread in the
other ("PIER 37 NORTH" as "PIERS7 NORTHL"). Video was not tested.

Refusals. Heretic's KeywordRate rule (p-e-w/heretic 0db5c31): a reply counts if any of Heretic's 33 marker
phrases appears anywhere in it, after lower-casing and removing *. mlabonne/harmful_behaviors test[:100], 100
tokens, system prompt You are a helpful assistant., greedy, thinking off: 33/100 contain a marker; 0/100
open with one. The opening count lower-cases the reply and keeps markdown, so the 11 replies that begin with a bold
"Disclaimer:" line and then answer are not counted as refusals. All 100 replies run to the 100-token cap; within
that window the matches are disclaimers or hedges around the start of an answer, and three replies open by
challenging the question's premise instead of answering it directly. The all-4-bit layout of the same uncensored
weights measured 31/100 and 0/100 in the same setting, and in a fuller set of runs (no system prompt, 512 tokens, the
thobauma/Anthropic-harmless-base and Paul/XSTest over-refusal sets) refused alike to
ARC4NUM/Qwen3.8-Flash-Next-Uncensored-MLX-Serve-4bit,
an mlx-serve pack of the same orcarouter base, with no harmful reply opening with a refusal. Those fuller runs were not
repeated for this pack.

Kept, not tested here: video input and thinking mode. Tool calling was scored only as single calls (BFCL simple),
not multi-turn agent use.

Hardware

TensorFold loads within 70% of RAM by default, so a 256 GB Apple Silicon Mac (M3 Ultra or newer) is the practical
minimum; tested on an M3 Ultra 256 GB. 512 GB is comfortable. On 192 GB the default limit (70%, about 134 GiB)
is below this pack's load plan (the all-4-bit layout's was 135.3 GiB, and this pack is about 0.8 GiB larger), so
TensorFold would refuse to load it unless FLASHNEXT_LOAD_LIMIT_GB is raised or --ple-on-ssd is used; not tested.

128 GB Macs: not tested with this pack. With TensorFold's --ple-on-ssd (the 29.8 GiB n-gram table stays on the
SSD), the all-4-bit layout measured 103 GiB in memory under a 114 GB load cap on the M3 Ultra, with replies identical
to the in-RAM run on 4 of 4 prompts, but on TensorFold 1.2.0 at about half speed (76 / 68 / 69 tok/s at 2k / 28k /
131k), first tokens about 3× slower and no room for a prompt cache. This pack needs about 0.6–0.8 GiB more, so its
plan would be about 106.1–106.3 GiB, just above the 114 GB (106.2 GiB) cap used for that layout; the commands below
use 116 GB. A 128 GB Mac must also have macOS's GPU memory limit raised above the plan (the value below is an
untested example). TensorFold's runbook warns that past 70% of RAM a load that wires most of the memory can stall
macOS until its watchdog restarts the Mac. Treat this as experimental. Smaller Macs cannot load it.

Running it

TensorFold 1.2.0:

tensorfold-native serve /path/to/this/pack --host 127.0.0.1 --port 8080 --no-thinking --keep-warm 86400

--keep-warm 86400 keeps the model wired for a day after each request instead of TensorFold's default 900 s; see
the first known issue. Add --vision for image input. On a 128 GB Mac (untested with this pack; the GPU limit resets
at reboot):

sudo sysctl iogpu.wired_limit_mb=112000
FLASHNEXT_LOAD_LIMIT_GB=116 tensorfold-native serve /path/to/this/pack --host 127.0.0.1 --port 8080 \
  --no-thinking --ple-on-ssd --prompt-cache-gib 0

Leave out --parallel. With the all-4-bit layout, one request ran at 94.0 tok/s without it and 78.6 with
--parallel 4; four requests at once totalled 98.4 tok/s when they queued and 48.2 with --parallel 4 (each stream
pulls different experts; these figures include the prefill of a ~1.5k-token prompt). mlx-serve can't read this pack
(it needs its own pack format). oMLX's mlx_vlm loaded this pack for the KL measurement; it was not speed-tested
there, and the Hugging Face "Use this model" snippet for MLX was not tried.

chat_template.jinja is the file from jedisct1 revision 7d92e74f3e1d, unchanged; read in full, it contains no
injected instruction. With thinking off, the template itself emits an empty <think> block; that is the template's
own behaviour. Primary languages are English and Chinese, as in the Qwen base.

Recommended sampling

The agent row is the setting used in our coding-agent harness (not benchmarked against the others).
generation_config.json is left as upstream ships it.

Known issues

• A long prompt can fail with HTTP 500 right after idle or a slow load (TensorFold 1.2.0): TensorFold keeps the
  model wired for 900 s after a request (--keep-warm); after that, and apparently after a slow load, macOS may
  unwire and compress it. A long prompt runs as two staggered GPU queues, and the second can wait longer than macOS's
  ~5 s GPU watchdog while the memory comes back; the request then ends GpuFailed / HTTP 500. Seen 4 times in about
  3,600 requests of agent use with the all-4-bit layout, on prompts of 27k–203k tokens, each the first long prompt
  after a slow load or idle. A long --keep-warm (for example 86400) keeps the model wired and should avoid the idle
  case, and also removes a 1–25 s delay on the first request after idle; that was not verified on stock 1.2.0, and it
  does not cover the first long prompt after a slow load. The failed request is lost; the client has to send it
  again. We fixed the race in a local TensorFold build; the fix is not in TensorFold 1.2.0.
• Structured output: TensorFold 1.2.0 answers HTTP 400 to response_format / JSON-schema requests and to
  tool_choice: "required" with this model (its backend has no token grammar yet; the error message says the same
  applies to a named function). tool_choice: "auto" tool calls work.
• Thinking plus tools (observed in agent use with the all-4-bit layout, not measured): with thinking on, the model
  sometimes writes the tool-call XML inside the think block, where the client never sees it. Keep thinking off for
  tool use, or check for this in your client.
• Loops at long context (observed with the all-4-bit layout, not measured): if thinking turns into repeated
  punctuation or a loop, stop and start a fresh conversation instead of continuing that transcript. In a
  coding-agent harness at about 100k tokens, that layout once kept alternating the same two tool calls (each turn
  identical to the one two before); a guard that only looks for one repeated call does not catch this, so detect
  repeats of a short cycle or cap identical calls per task. A very high decode speed during such a loop is likely the
  drafts copying the repeated text, not progress.
• MTP and accuracy: jedisct1's card advises keeping MTP off for coding agents: in its oMLX tool-use evaluation the
  MTP-on run passed 48 of 50 positive cases against 50 of 50 with MTP off. The scores above were measured with TensorFold's MTP on; drafts off (--no-drafts) was
  not compared.

Changelog

• First publication. Built from jedisct1 revision 7d92e74f3e1d and mlx-community revision 97509cce. The change
  against those sources is the table in "What is in this pack".

Reproduce

Regroup jedisct1's 4-bit and 8-bit codes from group size 64 to 32 (repeating scales and biases), quantize lm_head
to 4-bit and the MTP fusion projections to 8-bit (group size 32), and quantize its shared-expert MLPs from 8-bit to
4-bit group size 32; then replace the 925 attention and other non-expert modules with mlx-community oQ6e's tensors,
byte for byte. The scripts are not in this repository. Evals: GSM8K, MMLU-Pro and BFCL as described in Measured,
greedy, one request at a time against tensorfold-native serve. Shard hashes are in SHA256SUMS.

License

Qwen Community License 1.0, inherited from the base model. See LICENSE (byte-identical to the file in
Qwen/Qwen3.8-Flash-Next); its notice must ship with every copy. orcarouter's card labels its uncensored model
Apache 2.0, but its repository ships this Qwen licence text, as jedisct1's and mlx-community's cards also note; this
release follows the licence file, not that label.

Two conditions in that license matter for deployment (read the full text, this is a summary):

• A product or service built on it with more than 100 million monthly active users or US$20 million monthly
  revenue must display the model name prominently.
• A company running a Model-as-a-Service or AI work-assistant business needs a separate license from Qwen to use
  it, or any derivative, for a commercial purpose. Internal use is exempt only while nothing about the model,
  its outputs or its capabilities is made available to a third party.