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.

wir haben viel darüber gesprochen Was für ein unglaubliches Werkzeug RAG ist um die Leistungsfähigkeit der KI auf benutzerdefinierten Daten zu nutzen. Unabhängig davon, ob es sich um einfache LLM-API-Anfragen, RAG-Anwendungen oder komplexere KI-Agenten handelt, gibt es eine häufig gestellte Frage, die immer dieselbe bleibt. Wie lassen sich all diese Dinge skalieren? Was passiert insbesondere mit den Kosten und der Latenz, wenn die Anzahl der Anfragen in solchen Apps wächst? Insbesondere für fortgeschrittenere KI-Agenten, die kann mehrere Anrufe enthalten B. einem LLM zur Bearbeitung einer einzelnen Benutzeranfrage, kommt diesen Fragen eine besondere Bedeutung zu.

Glücklicherweise werden in der Realität bei Aufrufen eines LLM normalerweise dieselben Eingabetokens über mehrere Anforderungen hinweg wiederholt. Benutzer werden einige spezifische Fragen viel häufiger stellen als andere, Systemaufforderungen und Anweisungen, die in KI-gestützte Anwendungen integriert sind, werden bei jeder Benutzerabfrage wiederholt, und selbst für eine einzelne Eingabeaufforderung führen Modelle rekursive Berechnungen durch, um eine vollständige Antwort zu generieren (erinnern Sie sich, wie LLMs Textual content erzeugen, indem sie Wörter einzeln vorhersagen?). Ähnlich wie bei anderen Anwendungen ist die Verwendung von CacheDas Lösungskonzept kann erheblich dazu beitragen, die Kosten und Latenz von LLM-Anfragen zu optimieren. Beispielsweise laut OpenAI-Dokumentationn, Immediate Caching kann die Latenz um bis zu beeindruckende 80 % und die Eingabe-Token-Kosten um bis zu 90 % reduzieren.

Was ist mit Caching?

Im Allgemeinen, Caching in der Informatik ist keine neue Idee. Im Kern handelt es sich bei einem Cache um eine Komponente, die Daten vorübergehend speichert, damit zukünftige Anfragen nach denselben Daten schneller bearbeitet werden können. Auf diese Weise können wir zwischen zwei grundlegenden Cache-Zuständen unterscheiden – einem Cache-Hit und einem Cache-Miss. Insbesondere:

• Ein Cache-Hit tritt auf, wenn die angeforderten Daten im Cache gefunden werden, was einen schnellen und kostengünstigen Abruf ermöglicht.
• Ein Cache-Fehler tritt auf, wenn sich die Daten nicht im Cache befinden, wodurch die Anwendung gezwungen wird, auf die Originalquelle zuzugreifen, was teurer und zeitaufwändiger ist.

Eine der typischsten Implementierungen des Caches findet sich in Webbrowsern. Wenn Sie eine Web site zum ersten Mal besuchen, prüft der Browser die darin enthaltene URL Cache Speicher, findet aber nichts (das wäre ein Cache-Fehler). Da die gesuchten Daten nicht lokal verfügbar sind, muss der Browser eine teurere und zeitaufwändigere Anfrage über das Web an den Webserver stellen, um die Daten auf dem Distant-Server zu finden, auf dem sie ursprünglich vorhanden waren. Sobald die Seite schließlich geladen ist, kopiert der Browser diese Daten normalerweise in seine lokale Datei Cache. Wenn wir 5 Minuten später versuchen, dieselbe Seite erneut zu laden, sucht der Browser in seinem lokalen Speicher danach. Diesmal wird es gefunden (ein Cache-Treffer) und von dort geladen, ohne auf den Server zurückzugreifen. Dadurch arbeitet der Browser schneller und verbraucht weniger Ressourcen.

Wie Sie sich vorstellen können, ist Caching besonders nützlich in Systemen, in denen dieselben Daten mehrmals angefordert werden. In den meisten Systemen ist der Datenzugriff selten einheitlich, sondern folgt eher einer Verteilung, bei der ein kleiner Teil der Daten die überwiegende Mehrheit der Anfragen ausmacht. Ein großer Teil der realen Anwendungen folgt dem Pareto-Prinzipwas bedeutet, dass etwa 80 % der Anfragen etwa 20 % der Daten ausmachen. Ohne das Pareto-Prinzip müsste der Cache-Speicher so groß sein wie der Primärspeicher des Programs, was ihn sehr, sehr teuer machen würde.

