Quando si confrontano ricette di fine-tuning con numeri di parametri addestrabili molto diversi usando un unico learning rate, si rischia di premiare l'opzione più piccola per un artefatto statistico, non per un vantaggio reale. Il caso arriva dalla compressione post-hoc della KV-cache basata su SVD, ma la lezione vale per qualunque confronto parameter-efficient.

L'artefatto del learning rate condiviso

Un modello già pre-addestrato viene convertito in una cache a basso rango in stile multi-head latent attention, fattorizzando i pesi di key e value in una proiezione verso il basso (encoder) e una verso l'alto (decoder). Dopo la troncatura, un breve fine-tuning di healing recupera l'accuratezza persa. Con un learning rate condiviso, congelare il decoder e addestrare solo l'encoder sembrava nettamente vincente rispetto a lavorare sul decoder o su entrambi i fattori. Assegnando a ciascun braccio il proprio learning rate ottimizzato, quel vantaggio scompare e l'encoder-only raggiunge la parità con le alternative.

Il meccanismo è chiaro: quando i bracci differiscono per numero di parametri, un tasso condiviso può deprimere le medie dei bracci più grandi e gonfiarne la varianza, producendo un falso segnale di robustezza multi-seed per il braccio più piccolo. Gli autori lo hanno verificato su un modello vision-language, Qwen2.5-VL-3B-Instruct, con tre seed per configurazione e un rapporto di compressione, più una replica su un banco di prova solo testo con due backbone.

Il valore per chi fa self-hosting

Il fatto che l'encoder-only healing non sia superiore non lo rende irrilevante. Mantiene un risparmio reale e misurato: 3 volte meno parametri addestrabili e 3 volte meno memoria per lo stato dell'ottimizzatore. Per chi opera in ambienti self-hosted o con vincoli di VRAM su LLM, questo si traduce in un fine-tuning più leggero e in una pipeline di retrofitting meno esigente per la compressione della KV-cache in fase di training. Non è una scorciatoia gratuita: la parità emerge solo con un tuning per braccio, e il protocollo copre un solo rapporto di compressione. Ma sposta l'attenzione dal benchmark gonfiato al risparmio concreto, che è la metrica che conta quando l'hardware è un vincolo e il TCO dipende da quanta memoria serve davvero.

La conseguenza di secondo ordine è per chi progetta benchmark: se un protocollo così diffuso può fabbricare un vantaggio apparente, i confronti futuri dovrebbero calibrare il learning rate per ciascun braccio, non trattarlo come una costante comoda. Vale anche per chi valuta approcci diversi di compressione o adattamento low-rank: senza quel controllo, si promuovono ricette non per efficienza reale ma per un artefatto di ottimizzazione. AI-RADAR segue questi nodi quando analizza i trade-off per chi valuta deployment on-premise, dove le decisioni di fine-tuning e compressione hanno effetti misurabili su memoria e costi. La prossima volta che un confronto mostra un vincitore piccolo e brillante, conviene chiedersi se il learning rate era davvero lo stesso per tutti.