L’ANALISI
llama.cpp b10731 elimina un collo di bottiglia nello speculative decoding di Qwen
La build b10731 aggiunge il rollback dello stato ricorrente per Qwen4exp/MTP. Nel test pubblicato dal progetto, Qwen3.8-Flash-Next UD-Q4_K_XL raggiunge 183 tok/s sul codice e 144 tok/s sulla prosa, contro 123 e 83 tok/s prima della modifica.
Risposta diretta: La patch evita di serializzare l’intero stato ricorrente nella memoria host a ogni round quando alcuni token draft vengono rifiutati. Nel setup dichiarato dal progetto il costo del rollback scende abbastanza da rendere utile il draft MTP.
Il problema corretto
Senza il rollback, il server classifica il contesto come stato completo e copia lo stato ricorrente verso la memoria host a ogni ciclo. Quel costo può superare il lavoro risparmiato dallo speculative decoding.
Come cambia il rollback
La cache ricorrente dispone già di piani snapshot. La modifica salva una fotografia per slot, ciascuna terminata un token prima, così lo stato delle convoluzioni può tornare al punto corretto dopo il rifiuto dei token draft.
I numeri pubblicati
Con Qwen3.8-Flash-Next UD-Q4_K_XL, draft MTP standalone, n-max 3 e un solo slot, il progetto riporta 183 tok/s sul codice e 144 tok/s sulla prosa. La stessa branch prima della patch misura 123 e 83 tok/s; senza draft 108 tok/s.
Condizioni e limiti
I numeri sono misure dell’autore, non un benchmark indipendente. Mancano hardware, consumo di memoria, distribuzione delle accettazioni e controllo della qualità. Un test locale deve fissare tutti questi elementi prima di attribuire il delta alla patch.
Procedura verificabile
- scaricare b10731 e la build precedente dallo stesso canale
- usare lo stesso GGUF, backend, prompt, seed e contesto
- fissare draft model, n-max e numero di slot
- registrare tok/s, RAM o VRAM e tasso di accettazione
- ripetere codice e prosa per almeno tre run
- controllare che l’output non cambi in qualità o correttezza