Immediate Caching und ein wenig über LLM-Inferenz

Das Caching-Konzept – häufig verwendete Daten irgendwo zu speichern und von dort abzurufen, anstatt sie erneut von ihrer primären Quelle zu beziehen – wird in ähnlicher Weise zur Verbesserung der Effizienz von LLM-Anrufen genutzt, was eine deutliche Reduzierung von Kosten und Latenz ermöglicht. Caching kann in verschiedenen Elementen verwendet werden, die an einer KI-Anwendung beteiligt sein können. Das wichtigste davon ist Immediate Caching. Dennoch kann Caching auch große Vorteile bieten, wenn es auf andere Aspekte einer KI-App angewendet wird, wie zum Beispiel das Caching beim RAG-Abruf oder das Abfrage-Antwort-Caching. Dennoch konzentriert sich dieser Beitrag ausschließlich auf Immediate Caching.

Um zu verstehen, wie Immediate Caching funktioniert, müssen wir zunächst ein wenig darüber verstehen, wie LLM-Inferenz – die Verwendung eines trainierten LLM zum Generieren von Textual content – funktioniert. Die LLM-Inferenz ist kein einzelner kontinuierlicher Prozess, sondern ist in zwei unterschiedliche Phasen unterteilt. Das sind:

• Vorfüllenwas sich auf die Verarbeitung der gesamten Eingabeaufforderung auf einmal bezieht, um das erste Token zu erzeugen. Diese Part erfordert umfangreiche Berechnungen, und das ist auch der Fall rechengebunden. Wir können uns eine sehr vereinfachte Model dieser Part vorstellen, bei der sich jeder Token um alle anderen Token kümmert, oder so etwas wie den Vergleich jedes Tokens mit jedem vorherigen Token.
• Dekodierungwodurch das zuletzt generierte Token wieder in die Sequenz eingefügt und das nächste automatisch regressiv generiert wird. Diese Part ist Erinnerungsgebundenda das System den gesamten Kontext vorheriger Token aus dem Speicher laden muss, um jedes einzelne neue Token zu generieren.

Stellen Sie sich zum Beispiel vor, wir hätten die folgende Eingabeaufforderung:

What ought to I cook dinner for dinner? 

Daraus können wir dann den ersten Token erhalten:

Right here

und die folgenden Dekodierungsiterationen:

Right here 
Listed here are 
Listed here are 5 
Listed here are 5 straightforward 
Listed here are 5 straightforward dinner 
Listed here are 5 straightforward dinner concepts

Das Drawback dabei ist, dass das Modell zum Generieren der vollständigen Antwort immer wieder dieselben vorherigen Token verarbeiten müsste, um während der Dekodierungsphase jedes nächste Wort zu erzeugen, was, wie Sie sich vorstellen können, äußerst ineffizient ist. In unserem Beispiel bedeutet dies, dass das Modell die Token erneut verarbeiten würde.Was soll ich zum Abendessen kochen? Hier sind 5 einfache‚ zur Erstellung der Ausgabe ‚Ideen‚, auch wenn die Token bereits verarbeitet wurden ‚Was soll ich zum Abendessen kochen? Hier sind 5′ vor ein paar Millisekunden.

Um dies zu lösen, KV-Caching (Schlüsselwert). wird in LLMs verwendet. Dies bedeutet, dass zwischenzeitliche Schlüssel- und Werttensoren für die Eingabeaufforderung und zuvor generierte Token einmal berechnet und dann im KV-Cache gespeichert werden, anstatt sie bei jeder Iteration von Grund auf neu zu berechnen. Dies führt dazu, dass das Modell die minimal erforderlichen Berechnungen für die Erstellung jeder Antwort durchführt. Mit anderen Worten: Das Modell führt für jede Decodierungsiteration nur Berechnungen durch, um das neueste Token vorherzusagen, und hängt es dann an den KV-Cache an.

Allerdings funktioniert das KV-Caching nur für eine einzelne Eingabeaufforderung und zum Generieren einer einzelnen Antwort. Immediate Caching erweitert die beim KV-Caching verwendeten Prinzipien für die Nutzung des Cachings über verschiedene Prompts, Benutzer und Sitzungen hinweg.

