LLM Caching: Wann semantische Caches die richtige Antwort liefern

LLM Caching mit semantischem Abgleich kann wiederholte Modellaufrufe vermeiden – sofern unterschiedlich formulierte Anfragen dieselbe Antwort erhalten dürfen. Der Ablauf umfasst 4 Schritte: den Prompt in ein Embedding umwandeln, benachbarte Einträge suchen, einen Schwellenwert anwenden und dann entweder eine gespeicherte Antwort zurückgeben oder das Modell aufrufen. Schwierig ist die Entscheidung, wann ein ähnlicher Treffer trotzdem die falsche Antwort liefert.

Ein guter Einstieg sind ein Hilfecenter mit beständigen Inhalten oder öffentliche Produkt-FAQs. Ein großes Sprachmodell (LLM), das die Antwort erzeugt, sollte dieselbe veröffentlichte Richtlinie nicht bei jeder neuen Formulierung erneut erklären müssen. Kontostände, Bestellstatus und Aktionen wie das Auslösen einer Erstattung gehören dagegen nicht in diesen gemeinsam genutzten Cache.

Die folgenden Implementierungsdetails wurden am 21. Oktober 2026 anhand der Originaldokumentation geprüft. Das durchgerechnete Shopbeispiel ist fiktiv; seine Ähnlichkeitswerte veranschaulichen eine Entscheidung und sind keine gemessenen Embedding-Ergebnisse.

LLM Caching: Semantischer Cache, exakter Cache und Prompt Caching

Ein semantischer Cache verwendet eine frühere Antwort erneut, wenn eine neue Anfrage offenbar dasselbe meint. Das lässt sich mit einem Supportmitarbeiter vergleichen, der eine freigegebene Antwort aus dem Aktenschrank holt: Unterschiedliche Formulierungen können zur selben Akte führen. Trotzdem muss er prüfen, für welche Richtlinie und welchen Kunden die Antwort gilt.

Ein Embedding ist eine numerische Darstellung von Text, mit der sich Bedeutungen vergleichen lassen. Der Cache speichert das Embedding eines früheren Prompts zusammen mit der Antwort und dem zugehörigen Kontext. Aus einem neuen Prompt entsteht ein weiteres Embedding; eine Vektorsuche sucht dazu benachbarte Einträge. Microsoft beschreibt in seiner Dokumentation zum semantischen Cache dieses Prinzip der Antwortwiederverwendung und die Bedeutung des Gesprächskontexts.

Die einzelnen Cache-Ebenen sparen unterschiedliche Arbeit ein:

Beim exakten Antwortcache haben „Kann ich diese Kopfhörer zurückgeben?“ und „Sind diese Kopfhörer rückgabefähig?“ normalerweise unterschiedliche Schlüssel. Semantisches Caching kann diese Umformulierungen zusammenführen. Keines der beiden Verfahren macht eine veraltete Antwort oder eine Antwort aus dem falschen Geltungsbereich unbedenklich.

Prompt Caching beim Anbieter ruft keine alte Antwort ab, nur weil eine Frage ähnlich klingt. Anthropics Dokumentation zu Prompt Caching beschreibt die Wiederverwendung übereinstimmender Prompt-Präfixe und grenzt sie ausdrücklich von der Ausgabeerzeugung ab. Die Anwendung fordert das Modell weiterhin auf, eine Antwort zu erzeugen. Der Erklärartikel zum KV-Cache erläutert den modellinternen Zustand hinter dieser Unterscheidung.

Die Ebenen lassen sich kombinieren: Zuerst wird der exakte Antwortcache geprüft, dann der semantische Antwortcache. Erst danach folgt der Modellaufruf, soweit verfügbar mit Prompt Caching beim Anbieter. Der Nutzen des semantischen Cachings sollte an diesem bereits optimierten Ausgangszustand gemessen werden.

Semantisches Caching für LLM-Antworten in vier Schritten

