DatKurai/Swift-1.5-Qwen3.8-Flash-Next-GSQ-RCO-Uncen-IQ1-332Exp-GGUF

Swift-1.5-Qwen3.8-Flash-Next-GSQ-RCO-Uncen · IQ1 · 332 experts/layer (GGUF) — mixed IQ3_XXS payload, not 1-bit

⚠️ Read this first — ignore the automatic "Use this model" panel. It suggests a :BF16 llama.cpp/Ollama launch that does not match this release. This GGUF runs with the Strata engine: follow the Quick start below (stock llama.cpp / Ollama / vLLM are not tested).

Swift-1.5 Uncensored (Uncen) is an abliterated (refusal-reduced) build of Swift 1.5 — the uncensored line of the Qwen3.8-Flash-Next GSQ-RCO family. This release shrinks the MoE expert pool from 512 → 332 experts/layer so it serves on consumer hardware (a single 16 GB GPU + 32 GB RAM with the Strata engine), while keeping as much coding, agent and tool-calling capability as possible.

• About the IQ1 name — read first. IQ1 here does not mean 1-bit tensor quantization. It labels the effective payload class of the pruned release — ~60.65 GB (56.49 GiB) — the same naming convention and size class as the GSQ-RCO Coder IQ1_M release (58.4 GB; itself a pruned build). Every tensor in this release keeps its original quantization inherited from the source; nothing was re-quantized. Equal size class is not quantization equivalence: this release keeps the source's mixed IQ3_XXS tensor bytes, while the Coder's kept experts are stored at ~3.5 bpw — read neither name as a tensor-precision tier.
• Base: SC117/Swift-1.5-Qwen3.8-Flash-Next-GSQ-RCO-abliterated-GGUF @ 46d8cfdd (IQ3_XXS tier) — all weights, including every kept expert, come from this uncensored source.
• Experts: 512 → 332 per layer (≈ 64.8% of the pool), 48 layers, 10 routed experts/token.
• Payload: 36.47 GB + 24.18 GB = 60.65 GB (56.49 GiB) across 2 GGUF shards; the vision projector is included.
• Verified setup (author's experience): Windows 11 · single RX 6800 16 GB + 32 GB system RAM · Strata engine with --resident-experts and expert caching · KV int8 · MTP speculative decoding. Production-served at 144K–192K context; 256K context was verified at runtime (a ~251.5K-token prompt was recalled correctly in testing). Other hardware will vary.
• Multilingual: inherits Qwen3.8-Flash-Next's language coverage. Smoke-tested in eight languages across Latin, CJK and Cyrillic scripts — arithmetic + explanation passed in all eight; free-form writing is shown for the languages that met the bar (see i18n-smoke/).
• Vision: image-text input works with the included projector — smoke-tested on 5 images (OCR card, flow diagram, settings screenshot, shapes, abstract render), all read correctly (see vision-smoke/).
• Quality note: in our own A/B tests so far we have not observed a clear quality difference vs the original full-expert model on the tasks evaluated (agentic coding through OpenCode). These are informal A/Bs — this release has no standardized quality benchmark yet (no LiveCodeBench / SWE-bench claim).

Runtime support. This release is built for and verified with the Strata engine. Stock llama.cpp / Ollama / vLLM are NOT tested with it — do not assume they will load or run it correctly.

Community testing & feedback

No standardized benchmark ships with this release yet. If you run it, please open a discussion in the Community tab (Community → New discussion) with: hardware + RAM, engine + version, context length, KV/spec settings, PP/TG numbers, and any coding or behavior results. Reports — including negative ones — are welcome and will be linked as they arrive.

---

1. Overview

This is a routing-aware expert-pruned build of Swift 1.5. The goal is straightforward: shrink the checkpoint so it serves well on consumer hardware (16 GB VRAM + RAM expert cache) while sacrificing as little coding capability as possible.

Unlike uniform pruning, the expert map is derived from real-world routing traces, primarily English coding-agent and test-writing workloads, supplemented by Vietnamese and mixed-language traces, and blended with the published GSQ-RCO Coder mask. The result is a code/agent-focused expert map rather than a generic downsample.

What is preserved:

• Swift 1.5 post-training — encoded in the weights of every retained tensor; no distillation, no re-quantisation.
• Original quant bytes/scales — retained experts and all non-expert tensors keep their exact source bytes; router/gate/up/down tensors are sliced consistently per layer, nothing else modified.
• Uncensored character — abliteration inherited from the source model; refusals are drastically reduced. (Throughout this card, "Uncen / uncensored" always means this inherited abliteration — it is not a separate tuning step.)
• Multilingual coverage — inherited from Qwen3.8-Flash-Next.

---

2. Where the experts come from — and why this recipe

All weights come from the uncensored source. Every tensor — including all 332 experts kept per layer — is taken byte-for-byte from SC117/Swift-1.5-Qwen3.8-Flash-Next-GSQ-RCO-abliterated-GGUF (IQ3_XXS tier). This model is not a Coder derivative: no Coder weights are used. "Uncen" is inherited from that abliterated source.

The Coder contributes a selection mask, not weights. The starting point of the expert map is the 256/512-per-layer expert set published by ISTA-DASLab in the GSQ-RCO Coder release (rco-allocation.txt). One naming note: RCO stands for Riemannian Constrained Optimization — the budget-constrained assignment method introduced in Model Compression with Exact Budget Constraints via Riemannian Manifolds (Helcig & Alistarh, 2026). In that pipeline RCO is used both to choose which experts survive and to allocate the compression budget; this build uses RCO only as the published expert mask — no precision re-allocation was applied, and the quantization bytes are untouched.

The mask was measured and repaired on our model. Routing traces collected on the uncensored model itself show that mask transfer is imperfect: the Coder's mask alone covers ~72.4% of code routing and ~69.4% of multilingual routing on this model (the "weaker outside code" caveat the Coder's authors state). A frequency-only ranking was also tested and rejected: it would have missed ~25% of the RCO-selected experts (set overlap ~74.7%) — rare specialists that pure frequency discards. Per layer, this build therefore:

1. Starts from the Coder's kept 256/512 mask (RCO set, as above).
2. Removes dead weight — experts with zero routing usage across three real traces collected on this model (code / multilingual / mixed), with a cap of 32 swaps per layer so no layer is destabilised.
3. Adds back by measured frequency — 56 experts by code-routing, 8 by multilingual routing (the viet-512 set), 12 by test-writing routing, and the remaining slots by combined code + multilingual + test frequency.

The repair works: the final map routes 96.4% / 96.4% of code / multilingual trace slots (layer mean; worst layer 89.9% / 88.3%) and 98.2% of the test-writing trace — only ~3.6% of routing mass remains in the excluded tail, and that tail is diffuse (its top-5 experts carry <1% of it). Composition: 76.1% of all kept positions come from the Coder's RCO mask; 23.9% are re-selected on our traces (56 code + 8 multilingual + 12 test per layer, plus 163 zero-usage swaps in total — the 32-swap/layer cap never binds, the worst layer needed 16). Routing coverage is a routing-level metric, not a quality score — but it quantifies exactly what the pruning gave up and recovered.

Calibration vs verification (trace split)

The numbers above are measured on the same traces used to build the map (in-sample), so we also ran held-out checks:

• Split-half (map built on the first half of a trace only, evaluated on the unseen second half): code 96.1% (vs 97.9% in-half) · multilingual 93.9% · test 98.8% — against 71.3% / 67.7% / 75.8% for the raw Coder mask.
• Cross-trace (map built without the test-writing trace, evaluated on it): 97.9% on test, vs 98.2% for the final map — the recipe generalises beyond its selection data.
• Code-only map (no multilingual or test data at selection time): code 96.8% · multilingual 96.0% · test 97.9% · mixed 93.7%.

Trace construction: code (9,418 tokens: 19 code prompts + 21 real-session replays + 20 system/safety payloads), test-writing (9,423 tokens of test-task replays), multilingual (1,365 tokens, 9 prompts — the viet-512 set: Vietnamese-language prompts), mixed (3,177 tokens, an earlier mixed trace from the same family). Held-out routing coverage remains high, with differences varying across trace types and split strategies (from −2.5 to +0.6 points in these checks — the test-writing split-half even lands slightly above its in-sample number). Both views are published because the in-sample figures describe the selection set while the held-out checks are the honest range for a fresh workload.

Why exactly 332 experts? Measured cost vs. coverage: one expert costs ~1.7–2.2 MB on disk, so the ~76-per-layer fill adds ~6.7 GB over the raw mask and recovers ~24 points of code-routing coverage. Beyond this point the curve flattens: the next +128 code experts/layer would add ~10–14 GB for ~+3.6 points (a diminishing ~0.3 pp/GB), and keeping all 512 experts pushes the artifact to 75.8 GB — out of the 32 GB-RAM budget that keeps the expert working set resident (see the residency note below). 332 is the point where coverage gains flatten against memory cost.