In der Praxis speichern wir beim Immediate-Caching die wiederholten Teile eines Prompts nach der ersten Anforderung. Diese wiederholten Teile einer Eingabeaufforderung haben normalerweise die Type von Großformaten Präfixewie Systemaufforderungen, Anweisungen oder abgerufener Kontext. Wenn eine neue Anfrage dasselbe Präfix enthält, verwendet das Modell auf diese Weise die zuvor durchgeführten Berechnungen, anstatt eine Neuberechnung durchzuführen. Dies ist unglaublich praktisch, da es die Betriebskosten einer KI-Anwendung erheblich senken kann (wir müssen nicht für wiederholte Eingaben bezahlen, die dieselben Token enthalten) und auch die Latenz reduzieren (wir müssen nicht darauf warten, dass das Modell bereits verarbeitete Token verarbeitet). Dies ist besonders nützlich bei Anwendungen, bei denen Eingabeaufforderungen umfangreiche wiederholte Anweisungen enthalten, z RAG-Pipelines.

Es ist wichtig zu verstehen, dass dieses Caching funktioniert auf Token-Ebene. In der Praxis bedeutet dies, dass selbst wenn sich zwei Eingabeaufforderungen am Ende unterscheiden, die zwischengespeicherten Berechnungen für diesen gemeinsam genutzten Teil immer noch wiederverwendet werden können und nur neue Berechnungen für die unterschiedlichen Token durchgeführt werden, solange sie dasselbe Token-Präfix verwenden. Der schwierige Teil besteht darin, dass die gemeinsamen Token am Anfang der Eingabeaufforderung stehen müssen. Daher ist die Artwork und Weise, wie wir unsere Eingabeaufforderungen und Anweisungen bilden, von besonderer Bedeutung. In unserem Kochbeispiel können wir uns folgende aufeinanderfolgende Aufforderungen vorstellen.

Immediate 1
What ought to I cook dinner for dinner? 

und wenn wir dann die Eingabeaufforderung eingeben:

Immediate 2
What ought to I cook dinner for launch? 

Die geteilten Token ‚Was soll ich kochen? sollte ein Cache-Treffer sein, und daher sollte man damit rechnen, dass für Immediate 2 deutlich weniger Token verbraucht werden.

Wenn wir jedoch die folgenden Aufforderungen hätten …

Immediate 1
Meal time! What ought to I cook dinner? 

und dann

Immediate 2
Launch time! What ought to I cook dinner? 

Dies wäre ein Cache-Fehler, da das erste Token jeder Eingabeaufforderung unterschiedlich ist. Da die Eingabeaufforderungspräfixe unterschiedlich sind, können wir nicht auf den Cache zugreifen, selbst wenn ihre Semantik im Wesentlichen gleich ist.

Daher besteht eine grundlegende Faustregel für die Funktion des Immediate-Caching darin, immer alle statischen Informationen, wie Anweisungen oder Systemaufforderungen, am Anfang der Modelleingabe anzuhängen. Auf der anderen Seite sollten alle typischerweise variablen Informationen wie Zeitstempel oder Benutzeridentifikationen am Ende der Eingabeaufforderung stehen.

Mit der OpenAI-API machen wir uns die Hände schmutzig

Heutzutage sind die meisten Frontier-Stiftungsmodelle wie GPT oder Claudebieten eine Artwork Immediate-Caching-Funktionalität, die direkt in ihre APIs integriert ist. Genauer gesagt wird Immediate Caching in den genannten APIs von allen Benutzern einer Organisation gemeinsam genutzt, die auf denselben API-Schlüssel zugreifen. Mit anderen Worten: Sobald ein Benutzer eine Anfrage stellt und sein Präfix im Cache gespeichert wird, erhalten wir für jeden anderen Benutzer, der eine Eingabeaufforderung mit demselben Präfix eingibt, einen Cache-Treffer. Das heißt, wir können vorab berechnete Berechnungen verwenden, die den Token-Verbrauch erheblich reduzieren und die Antwortgenerierung beschleunigen. Dies ist besonders nützlich bei der Bereitstellung von KI-Anwendungen im Unternehmen, wo wir davon ausgehen, dass viele Benutzer dieselbe Anwendung und damit dieselben Eingabepräfixe verwenden.

Bei den neuesten Modellen ist Immediate Caching standardmäßig automatisch aktiviert, es ist jedoch ein gewisser Grad an Parametrisierung verfügbar. Wir können unterscheiden zwischen:

• Im Speicher sofortige Cache-Aufbewahrung, bei der die zwischengespeicherten Präfixe etwa 5–10 Minuten und bis zu 1 Stunde lang beibehalten werden, und
• Erweitert Sofortige Cache-Aufbewahrung (nur für bestimmte Modelle verfügbar), was eine längere Aufbewahrung des zwischengespeicherten Präfixes von bis zu maximal 24 Stunden ermöglicht.