Die Suche soll eine wiederverwendbare Antwort innerhalb eines zulässigen Kontexts finden. Dieser Kontext muss vor der Suche feststehen: der authentifizierte Nutzer oder Mandant, die geltende Richtlinie, die Sprache und alle weiteren Umstände, die den zulässigen Inhalt der Antwort beeinflussen.

1. 1

   1. Den Prompt in ein Embedding umwandeln

   Die eingehende Frage wird mit demselben Embedding-Modell und einer kompatiblen Konfiguration wie bei den gespeicherten Einträgen in ein Embedding umgewandelt. Der zur Interpretation nötige Gesprächskontext muss einfließen. Alternativ wird das Caching auf eigenständig verständliche Fragen begrenzt.

   „Und was ist mit meiner?“ ist kein vollständiger Cache-Schlüssel. Wenn sich „meiner“ nur mithilfe privater Bestelldaten auflösen lässt, muss die Anfrage den gemeinsam genutzten Antwortcache umgehen.

2. 2

   2. Benachbarte Einträge suchen

   Innerhalb des zulässigen Geltungsbereichs werden die gespeicherten Prompt-Embeddings nach nahe gelegenen Kandidaten durchsucht. Zu jedem Kandidaten werden die Antwort und die Metadaten abgerufen, also die Felder zu Eigentümer, Quellversion und Ablaufzeit.

   Der nächste Nachbar ist lediglich der nächstgelegene gefundene Eintrag. Er kann dennoch irrelevant sein. Etwas zu finden bedeutet noch nicht, einen verwertbaren Treffer zu haben.

3. 3

   3. Schwellenwert und Wiederverwendbarkeit prüfen

   Die Ähnlichkeit oder Distanz des Kandidaten wird mit dem kalibrierten Grenzwert verglichen. Anschließend müssen alle Felder exakt übereinstimmen, die die Antwort verändern können, etwa Produktzustand, Richtlinienversion und Zugriffsbereich.

   Besteht der Wert die Prüfung, der Kontext aber nicht, liegt ein Cache-Miss vor. Dasselbe gilt, wenn sich der erforderliche Kontext nicht zuverlässig feststellen lässt.

4. 4

   4. Die Antwort zurückgeben oder das Modell aufrufen

   Bei einem akzeptierten Treffer wird die gespeicherte Antwort ohne erneuten Generierungsaufruf zurückgegeben. Bei einem Cache-Miss läuft der normale Modell- oder Abrufprozess. Sein Ergebnis wird ausgegeben und nur dann gespeichert, wenn es die Aufnahmeregeln des Caches erfüllt.

   Nicht jede Modellausgabe darf automatisch zur wiederverwendbaren Antwort werden. Fehler, persönliche Angaben und Antworten, die an flüchtige Tool-Ergebnisse gebunden sind, können ungeeignet sein.

Der entscheidende Unterschied zur semantischen Suche liegt im Schritt nach dem Abruf. Eine Suche liefert relevantes Material. Ein Antwortcache kann dagegen eine frühere Antwort unmittelbar als Antwort auf die aktuelle Anfrage ausgeben. Eine falsche Zuordnung hat dadurch größere Folgen.

Ein gültiger Treffer und ein ähnlicher Fall, der keiner sein darf

Eine einzige geänderte Bedingung kann einen ansonsten überzeugenden Treffer unbrauchbar machen. Nehmen wir einen fiktiven Shop, dessen Richtlinie die Rückgabe ungeöffneter Kopfhörer erlaubt und geöffnete Kopfhörer ausschließt. Das sind Beispieldaten zur Erklärung, keine Aussage über die Richtlinie eines Händlers.

Im Cache liegen folgende Daten:

• Gespeicherte Frage: „Kann ich ungeöffnete Kopfhörer zurückgeben?“
• Gespeicherte Antwort: „Ja. Ungeöffnete Kopfhörer können nach der Rückgaberichtlinie dieses Shops zurückgegeben werden.“
• Gespeicherter Kontext: die aktuelle Richtlinienversion des Shops, die Kategorie Kopfhörer, Englisch und condition=unopened.

