L’ANALISI
llama.cpp: fix InternVL, cosa controllare nei test
llama.cpp b12029 corregge l’ordine del token CLS in InternVL. Il confronto va ripetuto sul proprio modello: non è un benchmark generale.
In breve: llama.cpp b12029 modifica il percorso visivo InternVL, non i pesi del modello: corregge la posizione del token CLS rispetto alle patch. È un aggiornamento da valutare per chi usa quella famiglia con mtmd; non prova che tutti i modelli multimodali siano diventati più accurati.
Verifica documentale della release REST, della pull request integrata e del diff. Non abbiamo eseguito InternVL, compilato questa build o riprodotto il confronto. La release è contrassegnata prerelease dall’API GitHub.
Che cosa corregge il runtime?
Il diff sposta il token CLS prima delle patch e cambia l’offset con cui viene escluso dal tensore finale. Il problema descritto riguarda la coerenza con la tabella delle posizioni. Per il lettore la distinzione utile è tra modificare l’elaborazione delle immagini e sostituire il modello: qui il cambiamento è nel runtime. Diff del percorso InternVL.
Quali prove presenta l’autore?
La pull request confronta embedding proiettati con il codice InternVL originale in fp32, tile da 448 e mmproj f32. Riporta inoltre la trascrizione di una pagina di dodici righe. Sono evidenze circoscritte: somiglianza degli embedding e correttezza di una trascrizione non equivalgono a un benchmark OCR completo. Pull request 30886: motivazione e prove dichiarate.
Quale build contiene la modifica?
La release GitHub b12029 punta al commit d5ef408e20c02ff015c2580de25a1860d4d1fbd7 e include la modifica. L’API la indica come prerelease. Conservare tag e commit nella scheda del proprio esperimento è più preciso che annotare soltanto di aver usato l’ultima versione. Release ufficiale llama.cpp b12029.
Come confrontare due esecuzioni senza confondere le cause?
Un protocollo proposto è riutilizzare lo stesso documento, prompt, modello, proiettore e impostazioni di generazione, cambiando soltanto il runtime. Annotare separatamente omissioni, sostituzioni e ripetizioni. Usare anche immagini già risolte correttamente: un miglioramento su una pagina non deve nascondere una regressione sulle altre. Questo protocollo non è stato eseguito qui. Pull request 30886: motivazione e prove dichiarate.
Condizioni e limitazioni
Le misure della pull request riguardano configurazioni specifiche e tre immagini. Non stabiliscono un guadagno generale di accuratezza o velocità, né garantiscono lo stesso risultato con altri modelli e quantizzazioni.
Checklist pratica
- Annotare build, commit, modello e hash del proiettore usato.
- Preparare un piccolo insieme di documenti senza dati personali, con trascrizione di riferimento.
- Bloccare prompt e impostazioni prima del confronto.
- Confrontare errori per documento, non soltanto una media o una schermata favorevole.
- Conservare il runtime precedente e valutare il ritorno alla versione nota se compaiono regressioni.