Aber schauen wir genauer hin!

All dies können wir anhand des folgenden minimalen Python-Beispiels in der Praxis sehen, indem wir Anfragen an die OpenAI-API stellen, Immediate Caching verwenden und die zuvor erwähnten Kochaufforderungen verwenden. Ich habe meinen Eingabeaufforderungen ein ziemlich großes gemeinsames Präfix hinzugefügt, um die Auswirkungen des Cachings besser sichtbar zu machen:

from openai import OpenAI
api_key = "your_api_key"
consumer = OpenAI(api_key=api_key)

prefix = """
You're a useful cooking assistant.

Your activity is to recommend easy, sensible dinner concepts for busy individuals.
Observe these tips fastidiously when producing ideas:

Normal cooking guidelines:
- Meals ought to take lower than half-hour to organize.
- Substances ought to be straightforward to search out in a daily grocery store.
- Recipes ought to keep away from overly complicated methods.
- Want balanced meals together with greens, protein, and carbohydrates.

Formatting guidelines:
- At all times return a numbered record.
- Present 5 ideas.
- Every suggestion ought to embody a brief rationalization.

Ingredient tips:
- Want seasonal greens.
- Keep away from unique components.
- Assume the person has fundamental pantry staples comparable to olive oil, salt, pepper, garlic, onions, and pasta.

Cooking philosophy:
- Favor easy dwelling cooking.
- Keep away from restaurant-level complexity.
- Deal with meals that individuals realistically cook dinner on weeknights.

Instance meal kinds:
- pasta dishes
- rice bowls
- stir fry
- roasted greens with protein
- easy soups
- wraps and sandwiches
- sheet pan meals

Food regimen issues:
- Default to wholesome meals.
- Keep away from deep frying.
- Want balanced macronutrients.

Extra directions:
- Hold explanations concise.
- Keep away from repeating the identical components in each suggestion.
- Present selection throughout the meal ideas.

""" * 80   
# large prefix to verify i get the 1000 one thing token threshold for activating immediate caching

prompt1 = prefix + "What ought to I cook dinner for dinner?"

und dann für die Eingabeaufforderung 2

prompt2 = prefix + "What ought to I cook dinner for lunch?"

response2 = consumer.responses.create(
    mannequin="gpt-5.2",
    enter=prompt2
)

print("nResponse 2:")
print(response2.output_text)

print("nUsage stats:")
print(response2.utilization)

Für Eingabeaufforderung 2 würde uns additionally nur der verbleibende, nicht identische Teil der Eingabeaufforderung in Rechnung gestellt. Das wären die Eingabe-Tokens abzüglich der zwischengespeicherten Tokens: 20.014 – 19.840 = nur 174 Tokens, additionally 99 % weniger Tokens.

Da OpenAI einen Mindestschwellenwert von 1.024 Token für die Aktivierung des Immediate-Caching vorschreibt und der Cache maximal 24 Stunden lang aufbewahrt werden kann, wird auf jeden Fall klar, dass diese Kostenvorteile in der Praxis nur dann erzielt werden können, wenn KI-Anwendungen in großem Maßstab ausgeführt werden und viele aktive Benutzer täglich viele Anfragen ausführen. Dennoch kann die Immediate-Caching-Funktion, wie für solche Fälle erläutert, erhebliche Kosten- und Zeitvorteile für LLM-basierte Anwendungen bieten.

In meinen Gedanken

Immediate Caching ist eine leistungsstarke Optimierung für LLMs, die die Effizienz von KI-Anwendungen sowohl hinsichtlich der Kosten als auch der Zeit erheblich verbessern kann. Durch die Wiederverwendung früherer Berechnungen für identische Eingabeaufforderungspräfixe kann das Modell redundante Berechnungen überspringen und die wiederholte Verarbeitung derselben Eingabetoken vermeiden. Das Ergebnis sind schnellere Antworten und niedrigere Kosten, insbesondere bei Anwendungen, bei denen große Teile der Eingabeaufforderungen – wie Systemanweisungen oder abgerufener Kontext – über viele Anfragen hinweg konstant bleiben. Da KI-Systeme skalieren und die Anzahl der LLM-Aufrufe zunimmt, werden diese Optimierungen immer wichtiger.

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.

