Perché l’espulsione del modello provoca picchi di latenza sui server AI domestici?

L'espulsione del modello crea un picco di latenza perché il modello che ha gestito la richiesta precedente non è più residente nella memoria veloce. La richiesta successiva deve ricaricare i pesi, ripristinare lo stato del runtime ed elaborare il prompt prima che possa iniziare la generazione normale dei token. Una volta che il modello è di nuovo caldo, le richieste successive possono sembrare veloci.

Se il tuo assistente AI domestico risponde rapidamente durante una conversazione attiva ma si blocca dopo un periodo di inattività, il cambio di modello o la condivisione della GPU con un altro servizio, il modello stesso potrebbe non essere lento. La domanda utile è se il tempo viene speso per caricare il modello o per generare la risposta. Questa distinzione determina cosa modificare.

L'espulsione del modello cambia la prima richiesta, non ogni richiesta

Un runtime di inferenza locale mantiene i pesi del modello nella memoria GPU, nella memoria unificata o nella RAM di sistema mentre il modello è attivo. L'espulsione avviene quando il runtime rimuove parte o tutto quello stato residente. Può farlo dopo un timeout di inattività, quando un altro modello necessita della stessa memoria o quando il servizio si riavvia.

Una richiesta calda può passare direttamente all'elaborazione del prompt perché i pesi sono già disponibili per il motore di inferenza. Una richiesta dopo l'espulsione segue un percorso più lungo: localizzare i file del modello, leggere i pesi, posizionarli nel livello di memoria richiesto, inizializzare il percorso di esecuzione e quindi valutare il prompt.

Ecco perché l'espulsione appare di solito come una pausa isolata piuttosto che una riduzione permanente dei token al secondo. La prima risposta dopo un periodo di inattività è lenta, mentre la seconda richiesta allo stesso modello è normale. Se ogni richiesta rimane lenta, il collo di bottiglia è più probabilmente la generazione, il carico della CPU, la larghezza di banda della memoria, la coda o i limiti termici.

La latenza AI è l'intera catena, non solo la velocità di generazione

Gli utenti spesso descrivono tutta l'attesa come “latenza di inferenza”, ma una richiesta AI locale ha diverse fasi. Può attendere in coda, caricare un modello, elaborare il prompt di input e generare token di output. Un server può quindi segnalare una velocità di generazione sana e comunque sembrare non reattivo prima che appaia il primo token.

L'espulsione del modello aumenta principalmente il tempo al primo token. Non cambia necessariamente la velocità dei token successivi. Ecco perché un benchmark basato solo sui token al secondo può non rilevare il problema: il benchmark potrebbe iniziare dopo che il caricamento è già terminato o potrebbe riutilizzare un modello che è rimasto caldo.

Quando il runtime espone i campi di temporizzazione, confrontali invece di affidarti alla sensazione. I tempi separati di caricamento del modello e di valutazione mostrano se il ritardo si verifica prima o durante l'elaborazione del prompt. Una componente di carico elevata sulla prima richiesta e una piccola sulla successiva è una forte prova di un modello freddo piuttosto che di una decodifica lenta.

Perché i server AI domestici espellono i modelli

La causa più semplice è una politica di inattività. Un runtime rilascia i modelli inattivi così che la memoria possa tornare al sistema operativo o ad altre applicazioni. In Ollama, i modelli rimangono caricati per cinque minuti di default, mentre le impostazioni di keep-alive possono estendere la permanenza. Una pausa che segue costantemente lo stesso intervallo di inattività indica una politica piuttosto che un guasto hardware.

La pressione sulla memoria crea uno schema meno prevedibile. Due modelli linguistici, un modello di embedding, un generatore di immagini o un servizio video possono competere per RAM o VRAM. I sistemi che condividono un server tra Plex e AI locale sono particolarmente vulnerabili perché una transcodifica o un lavoro in background possono sostituire un modello anche se il servizio AI stesso non è stato inattivo.

Il cambio modello può causare lo stesso scompiglio. Se solo un modello grande entra comodamente, richiedere il Modello B può costringere a espellere il Modello A. Tornare al Modello A quindi innesca un altro caricamento. Il server sembra casualmente lento, ma i picchi seguono in realtà l'ordine in cui i modelli sono usati.

