Cosa causa i picchi di latenza del primo token dopo che un servizio di IA locale cambia modello?

La latenza del primo token aumenta solitamente dopo il cambio di modello perché il modello appena selezionato deve ricostruire lo stato residente prima di poter elaborare il prompt.

Un server AI domestico può rispondere rapidamente con un modello già attivo, passare a un modello di visione o di programmazione e poi mettere in pausa l'elaborazione prima del primo token. Il ritardo può includere la lettura dei pesi, la dequantizzazione, il trasferimento al dispositivo, la compilazione dei kernel, l'acquisizione del grafo CUDA, l'allocazione della cache e il prefill del prompt. La fase dominante dipende dallo storage, dalla memoria disponibile dell'acceleratore, dai criteri del runtime e dal fatto che il modello precedente sia stato completamente rimosso o meno.

Il caricamento a freddo dei pesi è la prima famiglia di cause

Se il modello successivo non è presente nella RAM o nella VRAM, il server deve leggere uno o più frammenti del checkpoint, convalidarli o mapparli, costruire i tensori e trasferire i pesi utilizzabili al dispositivo di esecuzione. Un file più grande o un percorso NAS più lento prolunga la pausa prima che l'inferenza possa iniziare.

Le misurazioni della latenza di avvio a freddo degli LLM mostrano che l'avvio può dominare il TTFT quando lo stato del modello è freddo. Questo sintomo si manifesta con letture intense dallo storage e tempo impiegato dal caricatore del modello prima dell'esecuzione di qualsiasi kernel di prefill del prompt. Questa distinzione resta visibile durante i successivi test domestici.

Se il passaggio tra due modelli che rimangono entrambi residenti produce lo stesso aumento, il caricamento dei pesi non è una spiegazione completa. L'osservazione distintiva è verificare se i byte letti e lo stato dei modelli residenti cambiano con la richiesta lenta.

L'inizializzazione del runtime crea un secondo percorso a freddo

Un modello caricato può essere comunque freddo dal punto di vista operativo. Il runtime può inizializzare un contesto del dispositivo, selezionare i kernel, compilare le forme, acquisire i grafi, allocare i blocchi KV oppure creare cache per il tokenizer e i modelli di prompt alla prima richiesta dopo l'attivazione.

Un'analisi tecnica dello streaming e del warm-up dei modelli separa lo streaming dallo storage dall'inizializzazione e dal warm-up. Il profilo della fase mostra un I/O del checkpoint modesto seguito da compilazione, allocazione o attività dell'acceleratore prima dell'elaborazione del prompt. Il risultato intermedio deve rimanere ispezionabile prima di procedere con l'automazione.

La forma del modello, il backend di quantizzazione, il limite del contesto, i profili dei batch e lo stato dei driver determinano quali artefatti possono essere riutilizzati. Tornare rapidamente al modello precedente può essere veloce se le cache sono sopravvissute, mentre un'espulsione dovuta alla pressione sulla memoria rende nuovamente freddo lo stesso percorso.

L'accodamento e il prefill possono sembrare un ritardo nel caricamento del modello

La richiesta di cambio può attendere la chiusura del modello, il recupero della memoria, un altro utente o un prompt lungo. Una volta ammessa, la fase di prefill elabora ogni token di input prima del decode, quindi cronologie più lunghe aumentano il TTFT senza modificare il tempo di caricamento del modello. Questo confine dovrebbe essere misurato separatamente in condizioni operative realistiche.

La progettazione del servizio con ammissione della cache KV paginata spiega come le sequenze attive consumino blocchi KV paginati e come l'ammissione dipenda dalla capacità disponibile della cache. Un cambio che modifica le prenotazioni della cache può quindi alterare il tempo di accodamento indipendentemente dalle dimensioni del checkpoint.

Il confine indicativo di un problema è un modello caldo e residente, con inizializzazione stabile, accompagnato da un aumento della latenza che segue la lunghezza del prompt o la concorrenza. In questo caso, il cambio di modello è solo correlato: la causa diretta è il prefill o la pianificazione.

Featured

ZimaCube 2 NAS personale cloud domestico

ZimaCube2

$799.00 - $2,499.00

Buy Now

Suddividi il TTFT in caricamento, warm-up, coda e prefill

Riproduci prompt fissi registrando l'espulsione del modello, i byte del checkpoint, il throughput dello storage, il trasferimento dall'host al dispositivo, la creazione del contesto del dispositivo, la compilazione dei kernel, l'acquisizione del grafo, l'allocazione KV, l'attesa in coda, la durata del prefill e il primo passaggio di decode su un unico clock monotono. La conseguenza pratica emerge quando più fonti competono per un contesto limitato.

Confronta la traccia con il routing dei modelli in base alla memoria, quindi testa separatamente il cambio a freddo, il ritorno immediato al modello precedente, il routing con due modelli residenti, il prompt breve e il prompt lungo. Mantieni invariati sampling, client e concorrenza, così che cambi solo lo stato previsto. Questa dipendenza deve rimanere esplicita nell'interfaccia finale.

Attribuisci l'aumento alla prima fase che si espande. Mantieni i pesi residenti quando domina il caricamento, conserva gli artefatti compatibili quando domina l'inizializzazione e modifica i criteri di ammissione o del contesto quando sono l'accodamento o il prefill - non il cambio in sé - a determinare il TTFT.