Warum steigt die Latenz des ersten Tokens bei einem lokalen LLM, nachdem der Server im Leerlauf war?
Die Latenz bis zum ersten Token steigt nach einer Leerlaufphase oft an, weil die nächste Anfrage den Modell-, Speicher-, Beschleuniger- und Energiezustand wiederherstellen muss, den bereits aufgewärmte Anfragen wiederverwenden.
Ein heimischer KI-Server kann wiederholte Prompts schnell beantworten und sich dann langsam anfühlen, wenn die erste Anfrage am nächsten Morgen eintrifft. Das Modell befindet sich möglicherweise noch auf der Festplatte, aber seine Seiten, GPU-Zuweisung, Kernel und sein Ausführungskontext sind eventuell nicht mehr aktiv. Speichergeschwindigkeit, Speicherdruck, Laufzeit-Eviction, Energieverwaltung des Geräts und die Prompt-Länge bestimmen, wie viel Verzögerung zurückkehrt.
Leerlauf entfernt mehrere verschiedene Arten eines aktiven Zustands
Eine aufgewärmte Anfrage kann Gewichte wiederverwenden, die bereits im RAM oder VRAM liegen, vom Betriebssystem vorgehaltene Dateisystemseiten, initialisierte Beschleunigerbibliotheken, kompilierte Kernel, Speicherpools und einen aktiven Modell-Worker. Die Bereinigung im Leerlauf kann nur eine Ebene entfernen oder den gesamten Prozess beenden.
Checkpoint-Laden über mehrere Ebenen reduziert den Start von serverloser Modellinferenz, indem Checkpoints nahe an Beschleunigern gehalten, über mehrere Speicherebenen geladen und Anfragen dort eingeplant werden, wo der Modellzustand bereits lokal ist. Das Design zeigt, dass die Kaltstart-Latenz eine Kette aus Übertragungs- und Initialisierungsschritten ist und nicht nur aus einem einzelnen Wert für das Lesen von der Festplatte besteht.
Die beobachtbare Verzögerung hängt davon ab, welche Ebene kalt geworden ist. Ein weiterhin laufender Prozess benötigt möglicherweise nur das Hochfahren des Gerätetakts, während ein ausgelagertes Modell Gewichte lesen, Gerätespeicher zuweisen, Laufzeitstrukturen neu aufbauen und anschließend den Prompt verarbeiten muss, bevor es ein Token ausgibt.
Modellladen und Prefill summieren sich, bevor ein Token erscheint
Die Zeit bis zum ersten Token umfasst Warteschlangenzeit, Verfügbarkeit der Gewichte, Initialisierung der Laufzeit, Tokenisierung und Prefill über die gesamte Eingabe. Eine hohe Decodierungsrate kann diese Phasen nicht verbergen, weil kein Ausgabetoken existiert, bevor der Prefill-Zustand für die erste Decodierung erzeugt wurde.
Die Wiederverwendung von GPU-Speicher behält Parameter in ungenutztem GPU-Speicher und nutzt eine affin itätsbewusste Planung, um wiederholte Übertragungen zu reduzieren. Die berichteten Verbesserungen bei Kaltstarts zeigen, warum die teilweise Beibehaltung im Speicher wichtig sein kann, selbst wenn ein Dienst nicht jedes Modell vollständig geladen halten kann.
Ein langer System-Prompt kann daher auch bei warmen Gewichten langsam bleiben, während ein kurzer Prompt bei einem kalten Modell weiterhin ins Stocken geraten kann. Die getrennte Betrachtung von Ladezeit, Initialisierung, Prefill und erster Decodierung verhindert, dass ein einziger gemittelter TTFT-Wert die tatsächliche Kaltstart-Komponente verbirgt.
Energiesparen ist meist eine kleinere, aber messbare Ebene
CPUs, GPUs, NVMe-Geräte und PCIe-Verbindungen können bei Inaktivität in Energiesparzustände wechseln. Der erste Burst muss die Taktfrequenzen erhöhen und aktive Pfade wiederherstellen, wodurch vor Beginn der dauerhaften Berechnung eine kurze Anlaufphase entsteht; ein aggressiver Ruhezustand des Hosts kann durch das Anhalten von Diensten oder Laufwerken deutlich mehr Zeit hinzufügen.
Überlappende Kaltstartphasen überlagert das Laden von Modellen, Kommunikation und Berechnung bei Kaltstarts von Edge-LLMs. Die Arbeit zeigt, dass das Verbergen einer Startphase die Koordination mit den anderen Phasen erfordert, insbesondere wenn Gewichte und Berechnung auf Geräte mit begrenzten Ressourcen verteilt sind.
Die problematische Grenze liegt darin, jede langsame erste Antwort dem Energiezustand zuzuschreiben. Wenn die Verzögerung viele Sekunden beträgt, dominieren normalerweise die Auslagerung des Modells, Lesevorgänge aus dem Speicher, der Start des Containers oder das Prompt-Prefill gegenüber einem Übergang der Taktfrequenz im Millisekundenbereich. Diagnostizieren Sie den zeitlichen Ablauf, statt standardmäßig jede Energieeinsparung zu deaktivieren.
Kaltstart und Kosten eines kalten Prompts getrennt betrachten
Senden Sie nach 0, 1, 10, 60 und 480 Minuten Leerlauf jeweils denselben kurzen Prompt. Protokollieren Sie für jedes Intervall die Prozesslebensdauer, den Modellaufenthalt im Speicher, die RAM- und VRAM-Nutzung, gelesene Byte, Gerätetaktfrequenzen, Warteschlangenzeit, Tokenisierung, Prefill, erste Decodierung und die gesamte TTFT.
Vergleichen Sie die Speicherebene mit dem Speicher für den Modell-Kaltstart. Wiederholen Sie den Test anschließend, während Sie den Worker festhalten, nur den Dateisystem-Cache aufwärmen, ausschließlich den Host-RAM warm halten und die Prompt-Länge verändern. Jeder Durchlauf sollte eine einzelne Zustandsebene verändern, statt alle Optimierungen zu kombinieren.
Betrachten Sie den Server nur dann als warm, wenn wiederholte Leerlaufintervalle die erforderliche TTFT erhalten, ohne andere Dienste auszuhungern. Wenn das Festhalten des Modells Speicherdruck verursacht oder Workloads mit höherer Priorität blockiert, akzeptieren Sie einen begrenzten Kaltstart und machen Sie ihn sichtbar, statt den Zielkonflikt zu verbergen.
Empfohlene Produkte
Tech- & KI-Zentrum
Mehr zum Lesen
Was verursacht, dass ein KI-Agentenplaner bereits abgeschlossene Schritte wiederholt?
Verfolge wiederholte Planungsschritte anhand von Zustandsbeibehaltung, Abschlussnachweisen, der Analyse von Tool-Ergebnissen, dem Erhalt des Kontexts, Wiederholungsversuchen, neuer Planung und Abbruchbedingungen.
Was verursacht Berechtigungsfehler nur innerhalb von KI-Agenten-Unterprozessen?
Vergleichen Sie die Identität des übergeordneten Prozesses und des untergeordneten Prozesses, die Dateisystemansicht, die Umgebung, die Fähigkeiten, die Sicherheitsrichtlinie und den Pfad zur ausführbaren...
Was verursacht eine CPU-Sättigung, wenn Hardware-Transkodierung und Video-KI gleichzeitig ausgeführt werden?
Verfolge die CPU-Auslastung bei Codec-Offloading, Pixeldatenkonvertierung, Frame-Kopien, KI-Vorverarbeitung, Audio, Untertiteln, Speicherzugriffen und Prozessplanung.
