L’ANALISI
llama.cpp: tag GGUF corretti e limiti delle viste
llama.cpp b12100 evita lo scambio F16/BF16; b12102 controlla le viste in base agli stride. Due prerelease, senza benchmark indipendenti.
In breve: llama.cpp b12100 corregge la selezione del file GGUF tramite -hf: F16 non deve corrispondere a BF16. La successiva b12102 controlla le viste tensoriali con gli stride reali. Sono due prerelease del 4 novembre 2026, non risultati prestazionali. llama.cpp b12100: correzione del matching -hf.
Metodo: lettura delle release ufficiali e dei commit associati, senza installazione dei binari, esecuzione dell'intera suite upstream o test su GPU. Le indicazioni operative qui sotto sono una procedura proposta, non una prova già svolta da Francesco.
Perché :F16 poteva scaricare un altro file?
Il resolver cercava il tag anche dentro nomi più lunghi: BF16 contiene F16 e IQ4_XS contiene Q4_XS. Il commit di b12100 aggiunge un confine prima del tag, compreso il carattere underscore usato da alcuni repository. Il problema riguarda l'identità del file selezionato, non una conversione dei pesi da un formato all'altro. La release è stata pubblicata il 4 novembre alle 08:59, ora italiana. llama.cpp b12100: correzione del matching -hf.
Che cosa confermano i test aggiunti nel commit?
Il diff introduce casi con F16 e BF16 nello stesso insieme di file, casi Q4_XS/IQ4_XS e nomi separati da underscore. Sono fixture upstream che documentano il comportamento atteso. La loro presenza nel codice non autorizza a dichiarare che siano state eseguite in questa analisi o che ogni repository del Hub sia ora coperto. Commit 4b29d026: confini dei tag e fixture di selezione.
Che cosa cambia per le viste tensoriali?
b12102, pubblicata alle 10:12 ora italiana, sposta il controllo sui byte effettivamente raggiunti dagli stride. Il controllo precedente usava la dimensione di un tensore contiguo con la stessa forma prima di assegnare gli stride: poteva respingere viste con righe sovrapposte valide e accettare viste che raggiungevano byte oltre la sorgente. Il commit aggiorna il costruttore e il modo in cui vengono create le finestre di delta_net. llama.cpp b12102: controllo delle viste tramite stride.
Come verificare il proprio confronto fra GGUF?
Prima di confrontare qualità, memoria o tempi, conviene congelare la revisione del runtime e del repository del modello, poi registrare il percorso del file realmente risolto e il suo SHA-256. Se si prova una prerelease, il controllo va fatto in un ambiente separato con gli stessi input e la stessa configurazione del riferimento. È una raccomandazione di riproducibilità ricavata dal tipo di errore, non un miglioramento misurato qui. Commit 4b29d026: confini dei tag e fixture di selezione.
Serve un aggiornamento immediato in produzione?
Le fonti esaminate qualificano entrambi i tag come prerelease. Il delta merita attenzione se il flusso dipende dal matching -hf o dalle viste interessate, ma da queste sole note non emerge un protocollo di risposta a un incidente. La decisione prudente è riprodurre il proprio caso in staging e conservare il binario precedente per un ritorno controllato, senza attribuire al fix un CVE o uno sfruttamento che non sono stati verificati. llama.cpp b12102: controllo delle viste tramite stride.
Condizioni e limitazioni
Sono correzioni verificate nelle note e nei diff upstream, non una nostra prova del binario. Non è dimostrato un aumento di velocità né uno scenario di sfruttamento del difetto delle viste.
Checklist pratica
- Annotare commit e tag del runtime di riferimento e della prerelease da confrontare.
- Congelare la revisione del repository HF e registrare il GGUF effettivamente selezionato.
- Calcolare e conservare il SHA-256 del file prima del confronto.
- Includere un caso F16/BF16 e, se pertinente, un caso Q4_XS/IQ4_XS.
- Confrontare gli stessi input in staging e distinguere esito funzionale da prestazioni.
- Tenere disponibile il binario precedente; non promuovere la prerelease senza una prova del proprio carico.