license: other
license_name: swift-open-license-1.0
base_model: d0xin/Swift-1.5-Qwen3.8-27B-Uncensored-BF16
base_model_relation: quantized
library_name: llama.cpp
pipeline_tag: text-generation
datasets:
- jakeatx/qwen3.8-27b-Swift1.5-Uncensored-ATX-AI2-LCB-KLD
tags: - gguf
- quantized
- qwen3.8
- swift-1.5
- uncensored
- abliterated
- mtp
- 12gb
Swift 1.5 Qwen3.8-27B Uncensored, ATX AI2 (about 2.3 bits per weight, with MTP)
Our best 2.3-bit build of Swift 1.5. It replaces
ATX-Swift-1.5-Qwen3.8-27B-Uncensored-2.3bpw-MTP-GGUF, which is deprecated.
| Artifact | Details |
|---|---|
qwen3.8-27b-Swift1.5-Uncensored-ATX-AI2.gguf |
9.14 GB (9,138,303,264 bytes), SHA-256 d4b73c62641f83aa3f742b683d89b9285d36b434dc1f1aeac931a6ef6af91c20 |
Results
All numbers were measured on this exact file. Raw per-problem and per-position data: jakeatx/qwen3.8-27b-Swift1.5-Uncensored-ATX-AI2-LCB-KLD.
Quality against the BF16 model (KLD, lower is better). 16,200 token positions, equal weight to coding, agentic and retrieval-style text:
| Model | Pooled KLD | Coding | Agentic | Retrieval |
|---|---|---|---|---|
| This model | 0.0594 | 0.0628 | 0.0686 | 0.0467 |
| Mirai S, 2.4 bit (community llama.cpp port) | 0.0745 | 0.0734 | 0.0844 | 0.0657 |
| Our earlier 2.3-bit build (different bit plan) | 0.0794 | 0.0837 | 0.0899 | 0.0646 |
It is lowest on all three task types. Mirai's build supports only an fp16 KV cache, so Mirai was scored with fp16 KV and this model with our 4-bit KV cache; controls show the KV type moves KLD by about 0.2%, far less than these gaps. KLD compares each quant with its own BF16 source, so it measures drift, not which base model is better. Details are in the dataset card.
LiveCodeBench v6 (100 problems, 3 runs each, temperature 1.0, reasoning effort xhigh, no output cap other than the context window):
| Grader | Score |
|---|---|
| Strict (same grader as our earlier results) | 84.3% (253/300) |
| Fixed (also accepts alternative correct forms on special-judge problems) | 88.3% (265/300) |
For context: our 4.56 bpw Swift IQ4_XS-M scored 89.25% on the same problems in an earlier run, and Qwen publishes 90.3% for BF16. The 2.3-bit build deprecated above reported 77.7% pooled over 7 runs on 12 GB cards in a different setup, so that is not a paired comparison.
Not a statistically significant gain over our previous best 2.3-bit build. That build scored 82.7% on the same 100 problems; the difference is +1.7 points (95% range -1.7 to +5.0, paired p = 0.46). Over an earlier 2.3-bit build (75.3%) the gain is +9.0 points (p = 0.003). We report this file as our best 2.3-bit quality because it has the lowest KLD and the highest LiveCodeBench score of the 2.3-bit builds we measured, but on LiveCodeBench alone we cannot separate it from the previous best. 9 of the 300 answers hit the length limit and count as failures.
How it was made, and what was not done
- Natively encoded from the Swift 1.5 BF16 checkpoint in our AI+ format. Each tensor uses 2, 2.5, 3, 4 or 5 bits chosen for how much it matters; no Mirai weights are included.
- After encoding, we ran a short, limited healing step. All quantized codes stayed frozen. Only the fp16 scales that are already in the file and the RMSNorm weights were adjusted (about 28.6 million numbers out of 27 billion), by matching the BF16 model's own activations and output probabilities. That healing took the KLD from 0.0676 to 0.0594 (12% lower).
- This is not coding post-training. The calibration text was small and mixed: fresh prompts we wrote in three families (coding, agentic investigation, retrieval-style reading), answered by the BF16 model, plus a small sample of public text (FineWeb-Edu, WikiText-103, GSM8K questions). No LiveCodeBench problems were used, the KLD test text was excluded, and 10% of the calibration text was held out to stop early. Keeping the training this narrow limits the risk of overfitting to any benchmark.
- File size, tensor layout and speed are unchanged by the healing step.
Size: 2.319 bits per weight for the main model, output head and MTP draft layer (about 7.79 GB). The 1.35 GB token embedding table is stored in Q8_0 and lives in system RAM, so that figure does not include it. This is a little above the 2.30 bpw target we aimed for.
The GGUF contains the text model and the MTP draft layer. It does not contain the vision tower. This is an uncensored, refusal-reduced derivative of UkisAI's Swift 1.5, built on Qwen3.8-27B.
Runtime: needs a newer llamAmpere than v0.6.1.1
This file uses tensor types from our AI+ format, including a 2.5-bit fractional type (type id 118) that llamAmpere v0.6.1.1 and earlier do not know. They will refuse to load it. It needs llamAmpere v0.6.2 or later (release pending). Stock llama.cpp will not load it either. llamAmpere targets NVIDIA Ampere (RTX 30-series) cards.
The LiveCodeBench scores above were measured with this server configuration, on a 48 GB card with 2 parallel slots and 262,144 tokens of context each (use a smaller -c on smaller cards):
llama-server -m qwen3.8-27b-Swift1.5-Uncensored-ATX-AI2.gguf \
-c 524288 --parallel 2 -b 4096 -ub 1024 -ngl 99 -fa on -fit off \
--no-context-shift --cache-ram 0 --jinja \
-ctk sjkvarn4 -ctv sjkvarn4 \
--spec-type draft-mtp-adaptive --spec-draft-n-min-adaptive 3 \
--spec-draft-n-max 3 --spec-draft-p-min 0 --spec-mb-mtp
We have not yet published a tested configuration for 12 GB cards with this file.
License
Swift Open License 1.0, inherited from Swift 1.5; see LICENSE, LICENSE-APACHE-2.0 and NOTICE.