Benefits measured on this recipe family (development notes, Oct 2026):

• ~2.3× decode speed vs the unpruned 512-expert build in the same runtime on the same machine (33.1 vs 14.6 t/s @8K TG, v1-era measurement of this recipe family).
• Expert-set residency on 32 GB RAM + 16 GB VRAM. Residency here means the expert working set stays in memory — it does not mean the whole 60.65 GB artifact fits in 48 GB of memory. Model files are still read from disk at load, and the PLE (n-gram) table lives on disk and is read with caching. In steady state, the v1 320-expert build of this family measured zero SSD expert reads, which is the single biggest factor for local speed on this class of hardware.
• Higher expert-cache hit rates — a smaller pool means more of the routing-relevant experts stay cached, which is why throughput holds up into long contexts (see the table below).

---

3. Specification

Item	Value
Release name	IQ1 (effective payload class after pruning; same size class as the GSQ-RCO Coder IQ1_M release at 58.4 GB)
Architecture	MoE — Qwen3.8-Flash-Next (GSQ-RCO): 48 layers, 10 routed experts/token, embedding 2560
Experts	512 → 332 per layer
Base model	SC117 Swift-1.5-Qwen3.8-Flash-Next-GSQ-RCO-abliterated @ 46d8cfdd (IQ3_XXS tier)
Quantization	Mixed, as inherited from the source and unchanged: Q2_0 · Q4_K · Q5_K · Q6_K · IQ2_XXS · IQ2_XS · IQ2_S · IQ3_XXS · IQ3_S · IQ4_NL · IQ4_XS · BF16 / F16 / F32 (dense, SSM, hyper-connections). No re-quantisation.
Payload size	36.47 GB + 24.18 GB = 60.65 GB (56.49 GiB)
Format	GGUF, split 2 shards; PLE table lives in shard 1
Context	262,144 max (metadata); production configs 144K–192K; 256K verified at runtime
Languages	Multilingual (inherits Qwen3.8-Flash-Next coverage; smoke tests in i18n-smoke/)
Vision	Image-text input via the included mmproj projector + Strata's vision encoder (projector weights identical to the base model's); 5-image smoke test in vision-smoke/
Engine	Strata — the engine this build is built and verified with. Stock llama.cpp / Ollama / vLLM not tested.
License	Swift Open License v1.0 (the Swift contribution) · Qwen Community License 1.0 (base model) — commercial terms summarized in § 7

Files

File	Content
Swift-1.5-Qwen3.8-Flash-Next-GSQ-RCO-Uncen-IQ1-332Exp-00001-of-00002.gguf (36.47 GB)	shard 1 — PLE table + layers 0–12 (317 tensors)
Swift-1.5-Qwen3.8-Flash-Next-GSQ-RCO-Uncen-IQ1-332Exp-00002-of-00002.gguf (24.18 GB)	shard 2 — layers 12–47 (907 tensors)
mmproj-SC117-abliterated-BF16.gguf (0.91 GB)	vision projector — sha256 2e788f8c511d8093c7b43cb87b2fd7e14228340318057f8fb20c86df2efe2355
MANIFEST.json	Full provenance: per-layer expert map, per-tensor source/output offsets, sizes, expected blake2b_256
expert-profile-332.bin (125 KiB)	The 332-expert static expert-cache ranking — all 15,936 layer–expert pairs, ranked (built from an English code-workload calibration; required by --resident-experts)
SHA256SUMS	Shard + support-file hashes
LICENSE · LICENSE-QWEN · NOTICE	Upstream license texts (Swift Open License v1.0 · Qwen Community License 1.0) + redistribution attribution
RUNTIME_VALIDATION.md	Post-packaging runtime/context validation (the build-time state stays in MANIFEST.json)
tokenizer/	Tokenizer + chat_template.jinja (runtime pack copy)
i18n-smoke/, vision-smoke/	smoke-test transcripts and images (see below)

---

4. Quick start

You need the Strata engine (public project: Niko1221/Strata) — the commands below are the same steps its tooling uses. The pack step was verified locally: the pack it produces is byte-identical to the production pack.

# 1) weights + projector
hf download DatKurai/Swift-1.5-Qwen3.8-Flash-Next-GSQ-RCO-Uncen-IQ1-332Exp-GGUF \
  --local-dir kurai-iq1

# 2) native pack for the engine (reads shard 1; ~1.5 GB output)
python tools/iq_pack.py \
  --gguf kurai-iq1/Swift-1.5-Qwen3.8-Flash-Next-GSQ-RCO-Uncen-IQ1-332Exp-00001-of-00002.gguf \
  --out  kurai-iq1/pack

