In meinem vorherigen BeitragImmediate Caching – was es ist, wie es funktioniert und wie es Ihnen viel Geld und Zeit sparen kann, wenn Sie KI-gestützte Apps mit hohem Datenverkehr ausführen. Im heutigen Beitrag führe ich Sie durch die Implementierung von Immediate Caching speziell mithilfe der OpenAI-API und bespreche einige häufige Fallstricke.
Eine kurze Erinnerung an Immediate Caching
Bevor wir uns die Hände schmutzig machen, werfen wir einen kurzen Blick auf das Konzept des Immediate Caching. Immediate Caching ist eine Funktionalität, die in Frontier-Modell-API-Diensten wie dem bereitgestellt wird OpenAI-API oder Claudes API, Dies ermöglicht das Zwischenspeichern und Wiederverwenden von Teilen der LLM-Eingabe, die häufig wiederholt werden. Solche wiederholten Teile können Systemaufforderungen oder Anweisungen sein, die jedes Mal beim Ausführen einer KI-App an das Modell übergeben werden, zusammen mit anderen variablen Inhalten, wie der Anfrage des Benutzers oder aus einer Wissensdatenbank abgerufenen Informationen. Um beim Immediate-Caching auf den Cache zugreifen zu können, müssen die wiederholten Teile des Prompts am Anfang des Prompts stehen, nämlich a Eingabeaufforderungspräfix. Damit das Immediate-Caching aktiviert werden kann, muss dieses Präfix außerdem einen bestimmten Wert überschreiten Schwelle (Beispiel: Für OpenAI sollte das Präfix mehr als 1.024 Token betragen, während Claude für verschiedene Modelle unterschiedliche Mindestcachelängen hat.) Sofern diese beiden Bedingungen erfüllt sind – wiederholte Token als Präfix, die den durch den API-Dienst und das API-Modell definierten Größenschwellenwert überschreiten – kann Caching aktiviert werden, um beim Ausführen von KI-Apps Skaleneffekte zu erzielen.
Im Gegensatz zum Caching in anderen Komponenten in einem RAG oder einer anderen KI-App erfolgt das Immediate-Caching auf Token-Ebene, in den internen Prozeduren des LLM. Insbesondere erfolgt die LLM-Inferenz in zwei Schritten:
- VorfüllenDas heißt, das LLM berücksichtigt die Benutzeraufforderung zum Generieren des ersten Tokens und
- DekodierungDas heißt, das LLM generiert rekursiv die Token der Ausgabe nacheinander
Kurz gesagt: Beim Immediate-Caching werden die Berechnungen gespeichert, die in der Pre-Fill-Section durchgeführt werden, sodass das Modell sie nicht erneut berechnen muss, wenn dasselbe Präfix erneut angezeigt wird. Alle Berechnungen, die in der Section der Dekodierungsiterationen stattfinden, werden nicht zwischengespeichert, auch wenn sie wiederholt werden.
Für den Relaxation des Beitrags werde ich mich ausschließlich auf die Verwendung von Immediate-Caching in der OpenAI-API konzentrieren.
Was ist mit der OpenAI-API?
In der API von OpenAI wurde das Immediate-Caching zunächst eingeführt 1. Oktober 2024. Ursprünglich wurde ein Rabatt von 50 % auf die zwischengespeicherten Token angeboten, heutzutage beträgt dieser Rabatt jedoch bis zu 90 %. Darüber hinaus können durch Zugriff auf den Immediate-Cache zusätzliche Latenzeinsparungen von bis zu 80 % erzielt werden.
Wenn das Zwischenspeichern von Eingabeaufforderungen aktiviert ist, versucht der API-Dienst, auf den Cache für eine übermittelte Anforderung zuzugreifen, indem er die übermittelte Eingabeaufforderung an einen entsprechenden Laptop weiterleitet, auf dem der entsprechende Cache voraussichtlich vorhanden ist. Dies wird als Cache-Routing bezeichnet. Zu diesem Zweck verwendet der API-Dienst normalerweise einen Hash der ersten 256 Token der Eingabeaufforderung.
Darüber hinaus ermöglicht ihre API auch die explizite Definition eines prompt_cache_key Parameter in der API-Anfrage an das Modell. Dabei handelt es sich um einen einzelnen Schlüssel, der definiert, auf welchen Cache wir uns beziehen. Ziel ist es, die Wahrscheinlichkeit weiter zu erhöhen, dass unsere Eingabeaufforderung an den richtigen Laptop weitergeleitet wird und den Cache erreicht.
Darüber hinaus bietet die OpenAI-API zwei unterschiedliche Arten des Cachings in Bezug auf die Dauer, die durch definiert werden prompt_cache_retention Parameter. Das sind:
- Beibehaltung des In-Reminiscence-Immediate-Cache: Dies ist im Wesentlichen der Normal-Caching-Typ, der für alle Modelle verfügbar ist, für die Immediate-Caching verfügbar ist. Beim In-Reminiscence-Cache bleiben zwischengespeicherte Daten für einen Zeitraum von 5 bis 10 Minuten zwischen Anfragen aktiv.
- Erweiterte Aufbewahrung des Immediate-Cache: Dies ist verfügbar für bestimmte Modelle. Der erweiterte Cache ermöglicht das Speichern von Daten im Cache für einen Zeitraum von maximal 24 Stunden.
Was nun die Kosten für all diese Kosten angeht, berechnet OpenAI dasselbe professional eingegebenem (nicht zwischengespeichertem) Token, unabhängig davon, ob wir das sofortige Caching aktiviert haben oder nicht. Wenn es uns gelingt, den Cache erfolgreich aufzurufen, werden uns die zwischengespeicherten Token zu einem stark reduzierten Preis in Rechnung gestellt, mit einem Rabatt von bis zu 90 %. Darüber hinaus bleibt der Preis professional Eingabe-Token sowohl für die In-Reminiscence- als auch für die erweiterte Cache-Aufbewahrung gleich.
Promptes Caching in der Praxis
Sehen wir uns additionally anhand eines einfachen Python-Beispiels mithilfe des API-Dienstes von OpenAI an, wie Immediate-Caching tatsächlich funktioniert. Genauer gesagt werden wir ein realistisches Szenario erstellen, in dem a lange Systemaufforderung (Präfix) wird über mehrere Anfragen hinweg wiederverwendet. Wenn Sie hier sind, haben Sie vermutlich bereits Ihre OpenAI API-Schlüssel installiert und die erforderlichen Bibliotheken installiert haben. Das erste, was Sie tun müssen, wäre additionally, das zu importieren OpenAI Bibliothek, sowie time zum Erfassen der Latenz und zum Initialisieren einer Instanz des OpenAI-Purchasers:
from openai import OpenAI
import time
shopper = OpenAI(api_key="your_api_key_here")Dann können wir unser Präfix definieren (die Token, die wiederholt werden und die wir zwischenspeichern möchten):
long_prefix = """
You're a extremely educated assistant specialised in machine studying.
Reply questions with detailed, structured explanations, together with examples when related.
""" * 200 Beachten Sie, wie wir die Länge künstlich erhöhen (mit 200 multiplizieren), um sicherzustellen, dass der Caching-Schwellenwert von 1.024 Token erreicht wird. Dann richten wir noch einen Timer ein, um unsere Latenzeinsparungen zu messen, und schon können wir endlich unseren Anruf tätigen:
begin = time.time()
response1 = shopper.responses.create(
mannequin="gpt-4.1-mini",
enter=long_prefix + "What's overfitting in machine studying?"
)
finish = time.time()
print("First response time:", spherical(finish - begin, 2), "seconds")
print(response1.output(0).content material(0).textual content)
Was erwarten wir additionally von hier aus? Für Modelle ab gpt-4o und neuer ist das Immediate-Caching standardmäßig aktiviert, und da unsere 4.616 Eingabe-Tokens deutlich über dem Schwellenwert von 1.024 Präfix-Tokens liegen, können wir loslegen. Diese Anfrage prüft additionally zunächst, ob es sich bei der Eingabe um einen Cache-Treffer handelt (das ist nicht der Fall, da wir zum ersten Mal eine Anfrage mit diesem Präfix stellen), und da dies nicht der Fall ist, verarbeitet sie die gesamte Eingabe und speichert sie dann im Cache. Wenn wir das nächste Mal eine Eingabe senden, die bis zu einem gewissen Grad mit den anfänglichen Token der zwischengespeicherten Eingabe übereinstimmt, erhalten wir einen Cache-Treffer. Lassen Sie uns dies in der Praxis überprüfen, indem wir eine zweite Anfrage mit demselben Präfix stellen:
begin = time.time()
response2 = shopper.responses.create(
mannequin="gpt-4.1-mini",
enter=long_prefix + "What's regularization?"
)
finish = time.time()
print("Second response time:", spherical(finish - begin, 2), "seconds")
print(response2.output(0).content material(0).textual content)
In der Tat! Die zweite Anfrage läuft deutlich schneller (23,31 vs. 15,37 Sekunden). Dies liegt daran, dass das Modell die Berechnungen für das zwischengespeicherte Präfix bereits durchgeführt hat und nur den neuen Teil „Was ist Regularisierung?“ von Grund auf verarbeiten muss. Dadurch erzielen wir durch die Verwendung von Immediate-Caching eine deutlich geringere Latenz und geringere Kosten, da zwischengespeicherte Token rabattiert werden.
Eine weitere Sache, die in der OpenAI-Dokumentation erwähnt wird, über die wir bereits gesprochen haben, ist die prompt_cache_key Parameter. Insbesondere können wir laut Dokumentation explizit einen Immediate-Cache-Schlüssel definieren, wenn wir eine Anfrage stellen, und auf diese Weise die Anfragen definieren, die denselben Cache verwenden müssen. Dennoch habe ich versucht, es in mein Beispiel einzubeziehen, indem ich die Anforderungsparameter entsprechend angepasst habe, hatte aber nicht viel Glück:
response1 = shopper.responses.create(
prompt_cache_key = 'prompt_cache_test1',
mannequin="gpt-5.1",
enter=long_prefix + "What's overfitting in machine studying?"
)
🤔
Es scheint eine Weile her zu sein prompt_cache_key in den API-Funktionen vorhanden ist, ist es im Python SDK noch nicht verfügbar. Mit anderen Worten: Wir können die Wiederverwendung des Caches noch nicht explizit steuern, sondern sie erfolgt eher automatisch und nach bestem Wissen und Gewissen.
Was kann additionally schief gehen?
Das Aktivieren des Immediate-Cachings und das tatsächliche Aufrufen des Caches scheint nach dem, was wir bisher gesagt haben, ziemlich einfach zu sein. Was kann additionally schief gehen und dazu führen, dass uns der Cache fehlt? Leider viele Dinge. So einfach es auch ist, erfordert Immediate-Caching viele verschiedene Annahmen. Das Fehlen auch nur einer dieser Voraussetzungen führt zu einem Cache-Fehler. Aber schauen wir genauer hin!
Ein offensichtlicher Fehler besteht darin, dass das Präfix unter dem Schwellenwert für die Aktivierung des Immediate-Caching liegt, nämlich weniger als 1.024 Token. Dies ist jedoch sehr leicht lösbar – wir können die Anzahl der Präfix-Token jederzeit künstlich erhöhen, indem wir einfach mit einem geeigneten Wert multiplizieren, wie im obigen Beispiel gezeigt.
Eine andere Sache wäre, das Präfix stillschweigend zu brechen. Insbesondere müssen wir, selbst wenn wir für alle Anforderungen persistente Anweisungen und Systemaufforderungen angemessener Größe verwenden, äußerst vorsichtig sein, die Präfixe nicht zu zerstören, indem wir zu Beginn der Modelleingabe vor dem Präfix Variableninhalte hinzufügen. Dies ist eine garantierte Möglichkeit, den Cache zu brechen, unabhängig davon, wie lang und wiederholt das folgende Präfix ist. Übliche Verdächtige, die in diese Falle tappen, sind dynamische Daten, beispielsweise das Anhängen der Benutzer-ID oder von Zeitstempeln am Anfang der Eingabeaufforderung. Daher besteht eine bewährte Vorgehensweise bei der gesamten KI-App-Entwicklung darin, dass dynamische Inhalte immer am Ende der Eingabeaufforderung angehängt werden sollten – niemals am Anfang.
Letztendlich ist hervorzuheben, dass es beim Immediate-Caching nur um die Pre-Fill-Section geht – die Dekodierung wird nie zwischengespeichert. Das bedeutet, dass selbst wenn wir dem Modell auferlegen, Antworten nach einer bestimmten Vorlage zu generieren, die mit bestimmten festen Token beginnt, diese Token nicht zwischengespeichert werden und uns ihre Verarbeitung wie gewohnt in Rechnung gestellt wird.
Umgekehrt ist es für bestimmte Anwendungsfälle nicht wirklich sinnvoll, Immediate Caching zu verwenden. In solchen Fällen handelt es sich um hochdynamische Eingabeaufforderungen wie Chatbots mit wenigen Wiederholungen, einmalige Anfragen oder personalisierte Systeme in Echtzeit.
. . .
In meinen Gedanken
Schnelles Caching kann die Leistung von KI-Anwendungen sowohl hinsichtlich der Kosten als auch der Zeit erheblich verbessern. Insbesondere bei der Skalierung von KI-Apps ist Immediate-Caching äußerst praktisch, um Kosten und Latenz auf einem akzeptablen Niveau zu halten.
Für die OpenAI-API ist das Immediate-Caching standardmäßig aktiviert und die Kosten für Eingaben und nicht zwischengespeicherte Token sind dieselben, unabhängig davon, ob wir das Immediate-Caching aktivieren oder nicht. Man kann additionally nur gewinnen, wenn man das Immediate-Caching aktiviert und versucht, es bei jeder Anfrage zu treffen, auch wenn man keinen Erfolg hat.
Claude bietet über seine API auch umfangreiche Funktionen zum Immediate-Caching, die wir in einem zukünftigen Beitrag ausführlich untersuchen werden.
Danke fürs Lesen! 🙂
. . .
Hat Ihnen dieser Beitrag gefallen? Lasst uns Freunde sein! Begleiten Sie mich auf:
📰Unterstapel 💌 Medium 💼LinkedIn ☕Kauf mir einen Kaffee!
Alle Bilder vom Autor, sofern nicht anders angegeben.