Wie reduziert Prefix-Caching die wiederholte Prompt-Verarbeitung auf einem Home-KI-Server?

Präfix-Caching reduziert wiederholte Prompt-Verarbeitung, indem der bereits berechnete Key-Value-Zustand für eine identische führende Token-Sequenz wiederverwendet wird.

Auf einem KI-Heimserver kann dieser gemeinsame Präfix eine Systemrichtlinie, ein Tool-Schema, ein langes Dokument, ein haushaltsweites Anweisungsset oder ein wiederholter Chatverlauf sein. Die erste Anfrage verursacht weiterhin die vollständigen Prefill-Kosten, aber spätere übereinstimmende Anfragen können einen großen Teil davon überspringen. Der Hauptvorteil ist ein kürzerer Prefill-Pfad und ein schnellerer erster Token, nicht eine kostenlose Generierung.

Wiederholte Prompts berechnen dasselbe Prefill ohne Cache erneut

Bevor ein Modell eine Antwort generiert, verarbeitet es als autoregressives Modell die Eingabetoken und erstellt den Key-Value-Zustand, der für die anschließende Decodierung verwendet wird. Ein langer System-Prompt, ein Tool-Schema, ein Dokumentkopf oder ein gemeinsamer Anweisungsblock kann daher bei jeder Anfrage dieselbe Prefill-Arbeit verursachen.

Prompt Cache formalisiert diese Möglichkeit, indem es Attention-Zustände aus überlappenden Prompt-Segmenten wiederverwendet. Auf einem KI-Heimserver kann der wiederholte Abschnitt Tausende von Token umfassen, obwohl der Benutzer nur einen neuen Satz beiträgt.

Ohne Wiederverwendung führt die GPU oder CPU diese Matrixoperationen erneut aus und liest für denselben Präfix dieselben Modellgewichte. Die Ausgabe kann identisch sein, aber der Server bezahlt weiterhin die Rechenkosten für die Vorbereitung.

Ein Präfix-Cache speichert den KV-Zustand eines bereits verarbeiteten Präfixes

Nach der ersten kompatiblen Anfrage kann die Laufzeitumgebung den mit dem gemeinsamen Präfix verknüpften KV-Zustand behalten. Eine spätere Anfrage beginnt mit der Prüfung, ob ihre führende Token-Sequenz mit den gecachten Blöcken übereinstimmt.

Der automatische Präfix-Cache von vLLM identifiziert Blöcke anhand von den Token im Block und dem vorangehenden Präfix. Übereinstimmende Anfragen können auf dieselben physischen Cache-Blöcke verweisen, anstatt doppelte Zustände zuzuweisen und zu berechnen.

Das wiederverwendbare Objekt ist weder die endgültige Antwort noch eine allgemeine semantische Zusammenfassung. Es handelt sich um einen modellspezifischen Attention-Zustand für einen exakt kompatiblen Präfix.

Ein Cache-Treffer überspringt das gemeinsame Prefill, berechnet aber weiterhin das neue Suffix

Wenn der Präfix übereinstimmt, kann die Laufzeitumgebung beim gespeicherten Attention-Zustand beginnen und nur die neuen Token nach der Cache-Grenze auswerten. Ein Haushaltsassistent mit einem stabilen System-Prompt kann so vor jedem kurzen Befehl wiederholte Arbeit vermeiden.

LMCache beschreibt die Wiederverwendung des KV-Caches über LLM-Anfragen hinweg als Optimierung auf der Serving-Ebene und nicht als Änderung der Modellgewichte.

Die neue Benutzernachricht muss weiterhin einem Prefill unterzogen werden, und jeder generierte Ausgabetoken erfordert weiterhin Decodierungsberechnungen. Präfix-Caching reduziert hauptsächlich redundante Arbeit, bevor die Generierung beginnt.

Featured

ZimaCube 2 Persönliche Cloud Home NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Lange stabile Präfixe sorgen für den größten Zeitgewinn bis zum ersten Token

Ein Cache spart Arbeit proportional zu dem Anteil, der andernfalls erneut berechnet würde. Die Wiederverwendung eines 2.000 Token langen Anweisungs- und Dokumentpräfixes ist wichtiger als die Wiederverwendung einer zehn Token langen Begrüßung.

Das Serving-Design von SGLang verwendet eine strukturierte KV-Wiederverwendung, um Workloads mit gemeinsamem Präfix zu beschleunigen. Das entsprechende Szenario auf einem Heimserver ist eine wiederholte Agentenrichtlinie, ein Tool-Katalog, ein haushaltsweites Wissenspaket oder eine Dokumentvorlage.

Deshalb sollte Präfix-Caching anhand der Zeit bis zum ersten Token und des Prefill-Durchsatzes bewertet werden, nicht nur anhand der Token-pro-Sekunde-Rate während der Generierung. Die Decodierungsphase kann nahezu unverändert bleiben, während die Antwort früher beginnt.

Kleine Prompt-Änderungen können die Wiederverwendung an der Blockgrenze verhindern

Ein Cache arbeitet in der Regel exakt in Bezug auf Token und Modellzustand. Das Umordnen von Tooldefinitionen, das Einfügen eines veränderlichen Zeitstempels am Anfang, der Wechsel von Adaptern oder eine Änderung des System-Prompts kann dazu führen, dass spätere Blöcke nicht mehr wiederverwendet werden können.

Die Serving-Empfehlungen von Hugging Face unterscheiden Prefill- und Decodierungsplanung. Wenn stabile Inhalte früh im Prompt stehen, kann ein größerer Teil des Prefills wiederverwendet werden.

Anwendungen sollten daher vermeiden, veränderliche Daten am Anfang eines ansonsten stabilen Präfixes einzufügen, wenn dieselben Informationen weiter hinten platziert werden könnten.

Cache-Kapazität und Verdrängung bestimmen die Grenzen auf dem Heimserver

KV-Blöcke verbrauchen Speicher, daher kann der Server nicht jeden Präfix dauerhaft behalten. Gleichzeitige Unterhaltungen, lange Kontexte und mehrere Modelle konkurrieren um denselben Speicherpool und können alte wiederverwendbare Zustände verdrängen.

Die Erklärung von ZimaSpace zu Modell-Caching und der Latenz bei warmen Antworten beschreibt die übergeordnete Cache-Hierarchie. Präfix-Caching ist nur eine Ebene und sollte nicht mit dem dauerhaften Vorhalten von Modellgewichten im Speicher verwechselt werden.

Miss die Cache-Trefferquote, die Anzahl wiederverwendeter Token, die Zeit bis zum ersten Token, den Prefill-Durchsatz, den KV-Speicherverbrauch und die Verdrängungsrate unter der realen Auslastung durch mehrere Haushaltsmitglieder.

Die Dokumentation von NVIDIA zu TensorRT-LLM beschreibt die Wiederverwendung des KV-Caches als Serving-Optimierung mit derselben grundlegenden Einschränkung: Wiederverwendbarer Zustand hilft nur, solange die übereinstimmenden Blöcke verfügbar bleiben.