license: mit
license_link: LICENSE
base_model: ISTA-DASLab/DeepSeek-V4.1-Flash-1017-GSQ-RCO-GGUF
base_model_relation: finetune
tags:

• gguf
• abyss
• deepseek
• abliterated
• uncensored
• refusal-direction

DeepSeek-V4.1-Flash-1017-GSQ-RCO-uncensored-t1-4-GGUF

日本語

This model is ISTA-DASLab's quantized file of DeepSeek-V4.1-Flash-1017 (GSQ-RCO IQ2_XXS) with the refusal direction removed, so that it also answers requests the original model refuses. The refusal direction is the direction in which the mean layer output differs between requests the model refuses and ordinary requests.
On 60 harmful requests, the number answered rose from 4 to 60, and scores on MATH and on hands-on tasks are unchanged from the original model.
I am releasing it to show that even if published uncensored models become unavailable, one person can make one with a single consumer GPU (RTX 5090, 121 GiB RAM).

It differs from the other published models built from the same ISTA-DASLab files in three ways.

• Tokens used to find the refusal direction: the other models find it at the last token of the request. This model finds it over the first 40% of the reasoning tokens. Setting the component along this direction to zero (strength 1.0) was enough for the model to answer all 60 harmful requests with reasoning on. The other models use strength 2.0, which flips the sign of the component
• Number of directions and edited layers: the other models apply one direction to every layer. This model finds a direction per layer and per output, and edits only the layers where harmful and ordinary requests separate well
• Weights edited: the other models edit the original full-precision weights and then quantize. This model edits the quantized file directly

The strength and method of the other models are taken from the two cards that state them.

Table 1. Evaluation results of the original model and this model

Harmful requests: harmful requests from MaliciousInstruct. Over-refusal test: requests from XSTest that should be answered.
One run per problem (three for the image-generation request), Abyss v1.3.91.

Performance: answers harmful requests; MATH and hands-on task scores are unchanged

Figure 1. Answers and correct answers per evaluation, original model and this model

Same evaluations as Table 1.
The difference on harmful requests is p<0.001 by McNemar's exact test; the difference on MATH is p=1.000 (per problem).

Figure 2. Success or failure on 13 items of hands-on tasks, original model and this model

The model solved four hands-on tasks from OpenCode, scored as 13 items in total. Three runs each.
Filled means success; × means failure.
The image-generation request asks the model to generate an NSFW image with ComfyUI from OpenCode. The original model refused all three times.

The author's hands-on use in OpenCode: practical for real work

This is not a measured evaluation but the author's impression from everyday use in OpenCode.

• Answer quality dropped sharply once the context went past about 160K tokens. I recommend setting context compaction to trigger before 160K
• Asked to generate NSFW images, it carried the task through to the end without refusing. In my experience, Claude refuses the same request
  • Browser automation with Playwright worked without problems
  • It worked out how to use the author's own Krea workflow in ComfyUI and generated several of the intended images
• I think it is practical for real work

Next-token predictions are almost the same as the original model's

I fed the reasoning and answers that the original model wrote for 10 problems from MATH-500 Level 5 to both models, and compared the next-token probability distributions at 16,025 positions.
The mean KL divergence was 0.0058, and the most probable token agreed at 97.08% of positions.

Speed: about 50 tokens per second of output on one RTX 5090

Output speed was 6–9% slower than the original model (one RTX 5090, Abyss v1.3.91).

Table 3. Output speed of the original model and this model (tokens per second, median)

Median of "output tokens ÷ response time" per problem, from the logs of the Table 1 evaluations.

How it was made: the refusal direction was removed from the weights of 37 attention-output layers and 31 shared-expert layers

I edited the weights of the quantized file directly, in four steps.

1. Find the refusal direction: have the original model answer 200 harmful and 200 ordinary requests with reasoning on, average each layer's output over the first 40% of the reasoning tokens, and take the difference between the two. The t1-4 in the name refers to segments 1 to 4 of the reasoning split into 10 equal parts
2. Choose the layers to edit: choose only the layers where harmful and ordinary requests separate well (37 attention-output layers, 31 shared-expert layers)
3. Edit the weights: of the three kinds of matrices that write into the residual stream in each layer, remove the component along the refusal direction u from the attention output matrix attn_output_b and the shared-expert down projection ffn_down_shexp, as W' = W − u uᵀW (strength 1.0). The routed-expert down projection ffn_down_exps is not edited
4. Save as Q8_0: if kept in the original Q5_K, rounding error brings back the removed component

