HotKV senkte den Claude-Token-Verbrauch in unserem Banking77-Benchmark um 70 %

Ein semantischer Cache verspricht, die LLM-Ausgaben zu senken, indem er wiederholte und ähnliche Fragen aus dem Speicher beantwortet, statt das Modell aufzurufen. Wir haben das Ende-zu-Ende gemessen: dieselben 3.000 Kundensupport-Anfragen, an jedes von vier Claude-Modellen zweimal gesendet, einmal direkt an das Modell und einmal mit HotKV davor, wobei das Prompt-Caching von Anthropic in beiden Läufen eingeschaltet blieb. Hier steht genau, was wir ausgeführt haben und was dabei herauskam, einschließlich der Stellen, an denen es Schwächen zeigt.

Kurz gesagt. HotKV senkte die Modellaufrufe, die Token (Eingabe plus Ausgabe) und die API-Kosten bei jedem der vier Modelle um etwa 70 %. Der größte Teil davon stammt von Fragen, die sich wortgleich wiederholen. Die semantische Schicht bringt grob 12 Punkte obendrauf. Beim Standard-Ähnlichkeits-Schwellenwert von 0,81 beurteilten die Bewerter zwischengespeicherte Antworten um 5,8 bis 10,7 Prozentpunkte seltener als zur exakten Frage passend als frische Antworten. Bei dem einzigen Modell, für das wir mehrere Schwellenwerte durchgemessen haben (Sonnet 5.5), zeigte sich ab einem Schwellenwert von 0,88 keine solche Lücke.

Aktualisiert am 12. Oktober 2026: Dieser Artikel berichtet jetzt über unseren größeren Lauf mit vier aktuellen Claude-Modellen. Er ersetzt einen früheren Lauf mit 1.500 Anfragen an GPT und Claude Sonnet 5, der etwa 60 % weniger Token ergab und den wir nicht mehr darstellen.

Was wir getestet haben

Der Workload

Wir haben Kundensupport-Fragen aus dem Test-Split von Banking77 (PolyAI, CC BY 4.0) abgespielt, einem öffentlichen Datensatz kurzer Banking-Fragen, die mit 77 Intents annotiert sind. Er wurde in Casanueva et al., 2020 vorgestellt. Die 3.000 Anfragen wurden mit einem festen Seed gezogen. Die Beliebtheit der Intents folgt einer Zipf-Verteilung mit dem Exponenten 1,0, einer synthetischen Verzerrung, bei der einige wenige Intents weit häufiger vorkommen als der Rest, und die Frage innerhalb eines Intents wird gleichverteilt gezogen, mit Wiederholungen. Alle 77 Intents kommen vor, und 1.264 der 3.000 Anfragen sind voneinander verschiedene Fragen (durch erneutes Abspielen des Anfragegenerators mit seinem Seed gezählt). Die Bank und ihre Support-Richtlinie sind fiktiv. Wir haben eine Richtlinie von etwa 2.200 Token geschrieben, die bei jeder Anfrage als Systemprompt gesendet wird und zwei bis vier kurze Sätze verlangt.

Modelle und Einstellungen

Wir haben claude-fable-5-1, claude-opus-5-5, claude-sonnet-5-5 und claude-haiku-5-5 ausgeführt. Fable 5.1 und Opus 5.5 liefen mit ihrem niedrigsten Reasoning-Aufwand, weil sich ihr Thinking nicht abschalten lässt. Sonnet 5.5 lief mit ausgeschaltetem vorgelagertem Thinking, seiner niedrigsten Einstellung, und Haiku 5.5 mit deaktiviertem Thinking. Die maximale Ausgabe betrug 2.000 Token für Fable und Opus und 400 für Sonnet und Haiku, und jede Antwort endete normal, statt abgeschnitten zu werden. In beiden Modi liefen jeweils acht Anfragen gleichzeitig, die Aufrufe wurden nicht gestreamt, und jede Bedingung wurde einmal ausgeführt.

Die beiden Läufe

• Baseline: Jede Anfrage geht direkt an das Modell, mit eingeschaltetem Prompt-Caching von Anthropic (cache_control auf dem Systemprompt, standardmäßige Lebensdauer von fünf Minuten). Dies ist die hier verwendete konfigurierte Baseline und keine Behauptung, dass jede anbieterseitige Optimierung ausgeschöpft wurde.
• Mit HotKV: HotKV ist demselben Traffic und demselben Systemprompt vorgeschaltet, wobei der Cache leer startet.

