Cloudflare AI Gateway erweitert die benutzerdefinierte Kostenrechnung um Cache-Token-Preise

Cloudflare hat der benutzerdefinierten Kostenrechnung von AI Gateway Cache-Lese- und Cache-Schreib-Token-Raten hinzugefügt, ein kleiner Änderungsprotokolleintrag mit großen Abrechnungskonsequenzen für Teams, die die Modellnutzung zwischen Anbietern weiterverkaufen, weiterleiten oder abgleichen.

Das Update vom 9. September bedeutet, dass Entwickler jetzt Werte für per_cache_read_token und per_cache_write_token übergeben können cf-aig-custom-cost-Header. Wenn eine Cache-spezifische Rate vorhanden ist, aktiviert AI Gateway laut Cloudflare die Cache-Token-Preise und berücksichtigt Anbieterunterschiede, sodass dieselbe Cache-Nutzung nicht zweimal gezählt wird.

Das klingt eng. Das ist es nicht. Die Cache-Preisgestaltung ist zu einem der schwierigeren Aspekte der einheitlichen KI-API-Abrechnung geworden, insbesondere da Anbieter unterschiedliche Namen, Einheiten und Abrechnungsregeln für wiederverwendeten Kontext verwenden. Es mag einfach sein, jedes zwischengespeicherte Token als normales Eingabetoken zu behandeln, aber es kann falsch genug sein, um die Reseller-Marge zu löschen oder Kunden darüber in die Irre zu führen, welche Workloads tatsächlich teuer sind.

Was sich geändert hat

AI Gateway ermöglichte bereits das Anhängen benutzerdefinierter Kostendaten an Anfragen, wodurch Teams die Möglichkeit hatten, ausgehandelte Tarife oder interne Preisbücher darzustellen, anstatt sich nur auf die Preise öffentlicher Anbieter zu verlassen. Die neue Änderung erweitert diesen Mechanismus auf Cache-spezifische Token-Kategorien.

In der Praxis kann ein Gateway-Betreiber Cloudflare jetzt nicht nur mitteilen, was ein Eingabe- oder Ausgabe-Token kostet, sondern auch, was ein Cache-Lese- oder Cache-Schreibvorgang kostet. Diese Unterscheidung ist wichtig, da Anbieter Prompt-Caching zunehmend als eigene wirtschaftliche Ebene bewerten. Ein Cache-Schreibvorgang kann mehr kosten als ein Cache-Lesevorgang. Ein Cache-Lesevorgang kann erheblich günstiger sein als eine neue Eingabe. Einige Anbieter stellen die Cache-Erstellung und den Cache-Abruf möglicherweise unterschiedlich in Nutzungsdatensätzen dar.

Der Hinweis von Cloudflare, dass Anbieterunterschiede gehandhabt werden, um Doppelzählungen zu vermeiden, ist ebenfalls wichtig. Cache-Felder sind nicht immer sauber von den Eingabe-Token-Summen getrennt. Wenn ein Abrechnungssystem naiv Cache-Tokens zusätzlich zur vom Anbieter gemeldeten Eingabenutzung hinzufügt, kann es Kunden überfordern oder die internen Kosten in die Höhe treiben. Wenn Cache-Felder ignoriert werden, können die Kosten von Anwendungen mit langem Kontext, die häufig Cache-Einträge erstellen, unterschätzt werden.

Warum Cache-Accounting jetzt wichtig ist

Promptes Caching war früher ein Optimierungsdetail. Für viele Produktions-Workloads ist es jetzt Teil der Preisarchitektur.

Lange Systemaufforderungen, durch den Abruf erweiterter Kontext, Coding-Agent-Repositorys, Pakete mit rechtlichen Dokumenten und Support-Wissensdatenbanken profitieren alle von der Wiederverwendung von Kontext. Je mehr wiederholter Kontext ein System sendet, desto mehr verändert die Cache-Preisgestaltung die tatsächliche Einheitsökonomie. Zwei Anfragen mit ähnlicher Tokenanzahl können sehr unterschiedliche Kosten verursachen, wenn eine einen Cache-Eintrag schreibt und eine andere daraus liest.

Das macht die Cache-Sichtbarkeit zu einem finanziellen Problem und nicht nur zu einem technischen Problem. Ein Team, das interne Agenten betreibt, muss möglicherweise wissen, ob ein neuer Workflow teuer ist, weil er zu viele neue Eingabeaufforderungen generiert, den Cache übersieht oder zu oft große Cache-Blöcke schreibt. Ein Wiederverkäufer muss seinen Kunden möglicherweise zeigen, warum die in Rechnung gestellte Nutzung einer Anwendung geringer ist als erwartet, obwohl die Eingabeaufforderung scheinbar groß ist. Ein Gateway-Anbieter muss möglicherweise Cache-Felder in Protokollen, Analysen und Hauptbuchdatensätzen beibehalten, damit der Monatsabgleich mit den Anbieterrechnungen übereinstimmt.

Hier wird auch die AI API-Kostenanalyse anspruchsvoller. Die aggregierten Anfragekosten reichen nicht mehr aus. Teams müssen Eingabe-, Ausgabe-, Cache-Schreib- und Cache-Leseverhalten separat sehen und diese Kategorien dann mit API-Schlüsseln, Kunden, Modellen und Routen verknüpfen.