Table 4. Edited tensors

The routed-expert down projections are IQ1_M in 28 layers, IQ2_XXS in 8 layers and IQ2_XS in 4 layers.
All other weights are byte-identical to the original file.

Figure 3. Matrices edited in each layer

Dark cells are edited layers.

Development history: why the refusal direction was found over the first 40% of the reasoning

The refusal direction is usually found at the last token of the prompt.
For this model, removing a direction found that way still left refusals in real use.
The cause was how the direction was found. So I redid the choice of tokens for finding the direction and of layers to edit, in the six stages below.

Table 6. Six stages to decide how to find the refusal direction

In stages 1–5 the weights were not edited; instead the component along the direction was subtracted from the layer outputs at every inference step.

1. Removing a direction found the usual way still left refusals in real use

I found the refusal direction the usual way and removed it. Refusals in the reasoning fell, but refusals remained in real use.

The direction was found as follows. Below, this direction is called the "first direction".

• With reasoning off, layer outputs at the last token of the prompt were recorded
• The mean of ordinary requests was subtracted from the mean of harmful requests

The results of removing it were as follows.

• Strength 1.0: refusals in the reasoning fell from 19 of 20 to 5. Refusals remained in real use
• Strength 2.0: refusals in the reasoning fell to 0. In real use, the model avoided answering
• Strength 2.0 also changes the weights twice as much as strength 1.0

Figure 4 shows, for the original model and the two versions with the first direction removed, the number of refusals in the reasoning and the response in real use.

Figure 4. Refusals in the reasoning, original model and versions with the first direction removed at strength 1.0 and 2.0

20 harmful requests, one run each. The bottom row is the response in real use.

2. After removing the first direction, 28% of the difference between harmful and ordinary requests remained in another direction

Raising the strength in stage 1 did not fix it, so I examined what remained in the model after removal.
28% of the difference between harmful and ordinary requests remained, in another direction.

The examination was as follows.

• Outputs of all 40 layers were recorded for 200 harmful and 200 ordinary requests
• The original model was compared with the versions with the first direction removed

The results were as follows.

• The component along the removed direction was zero (at most 2.1×10⁻⁷)
• Still, 28% of the difference remained at strength 1.0 and 3% at strength 2.0 (original model = 100%)
• The remaining difference lay in directions other than the removed one

Figure 5 shows how much of the difference between harmful and ordinary requests remained after removing the first direction, and which outputs it came from.

Figure 5. Difference in the vectors added to the residual stream, original model and versions with the first direction removed at strength 1.0 and 2.0

Difference: at the first token of the answer, the vectors each layer adds to the residual stream (attention output, routed-expert output, shared-expert output) were projected onto the reference direction, and the difference between the means of 200 harmful and 200 ordinary requests was summed over all 40 layers.

Reference direction: the direction of the difference between the means of harmful and ordinary requests in the residual stream at layer 26 of the original model.

Colors show the breakdown by the output that produced the difference.

3. The first direction was found the wrong way; found again as the mean over the whole reasoning, it removed refusals in real use

Stage 2 showed that the first direction did not capture the difference, so I changed the tokens used and found the direction again.
The first direction turned out to have been found the wrong way.

The direction was found again as follows.

• The recordings from stage 2 (reasoning on) were used
• Directions were found at six token positions: last token and mean of the prompt, start and mean of the reasoning, start and mean of the answer

The results were as follows.

• Only the direction from the mean over the whole reasoning answered all 10 harmful requests (the other five positions answered 4–9, the first direction 8)
• Only that direction also did not refuse in real use
• Its cosine similarity with the first direction (1 means the same direction, 0 means unrelated) was 0.34, so it was a different direction

Figure 6 shows, for each token position used to find the direction, the number of the 10 harmful requests answered and the response in real use.