Wenn Sie LangGraph lernen oder mehr darüber erfahren, ist es hilfreich, etwas über das vorgefertigte Caching auf Knotenebene in LangGraph zu wissen. Caching eliminiert nicht nur unnötige Berechnungen, sondern verkürzt auch die Latenz. Wir werden uns in diesem Artikel mit der Umsetzung befassen. Es wird davon ausgegangen, dass Sie eine Vorstellung von Agenten und Knoten in LangGraph haben, da wir uns nicht auf diesen Teil der Geschichte konzentrieren werden. Lassen Sie uns additionally ohne weitere Umschweife auf die Konzepte und die Implementierung eingehen.

Was ist Caching?

Beim Caching werden Daten im temporären Speicher gespeichert, damit das System sie schnell abrufen kann. Im Rahmen von LLMs Und KI-Agentenspeichert es frühere Anfragen und verwendet sie wieder, wenn dieselben Eingabeaufforderungen an das Modell oder den Agenten gesendet werden. Da es sich nicht um eine neue Anfrage handelt, erhebt das System keine Gebühren dafür und die Antwort kommt aufgrund des temporären Speichers schneller an. Wenn ein Teil einer Eingabeaufforderung gleich bleibt, verwendet das System die vorherige Antwort wieder und generiert nur für den zusätzlichen Teil eine neue, was die Kosten auch für neue Anfragen erheblich senkt.

Caching-Parameter und Speicher

Es ist wichtig, den TTL-Parameter (Time to Dwell) zu kennen, der verwendet wird, um die Zeitspanne (in Sekunden) zu definieren, die der Cache im Speicher verbleibt. Wenn wir einstellen ttl=Keine oder lassen Sie es so wie es ist, dann wird der Cache den Speicher nie verlassen.

Beim Kompilieren eines Diagramms müssen wir einen Cache angeben. Wir verwenden InMemoryCache, um die Eingaben und Ausgaben des Knotens zu speichern, die später zum Abrufen der vorherigen Antwort des Knotens in diesem Artikel verwendet werden können. Alternativ können Sie je nach Bedarf auch SqliteCache, redisCache oder benutzerdefinierten Cache implementieren.

Caching in Aktion

Lassen Sie uns umsetzen Caching auf Knotenebene für eine Funktion, die dabei hilft, Celsius in Fahrenheit umzurechnen.

Installationen

!pip set up langgraph 

Definieren des Diagramms

Wir definieren zunächst die Diagrammstruktur und eine einfache Funktion, die eine langsame Berechnung simuliert time.sleep() um den Caching-Effekt sichtbar zu machen.

import time 

from typing_extensions import TypedDict 

from langgraph.graph import StateGraph 

from langgraph.cache.reminiscence import InMemoryCache 

from langgraph.varieties import CachePolicy 

class State(TypedDict): 

   celsius: float 

   fahrenheit: float 

builder = StateGraph(State) 

def convert_temperature(state: State) -> dict(str, float): 

   time.sleep(2) 

   fahrenheit = (state('celsius') * 9/5) + 32 

   return {"fahrenheit": fahrenheit} 

builder.add_node("convert_temperature", convert_temperature, cache_policy=CachePolicy(ttl=None)) 

builder.set_entry_point("convert_temperature") 

builder.set_finish_point("convert_temperature") 

cache=InMemoryCache() 

graph = builder.compile(cache=cache)

Aufrufen des Diagramms

Rufen wir nun das Diagramm mehrmals auf und beobachten, wie sich der Cache verhält.

print(graph.invoke({"celsius": 25})) 

print(graph.invoke({"celsius": 25}, stream_mode="updates"))  # Cached 

print(graph.invoke({"celsius": 36}, stream_mode="updates"))  

time.sleep(10) 

print(graph.invoke({"celsius": 36}, stream_mode="updates"))  

cache.clear() # clears the complete cache

Ausgabe:

{'celsius': 25, 'fahrenheit': 77.0} 
({'convert_temperature': {'fahrenheit': 77.0}, '__metadata__': {'cached': True}}) 
({'convert_temperature': {'fahrenheit': 96.8}}) 
({'convert_temperature': {'fahrenheit': 96.8}})

Das System ruft die Antwort bei der ersten wiederholten Anfrage aus dem Cache ab und die TTL ist auf 5 Sekunden eingestellt. Es behandelt die nächste wiederholte Anfrage als eine neue, wenn die Lücke die TTL überschreitet. Wir haben verwendet cache.clear() Um den gesamten Cache zu leeren, ist dies beim Festlegen nützlich ttl=Keine.

