L’ANALISI
llama.cpp b11158 su Adreno: come verificare le cooperative matrix Vulkan
La build b11158 abilita il percorso KHR cooperative matrix sulle GPU Adreno. Cosa cambia, quali artefatti usare e come misurare il risultato.
In breve: Il delta pratico è nel backend Vulkan: b11158 abilita il supporto cooperative matrix per Adreno e corregge il percorso mul_mat_s. La release offre binari Snapdragon per Linux arm64 e Android arm64, ma non include misure di velocità o stabilità. Serve quindi un confronto controllato con la build precedente sullo stesso dispositivo.
Che cosa cambia nel backend Vulkan
La modifica abilita il percorso cooperative matrix del backend Vulkan sulle GPU Adreno e corregge mul_mat_s. Le cooperative matrix permettono al runtime di usare primitive matriciali offerte dal driver, ma l’effetto reale dipende dall’implementazione Vulkan del dispositivo e dalla forma delle operazioni del modello.
Quali artefatti sono disponibili
La pagina della build include pacchetti Snapdragon per Linux arm64 e Android arm64, oltre agli artefatti generali per desktop e mobile. Questo rende il test più accessibile, ma non sostituisce la verifica dell’estensione KHR e del driver effettivamente esposto dal dispositivo.
Perché è un delta pratico
Il cambiamento riguarda ciò che si può eseguire e misurare oggi su dispositivi Adreno: non è soltanto una proposta o una modifica documentale. Chi usa llama.cpp su Snapdragon può confrontare il nuovo percorso Vulkan con la build precedente e con CPU, mantenendo invariati modello, quantizzazione e prompt.
Limiti e condizioni
b11158 è marcata come pre-release e non contiene benchmark ufficiali Adreno. Non sono dichiarati dispositivi, versioni driver, regressioni o vantaggi medi. Un risultato positivo su un SoC non va esteso automaticamente all’intera famiglia Adreno.
Checklist pratica
- Identificare SoC, GPU Adreno, versione Android o Linux e driver Vulkan.
- Verificare che il dispositivo esponga l’estensione cooperative matrix richiesta.
- Scaricare il pacchetto Snapdragon b11158 e conservarne nome e checksum.
- Usare lo stesso GGUF, quantizzazione, contesto e prompt della build precedente.
- Confrontare Vulkan, CPU e b11156 registrando prompt processing, token al secondo, memoria e temperatura.
- Ripetere il test dopo un riavvio e annotare crash, fallback o output divergenti.
- Mantenere la build precedente pronta per il rollback.