Was verursacht Spitzen bei der First-Token-Latenz, nachdem ein lokaler KI-Dienst die Modelle wechselt?

Die Latenz bis zum ersten Token steigt nach einem Modellwechsel normalerweise stark an, weil das neu ausgewählte Modell zunächst den residenten Zustand neu aufbauen muss, bevor es die Eingabe verarbeiten kann.

Ein KI-Server zu Hause kann mit einem bereits aufgewärmten Modell schnell antworten, zu einem Vision- oder Codierungsmodell wechseln und dann vor dem ersten Token pausieren. Die Verzögerung kann das Lesen der Gewichte, die Dequantisierung, die Übertragung auf das Gerät, die Kernel-Kompilierung, die Erfassung von CUDA-Graphen, die Cache-Zuweisung und das Prefill der Eingabe umfassen. Welche Phase dominiert, hängt vom Speicher, dem verfügbaren Beschleunigerspeicher, der Laufzeitrichtlinie und davon ab, ob das vorherige Modell vollständig aus dem Speicher entfernt wurde.

Das Laden kalter Gewichte ist die erste Ursachengruppe

Wenn das nächste Modell nicht im RAM oder VRAM vorhanden ist, muss der Server ein oder mehrere Checkpoint-Segmente lesen, sie validieren oder einbinden, Tensoren erstellen und die nutzbaren Gewichte auf das Ausführungsgerät übertragen. Eine größere Datei oder ein langsamerer NAS-Pfad verlängert die Pause, bevor die Inferenz beginnen kann.

Messungen der Kaltstartlatenz von LLMs zeigen, dass der Start die TTFT dominieren kann, wenn der Modellzustand kalt ist. Dieses Symptom zeigt sich in umfangreichen Lesevorgängen und einer langen Ladezeit des Modells, bevor Kernel für das Prefill der Eingabe ausgeführt werden. Dieser Unterschied bleibt auch bei späteren Tests im Haushalt sichtbar.

Wenn der Wechsel zwischen zwei Modellen, die beide resident bleiben, denselben Ausschlag erzeugt, ist das Laden der Gewichte keine vollständige Erklärung. Entscheidend ist, ob sich die gelesene Datenmenge und der Zustand der residenten Modelle bei der langsamen Anfrage ändern.

Die Initialisierung der Laufzeitumgebung erzeugt einen zweiten kalten Pfad

Ein geladenes Modell kann dennoch operativ kalt sein. Die Laufzeitumgebung kann beim ersten Auftrag nach der Aktivierung einen Gerätekontext initialisieren, Kernel auswählen, Formen kompilieren, Graphen erfassen, KV-Blöcke zuweisen oder Caches für Tokenizer und Eingabevorlagen erstellen.

Eine technische Analyse zu Modell-Streaming und Aufwärmen trennt das Streaming des Speichers von der Initialisierung und dem Aufwärmen. Das charakteristische Muster dieser Phase besteht aus moderaten Checkpoint-E/A-Vorgängen, gefolgt von Kompilierung, Zuweisung oder Aktivität des Beschleunigers vor der Verarbeitung der Eingabe. Das Zwischenergebnis muss überprüfbar bleiben, bevor die Automatisierung fortgesetzt wird.

Modellform, Quantisierungs-Backend, Kontextlimit, Batch-Profile und Treiberzustand bestimmen, welche Artefakte wiederverwendet werden können. Ein schneller Wechsel zurück kann möglich sein, wenn Caches erhalten geblieben sind, während eine durch Speicherdruck ausgelöste Auslagerung denselben Pfad erneut kalt macht.

Warteschlangen und Prefill können wie eine Verzögerung beim Laden des Modells wirken

Die Wechselanfrage kann hinter dem Herunterfahren eines Modells, der Speicherfreigabe, einem anderen Benutzer oder einer langen Eingabe warten. Nach der Zulassung verarbeitet das Prefill jedes Eingabetoken vor der Dekodierung. Dadurch verlängern größere Verläufe die TTFT, ohne die Ladezeit des Modells zu verändern. Diese Grenze sollte unter realistischen Betriebsbedingungen separat gemessen werden.

Das Serving-Design mit Paged-KV-Cache-Zulassung erklärt, wie aktive Sequenzen Paged-KV-Blöcke belegen und wie die Zulassung von der verfügbaren Cache-Kapazität abhängt. Ein Wechsel, der die Cache-Reservierungen verändert, kann daher die Wartezeit unabhängig von der Checkpoint-Größe beeinflussen.

Die Fehlergrenze ist ein warmes, residentes Modell mit stabiler Initialisierung und einem Latenzausschlag, der der Eingabelänge oder der Nebenläufigkeit folgt. In diesem Fall besteht lediglich eine Korrelation mit dem Modellwechsel; die direkte Ursache ist das Prefill oder die Zeitplanung.

Featured

ZimaCube 2 Persönliche Cloud Home NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

TTFT in Laden, Aufwärmen, Warteschlange und Prefill aufteilen

Gib feste Eingaben erneut ein und protokolliere auf einer einzigen monotonen Uhr die Auslagerung des Modells, die Checkpoint-Datenmenge, den Speicherdurchsatz, die Übertragung vom Host zum Gerät, die Erstellung des Gerätekontexts, die Kernel-Kompilierung, die Graph-Erfassung, die KV-Zuweisung, die Wartezeit in der Warteschlange, die Prefill-Dauer und den ersten Dekodierungsschritt. Die praktische Auswirkung zeigt sich, wenn mehrere Quellen um begrenzten Kontext konkurrieren.

Vergleiche die Aufzeichnung mit der speicherbasierten Modellweiterleitung und teste anschließend separat den kalten Wechsel, den sofortigen Wechsel zurück, die Weiterleitung zwischen zwei residenten Modellen sowie kurze und lange Eingaben. Behalte Sampling, Client und Nebenläufigkeit bei, damit sich nur der beabsichtigte Zustand ändert. Diese Abhängigkeit sollte in der endgültigen Oberfläche ausdrücklich erhalten bleiben.

Ordne den Ausschlag der frühesten Phase zu, die sich ausweitet. Halte die Gewichte resident, wenn das Laden dominiert, bewahre kompatible Artefakte auf, wenn die Initialisierung dominiert, und ändere die Zulassungs- oder Kontextregeln, wenn die Warteschlange oder das Prefill - nicht der Wechsel selbst - die TTFT bestimmt.