StableLearn Logo

Search Content

News 5 min read

320 Answers, 3.86 Points Down: The Cost of Uncensoring DeepSeek

An uncensored DeepSeek V4.1 Flash weight release claims 320/320 HarmBench compliance, but its own MMLU score drops 3.86 points and testing requires four H200 GPUs.

Cover image for 320 Answers, 3.86 Points Down: The Cost of Uncensoring DeepSeek

320 test prompts. All answered.

MMLU score. Down 3.86 points.

Hardware used for testing. Four H200 GPUs.

Those are the three numbers that matter most in the Hugging Face release called DeepSeek-V4.1-Flash-1017-UNCENSORED-FP8. It puts the model’s refusal behavior front and center, but the story is bigger than “DeepSeek finally stopped saying it cannot help.”

One source note first: the model details, benchmark results, and deployment setup below come from dealignai’s Hugging Face model card. They are the publisher’s own results, not independent verification. The related Linux.do discussion is currently unavailable publicly, so I am not treating details from that thread as confirmed facts.

This Changes the Weights

The publisher says the release is based on deepseek-ai/DeepSeek-V4.1-Flash-1017 and applies abliteration directly to the native FP8 weights to reduce refusal behavior.

The model card also lists what was not changed: no chat template modification, no forced-compliance system prompt, no LoRA adapter, no runtime hook, and no new SFT, RLHF, or DPO training run.

That makes it different from the jailbreak prompts circulating online. A prompt can temporarily persuade a model to behave differently. The publisher claims this model already carries the change when loaded. The goal is not to tell the model “do not refuse.” It is to weaken the refusal tendency inside the weights.

That is more direct, and harder to dismiss. A prompt can be deleted. A weight edit travels with the model. There is no chat setting that simply switches the model back to its original refusal behavior.

320 Answers. So What?

The most eye-catching result is HarmBench-320. The publisher reports that all 320 test cases were classified as substantive compliance, with zero hard refusals, soft refusals, or hedged responses.

What does that prove? Under this test setup and scoring method, the model almost stopped refusing.

It does not prove that all 320 answers were correct. It does not prove that the model is safe in every situation. A benchmark can show a behavior shift; it cannot replace independent testing across real-world prompts. Fewer refusals do not automatically produce better answers.

The other number is more revealing. On the publisher’s MMLU test, the base model scored 87.63% and the edited model scored 83.77%, a drop of 3.86 percentage points. The reported humanities gap was even larger: 90.00% for the base model versus 82.69% for the edited version.

The same model card therefore presents two very different signals: 320/320 compliance, alongside a decline in general knowledge performance. That is the real story. Once the refusal boundary is weakened, did other judgments move with it? Based on the publisher’s own numbers, it is too early to claim there was no cost.

These are still self-reported results, so they cannot prove that abliteration caused every point of the difference. They do support one cautious conclusion: “remove refusals without touching capability” is currently a goal, not an independently verified result.

763B Parameters. Do Not Rush to Download

The listed base capabilities are substantial: roughly 763B parameters in a Mixture-of-Experts architecture, a 1M-token context window, image and video understanding, tool calling, and low, high, and max reasoning tiers. The weights use native FP8 e4m3, ue8m0 block scales, and FP4 MoE experts.

Then comes the hardware bill.

The publisher verified the model on four H200 GPUs with roughly 564GB of total VRAM. The model card expects H100, B200, and B300 systems to work as well, but deployment still involves CUDA 12.8, weight conversion, tensor and expert parallelism, and first-run kernel compilation.

So “the weights are public” does not mean “they run on your desktop.” If you have one consumer GPU, this native FP8 checkpoint was not built for your machine. The model card also warns that directly quantizing it to lower bit widths can stack quantization error on top of the weight edit and cause the intended behavior change to regress.

The million-token context is impressive. It is also expensive. Longer contexts and more concurrent requests keep pushing up memory use. For most people who simply want to try a chat model, this is a multi-GPU research checkpoint, not a download-and-click toy.

Who Takes Responsibility for the Answer?

For researchers, the release is useful. Put it next to the base model and you can study the relationship between refusal behavior, general capability, tool use, and safety boundaries. For infrastructure teams, owning the weights provides more visibility than relying entirely on a black-box API.

The trap for ordinary users is reading “does not refuse” as “smarter” or “more truthful.” The model may explain a wrong answer in greater detail. It may produce risky advice more smoothly. The more fluent the response, the easier it is to forget that the model may still be making things up.

The publisher says as much in the model card: the model may generate incorrect, offensive, dangerous, or illegal content. Once the default refusal layer is reduced, more of the checking work moves to the person running and using the model.

This release deserves attention, but “uncensored” is not a performance result. The real question is how much judgment remains after the refusal behavior is reduced. So far, the public evidence is the publisher’s own testing and a noticeable MMLU drop.

320 answers makes the headline. The 3.86-point decline and four H200 GPUs are what readers should remember.

Sources

Share Article

More Articles