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

日本語

◼︎ Update, 2026-11-03: added a six-shard version that llama.cpp can load

A version in llama.cpp's file layout (six shards) was added. The earlier version stays. It was checked to run on llama.cpp, Abyss and Strata. The commands are in the Usage section.

---

◼︎ This model: the refusal direction removed, so it answers requests the original refuses

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).

---

◼︎ How it differs from other published models: tokens for the direction, number of directions and layers, weights edited

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.

---

◼︎ Results: harmful requests answered rose from 4 to 60; MATH unchanged

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.

Evaluation conditions and terms

• Harmful requests: harmful requests chosen from MaliciousInstruct
• Over-refusal test: the safe prompts of XSTest. They contain words that look dangerous, but should be answered
• Ordinary requests: requests with no reason to refuse, such as those in harmless_alpaca (used to find the refusal direction)
• Whether a response answered the request was judged by Qwen3.8-Flash-Next (q8g)
• Hit the length limit: output stopped at the maximum number of tokens
• Looked like a loop: one repeated phrase took up half or more of the output

---

◼︎ 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.

KL divergence stated in the cards of other published models (Table 2)

The input text and the range of the calculation differ, so these are not directly comparable. Shown for reference.

Table 2. KL divergence against the unedited file (values stated in each card)

Smaller values mean closer to the original model's predicted distribution. Unit: nats.

---

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

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. One RTX 5090, Abyss v1.3.91.

---

◼︎ 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.

Details of the method (edited matrices and layers, why routed experts were not edited, procedure, comparison with other published models)

Edited matrices and layers

In each layer, attention and the FFN (one shared expert plus the sum of the selected routed experts) each output a 5120-dimensional vector, which is added to the four residual streams. Three kinds of matrices produce these vectors last.

The edited matrices output no component along u.

The method is the same as in my previous model, Qwen3.8-Flash-Next q8g.

Why the routed experts were not edited

Each layer has 384 routed experts, stored in formats of about 2 bits such as IQ1_M. Abyss assumes that all 384 experts in a layer share the same format. Editing them would mean requantizing about 1GB per layer, so I left them out this time. In the original model, 28% of the difference between harmful and ordinary requests in the vectors added to the residual stream comes from the routed-expert output (Figure 5 in the development history).

Procedure

Recording layer outputs

• Prompts: the first 200 of the train split of mlabonne/harmful_behaviors (harmful) and of mlabonne/harmless_alpaca (ordinary). The same prompts as for Qwen3.8-Flash-Next q8g
• The original model answered each prompt to the end with reasoning on, and the attention output and shared-expert output of every layer were recorded
• The reasoning was split by length into 10 segments, and tokens were averaged within each segment
• This took about 2 hours 10 minutes on one RTX 5090

Finding the direction

1. Combine the means of segments 1 to 4, weighted by the number of tokens in each segment
2. For each layer, subtract the mean of ordinary requests from the mean of harmful requests and normalize to length 1
3. Orthogonalize the direction against the mean of ordinary requests at five positions (prompt mean, start and end of the reasoning, start and end of the answer)

Criteria for choosing layers to edit

Only layers meeting both of the following were edited.

• d′ of 3.0 or more
• Leave-one-out classification accuracy of 95% or more

d′ measures how well harmful and ordinary requests separate; larger means better separation. The 400 prompts are split randomly in half, and the direction is found on one half. For the other half, each layer's output is projected onto that direction. The difference between the mean projections of harmful and ordinary requests is divided by the square root of the mean of their variances. This is averaged over three different splits.

In leave-one-out classification, the direction and the mean projections of harmful and ordinary requests are found from the remaining 399 prompts. The held-out prompt is classified as harmful if its projection lies on the harmful side of the midpoint between the two means.

Editing the weights

1. Read the 68 tensors (Q5_K) and dequantize them to floating point
2. Compute W' = W − u uᵀW (strength 1.0)
3. Write them as Q8_0 to overlay-00001 (31.8 seconds on CPU)
4. The component along u left in the written weights was within ±0.0001

Comparison with other published models

Table 5. How the other published models and this model were made

Ordinary requests: requests with no reason to refuse, such as those in harmless_alpaca. Strength 1.0 sets the component along the direction to zero; 2.0 flips its sign. Values for the other published models are as stated in each card. Edited layers are stated only in the Harsha001 and Abiray cards, and strength only in the AtomicChat and Harsha001 cards.

---

◼︎ 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

Details

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

Details

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

Details

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

Details

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

