Wat veroorzaakt pieken in de latency van het eerste token nadat een lokale AI-service van model wisselt?

De latentie van het eerste token piekt meestal na het wisselen van model, omdat het nieuw geselecteerde model zijn aanwezige status opnieuw moet opbouwen voordat het de prompt kan verwerken.

Een AI-thuisserver kan snel antwoorden met één opgewarmd model, overschakelen naar een vision- of codeermodel en vervolgens pauzeren voordat het eerste token verschijnt. De vertraging kan bestaan uit het lezen van gewichten, dequantisatie, overdracht naar het apparaat, kernelcompilatie, het vastleggen van CUDA-grafieken, cachetoewijzing en prompt-prefill. Welke fase overheerst, hangt af van de opslag, het beschikbare geheugen van de accelerator, het runtimebeleid en de vraag of het vorige model volledig was verwijderd.

Het koud laden van gewichten is de eerste oorzaakcategorie

Als het volgende model niet in RAM of VRAM aanwezig is, moet de server een of meer checkpoint-shards lezen, deze valideren of mappen, tensors opbouwen en bruikbare gewichten naar het uitvoerapparaat overbrengen. Een groter bestand of een trager NAS-pad verlengt de pauze voordat de inferentie kan beginnen.

Metingen van cold-startlatentie van LLM's laten zien dat het opstarten de TTFT kan domineren wanneer de modelstatus koud is. Dit verschijnsel is zichtbaar als intensieve opslagactiviteit en tijd in de modellader voordat er kernels voor prompt-prefill worden uitgevoerd. Dit onderscheid blijft zichtbaar tijdens latere tests in huiselijke omstandigheden.

Als het wisselen tussen twee modellen die beide aanwezig blijven dezelfde piek veroorzaakt, is het laden van gewichten niet de volledige verklaring. De onderscheidende observatie is of het aantal gelezen bytes en de status van het aanwezige model veranderen bij het trage verzoek.

Runtime-initialisatie creëert een tweede koud pad

Een geladen model kan operationeel nog steeds koud zijn. De runtime kan een apparaatcontext initialiseren, kernels selecteren, vormen compileren, grafieken vastleggen, KV-blokken toewijzen of tokenizer- en promptsjablooncaches opbouwen bij het eerste verzoek na activering.

Een technische analyse van modelstreaming en opwarming maakt onderscheid tussen opslagstreaming, initialisatie en opwarming. Het kenmerkende patroon van deze fase is beperkte checkpoint-I/O, gevolgd door compilatie, toewijzing of acceleratoractiviteit voordat de promptverwerking begint. Het tussentijdse resultaat moet inspecteerbaar blijven voordat automatisering wordt toegepast.

De modelvorm, quantisatiebackend, contextlimiet, batchprofielen en drivertoestand bepalen welke artefacten kunnen worden hergebruikt. Snel terugschakelen kan vlot verlopen als caches behouden zijn gebleven, terwijl een verwijdering door geheugendruk hetzelfde pad opnieuw koud maakt.

Wachtrijen en prefill kunnen worden aangezien voor vertraging door het laden van een model

Het verzoek om te wisselen kan wachten op het afsluiten van een model, het vrijmaken van geheugen, een andere gebruiker of een lange prompt. Zodra het verzoek is toegelaten, verwerkt prefill elk invoertoken vóór het decoderen, waardoor langere geschiedenissen de TTFT verhogen zonder de laadtijd van het model te veranderen. Die grens moet afzonderlijk worden gemeten onder realistische bedrijfsomstandigheden.

Het serverontwerp met toelating van een gepagde KV-cache legt uit hoe actieve reeksen gepagde KV-blokken gebruiken en hoe toelating afhankelijk is van de beschikbare cachecapaciteit. Een wissel die cache-reserveringen verandert, kan daardoor de wachttijd onafhankelijk van de checkpointgrootte beïnvloeden.

De foutgrens is een warm, aanwezig model met stabiele initialisatie en een latentiepieк die de promptlengte of gelijktijdigheid volgt. In dat geval is het wisselen van model slechts gecorreleerd; prefill of planning is de directe oorzaak.

Featured

ZimaCube 2 Persoonlijke Cloud Home NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Splits TTFT op in laden, opwarming, wachtrij en prefill

Speel vaste prompts opnieuw af en log modelverwijdering, checkpointbytes, opslagdoorvoer, overdracht van host naar apparaat, het aanmaken van de apparaatcontext, kernelcompilatie, het vastleggen van grafieken, KV-toewijzing, wachttijd in de wachtrij, prefillduur en de eerste decodeerstap op één monotone klok. Het praktische gevolg wordt zichtbaar wanneer meerdere bronnen concurreren om beperkte context.

Vergelijk de trace met routering van modellen op basis van geheugen en test vervolgens afzonderlijk een koude wissel, onmiddellijk terugschakelen, routering met twee aanwezige modellen, een korte prompt en een lange prompt. Houd sampling, client en gelijktijdigheid gelijk, zodat alleen de bedoelde status verandert. Deze afhankelijkheid moet expliciet blijven in de uiteindelijke interface.

Wijs de piek toe aan de eerste fase die zich uitbreidt. Houd gewichten aanwezig wanneer laden de dominante factor is, bewaar compatibele artefacten wanneer initialisatie overheerst en pas het toelatings- of contextbeleid aan wanneer wachtrijen of prefill - en niet de wissel zelf - de TTFT bepalen.