16 GB bastano: la tabella di misurazioni Qwen3.8-27B GGUF
TL;DR: IST-DASLab fornisce Qwen3.8-27B in GGUF in quattro dimensioni — da 8,4 a 11,8 GB. Il livello consigliato IQ3_S mantiene il 99,8 % delle prestazioni di base con una riduzione di 4,6× e sta interamente sulle GPU 16 GB di fascia media. Questo articolo porta la tabella dei file, i tassi di token misurati e una regola di decisione per l'uso batch rispetto a quello interattivo.
Cosa cambiano concretamente GSQ e RCO
Le due abbreviazioni indicano una procedura in due stadi che supera le note quantizzazioni dinamiche Unsloth a parità di dimensione del file.
GSQ (Gumbel-Softmax Quantization) quantizza ogni tensore singolarmente: apprende l'assegnazione della griglia per coordinata e le scale per gruppo congiuntamente tramite un rilassamento Gumbel-Softmax. L'effetto: a 2–3 bit per peso, GSQ colma il divario tra quantizzazione scalare e vettoriale, restando un GGUF standard eseguibile in llama.cpp, Ollama e LM Studio.
RCO (Riemannian Constrained Optimization) distribuisce poi i tipi di quantizzazione sui tensori. Il limite di budget di dimensione è formulato come varietà riemanniana lisciata nello spazio dei logit, così il gradiente ottimizza direttamente sulla perdita del task — senza mai violare il budget.
Il risultato per file non è uniforme ma ottimizzato a livello di tensore. Nel workflow nulla cambia: sono normali file GGUF.
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
La tabella di misurazioni: ingombro per livello di file
I quattro file pubblicati con il vero bits-per-weight medio dell'intero file, più i valori di benchmark della model card contro la base BF16 (53,8 GB):
| File | bpw | Dimensione | AIME25 | GPQA-Diamond | LiveCodeBench v6 | Valutazione |
|---|---|---|---|---|---|---|
| IQ2_XS | 2,50 | 8,4 GB | 96,67 | 84,85 | 76,57 | livello minimo, zero-shot sopra BF16 |
| IQ2_S | 2,75 | 9,3 GB | 100,00 | 86,36 | 82,29 | raggiunge il livello base su AIME25 |
| IQ3_XXS | 3,00 | 10,1 GB | 100,00 | 88,89 | 84,57 | punto polivalente forte |
| IQ3_S | 3,50 | 11,8 GB | 100,00 | 89,39 | 85,71 | consigliato: senza perdita di task (99,8 % media) |
| Base BF16 | 16,00 | 53,8 GB | 100,00 | 89,90 | 85,71 | riferimento |
Tre osservazioni che sostengono la decisione d'acquisto:
- IQ3_S è il punto ideale. AIME25 e LiveCodeBench sono riprodotti esattamente; su GPQA-Diamond mancano solo 0,51 punti — con una riduzione di 4,6×.
- Il vantaggio cresce sui file piccoli. A 8,4 GB, IQ2_XS precede UD-IQ2_S di pari dimensione di 10,00 punti su AIME25 e 8,59 su GPQA-Diamond.
- Ci sono extra: un file mmproj (BF16, 0,9 GB) per l'input vision e build -mtp opzionali (+0,35 GB) con testa Multi-Token-Prediction per la decodifica speculativa — stessa qualità, più velocità.
Velocità nella pratica: schede da 16 GB a confronto
I valori della model card sono adimensionali; per la velocità contano le misurazioni della community su hardware reale. Punti di ancoraggio segnalati:
| Scheda / impostazione | Risultato |
|---|---|
| RTX 5090 (fiore all'occhiello desktop) | ~136 tok/s con IQ3_S, contesto lungo |
| RTX 5060 Ti 16 GB (desktop) | ~40 tok/s medi, 552 tok/s di prefill a 112k di contesto |
| 5060 Ti, contesto 112k pieno | 17–30 tok/s, ~25–30 verso la fine della finestra |
| RX 6800M 12 GB (laptop) | IQ3_S riempie quasi la scheda (97 % a 4K di contesto); IQ2_XS lascia ~1,3 GB di margine |
Lo schema: tra 40 e 136 tok/s la classe 27B sta comodamente sopra la velocità di lettura. Con contesti lunghi il tasso cala perché la cache KV cresce — Qwen3.8 è un ibrido gated-delta-net con attenzione lineare nella maggior parte dei layer, il che riduce la tassa di contesto rispetto ai transformer puri senza eliminarla.
Regola di decisione: 40 tok/s bastano?
Sì, per tutto l'interattivo. 40 tok/s corrispondono circa al doppio della velocità di lettura umana; il testo in streaming appare fluido.
Per la classificazione secondo l'uso:
- Sessioni interattive (chat, loop di agenti): IQ3_S su scheda da 16 GB. Gli 11,8 GB lasciano 3–4 GB per cache KV e attivazioni — contesti fino a ~100k sono praticamente utilizzabili.
- Job batch (classificazione, estrazione, molti documenti): IQ2_XS o IQ2_S. A 8,4–9,3 GB stanno persino su vecchie schede da 12 GB con spazio per batch più grandi; i 3–4 punti in meno su GPQA raramente contano per task brevi e formali.
- Multimodale: il livello IQ corrispondente più il file mmproj da 0,9 GB — identico per tutti i livelli.
Il punto dei 16 GB è la soglia vera: con la vecchia logica di quantizzazione uniforme un modello denso 27B richiedeva 18–20 GB. La ricerca per tensore lo spinge sotto il bordo — e le assegnazioni sono nel repo come .rco-allocation.txt, quindi verificabili.
Il limite: il denso 27B tocca la sua fine
La compressione densa ha un pavimento duro: a 2,5 bpw la media di task è vicina al valore base; sotto, collassa. Chi vuole più parametri cambia architettura — i modelli MoE con layer streaming da NVMe (es. Kimi K3 2,8T su quattro SSD) aggirano il bordo RAM ma scendono a ~1 tok/s. Tra questi due poli sta la classe densa 27B: un modello completo in RAM, misurazioni a 40–136 volte il tasso dell'offload. Per la maggior parte dei setup laptop 2026, IQ3_S è il punto finale razionale.
FAQ
Quale file GGUF prendo su una scheda da 16 GB? Prendi IQ3_S da 11,8 GB se ti serve la piena qualità del modello e lavori con 100k–112k di contesto. Prendi IQ2_S da 9,3 GB se vuoi più margine per batch grandi o finestre lunghe — raggiunge già il livello base AIME25. IQ2_XS è la scelta per i laptop da 12 GB, dove 8,4 GB più mmproj stanno ancora con aria tra i layout.
40 tok/s sulla 5060 Ti è un valore fisso? No, il tasso dipende dal contesto: fino a ~50 tok/s misurati all'inizio della finestra, ~25–30 tok/s verso la fine di un contesto 112k pieno. Il prefill da 552 tok/s non è influenzato, perché gira in parallelo sui token del prompt. Pianifica un intervallo invece di un numero nel calcolare le latenze degli agenti.
Mi serve la variante -mtp? Se usi llama.cpp con decodifica speculativa: sì, la testa MTP costa solo 0,35 GB e accelera misurabilmente la decodifica senza cambiare i pesi. La qualità resta identica perché l'assegnazione tensoriale di base è la stessa. Senza supporto MTP nell'harness, basta il file standard.
Qual è la differenza rispetto alle quantizzazioni dinamiche Unsloth? Entrambe sono ottimizzate per tensore, ma GSQ+RCO danno più punti a dimensione uguale o minore: a 8,4 GB IQ2_XS guida con 10 punti su AIME25; a ~12 GB IQ3_S guida con 3,33 punti in meno di 0,2 GB di dimensione. Su GPQA-Diamond UD-IQ3_S è marginalmente avanti (0,51 punti) — un trade-off irrilevante al 99,8 % di media di task.
Come verifico da me l'assegnazione di un file? Ogni livello include un file tensor-allocation nel repo con il tipo di quantizzazione assegnato per tensore più l'istogramma delle larghezze di bit. Così si controlla il rispetto del budget senza caricare il modello. In aggiunta, è inclusa la matrice di importanza (imatrix-qwen3.8-27b.gguf, 1000 × 4096 token), che rende riproducibile la quantizzazione.
Fonti
- https://huggingface.co/ISTA-DASLab/Qwen3.8-27B-GSQ-RCO-GGUF — model card con la tabella di misurazioni completa (consultata il 17.09.2026)
- https://huggingface.co/ISTA-DASLab/Qwen3.8-27B-GSQ-RCO-GGUF/discussions/6 — misurazioni della community su RTX 5060 Ti (contesto 112k)
- https://arxiv.org/abs/2604.18556 — GSQ: quantizzazione scalare ad alta precisione e bassa precisione via campionamento Gumbel-Softmax
- https://arxiv.org/abs/2605.00649 — RCO: compressione di modelli con vincoli esatti di budget via varietà riemanniane
- https://github.com/IST-DASLab/GSQ — implementazione di riferimento
- https://github.com/IST-DASLab/RCO — implementazione di riferimento
- https://velstech.net/qwen38-27b-gsq-rco-rx6800m — test indipendente su laptop da 12 GB (RX 6800M)