16 GB is enough: the Qwen3.8-27B GGUF measurement table
TL;DR: IST-DASLab ships Qwen3.8-27B as GGUF in four sizes — from 8.4 to 11.8 GB. The recommended IQ3_S tier keeps 99.8 % of base performance at a 4.6× reduction and fits entirely on mid-range 16-GB GPUs. This article brings the file table, measured token rates, and a decision rule for batch versus interactive use.
What GSQ and RCO concretely change
The two abbreviations stand for a two-stage procedure that beats the known Unsloth dynamic quantizations at the same file size.
GSQ (Gumbel-Softmax Quantization) quantizes each tensor individually: it learns the grid assignment per coordinate and the scales per group jointly via a Gumbel-Softmax relaxation. The effect: at 2 to 3 bits per weight, GSQ closes the gap between scalar and vector quantization while remaining a standard GGUF that runs in llama.cpp, Ollama, and LM Studio.
RCO (Riemannian Constrained Optimization) then distributes the quantization types across the tensors. The size-budget bound is formulated as a smoothed Riemannian manifold in logit space, so the gradient optimizes directly against the task loss — without ever violating the budget.
The result per file is not uniform but tensor-level optimized. Nothing changes in the user's workflow: these are normal GGUF files.
hf download ISTA-DASLab/Qwen3.8-27B-GSQ-RCO-GGUF Qwen3.8-27B-GSQ-RCO-IQ3_S.gguf --local-dir .
llama-cli -m Qwen3.8-27B-GSQ-RCO-IQ3_S.gguf -p "Explain mixed-precision quantization." -ngl 99
The measurement table: footprint per file tier
The four release files with the true average bits-per-weight of the whole file, plus the model-card benchmark values against the BF16 base (53.8 GB):
| File | bpw | Size | AIME25 | GPQA-Diamond | LiveCodeBench v6 | Assessment |
|---|---|---|---|---|---|---|
| IQ2_XS | 2.50 | 8.4 GB | 96.67 | 84.85 | 76.57 | smallest tier, zero-shot above BF16 |
| IQ2_S | 2.75 | 9.3 GB | 100.00 | 86.36 | 82.29 | reaches base level on AIME25 |
| IQ3_XXS | 3.00 | 10.1 GB | 100.00 | 88.89 | 84.57 | strong all-round point |
| IQ3_S | 3.50 | 11.8 GB | 100.00 | 89.39 | 85.71 | recommended: task-lossless (99.8 % task average) |
| BF16 base | 16.00 | 53.8 GB | 100.00 | 89.90 | 85.71 | reference |
Three observations that carry the purchase decision:
- IQ3_S is the sweet spot. AIME25 and LiveCodeBench are reproduced exactly; GPQA-Diamond is off by only 0.51 points — at a 4.6× reduction.
- The advantage grows with smaller files. At 8.4 GB, IQ2_XS leads the same-sized UD-IQ2_S by 10.00 points on AIME25 and 8.59 on GPQA-Diamond.
- There are extras: a mmproj file (BF16, 0.9 GB) for vision input and optional -mtp builds (+0.35 GB) with a Multi-Token-Prediction head for speculative decoding — same quality, more speed.
Speed in practice: 16-GB cards in comparison
The model-card values are dimensionless; for speed, community measurements on real hardware count. Reported anchor points:
| Card / setting | Result |
|---|---|
| RTX 5090 (desktop flagship) | ~136 tok/s with IQ3_S, long context |
| RTX 5060 Ti 16 GB (desktop) | ~40 tok/s average, 552 tok/s prefill at 112k context |
| 5060 Ti, 112k context filled | 17–30 tok/s, ~25–30 toward the end of the window |
| RX 6800M 12 GB (laptop) | IQ3_S nearly fills the card (97 % at 4K context); IQ2_XS leaves ~1.3 GB of headroom |
The pattern: between 40 and 136 tok/s the 27B class sits comfortably above reading speed. At long contexts the rate drops because the KV cache grows — Qwen3.8 is a gated-delta-net hybrid with linear attention in most layers, which lowers the context tax versus pure transformer architectures but does not eliminate it.
Decision rule: is 40 tok/s enough?
Yes, for everything interactive. 40 tok/s is roughly double human reading speed; streamed text appears fluid.
For classification by use case:
- Interactive sessions (chat, agent loops): IQ3_S on a 16-GB card. The 11.8 GB leaves 3–4 GB for KV cache and activations — contexts up to ~100k are practically usable.
- Batch jobs (classification, extraction, many documents): IQ2_XS or IQ2_S. At 8.4–9.3 GB they even fit older 12-GB cards with room for larger batches; the 3–4 fewer points on GPQA are rarely relevant for short, format-like tasks.
- Multimodal: the matching IQ tier plus the 0.9-GB mmproj file — identical for all tiers.
The 16-GB point is the actual threshold: with the old uniform-quantization logic a 27B dense model needed 18–20 GB. The per-tensor search pushes it under the edge — and the allocations ship as .rco-allocation.txt in the repo, i.e. verifiable.
The limit: dense 27B reaches its end
Dense compression has a hard floor: at 2.5 bpw the task average is near the base value; below that it collapses. Anyone wanting more parameters switches architecture — MoE models with layer streaming from NVMe (e.g. 2.8T Kimi K3 across four SSDs) bypass the RAM edge but fall to ~1 tok/s. Between these two poles sits the 27B dense class: a complete model in RAM, measurements at 40 to 136 times the offload rate. For most laptop setups in 2026, IQ3_S is the rational endpoint.
FAQ
Which GGUF file do I take on a 16-GB card? Take IQ3_S at 11.8 GB if you need full model quality and work with 100k–112k context. Take IQ2_S at 9.3 GB if you want more headroom for large batches or long windows — it already reaches the AIME25 base level. IQ2_XS is the choice for 12-GB laptops, where 8.4 GB plus mmproj still fits with air between the layouts.
Is 40 tok/s on the 5060 Ti a fixed value? No, the rate depends on context: at the start of a window up to ~50 tok/s were measured, toward the end of a full 112k context ~25–30 tok/s. The prefill throughput of 552 tok/s is unaffected, because it runs in parallel over the prompt tokens. Plan a range instead of a number when you calculate agent latencies.
Do I need the -mtp variant? If you run llama.cpp with speculative decoding: yes, the MTP head costs only 0.35 GB and measurably speeds up decoding without changing the weights. Quality stays identical because the base tensor allocation is the same. Without MTP support in your harness, the standard file suffices.
What is the difference versus Unsloth dynamic quantizations? Both are per-tensor optimized, but GSQ+RCO deliver more points at the same or smaller file size: at 8.4 GB IQ2_XS leads by 10 points on AIME25; at ~12 GB IQ3_S leads by 3.33 points with 0.2 GB less size. On GPQA-Diamond, UD-IQ3_S is marginally ahead (0.51 points) — a trade-off that hardly matters at a 99.8 % task average.
How do I verify a file's allocation myself? Each tier ships a tensor-allocation file in the repo listing the assigned quantization type per tensor plus the bit-width histogram. That lets you check budget compliance without loading the model. Additionally, the importance matrix (imatrix-qwen3.8-27b.gguf, 1000 × 4096 tokens) is included, making the quantization reproducible.
Sources
- https://huggingface.co/ISTA-DASLab/Qwen3.8-27B-GSQ-RCO-GGUF — model card with the full measurement table (retrieved 17.09.2026)
- https://huggingface.co/ISTA-DASLab/Qwen3.8-27B-GSQ-RCO-GGUF/discussions/6 — community measurements on RTX 5060 Ti (112k context)
- https://arxiv.org/abs/2604.18556 — GSQ: Highly-Accurate Low-Precision Scalar Quantization for LLMs via Gumbel-Softmax Sampling
- https://arxiv.org/abs/2605.00649 — RCO: Model Compression with Exact Budget Constraints via Riemannian Manifolds
- https://github.com/IST-DASLab/GSQ — reference implementation
- https://github.com/IST-DASLab/RCO — reference implementation
- https://velstech.net/qwen38-27b-gsq-rco-rx6800m — independent test on a 12-GB laptop (RX 6800M)