I riavvii sono un altro confine. Un aggiornamento del container, un crash del servizio, un riavvio dell'host o una fermata manuale cancellano lo stato residente indipendentemente dal valore di keep-alive. La prima richiesta dopo quell'evento è un avvio a freddo per design. Trattarlo come un bug di espulsione può portare a impostazioni aggressive che consumano memoria senza migliorare il funzionamento normale.

Dove si accumula il ritardo di espulsione

Il primo costo è il trasferimento del modello. Caricare i pesi del modello nella memoria GPU richiede tipicamente di leggerli dallo storage nella memoria CPU prima di trasferirli alla GPU. File più grandi e percorsi di storage più lenti allungano questa parte dell'attesa.

Il percorso dei dati conta tanto quanto l'etichetta dell'unità. I pesi possono attraversare lo storage, la memoria di sistema e un percorso PCIe o di memoria unificata prima che inizi l'inferenza. Durante quel trasferimento, una larghezza di banda limitata della memoria può aumentare la latenza dell'IA, specialmente quando un altro carico di lavoro sta spostando grandi quantità di dati contemporaneamente.

Il caricamento dei byte non è sempre la fine del percorso a freddo. A seconda del runtime, il server può anche creare un contesto GPU, allocare pool di memoria, preparare kernel o catturare grafici di esecuzione. I sistemi che mantengono lo stato CUDA inizializzato possono riattivarsi più velocemente di un riavvio completo perché quei passaggi di configurazione non devono essere tutti ripetuti.

Il prompt deve quindi essere valutato di nuovo. L'espulsione normalmente scarta la cache attiva del modello, quindi un prompt di sistema lungo, un contesto recuperato o la cronologia della chat devono passare attraverso il prefill prima che appaia il primo nuovo token. Quel ritardo non è il caricamento dei pesi, ma gli utenti sperimentano entrambi i costi come una pausa silenziosa.

Cosa significano di solito i diversi schemi di latenza

Il modello temporale rivela più di un semplice test di velocità. Confronta quando si verifica la pausa, quale metrica cresce e cosa succede alla richiesta immediata ripetuta.

La firma di espulsione più caratteristica è la prima riga: una richiesta costosa seguita da risposte normali dallo stesso modello. Le altre righe impediscono di bloccare un modello in memoria quando il vero problema si trova altrove nel percorso della richiesta.

Come testare se l'espulsione è la causa

Inizia con un modello e un prompt fisso. Invia il prompt due volte con solo una breve pausa, quindi ripeti il test dopo che il server è rimasto inattivo abbastanza a lungo da superare la sua attuale politica di scaricamento. Mantieni invariata la lunghezza del prompt e le impostazioni del modello in modo che il confronto isoli la residenza.

Registra il tempo totale di risposta, il tempo di caricamento del modello, il tempo di valutazione del prompt e il tempo di generazione dove il runtime li espone. Se solo il tempo di caricamento si allunga dopo il periodo di inattività, l’evidenza indica un’espulsione. Se invece cresce la valutazione del prompt, la lunghezza del contesto o il riutilizzo della cache sono la pista migliore.

Osserva la memoria contemporaneamente. Un modello dovrebbe apparire in RAM o VRAM dopo la prima richiesta e rimanervi durante il test di riscaldamento. Se la sua impronta scompare prima della richiesta lenta, hai la conferma diretta che il runtime o un altro carico di lavoro l’ha rilasciato.

Infine, modifica una condizione. Estendi il keep-alive, interrompi temporaneamente i servizi GPU concorrenti o precarica il modello prima della richiesta di test. Una diagnosi reale di espulsione dovrebbe rispondere al cambiamento. Se la latenza rimane invariata, torna a collo di bottiglia di calcolo, memoria, storage o rete invece di presumere che il modello sia stato scaricato.

Impostazioni pratiche che riducono i picchi di espulsione

Mantieni il modello che serve le richieste interattive residente per un periodo che corrisponda all’uso effettivo. Un assistente domestico usato ogni pochi minuti può beneficiare di una finestra di keep-alive più lunga. Un modello grande usato una volta al giorno potrebbe non averne bisogno. L’impostazione dovrebbe proteggere il percorso caldo, non trasformare ogni modello scaricato in un consumo permanente di memoria.