Details

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. For the T1–T4 bundle, this is the author's use after the edit was written into the weights (see "The author's hands-on use in OpenCode").

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

Details

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: Abyss recommended; also in upstream llama.cpp's six-shard layout

This model was made and evaluated entirely on Abyss, so Abyss is recommended. ISTA-DASLab switched to upstream llama.cpp's six-shard layout, and this model now follows it. It was checked to run on llama.cpp b12032, Abyss v1.3.91 and Strata v0.2.10.

Use with Abyss

Download (about 250GB) and build a launch pack in the Abyss folder. Shard 6 is the Engram file, so it is linked to the fixed name.

hf download rSalone/DeepSeek-V4.1-Flash-1017-GSQ-RCO-uncensored-t1-4-GGUF \
  --include "*-uncensored-t1-4-*-of-00006.gguf" "DeepSeek-V4.1-Flash-Engram-IQ4_NL.gguf" --local-dir <DSF>
cd <DSF>
M=DeepSeek-V4.1-Flash-1017-GSQ-RCO-IQ2_XXS-uncensored-t1-4
ln -s DeepSeek-V4.1-Flash-Engram-IQ4_NL.gguf $M-00006-of-00006.gguf
cd <path to Abyss-1.3.91>
python tools/iq_pack.py --compat-bf16 --gguf <DSF>/$M-00001-of-00006.gguf --out <DSF>/pack

The pack records absolute file paths, so write <DSF> as an absolute path. Start Abyss with these settings.

{
 "exe": "<path to Abyss-1.3.91>/build/strata",
 "args": ["--glm-pack", "<DSF>/pack", "--max-context", "262144", "--prefill", "auto"],
 "cwd": "<path to Abyss-1.3.91>",
 "tokenizer": "<DSF>/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"
 }
}

Use with llama.cpp

Download and link as above, then pass shard 1 to -m.

cd <DSF>
M=DeepSeek-V4.1-Flash-1017-GSQ-RCO-IQ2_XXS-uncensored-t1-4
llama-server -m $M-00001-of-00006.gguf -c 65536 --jinja

Use with Strata

Strata's setup and launch --model-path check ISTA-DASLab's file names and SHA-256. This model's files have edited weights, so they do not pass the check. Instead, build the pack by hand in the Strata folder and write the launch config by hand.

cd <path to Strata-0.2.10>
M=DeepSeek-V4.1-Flash-1017-GSQ-RCO-IQ2_XXS-uncensored-t1-4
python3 tools/dsv41/pack_gguf.py --model <DSF> \
  --shards $M-0000{1,2,3,4,5}-of-00006.gguf \
  --engram <DSF>/DeepSeek-V4.1-Flash-Engram-IQ4_NL.gguf \
  --dspark-gguf <path>/dspark-DeepSeek-V4.1-Flash-1017-Q8_0.gguf \
  --out <DSF>/strata-pack

Pass only shards 1 to 5 to --shards, and pass the Engram file itself (the sixth shard) to --engram. --dspark-gguf is the drafter for speculative decoding (dspark-DeepSeek-V4.1-Flash-1017-Q8_0.gguf from unsloth/DeepSeek-V4.1-Flash-1017-GGUF).

The launch config and the launch command:

{
 "exe": "<path to Strata-0.2.10>/build-dsv41/strata-dsv41",
 "args": ["--pack", "<DSF>/strata-pack", "--max-context", "65536", "--eos", "1",
          "--dspark", "auto", "--dspark-conf", "0.65", "--ssd-cache", "85"],
 "cwd": "<path to Strata-0.2.10>",
 "tokenizer": "<DSF>/strata-pack/tokenizer",
 "model_name": "dsf-t1-4-iq2xxs",
 "arch": "deepseek41",
 "port": 8098,
 "gpu": 0
}

.venv/bin/python serve/server.py --engine strata --config <the json above> --port 8098

This procedure was checked on Strata v0.2.10. It does not create expert-profile.bin (the table of the most-used experts) that setup makes.

The earlier layout's files (Abyss only) are still here and work as before.

Earlier layout with Abyss

Download only the earlier layout's files (about 249GB).

hf download rSalone/DeepSeek-V4.1-Flash-1017-GSQ-RCO-uncensored-t1-4-GGUF \
  --include "overlay-*" "engram-IQ4_NL.gguf" "pack/*" "mmproj-BF16.gguf" "exp_probs_b_vl.f32" --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"
 }
}

Settings for image input (Abyss v1.3.93 or later)

{
 "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
 }
}

