Perché un runtime IA locale riserva memoria dopo una richiesta?
Un runtime AI locale riserva memoria dopo una richiesta, così i tensori futuri possono riutilizzare i blocchi del dispositivo senza sostenere nuovamente i costi di allocazione e sincronizzazione.
Il risultato visibile può sembrare una perdita di memoria: il calcolo sulla GPU scende a zero, la risposta è completa, ma il processo occupa ancora gran parte della memoria dell’acceleratore. Una parte di tale ingombro può essere costituita dai pesi attivi del modello o dallo stato KV, mentre un’altra può appartenere a un allocatore con caching, al contesto di esecuzione, alla cattura del grafo, allo spazio di lavoro delle librerie o a una policy di mantenimento attivo del modello. Le sezioni seguenti distinguono le allocazioni attive dalle prenotazioni riutilizzabili e mostrano quando la memoria persistente è normale, inefficiente o indicativa di una vera perdita.
L’allocazione sul dispositivo è abbastanza costosa da giustificare il caching
I tensori creati durante le richieste vengono creati e rilasciati ripetutamente. Restituire ogni blocco al driver può introdurre sincronizzazioni e costringere la richiesta successiva a ricostruire la stessa disposizione della memoria.
L’allocatore CUDA di PyTorch separa i blocchi dell’allocatore con caching dai tensori che rimangono allocati attivamente.
Mantenere i blocchi liberi all’interno del processo migliora la latenza delle richieste ripetute, ma un altro servizio AI non può utilizzare quei byte finché l’allocatore non li restituisce al driver.
Memoria allocata, riservata e libera sul dispositivo sono metriche diverse
La memoria allocata appartiene ai tensori attivi. La memoria riservata è gestita dall’allocatore del runtime e può includere sia allocazioni attive sia blocchi riutilizzabili attualmente inutilizzati.
Un runtime può quindi mostrare un divario nella memoria riservata anche dopo la distruzione dei tensori temporanei.
Gli strumenti del dispositivo, come nvidia-smi, riportano l’ingombro del processo visibile al driver, non quali blocchi siano logicamente liberi all’interno del framework.
Lo stato del modello e del runtime può rimanere intenzionalmente pronto
Il processo può mantenere pronti i pesi del modello, lo stato del tokenizer, i kernel, i grafi di esecuzione e i contesti dell’acceleratore, perché scaricarli trasformerebbe la richiesta successiva in un avvio a freddo.
La spiegazione di ZimaSpace sulla permanenza del modello mostra perché un servizio pronto consuma memoria anche quando nessun utente sta generando token.
Si tratta di un compromesso intenzionale tra capacità e latenza. Dal punto di vista del calcolo, la memoria è inattiva, ma rimane preziosa perché conserva lo stato già pronto.
La frammentazione può lasciare blocchi riservati difficili da riutilizzare
Un pool può contenere una quantità totale sufficiente di byte inutilizzati, mentre le dimensioni dei suoi blocchi non corrispondono alla richiesta successiva. Prompt variabili, dimensioni delle immagini, batch e cambi di modello possono creare una disposizione frammentata delle prenotazioni.
GMLake studia la frammentazione degli allocatori causata da dimensioni di allocazione irregolari.
In questo caso, la memoria trattenuta non è né attivamente utile né disponibile per altri processi, e il riavvio del processo può ripristinare temporaneamente una disposizione più ordinata.
Misura se l’ingombro si stabilizza o cresce
Esegui ripetutamente la stessa richiesta fissa e registra, dopo ogni completamento, la memoria allocata, riservata, della cache KV, dei pesi del modello e libera sul dispositivo.
Un punto massimo stabile suggerisce un comportamento normale di caching o mantenimento attivo. Un ingombro che cresce a ogni richiesta identica e non riutilizza mai i blocchi precedenti suggerisce una perdita, una cache senza limiti, una sessione mantenuta o variazioni del carico di lavoro.
Prova i controlli per il rilascio della cache solo dopo aver verificato quale stato rimuovono. Svuotare i blocchi inutilizzati dell’allocatore non scarica i pesi attivi del modello, mentre scaricare il modello può peggiorare i tempi di risposta.
Per un home server con più servizi, definisci un budget di memoria e una policy di inattività per ogni runtime, così la prenotazione di un servizio non impedisce silenziosamente l’avvio di un altro.
Prodotti consigliati
Hub Tecnologico e AI
Altro da leggere
Perché le previsioni della casa intelligente diventano meno accurate dopo i cambiamenti stagionali delle abitudini?
Le routine stagionali cambiano il rapporto tra tempo, sensori, presenza e azioni desiderate, rendendo obsoleto un modello addestrato su abitudini precedenti.
Perché un NVR domestico perde gli eventi brevi quando il rilevamento degli oggetti è attivato?
Il tracciamento necessita di un numero sufficiente di rilevamenti per avviare e confermare una traiettoria, quindi un oggetto che compare solo per poco tempo...
Perché le etichette delle foto generate dall’IA cambiano dopo un aggiornamento del modello?
Un aggiornamento del modello modifica la rappresentazione e la classificazione utilizzate per assegnare le etichette, quindi la stessa foto può oltrepassare confini semantici o...
