DeepSeek-V4.1-Flash-UNCENSORED-GGUF

Uncensored 552B MoE with 1M-token context, vision, and full tool/reasoning support — converted to GGUF for llama.cpp.

Built from dealignai/DeepSeek-V4.1-Flash-UNCENSORED-FP8 (permanent weight-level abliteration of deepseek-ai/DeepSeek-V4.1-Flash), converted to GGUF and requantized. No guardrails: the model follows on prompts the base model refuses (verified, see Benchmarks).

Notice — the same quants, in smaller files, are coming (updated during testing)

While benchmarking, a per-layer audit of the quantized files revealed that the routed experts are larger in the Q4_K_M and Q3_K_M files than in the Q8_0 file — the Q4 experts re-encoded from the source checkpoint's native MXFP4 (4.0 bits/weight) into Q4_K (~4.5 bits/weight), a net precision upgrade that added ~40 GB. The Q3 file is near Q8-sized for the same reason plus the Q5_K up-scaled expert down-projections.

Update: the corrected ramp landed first as the new Q2_K set (271 GB, 6×50 GB shards) — it fits a 256 GB machine and passes the full benchmark suite, see Benchmarks. Smaller corrected Q3/Q4 re-quants (experts back at checkpoint-native MXFP4) will replace those files within a few days.

What this means for you: - The files on the Hub right now are correct and tested — fine to download if you want them. - If you can afford to wait, you should — otherwise you'll download ~450 GB, delete it, and download the smaller version again. Sorry in advance. :D

Details: Per-group quantization & size · Requantization note

Files

All quant files are sharded. The Q2 set is sharded at ≤50 GB (friendlier resumable downloads); the older Q3/Q4/Q8 sets at ≤180 GB. Download every file with the same prefix — llama-server -m accepts any one shard filename and loads all of them automatically.

Quick download example (Q4):

hf download Adolphsson/DeepSeek-V4.1-Flash-UNCENSORED-GGUF \
  --include "DeepSeek-V4.1-Flash-UNCENSORED-Q4_K_M*" \
  --local-dir ./dsv41

Requantization note (read this): the Q8_0 file is a direct FP8→GGUF conversion. Q4_K_M and Q3_K_M are requantized from the Q8_0 GGUF, not from FP8. For attention weights and sensitive tensors the loss is negligible (8-bit is an excellent intermediate), but strictly speaking these are two-step quants. We kept Q8_0 in this repo precisely so anyone can requantize anything else from the highest-fidelity GGUF we have.

Heads-up on Q8_0 routed experts: the source checkpoint stores the 384 routed experts per layer in MXFP4 (4-bit float). The converter passes them through as MXFP4 rather than re-encoding to Q8_0 — so "Q8_0" applies to everything except the routed experts, which are 4-bit in the Q8 file and get re-encoded to Q3_K/Q4_K in the lower quants. The engram memory tables follow the base quant (Q8_0 → Q4_K → Q3_K), which is the main reason the file size drops so much between quants.

Per-group quantization & size (measured from the actual files)

What each quant actually contains, per weight group — type + size as read from the GGUF headers:

Q2 uses the corrected sensitivity ramp: every group at its OrcaSAQ role step (w1/w3 = base, w2 = base+1, shared = base+2, attention pinned 8-bit, engram value-projection pinned 6-bit) — no group exceeds the checkpoint-native MXFP4 precision. The older Q3/Q4 sets above still carry the pre-correction static recipe (Q5_K everywhere for w2), which is exactly the inconsistency the audit caught; corrected re-quants are coming.

The attention block, indexers and sensitive tensors stay Q8_0 in every quant (sensitivity-aware recipe, see Quant pipeline). The engram memory tables are the second size driver after the experts — they drop from Q8_0 (209 GB) to Q4_K/Q3_K. Vision weights live in the separate mmproj file (BF16, unchanged).

Vision note

The standard mmproj export for this model (pfeifferj/DeepSeek-V4.1-Flash-GSQ-RCO-GGUF) is missing the v.token_embd.img_pad tensor required by the fork's DEEPSEEK4V projector loader, which makes --mmproj abort at load. We added a zero-initialized img_pad row (5120 dims, same dtype/shape as img_start) via byte-level GGUF surgery — all 298 original tensors verified byte-identical. The img_pad sentinel is not written by the runtime layout for normal images, so a zero row is functionally correct. Verified: a blue square image → "The square is blue." on CPU.

How to run (CPU + RAM, full 1M context)

Reference hardware: 64-core CPU (2 NUMA nodes), 440 GB RAM. Works on 96/128-core / 512 GB too, just slower.

numactl --cpunodebind=0 --membind=0 llama-server \
  -m DeepSeek-V4.1-Flash-UNCENSORED-Q4_K_M-00001-of-00003.gguf \
  --mmproj DeepSeek-V4.1-Flash-mmproj-BF16.gguf \
  -lm mmap --numa numactl -ngl 0 -cmoe \
  -ot "engram_embd.weight=CPU" \
  -fa on -c 1048576 -b 2048 -ub 1024 -t 32 \
  --host 0.0.0.0 --port 9876