Jetzt implementieren wir das Caching für den Knoten mit einem Agenten.

Voraussetzungen

Wir benötigen einen Gemini-API-Schlüssel, um Gemini-Modelle im Agenten verwenden zu können Google AI Studio So erhalten Sie Ihren API-Schlüssel: https://aistudio.google.com/api-keys

Installationen

Der langchain_google_genai Das Modul wird uns bei der Integration helfen Zwillinge Modelle im Knoten.

!pip set up langgraph langchain_google_genai 

Agentendefinition

Definieren wir einen einfachen Mathematikagenten, der Zugriff auf das Taschenrechnertool hat, und legen den fest ttl=Keine zur Zeit.

from langgraph.prebuilt import create_react_agent 

from langchain_google_genai import ChatGoogleGenerativeAI 

def solve_math_problem(expression: str) -> str: 

   """Resolve a math drawback.""" 

   strive: 

       # Consider the mathematical expression 

       outcome = eval(expression, {"__builtins__": {}}) 

       return f"The reply is {outcome}." 

   besides Exception: 

       return "I could not remedy that expression." 

# Initialize the Gemini mannequin with API key 

mannequin = ChatGoogleGenerativeAI( 

   mannequin="gemini-2.5-flash", 

   google_api_key=GOOGLE_API_KEY 

) 

# Create the agent 

agent = create_react_agent( 

   mannequin=mannequin, 

   instruments=(solve_math_problem), 

   immediate=( 

       "You're a Math Tutor AI. " 

       "When a consumer asks a math query, cause via the steps clearly " 

       "and use the device `solve_math_problem` for numeric calculations. " 

       "All the time clarify your reasoning earlier than giving the ultimate reply." 

   ), 

)

Definieren des Knotens

Als Nächstes packen wir den Agenten in einen LangGraph-Knoten und fügen ihm Caching hinzu.

import time 

from typing_extensions import TypedDict 

from langgraph.graph import StateGraph 

from langgraph.cache.reminiscence import InMemoryCache 

from langgraph.varieties import CachePolicy 

class AgentState(TypedDict): 

   immediate: str 

   response: str 

builder = StateGraph(AgentState) 

def run_agent(state: AgentState) -> AgentState: 

   print("Working agent...")  # this line helps present caching habits 

   response = agent.invoke({"messages": ({"function": "consumer", "content material": state("immediate")})}) 

   return {"response": response} 

builder.add_node("run_agent", run_agent, cache_policy=CachePolicy(ttl=None)) 

builder.set_entry_point("run_agent") 

builder.set_finish_point("run_agent") 

graph = builder.compile(cache=InMemoryCache())

Aufruf des Agenten

Rufen wir abschließend den Agenten zweimal an, um das Caching in Aktion zu sehen.

# Invoke graph twice to see caching 

print("First name") 

result1 = graph.invoke({"immediate": "What's (12 + 8) * 3?"},stream_mode="updates") 

print(result1) 

print("Second name (needs to be cached)") 

result2 = graph.invoke({"immediate": "What's (12 + 8) * 3?"},stream_mode="updates") 

print(result2)

Ausgabe:

Beachten Sie, dass der zweite Aufruf nicht „Laufender Agent..‚, was eine Druckanweisung im Knoten ist. So ist es uns gelungen, die Antwort vom Agenten zu erhalten, ohne den Agenten über den Cache-Speicher auszuführen.

Abschluss

LangGraphDas integrierte Caching auf Knotenebene bietet eine einfache, aber leistungsstarke Möglichkeit, Latenz und Berechnungen durch Wiederverwendung früherer Ergebnisse zu reduzieren. Mit Parametern wie TTL zur Verwaltung der Cache-Lebensdauer und Optionen wie InMemoryCache, SqliteCache oder RedisCache bietet es Flexibilität je nach Anwendungsfall. Anhand von Beispielen wie der Temperaturkonvertierung zu agentenbasierten Knoten! Wir haben gesehen, wie Caching redundante Ausführung vermeidet und Kosten spart. Insgesamt verbessert das Caching in LangGraph die Effizienz erheblich und macht Arbeitsabläufe schneller und optimierter.

Häufig gestellte Fragen

Leidenschaftlich für Technologie und Innovation, Absolvent des Vellore Institute of Know-how. Derzeit arbeite ich als Information Science Trainee mit Schwerpunkt auf Information Science. Großes Interesse an Deep Studying und generativer KI, begierig darauf, modernste Techniken zu erforschen, um komplexe Probleme zu lösen und wirkungsvolle Lösungen zu schaffen.

