Semantisches Caching für LLMs: Kosten und Latenz senken – jenseits von Prefix Caching

Prefix Caching verwendet identische Prompts wieder. Semantisches Caching nutzt ähnliche Anfragen: Die eingehende Anfrage wird in einen Vektor umgewandelt (Embedding). Wenn eine nahezu identische Frage kürzlich beantwortet wurde, wird die gespeicherte Antwort ausgegeben, anstatt das Modell erneut aufzurufen. Dies ist einer der effektivsten Hebel für ein Gateway, um Kosten und Latenz zu reduzieren – wobei jedoch ein großer Unterschied zwischen „funktioniert in der Demo“ und „ist sicher in der Produktion“ besteht. Dieser Beitrag erklärt die Funktionsweise, den entscheidenden Stellhebel, die Fälle, in denen das System unbemerkt falsche Antworten liefert, und wo der Cache am besten platziert werden sollte.

Kabir, ein Backend-Entwickler, erlebte eine gute und dann eine schlechte Woche. Die gute Woche: Er hatte einen semantischen Cache vor den Support-Assistenten von Northwind geschaltet – jede eingehende Frage wurde in einen Vektor umgewandelt, und bei einer nahezu identischen Frage wurde die gespeicherte Antwort zurückgegeben, statt das Modell aufzurufen. Das Volumen der Modellaufrufe sank um 35 %. Die Latenz bei Cache-Treffern fiel von etwa 900 ms auf unter 40 ms. Die schlechte Woche: Ein Kunde fragte „Wo ist meine Lieferung?“ und erhielt eine überzeugende, detaillierte Antwort – über die Bestellung eines anderen Kunden. Zwei Kunden hatten innerhalb weniger Minuten semantisch identische Fragen gestellt; der Cache wandelte beide in nahezu denselben Vektor um, erzielte einen Treffer und lieferte die Antwort des ersten Kunden an den zweiten aus.

Der Cache funktionierte genau wie geplant. Er hatte nur keine Ahnung, dass „Wo ist meine Lieferung?“ je nach Fragesteller etwas anderes bedeutet. Semantisches Caching ersetzt einen Modellaufruf durch einen Ähnlichkeitsabgleich, und die Sicherheit dieses Vorgangs hängt von zwei Faktoren ab: dem Schwellenwert für den Abgleich und dem, was Sie überhaupt erst in den Cache lassen. Dieser Beitrag behandelt beides.

Was das AI Gateway von TrueFoundry hier bietet

Alles, was in diesem Beitrag beschrieben wird – exaktes und semantisches Caching, der Ähnlichkeitsschwellenwert als pro Route konfigurierbarer Parameter, die mandantenbezogene Isolierung, damit Kabirs Fehler aus der Einleitung niemals passiert, sowie die Telemetrie zu Trefferraten und Kosteneinsparungen, die Ihnen zeigt, ob sich der Cache tatsächlich auszahlt – ist etwas, das das AI Gateway Caching von TrueFoundry als Gateway-Konfiguration bereitstellt. Ein einziger Header in der Anfrage aktiviert die Funktion; das Gateway hasht die Anfrage (oder erstellt bei semantischem Caching ein Embedding der letzten Nachricht), vergleicht sie mit einem Redis-basierten Speicher und gibt bei einem Treffer die zwischengespeicherte Antwort zurück. Bei einem Misserfolg geht die Anfrage an den Anbieter, und die neue Antwort sowie das Embedding werden für das nächste Mal gespeichert.

Die Korrektheit – also sicherzustellen, dass zwei semantisch ähnliche Anfragen von verschiedenen Benutzern niemals die Antwort des jeweils anderen zurückgeben – wird durch ein zweistufiges Namespacing gewährleistet. Stufe 1 ist automatisch: Jeder Cache-Eintrag ist an den aufrufenden Benutzer oder das virtuelle Konto gebunden, sodass die Anfrage von Benutzer A niemals den Eintrag von Benutzer B treffen kann, Punkt. Stufe 2 ist optional: ein Namespace -Feld in der Cache-Konfiguration ermöglicht eine weitere Unterteilung (pro Mandant, pro Umgebung, pro System-Prompt-Version), was in der Praxis genau das ist, was das Namespace-Argument in diesem Beitrag erfordert. Zusammen sorgen diese Mechanismen dafür, dass ein semantischer Cache auf Gateway-Ebene sicher über verschiedene Dienste hinweg geteilt werden kann, ohne dass jeder Dienst die Isolierung selbst implementieren muss.

‍

‍