Nur für dieses Beispiel nehmen wir eine minimale Kosinusähnlichkeit von 0.90 an. Die Kosinusähnlichkeit vergleicht die Richtung von Vektoren; sie gibt nicht die Wahrscheinlichkeit an, dass eine Antwort richtig ist. Die folgenden Werte sind erfunden, um die Entscheidung zu verdeutlichen.

Beide Kandidaten überschreiten den numerischen Schwellenwert. Nur die Umformulierung darf die Antwort wiederverwenden. Die ähnliche, aber unzulässige Anfrage teilt Produkt, Handlung und einen Großteil der Formulierung mit dem gespeicherten Eintrag. Sie verändert jedoch genau den Umstand, der über die Antwort entscheidet.

Die Anwendung sollte den Zustand als strukturiertes Feld mitführen, sobald er bekannt ist. Muss sie ihn erst aus dem Text extrahieren, sollte eine unsichere Erkennung zum normalen Antwortprozess führen. Ein weiterer Embedding-Vergleich ersetzt nicht das Wissen darüber, ob der Artikel geöffnet wurde.

Welche Einstellungen über eine sichere Wiederverwendung entscheiden

Schwellenwert, Gültigkeitsdauer und Geltungsbereich wirken zusammen. Wer nur den Schwellenwert abstimmt, lässt den Cache anfällig für vollkommen ähnliche Anfragen, die unterschiedliche Antworten brauchen.

Ähnlichkeitsschwellenwert: An falschen Antworten kalibrieren

Ein strengerer Grenzwert verzichtet auf einige nützliche Treffer, um weniger falsche Zuordnungen zuzulassen. Ein großzügigerer Grenzwert erhöht die Wiederverwendung und kann zugleich mehr falsche Wiederverwendungen verursachen. Aus dem eigenen Anfrageaufkommen sollte ein gekennzeichneter Datensatz entstehen: mit Umformulierungen und schwer unterscheidbaren Negativbeispielen, also ähnlichen Fragen, deren Antworten verschieden sein müssen.

Dazu gehören veränderte Daten, Produktvarianten, Verneinungen, Währungen, Kontorollen und Gesprächsverläufe. Entscheidend ist, ob die gespeicherte Antwort für die neue Anfrage gilt – nicht bloß, ob die Prompts dasselbe Thema behandeln.

Vor jeder Anpassung muss klar sein, was die Metrik misst. Die Redis Vector Library (RedisVL), eine Bibliothek für Anwendungen mit der Redis-Vektorsuche, dokumentiert distance_threshold in Redis-COSINE-Distanzeinheiten von 0 bis 2. Niedrigere Werte bedeuten dort eine strengere Zuordnung. Bei einem Mindestwert für Ähnlichkeit ist die Richtung üblicherweise umgekehrt. RedisVL-API-Referenz.

Es gibt keinen universellen Grenzwert, der sich zwischen Embedding-Modellen, Datensätzen oder Produkten übertragen lässt. Auch ein Wechsel des Embedding-Modells erfordert eine geplante Indexmigration und eine neue Kalibrierung. Alte und neue Vektoren sollten nicht unbedacht vermischt werden.

Gültigkeitsdauer: Das Ablaufdatum ist nur eine Absicherung

Time to live (TTL) bezeichnet die Zeitspanne, in der ein Eintrag vor seinem Ablauf noch verwendet werden darf. Maßgeblich ist, wie lange eine alte Antwort vertretbar bleibt – nicht, wie lange der Cache sie speichern könnte.

Eine Antwort aus beständiger Dokumentation hat andere Aktualitätsanforderungen als eine Auskunft zum aktuellen Lagerbestand. Letztere sollte womöglich gar nicht gecacht werden. Eine dringende Korrektur der Richtlinie muss betroffene Einträge sofort ungültig machen, auch wenn ihre TTL noch nicht abgelaufen ist.

Die Quell- oder Richtlinienversion sollte Teil der Prüfung auf Wiederverwendbarkeit sein. Ändert sich die Version, passen alte Einträge nicht mehr. RedisVL bietet sowohl eine Standard-TTL als auch abweichende Werte je Eintrag. Die passende Gültigkeitsdauer muss jedoch die Anwendung festlegen. RedisVL-Cache-API.