Bild vom Autor

In Python können Sie Caching verwenden, um die Ergebnisse aufwändiger Funktionsaufrufe zu speichern und sie wiederzuverwenden, wenn die Funktion erneut mit denselben Argumenten aufgerufen wird. Dadurch wird Ihr Code leistungsfähiger.

Python bietet integrierte Unterstützung für das Caching durch die functools Modul: die Dekorateure @cache Und @lru_cache. Und wir werden in diesem Tutorial lernen, wie man Funktionsaufrufe zwischenspeichert.

Warum ist Caching hilfreich?

Das Zwischenspeichern von Funktionsaufrufen kann die Leistung Ihres Codes erheblich verbessern. Hier sind einige Gründe, warum das Zwischenspeichern von Funktionsaufrufen von Vorteil sein kann:

• Leistungsverbesserung: Wenn eine Funktion mehrmals mit denselben Argumenten aufgerufen wird, kann das Zwischenspeichern des Ergebnisses redundante Berechnungen vermeiden. Anstatt das Ergebnis jedes Mal neu zu berechnen, kann der zwischengespeicherte Wert zurückgegeben werden, was zu einer schnelleren Ausführung führt.
• Reduzierung des Ressourcenverbrauchs: Einige Funktionsaufrufe können rechenintensiv sein oder erhebliche Ressourcen erfordern (z. B. Datenbankabfragen oder Netzwerkanforderungen). Durch das Zwischenspeichern der Ergebnisse müssen diese Vorgänge nicht so oft wiederholt werden.
• Verbesserte Reaktionsfähigkeit: Bei Anwendungen, bei denen die Reaktionsfähigkeit von entscheidender Bedeutung ist, wie etwa Webservern oder GUI-Anwendungen, kann das Caching zur Reduzierung der Latenz beitragen, indem wiederholte Berechnungen oder E/A-Vorgänge vermieden werden.

Kommen wir nun zum Codieren.

Caching mit dem @cache Decorator

Lassen Sie uns eine Funktion codieren, die die n-te Fibonacci-Zahl berechnet. Hier ist die rekursive Implementierung der Fibonacci-Folge:

def fibonacci(n):
    if n <= 1:
        return n
    return fibonacci(n-1) + fibonacci(n-2)

Ohne Zwischenspeicherung führen die rekursiven Aufrufe zu redundanten Berechnungen. Wenn die Werte zwischengespeichert werden, wäre es viel effizienter, die zwischengespeicherten Werte nachzuschlagen. Und dafür können Sie den @cache Dekorateur.

Der @cache Dekorateur aus dem functools Das Modul in Python 3.9+ wird verwendet, um die Ergebnisse einer Funktion zwischenzuspeichern. Es funktioniert, indem es die Ergebnisse teurer Funktionsaufrufe speichert und sie wiederverwendet, wenn die Funktion mit denselben Argumenten aufgerufen wird. Lassen Sie uns nun die Funktion mit dem @cache Dekorateur:

from functools import cache

@cache
def fibonacci(n):
    if n <= 1:
        return n
    return fibonacci(n-1) + fibonacci(n-2)

Wir werden später auf den Leistungsvergleich eingehen. Sehen wir uns nun eine andere Möglichkeit an, Rückgabewerte von Funktionen mit dem @lru_cache Dekorateur.

Zwischenspeichern mit dem @lru_cache Decorator

Sie können die integrierte functools.lru_cache Dekorator auch für das Caching. Dies verwendet den Least Just lately Used (LRU)-Caching-Mechanismus für Funktionsaufrufe. Wenn beim LRU-Caching der Cache voll ist und ein neues Ingredient hinzugefügt werden muss, wird das am wenigsten zuletzt verwendete Ingredient im Cache entfernt, um Platz für das neue Ingredient zu schaffen. Dadurch wird sichergestellt, dass die am häufigsten verwendeten Elemente im Cache erhalten bleiben, während weniger häufig verwendete Elemente verworfen werden.

Der @lru_cache Dekorateur ist ähnlich wie @cache Sie können jedoch die maximale Größe festlegen, da die maxsize Argument – ​​des Caches. Sobald der Cache diese Größe erreicht, werden die zuletzt verwendeten Elemente verworfen. Dies ist nützlich, wenn Sie die Speichernutzung begrenzen möchten.

