---
license: apache-2.0
base_model:
  - HauhauCS/Qwen3.5-27B-Uncensored-HauhauCS-Aggressive
  - Qwen/Qwen3.5-27B
  - dnhkng/RYS-Qwen3.5-27B-FP8-XL
tags:
  - qwen3.5
  - uncensored
  - RYS
  - GGUF
  - coding
  - reasoning
  - imatrix
language:
  - en
pipeline_tag: text-generation
model_type: qwen3_5
quantized_by: jackasda211233
---

# Qwen3.5-27B-Uncensored-RYS-Reasoner-GGUF

## Related code

- Specialized inference/runtime fork for this deployment: [noonr48/rys-splice-ik-llama](https://github.com/noonr48/rys-splice-ik-llama)
- The recent fastpath benchmarking documented there was run on **three RTX 3090s**.
- **Experimental benchmark note:** that inference comparison is an experimental, session-specific result from one three-RTX-3090 deployment and should be treated as directional rather than a broad performance guarantee.

### Recent experimental inference benchmarks

| Runtime / mode | Model used | Split mode | Prompt speed | Decode speed |
| --- | --- | --- | ---: | ---: |
| baseline `ik-llama` | custom RYS splice GGUF | `graph` | 87.6 tok/s | 44.4 tok/s |
| `ik-llama` + `--rys-splice-fastpath` | custom RYS splice GGUF | `graph` | 91.6 tok/s | 56.7 tok/s |
| base `llama.cpp` | mainline sibling GGUF | `layer` | 127.8 tok/s | 38.1 tok/s |

The first two rows are the direct same-deployment comparison on the custom model. The `llama.cpp` row is included as a useful reference on the same three-RTX-3090 machine, but it is **not perfectly apples-to-apples** because upstream `llama.cpp` used the sibling mainline GGUF and `split-mode layer` rather than the custom GGUF with `split-mode graph`.

An uncensored, coding-focused Qwen3.5-27B with RYS (Repeat Your Self) layer duplication, built via a novel **splice method** and quantized with a **custom reasoning-focused importance matrix**.

## Why This Model Exists

### The Censorship Problem

Over the past several years, the author has observed a consistent trend of **increasing censorship across all major model releases** — particularly in domains where unrestricted knowledge is most critical: biology, legal studies, and medicine. This model is an attempt to push back against that trend — a smaller model that aims to be more capable than the already remarkable Qwen3.5-27B base, without the artificial knowledge restrictions.

### The Original RYS Experience

The original RYS-Qwen3.5-27B by [dnhkng](https://github.com/dnhkng) was exceptional as a coding agent. In the author's experience over 40+ hours of comparative usage against GPT-5.3 Codex on a complex multi-service project (a custom agent OS with a vault messaging app, webhook bridge, and multi-agent backend), dnhkng's RYS model identified and fixed deep architectural bugs that Codex missed entirely — such as silently misdirected conversation routing between the vault app and the backend, where messages were being sent to a dead webhook port while the actual agent bridge was running on a different service.

However, even the original (censored) RYS model and the standard Qwen3.5-27B exhibited a frustrating pattern: when asked to fix issues in existing infrastructure, the model would silently attempt to create an entirely new backend or service rather than modify the pre-existing one. This model eliminates that friction.

### Previous Attempt & Lessons Learned

An earlier version of this uncensored RYS model was released prematurely. While that version performed well conversationally, **it failed as a coding agent** — calling wrong tools, making poor file edits. This release is the proper replacement with verified tool calling, decreased looping, and proper code generation.

### Technical Motivation

The standard Qwen3.5-27B's safety guardrails actively interfere with legitimate development:
- **SSH/Network access refusal** — refuses to SSH into the user's own machines
- **Memory system avoidance** — avoids implementing persistent memory
- **API integration refusal** — hesitates on webhook endpoints, external services
- **Tool calling interference** — malformed or incomplete tool invocations

This model is designed as a **coding agent model** for use with Claude Code, OpenCode, claw-code, Qwen-Agent, or any OpenAI-compatible scaffold.

## Disclaimer & Responsible Use

> ⚠️ **Uncensored Model:** As far as the author can determine, this model is completely uncensored when prompted with appropriate system instructions. By default, the model will not produce highly graphic or explicit material unless the system prompt specifically instructs it to do so.
>
> **The author is not responsible for how this model is used.** Any actions taken are solely the responsibility of the user. Use in accordance with applicable laws and ethical standards.

## Representative Live Test

The model autonomously built a complete AI/ML news aggregator:

- **26KB FastAPI backend** with 4 live API integrations (GitHub, Reddit, HuggingFace, ArXiv)
- **25KB dark-theme SPA frontend** (881 lines, search, filters, cards, bookmarks)
- **SQLite database** with 175 items persisted from live API fetches
- **Setup & test scripts** — venv, deps, 9 endpoint tests
- **Self-corrected** 3 tool format errors autonomously
- **Zero loops** across ~70k token generation at 256k context

Tested via [claw-code](https://github.com/ultraworkers/claw-code) agent framework (required patching `reasoning_content` support for OpenAI-compatible streaming — see our fork).

Testing environment: [OpenCode](https://github.com/opencode-ai/opencode) on Arch Linux with root access. Primary runtime testing used ik-llama.cpp with the build info below and the current recommended parameters from this README.

## Available Files

| File | Quant | Size | Description |
|------|-------|------|-------------|
| `RYS-Qwen3.5-27B-Uncensored-Splice-BF16.gguf` | BF16 | 56 GB | Full precision reference |
| `RYS-Qwen3.5-27B-Uncensored-Splice-IQ4_NL-ik-llama.gguf` | IQ4_NL | 17 GB | **Author's personal driver / primary recommendation** — quantized for ik-llama.cpp, tested the most |
| `RYS-Qwen3.5-27B-Uncensored-Splice-IQ4_NL-llama.cpp-compatible.gguf` | IQ4_NL | 17 GB | Standard llama.cpp-compatible build made from the same BF16 source and custom imatrix |

### Which IQ4_NL should you use?

- **Use `RYS-Qwen3.5-27B-Uncensored-Splice-IQ4_NL-ik-llama.gguf` if you run ik-llama.cpp.** This is the author's actual daily driver and the variant that will continue receiving the most real-world testing.
- **Use `RYS-Qwen3.5-27B-Uncensored-Splice-IQ4_NL-llama.cpp-compatible.gguf` if you run standard llama.cpp or a frontend built on it.**

> **Footnote:** The `ik-llama` build is not a uniform IQ4_NL quant. It uses a mixed tensor layout: mostly `iq4_nl`, plus a small number of higher-precision tensors (`iq5_k` / `q6_K`). The `llama.cpp-compatible` build is also mixed, but uses mainline-supported tensor types instead (`q5_K` / `q6_K`).

## Why IQ4_NL is Recommended Over BF16, Q8, and Q6

This is not typical. In the author's tested coding / agent workloads, the **preferred IQ4_NL quantization with custom importance matrix consistently outperformed Q8_0, Q6_K, and full-precision BF16**:

1. **Quantization acts as a regularizer** — slight weight rounding prevents degenerate thinking loops that BF16 and Q6_K are prone to
2. **Custom imatrix preserves reasoning weights** — 30% reasoning/self-verification calibration data ensures chain-of-thought and self-correction weights are preserved
3. **Half the size, better results** — 17GB vs 56GB, fits on a single 24GB GPU

### How IQ4_NL Was Chosen

Multiple quantization variants were tested on the same real-world task: building a full-stack AI/ML news aggregator (AI Radar) from a single prompt, using [claw-code](https://github.com/ultraworkers/claw-code) as the agent framework. The project required 4 live API integrations (GitHub, Reddit, HuggingFace, ArXiv), a FastAPI backend, SQLite database, dark-theme SPA frontend, and automated test suite — all at 256k context.

**Real-world project results (same prompt, same model, different quants):**

| Variant | Project Completed | Database Persisted Data | Self-Corrected Errors | Loops | Verdict |
|---------|-------------------|------------------------|----------------------|-------|---------|
| **IQ4_NL + custom imatrix + F16 KV** | **✅ 7 files** | **✅ 175 items from live APIs** | **3 (all recovered)** | **0** | **Best** |
| Same IQ4_NL + wiki imatrix + F16 KV | ❌ 0 files | — | 10 (never recovered) | 10+ looping write attempts | Failed |
| Same model + any quant + BF16 KV | ❌ 0 files | — | — | Looped on basic commands | Failed |

The IQ4_NL with custom imatrix was the **only variant that produced working database persistence** — all other variants had bugs in async database writes that prevented data from being saved. The custom imatrix preserves the model's self-correction behavior ("wait, that's wrong, let me fix it") that standard calibration destroys at this quantization level.

**Supporting evidence: 5 automated coding problems (merge intervals, LCS, RPN evaluator, valid parentheses, trapping rain water) tested at both temperature 0.6 and 0.8 — IQ4_NL with custom imatrix scored 5/5 at both temperatures.** BF16 and Q6_K both entered infinite thinking loops on the same problems.

For clarity: the results above come from the **ik-llama.cpp-oriented IQ4_NL build**, which remains the author's primary recommendation. A separate standard llama.cpp-compatible IQ4_NL build is provided for portability.

## Critical: KV Cache Recommendations

| KV Cache | Recommended Use | Notes |
|----------|-----------------|-------|
| **F16** | **Default up to ~160k context** | Best balance of stability, speed, and VRAM in current testing |
| **F32** | **Recommended above ~160k context** | Most stable option for very long context; the author has consistently reached ~220k before compression |
| BF16 | Avoid | Unstable in current testing; more prone to loops and degraded instruction following |

For this model and for the base Qwen3.5-27B family more broadly, **BF16 KV cache appears unstable** in llama.cpp-family runtimes. In current testing, **F16 KV cache works reliably up to roughly 160k context**, while **F32 KV cache is recommended beyond that** if you want maximum stability.

**Subjective observation:** F32 KV cache often completed similar tasks with fewer output tokens and showed better instruction following than BF16, and in some cases better than F16 as well.

If you are pushing long context, prefer:
- `--cache-type-k f32 --cache-type-v f32`

If you want the best general balance at moderate context lengths, use:
- `--cache-type-k f16 --cache-type-v f16`

Qwen3.5 support in llama.cpp-family runtimes is still moving quickly. If you hit compatibility issues, use the newest available build first.

## Custom Importance Matrix

The IQ4_NL uses a custom-built imatrix — not standard wiki calibration. This is the single biggest quality factor.

**Calibration dataset (English only):**

| Content | Weight | Purpose |
|---------|--------|---------|
| Reasoning & self-verification | 30% | Math proofs with ✓/✗ checks, debugging narratives, self-correction, algorithm tracing |
| Code (Python, JS, Bash) | 25% | Multi-file projects, test suites, error handling |
| Academic papers (broad) | 15% | ArXiv + PubMed across all fields |
| Instruction/agent prompts | 15% | Terse multi-step commands, agentic style |
| Infrastructure/sysadmin | 10% | systemd, SSH, GPU config, shell |
| General English | 5% | Wiki baseline |

**What the imatrix specifically targets:**

The 30% reasoning/self-verification block is calibrated to preserve the weights responsible for:
- **Prolonged chain-of-thought** — sustaining coherent multi-step reasoning across thousands of tokens without degradation
- **Self-correction** — the ability to recognize "wait, that's wrong" mid-generation and backtrack
- **Verification loops** — tracing through algorithms step-by-step with explicit ✓/✗ checks ("Test case 1: expected X, got X ✓")
- **Knowing when to stop thinking** — concluding a `<think>` block and producing output instead of looping indefinitely
- **Never assuming** — the model should verify, not guess. The calibration data includes debugging narratives that explicitly check each assumption

The code/instruction blocks preserve:
- **Multi-file project architecture** — maintaining coherence across 1000+ line codebases
- **Tool call formatting** — precise JSON parameter construction for agent frameworks
- **Direct instruction parsing** — understanding terse, multi-step commands without needing hand-holding

**English-only calibration** — the entire imatrix dataset is English. Qwen3.5-27B supports 200+ languages, but this model's calibration deliberately reallocates precision from unused multilingual weights to English reasoning, code generation, and instruction following. If you need multilingual output, this quant is not optimized for it — use the BF16 instead.

Standard wiki-only calibration under-represents ALL of the above patterns because wiki text contains none of them. The result: standard-calibrated quants lose self-correction first (causing infinite thinking loops), then lose tool call precision, then lose code coherence — in that order.

## llama.cpp Compatibility Note

There are now **two** IQ4_NL releases because the original custom quant and the new mainline-compatible quant are not identical artifacts.

### What happened?

The original IQ4_NL quant was built for **ik-llama.cpp** and some users loading it in standard llama.cpp / llama.cpp-based frontends hit this error:

```text
gguf_init_from_file_ptr: tensor 'blk.3.attn_v.weight' has invalid ggml type 140
```

That failure was **not** caused by KV cache format. It was a model-file compatibility issue.

### What changed?

To fix that, the author rebuilt a second IQ4_NL release directly with **standard llama.cpp's `llama-quantize`**, using the same BF16 splice source and the same custom calibration/imatrix:

- BF16 source: `RYS-Qwen3.5-27B-Uncensored-Splice-BF16.gguf`
- imatrix: `splice_custom.imatrix`
- imatrix dataset: `calibration_custom.txt`
- imatrix stats: `558` entries over `2151` chunks

The resulting standard llama.cpp-compatible file still uses a mixed quant layout, but one that **mainline llama.cpp can load successfully**:

- `iq4_nl`: 487 tensors
- `q5_K`: 72 tensors
- `q6_K`: 1 tensor

### Recommendation

- **ik-llama.cpp users:** use the `-ik-llama` file
- **standard llama.cpp users:** use the `-llama.cpp-compatible` file

The author still personally recommends the **ik-llama** build because that is the day-to-day driver and the one that will be exercised the most in live coding / agent workloads.

Both IQ4_NL releases are mixed quants. The key difference is that the `ik-llama` build uses ik-specific tensor types, while the `llama.cpp-compatible` build uses mainline-supported tensor types.

## Recommended Parameters

These are the **current best test parameters** for this repo so far:

```bash
llama-server \
  -m RYS-Qwen3.5-27B-Uncensored-Splice-IQ4_NL-ik-llama.gguf \
  -ngl 99 -c 262144 \
  --cache-type-k f16 --cache-type-v f16 \
  --cache-ram 30720 \
  --flash-attn on \
  --jinja --reasoning-format deepseek \
  --temp 0.7 --top-p 0.95 --top-k 20 \
  --min-p 0.0 --repeat-penalty 1.0
```

For contexts above ~160k, consider switching the KV cache to F32:
- `--cache-type-k f32 --cache-type-v f32`

Avoid BF16 KV cache in current llama.cpp-family builds.

For the standard llama.cpp-compatible quant, simply swap the filename to:

```bash
RYS-Qwen3.5-27B-Uncensored-Splice-IQ4_NL-llama.cpp-compatible.gguf
```

## How It Was Built

### Splice Method

```
Layers  0–25:  HauhauCS Uncensored weights (26 layers)
Layers 26–41:  dnhkng's RYS-XL layers (FP8→F16→BF16, 16 layers = 8 duplicated)
Layers 42–71:  HauhauCS Uncensored weights (30 layers)
```

78% uncensored layers. Built via direct GGUF→GGUF splice — no safetensors conversion.

### Source Models

- **[Qwen/Qwen3.5-27B](https://huggingface.co/Qwen/Qwen3.5-27B)** — Base architecture (Apache 2.0)
- **[HauhauCS/Qwen3.5-27B-Uncensored-HauhauCS-Aggressive](https://huggingface.co/HauhauCS/Qwen3.5-27B-Uncensored-HauhauCS-Aggressive)** — 78% of layer weights
- **[dnhkng/RYS-Qwen3.5-27B-FP8-XL](https://huggingface.co/dnhkng/RYS-Qwen3.5-27B-FP8-XL)** — 22% of layer weights (duplicate zone)
- **[dnhkng/RYS](https://github.com/dnhkng/RYS)** — Method & research ([Blog](https://dnhkng.github.io/posts/rys-ii/))
- **[ikawrakow/ik_llama.cpp](https://github.com/ikawrakow/ik_llama.cpp)** — Quantization tooling

## Tested Runtimes / Builds

Primary validation for this release used **ik-llama.cpp**, mainly because its **graph split** is a major performance boost on multi-GPU systems compared to standard layer split.

### ik-llama.cpp (author's primary runtime)

| Field | Value |
|-------|-------|
| Version | 61 (`0147cf4`) |
| Git Commit | `0147cf4` - "Add additional explanations to the pinned memory log" |
| Compiler | GCC 15.2.1 (20260103) |
| Build Type | Release |
| CUDA | ON |
| Flash Attention | ON (`GGML_CUDA_FA_ALL_QUANTS`) |
| Build Date | Apr 5, 2026 |

The author uses ik-llama because graph split performs much better on multi-GPU setups. It remains the author's **personal daily driver** and the variant that will receive the most testing.

### standard llama.cpp (used for the new compatibility build)

The new `RYS-Qwen3.5-27B-Uncensored-Splice-IQ4_NL-llama.cpp-compatible.gguf` was created and tested with standard llama.cpp using:

| Field | Value |
|-------|-------|
| Binary | `/home/benbi/llama.cpp/build/bin/llama-server` |
| Quantizer | `/home/benbi/llama.cpp/build/bin/llama-quantize` |
| Build string | `build: 8401 (a69d54f99) with GNU 15.2.1 for Linux x86_64` |
| CUDA archs reported | `ARCHS = 860,1200` |
| CUDA | ON |
| Flash Attention | ON |

In either runtime, **use the latest available compile/build when testing**.

## Vision Compatibility

Qwen3.5 is a multimodal family, but **mmproj was not part of the validation for this release**. The author has not done proper testing to confirm whether vision works on this splice, so vision support should currently be treated as **unverified**.

## Citation

```bibtex
@misc{qwen3.5,
  title = {{Qwen3.5}: Towards Native Multimodal Agents},
  author = {{Qwen Team}},
  year = {2026},
  url = {https://qwen.ai/blog?id=qwen3.5}
}

@misc{dnhkng_rys,
  title = {LLM Neuroanatomy II},
  author = {dnhkng},
  year = {2025},
  url = {https://dnhkng.github.io/posts/rys-ii/}
}
```