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 hereund 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 conceptsDas 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.