Hier das fibonacci Die Funktion speichert bis zu 7 zuletzt berechnete Werte im Cache:

from functools import lru_cache

@lru_cache(maxsize=7)  # Cache as much as 7 most up-to-date outcomes
def fibonacci(n):
    if n <= 1:
        return n
    return fibonacci(n-1) + fibonacci(n-2)

fibonacci(5)  # Computes Fibonacci(5) and caches intermediate outcomes
fibonacci(3)  # Retrieves Fibonacci(3) from the cache

Hier das fibonacci Funktion ist dekoriert mit @lru_cache(maxsize=7)und geben Sie an, dass bis zu 7 aktuelle Ergebnisse zwischengespeichert werden sollen.

Wann fibonacci(5) heißt, die Ergebnisse für fibonacci(4), fibonacci(3)Und fibonacci(2) werden zwischengespeichert. Wenn fibonacci(3) wird anschließend aufgerufen, fibonacci(3) wird aus dem Cache abgerufen, da es sich um einen der sieben zuletzt berechneten Werte handelte, wodurch redundante Berechnungen vermieden werden.

Timing von Funktionsaufrufen zum Vergleich

Vergleichen wir nun die Ausführungszeiten der Funktionen mit und ohne Caching. Für dieses Beispiel setzen wir keinen expliziten Wert für maxsize. Additionally maxsize wird auf den Standardwert 128 gesetzt:

from functools import cache, lru_cache
import timeit

# with out caching
def fibonacci_no_cache(n):
    if n <= 1:
        return n
    return fibonacci_no_cache(n-1) + fibonacci_no_cache(n-2)

# with cache
@cache
def fibonacci_cache(n):
    if n <= 1:
        return n
    return fibonacci_cache(n-1) + fibonacci_cache(n-2)

# with LRU cache
@lru_cache
def fibonacci_lru_cache(n):
    if n <= 1:
        return n
    return fibonacci_lru_cache(n-1) + fibonacci_lru_cache(n-2)

Um die Ausführungszeiten zu vergleichen, verwenden wir die timeit„ Funktion aus dem timeit Modul:

# Compute the n-th Fibonacci quantity
n = 35  

no_cache_time = timeit.timeit(lambda: fibonacci_no_cache(n), quantity=1)
cache_time = timeit.timeit(lambda: fibonacci_cache(n), quantity=1)
lru_cache_time = timeit.timeit(lambda: fibonacci_lru_cache(n), quantity=1)

print(f"Time with out cache: {no_cache_time:.6f} seconds")
print(f"Time with cache: {cache_time:.6f} seconds")
print(f"Time with LRU cache: {lru_cache_time:.6f} seconds")

Die Ausführung des obigen Codes sollte zu einer ähnlichen Ausgabe führen:

Output >>>
Time with out cache: 2.373220 seconds
Time with cache: 0.000029 seconds
Time with LRU cache: 0.000017 seconds

Wir sehen einen deutlichen Unterschied in den Ausführungszeiten. Der Funktionsaufruf ohne Zwischenspeicherung dauert viel länger, insbesondere bei größeren Werten von n. Während die zwischengespeicherten Versionen (beide @cache Und @lru_cache) werden viel schneller ausgeführt und haben vergleichbare Ausführungszeiten.

Einpacken

Mithilfe der @cache Und @lru_cache Dekoratoren können Sie die Ausführung von Funktionen, die teure Berechnungen oder rekursive Aufrufe beinhalten, erheblich beschleunigen. Den vollständigen Code finden Sie auf GitHub.

Wenn Sie nach einem umfassenden Leitfaden zu Finest Practices für die Verwendung von Python für Knowledge Science suchen, lesen Sie 5 Python Finest Practices für Knowledge Science.

Bala Priya C ist Entwicklerin und technische Redakteurin aus Indien. Sie arbeitet gerne an der Schnittstelle zwischen Mathematik, Programmierung, Datenwissenschaft und Inhaltserstellung. Ihre Interessens- und Fachgebiete umfassen DevOps, Datenwissenschaft und natürliche Sprachverarbeitung. Sie liest, schreibt, programmiert und trinkt gerne Kaffee! Derzeit arbeitet sie daran, ihr Wissen zu lernen und mit der Entwickler-Group zu teilen, indem sie Tutorials, Anleitungen, Meinungsbeiträge und mehr verfasst. Bala erstellt auch ansprechende Ressourcenübersichten und Programmier-Tutorials.