Modell-Caching verändert die Antwortzeit, indem wiederholte Anfragen bereits heruntergeladene Dateien, im Speicher befindliche Gewichte, kompilierte Kernel oder zuvor verarbeitete Prompt-Zustände wiederverwenden.
Ein KI-Heimserver verfügt nicht über einen einzigen universellen Cache. Das Modellartefakt kann bereits auf dem lokalen Speicher vorhanden sein, seine Dateiseiten können im System-RAM verbleiben, die Gewichte können im Beschleunigerspeicher geladen bleiben, kompilierter Ausführungscode kann wiederverwendbar sein, und ein wiederholter System-Prompt kann weiterhin über einen gültigen KV-Zustand verfügen. Jede Ebene entfernt einen anderen Teil des Anfragepfads. Die folgenden Abschnitte trennen diese Ebenen, damit eine schnelle zweite Antwort nicht fälschlicherweise als schnellere Modellgenerierung oder bessere Hardware interpretiert wird.
Modell-Caching umfasst mehrere unabhängige Ebenen
Die erste wichtige Unterscheidung betrifft die Art der zwischengespeicherten Daten. Ein heruntergeladener Checkpoint vermeidet die Netzwerkübertragung, der Dateisystem-Cache verhindert das erneute Lesen bestimmter Blöcke vom Speicher, geladene Gewichte vermeiden das erneute Laden des Modells, kompilierte Artefakte vermeiden Einrichtungsaufwand, und ein Präfix-Cache verhindert die erneute Berechnung gemeinsamer Prompt-Tokens.
Die Forschung zu mehrstufigem Caching betrachtet den Modellstart als Bewegung durch Speicher, Hauptspeicher und Beschleunigerspeicher und nicht als einen einfachen Zustand zwischen „kalt“ und „warm“. Eine Anfrage kann auf einer Ebene warm und auf einer anderen kalt sein.
Das erklärt, warum die Aussage „Das Modell ist im Cache“ unvollständig ist. Der Server kann die Dateien lokal gespeichert haben und dennoch VRAM zuweisen, Gewichte laden, Kernel kompilieren und den Prompt verarbeiten müssen, bevor er ein Token erzeugt.
Ein Artefakt-Cache beseitigt Verzögerungen durch Downloads und Repositories
Wenn Modelldateien bereits auf dem Heimserver vorhanden sind, entfallen beim Start die Authentifizierung, Prüfungen von Repository-Metadaten, die externe Bandbreite und das Herunterladen mehrerer Gigabyte großer Shards. Die Laufzeitumgebung kann mit der lokalen Kopie beginnen.
Netflix beschreibt das Caching von Modellartefakten als notwendig, weil das Herunterladen großer Gewichte während des Starts die praktikable Latenz von Schedulern überschreitet. Derselbe Mechanismus ist zu Hause relevant, wenn ein Container neu erstellt oder ein Modell nach einer Bereinigung gestartet wird.
Der Artefakt-Cache garantiert keinen schnellen ersten Token. Ein lokaler Checkpoint kann sich weiterhin auf einem langsamen Laufwerk befinden, viele Shards verwenden, eine Konvertierung erfordern oder mit NAS-Lese- und Schreibvorgängen konkurrieren.
Der Dateisystem-Cache kann das zweite Laden deutlich beschleunigen
Nachdem das Betriebssystem Modelldateien gelesen hat, können saubere Dateiseiten im ungenutzten System-RAM verbleiben. Bei einem späteren Start lassen sich diese Daten aus dem Speicher abrufen, anstatt erneut auf das Speichergerät warten zu müssen.
MAIO verbessert den Start von LLMs durch die Optimierung der beim Laden von Modellen verwendeten Dateisystem-Cache-Richtlinie. Die Ergebnisse zeigen, warum zwei Starts über denselben NVMe-Pfad je nach den weiterhin gecachten Modellseiten unterschiedliche Lesezeiten haben können.
Dieser Cache kann freigegeben werden. Backups, Dateifreigaben, Datenbanken oder ein anderes Modell können diese Seiten verdrängen. Daher kann eine gestern schnelle Antwort nach Speicherdruck oder einem Neustart wieder durch die Geschwindigkeit des Speichers begrenzt sein.
Benchmarks, die den Zustand des Seiten-Caches nicht definieren, vermischen zwei Speicherbedingungen und können die Verbesserung durch ein Laufwerks-Upgrade überbewerten.
Im Speicher verbleibende Gewichte beseitigen die größte Ladegrenze
Wenn Gewichte im RAM, Unified Memory oder VRAM verbleiben, kann die Laufzeitumgebung direkt zur Prompt-Verarbeitung übergehen. Das Entladen des Modells gibt Kapazität für andere Anwendungen frei, führt aber dazu, dass die nächste Anfrage den Ladepfad erneut durchlaufen muss.
Der Leitfaden von ZimaSpace zu im Speicher verbleibenden Modellen zeigt das typische Muster: eine langsame Anfrage nach der Verdrängung, gefolgt von normalen Antworten, solange das Modell warm bleibt.
Die Speicherresidenz verändert hauptsächlich die Bereitschaft und die Zeit bis zum ersten Token. Sie erhöht nicht unbedingt die Rate der Ausgabetokens, sobald die Generierung läuft.
Wenn jedes Modell im Speicher verbleibt, kann dies außerdem den Speicherdruck erzeugen, durch den ein anderes Modell, ein KV-Cache oder eine Heimserver-Anwendung verdrängt wird.
Kompilierungs- und Kernel-Caches beseitigen den Aufwand der ersten Ausführung
Einige Laufzeitumgebungen spezialisieren Kernel, erfassen Ausführungsgraphen oder kompilieren Code für das aktive Modell, die GPU-Architektur, Tensorformen und die Laufzeitkonfiguration. Die erste kompatible Anfrage kann Arbeiten ausführen, die spätere Anfragen wiederverwenden.
Eine praktische Analyse von Kaltstarts weist darauf hin, dass sich die Kompilierung zur Laufzeit zwischen dem Laden der Gewichte und der Bereitstellung der ersten Antwort befinden kann. Ein persistenter Kompilierungs-Cache verlagert diese Kosten von späteren Starts weg, bis eine Änderung am Modell, Treiber, der Laufzeitumgebung oder Hardware ihn ungültig macht.
Dadurch entsteht ein weiterer warmer Zustand: Dateien und Gewichte können bereits vorhanden sein, während eine neue Form oder ein neuer Ausführungspfad dennoch eine Latenzspitze verursacht.
Präfix-Caching reduziert die Prefill-Zeit, nicht aber die Decodierung neuer Tokens
Ein wiederholter System-Prompt, ein langes Dokumentpräfix oder ein gemeinsamer Anweisungsblock muss normalerweise erneut verarbeitet werden, bevor das Modell die neue Benutzereingabe erreicht. Ein Präfix-Cache speichert den wiederverwendbaren Aufmerksamkeitszustand aus dieser vorherigen Prefill-Phase.
Die Forschung zu Prompt Cache berichtet über eine geringere Latenz bis zum ersten Token, wenn Anfragen lange Prompt-Module wiederverwenden. Der Vorteil wächst mit der Länge des gemeinsamen Präfixes, weil mehr Prefill-Berechnungen übersprungen werden können.
Beliebige neue Prompts werden dadurch nicht schneller, und die Kosten für die Decodierung neu erzeugter Ausgabetokens entfallen ebenfalls nicht. Cache-Treffer hängen von einer exakten oder unterstützten Präfix-Wiederverwendung, der verfügbaren Cache-Kapazität und der Verdrängungsrichtlinie der Laufzeitumgebung ab.
Kalte und warme Pfade als separate Antwortklassen messen
Teste eine feste Anfrage nach einem Neustart, nach dem Laden des Modells, nach einer unmittelbaren Wiederholung, nach einer längeren Leerlaufzeit und nach einer konkurrierenden Arbeitslast. Erfasse Download des Artefakts, Speicherzugriff, Modellladen, Kompilierung, Prompt-Auswertung, erstes Token und die Rate der Ausgabetokens getrennt.
Eine Analyse von Kalt-Caches weist darauf hin, dass die Latenz bei warmem Cache eine längere Spitze verbergen kann, wenn einige Anfragen den Cache verfehlen. Ein Haushaltsassistent sollte anhand der Anfragemischung bewertet werden, die tatsächlich auftritt, und nicht nur anhand eines unmittelbar wiederholten Benchmarks.
Sobald die verfehlte Ebene identifiziert ist, wird die Lösung konkreter: Modelldateien vorab abrufen, ausreichend Spielraum für den Seiten-Cache bewahren, die Keep-Alive-Zeit des Modells verlängern, Kompilierungsartefakte dauerhaft speichern oder die Präfix-Wiederverwendung für stabile gemeinsame Prompts aktivieren.
FAQ
Verbraucht ein gecachtes Modell immer weniger RAM?
Nein. Einige Caches belegen absichtlich RAM oder VRAM, um zukünftigen Aufwand zu reduzieren. Sie tauschen Kapazität gegen geringere Latenz, anstatt den Speicherverbrauch zu senken.
Warum ist die erste Antwort langsam, während spätere Antworten schnell sind?
Die erste Anfrage muss möglicherweise Gewichte laden, Laufzeitstatus zuweisen, Kernel kompilieren oder einen langen Prompt verarbeiten. Spätere Anfragen verwenden eines oder mehrere dieser Ergebnisse wieder.
Kann das Leeren von Caches falsche KI-Antworten beheben?
In manchen Fällen können dadurch veraltete oder beschädigte Laufzeitartefakte behoben werden. Modell-Caches beeinflussen normalerweise jedoch das Laden und die Wiederverwendung von Berechnungen und nicht die faktische Qualität unveränderter Gewichte und Prompts.
Tech- & KI-Zentrum
Mehr zum Lesen

Wie beeinflusst das Downsampling von Zeitreihen die Anomalieerkennung im Smart Home?
Sehen Sie, wie Bucket-Breite, Aggregation, Anti-Aliasing, fehlende Daten, Ereignisdauer und Aufbewahrung über mehrere Skalen die Erkennungsrate von Anomalien im Smart Home verändern.

Wie kombiniert ein Belegungsraster schwache Smart-Home-Signale?
Erfahren Sie, wie räumliche Zellen, Sensormodelle, Log-Odds-Aktualisierungen, Zerfall, korrelierte Evidenz und Schwellenwerte schwache Signale aus dem Zuhause in Belegungsschätzungen umwandeln.

Wie beeinflusst die photometrische Normalisierung das private Clustering von Gesichtern?
Sehen Sie, wie die Beleuchtungskorrektur Gesichtsausschnitte, Einbettungen, Clusterabstände, Schwellenwerte, Übernormalisierung und die Bewertung der privaten Fotosuche verändert.

