ISTA-DASLab releases GSQ-RCO non-uniform GGUF quantizations of Qwen3.8-Flash-Next, a 512-expert multimodal MoE, at 2.4-3.0 bits per weight.
The repository provides GGUF quantizations of Qwen3.8-Flash-Next, a sparse mixture-of-experts model with 512 routed experts across 48 layers (10 active per token) plus a BF16 vision projector for multimodal use. Quantization combines GSQ (Gumbel-Softmax scalar quantization) and RCO (Riemannian constrained optimization), developed at IST Austria's DASLab, assigning quantization types per tensor via gradient-based search under a size budget. Three variants ship at 2.40-3.00 average bpw (66.4-75.8 GB total), and the recommended IQ3_XXS build matches the base model on AIME25 (100.00) while staying within 0.51 points on GPQA-Diamond and 1.14 on LiveCodeBench v6 at roughly one fifth of BF16 size. Files are standard GGUF running unmodified in llama.cpp, Ollama, and LM Studio under an Apache-2.0 license.
IQ3_XXS variant matches the base model on AIME25 (100.00) at about one fifth of BF16 size.
GSQ and RCO jointly select per-tensor quantization types via gradient-based search under a size budget.
Q2_0 build delivers 3.4x prompt throughput and 1.9x lower latency than IQ2_XS with minor quality loss.
Includes a BF16 vision projector (mmproj) for multimodal inference; Apache-2.0 licensed.
Base model is a 512-expert sparse MoE across 48 layers with 10 experts active per token.
---
## Overview
This repository provides GGUF quantizations of **Qwen3.8-Flash-Next** at three sizes, together with the model's vision projector (`mmproj`) for multimodal use. In contrast to uniform quantization, which applies a single quantization type to all weight tensors, each model here assigns a separate quantization type to every tensor. The assignment is obtained by a gradient-based search that allocates precision according to per-tensor sensitivity, subject to a total size budget. The resulting files are standard GGUF and run unmodified in `llama.cpp`, Ollama, and LM Studio.
Flash-Next is a sparse mixture-of-experts model: **512 routed experts per layer across 48 layers**, of which 10 are active per token. The routed expert matrices dominate the parameter count, so they also dominate the size budget: 95% of the searchable weights live in the experts. The search therefore spends most of its freedom there, assigning a quantization type **per layer** (not per expert, which GGUF cannot express).
> **Method summary.** GSQ provides accurate low-bit scalar quantization of each tensor at a given quantization type; RCO assigns the per-tensor quantization types under a size budget. Together they yield a non-uniform GGUF at the requested size.
| Method | Description |
|---|---|
| **GSQ** (Gumbel-Softmax Quantization, [paper](https://arxiv.org/abs/2604.18556), [code](https://github.com/IST-DASLab/GSQ)) | Post-training scalar quantization that jointly learns the per-coordinate grid assignments and the per-group scales via a Gumbel-Softmax relaxation. GSQ closes most of the gap between scalar and vector quantization at 2 to 3 bits while remaining deployable in standard scalar formats such as GGUF. |
| **RCO** (Riemannian Constrained Optimization, [paper](https://arxiv.org/abs/2605.00649), [code](https://github.com/IST-DASLab/RCO)) | Assigns one of K quantization types to each of N tensors under a total size budget. The budget constraint is reformulated as a smooth Riemannian manifold in logit space, which permits gradient-based optimization directly on the task loss while enforcing the budget exactly, without constraint-specific hyperparameter tuning. |
Both methods were developed at the [Deep Algorithms and Systems Lab (DASLab)](https://github.com/IST-DASLab), Institute of Science and Technology Austria.
---
## Available files
Files follow the convention **`<model>-GSQ-RCO-<type>.gguf`**, where the suffix names the quantization class; the table lists each file's average bit-width over the transformer weights.
The `mmproj` file carries the vision encoder and projector at BF16; one copy serves all quantizations. Each quantized model ships as **two shards**. The second shard is identical across all three variants: it holds the per-layer n-gram embedding table (`per_layer_token_embd`, 51.2B parameters) at IQ4_NL. That table is a lookup, not a matmul weight, so it is held at a fixed 4.5 bpw in every build and excluded from the search. It is quantized in the evaluated models, not just the shipped ones.
**Q2_0** is built for speed. It avoids the quantization formats that rely on large lookup tables: those formats pack more accuracy into a given bit-width, but decoding them costs real time, and on this model that cost dominates inference. Q2_0 delivers **3.4x the prompt throughput** and **1.9x lower end-to-end latency** than IQ2_XS at a slightly smaller file size, and its decode rate stays flat across workloads instead of varying with the content. The trade is a little quality: 89.07 task average against 89.16 for IQ2_XS, and 3.5 points below IQ3_XXS. Pick it when throughput matters most, and see [Performance](#performance) for the measurements.
The IQ3_XXS model is the strongest operating point: it matches the base model exactly on AIME25 (100.00) and is within 0.51 points on GPQA-Diamond and 1.14 on LiveCodeBench v6, at roughly one fifth of the BF16 size.
### Memory requirements
Only the first shard holds transformer weights and needs to be resident. The second shard is the n-gram lookup table: it is read sparsely, one row per token, so it can stay memory-mapped on disk and does not need to occupy VRAM. Run with `-lm mmap --lazy-mode on` to get this behaviour, plan for **shard 1 in VRAM**, and keep shard 2 on an SSD so the paging stays cheap.
| Model | Must be resident (shard 1) | Can stay on disk (shard 2) | Total download |
|---|---|---|---|
| `Q2_0` | 37.6 GB | 28.8 GB | 66.4 GB |
| `IQ2_XS` | 39.2 GB | 28.8 GB | 68.0 GB |
| `IQ3_XXS` | 47.0 GB | 28.8 GB | 75.8 GB |
Add headroom for the KV cache and the vision projector (0.91 GB) if used. Keeping the n-gram table in RAM rather than on disk removes the paging cost entirely and is worth it where memory allows.
---
## Performance
Measured with `llama.cpp` over 55 prompts spanning eleven categories (coding, humanities, math, QA, RAG, reasoning, STEM, writing, multilingual, summarization, roleplay).
| Model | Prompt t/s | Decode t/s | Avg latency |
|---|---|---|---|
| `Q2_0` | **367.49** | **93.79** | **6.70 s** |
| `IQ2_XS` | 108.19 | 70.30 | 12.68 s |
The gap comes from the quantization formats rather than the size: the two files differ by only 1.6 GB, and Q2_0 is the smaller of the two. Q2_0's decode rate is also far more stable across categories, 92.5 to 94.5 t/s (a 2.0 t/s spread), where IQ2_XS swings from 49.4 to 94.5 t/s (a 45.1 t/s spread), because the lookup cost varies with how much of each layer a request touches.
The prefill advantage is uneven, and largest where prompts are long: 9.6x on RAG, 6.8x on writing and 6.2x on coding. On short-prompt, reasoning-heavy categories the two are level or Q2_0 is marginally behind (0.8x to 0.9x on stem, math and reasoning), where prefill is too brief for the format's decoding cost to matter.
---
## Results
All models are evaluated against the **BF16** base model. We report the average over five zero-shot tasks (arc_easy, arc_challenge, hellaswag, winogrande, piqa), recovery (zero-shot average relative to BF16), and three reasoning and generation benchmarks: **AIME25**, **GPQA-Diamond**, and **LiveCodeBench v6**. Task average is the mean of the three. Sizes are the full download, including the n-gram shard; the bit-width column is the average over the transformer weights, which is what the search controls.
> **Reasoning effort.** These quantized models are primarily optimized for **xhigh reasoning effort**, and we recommend using them in that mode for best quality. The reported reasoning results should therefore be interpreted in that setting. At lower reasoning-effort levels, quantization-induced degradation can be larger than what is observed at xhigh, so the quality gap relative to the BF16 base model may increase.
All three models exceed the BF16 base on the zero-shot average (100.3% to 101.4%), which is common for careful low-bit quantization on these five tasks: the differences are within roughly one standard error and should be read as parity rather than improvement. The reasoning and generation benchmarks separate the models far more clearly.
At 3.00 bpw, IQ3_XXS reaches **99.4%** of the base model's task average (92.57 against 93.12) while being **4.7x smaller** (75.8 GB against 354 GB). It matches the base exactly on AIME25 (100.00), and trails by 0.51 on GPQA-Diamond and 1.14 on LiveCodeBench v6. At 2.50 bpw, IQ2_XS retains 95.7% of the task average at 68.0 GB, and the smallest build, Q2_0, holds 96.67 on AIME25 at 66.4 GB, a 5.3x reduction.
The two sub-2.5 bpw builds land within 0.1 points of each other on task average despite different allocations: Q2_0 is stronger on GPQA-Diamond (89.39 against 87.37) while IQ2_XS is stronger on LiveCodeBench v6 (83.43 against 81.14).
---
## Usage
Both shards must be downloaded; `llama.cpp` loads the split automatically when given the first one.
`-lm mmap --lazy-mode on` keeps the n-gram table memory-mapped on disk instead of loading it into memory, which removes 28.8 GB from the resident footprint. See [Memory requirements](#memory-requirements).
The projector was converted directly from the base checkpoint and is shared by all three quantizations.
### Ollama
```bash
ollama run hf.co/<this-repo> # pick the directory matching your memory budget
```
### LM Studio
Search the repo name, then pick a `GSQ-RCO-*` build from the file list.
---
## Quantization procedure
1. **Per-tensor database.** Each weight tensor is quantized at every candidate GGUF quantization type with GSQ, yielding a searchable database of quantized tensor variants.
2. **RCO search.** The budget-constrained Riemannian search assigns one quantization type per tensor such that the whole-file average bit-width meets the target.
3. **Assembly.** The selected per-tensor variants are stitched into a single standard GGUF file.
For this model the search covers **352 tensors**: the 304 dense tensors (attention, SSM projections, shared experts, embeddings, output head) and the 48 fused routed-expert matrices, one per layer. Two classes draw on separate quantization ladders, because the routed experts sit at a much lower bit-width than the dense path at any given budget. `ffn_down_exps` is excluded from the search and held at Q2_0. Its 640 rows are not divisible by 256, which rules out every block-256 K and I quant format; only the block-32 and block-64 types can represent it, so there is little to search over.
Reference implementations: **GSQ** at [IST-DASLab/GSQ](https://github.com/IST-DASLab/GSQ) and **RCO** at [IST-DASLab/RCO](https://github.com/IST-DASLab/RCO).
### Reproducibility artifacts
Each released GGUF ships the files needed to audit how it was built:
| File | Contents |
|---|---|
| `tensor-allocation/<model>.rco-allocation.txt` | The quantization type assigned to every tensor in that file, with a quant-type histogram and the target bit-width. This is the RCO search result, so the allocation can be inspected without opening the model. |
---
## Citation
If you use these models or methods, please cite both papers:
```bibtex
@article{gsq2026,
title = {GSQ: Highly-Accurate Low-Precision Scalar Quantization for LLMs via Gumbel-Softmax Sampling},
author = {Dadgarnia, Alireza and Tabesh, Soroush and Nikdan, Mahdi and Helcig, Michael and Kurtic, Eldar and Kleinegger, Maximilian and Alistarh, Dan},
Hacker News · AI