Wer ist betroffen?

Die unmittelbare Zielgruppe sind Cloudflare AI Gateway-Benutzer, die sich auf benutzerdefinierte Kosten und nicht auf öffentliche Standardpreise verlassen. Dazu gehören Unternehmen mit ausgehandelten Modelltarifen, Plattformen, die die Anbieternutzung für Kunden vergüten, und Teams, die Cloudflare als gemeinsame Steuerungsebene für mehrere Modellanbieter nutzen.

Wiederverkäufer sind besonders gefährdet. Wenn ein Wiederverkäufer seinen Kunden ein vereinfachtes Token-Modell in Rechnung stellt, während er Anbieter mit Cache-bewussten Preisen bezahlt, kann sich die Differenz stillschweigend summieren. Unterbelastete Cache-Schreibvorgänge oder überbelastete Cache-Lesevorgänge werden möglicherweise nicht in einer einzelnen Anfrage angezeigt, können aber bei Agentensitzungen, Stapelverarbeitung oder großen Abruf-Workloads von Bedeutung sein.

Entwickler, die OpenAI-kompatible Gateway-Schichten erstellen, sind davon betroffen, auch wenn sie Cloudflare nicht direkt verwenden. Die Änderung spiegelt eine breitere Richtung im Markt wider: Die Abrechnungsoberflächen der Anbieter werden detaillierter, während Kunden weiterhin eine saubere Rechnung und vorhersehbare Nutzungsberichte erwarten.Produkte wie Model Gate müssen Cache-Token-Felder als erstklassige Hauptbuchdaten behandeln, wenn sie genaue kundenbezogene Berichte, Nutzungsbeschränkungen und Margenanalysen über mehrere Anbieter hinweg wünschen.

Praktische Konsequenzen

Gateway-Teams sollten überprüfen, wie ihre Anfrageprotokolle, Kostenrechner und Rechnungen die Cache-Aktivität darstellen. Wenn Cache-Lese- und Schreibvorgänge in gewöhnliche Prompt-Tokens zusammengefasst werden, sieht die Analyse möglicherweise einfacher aus als die zugrunde liegende Rechnung. Wenn Anbieternutzungsdatensätze Cache-Felder enthalten, die während der Aufnahme gelöscht werden, wird ein späterer Abgleich schwierig sein.

Preis-Engines müssen außerdem mehr als einen Tarif pro Richtung unterstützen. Die alte Input-Output-Aufteilung reicht für die erweiterte Modellrechnung nicht mehr aus. Ein glaubwürdiges Modell-Ledger benötigt jetzt Platz für neue Eingabe-Tokens, Ausgabe-Tokens, Cache-Schreibvorgänge, Cache-Lesevorgänge und möglicherweise anbieterspezifische Varianten dieser Kategorien.

Kundenorientierte Dashboards sollten diese Unterschiede sorgfältig offenlegen. Die meisten Benutzer möchten keine rohen Anbietertelemetriedaten lesen, müssen aber verstehen, warum sich die Kosten ändern, wenn eine Anwendung beginnt, den Kontext effektiver wiederzuverwenden. Die beste Schnittstelle könnte eine Kostenaufschlüsselung sein, die Cache-Einsparungen und Cache-Erstellungskosten zeigt, ohne dass Kunden gezwungen werden, sich mit der Terminologie jedes Anbieters vertraut zu machen.

Es gibt auch betriebliche Auswirkungen auf Warnungen und Grenzwerte. Ein Kundenbudgetlimit, das nur auf der Gesamtzahl der Token basiert, kann möglicherweise eine Arbeitslast nicht abfangen, die teure Cache-Einträge schreibt. Eine Margenwarnung, die nur auf der Anzahl der Anfragen basiert, übersieht möglicherweise eine Preisinkongruenz des Anbieters. Für Teams, die den Zugriff über kundenbezogene Schlüssel verkaufen, sollte die Cache-fähige Buchhaltung an dieselben Kunden-, Projekt- oder Anwendungskennungen gebunden sein, die für die Ausgabenkontrolle verwendet werden.

Was bleibt offen

Das Änderungsprotokoll stellt Unterstützung für benutzerdefinierte Cache-Lese- und Cache-Schreibraten her, klärt jedoch nicht alle Implementierungsfragen für Gateway-Betreiber. Die Teams müssen noch testen, wie ihre jeweiligen Anbieter die Cache-Nutzung melden, wie die berechneten Kosten von Cloudflare in Protokollen und Exporten angezeigt werden und wie bestehende Rechnungen mit den neuen benutzerdefinierten Kostenfeldern verglichen werden sollten.

Die größere Richtung ist jedoch klar. Die AI-Gateway-Abrechnung wandelt sich von einem einfachen Token-Zähler hin zu einem detaillierten Nutzungsbuch. Die Cache-Preise sind jetzt Teil dieses Hauptbuchs. Teams, die die Details bewahren, verfügen über einen saubereren Abgleich und bessere Kundenanalysen. Teams, die es ignorieren, bemerken das Problem möglicherweise erst, wenn ihre Anbieterrechnung und ihre Kundenrechnung nicht mehr dasselbe erzählen.