Waarom neemt de latentie van het eerste token van een lokale LLM toe nadat de server enige tijd inactief is geweest?
De latentie van het eerste token loopt na inactiviteit vaak op, omdat het volgende verzoek de model-, geheugen-, accelerator- en voedingstoestand opnieuw moet opbouwen die warme verzoeken hergebruiken.
Een AI-server voor thuis kan herhaalde prompts snel beantwoorden en de volgende ochtend toch traag aanvoelen wanneer het eerste verzoek binnenkomt. Het model staat mogelijk nog op schijf, maar de pagina's, GPU-toewijzing, kernels en uitvoeringscontext zijn mogelijk niet meer warm. Opslagsnelheid, geheugendruk, runtime-evictie, energiebeheer van apparaten en promptlengte bepalen hoeveel vertraging terugkeert.
Inactiviteit verwijdert verschillende soorten warme toestand
Een warm verzoek kan gewichten hergebruiken die al in RAM of VRAM aanwezig zijn, bestandssysteempagina's die door het besturingssysteem zijn behouden, geรฏnitialiseerde acceleratorbibliotheken, gecompileerde kernels, geheugenpools en een actieve modelworker. Opruimen tijdens inactiviteit kan slechts รฉรฉn laag verwijderen, maar ook het volledige proces beรซindigen.
Laden van checkpoints in meerdere lagen verkort het opstarten van serverloze modellen door checkpoints dicht bij accelerators te houden, via meerdere opslaglagen te laden en verzoeken te plannen op locaties waar de modeltoestand al lokaal aanwezig is. Het ontwerp laat zien dat koude latentie een keten van overdrachten en initialisatiestappen is, en niet รฉรฉn getal voor schijflezen.
De waarneembare vertraging hangt af van de laag die koud is geworden. Een proces dat actief is gebleven, hoeft mogelijk alleen de apparaatklokken op te voeren, terwijl een geรซvict model gewichten moet lezen, apparaatgeheugen moet toewijzen, runtime-structuren opnieuw moet opbouwen en vervolgens de prompt moet verwerken voordat het een token kan produceren.
Model laden en prefill stapelen zich op voordat er een token verschijnt
De tijd tot het eerste token omvat wachtrijen, beschikbaarheid van gewichten, runtime-initialisatie, tokenisatie en prefill over de volledige invoer. Een hoge decodeersnelheid kan deze stappen niet verhullen, omdat er pas een uitvoertoken bestaat nadat prefill de eerste decodeertoestand heeft geproduceerd.
Hergebruik van GPU-geheugen behoudt parameters in ongebruikt GPU-geheugen en gebruikt affiniteitsbewuste planning om herhaalde overdrachten te beperken. De gerapporteerde verbeteringen bij koude starts laten zien waarom het behouden van gedeeltelijke residentie belangrijk kan zijn, zelfs wanneer een service niet elk model volledig geladen kan houden.
Een lange systeemprompt kan dus traag blijven nadat de gewichten warm zijn, terwijl een korte prompt nog steeds kan stagneren door het laden van een koud model. Door laadtijd, initialisatie, prefill en de eerste decode afzonderlijk te meten, voorkom je dat รฉรฉn gemiddelde TTFT-waarde het werkelijke koude component verbergt.
Energiebesparing is meestal een kleinere, maar meetbare laag
CPU's, GPU's, NVMe-apparaten en PCIe-verbindingen kunnen tijdens inactiviteit naar lagere energiestanden gaan. De eerste burst moet de klokken verhogen en actieve paden herstellen, waardoor een korte opstartfase ontstaat voordat langdurige berekening begint; agressieve slaapstand van de host kan veel meer tijd toevoegen doordat services of schijven worden opgeschort.
Overlappende stappen bij een koude start laat het laden van modellen, communicatie en berekening overlappen voor koude starts van edge-LLM's. Het onderzoek toont aan dat het verbergen van รฉรฉn opstartstap afstemming met de andere vereist, vooral wanneer gewichten en rekenkracht over beperkte apparaten zijn verdeeld.
De fout is om elk traag eerste antwoord aan de energiestand toe te schrijven. Als de vertraging vele seconden bedraagt, domineren model-evictie, lezen vanaf opslag, het starten van containers of prompt-prefill meestal een klokovergang van milliseconden. Stel de tijdlijn vast in plaats van standaard alle energiebesparing uit te schakelen.
Maak onderscheid tussen koude start en koude promptkosten
Stuur รฉรฉn vaste korte prompt na 0, 1, 10, 60 en 480 minuten inactiviteit. Noteer voor elk interval de levensduur van het proces, modelresidentie, RAM- en VRAM-gebruik, gelezen bytes, apparaatklokken, wachtrijtijd, tokenisatie, prefill, de eerste decode en de totale TTFT.
Vergelijk de opslaglaag met modelopslag voor koude starts en herhaal dit terwijl je de worker vastzet, alleen de bestandssysteemcache opwarmt, uitsluitend het host-RAM warm houdt en de promptlengte wijzigt. Elke run moet รฉรฉn toestandlaag veranderen in plaats van alle optimalisaties te combineren.
Beschouw de server alleen als warm wanneer herhaalde intervallen van inactiviteit de vereiste TTFT behouden zonder andere services te laten verhongeren. Als het vastzetten van het model geheugendruk veroorzaakt of workloads met een hogere prioriteit blokkeert, accepteer dan een begrensde koude start en maak die zichtbaar in plaats van de afweging te verbergen.
Aanbevolen producten
Tech & AI HUB
Meer om te lezen
Waardoor herhaalt een AI-agentplanner stappen die al zijn voltooid?
Traceer herhaalde planningsstappen via statuspersistentie, voltooiingsbewijs, het parseren van toolresultaten, contextbehoud, nieuwe pogingen, herplanning en stopvoorwaarden.
Waardoor ontstaan machtigingsfouten alleen binnen subprocessen van AI-agenten?
Vergelijk de identiteit van het bovenliggende en onderliggende proces, de bestandssysteemweergave, de omgeving, de mogelijkheden, het beveiligingsbeleid en het pad naar het uitvoerbare bestand...
Waardoor ontstaat CPU-verzadiging wanneer hardwaretranscodering en video-AI gelijktijdig worden uitgevoerd?
Breng CPU-verzadiging in kaart voor codec-offloading, pixelconversie, framekopieรซn, AI-voorbewerking, audio, ondertiteling, opslag en procesplanning.
