Wie Prefix Caching LLM-Prompts und gecachte Tokens wiederverwendet
Automatische Übersetzung
Dieser Artikel wurde automatisch aus der englischen Originalversion übersetzt.
Prefix Caching verwendet Attention-Zustände eines früheren kompatiblen Prompt-Präfixes erneut. Eine neue Anfrage verarbeitet nur den verbleibenden, nicht gecachten Teil, statt alle Prompt-Berechnungen zu wiederholen. Das hilft bei Workloads mit wiederholten Systemanweisungen, Beispielen, Dokumenten oder Gesprächspräfixen.
Der Abgleich betrifft Tokens und Model-Zustand. Ähnliche Formulierungen, wiederholter Text an einer späteren Stelle im Prompt oder dieselben Tokens mit einem anderen Adapter begründen keinen gültigen Cache-Treffer.
Was übereinstimmen muss
In einem kausalen Transformer hängen die gecachten Keys und Values eines Tokens von den vorherigen Tokens ab. Wer eine später wiederholte Passage nach einer geänderten früheren Passage wiederverwendet, würde andere kontextabhängige Zustände nutzen.
| Mögliche Wiederverwendung | Prüfung |
|---|---|
| Identischer System Prompt | Exakte Token-IDs und kompatibler Model-Zustand |
| Wiederholtes Dokument | Identisches vorangehendes Präfix sowie identisches Dokument |
| Fortgesetztes Gespräch | Unveränderte frühere Nachrichten, Vorlage und Tokens |
| Derselbe Text mit einem anderen Adapter | Adapter-Identität und Kompatibilitätsregeln des Caches |
| Multimodaler Prompt | Identität von Bildern und Medien, nicht nur Platzhalter-Tokens |
Das Prefix-Cache-Design von vLLM bildet Hashes aus den Tokens eines Blocks, seinem übergeordneten Präfix und zusätzlichen Kennungen wie LoRA und multimodalem Zustand. Es verwendet vollständige Blöcke erneut; ein unvollständiger letzter Block ist nicht automatisch ein Cache-Treffer. Cache-Salts können außerdem Anfragen voneinander trennen, die keinen gecachten Zustand teilen sollen.
RadixAttention von SGLang organisiert wiederverwendbare Präfixe in einem Radixbaum. Die Darstellung unterscheidet sich, aber ein kompatibler Präfixzustand ist weiterhin erforderlich.
Vermiedene Prefill-Arbeit messen
Prefix Caching vermeidet vor allem wiederholte Prompt-Berechnungen. Es beseitigt weder die Dekodierung noch deren Attention über den verfügbaren Verlauf. Eingesparte Berechnungen bedeuten auch nicht, dass sich die TTFT jeder Anfrage verbessert: Wartezeiten in der Warteschlange und Anfragen bei kaltem Cache bleiben bestehen.
Vergleichen Sie Anfragen bei kaltem Cache getrennt mit Anfragen, deren wiederholtes Präfix bereits im Cache liegt. Erfassen Sie wiederverwendete Tokens, nicht nur den Anteil der Anfragen mit irgendeinem Treffer. Ein Treffer für 32 Tokens und einer für 8,000 Tokens vermeiden unterschiedlich viel Arbeit. Messen Sie den belegten Cache-Speicher, Verdrängungen und Latency nach Präfixlänge.
Platzieren Sie stabile Anweisungen vor anfragespezifischen Daten, sofern diese Reihenfolge die beabsichtigte Wirkung des Prompts erhält. Berücksichtigen Sie Mandanten- und Adapter-Kompatibilität in der Cache-Richtlinie. Geben Sie den Cache-Zustand an, wenn Sie Serving-Ergebnisse veröffentlichen.
Engineering-Leitfaden: Prefix Caching erklärt den Zusammenhang zwischen Wiederverwendung und KV-Speicherzuweisung.