Was wir gezählt haben

Jede Token-Zahl stammt aus dem usage-Block der API-Antwort: nicht gecachte Eingabe, Cache-Lese- und Cache-Schreibvorgänge sowie Ausgabe (Thinking eingeschlossen). Embedding-Token werden separat geführt. Die Kosten beruhen auf den Listenpreisen von Anthropic vom 11. Oktober 2026 und schließen die Embedding-Aufrufe für semantische Lookups ein, das Hosting und den Betrieb von HotKV aber aus. Sie sind keine Angabe der aktuellen Preise.

So funktioniert der Cache

Für jede Frage versucht HotKV zwei Lookups, bevor das Modell aufgerufen wird:

1. Exakte Übereinstimmung: ein GET auf einen SHA-256-Schlüssel, der aus dem Modell, der Version des Systemprompts und der normalisierten Frage gebildet wird (in Kleinbuchstaben, Leerraum zusammengezogen). Er erfasst eine Frage, die mit identischem Wortlaut gestellt wird.
2. Semantische Übereinstimmung: ein SCACHE.GET-Aufruf mit einem Embedding der Frage (OpenAI text-embedding-3-small, Kosinus-Ähnlichkeit). Er sucht nach einer ähnlichen Frage. Ein Ähnlichkeitswert allein kann nicht garantieren, dass die zwischengespeicherte Antwort passt.

Nur eine Anfrage, bei der beide Lookups einen Cache-Miss ergeben, erreicht das Modell, und seine Antwort wird mit SET und SCACHE.SET zurückgeschrieben. Der Ähnlichkeits-Schwellenwert für einen semantischen Treffer wurde vor dem Lauf auf 0,81 festgelegt. Wir haben ihn auf einem separaten Banking77-Train-Split als den niedrigsten Wert in Schritten von 0,01 gewählt, dessen semantische Treffer in mindestens 98 % der Fälle auf denselben Intent verwiesen (dort 98,2 %). In diesem Lauf entsprachen auf dem unberührten Test-Split 96,7 % bis 96,8 % der semantischen Treffer dem Intent der gestellten Frage: 30 oder 31 Treffer mit falschem Intent pro Modell bei 926 bis 936 Treffern.

Ergebnisse

Aufrufe, Token und Kosten

Über die vier Modelle hinweg sanken die Aufrufe von 12.000 auf 3.588, die Token um 70,1 % und die Kosten um 69,6 %. Bei jedem Modell wurden etwa 70 % der Anfragen aus dem Cache beantwortet: grob 39 % durch exakte und 31 % durch semantische Übereinstimmung.

Aufrufe, Token und Dollar sinken gemeinsam, weil HotKV ganze Aufrufe entfernt. Lesen Sie die Token-Zahl mit Vorsicht: 90 % bis 93 % der gezählten Token sind Cache-Lesezugriffe auf denselben Richtlinien-Prompt mit 2.200 Token, den Anthropic zu einem kleinen Bruchteil des normalen Eingabepreises berechnet. Ausgabe-Token machen nur 6 % bis 9 % der Token aus, aber 73 % bis 92 % der Baseline-Kosten.

Geschwindigkeit

Die mediane Antwortzeit über den gesamten Lauf sank bei Fable 5.1 von 2,7 Sekunden auf 127 ms, bei Opus 5.5 von 2,9 Sekunden auf 126 ms, bei Sonnet 5.5 von 1,8 Sekunden auf 128 ms und bei Haiku 5.5 von 1,4 Sekunden auf 125 ms, was 11- bis 23-mal schneller ist. Eine wiederholte Frage kam im Median nach etwa 0,05 ms zurück, gemessen von einem Python-Client über Loopback auf derselben Maschine wie HotKV, es ist also ein lokaler Wert und kein Netzwerkwert. Eine umformulierte Frage, aus dem semantischen Cache bedient, dauerte etwa 130 ms, fast alles davon der Embedding-API-Aufruf.

Der Median über den gesamten Lauf liegt innerhalb dieses Bereichs der semantischen Treffer, weil exakte Treffer (etwa 39 % der Anfragen) allein zu wenige sind, um den Median zu tragen, während exakte und semantische Treffer zusammen (70 %) die Hälfte überschreiten. Das langsame Ende verändert sich weniger: 30 % der Anfragen rufen weiterhin das Modell auf. Das 99. Perzentil lag bei Fable 5.1 mit HotKV bei etwa 6,4 Sekunden gegenüber 6,6 Sekunden ohne, bei Haiku 5.5 ungefähr gleich. Bei Opus 5.5 (4,7 Sekunden gegenüber etwa 6) und bei Sonnet 5.5 (2,7 Sekunden gegenüber 3,3) war es niedriger. Die Aufrufe wurden nicht gestreamt, daher sind dies Zeiten bis zur vollständigen Antwort, nicht bis zum ersten Token.