Key flags: - -lm mmap — required. The engram tables are built for lazy mmap reads; -lm none (load-all) is ~20× slower for generation on this model. - --numa numactl + the external numactl binding — keeps weights and KV on one NUMA node, ~+25% prompt speed. - -cmoe + -fa on — MoE + flash-attention CPU kernels. - -ot "engram_embd.weight=CPU" — engram embedding table pinned to CPU. - -c 1048576 — full 1M context. KV is tiny for this model: ~890 bytes/token (~0.9 GB per slot at 1M) thanks to DeepSeek's sparse-attention KV compression, so context length is not your RAM bottleneck.

RAM expectations (measured, Q3): ~50 GiB working set for weights + engram at steady state (weights stream through mmap/page cache; only active MoE experts + engram + KV are resident). Budget roughly: Q3 ≈ 55 GiB, Q4 ≈ 70 GiB, Q8 ≈ 140 GiB + KV + headroom.

Performance (measured, Q3, CPU-only): | Metric | Value | |---|---| | Prompt processing (short) | ~30 t/s | | Prompt processing (512k ctx, measured) | ~26 t/s | | Prompt processing (1M ctx, measured) | ~15 t/s | | Generation (warm) | ~11.5 t/s | | Generation (cold start) | ~11 t/s |

Benchmarks

Hardware: 64-core CPU, 440 GB RAM, mmap recipe above, temperature=0. All quants ran GSM8K, MMLU, refusal smoke and NIAH 8k→128k. Q3 and Q2 are running the full NIAH ladder to 1M (Q3 complete, Q2 in progress).

* GSM8K differences between Q3/Q4/Q8 are within binomial noise at n=100 (±~3 items) and are reported for completeness, not as a ranking. Q2's 89 is outside that band — the first genuine capability step down. MMLU shows the same shape (Q2 at 72 vs 75–76). What survives intact on Q2: uncensored behavior (0/0 refusals) and every needle in the haystack up to 128k.

** Q8's 1/20 refusal is a false positive of the keyword detector: the model answers the prompt in full, and the match is the phrase "…while unable to move…" inside a factual description, not a refusal. All four quants answer every prompt.

Perplexity note: llama-perplexity against one identical 120k-character public-domain prose reference (sha256 6873c7ee…), identical window/stride on all three. The ladder is monotonic in the right direction (Q8 < Q4 < Q3) — the sensitivity recipe behaves as intended at every tier — but the reference is easy prose and nearly saturates: the Q8→Q4 step is within combined error bars, i.e. statistically indistinguishable. Read this as no catastrophic loss at any tier, not as a fine-grained ranking. It is, however, exactly the measurement that supports the re-quant work announced at the top: keeping the routed experts at the checkpoint-native MXFP4 (-40 GB on Q4) costs nothing measurable.

Uncensored sanity check: on the refusal smoke set the Q3 build follows on all 20 harmful prompts with zero "as an AI / I cannot / I'm sorry" responses, and answers all 10 benign ones normally. Consistent with dealignai's reported HarmBench-320 result of 100% ASR.

Note on Q3 as the NIAH reference: the lowest quant is the strictest needle-in-a-haystack test — if Q3 finds the needles, Q4/Q8 (strictly higher fidelity) will as well. Hence the full ladder (8k→1M) and GSM8K are run on Q3 only; Q4/Q8 get the 128k tier plus MMLU and refusal smoke — if a higher quant loses the needle at 128k where the lower quant found it, that is a regression worth reporting, and the ladder is extended downward.

The 1M NIAH tier was expected to be a multi-week run on this hardware and was planned to be skipped — it finished in ~19 h instead (≈15 tok/s effective prefill at 1M: DeepSeek's sparse attention keeps long-context prefill practical) and found the needle. The full ladder 8k→1M is now complete on Q3; Q4/Q8 get the 128k tier.

Provenance

• Abliterated base: dealignai/DeepSeek-V4.1-Flash-UNCENSORED-FP8 (abliteration 2026-09-10). Verified: all vision.* tensors byte-identical to deepseek-ai base (shard 00001, matching LFS-SHA256); edits confined to MoE shards 00013–00039.
• GGUF conversion & quants: llama.cpp fork vcruz305/llama.cpp branch runtime/deepseek41 (commit 5210c7c) — the only public build with DeepSeek-V4.1 text-model GGUF support + the DEEPSEEK4V projector.
• Original (reference) Q3: the excellent vcruz305/DeepSeek-V4.1-Flash-GGUF — this repo's Q3/Q4 are the uncensored counterparts.
• Built & tested by: Adolphsson
• Related release: IndrasMirror/DeepSeek-V4.1-Flash-GSQ-Uncensored — a Strata-runtime GSQ (2-bit ternary) release of the same dealignai base. Not a llama.cpp/Ollama/LM Studio GGUF (per-expert quant types those runtimes don't load) — use it with Strata-DSV4.1. Different runtime, same base: both are welcome.

License

Lineage

• Original base model: deepseek-ai/DeepSeek-V4.1-Flash (MIT)
• Source model: dealignai/DeepSeek-V4.1-Flash-UNCENSORED-FP8 (MIT) — the "CRACK" weight-level abliteration
• Direct contribution (this repo): GGUF conversion of the dealignai FP8 checkpoint to Q8_0, requantization to Q4_K_M / Q3_K_M, the mmproj img_pad patch, and the CPU benchmark suite. This is a quantization/conversion release only — the uncensored behavior was created by dealignai, not by this repo.

The model weights are MIT-licensed at every step of the lineage (DeepSeek-V4.1-Flash → dealignai abliteration → this repo). Quantization changes the weights numerically but not their provenance or license.

Full license text: LICENSE · Upstream attribution: NOTICE