Lascia un margine reale di memoria. La VRAM installata non è identica alla memoria disponibile per i pesi del modello perché anche il display, il runtime, la cache di contesto e altre applicazioni la consumano. Controllare la memoria usata e rimanente con nvidia-smi permette di misurare la VRAM libera reale prima di scegliere la dimensione e la quantizzazione del modello.

Riduci il set di lavoro residente quando il modello caldo si adatta a malapena. Una quantizzazione più piccola, un limite di contesto più breve o un modello predefinito più piccolo possono creare un margine sufficiente per prevenire l’espulsione di routine. Le scelte di modello e contesto dovrebbero seguire i requisiti di RAM e acceleratore del carico di lavoro piuttosto che solo il numero di parametri.

Controlla il cambio modello. Instrada le richieste comuni verso un modello predefinito e riserva un modello specialistico più grande per i compiti che giustificano il ricaricamento. Se più modelli devono rimanere disponibili, verifica che il loro peso combinato, cache e overhead di runtime si adattino invece di aumentare ciecamente il limite di concorrenza.

Usa uno storage locale veloce per i file del modello e precarica il modello interattivo dopo un riavvio programmato. Lo storage più veloce non può eliminare l'inizializzazione o il lavoro di pre-riempimento del prompt, ma può abbreviare la fase di trasferimento. Il precaricamento sposta quel costo a un momento controllato invece di far aspettare la prima persona che fa una domanda.

Quando l'espulsione è ancora il compromesso giusto

L'espulsione non è automaticamente un errore. Su un server domestico con memoria limitata, previene che un carico di lavoro AI occasionale monopolizzi risorse necessarie per la condivisione file, container, servizi media o un altro modello. Il server rinuncia al tempo di attivazione istantaneo in cambio di capacità e stabilità.

La politica giusta segue il carico di lavoro. Mantieni caldo un assistente usato frequentemente e sensibile alla latenza. Permetti ai modelli batch, ai modelli di immagini e agli esperimenti usati raramente di scaricarsi. Se due modelli interattivi si sostituiscono costantemente, le scelte durature sono modelli più piccoli, più memoria o acceleratori separati, non un valore infinito di keep-alive.

Un confine pratico è la frequenza di ripetizione. Se gli utenti tornano comunemente prima che il modello venga scaricato, estendere la residenza elimina attriti visibili a un modesto costo di memoria. Se le richieste sono a ore di distanza e la macchina ha altri compiti, accettare un avvio a freddo può essere un design di sistema più pulito.

FAQ

L'espulsione del modello peggiora le risposte dell'IA?

L'espulsione cambia la prontezza, non i pesi del modello memorizzati. Ricaricare lo stesso modello con lo stesso prompt e impostazioni non dovrebbe ridurne la capacità. Tuttavia, una conversazione o cache di prefisso scartata può cambiare la quantità di contesto da elaborare di nuovo, e lo stato dell'applicazione mancante può influire sulla continuità se non è stato memorizzato separatamente.

Un drive NVMe più veloce può eliminare il picco di latenza?

Può abbreviare la fase di lettura dei pesi, specialmente quando il percorso di archiviazione precedente era lento o occupato, ma non può eliminare la configurazione della GPU, l'allocazione della memoria, la preparazione del kernel o il pre-riempimento del prompt. Se l'archiviazione è solo una piccola parte del tempo di caricamento misurato, un aggiornamento NVMe non eliminerà tutta la pausa.

Ogni modello locale dovrebbe rimanere caricato?

No. Bloccare ogni modello può creare la stessa pressione sulla memoria che ha causato il ricambio, riducendo la capacità per le cache e altri servizi. Mantieni caldi solo i modelli sensibili alla latenza, lascia scaricare occasionalmente gli altri modelli e verifica l'impronta combinata residente sotto il carico reale del server.

La regola più semplice è confrontare la prima richiesta con la ripetizione immediata. Una grande differenza nei tempi di caricamento indica un'espulsione; una generazione lenta in entrambe le richieste indica altro. Misura prima quel confine, poi regola la residenza, la dimensione del modello e le risorse condivise in base a ciò di cui gli utenti del modello hanno effettivamente bisogno per percepire l'immediatezza.