Prompt-Caching in Strom
Eine kurze Einführung, wie wir bei Strom cachen und wie ihr eure Anfragen für möglichst viel Cache-Wiederverwendung optimiert.
Bei einer Anfrage an Strom greifen zwei Ebenen des Cachings:
- Caching innerhalb einer Anfrage: Caching zwischen den Teilen einer einzelnen API-Anfrage
- Caching über Anfragen hinweg: wenn aufeinanderfolgende Anfragen einen gemeinsamen Anfang haben
1. Caching innerhalb einer Anfrage
Eine Anfrage mit diesem Aufbau:
State + Question 1 + Question 2 + ...läuft intern als ein Modellaufruf pro Frage (parallel):
State + Question 1
State + Question 2
...Den State können wir offensichtlich cachen, da er der gemeinsame Anfang ist. In einem eigenen "Priming"-Schritt legen wir den State in den Cache, und jede Frage startet dann von diesem gecachten State. Priming kostet einen zusätzlichen Aufruf, deshalb machen wir es nur, wenn es sich lohnt: wenn genug Fragen einen ausreichend langen State teilen. Anfragen mit Bildern werden nicht geprimt.
2. Caching über Anfragen hinweg
Das ist der einfachere Fall. Wenn eine Anfrage denselben Anfang (State und optional Fragen) hat wie eine vorherige, verwendet Strom diesen gemeinsamen Teil automatisch wieder, was die Latenz senkt.
Tipps, um das Beste aus dem Caching herauszuholen
- Stellt viele Fragen in einer Anfrage statt einer Anfrage pro Frage.
- Haltet den State zwischen Anfragen, die ihn teilen sollen, byte-identisch. Es gelten die üblichen Regeln für LLM-Caching, zum Beispiel den veränderlichen Teil des States (etwa Kontext oder das aktuelle Datum) ans Ende zu stellen.
- Wie viel aus dem Cache wiederverwendet wird, hängt auch von der Auslastung unserer Server ab.
- Caching wirkt sich nur auf die Latenz aus. Die Zahl der abgerechneten Tokens hängt nur von der Größe der Anfrage ab.
- Jede Antwort gibt in
usage.cached_input_tokensan, wie viele Input-Tokens aus dem Cache kamen.