ByteShape rilascia le quantizzazioni GGUF per Qwen 3.6 35B-A3B
ByteShape ha pubblicato le quantizzazioni GGUF del modello Qwen 3.6 35B-A3B, suddivise in due famiglie: NTP (Next Token Prediction, la previsione standard del token successivo) e MTP (Multi-Token Prediction, la previsione multi-token).
L’annuncio è apparso su Reddit (r/LocalLLaMA) a maggio 2026. Il blog ufficiale e i repository Hugging Face contengono tutti i dettagli:
- Blog: https://byteshape.com/blogs/Qwen3.6-35B-A3B/
- Modelli NTP: https://huggingface.co/byteshape/Qwen3.6-35B-A3B-GGUF
- Modelli MTP: https://huggingface.co/byteshape/Qwen3.6-35B-A3B-MTP-GGUF
Il rilascio include confronti con le quantizzazioni di Bartowski, Unsloth, Mudler e AesSedai.
NTP e MTP: due modi di generare testo
La previsione del token successivo (NTP) è il metodo classico: il modello genera un token alla volta, basandosi sulla sequenza precedente. È semplice, ben collaudato e funziona su qualsiasi hardware.
La previsione multi-token (MTP), invece, cerca di generare più token contemporaneamente. Su GPU, ByteShape ha misurato un incremento della velocità di generazione del 20–40%, a seconda del carico di lavoro. Questo però ha un costo: MTP consuma più memoria GPU durante l'esecuzione.
Di conseguenza, su schede con 16 GB di VRAM il modello MTP più grande risulta impraticabile per contesti lunghi. ByteShape consiglia di usare il variante GPU-2 MTP in questi casi. Per la CPU, invece, MTP non è consigliato: la velocità di elaborazione del prompt sulla CPU è già lenta, e MTP la peggiora. Su CPU resta preferibile la famiglia NTP.
“Pick the largest quant that fits” – per NTP, la regola è semplice: scegliete la quantizzazione più grande che entra nella memoria disponibile.
Prestazioni: non sempre meno bpw è meglio
Uno dei risultati più interessanti emersi dai benchmark è che un numero di bit per peso (bpw) più basso non è automaticamente migliore. La variante più grande tra quelle rilasciate (GPU-5, 4.15 bpw) spesso competeva – e talvolta superava – varianti con bpw inferiore, sia in qualità che in velocità di elaborazione (prompt processing e token generation).
Le eccezioni riguardano dispositivi con memoria limitata, come GPU da 16 GB e il Raspberry Pi 5. In quei casi, scendere di bpw è necessario per far entrare il modello.
Il messaggio chiave: non minimizzate il bpw ciecamente; se un modello più grande entra nel budget di memoria e contesto, potrebbe essere la scelta migliore.
Hardware utilizzato per i test
ByteShape ha testato il modello originale e le varianti quantizzate su:
- GPU: RTX 4090, RTX 5090, Pro 6000, RTX 4080, RTX 5060 Ti
- CPU: Intel i7, Intel Ultra 7, Ryzen 9, Raspberry Pi 5
Grafici completi, esperimenti e dettagli metodologici sono pubblicati nel blog ufficiale.
# Comando utilizzato dall'utente janvitos su Reddit per eseguire il modello MTP llama-server \ --fit --fit-margin 1664 \ --ctx-size 131072 \ --cache-type-k q8_0 --cache-type-v q8_0 \ --cache-type-k-draft q8_0 --cache-type-v-draft q8_0 \ --multi-token-prediction \ --draft-p-min 0.75 --draft-max 3 \ --no-mmap --mlock \ --threads 8 --temp 0.0 # Risultati su RTX 4070 Super 12 GB: # Media di 110.24 tok/s su 9 richieste # Tempo totale: 16.64 s, token predetti: 1592, draft: 1127, accettati: 986 # Tasso di accettazione aggregato: 0.8749
Report dalla community
Diversi utenti hanno condiviso i propri test con Qwen 3.6 (sia la versione 35B sia la 27B). Ecco i risultati più significativi.
Test su RTX 4070 Super (janvitos)
Con il modello Qwen3.6-35B-A3B-IQ4_XS-4.19bpw (GPU-5) MTP su una RTX 4070 Super 12 GB, l’utente ha ottenuto 110.24 tok/s medi. Ha usato llama-server con i flag sopra riportati, notando che --fit-margin potrebbe richiedere regolazioni in base alla VRAM.
Confronto MTP vs MXFP4 su RTX 2080 (Mooncast Productions)
Su una RTX 2080, l’utente ha confrontato Beellama (K/V=turbo4/turbo3 + decodifica speculativa ngram) con llama.cpp (K/V=Q8/Q4 + MTP). Il metodo MXFP4 è risultato +41% più veloce, pur utilizzando modelli 3 GB più grandi.
Degradazione a contesto estremo (Andrew Zhu)
Quando il contesto è cresciuto fino a 180.000 token, la velocità del modello Qwen3.6-27B con MTP è scesa da 60 tok/s a 20 tok/s.
Guadagni spettacolari a scala grande (Ankit Prateek)
Su una singola RTX 5090, con il modello Qwen 3.6 27B, l’MTP ha quasi raddoppiato la produttività a contesti estremi, senza perdita di qualità. Ecco i dati:
| Contesto | Quantizzazione | Senza MTP (tok/s) | Con MTP (tok/s) | Speedup |
|---|---|---|---|---|
| 128K | Q4_K_XL | 40.8 | 83.1 | 2.0× |
| 250K | Q5_K_XL | 25.3 | 54.2 | 2.1× |
“At temp=0, MTP holds a strict veto layer; logical, code, and math accuracy remain 100% intact.” – Ankit Prateek
Stacking MTP e ngram-mod (Fahd Mirza)
L’utente ha riferito che con Qwen3.6 27B, combinando MTP e ngram-mod in llama.cpp, la velocità è passata da 22 tok/s a 56 tok/s, usando solo quattro flag aggiuntivi e nessun file modello extra. MTP gestisce la generazione creativa (teste di previsione integrate nei pesi), mentre ngram-mod si occupa della ripetizione (pattern matching puro).
LM Studio e MTP in beta
Gli sviluppatori di LM Studio hanno annunciato che il supporto a Multi Token Prediction è ora in beta, richiedendo l’aggiornamento a 0.4.14+3 e il motore llama.cpp 2.15.0.
Metodologia: perché MMLU è stato escluso
ByteShape ha escluso il benchmark MMLU da questa release. Il motivo: un problema di conformità nel formato delle risposte del modello Qwen 3.6, assente in Qwen 3.5. In diversi casi, il modello in precisione piena conosceva la risposta ma non rispettava il formato richiesto dal benchmark, nonostante i prompt a 5 shot. Poiché si tratta di un comportamento del modello base, non di un artefatto di quantizzazione, MMLU è stato ritenuto un segnale rumoroso per il confronto tra quantizzazioni.