Nutzerbezogener Geltungsbereich: Identität verlangt eine exakte Grenze

Ein gemeinsam genutzter Cache eignet sich nur für Antworten, die auch zur gemeinsamen Nutzung bestimmt sind. Ein Mandant ist eine Kundenorganisation. Die Mandantengrenze allein genügt nicht, wenn Beschäftigte innerhalb dieser Organisation unterschiedliche Zugriffsrechte haben.

Eine kontospezifische Antwort braucht einen Geltungsbereich, der den authentifizierten Nutzer und dessen aktuelle Berechtigungen abbildet. „Wann steht meine Verlängerung an?“ darf keine Suche über alle Personen auslösen, die dieselbe Frage gestellt haben. Die Identität muss aus der vertrauenswürdigen Authentifizierung der Anwendung stammen – weder aus einem Satz des Nutzers noch aus einem Embedding.

Filter für den Geltungsbereich müssen vor der Kandidatenauswahl greifen; vor der Ausgabe ist die Zugriffsberechtigung zu prüfen. Änderungen an Berechtigungen und Löschungen müssen die betroffene Wiederverwendung unterbinden. RedisVL stellt mit filterable_fields und filter_expression grundlegende Filterfunktionen bereit. Sie definieren jedoch nicht automatisch die Berechtigungsregeln der Anwendung. Filterparameter.

Kontext und Versionen: Die Voraussetzungen der Antwort mitführen

Zum Geltungsbereich eines Eintrags gehören alle antwortrelevanten Vorgaben: Systemprompt, Modellanforderungen, Ausgabeschema, Sprache und Quellversion. Ein gespeicherter Absatz erfüllt keine neue Anfrage, die eine anders strukturierte Antwort verlangt.

Beim Caching von Gesprächen kann derselbe letzte Satz auf unterschiedliche zuvor besprochene Themen verweisen. Microsoft erläutert diesen Fehlerfall ausdrücklich in seiner Erklärung zum Kontextfenster. Solange sich der relevante Verlauf nicht abbilden und prüfen lässt, sind eigenständig verständliche Fragen der bessere Einstieg.

Umsetzung: Gateway, Redis-Architektur oder Bibliothek

Der passende Integrationspunkt liegt dort, wo sich die Grenzen für eine Antwort durchsetzen lassen. Die folgenden Ansätze sind Implementierungsbeispiele, keine Rangliste austauschbarer Produkte.

Gateway-Funktion: Kong AI Semantic Cache

Kong AI Semantic Cache ist ein Plugin des Angebots AI Gateway Enterprise von Kong. Es platziert das semantische Antwortcaching am Gateway, also am Eingangspunkt für Modellanfragen. Die Dokumentation beschreibt eine Embedding-basierte Suche mit Redis- oder pgvector-Konfigurationen. Die Konfigurationsreferenz führt cache_ttl, message_countback und vectordb.threshold auf.

Das passt zu zentral verwalteten, wiederkehrenden Anfrageabläufen. Die wichtigste Einschränkung ist der Anwendungskontext: Ein Gateway kann nur jene Unterschiede berücksichtigen, die in seiner Konfiguration und seinen Anfragen enthalten sind. Vor dem Einsatz für personalisierte Chats müssen daher die Trennung zwischen Nutzern und die Verarbeitung des Gesprächsverlaufs geprüft werden.

Auch die Bezeichnung einer Option verdient Aufmerksamkeit: Laut Kongs Plugin-Übersicht deaktiviert das Einschalten des exakten Cachings die ähnlichkeitsbasierten Treffer nicht. Dieser Schalter ist daher kein Sicherheitsmodus, der ausschließlich exakte Treffer zulässt.

Semantisches Caching mit Redis