# 3) MTP draft layer (fetched from the original BF16 checkpoint via HTTP ranges, packed, relayouted)
python tools/mtp_fetch.py fetch --out kurai-iq1/mtp-bf16
python tools/mtp_pack.py --src kurai-iq1/mtp-bf16 --experts q2_0 --out kurai-iq1/mtp-bf16/mtp-q2_0.gguf
python tools/mtp_rt.py  --gguf kurai-iq1/mtp-bf16/mtp-q2_0.gguf --out kurai-iq1/mtp-bf16/rt

# 4) serve — start at 32K context; raise --max-context in steps as memory allows (see Context in the notes)
strata --serve \
  --pack           kurai-iq1/pack \
  --native         kurai-iq1/Swift-1.5-Qwen3.8-Flash-Next-GSQ-RCO-Uncen-IQ1-332Exp-00001-of-00002.gguf \
  --ple-gguf       kurai-iq1/Swift-1.5-Qwen3.8-Flash-Next-GSQ-RCO-Uncen-IQ1-332Exp-00001-of-00002.gguf \
  --expert-profile kurai-iq1/expert-profile-332.bin \
  --expert-cache   auto \
  --prefill        auto \
  --spec           4 \
  --spec-min-p     0.5 \
  --mtp            kurai-iq1/mtp-bf16/rt \
  --kv             int8 \
  --resident-experts \
  --max-context    32768

Notes:

• The PLE table lives in shard 1, so --ple-gguf points at the same shard as --native (as above).
• --resident-experts keeps the expert working set in RAM; on a 32 GB machine the engine manages the split with VRAM automatically. --vram-reserve-mib tunes how much VRAM is left free.
• --expert-cache auto sizes the cache from available memory, --prefill auto sizes prompt chunks automatically, and --spec 4 --spec-min-p 0.5 drive the MTP draft — the same serve set the upstream Strata setup writes into its configuration.
• Sampling — the base model's recommendation: temperature 1.0, with top_p 0.95, top_k 20 (the sampling block of the serve configuration; this is what our production serves).
• Context — the example starts at --max-context 32768, a safe start (including for 12 GB VRAM + 32 GB RAM). Raise it in steps — 65536 → 131072 → 196608 → 262144 — while watching memory and decode speed as you go: a longer context reserves more RAM/VRAM (the int8 KV is ≈ 2 GB at 144K–160K, ≈ 3 GB at 256K) and the expert cache shares those budgets. The production configs behind this card ran 144K–192K on 16 GB VRAM + 32 GB RAM (256K was verified in testing); on a smaller card, start lower and climb only while it stays comfortable.
• Engine — verified with Strata v0.1.38 → v0.1.43.1; use a current release (Niko1221/Strata). The first load reads the weights from disk and builds the resident RAM complement (minutes); the engine log reports how much of the expert set stayed resident (see RUNTIME_VALIDATION.md).
• The MTP draft (step 3) is optional — without it, drop --mtp, --spec and --spec-min-p.
• --resident-experts requires a static --expert-profile — without one the engine exits with strata generate: --resident-cpu-experts requires --mmap-experts and a static --expert-profile (the message quotes the internal flags: --resident-experts already enables --mmap-experts and the resident CPU-expert mode — pass neither separately). This repo ships expert-profile-332.bin — the 48×332 pair ranking (all 15,936 layer–expert pairs, ranked) built from an English, code-workload calibration (see Expert profile below). To run without the resident mode, drop both --resident-experts and --expert-profile.
• An advanced setup is required in the sense that Strata itself must be built or downloaded from its repository first; the engine is not part of this repo.

Expert profile (48 × 332)

This release includes expert-profile-332.bin, a static expert-ranking profile for Strata's resident expert cache, derived from an English, code-workload calibration run (19 code prompts; all 15,936 layer–expert pairs, ranked).

• The profile determines expert cache residency priorities and does not modify the model's weights or routing behavior.
• It is provided as a reproducible starting point. Cache performance may vary depending on workload, hardware, and usage patterns.
• Users can optionally enable adaptive profile saving (--expert-profile-save) to optimize expert residency for their own workloads.
• Want a ranking matched to your own workload instead? Dump one routing trace (--dump-routing trace.bin on a prompt typical of your use) and run python tools/make_profile.py --n-expert 332 --base expert-profile-332.bin --reorder trace.bin --out my-profile.bin, then point --expert-profile at the result.
• This model is intended for general-purpose coding, agent workflows, reasoning, and multilingual use, with no language-specific specialization claimed.

