Technology

A post-trained Qwen 3.8 27B model was trained to be more efficient by identifying which tokens were linked to overthinking and penalizing them without directly "attacking" the reasoning length. Accuracy was then restored using a technique hinted to be On-Policy Distillation. The result was -58% thinking tokens, 1.95x speed up, and <1% accuracy loss, and the model was open-sourced for community feedback.

The model is available here: https://huggingface.co/ukisai/Swift-Qwen3.8-27b [1]

A GGUF [3] version (Q1-Q8) is also available, along with several community quants (Bartowski) [4] at even lower/higher precision. The community also created NVFP4, W4A16, and Uncensored [5] versions of the model on Huggingface.

This training approach is not a replacement for reasoning effort settings, chat templates, or token caps, but is complementary and targets a separate issue: overthinking and "anxiety-like" reasoning loops previously seen in PTQ, but also identified as prominent in BF16 models of this size class. Contrary to popular belief, these specific patterns do not contribute to answer quality when properly targeted. The thesis is that reasoning length is extremely important and should not be shortened by force, but rather optimized. This is demonstrated in the xhigh vs medium effort benchmark table below. The goal is to keep xhigh accuracy while reducing only the unnecessary part of thinking.

TLDR of the thought process, research, training, and benchmarks:

1. When running quantized Qwen 3.8 27B instances, random reasoning loops (referred to in the paper below as "overthinking errors") were a persistent annoyance. These random loops were persistent throughout medium and low reasoning settings.
2. A paper by Meta [6] was identified that is supposed to target this phenomenon in PTQ, but when used straight out of the box it produced mixed results.
3. The hypothesis was tested as to whether it was a matter of targeting the right keywords and tuning the parameters, so a large amount of different (out of distribution) domain (coding, language, vision, agentic) traces were generated using an 8xH100 box.
4. The traces with overthinking were grouped and "common denominator" tokens between them were found, targeting the most prominent ones.
5. An inference-time penalizer of those tokens was built as seen in the paper, with the hopes of simply generating traces and doing cross-entropy SFT over them.
6. This did not work at all, but the penalizer seemed to work much better than the tokens provided in the paper, and not only for lower precision models but for bf16 as well. Hence experimentation continued. A loss function was built using the identified tokens and LoRa SFT was run over the previously generated traces; reasoning seemed to fall off significantly but accuracy seemed to follow. The reasoning reduction seemed to generalize.
7. After a significant amount of tinkering (since the day of Qwen 3.8 27B release), the reasoning reduction was satisfactory. After that, ways of restoring accuracy were searched. Several methods were experimented with, including RL(GSPO), On-Policy Distillation, and using the ThinkingCap 3.6 27B adapter chunks, until the accuracy loss was satisfactory. It was restored to <1% loss on almost all OOD in-house tests.
8. Intensive benchmarks were then performed across several reasoning efforts, precision variants, etc. A few problems were encountered, one of which was that to get a reliable score, each benchmark needed to be run 10x (5x on base + 5x with the adapter, following the standard procedure on the Qwen 3.6 27B model card on Terminal Bench). After running it, the performance converged to 40-60% token reduction with <1% accuracy loss across GPQA, MMLU, Terminal Bench 2.1, LiveCodeBench v6, ERQA, C-Eval, IFBench, and HMMT25, with an exception being AIME26 with an accuracy loss of 4.6%, which was later linked to a bug during training with a specific token relevant for math-related reasoning being penalized. This is planned to be fixed in an updated release.

The benchmarks: (raw benchmark files here - https://github.com/UkisAI/Swift-Qwen3.8-27B-evals/ ) [7]

Swift-27B vs Qwen3.8-27B (BF16, all benchmarks ran x5, thinking effort xhigh)

| Benchmark | Qwen3.8-27B | Swift-27B | Median tokens | |

|

|

|

| | GPQA-Diamond | 88.4% | 88.3% | 58% fewer | | LiveCodeBench v6 | 76.8% | 81.6% (+4.8pp, due to default truncation in LCB it is not performance gain) | 46% fewer thinking tokens | | Terminal-Bench 2.1 | 66.7% | 65.8% | 39% fewer | | MMLU-Pro | 85.5% | 85.0% | 28% fewer | | C-Eval | 90.0% | 90.6% | 19% fewer | | IFBench | 73.5% | 71.8% | 51% fewer | | AIME 2026 | 98.7% | 94.0% | 50% fewer | | HMMT (Nov 2025) | 99.3% | 96.0% | 46% fewer | | ERQA (vision) | 67.5% | 66.3% | 55% fewer |

Token savings hold at every reasoning effort (mean thinking reduction): xhigh 41%, medium 23%, low 26% (albeit with accuracy losses of 1-4% on medium and 1-2% on low, which need further testing).

Swift at xhigh vs the base's own effort settings on GPQA-Diamond (198 questions x 5 seeds):

| Model / effort | Accuracy | Median tokens | |

|

|

| | Base xhigh | 88.4% | 6,642 | | Swift xhigh | 88.3% | 2,771 | | Base medium | 84.1% | 1,753 |

So Swift keeps xhigh accuracy at under half the tokens, and beats base-medium by 4pp at roughly 1.6x its tokens.