Quanta memoria GPU serve per la ricerca visivo-linguistica su un NAS domestico?
La ricerca basata sulla visione e sul linguaggio può iniziare con circa 8–12 GB di VRAM, ma le dimensioni del modello, la quantizzazione, i token delle immagini, la lunghezza del contesto e la concorrenza determinano il limite minimo affidabile.
Un modello quantizzato compatto della classe 7B può essere caricato su una GPU da 8 GB, ma potrebbe non riuscire a elaborare insieme diverse immagini ad alta risoluzione e una lunga cronologia della chat. La ricerca può inoltre utilizzare un encoder delle immagini e un reranker separati. La capacità deve includere le allocazioni di picco durante l’esecuzione, non solo le dimensioni del file del modello mostrate sul disco durante il tipo di query più intenso previsto.
I pesi stabiliscono il limite minimo, non il picco
La memoria teorica dei pesi equivale al numero di parametri moltiplicato per i bit per parametro. Sette miliardi di parametri a quattro bit occupano circa 3,5 GB prima di considerare scale, metadati, buffer del framework ed eventuali livelli non quantizzati. Un encoder delle immagini può essere separato o integrato nel modello.
Una spiegazione pratica dei componenti della memoria GPU distingue i pesi del modello dalla cache KV, dalle attivazioni e dall’overhead di runtime. Le sole dimensioni del file sottostimano quindi la memoria necessaria per l’inferenza.
La quantizzazione riduce la permanenza dei pesi in memoria, ma non riduce tutte le allocazioni nella stessa misura. Le proiezioni della visione, i buffer temporanei dell’attenzione e alcuni kernel possono rimanere in precisione a 16 bit. Un modello che si carica appena non lascia margine per query reali con immagini.
Le immagini diventano token e stato di runtime
Gli encoder della visione dividono o ricampionano le immagini in patch, quindi passano i token visivi al modello linguistico. Più immagini, una risoluzione accettata più elevata o il tiling dinamico aumentano il numero di token. Questi token aumentano il lavoro dell’attenzione e, nelle fasi autoregressive, la richiesta di cache KV.
La ricerca sul visual instruction tuning mostra come le immagini vengano collegate ai modelli linguistici tramite rappresentazioni visive apprese. L’architettura e la preelaborazione determinano quante caratteristiche visive entrano nel contesto.
L’elaborazione in batch di diverse ricerche moltiplica lo stato attivo delle immagini e del testo, anche quando i pesi rimangono condivisi. Per questo una fascia da 8–12 GB è adatta alla ricerca compatta per un singolo utente, mentre 16–24 GB offrono più spazio per modelli più grandi, più immagini o richieste simultanee.
Quando le raccomandazioni sulla VRAM non sono più applicabili
I sistemi a memoria unificata, l’offload sulla CPU, gli encoder suddivisi e la ricerca degli embedding basata su disco modificano il vincolo. L’offload può consentire l’esecuzione di un modello con meno VRAM, ma aumentare la latenza. Gli embedding delle immagini precalcolati richiedono molto meno lavoro di visione a runtime rispetto alla generazione di descrizioni per ogni query.
Una discussione sull’allocazione della cache KV illustra come la lunghezza del contesto e l’allocazione della cache KV possano imporre limiti più bassi anche quando i pesi rientrano nella memoria disponibile. Gli input multimodali restringono ulteriormente lo stesso budget.
Questi intervalli non valgono nemmeno per l’addestramento o il fine-tuning, che richiedono gradienti e stato dell’ottimizzatore. Descrivono esclusivamente l’inferenza. Una maggiore quantità di VRAM non garantisce una ricerca accurata se gli embedding delle immagini, l’OCR, la fusione dei metadati o la valutazione sono carenti.
Verifica la VRAM di picco con query rappresentative contenenti immagini
Carica il modello quantizzato, l’encoder e il reranker previsti, quindi esegui query rappresentative con una singola immagine, più immagini, immagini ad alta risoluzione e una cronologia lunga. Ripeti i test con la concorrenza pianificata, registrando la VRAM allocata e riservata, gli eventi di memoria insufficiente, la latenza al primo token e il tempo di elaborazione delle immagini.
Testa con un dataset della larghezza di banda della pipeline delle immagini che rifletta immagini e screenshot realizzati dai creator, anziché input sintetici vuoti. Mantieni separati i percorsi con embedding precalcolati e quelli con codifica in tempo reale.
Seleziona una fascia di VRAM il cui caso peggiore valido rimanga al di sotto di circa l’80–85% della capacità. Se il picco riguarda solo la codifica delle immagini, sposta quell’encoder o precalcola gli embedding. Se domina la cache KV, limita il contesto o la concorrenza prima di presumere che sia necessario un modello di visione più grande.
Prodotti consigliati
Hub Tecnologico e AI
Altro da leggere
Come misurare la qualità del recupero RAG locale e interpretare recall, precisione e copertura delle citazioni
Crea un set di test RAG locale, calcola le metriche di base del recupero, interpretane i compromessi e verifica se le affermazioni nelle risposte...
Perché l’elaborazione delle funzionalità della casa intelligente diventa più importante all’aumentare del numero di sensori con la stessa frequenza di campionamento?
Monitora i calcoli per sensore e tra sensori all’aumentare del numero di dispositivi, identifica i costi di fusione non lineari e valuta le prestazioni...
Perché il costo della valutazione RAG diventa più importante con l’aumentare della libreria di documenti, a parità di volume di query?
Comprendi perché la crescita del corpus aumenta lo sforzo di valutazione del RAG senza un aumento delle query degli utenti e come i test...