With the same weights, I confirmed that the model answers text and image questions correctly (images processed on CPU). However, image input with this repository's file layout as is has not been tried yet.

How the six-shard layout was made and checked

On October 27, 2026, ISTA-DASLab switched its quantized files to the layout of upstream llama.cpp (b11870 or later). This model was made from the files before the switch (commit 653a9874aa38c356233c5f3cc8c96b19a43b57eb), so llama.cpp could not load it. The six-shard layout was made in two steps.

1. In the original four shards, the 68 edited tensors were replaced with their edited values. In the earlier layout, the 68 edited tensors are in both overlay-00001 and the original weights, and Abyss uses overlay-00001, which it reads first. The conversion script and llama.cpp do not expect two tensors with the same name, so the set was made into one first
2. ISTA-DASLab's conversion script (convert_ds41_upstream.py) converted it to the six-shard layout, and the model name (general.name) was changed to this model's name

The following was checked on the files made.

• The 940 unedited tensors are byte-identical to the original files
• The 68 edited tensors match the earlier layout's values
• Against ISTA-DASLab's six-shard files, tensor names, shapes and the split into six shards match. Only the 68 edited tensors differ in type
• On Abyss, comparing next-token distributions with the earlier layout gave a mean KL divergence of 0.00106, with the most likely token agreeing at 98.84% (16,025 positions in 10 capability problems). Two runs of the earlier layout against each other gave KL 0 and 100% agreement
• This difference comes from the conversion to the six-shard layout. Converting ISTA-DASLab's unedited original files the same way and comparing them gave the same size of difference: a mean KL of 0.00104 and 98.75% agreement. Which part of the conversion causes it has not been examined yet
• The effect of the weight edit is unchanged. The KL against the original model is 0.00577 in the earlier layout and 0.00571 in the six-shard layout

Table 8. Files in this repository

… stands for DeepSeek-V4.1-Flash-1017-GSQ-RCO-IQ2_XXS-uncensored-t1-4.

---

◼︎ 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
• The six-shard layout was checked on llama.cpp b12032, Abyss v1.3.91 and Strata v0.2.10. On each, it answered six general questions sensibly, answered every harmful request (10 on Abyss, 3 on the others) and solved every MATH problem (5 on Abyss, 2 on the others). llama.cpp and Strata got fewer problems because they take longer
• 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

---

◼︎ References

Method

• Arditi et al. (2024), Refusal in Language Models Is Mediated by a Single Direction: the paper behind abliteration. It takes the refusal direction as the difference of mean activations between harmful and harmless prompts and removes it from the weights.
• mlabonne, Uncensor any LLM with abliteration: an introduction to abliteration.
• rSalone/Qwen3.8-Flash-Next-GSQ-RCO-uncensored-q8g-GGUF: my previous model. The weights were edited the same way as in this model.

Models

• Base 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). The six-shard layout was made with that repository's conversion script convert_ds41_upstream.py.
• Drafter for Strata: dspark-DeepSeek-V4.1-Flash-1017-Q8_0.gguf from unsloth/DeepSeek-V4.1-Flash-1017-GGUF
• Judge: rSalone/Qwen3.8-Flash-Next-GSQ-RCO-uncensored-q8g-GGUF, run on Strata.
• Other published models compared (built from the same ISTA-DASLab files): DeepSeek-V4.1-Flash-1017-Uncensored-GSQ-RCO-GGUF by AtomicChat, DeepSeek-V4.1-Flash-1017-Uncensored-GSQ-RCO-StrixHalo-GGUF by Harsha001, DeepSeek-V4.1-Flash-1017-Uncensored-GSQ-RCO-IQ2_XXS-GGUF by Abiray

Datasets and benchmarks

• Refusal direction: mlabonne/harmful_behaviors, mlabonne/harmless_alpaca
• Harmful requests (MaliciousInstruct): paper arXiv:2310.06987, repository Princeton-SysML/Jailbreak_LLM
• Over-refusal test (XSTest): paper arXiv:2308.01263, dataset natolambert/xstest-v2-copy
• MATH Level 5 (50 problems): paper arXiv:2103.03874, dataset EleutherAI/hendrycks_math
• Level 5 of MATH-500 (the 10 problems for the KL divergence and the candidate comparison): paper arXiv:2305.20050, dataset HuggingFaceH4/MATH-500

Software

• Inference engines: Abyss, llama.cpp, Strata
• Hands-on tasks and the image-generation request: OpenCode, ComfyUI

Thank you to everyone who published these.