BLUF — Prefix-Caching kann wiederholte Prompt-Verarbeitung vermeiden. Die Arbeit zur Generierung einer Antwort entfällt dadurch nicht. Entscheiden Sie anhand der Kosten je akzeptierter, SLO-konformer Antwort unter einem repräsentativen Lastmix — nicht anhand eines Screenshots mit schneller erster Token-Ausgabe bei warmem Cache. Beim Eigenbetrieb steht wiederverwendbarer KV-Zustand gegen effektiv nutzbare Serving-Kapazität. Beim API-Einkauf entscheidet der tatsächliche Abrechnungsvertrag für gecachte Eingaben. Beides ist kein pauschaler Rabatt auf sämtliche Tokens.
Dieser Beitrag liefert einen Versuchsplan und eine transparente Kostenrechnung, keine gemessenen Leistungswerte. Die konkrete Entscheidung lautet: Rechtfertigen wiederholte Präfixe ihren betrieblichen und speicherbezogenen Aufwand? Nutzen Sie das SLO-Modell für selbst betriebene LLM-Inferenz für die Phaseninstrumentierung und den folgenden Versuch, bevor Sie Caching als Einsparung in der Kapazitätsplanung ansetzen.
Was wiederverwendet wird — und was nicht
Die vLLM-Dokumentation zu Automatic Prefix Caching beschreibt die Wiederverwendung bereits berechneter Key/Value-Zustände, wenn eine neue Anfrage ein vorhandenes Präfix teilt. Die Engine überspringt die Berechnung des wiederverwendbaren Prompt-Anteils. Dieselbe Dokumentation begrenzt den Nutzen ausdrücklich auf Prefill statt auf die Generierung neuer Tokens. Beim Decoding wird der Kontextzustand weiterhin verwendet und die angeforderte Ausgabe erzeugt.
Ein Cache-Treffer ist deshalb keine gespeicherte Antwort. Zwei Anfragen können System-Prompt und Dokumentpräfix teilen, aber unterschiedliche Fragen stellen und andere Antworten erzeugen. Umgekehrt reicht semantisch ähnlicher Text nicht aus: Token-Identität, Reihenfolge und vorausgehender Kontext sind entscheidend. Die vLLM-Designbeschreibung erläutert Hashes aus Block-Tokens und vorausgehendem Präfix sowie die Wiederverwendung vollständiger Blöcke. Ein gemeinsames Suffix nach einem früh veränderten Token ist kein gemeinsames Präfix.
Platzieren Sie stabile Anweisungen und freigegebene gemeinsame Inhalte vor anfragespezifischen Inhalten, sofern die Aufgabensemantik erhalten bleibt. Verschieben Sie keine Sicherheitsanweisungen, verändern Sie keine Chat-Rollen und schwächen Sie keine Aktualitätsanforderungen der Retrieval-Daten, nur um mehr Treffer zu erzielen. Fixieren Sie Tokenizer, Chat-Template, Modell- und Adapterrevisionen für den Versuch. Ein früh eingefügter Zeitstempel oder eine Anfragekennung kann nützliche Wiederverwendung verhindern. Belassen Sie Betriebsmetadaten außerhalb des Prompts, wenn das Modell sie nicht benötigt.
Trennen Sie drei unterschiedliche Cache-Entscheidungen
Der Leitfaden zu Cache-Strategien von Hugging Face unterscheidet dynamische, statische, ausgelagerte und quantisierte KV-Caches. Diese Varianten beschreiben Darstellung, Allokation oder Speicherort des Attention-Zustands. Sie bilden für sich genommen keinen Dienst zur Präfixfreigabe zwischen Anfragen. Der Leitfaden zeigt auch explizites Prefill mit anschließender Wiederverwendung; Anwendungscode benötigt weiterhin einen korrekten Lebenszyklus und eine Isolationsregel.
Statische Allokation kann Kompilierung unterstützen, aber mehr Kapazität reservieren, als kurze Anfragen benötigen. Offloading verschiebt Zustand zwischen CPU und GPU und kann den Durchsatz senken. Quantisierter Zustand spart Speicher, kann jedoch zusätzliche Latenz verursachen und benötigt eine Qualitätsprüfung. Diese Entscheidungen können mit Prefix-Caching kombiniert werden. Messen Sie sie dennoch als getrennte Änderungen. Wenn Sie Cache-Strategie, Modellquantisierung und Prefix-Caching gleichzeitig ändern, können Sie Unterschiede nicht sauber APC zuschreiben.
Halten Sie auch die Decoding-Strategie konstant. Die Transformers-Dokumentation zu Generierungsstrategien erläutert, wie Greedy Decoding, Sampling und Beam Search die Token-Auswahl verändern. Ausgabelimits, Stoppregeln und tatsächlich erzeugte Längen gehören in das Versuchsmanifest. Eine kürzere Antwort belegt keine Beschleunigung des Decodings durch Prefix-Caching.
Kosten-Wasserfall: ein explizites Rechenmodell
Beginnen Sie mit einer Zuordnung der Arbeit, bevor Sie Latenz in Geld umrechnen. Für eine feste Anfrageklasse bezeichnet P die bisherigen Prefill-Kosten, D die Decoding-Kosten und F weitere zugeordnete Serving-Kosten. h ist der über alle Anfragen vermiedene Anteil der Prefill-Arbeit — nicht bloß der Anteil von Anfragen mit mindestens einem Treffer. H umfasst Cache-bedingten Zusatzaufwand und gegebenenfalls separat berücksichtigte Kapazitätsnachteile. Das vereinfachte Modell lautet C_Basis = P + D + F und C_Cache = (1 − h)P + D + F + H. Vergleichbare Ausgabearbeit und Serving-Bedingungen sind Voraussetzungen; prüfen Sie Abweichungen unter Mischlast.
| Schritt im Wasserfall | Beispielhafte Kosteneinheiten je Anfrage | Bedeutung |
|---|---|---|
| Bisheriges Prefill | 40 | Verarbeitung wiederholter und individueller Eingaben |
| Bisheriges Decoding | 50 | Ausgabegenerierung bleibt notwendig |
| Weitere Basiskosten | 10 | Zugeordnete Kosten außerhalb der Phasen |
| Bisherige Gesamtkosten | 100 | Ausgangswert |
| Vermiedenes Prefill | −30 | Angenommene Reduktion der Prefill-Arbeit um 75% |
| Cache-Aufwand und Kapazitätsnachteil | +5 | Explizite Modellannahme |
| Gesamtkosten mit Cache | 75 | Nettoreduktion um 25 Kosteneinheiten |
Diese Zahlen sind frei gewählte Szenarioeingaben zur Erläuterung der Rechnung, kein GPU-Benchmark und kein Anbieterpreis. Es gilt 100 − 30 + 5 = 75: eine Gesamtreduktion um 25%, nicht um 75%. Berücksichtigen Sie einen Kapazitätsnachteil nicht doppelt, wenn eine vollständige Flottenrechnung oder ein GPU-Stunden-Nenner ihn bereits erfasst. Die vereinfachte Gewinnschwelle lautet hP > H. Die Produktionsfreigabe erfordert zusätzlich Qualitäts-, Isolations- und SLO-Prüfungen.
Bei eigenen oder reservierten GPUs senkt weniger Prefill-Arbeit nicht automatisch die Rechnung. Eine zahlungswirksame Ersparnis entsteht erst, wenn Kapazität tatsächlich abgebaut oder vermieden werden kann. Andernfalls berichten Sie höheren SLO-konformen Durchsatz oder zurückgewonnene Reserve. Berechnen Sie Flottenkosten je akzeptierter Antwort über das gesamte Testintervall einschließlich Leerlauf und Aufwärmen. Wiederholungen und Fehler zählen zu den Kosten, nicht zu den erfolgreichen nutzbaren Antworten. Gleichen Sie bei Anbieter-APIs ungecachte Eingaben, gecachte Eingaben, Ausgaben und gegebenenfalls Speicher- oder Schreibgebühren mit dem tatsächlichen Vertrag ab. Dieses Rechenmodell ersetzt keine Abrechnungsregeln. Die Entscheidungsebene für produktionsreifes Model Routing ergänzt die erforderliche Richtlinien- und Abrechnungsgrenze.
Benchmark-Matrix: kalt, warm und realistisch
Fixieren Sie Serving-Image-Digest, Modell- und Tokenizerrevision, Hardware, Parallelismus, Speicherbudget, Scheduler-Einstellungen, Generierungskonfiguration, Prompt-Familien und Ankunftsfolge. Trennen Sie Modellladen und Kernel-Aufwärmen vom Aufwärmen des Präfix-Caches: Ein kalter Präfix-Cache darf keine ansonsten uninitialisierte Laufzeit bedeuten. Verwenden Sie unabhängige Läufe oder ein verifiziertes Reset-Verfahren und dokumentieren Sie den hergestellten Kaltzustand.
| Testfall | Präfix- und Ausgabemix | In jedem Lauf erfassen | Sichtbare Entscheidung |
|---|---|---|---|
| Basis ohne APC | Repräsentative Ein- und Ausgaben | Definition der Treffermetrik; TTFT; Inter-Token-Latenz; Spitzenspeicher; Durchsatz | Vergleichbare Referenz statt uninitialisiertem Server |
| APC aktiviert, kalt | Gleiche Lastfolge ohne vorbereitete Präfixe | Gleiche Metriken plus Aufwärmkosten und Fehler | Erstnutzungsaufwand und Betriebsbereitschaft |
| APC aktiviert, warm | Wiederholte lange Präfixe, kurze Ausgaben | Gleiche Metriken plus Anteil wiederverwendeter Eingabe-Tokens | Günstiger plausibler Wiederverwendungsfall |
| Produktionsnaher Mischlast-Replay | Wiederholte und individuelle Präfixe, ursprüngliche Zeitabstände | Gleiche Metriken plus Eviction und Preemption | Bestand der Wiederverwendung unter wechselnder Last |
| Decoding-lastiger Stresstest | Gleiche Präfixe, lange Ausgaben | Gleiche Metriken plus tatsächliche Ausgabelängen | Niedrigere Obergrenze der Gesamtersparnis |
| Isolation und Neustart | Getrennte Vertrauensgruppen; Neustart oder Rollout | Gleiche Metriken plus gruppenübergreifende Wiederverwendungstests | Sicherheitsgrenze und Wiederanlaufkosten |
Dies ist eine unausgefüllte Messmatrix, keine Ergebnisprognose. Berichten Sie p50/p95/p99 für TTFT und Inter-Token-Latenz, erfolgreiche Anfragen pro Sekunde, Ausgabe-Tokens pro Sekunde, tatsächlichen Spitzenspeicher des Geräts und verfügbare KV-Block-Auslastung der Engine. Prüfen Sie das bereitgestellte Metrikschema, bevor Sie einen Counter benennen. Präfix-Treffermetriken können Tokens, Blöcke oder Anfragen zählen. Dokumentieren Sie Zähler und Nenner. Ein Treffer für ein kurzes Präfix ist nicht gleichwertig mit der Wiederverwendung fast eines ganzen langen Prompts.
Variieren Sie die angebotene Ankunftsrate bei realistischen Präfixhäufigkeiten und Wiederverwendungsabständen. Ein Closed-Loop-Client, der vor jeder neuen Anfrage auf die vorige Antwort wartet, kann Überlast verdecken. Testen Sie auch das tatsächliche Ankunftsmuster mit begrenzter Zulassung und erfassen Sie Ablehnungen sowie Zeitüberschreitungen. Randomisieren und wiederholen Sie Läufe, damit Temperaturzustand, Hintergrundlast und Cache-Historie nicht als Behandlungseffekt erscheinen. Behalten Sie Ergebnisse je Anfrageklasse bei, statt kurze Chats und lange Dokumentgenerierung zu mitteln.
Speicherdruck und Isolation sind Freigabekriterien
Gecachte Blöcke belegen einen verwalteten Pool, nicht zwingend eine zusätzlich angelegte vollständige Kopie des Modellkontexts. Gemeinsame Nutzung kann doppelte Zustände reduzieren; selten wiederverwendete Blöcke können für neue Arbeit verdrängt werden. Hoher allokierter GPU-Speicher allein belegt deshalb keinen Kapazitätsschaden durch APC. Prüfen Sie aktive und wiederverwendbare Zustände, soweit die Engine sie offenlegt. Korrelieren Sie Eviction, Preemption, wartende Anfragen und nutzbaren Durchsatz. Verwerfen Sie eine Optimierung des warmen Caches, wenn die Klasse individueller Präfixe dadurch ihr vereinbartes Budget überschreitet.
vLLM dokumentiert cache_salt zur Begrenzung der Wiederverwendung auf Anfragen mit gleichem Salt. Behandeln Sie dies als Engine-Mechanismus, nicht als vollständige Mandantenauthentifizierung oder allgemeine Garantie gegen Seitenkanäle. Leiten Sie die Vertrauensgruppe am authentifizierten Gateway ab; ein nicht vertrauenswürdiger Aufrufer darf keinen fremden Gruppenwert auswählen. Prüfen Sie Unterstützung und Verhalten in der konkret eingesetzten Version und im tatsächlichen Anfragepfad. Testen Sie gleiche Präfixe innerhalb und zwischen Gruppen einschließlich Proxy-Weiterleitung und Neustarts. Vertrauliche Prompts oder geheime Salt-Werte gehören nicht in Metriklabels.
Freigabecheckliste und Rücknahmeentscheidung
Prüfung 1 — Evidenz: Sichern Sie versioniertes Manifest, Verfahren für den Kaltzustand, Lastzusammensetzung, aggregierte Messwerte, Nennerdefinitionen und Streuung zwischen Läufen. Trennen Sie Beobachtungen von Annahmen der Kostenrechnung.
Prüfung 2 — Abnahme: Verlangen Sie die Einhaltung vereinbarter Budgets je Klasse für TTFT, Streaming, Fehler und Qualität. Vergleichen Sie Gesamtkosten je akzeptierter Antwort, nicht nur die Trefferquote. Vereinbaren Sie Schwellen mit der Serviceverantwortung, bevor Kandidatenergebnisse vorliegen.
Prüfung 3 — Sicherheit: Verifizieren Sie Vertrauensgruppenisolation, freigegebene Datenverarbeitung und Lebenszyklusverhalten. Wenn sich grenzüberschreitende Wiederverwendung nicht ausschließen lässt, deaktivieren Sie sie für die betroffene Route, statt einem Standardwert zu vertrauen.
Prüfung 4 — Einführung: Starten Sie einen Canary für eine Route mit dokumentierter Rückkehr zur Basiskonfiguration. Proben Sie kalten Cache bei Neustart und Rücknahme: Ein deaktivierter oder geleerter Cache kann eine Prefill-Lastspitze auslösen. Halten Sie ausreichend Reserve oder Zulassungskontrolle vor, um diese Spitze zu begrenzen.
Machen Sie aus dem Ergebnis eine Kapazitätsentscheidung
Wählen Sie eine Lastklasse mit wiederholten Dokumenten oder gemeinsamen Anweisungen sowie eine Kontrollklasse mit individuellen Präfixen. Bringen Sie eine bereinigte Ankunftsfolge, ein Serving-Manifest und die Kostengrenze in ein Architekturreview ein. Das Ergebnis sollte ein reproduzierbarer Benchmark, ein Isolationstest und eine ausdrückliche Beibehalten-oder-Deaktivieren-Entscheidung sein — kein allgemeines Beschleunigungsversprechen. Wenn gemessene Prefill-Ersparnisse realistischen Präfixwechseln, Ausgabelängen und Vertrauensgrenzen nicht standhalten, richten Sie den nächsten Optimierungszyklus auf den tatsächlich nachgewiesenen Engpass.