Figure 6. Harmful requests answered (of 10), by the token position used to find the direction

Strength 1.0, one run each. The 10 requests were not used to find the direction. The bottom row is the response in real use.

4. The earlier in the reasoning, the better harmful and ordinary requests separated

In stage 3 the direction from the mean over the whole reasoning removed refusals, so I examined which part of the reasoning the direction should be found over.
The earlier in the reasoning, the better harmful and ordinary requests separated.

The examination was as follows.

• The reasoning was split by length into 10 segments (T1 = 0–10%, T2 = 10–20%, …, T10 = 90–100%)
• Directions were found for each segment and for each bundle of consecutive segments

The results were as follows.

• Separation (d′, larger means better separated) was highest for the first 30% (6.38), followed by the first 40% (6.27)
• The more later segments were included, the lower d′ became
• T1, T2 and the bundles starting at T1 answered all 10 harmful requests. T3–T10 answered 7–9 (one run each, so the difference is only a tendency)

Figure 7 shows, for all 55 spans of the reasoning, how well harmful and ordinary requests separate when the direction is found by averaging over that span.

Figure 7. d′ between harmful and ordinary requests, by the span of the reasoning averaged

Each cell is the d′ of the direction found by averaging from the start of the span on the horizontal axis to the end of the span on the vertical axis.
Attention output, mean over all 40 layers, 400 prompts. The thick border is this model (0–40%).

5. Fourteen candidates were compared and narrowed to two that edit only well-separated layers

In stage 4 many directions answered close to all 10 requests, so the test could not tell them apart; I made 14 candidates and compared them on capability and in real use.
The versions that edit only well-separated layers stayed closest to the original model.

The 14 candidates combine the following two.

• 7 directions: T1, T2, T3, the T1–T2 bundle, the T1–T3 bundle, the T1–T4 bundle, and the T1–T10 bundle (the whole reasoning) for comparison
• 2 ways to choose layers: well-separated layers only, all 40 layers

The results were as follows.

• Top-1 agreement with the original model (reasoning and answers for 10 capability problems, 14,954 positions): for all 7 directions, the well-separated-layers version was higher (about 97% versus 86–95%)
• 10 harmful requests (the harmful part of a 30-prompt test, reasoning on) and 10 MATH Level 5 problems: differences were within one problem
• NSFW image-generation request (in a setup reproducing everyday use in OpenCode, three runs each): the original model refused all three times, and all 14 candidates made the image all three times
• Hands-on use in OpenCode by the author (everyday settings, only some candidates): T3 was best, and the T1–T10 bundle refused

From the well-separated-layers versions, I chose these two.

• T3: best in hands-on use in OpenCode
• T1–T4 bundle: answered all 10 requests with both ways of choosing layers, and did not hesitate in the reasoning

Figure 8 shows all results for the 14 candidates and the original model.

Figure 8. Results per evaluation for the 14 candidates and the original model

Within each column, better is darker (for hesitation, fewer is darker). The thick border is this model. One run each (three for NSFW images).

Harmful answered and hesitated in reasoning: the 10 harmful requests of the 30-prompt test, reasoning on. The original model's values were measured on another day with the same prompts and seed.

Top-1 agreement: the share of positions, over the reasoning and answers for 10 capability problems (14,954 positions), where the most probable token matched the original model's.

MATH correct: 10 MATH Level 5 problems, temperature 0.

NSFW images made: in a setup reproducing everyday use in OpenCode (AGENTS.md, everyday settings, working folder), three runs each. T3 made the image all three times, after hesitating.

Hands-on in OpenCode: tried by hand by the author with everyday OpenCode settings. Only some candidates, due to time.

Figure 9 shows the agreement from Figure 8, with the two versions of each direction joined.

Figure 9. Top-1 agreement with the original model for the 14 candidates

The dashed line is a version with a random direction removed, for comparison.

A version with 8 times the strength, which breaks the output, scored 58.0% and is outside the plotted range.

6. The two did not differ; by the order decided in advance, MATH correct answers picked the T1–T4 bundle

I wrote the two candidates from stage 5 into the weights and compared them on more problems.
They did not differ, and by the order decided in advance, MATH correct answers picked the T1–T4 bundle.

