L’ANALISI
llama.cpp Vulkan: cosa cambia con top-k radix nella build b10712
La build b10712 non promette un aumento generico di velocità. Introduce un percorso Vulkan specifico per il top-k ampio usato dalla Qwen Sparse Attention di Qwen3.8 Flash Next, con vantaggi misurati soprattutto quando il contesto cresce.
In breve: llama.cpp b10712 può accelerare Qwen3.8 Flash Next su Vulkan quando il modello usa il suo top-k interno da 2048 o più elementi e il contesto è già lungo. Non è il parametro --top-k del sampling e non rende automaticamente più veloce qualsiasi GGUF.
Che cosa cambia davvero in llama.cpp b10712
La release b10712 aggiunge al backend Vulkan uno shader radix-select per operazioni top-k con k ≥ 1024. La modifica nasce per Qwen3.8 Flash Next, che nella propria Qwen Sparse Attention seleziona almeno 2048 posizioni rilevanti prima di calcolare l’attenzione.
Qui c’è una distinzione importante. Il top-k ottimizzato dalla patch è un’operazione interna del modello, usata dall’indicizzatore dell’attenzione sparsa. Non coincide con il comune parametro di generazione --top-k 20, che limita i token candidati durante il sampling. La mia prima lettura parlava del sampling: era imprecisa e l’ho corretta dopo aver verificato la pull request.
I benchmark pubblicati dall’autore della patch
La pull request #28032 confronta il vecchio percorso Vulkan con radix-select e con la fusione dell’indicizzatore QSA. Questi sono risultati dell’autore, non ancora una mia replica.
AMD 8060S, contesto 16K
Prompt: 183,3 → 219,9 tok/s
Generazione: 15,82 → 18,21 tok/s
AMD 8060S, contesto 32K
Prompt: 145,8 → 179,5 tok/s
Generazione: 12,84 → 15,16 tok/s
DGX Spark, contesto 32K
Prompt: 390,1 → 520,8 tok/s
Generazione: 12,02 → 19,78 tok/s
Contesto iniziale
Sull’AMD 8060S il nuovo percorso è leggermente più lento a profondità zero. Il vantaggio emerge quando cresce il contesto.
Calcolando dai valori pubblicati, sull’AMD 8060S il guadagno a 32K è circa il 23% nel prompt processing e il 18% nella generazione. Sul DGX Spark, a 32K, il prompt processing cresce di circa il 34% e la generazione di circa il 65%. Questi numeri valgono per quella configurazione e per quel modello.
Chi può aspettarsi un vantaggio
- chi esegue Qwen3.8 Flash Next con llama.cpp e backend Vulkan;
- chi lavora con contesti già lunghi, dove la selezione top-k dell’attenzione sparsa pesa di più;
- chi usa hardware e driver compatibili con il nuovo shader Vulkan.
Non userei questa release come prova che “Vulkan è più veloce” in generale. Modello, quantizzazione, driver, profondità del contesto e percorso effettivamente eseguito possono cambiare completamente il risultato.
Come farei un test utile
- stesso file GGUF e stesso backend Vulkan;
- build precedente e b10712, senza cambiare altri componenti;
- stessi prompt, seed, batch, contesto e parametri;
- misure separate a contesto iniziale, 16K e 32K;
- prompt processing e generazione registrati separatamente;
- almeno cinque ripetizioni, riportando mediana e dispersione.
Sul mio Beelink con Radeon 8060S il test ha senso proprio perché coincide con uno degli hardware usati nella pull request. Finché non eseguo la replica, però, tratto i valori come benchmark dell’autore e non come un risultato mio.
La conclusione pratica
b10712 è interessante non perché “ottimizza Vulkan”, ma perché rimuove un collo di bottiglia preciso della Qwen Sparse Attention quando il contesto diventa lungo. Per chi usa altri modelli o prompt corti potrebbe cambiare poco; per Qwen3.8 Flash Next a 16K e 32K, i dati pubblicati meritano una prova controllata.
FONTI VERIFICATE