La permanenza del modello consiste nel mantenere i pesi del modello nella memoria dell'host o dell'acceleratore tra una richiesta e l'altra, così che l'inferenza successiva eviti parte o tutto il lavoro di caricamento.
Un assistente domestico utilizzato ogni pochi minuti si comporta in modo molto diverso quando un modello da otto gigabyte rimane nella memoria della GPU invece di essere letto dall'archiviazione ogni volta. La permanenza può esistere a diversi livelli: cache del filesystem, pagine dell'host mappate, RAM bloccata o VRAM pronta per i kernel. Mantenere i pesi pronti riduce il ritardo di avvio, ma riserva memoria limitata e può impedire l'esecuzione di altri modelli o carichi di lavoro.
La permanenza descrive dove rimane lo stato riutilizzabile del modello
Un modello freddo esiste solo nell'archiviazione e deve essere letto, allocato, trasformato e copiato prima dell'inferenza. I pesi residenti nell'host evitano le letture dall'archiviazione, mentre quelli residenti nell'acceleratore evitano anche il trasferimento dall'host al dispositivo e il percorso di inizializzazione del runtime. Questa distinzione rimane visibile durante i successivi test domestici.
L'analisi dello streaming dei modelli di NVIDIA separa il percorso di caricamento del modello dal lavoro di trasferimento e inizializzazione, mostrando perché la posizione dei pesi determina molti avvii a freddo. Un processo caldo potrebbe comunque dover inizializzare tokenizer, grafo, adattatore o cache. Il risultato intermedio deve rimanere verificabile prima di procedere con l'automazione.
La permanenza non equivale a una richiesta attiva. Un modello può rimanere caricato senza cache KV né dati dell'utente, pronto a rispondere mentre consuma memoria e alcune risorse in background. Questo limite deve essere misurato separatamente in condizioni operative realistiche.
Il livello di preparazione varia lungo una gerarchia di memoria
Il sistema operativo può conservare le pagine del modello nella cache delle pagine anche dopo la chiusura di un processo, la mappatura della memoria può caricare le pagine in modo differito e un processo di servizio può mantenere i tensori nella RAM o nella VRAM. Ogni livello più pronto riduce generalmente la latenza, consumando però una risorsa più limitata.
ServerlessLLM esamina il caricamento dei modelli a più livelli tra archiviazione, memoria dell'host e memoria della GPU, pianificando il caricamento per ridurre il costo degli avvii a freddo. La gerarchia spiega perché un modello apparentemente non caricato possa riavviarsi rapidamente finché la pressione sulla cache non ne espelle le pagine.
La quantizzazione riduce i byte necessari per mantenere i modelli residenti e può consentire la coesistenza di diversi modelli specializzati. Può anche modificare i kernel di esecuzione e la qualità, quindi il risparmio di memoria non deve essere considerato un aumento gratuito della capacità. La conseguenza pratica emerge quando diverse fonti competono per un contesto limitato.
La politica di espulsione trasforma la pressione sulla memoria in ritardo di avvio
Un servizio può mantenere residenti i modelli utilizzati di frequente ed espellere quelli meno recenti in base alla recenza, alla domanda prevista, alla priorità o al costo di caricamento. Il routing multi-modello richiede regole di ammissione affinché il lavoro in background non sostituisca il modello vocale che deve rispondere immediatamente.
FlexGen dimostra il trasferimento dei pesi tra GPU, CPU e archiviazione per l'inferenza con risorse limitate. Sebbene sia pensato per il throughput, rende esplicito il compromesso fondamentale: spostare i pesi tra i livelli consente di risparmiare memoria limitata, ma aggiunge costi di trasferimento e pianificazione.
Il limite di errore è rappresentato dalla pressione sulla memoria che attiva lo swapping, i riavvii per OOM o il continuo ciclo di espulsione e ricaricamento. Mantenere caricati troppi pesi può rendere ogni modello più lento e meno affidabile rispetto al riscaldamento deliberato di un insieme di lavoro più ristretto. Questa dipendenza deve rimanere esplicita nell'interfaccia finale.
Imposta la permanenza in base alla distanza tra riutilizzi e al margine di memoria
Misura il tempo di avvio a freddo, con l'host caldo e con l'acceleratore caldo per ogni modello, quindi registra l'intervallo tra le richieste, i byte caricati, l'occupazione di VRAM e RAM, il consumo energetico in inattività, il numero di espulsioni e la domanda dei carichi di lavoro concorrenti. Il risultato deve quindi essere verificato rispetto alle prove originali.
Confronta il meccanismo di avvio con l'avvio tramite mappatura della memoria. Riproduci una settimana di arrivi con finestre di mantenimento attivo e priorità candidate, includendo picchi, lunghi periodi di inattività e richieste simultanee di modelli. Questa distinzione rimane visibile durante i successivi test domestici.
Mantieni residente un modello quando la latenza di caricamento evitata e la frequenza di riutilizzo giustificano la memoria protetta. Espellilo quando la capacità riservata causa code o continui cicli di espulsione e ricaricamento, mantenendo un margine di emergenza per la cache KV e le allocazioni temporanee.
Hub Tecnologico e AI
Altro da leggere

Che cos’è la deriva degli embedding e quando è necessario ricostruire un indice di ricerca privato?
Decodifica il modello, il preprocessing, il corpus e il drift delle query; distingui il monitoraggio dall'incompatibilità e decidi quando è necessario ricostruire un indice...

Che cos'è la compatibilità dei tokenizzatori e perché può compromettere il passaggio da un modello all'altro?
Decodifica l'identità del vocabolario, la semantica dei token speciali, i modelli di chat, i token memorizzati nella cache, gli adattatori e i controlli di...

Che cos'è il tasso di accettazione della decodifica speculativa e perché è importante?
Decodifica la metrica di accettazione, definisci la verifica, il comportamento in caso di rifiuto, i limiti di accelerazione, la variazione del carico di lavoro...