Aufwärmphase

Der Cache startet leer, daher erreichen frühe Anfragen noch das Modell. Der Anteil der aus dem Cache bedienten Anfragen lag in den ersten tausend Anfragen bei etwa 52 % und in den letzten tausend bei etwa 81 %.

Woher die Einsparung kommt

Der größte Teil der Einsparung ist schlichte Wiederholung. Ein reiner Cache mit exakter Übereinstimmung hätte höchstens 1.264 Modellaufrufe von 3.000 benötigt, einen für jede verschiedene Frage, das sind etwa 58 % weniger. Die semantische Schicht hat das auf etwa 70 % gesteigert, sie trägt bei diesem Workload also grob 12 Punkte bei. Sie ist auch der Teil, der das Risiko für die Antwortqualität birgt, wie der nächste Abschnitt zeigt. Das ist aus der Anfragefolge und den Logs abgeleitet, kein separater Messlauf.

Antwortqualität

Ein semantischer Treffer bedeutet denselben Intent, nicht dieselbe richtige Antwort. Um die Korrektheit zu messen, haben wir jeden semantischen Treffer von einem anderen Claude-Modell bewerten lassen. Der Bewerter sah die Frage des Kunden und zwei Antworten in zufälliger Reihenfolge: die zwischengespeicherte Antwort, die HotKV ausgeliefert hat, und die frische Antwort, die dasselbe Modell im Baseline-Lauf auf genau diese Frage gegeben hat. Er gab an, ob jede Antwort genau diese Frage korrekt beantwortet. Opus 5.5 bewertete die Antworten von Fable 5.1, Sonnet 5.5 und Haiku 5.5, und Fable 5.1 bewertete Opus 5.5, sodass kein Modell seine eigene Ausgabe bewertet hat.

Beim Standard-Schwellenwert

Bei 0,81 passte eine zwischengespeicherte Antwort um 5,8 bis 10,7 Prozentpunkte seltener zur exakten Frage als eine frische Antwort desselben Modells. Semantische Treffer machen etwa 31 % der Anfragen aus, über alle Antworten hinweg und mit exakten Treffern als neutral gezählt sind das grob 2 bis 3 Punkte (1,8 bis 3,3). Die Bewerter unterscheiden sich in ihrer Strenge, vergleichen Sie daher zwischengespeicherte und frische Antworten nur innerhalb eines Modells.

Den Schwellenwert erhöhen

Wir haben Sonnet 5.5 mit vier weiteren Schwellenwerten erneut ausgeführt, jeweils mit leerem Cache und demselben Bewerter. Die Baseline-Kosten betrugen 5,51 $.

Ab 0,88 zeigten zwischengespeicherte Antworten kein Defizit gegenüber frischen und senkten dabei weiterhin die Kosten, um 64 % bei 0,88 und um 61 % bei 0,90. Die Beleglage ist dünn. Bei 0,90 reicht das 95-%-Intervall für den Unterschied von etwa 4 Punkten schlechter bis zu 7 Punkten besser, die Zeile für 0,95 hat nur 50 Treffer, und jede Zeile bewertet eine andere Teilmenge von Treffern. Das ist ein Modell, ein Bewerter und ein Lauf pro Schwellenwert, daher ist es weder ein Beweis für gleichwertige Qualität noch für einen universell sicheren Schwellenwert.

Fast identische Fragen

Das eigentliche Risiko sind Fragen, die fast identisch aussehen, aber unterschiedliche Antworten erfordern, etwa Einzahlen versus Abheben. Wir ließen 119 Paare von Opus 5.5 schreiben, jeweils eine echte Frage aus dem Train-Split plus eine Version, in der ein entscheidendes Detail verändert wurde, und zählten, wie viele veränderte Fragen den Schwellenwert gegen einen Cache überschreiten würden, der nur das Original enthält. Diese Paare sind bewusst schwierig gebaut, wurden nicht von einem Menschen geprüft und zeigen einen schlimmsten Fall, nicht wie oft er im realen Traffic auftritt.

Ein höherer Schwellenwert verringert das Risiko, beseitigt es aber nicht. Selbst bei 0,90 würden 25 % der absichtlich ähnlichen Paare übereinstimmen, und es stimmen auch weniger echte Umformulierungen überein.

