Perché la latenza del primo token di un LLM locale aumenta dopo che il server rimane inattivo?

La latenza del primo token spesso aumenta dopo un periodo di inattività perché la richiesta successiva deve ricostruire lo stato del modello, della memoria, dell'acceleratore e dell'alimentazione che le richieste a caldo riutilizzano.

Un server AI domestico può rispondere rapidamente a richieste ripetute, per poi sembrare lento quando arriva la prima richiesta la mattina seguente. Il modello potrebbe essere ancora presente sul disco, ma le sue pagine, l'allocazione della GPU, i kernel e il contesto di esecuzione potrebbero non essere più a caldo. La velocità dello storage, la pressione sulla memoria, l'espulsione da parte del runtime, la gestione energetica del dispositivo e la lunghezza del prompt determinano quanta latenza si ripresenta.

Il tempo di inattività rimuove diversi tipi di stato a caldo

Una richiesta a caldo può riutilizzare pesi già residenti nella RAM o nella VRAM, pagine del filesystem conservate dal sistema operativo, librerie dell'acceleratore inizializzate, kernel compilati, pool di memoria e un worker del modello attivo. La pulizia durante l'inattività può rimuovere un solo livello oppure arrestare completamente il processo.

Il caricamento dei checkpoint su più livelli riduce l'avvio dei modelli serverless mantenendo i checkpoint vicini agli acceleratori, caricandoli attraverso più livelli di storage e programmando le richieste dove lo stato del modello è già locale. Il suo design mostra che la latenza a freddo è una catena di trasferimenti e fasi di inizializzazione, non un singolo valore di lettura dal disco.

Il ritardo osservabile dipende dal livello che si è raffreddato. Un processo rimasto attivo potrebbe aver bisogno soltanto di aumentare la frequenza del dispositivo, mentre un modello espulso deve leggere i pesi, allocare la memoria del dispositivo, ricostruire le strutture del runtime e quindi elaborare il prompt prima di emettere un token.

Il caricamento del modello e il prefill si accumulano prima che appaia un token

Il tempo al primo token include l'accodamento, la disponibilità dei pesi, l'inizializzazione del runtime, la tokenizzazione e il prefill dell'intero input. Una velocità di decodifica elevata non può nascondere queste fasi, perché nessun token di output esiste finché il prefill non produce il primo stato di decodifica.

Il riutilizzo della memoria GPU conserva i parametri nella memoria GPU inutilizzata e usa una programmazione basata sull'affinità per ridurre i trasferimenti ripetuti. I miglioramenti riportati nell'avvio a freddo mostrano perché preservare una residenza parziale può essere importante anche quando un servizio non può mantenere ogni modello completamente caricato.

Un prompt di sistema lungo può quindi rimanere lento anche dopo che i pesi sono a caldo, mentre un prompt breve può comunque bloccarsi a causa del caricamento a freddo del modello. Separare il tempo di caricamento, l'inizializzazione, il prefill e la prima decodifica impedisce a un singolo valore medio di TTFT di nascondere l'effettiva componente a freddo.

Il risparmio energetico è solitamente un livello più ridotto, ma misurabile

CPU, GPU, dispositivi NVMe e collegamenti PCIe possono entrare in stati a basso consumo durante l'inattività. Il primo picco deve aumentare la frequenza e ripristinare i percorsi attivi, aggiungendo una breve fase di accelerazione prima dell'avvio dell'elaborazione continuativa; la sospensione aggressiva dell'host può aggiungere molto di più mettendo in pausa servizi o dischi.

La sovrapposizione delle fasi di avvio a freddo sovrappone il caricamento del modello, la comunicazione e l'elaborazione per gli avvii a freddo degli LLM edge. Il lavoro dimostra che nascondere una fase di avvio richiede il coordinamento con le altre, soprattutto quando pesi ed elaborazione sono distribuiti tra dispositivi con risorse limitate.

L'errore consiste nell'attribuire ogni prima risposta lenta allo stato energetico. Se il ritardo si misura in molti secondi, l'espulsione del modello, le letture dallo storage, l'avvio del container o il prefill del prompt sono solitamente più determinanti di una transizione della frequenza nell'ordine dei millisecondi. Diagnostica la sequenza temporale invece di disabilitare per impostazione predefinita ogni forma di risparmio energetico.

Featured

ZimaCube 2 NAS personale cloud domestico

ZimaCube2

$799.00 - $2,499.00

Buy Now

Separa l'avvio a freddo dal costo del prompt a freddo

Invia un singolo prompt breve e fisso dopo 0, 1, 10, 60 e 480 minuti di inattività. Registra la durata del processo, la residenza del modello, l'utilizzo di RAM e VRAM, i byte letti, le frequenze del dispositivo, il tempo in coda, la tokenizzazione, il prefill, la prima decodifica e il TTFT totale per ciascun intervallo.

Confronta il livello di storage con il cold start del modello, quindi ripeti il test bloccando il worker, riscaldando solo la cache del filesystem, mantenendo a caldo soltanto la RAM dell'host e modificando la lunghezza del prompt. Ogni esecuzione dovrebbe modificare un solo livello di stato invece di combinare tutte le ottimizzazioni.

Considera il server a caldo solo quando intervalli di inattività ripetuti mantengono il TTFT richiesto senza affamare gli altri servizi. Se bloccare il modello causa pressione sulla memoria o ostacola carichi di lavoro con priorità più alta, accetta un avvio a freddo limitato e rendilo visibile invece di nascondere il compromesso.