In che modo la memorizzazione nella cache dei modelli cambia i tempi di risposta dei server AI domestici?
La memorizzazione nella cache del modello modifica i tempi di risposta consentendo alle richieste ripetute di riutilizzare file scaricati, pesi residenti in memoria, kernel compilati o lo stato del prompt elaborato in precedenza.
Un server AI domestico non dispone di un’unica cache universale. L’artefatto del modello potrebbe essere già presente nello spazio di archiviazione locale, le pagine del file potrebbero rimanere nella RAM di sistema, i pesi potrebbero restare caricati nella memoria dell’acceleratore, il codice di esecuzione compilato potrebbe essere riutilizzabile e un prompt di sistema ripetuto potrebbe avere ancora uno stato KV valido. Ogni livello elimina una parte diversa del percorso della richiesta. Le sezioni seguenti distinguono questi livelli, così una seconda risposta rapida non viene scambiata per una generazione del modello più veloce o per un hardware migliore.
La memorizzazione nella cache del modello comprende diversi livelli indipendenti
La prima distinzione utile riguarda ciò che è stato memorizzato nella cache. Un checkpoint scaricato evita il trasferimento dalla rete, la cache delle pagine del file system evita di rileggere alcuni blocchi dallo spazio di archiviazione, i pesi residenti evitano il caricamento del modello, gli artefatti compilati evitano il lavoro di configurazione e la cache del prefisso evita di ricalcolare i token del prompt condivisi.
La ricerca sulla memorizzazione nella cache su più livelli considera l’avvio del modello come un movimento tra spazio di archiviazione, memoria host e memoria dell’acceleratore, anziché come un unico stato binario freddo o caldo. Una richiesta può essere calda a un livello e fredda a un altro.
Questo spiega perché dire “il modello è nella cache” sia incompleto. Il server potrebbe avere i file localmente, ma dover comunque allocare la VRAM, caricare i pesi, compilare i kernel ed elaborare il prompt prima di produrre un token.
La cache degli artefatti elimina i ritardi di download e del repository
Quando i file del modello sono già presenti sul server domestico, l’avvio evita l’autenticazione, i controlli dei metadati del repository, la larghezza di banda remota e il download di shard da diversi gigabyte. Il runtime può iniziare dalla copia locale.
Netflix descrive la memorizzazione nella cache degli artefatti del modello come necessaria perché scaricare pesi di grandi dimensioni durante l’avvio supera la latenza pratica dello scheduler. Lo stesso meccanismo è importante in casa quando un container viene ricreato o un modello viene avviato dopo una pulizia.
La cache degli artefatti non garantisce un primo token rapido. Un checkpoint locale può trovarsi su un disco lento, utilizzare molti shard, richiedere una conversione o competere con le letture e le scritture del NAS.
La cache del file system può rendere molto più veloce il secondo caricamento
Dopo che il sistema operativo legge i file del modello, le pagine pulite dei file possono rimanere nella RAM di sistema inutilizzata. Un avvio successivo può recuperare quei dati dalla memoria invece di attendere nuovamente il dispositivo di archiviazione.
MAIO migliora l’avvio degli LLM ottimizzando i criteri della cache del file system utilizzati durante il caricamento del modello. I suoi risultati mostrano perché due avvii dallo stesso percorso NVMe possono avere tempi di lettura diversi, a seconda delle pagine del modello rimaste nella cache.
Questa cache può essere recuperata dal sistema. Backup, condivisione di file, database o un altro modello possono sostituire quelle pagine, quindi una risposta rapida ieri potrebbe tornare a dipendere dallo spazio di archiviazione dopo una pressione sulla memoria o un riavvio.
Effettuare benchmark senza definire lo stato della cache delle pagine mescola due regimi di archiviazione e può sovrastimare il miglioramento derivante dall’aggiornamento di un’unità.
I pesi residenti eliminano il principale limite del ricaricamento
Mantenere i pesi nella RAM, nella memoria unificata o nella VRAM consente al runtime di passare direttamente all’elaborazione del prompt. Scaricare il modello libera capacità per altre app, ma costringe la richiesta successiva a percorrere nuovamente il processo di caricamento.
La guida di ZimaSpace sulla permanenza del modello in memoria mostra il comportamento tipico: una richiesta lenta dopo l’espulsione, seguita da risposte normali finché il modello rimane caldo.
La permanenza in memoria modifica principalmente la prontezza e il tempo al primo token. Non aumenta necessariamente la velocità di output dei token una volta avviata la generazione.
Mantenere ogni modello residente può inoltre creare la pressione sulla memoria che causa l’espulsione di un altro modello, della cache KV o di un’app del server domestico.
Le cache di compilazione e dei kernel eliminano il lavoro della prima esecuzione
Alcuni runtime specializzano i kernel, acquisiscono grafi di esecuzione o compilano codice per il modello attivo, l’architettura della GPU, le forme dei tensori e la configurazione del runtime. La prima richiesta compatibile può eseguire operazioni che le richieste successive riutilizzano.
Un’analisi pratica dell’avvio a freddo osserva che la compilazione del runtime può collocarsi tra il caricamento dei pesi e la gestione della prima risposta. Una cache di compilazione persistente sposta questo costo lontano dagli avvii successivi, finché una modifica al modello, al driver, al runtime o all’hardware non la invalida.
Si crea così un altro stato caldo: file e pesi possono essere già presenti, ma la prima nuova forma o il primo nuovo percorso di esecuzione possono comunque causare un picco di latenza.
La memorizzazione nella cache del prefisso riduce il prefill, ma non la decodifica dei nuovi token
Un prompt di sistema ripetuto, un lungo prefisso documentale o un blocco di istruzioni condiviso richiede normalmente che il modello elabori nuovamente gli stessi token prima di raggiungere il nuovo input dell’utente. Una cache del prefisso memorizza lo stato di attenzione riutilizzabile derivante da quel prefill precedente.
La ricerca Prompt Cache riporta una riduzione della latenza al primo token quando le richieste riutilizzano moduli di prompt lunghi. Il vantaggio cresce con la lunghezza del prefisso condiviso, perché è possibile saltare una parte maggiore del calcolo di prefill.
Non rende più veloci i prompt nuovi arbitrari e non elimina il costo della decodifica dei nuovi token di output. I riscontri nella cache dipendono dal riutilizzo esatto o supportato del prefisso, dalla capacità disponibile e dai criteri di espulsione del runtime.
Misura i percorsi freddi e caldi come classi di risposta separate
Prova una richiesta fissa dopo un riavvio, dopo il caricamento del modello, dopo una ripetizione immediata, dopo un lungo periodo di inattività e dopo un carico di lavoro concorrente. Registra separatamente il download dell’artefatto, la lettura dallo spazio di archiviazione, il caricamento del modello, la compilazione, la valutazione del prompt, il primo token e la velocità dei token di output.
L’analisi della cache fredda avverte che la latenza con cache calda può nascondere una coda più lenta quando alcune richieste non trovano riscontri nella cache. Un assistente domestico dovrebbe essere valutato in base alla combinazione di casi che gli utenti incontrano realmente, non solo con un benchmark ripetuto immediatamente.
Una volta identificato il livello che non ha trovato riscontro, la soluzione diventa specifica: pre-caricare i file del modello, mantenere margine nella cache delle pagine, prolungare il keep-alive del modello, rendere persistenti gli artefatti compilati o abilitare il riutilizzo del prefisso per i prompt condivisi stabili.
Domande frequenti
Un modello memorizzato nella cache utilizza sempre meno RAM?
No. Alcune cache consumano deliberatamente RAM o VRAM per ridurre il lavoro futuro. Scambiano capacità con una latenza inferiore, anziché ridurre l’uso della memoria.
Perché la prima risposta è lenta, mentre le successive sono rapide?
La prima richiesta potrebbe caricare i pesi, allocare lo stato del runtime, compilare i kernel o elaborare un prompt lungo. Le richieste successive riutilizzano uno o più di questi risultati.
Cancellare le cache può correggere le risposte errate dell’AI?
In alcuni casi può risolvere artefatti del runtime obsoleti o danneggiati, ma le cache del modello normalmente influiscono sul caricamento e sul riutilizzo dei calcoli, non sulla qualità fattuale di pesi e prompt invariati.
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...