Was das im großen Maßstab bedeutet

Rechnet man die gemessenen Kosten pro Anfrage auf 1 Million Anfragen pro Tag über einen Monat mit 30 Tagen hoch und nimmt dasselbe Traffic-Muster an, ergeben sich diese Monatswerte:

• claude-fable-5-1: etwa 303.100 $ ohne HotKV, 91.800 $ mit HotKV, grob 211.300 $ gespart.
• claude-opus-5-5: etwa 146.000 $ ohne HotKV, 45.000 $ mit HotKV, grob 101.000 $ gespart.
• claude-sonnet-5-5: etwa 55.100 $ ohne HotKV, 16.600 $ mit HotKV, grob 38.500 $ gespart.
• claude-haiku-5-5: etwa 2.700 $ ohne HotKV, 800 $ mit HotKV, grob 1.900 $ gespart.

Das ist Arithmetik auf den gemessenen Kosten pro Anfrage, kein weiterer Messlauf. Das Hosting ist darin nicht enthalten, und die für dieses Volumen nötige Kapazität wurde nicht gemessen. Bei den 3.000 Anfragen, die wir ausgeführt haben, beträgt die Einsparung nur 0,19 $ für Haiku 5.5 und 21,12 $ für Fable 5.1. Die vier Modelle liefen mit kurzen Antworten, Fable 5.1 und Opus 5.5 mit ihrem niedrigsten Reasoning-Aufwand, sodass längere oder Reasoning-lastige Antworten jeden vermiedenen Aufruf wertvoller machen würden.

Einschränkungen

Das ist keine allgemeine Aussage „HotKV spart Ihnen 70 %“. Es ist das, was wir bei diesem Workload gemessen haben, und der Workload trägt dabei die Hauptlast.

• Die Einsparung folgt der Wiederholung. Bei gleich wahrscheinlichen Intents statt einer Zipf-Verteilung sanken die Kosten bei Sonnet 5.5 und Haiku 5.5 um 56 %. Bei 3.000 lauter verschiedenen Fragen sanken sie um 38 %, vollständig durch semantische Übereinstimmungen zwischen verschiedenen Fragen desselben Intents, von denen Banking77 reichlich hat. Ein Workload ohne wiederholte oder ähnliche Fragen spart nichts.
• Synthetischer Traffic. Die Ziehungen sind unabhängig: keine Bursts, Sessions oder Kontexte über mehrere Gesprächsrunden. Ein öffentlicher Datensatz kurzer Banking-Fragen, eine für diesen Test geschriebene fiktive Richtlinie und ein endlicher Pool von etwa 3.080 Testfragen.
• Ein Modell bewertet die Antworten. Kein Mensch hat sie geprüft, es gab keinen zweiten Bewerter, und jeder Bewerter ist ein Claude-Modell. Frische Antworten fielen beim „passt“-Test des Bewerters in 1 % bis 21 % der Fälle durch, es ist also eine strenge Hürde.
• Gleicher Intent ist nicht gleiche Antwort. Der Schwellenwert von 0,81 wurde an Intent-Labels kalibriert, nicht an der Antwortqualität. Die Schwellenwert-Läufe und der Test mit fast identischen Fragen decken ein Modell und ein Embedding-Modell ab.
• Kleiner Testaufbau. Ein Lauf pro Bedingung, ein einzelner Server mit vier vCPUs, auf dem auch der Client läuft, und ein Cache, der vor den HotKV-Läufen nicht aufgewärmt wurde.
• Die Kosten sind API-Kosten. Sie schließen das Hosting und den Betrieb von HotKV aus. Prüfen Sie die Antwortqualität anhand Ihrer eigenen Fragen, und nutzen Sie exaktes Caching oder frische Antworten, wo semantische Wiederverwendung ungeeignet ist.

Die Zahlen pro Modell stehen auch auf der KI-Seite.

Probieren Sie es selbst aus

Der Cache mit exakter Übereinstimmung in diesem Test nutzt einfaches GET und SET, die jeder HotKV-Tarif enthält. Den semantischen Cache (SCACHE.*) gibt es ab dem Performance-Tarif (Preise). Starten Sie auf HotKV Cloud und richten Sie Ihren bestehenden Traffic darauf aus, oder sprechen Sie mit dem Vertrieb, wenn Sie die Zahlen zuerst für Ihren eigenen Workload durchrechnen möchten.