16 GB sind genug: die Qwen3.8-27B-GGUF-Mess-Tabelle
TL;DR: Das IST-DASLab liefert Qwen3.8-27B als GGUF in vier Größen — von 8,4 bis 11,8 GB. Die empfohlene IQ3_S-Stufe hält 99,8 % der Basisleistung bei 4,6-facher Verkleinerung und passt damit komplett auf 16-GB-Grafikkarten der Mittelklasse. Dieser Artikel bringt die Dateitabelle, gemessene Token-Raten und eine Entscheidungsregel für Batch- gegenüber interaktiven Einsatz.
Was GSQ und RCO konkret ändern
Die beiden Abkürzungen stehen für ein zweistufiges Verfahren, das die bekannten Unsloth-Dynamic-Quantisierungen bei gleicher Dateigröße schlägt.
GSQ (Gumbel-Softmax Quantization) quantisiert jeden Tensor einzeln: Es lernt die Gitter-Zuordnung pro Koordinate und die Skalen pro Gruppe gemeinsam über eine Gumbel-Softmax-Relaxierung. Der Effekt: Bei 2 bis 3 Bits pro Gewicht schließt GSQ die Lücke zwischen Scalar- und Vektor-Quantisierung, bleibt aber als Standard-GGUF in llama.cpp, Ollama und LM Studio lauffähig.
RCO (Riemannian Constrained Optimization) verteilt dann die Quantisierungstypen auf die Tensors. Die Größenbudget-Grenze wird als geglättete Riemannsche Mannigfaltigkeit im Logit-Raum formuliert, sodass per Gradient direkt auf den Task-Loss optimiert wird — ohne dass das Budget je verletzt wird.
Das Ergebnis pro Datei ist nicht uniform, sondern tensor-genau optimiert. Für den Nutzer ändert sich am Workflow nichts: Es sind normale GGUF-Dateien.
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
Die Mess-Tabelle: Fußabdruck pro Dateistufe
Die vier Releasedaten mit dem echten Durchschnitts-Bitwert der ganzen Datei. Dazu die Benchmark-Werte der Model Card gegen den BF16-Base (53,8 GB):
| Datei | bpw | Größe | AIME25 | GPQA-Diamond | LiveCodeBench v6 | Einordnung |
|---|---|---|---|---|---|---|
| IQ2_XS | 2,50 | 8,4 GB | 96,67 | 84,85 | 76,57 | kleinste Stufe, Zero-Shot über BF16 |
| IQ2_S | 2,75 | 9,3 GB | 100,00 | 86,36 | 82,29 | erreicht Basisniveau auf AIME25 |
| IQ3_XXS | 3,00 | 10,1 GB | 100,00 | 88,89 | 84,57 | starker Allround-Punkt |
| IQ3_S | 3,50 | 11,8 GB | 100,00 | 89,39 | 85,71 | empfohlen: task-lossless (99,8 % Task-Schnitt) |
| BF16-Base | 16,00 | 53,8 GB | 100,00 | 89,90 | 85,71 | Referenz |
Drei Beobachtungen, die die Kaufentscheidung tragen:
- IQ3_S ist der Süßpunkt. AIME25 und LiveCodeBench werden exakt reproduziert, auf GPQA-Diamond fehlen nur 0,51 Punkte — bei 4,6-facher Verkleinerung.
- Der Vorsprung wächst bei kleinen Dateien. Auf 8,4 GB führt IQ2_XS gegen das gleich große UD-IQ2_S mit 10,00 Punkten auf AIME25 und 8,59 auf GPQA-Diamond.
- Es gibt Extras: eine mmproj-Datei (BF16, 0,9 GB) für Vision-Eingabe und optionale -mtp-Builds (+0,35 GB) mit Multi-Token-Prediction-Head für Speculative Decoding — gleiche Qualität, mehr Tempo.
Tempo in der Praxis: 16-GB-Karten im Messvergleich
Die Model-Card-Werte sind dimensionslos; für die Geschwindigkeit zählen Community-Messungen auf echte Hardware. Gemeldete Ankerpunkte:
| Karte / Setting | Ergebnis |
|---|---|
| RTX 5090 (Desktop-Flaggschiff) | ~136 tok/s mit IQ3_S, long context |
| RTX 5060 Ti 16 GB (Desktop) | ~40 tok/s im Mittel, 552 tok/s Prefill bei 112k Kontext |
| 5060 Ti, 112k Kontext gefüllt | 17–30 tok/s, gegen Ende des Fensters ~25–30 |
| RX 6800M 12 GB (Notebook) | IQ3_S füllt die Karte fast (97 % bei 4K Kontext); IQ2_XS lässt ~1,3 GB Puffer |
Das Muster: Zwischen 40 und 136 tok/s liegt die 27B-Klasse komfortabel über der Lesegeschwindigkeit. Bei langen Kontexten fällt die Rate, weil der KV-Cache mit wächst — Qwen3.8 ist ein Gated-Delta-Net-Hybrid mit linearem Attention in den meisten Layern, was die Kontext-Steuer gegenüber reinen Transformerarchitekturen senkt, aber nicht eliminiert.
Entscheidungsregel: 40 tok/s — reicht das?
Ja, für alles Interaktive. 40 tok/s entsprechen etwa dem Doppelten der menschlichen Lesegeschwindigkeit; Streaming-Text erscheint flüssig.
Für die Einordnung nach Einsatz:
- Interactive Sessions (Chat, Agent-Loops): IQ3_S auf 16-GB-Karte. Die 11,8 GB lassen 3–4 GB für KV-Cache und Aktivierungen — Kontexte bis ~100k sind damit praktisch nutzbar.
- Batch-Jobs (Klassifikation, Extraktion, viele Dokumente): IQ2_XS oder IQ2_S. 8,4–9,3 GB passen sogar auf ältere 12-GB-Karten mit Luft für größere Batches; die 3–4 Punkte weniger auf GPQA sind bei kurzen, formatischen Tasks selten relevant.
- Multimodal: jeweils die passende IQ-Stufe plus die 0,9-GB-mmproj-Datei — sie ist für alle Stufen identisch.
Der 16-GB-Punkt ist dabei die eigentliche Schwelle: Mit der alten Uniform-Quantisierungslogik brauchte ein 27B-Dense-Modell 18–20 GB. Die per-Tensor-Suche drückt es unter die Kante — und die Zuweisungen liegen als .rco-allocation.txt im Repo, also nachprüfbar.
Die Grenze: Dense-27B stößt an ihr Ende
Dense-Kompression hat eine harte Untergrenze: bei 2,5 bpw ist der Task-Schnitt nahe dem Basiswert, darunter kollabiert er. Wer mehr Parameter will, wechselt die Architektur — MoE-Modelle mit Layer-Streaming von der NVMe (z. B. 2,8T Kimi K3 über vier SSDs) umgehen die RAM-Kante, fallen aber auf ~1 tok/s. Zwischen diesen beiden Polen liegt die 27B-Dense-Klasse: ein vollständiges Modell im RAM, Messwerte im 40- bis 136-fachen der Offload-Taktung. Für die meisten Laptop-Setups 2026 ist IQ3_S damit der rationale Endpunkt.
FAQ
Welche GGUF-Datei nehme ich auf einer 16-GB-Karte? Nimm IQ3_S mit 11,8 GB, wenn du die volle Modellqualität brauchst und mit 100k–112k Kontext arbeitest. Nimm IQ2_S mit 9,3 GB, wenn du mehr Puffer für große Batches oder lange Fenster willst — es erreicht bereits das AIME25-Basisniveau. IQ2_XS ist die Wahl für 12-GB-Notebooks, wo 8,4 GB plus mmproj noch mit Luft zwischen den Layouts passt.
Ist 40 tok/s auf der 5060 Ti ein fester Wert? Nein, die Rate hängt am Kontext: zu Beginn eines Fensters wurden bis ~50 tok/s gemessen, gegen Ende bei vollem 112k-Kontext ~25–30 tok/s. Der Prefill-Durchsatz von 552 tok/s bleibt davon unberührt, weil er parallel über die Prompt-Tokens läuft. Plane also eine Spanne ein statt einer Zahl, wenn du Latenzen für Agents kalkuliers.
Brauche ich die -mtp-Variante? Wenn du llama.cpp mit Speculative Decoding fährst: ja, der MTP-Head kostet nur 0,35 GB und beschleunigt die Dekodierung messbar, ohne die Gewichte zu verändern. Die Qualität bleibt identisch, weil die Basis-Tensorzuweisung dieselbe ist. Ohne MTP-Unterstützung im Harness reicht die Standarddatei.
Was ist der Unterschied zu Unsloth-Dynamic-Quantisierungen? Beide sind per-Tensor-optimiert, aber GSQ+RCO liefern bei gleicher oder kleinerer Datei mehr Punkte: bei 8,4 GB führt IQ2_XS mit 10 Punkten auf AIME25, bei ~12 GB führt IQ3_S mit 3,33 Punkten bei 0,2 GB weniger Größe. Auf GPQA-Diamond liegt UD-IQ3_S minimal (0,51 Punkte) vorn — ein Trade-off, der bei 99,8 % Task-Schnitt praktisch keine Rolle spielt.
Wie prüfe ich die Zuweisung einer Datei selbst nach? Jede Stufe shippt eine tensor-allocation-Datei im Repo, in der der zugewiesene Quantisierungstyp pro Tensor plus das Bitwert-Histogramm steht. Damit lässt sich die Budget-Einhaltung prüfen, ohne das Modell zu laden. Ergänzend liegt die Importance-Matrix (imatrix-qwen3.8-27b.gguf, 1000 × 4096 Tokens) bei, mit der die Quantisierung reproduzierbar ist.
Sources
- https://huggingface.co/ISTA-DASLab/Qwen3.8-27B-GSQ-RCO-GGUF — Modell-Karte mit vollständiger Mess-Tabelle (abgerufen 17.09.2026)
- https://huggingface.co/ISTA-DASLab/Qwen3.8-27B-GSQ-RCO-GGUF/discussions/6 — Community-Messungen auf RTX 5060 Ti (112k Kontext)
- 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 — Referenzimplementierung
- https://github.com/IST-DASLab/RCO — Referenzimplementierung
- https://velstech.net/qwen38-27b-gsq-rco-rx6800m — Independent-Test auf 12-GB-Notebook (RX 6800M)