Redis, ein Datenspeicher mit Vektorsuchfunktionen, überlässt der Anwendung die Cache-Abfrage und die Verarbeitung bei einem Cache-Miss. Der dokumentierte SemanticCache von RedisVL bietet die Operationen check und store, Metadaten, Filter und TTL-Einstellungen. RedisVL-Dokumentation.

Dieser Ansatz eignet sich, wenn die Anwendung Mandant, Richtlinie und Datensatzversionen bereits kennt und vor der Ausgabe eines Ergebnisses durchsetzen muss. Dieselbe Architektur lässt sich auch mit einem anderen geeigneten Vektorspeicher umsetzen: Prompt-Vektoren finden die Kandidaten; gespeicherte Antworten und Metadaten bestimmen, was wiederverwendet werden darf.

Damit liegt auch die Verantwortung bei der Anwendung. Ein Vektorindex liefert weder Aufnahmeregeln für den Cache noch Invalidierung, Berechtigungsprüfung oder eine korrekte Antwort. Diese Funktionen müssen implementiert und überwacht werden. Außerdem muss die Betriebsumgebung die verwendeten Vektorabfragen unterstützen.

Bibliothek: GPTCache

GPTCache ist eine Bibliothek zum Aufbau semantischer Caches. Sie trennt Embedding-Erzeugung, Antwortspeicherung, Vektorsuche und Ähnlichkeitsbewertung in konfigurierbare Komponenten. Ihre Dokumentation warnt ausdrücklich davor, dass nicht jede Modulkombination kompatibel ist.

Das eignet sich für Entwickler, die innerhalb ihrer Anwendung mit Abruf und Bewertung experimentieren möchten. Die wesentliche Einschränkung ist der Integrationsaufwand: Die gewählten Adapter müssen mit dem aktuellen Modell-SDK und der Betriebsumgebung geprüft werden. Auch hier bleiben dieselben Prüfungen für Geltungsbereich und Aktualität nötig. Die Abstraktion durch eine Bibliothek macht einen semantischen Treffer nicht automatisch korrekt.

Wer zugleich die Ebene für das Routing der Anfragen auswählt, findet im Vergleich von KI-Gateways und in LiteLLM vs OpenRouter eine Grundlage für diese weitergehende Entscheidung. Caching ist dabei eine Anforderung neben Routing, Zugangsdaten und Beobachtbarkeit.

Einsparungen anhand des eigenen Anfrageaufkommens berechnen

Ein Cache spart nur dann Geld, wenn die vermiedenen Generierungskosten höher sind als die Kosten für Embeddings, Abfragen, Speicherung und Betrieb. Auch Cache-Misses zählen: Bei ihnen entsteht zusätzlicher Cache-Aufwand, und das Modell wird trotzdem aufgerufen.

Für die Rechnung gelten ein einheitlicher Messzeitraum und eine einheitliche Währung. N steht für die cachefähigen Anfragen, die nach eventuellen Treffern im exakten Cache die semantische Ebene erreichen; H für akzeptierte semantische Treffer; G für die Generierungskosten je Anfrage unter der vereinfachenden Annahme gleicher Kosten; E für Embedding- und Abfragekosten je cachefähiger Anfrage; W für die Cache-Schreibkosten je Cache-Miss; und F für die festen Infrastruktur- und Betriebskosten des Zeitraums.

Die Rechnung lautet:

• Ohne semantische Cache-Ebene: N × G
• Mit semantischer Cache-Ebene: (N − H) × G + N × E + (N − H) × W + F
• Nettoeinsparung: H × G − N × E − (N − H) × W − F

Mit den eigenen Protokolldaten lässt sich das durchrechnen: Die akzeptierten Treffer werden mit den dadurch vermiedenen Modellkosten multipliziert. Davon gehen die Abfragekosten für alle cachefähigen Anfragen, die Schreibkosten für Cache-Misses und die Fixkosten ab. Für die Generierungskosten zählt der Betrag nach einem möglichen Vorteil durch Prompt Caching beim Anbieter, nicht der Listenpreis ohne Caching.

Unter diesen Annahmen ist die Gewinnschwelle erreicht, wenn:

H > [N × (E + W) + F] / (G + W)

Bei einem gemischten Anfrageaufkommen wird H × G durch die Summe der tatsächlich vermiedenen Generierungskosten für die Trefferanfragen ersetzt. Werden manche Antworten nicht in den Cache aufgenommen, zählen die tatsächlichen Schreibvorgänge. Wiederholungsversuche, Bewertungsaufrufe und Betriebsaufwand gehören in die jeweiligen Summen. Die Trefferquote allein zeigt nicht, ob sich die Wiederverwendung bezahlt gemacht hat.

Dasselbe Prinzip gilt für die Latenz. Treffer sparen die Generierung; bei Cache-Misses kommen Embedding und Suche vor der Generierung hinzu. Beide Abläufe müssen gemessen werden, einschließlich der besonders langsamen Anfragen. Ein überwiegend aus einmaligen Anfragen bestehendes Aufkommen kann insgesamt langsamer werden, obwohl einzelne Treffer schnell beantwortet sind.

Was wird beim semantischen Caching überschätzt?

Eine ähnliche Bedeutung garantiert nicht, dass dieselbe Antwort passt. Der Cache wählt eine vorhandene Antwort aus. Er stellt nicht fest, ob sie weiterhin korrekt, zulässig oder aktuell ist.

Besonders irreführend ist eine steigende Trefferquote ohne begleitende Prüfung falscher Treffer. Ein großzügigerer Schwellenwert kann das Dashboard besser aussehen lassen und zugleich mehr Nacharbeit für den Support verursachen. Gespeicherte Antworten müssen gegen die neuen Anfragen geprüft werden – vor allem jene, die nahe am Akzeptanzgrenzwert liegen.

Antwortcaching ersetzt auch keine Retrieval-Augmented Generation (RAG), bei der ein Modell abgerufenes Quellenmaterial erhält, um eine Antwort zu erzeugen. Ein Cache kann vor diesem Prozess liegen. Wird der Prozess übersprungen, entfällt aber auch der erneute Quellenabruf. Gespeicherte Antworten müssen deshalb an Quellversionen gebunden sein. Wo die zugrunde liegenden Fakten aktuell sein müssen, sollte die Wiederverwendung umgangen werden.

„Meine Bestellung stornieren“ ist eine Aktion, keine wiederverwendbare Frage. Eine frühere Bestätigung belegt nicht, dass eine neue Aktion autorisiert oder ausgeführt wurde. Die Ausführung und ihr aktuelles Ergebnis gehören in den regulären Anwendungsablauf.

Für wen sich der Einstieg lohnt und was als Nächstes ansteht

Entwickler mit wiederkehrenden öffentlichen Fragen können jetzt eng begrenzt beginnen. Dafür wird ein beständiges Anliegen ausgewählt, sein zulässiger Geltungsbereich festgelegt und der exakte Cache als Vergleichsbasis beibehalten. Der Nutzen liegt in weniger wiederholten Generierungsaufrufen, ohne die Arten von Antworten auszuweiten, die die Anwendung wiederverwenden darf.

Betreiber sollten zunächst im Schattenbetrieb evaluieren. Dabei wird protokolliert, welche gespeicherte Antwort ausgegeben worden wäre, während die Anwendung weiterhin die normale Antwort liefert. Echte Umformulierungen und ähnliche, aber unzulässige Fälle werden gekennzeichnet. Anschließend wird der Schwellenwert so abgestimmt, dass unvertretbare Fehler vermieden werden. Zu messen sind der zusätzliche Cache-Aufwand, das Ablaufverhalten und die Qualität der gespeicherten Antwort selbst.

Einkäufer sollten Belege für die Isolation und Invalidierung verlangen. Ein Häkchen bei „semantischer Cache“ reicht nicht. Entscheidend ist, wie das System identische Fragen verschiedener Nutzer behandelt und was unmittelbar nach einer Richtlinienänderung geschieht.

