Cosa fa aumentare gradualmente la memoria del server del modello locale tra una richiesta e l’altra?

La memoria del server dei modelli locali tende solitamente ad aumentare perché cache e allocatori conservano blocchi riutilizzabili, anche se riferimenti senza limiti o perdite native possono causare una crescita reale.

Dopo ogni richiesta al server domestico, una dashboard può mostrare un aumento della RAM o della VRAM senza tornare al valore di base originale. Il runtime può conservare blocchi KV, voci di prefisso, kernel, grafi, aree di lavoro e blocchi di tensori liberati per riutilizzarli. Lunghezze variabili dei prompt possono frammentare i pool, mentre registri, sessioni, buffer di immagini o estensioni possono conservare gli oggetti indefinitamente; perciò questi meccanismi richiedono evidenze e limiti diversi.

Gli allocatori con caching riservano i blocchi liberati per riutilizzarli

I framework GPU evitano costose allocazioni sul dispositivo conservando i blocchi rilasciati in un pool di proprietà del processo. I tensori dell'applicazione possono non esistere più, mentre il driver continua a segnalare il pool riservato come utilizzato dal server dei modelli. Questa distinzione resta visibile durante i successivi test domestici.

Un'analisi dell'allocatore spiega come i blocchi di memoria GPU memorizzati nella cache arrotondino, dividano, uniscano e memorizzino nella cache i blocchi CUDA. Il segnale tipico è una diminuzione della memoria dei tensori allocata dopo una richiesta, mentre la memoria riservata rimane elevata e le richieste successive la riutilizzano.

Questo plateau non è automaticamente una perdita. Diventa problematico quando il pool impedisce a un altro servizio di allocare memoria o continua ad ampliarsi dopo richieste ripetute della stessa forma, una volta completato il riscaldamento. Il risultato intermedio deve restare ispezionabile prima di procedere con l'automazione.

Le cache di serving e le forme delle richieste ampliano il working set previsto

Le cache KV crescono con il contesto attivo, le cache dei prefissi conservano prompt riutilizzabili e i grafi o i kernel compilati coprono le forme di batch osservate. Nuove lunghezze del contesto, modalità e profili di concorrenza possono aggiungere voci tra una richiesta e l'altra. Questo limite deve essere misurato separatamente in condizioni operative realistiche.

La ricerca sulla frammentazione della memoria degli LLM individua la frammentazione tra gli spazi di memoria delle attivazioni e della cache KV nel serving degli LLM. Questa osservazione spiega perché la capacità totale possa aumentare anche quando nessuna singola richiesta attiva è di grandi dimensioni. La conseguenza pratica emerge quando diverse fonti competono per un contesto limitato.

Registra il numero di voci della cache e le classi di forma. Una crescita che si arresta quando la distribuzione del carico di lavoro si stabilizza indica un riscaldamento limitato; una crescita proporzionale al numero totale di richieste o agli ID di sessione univoci suggerisce l'assenza di un'evizione. Questa dipendenza deve restare esplicita nell'interfaccia finale.

Gli oggetti CPU conservati e i buffer nativi producono una crescita reale

Cronologie delle richieste, code di streaming, etichette delle metriche, output dei tokenizzatori, immagini caricate, buffer host bloccati e allocazioni delle estensioni possono restare referenziati dopo il completamento. Gli snapshot della GPU possono apparire stabili mentre l'RSS del processo continua ad aumentare. Il risultato deve quindi essere verificato rispetto alle evidenze originali.

Un'indagine pratica sulla memoria allocata rispetto a quella riservata separa i segnali relativi alla memoria allocata, riservata e del processo. Questa visione a più livelli impedisce di diagnosticare erroneamente un problema di conservazione lato CPU come un comportamento dell'allocatore GPU. Questa distinzione resta visibile durante i successivi test domestici.

Il limite del problema è un aumento una tantum seguito da un limite superiore stabile. Chiamalo perdita solo quando richieste identiche e controllate producono una crescita continua della memoria conservata dopo aver tenuto conto dei limiti della cache, della raccolta dei rifiuti e dei pool previsti.

Featured

ZimaCube 2 NAS personale cloud domestico

ZimaCube2

$799.00 - $2,499.00

Buy Now

Costruisci una curva di conservazione della memoria per richiesta

Ripeti centinaia di richieste identiche, quindi richieste con lunghezze e modalità miste, registrando i byte GPU allocati e riservati, le voci KV e dei prefissi, la cache dei grafi, la memoria bloccata, l'RSS del processo, il numero di oggetti, le sessioni delle richieste, i riavvii dei worker e gli snapshot dell'allocatore.

Usa la memoria riservata dopo la richiesta per distinguere una riserva deliberata successiva alla richiesta. Ripeti l'operazione disabilitando separatamente ogni cache opzionale, estensione, percorso di caricamento e l'etichetta delle metriche, mantenendo fissi il modello e la concorrenza. Il risultato intermedio deve restare ispezionabile prima di procedere con l'automazione.

Accetta un riscaldamento limitato che raggiunga un plateau entro il budget di memoria dichiarato. Aggiungi l'evizione quando la cardinalità della cache cresce senza vantaggi, normalizza le forme delle richieste quando domina la frammentazione e isola una perdita reale solo dopo che gli stack delle allocazioni conservate hanno identificato un responsabile.