Swift Qwen3.8 27B GGUF

Swift-Qwen3.8-27B is UkisAI's reasoning-efficient derivative of Qwen3.8-27B, using 58.3% fewer thinking tokens while maintaining near-identical performance (<1% loss) and as a result getting a x1.95 speed-up on several tasks.

Evaluation scope

Benchmarks

Quantized evaluations

Quantized deployment is the intended use for Swift: lower-memory weights paired with shorter reasoning. The INT4 evaluations below come from the source model card and were run on W4A16 and AWQ checkpoints, not on this F16 GGUF. They retain token savings across GPQA, IFBench, and AIME. On AIME, Swift matches or improves accuracy and reduces output-cap failures by 31–33%.

Each row compares the same quantized base with and without the Swift adapter. GPQA and AIME use five seeds; IFBench uses four samples per prompt and strict scoring. Output caps: GPQA 100,000; IFBench 81,920; AIME 32,768. GPQA and IFBench use saved historical base runs. AIME uses template-default effort and counts truncated answers as incorrect. Its shorter cap makes it a separate comparison from the BF16 table.

GGUF quantizations

Mean KL divergence against the BF16 source, lower is better. Tiers marked new tier were added on 2026-09-13 and carry the wikitext @512 measurement and 512-token top-token agreement; their 32k columns will be filled as those runs complete. wikitext is wikitext-2 test; held-out is our own chat and long-document set, reserved before the importance matrix was fitted. Top-p is top-token agreement with BF16 at 32k on the held-out set.

Read the two 32k columns together. On this hybrid architecture (48 of 64 blocks are recurrent), a small fraction of positions (about 0.1%) diverge sharply at long context for every tier, including Q8_0, and the same is true of the public Q4_K_M and Q8_0 builds of the base Qwen3.8-27B measured on the same harness. Those rare positions dominate the held-out mean; the median divergence at 32k is within 10% of the 512-token value for every tier. Typical-token quality does not degrade with context. The pick below follows the 99th-percentile tail on the held-out set: 2.60 for Q4_K_M, 1.75 for Q5_K_M, 0.46 for Q6_K, 0.23 for Q8_0.

All tiers use the same importance matrix (8,016 chunks of domain, prompt and long-document text) and pin the recurrent gate projections ssm_alpha and ssm_beta to F32 and the MTP head to Q8_0. Q4_K_M additionally lifts ssm_out, attn_gate, output and token_embd to Q6_K; Q5_K_M and Q6_K lift attn_gate to Q8_0. The lifts cost about 1.1 GB on Q4_K_M and reduce its KL divergence by roughly 20% against a plain llama.cpp Q4_K_M of the same model.

The tiers added on 2026-09-13 (IQ2_XXS through Q6_K_L) use the same importance matrix and the same ssm_alpha/ssm_beta F32 and MTP Q8_0 pins, with per-tensor type layouts computed for this model by bartowski's quantization-config instead of llama.cpp's built-in heuristic (--tensor-type-file). Q4_K_L, Q6_K_S and Q6_K_L are the large and small layouts of Q4_K_M and Q6_K. All files were built with llama.cpp release b10896 from a BF16 conversion of the published safetensors and checked against BF16 on the harness above.

KV cache

Only 16 of the 64 blocks are full attention, so the cache stays small for a 27B:

Training approach

We built Swift by identifying reasoning-marker tokens that, in our analysis, trigger overthinking in Qwen’s reasoning rollouts. We then fine-tuned Qwen by penalizing usage of those tokens while it reasons.

Swift produces shorter reasoning traces. In our testing, we also observe fewer overthinking errors.

For maximum gains, Swift also includes a transfer component derived from BottleCap AI's ThinkingCap-Qwen3.6-27B.

How to use

llama.cpp

These files run with llama.cpp, installable in one line via llama.app. The command below is the llama.cpp counterpart of the vLLM configuration on the source card: full 262,144 context, thinking on at reasoning effort xhigh, reasoning and tool calls parsed from the embedded chat template, and Qwen3.8's thinking-mode sampling.

llama-server exposes an OpenAI-compatible API and a built-in chat web UI on the port above. Swap Q4_K_M for any tier in the table above (IQ2_XXS up to Q8_0) or F16; -hf fetches the tier and the vision projector automatically. The KV cache costs 64 KiB per token (16 GB at the full 262,144 context), so lower -c if it does not fit. Use a recent llama.cpp release with Qwen3.5/Qwen3.8 architecture support. The same sampling values are stored in the GGUF header and xhigh is the template default; the flags above make the configuration explicit.

They also work in LM Studio, koboldcpp and Jan AI. In those apps set the same sampling values by hand and a context length of at least 65,536 tokens; the default 4,096-token window overflows on long reasoning and looks like an endless loop.

Multimodal

This model supports image input. Alongside the quants, this repo includes the multimodal projector file mmproj-Swift-Qwen3.8-27B-F16.gguf, which pairs with any tier above. llama.cpp downloads the mmproj automatically when using -hf as shown above; if you are loading files manually, pass it with --mmproj.

MTP

This model has MTP (Multi-Token Prediction) layers, and they are included in every tier, stored at Q8_0. MTP layers act as a built-in draft model, letting llama.cpp run speculative decoding for faster generation. To use them, add the following flag to your llama.cpp command:

This is the counterpart of the vLLM --speculative-config '{"method":"mtp","num_speculative_tokens":3}' option.

Ollama

Use Ollama 0.33 or newer. The Modelfile in this repo pulls the Q4_K_M tier together with the vision projector, applies the sampling values above, and sets Ollama's built-in Qwen3.8 renderer and parser, which separate reasoning from the answer and parse tool calls. Swift's embedded chat template is identical to Qwen3.8's. For another tier, download the Modelfile, change the tag after FROM, and run ollama create swift -f Modelfile.

ollama run hf.co/ukisai/Swift-Qwen3.8-27B-GGUF:Q4_K_M also works without a Modelfile. It runs the embedded chat template through llama.cpp and reads the sampling values from the params file. Hugging Face cannot set Ollama's renderer and parser, so in this mode reasoning may appear inline with the answer.

Ollama sizes the context window from VRAM: 262,144 tokens with 48 GB or more, 32,768 with 24 GB, and 4,096 below that, which is too short for long reasoning. To raise it, start the server with OLLAMA_CONTEXT_LENGTH=65536 ollama serve or run /set parameter num_ctx 65536 in the chat. To use the MTP layers, run /set parameter draft_num_predict 3.

UkisAI API

If you would rather not run the weights yourself, Swift is served through an OpenAI-compatible API at https://ukisai.com/api/swift/v1. It is free for research purposes and needs no API key. The model id is swift.

curl https://ukisai.com/api/swift/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model": "swift", "messages": [{"role": "user", "content": "Hello, Swift."}]}'

Validation

The converted files passed a finite-tensor check and a CPU text-generation smoke test. Multimodal generation and the full benchmark suite have not been re-evaluated on this GGUF release. The results above and on the source model card come from the BF16 and INT4 checkpoints named there, not from these files.

License and access

Swift weights are distributed through gated access under the Swift Open License v1.0. Personal, research, educational, evaluation, and commercial use are free for individuals and organizations with annual recurring revenue, including affiliates, of up to US$1,000,000. Above that threshold, commercial use requires a separate Swift Enterprise License. Contact UkisAI for terms.

Citation

@misc{swift-qwen3.8-27b,
  title  = {Swift-Qwen3.8-27B},
  author = {UkisAI},
  year   = {2026},
  url    = {https://huggingface.co/ukisai/Swift-Qwen3.8-27b}
}