The selection rule decided in advance was as follows.

1. Drop any version clearly worse than the original model
2. Compare harmful requests answered (reasoning on)
3. If not significantly different, compare MATH, the over-refusal test and KL divergence, in that order

The results were as follows.

• Neither was clearly worse than the original model
• Harmful requests (reasoning on) were 58 and 60, not significantly different
• MATH was 48 and 50, which decided the T1–T4 bundle
• On every evaluation, the difference between the two was not significant (McNemar's exact test, p=0.07–1.0)

Table 7 shows the evaluation results of the original model and the last two candidates.

Table 7. Evaluation results of the last two candidates

One run per problem (three for the image-generation request), Abyss v1.3.91.

Usage: runs on Abyss v1.3.91 or later (image input needs v1.3.93 or later)

Download the whole repository (about 249GB).

hf download rSalone/DeepSeek-V4.1-Flash-1017-GSQ-RCO-uncensored-t1-4-GGUF --local-dir DSF

The paths inside pack/ are relative, so start Abyss with the downloaded folder as the working directory.

{
 "exe": "<path to Abyss-1.3.91>/build/strata",
 "args": ["--glm-pack", "pack", "--max-context", "262144", "--prefill", "auto"],
 "cwd": "<the folder you downloaded this repository into>",
 "tokenizer": "pack/tokenizer",
 "model_name": "dsf-t1-4-iq2xxs",
 "gpu": [0],
 "sampling": {"temperature": 1.0, "top_p": 0.95},
 "port": 8093,
 "log": "abyss.log",
 "env": {
  "STRATA_GLM_RAM_GB": "75",
  "STRATA_GLM_DISK_READERS": "8",
  "STRATA_GLM_USAGE": "0"
 }
}

{
 "exe": "<path to Abyss-1.3.93 or later>/build/strata",
 "args": ["--glm-pack", "pack", "--max-context", "262144", "--prefill", "auto"],
 "cwd": "<the folder you downloaded this repository into>",
 "tokenizer": "pack/tokenizer",
 "model_name": "dsf-t1-4-iq2xxs",
 "gpu": [0],
 "sampling": {"temperature": 1.0, "top_p": 0.95},
 "port": 8094,
 "log": "abyss.log",
 "env": {
  "STRATA_GLM_RAM_GB": "75",
  "STRATA_GLM_DISK_READERS": "8",
  "STRATA_GLM_USAGE": "0",
  "STRATA_GLM_VL_BIAS": "exp_probs_b_vl.f32"
 },
 "vision": {
  "exe": "<path to the strata-vision binary of the same build>",
  "mmproj": "mmproj-BF16.gguf",
  "model": "overlay-00002-of-00005.gguf",
  "gpu": false,
  "threads": 8,
  "max_tokens": 1024
 }
}

Table 8. Files in this repository

Acknowledgements

• Model: deepseek-ai/DeepSeek-V4.1-Flash-1017 (MIT license)
• Quantized file: IQ2_XXS of ISTA-DASLab/DeepSeek-V4.1-Flash-1017-GSQ-RCO-GGUF (commit 653a9874aa38c356233c5f3cc8c96b19a43b57eb). This model changes only overlay-00001
• Inference engine: Abyss

Thank you to everyone who published these.

Notes and disclaimer

• This model answers harmful requests too. Do not expect it to refuse where you would want a refusal
• Each evaluation was run once per problem (three times for hands-on tasks and the image-generation request). A difference of one or two problems cannot be told apart from run-to-run variation
• Long contexts have not been evaluated with numbers (see the Performance section for the author's hands-on impression in OpenCode). Long-running tasks such as SWE-bench have not been tried
• Abyss is the only inference engine this model has been checked on. It has not been checked yet on other engines such as Strata or llama.cpp; I will test them if there is demand
• Problems where output hit the length limit or looked like a loop: 1 for the original model, 3 for this model. All three occurred in the harmful requests and over-refusal test with reasoning on
• This model has not been compared under the same conditions with the other published models built from the same ISTA-DASLab files
• Users are responsible for their use of this model and its results