Abwarten ist sinnvoll, wenn die meisten Fragen von veränderlichen Datensätzen oder einem nicht sauber abgrenzbaren Gesprächskontext über mehrere Nachrichten abhängen. Deckt ein exakter Cache die wiederverwendbaren Anfragen bereits ab, kann eine semantische Suche wenig zusätzlichen Nutzen bringen. Prompt Caching beim Anbieter kann dennoch bei wiederholten Eingabepräfixen helfen, ohne die Wiederverwendung einer fertigen Antwort zu verlangen.

Der nächste konkrete Schritt für Montag: ein Anliegen aus dem Hilfecenter auswählen, seine Umformulierungen und bewusst verwechslungsanfällige Alternativen sammeln, den Cache-Geltungsbereich und die Invalidierungsregel festlegen und die Anfragen im Schattenbetrieb erneut abspielen. Die Wiederverwendung von Antworten wird erst aktiviert, wenn die Fälle mit falscher Antwort zuverlässig abgewiesen werden.

Häufige Fragen

Was ist semantisches Caching?

Es speichert frühere Antworten und ruft sie anhand ihrer Bedeutungsähnlichkeit ab. Für die Wiederverwendung sollten außerdem der Kontext passen, gültige Berechtigungen vorliegen und die Antworten ausreichend aktuell sein.

Welche drei Cache-Arten gibt es?

Für die hier behandelte LLM-Entscheidung sind der exakte Antwortcache, der semantische Antwortcache und Prompt Caching beim Anbieter zu unterscheiden. Das ist ein hilfreicher Vergleich für diesen Artikel, keine allgemeingültige Einteilung sämtlicher Computer-Caches.

Wie lässt sich semantisches Caching implementieren?

Zuerst wird der zulässige Geltungsbereich definiert. Dann werden eingehende Prompts in Embeddings umgewandelt, Kandidaten abgerufen und anhand eines kalibrierten Schwellenwerts sowie weiterer Bedingungen auf Wiederverwendbarkeit geprüft. Anschließend wird die gespeicherte Antwort zurückgegeben oder das Modell aufgerufen. Vor der Freigabe der Wiederverwendung müssen Ablaufzeiten, Invalidierung und die Überwachung falscher Treffer hinzukommen.

Ist ein CDN einfach ein Cache?

Nein. Ein Content Delivery Network (CDN) verteilt die Auslieferung von Inhalten auf mehrere Standorte; Caching ist einer seiner Mechanismen. Dazu siehe Cloudflares CDN-Architektur.

Ist Cloudflare ein CDN oder eine WAF?

Cloudflare bietet sowohl CDN-Dienste als auch eine Web Application Firewall (WAF), die den Anwendungsverkehr filtert. Keine der beiden Bezeichnungen steht für sich genommen für semantisches Caching von LLM-Antworten. Cloudflare-Architektur.

Was unterscheidet ein CDN von Redis?

Ein CDN liefert Inhalte über ein Edge-Netzwerk aus. Redis ist ein Datenspeicher, den eine Anwendung zum Caching nutzen kann, auch im Rahmen einer entsprechend konfigurierten semantischen Cache-Architektur. Beide übernehmen unterschiedliche Aufgaben im System.

Ist Cloudflare nur ein CDN?

Nein. Cloudflare beschreibt in seiner Referenzarchitektur auch DNS-, Firewall- und weitere Edge-Dienste.

Ist Kafka besser als Redis?

Die beiden lösen unterschiedliche Aufgaben. Apache Kafka ist eine Plattform für Event-Streaming. Es ist kein direkter Ersatz für die hier beschriebene Architektur eines semantischen Antwortcaches mit Redis.

Nutzt Netflix Redis?

Ja. Redis dokumentiert den Einsatz von Redis bei Netflix für prioritätsgesteuerte Warteschlangen und verlinkt dabei Netflix' Beitrag zu Timestone. Dieses historische Beispiel belegt kein semantisches LLM-Caching und ist kein Grund, es in der eigenen Anwendung zu aktivieren.

Praktische Hinweise zur Entwicklung zuverlässiger KI-Anwendungen gibt es im Newsletter.