Vision

Image input runs through Strata's vision pipeline with the included projector (mmproj-SC117-abliterated-BF16.gguf). The projector weights are identical to the base model's (abliteration does not touch vision tensors). A 5-image smoke test is published in vision-smoke/ — OCR card, flow diagram, settings screenshot, shapes and an abstract render, all read correctly; timings there are indicative only because the machine was concurrently in use.

Reference throughput (not a standard benchmark)

Measured on 16 GB VRAM (RX 6800) + 32 GB system RAM, Strata engine, KV int8, MTP spec 4 — author's system, environment-dependent:

Context	TG (t/s)	PP (t/s)
~8K	49–57	~640–700
~128K	46–50	—
~256K	30–36	—

---

5. Limitations

• No standardized quality benchmark yet. Byte integrity is fully verified (per-tensor blake2b_256 in MANIFEST.json), but this card claims no measured %-retention on LiveCodeBench / SWE-bench or any other suite. The quality note above reflects informal tests only.
• Runtime support is limited to the verified path. Built and verified with Strata; stock llama.cpp / Ollama / vLLM were not tested and are not supported as-is.
• Use the shipped chat template (tokenizer/chat_template.jinja) to match the runtime.
• Quantization is inherited, not uniform. The tensor mix above mirrors the source release; per-tensor types are listed in MANIFEST.json if you need exact composition.
• In-sample vs held-out routing coverage. The headline coverage numbers are measured on the selection traces (in-sample). Held-out checks vary by trace type and split strategy (−2.5 to +0.6 points in the published runs — see "Calibration vs verification"). Prefer the held-out view for expectation-setting.
• Uncensored model. The base is abliterated; outputs are not safety-filtered. Use responsibly and in accordance with applicable law.

---

6. Provenance & integrity

• Base weights: SC117/Swift-1.5-Qwen3.8-Flash-Next-GSQ-RCO-abliterated-GGUF @ 46d8cfdd9b6b036545d669eee068391de29383fa (IQ3_XXS tier).
• Coder expert mask (RCO set): ISTA-DASLab Qwen3.8-Flash-Next-GSQ-RCO-Coder-GGUF (rco-allocation.txt); method: RCO — Riemannian Constrained Optimization (IST-DASLab/RCO, Helcig & Alistarh 2026).
• Swift 1.5 post-training: ukisai/Swift1.5-Qwen3.8-Flash-Next.
• Map design, routing measurement, verification, packaging: DatKurai.

Integrity: expert map sha256 = fb7fbdd2…7409; calibration 85a90ab3…be7e. MANIFEST.json lists all 1,224 tensors with offsets, sizes and expected hashes — verify after download if desired. Pruning ran fully on CPU (gpu_used=false, inference_run=false).

---

7. License & commercial use

The weights inherit both upstream licenses, and both texts ship with this repository (LICENSE, LICENSE-QWEN; attribution in NOTICE):

• Swift contribution — Swift Open License v1.0. Free for research/non-profit use. Commercial use is licensed royalty-free up to US$1,000,000 gross revenue (your legal entity together with controlling/controlled entities, most recently completed fiscal year). Above the threshold, commercial use requires a separate Swift Enterprise License (ukisai.com/contact).
• Base model — Qwen Community License 1.0. Broadly permissive; two commercial conditions: products/services above 100M monthly active users or US$20M monthly revenue must display the model name in their UI, and businesses conducting "Model as a Service" or "AI Work Assistant" activity require a separate license from Qwen before commercial use (internal use exempt).
• This is a summary for orientation, not legal advice — the full texts govern.

8. Citation

@misc{datkurai_swift15_uncen_iq1_2026,
  title        = {Swift-1.5-Qwen3.8-Flash-Next-GSQ-RCO-Uncen - IQ1 - 332 experts/layer (GGUF)},
  author       = {DatKurai},
  year         = {2026},
  howpublished = {Hugging Face},
  note         = {Routing-aware size reduction of SC117 Swift 1.5 abliterated, code-retention focused}
}
@misc{helcig2026rco,
  title         = {Model Compression with Exact Budget Constraints via Riemannian Manifolds},
  author        = {Michael Helcig and Dan Alistarh},
  year          = {2026},
  eprint        = {2605.00649},
  archivePrefix = {arXiv},
  primaryClass  = {cs.LG},
}

---

Questions, throughput numbers and benchmark results are welcome in the Community tab.