Reduzieren Sie die LLM-API-Kosten mit Batch-Jobs und schnellem Caching: Ein praktisches Playbook

Viele Teams zahlen zu viel für LLM-APIs, weil sie jede Anfrage über denselben synchronen Pfad senden. Dies eignet sich für Chats, Programmierassistenten, Supportmitarbeiter, Zahlungsströme und alles, was auf einen Benutzer wartet. Es ist verschwenderisch für Auswertungen, Tagging, Anreicherung, Moderations-Sweeps, das Einbetten von Backfills, nächtliche Berichte und die Vorverarbeitung von Inhalten.

Die praktische Frage lautet nicht: „Welches Modell ist das günstigste?“ Es lautet: Welche Arbeit erfordert tatsächlich eine sofortige Reaktion und welche Arbeit kann warten? Sobald Sie diese Frage beantwortet haben, wird die KI-API-Kostenkontrolle zu einem Engineering-Workflow: Datenverkehr klassifizieren, latenztolerante Jobs an die Stapelverarbeitung senden, sofern unterstützt, wiederholte Aufforderungen zum Caching strukturieren und die tatsächlichen Einsparungen nach Fehlern, Wiederholungsversuchen und Betriebsaufwand messen.

Beginnen Sie mit einer Kostenprüfung nach Arbeitsbelastung, nicht nach Modell

Bevor Sie die Architektur ändern, exportieren Sie ein Beispiel der aktuellen API-Nutzung und gruppieren Sie es nach Arbeitslast. Eine nützliche Prüftabelle sollte Folgendes enthalten:

• Endpunkt und Modell: Chat-Abschlüsse, Antworten, Einbettungen, Moderation oder anbieterspezifische Endpunkte.
• Durchschnittliche Eingabe- und Ausgabetokens: Trennen Sie lange Eingabeaufforderungen von kurzen Klassifizierungsaufgaben.
• Eingabeaufforderungsform: stabile Systemanweisungen, wiederverwendbare Beispiele, Schemata, Abrufkontext und dynamische Benutzerdaten.
• Latenzanforderungen: Sekunden, Minuten, Stunden oder nächster Werktag.
• Benutzersichtbarkeit: ob eine Person auf das Ergebnis wartet.
• Wiederholungs- und Fehlerrate: fehlerhafte Anfragen, Validierungsfehler, Anbieter-Timeouts, abgelaufene Jobs und doppelte Übermittlungen.
• Eigentum: Projekt, Team, Kunde, API-Schlüssel oder Partnerkonto.
• Geschäfts-SLA: wann das Ergebnis spätestens noch nützlich ist.

Diese Prüfung zeigt normalerweise, dass „LLM-Verkehr“ keine einzelne Arbeitslast darstellt. Es ist eine Mischung aus interaktiven Produktfunktionen, interner Automatisierung, Berichterstellung, Datenaufbereitung und Qualitätsbewertung. Wenn man sie als eine einzige Kostenstelle behandelt, verbergen sich die einfachsten Einsparungen.

Verwenden Sie einen dreispurigen Workload-Klassifikator

Ein einfacher Klassifikator verhindert, dass Teams den falschen Datenverkehr in den Stapel verschieben und dann von verpassten Erwartungen überrascht werden.

Spur 1: interaktive Echtzeitanfragen

Halten Sie diese synchron. Dazu gehören Chat-UX, Copiloten, Support-Agenten, Human-in-the-Loop-Überprüfung, Live-Such- oder Abrufabläufe sowie Toolaufrufe mit unmittelbaren Nebenwirkungen. Wenn ein Benutzer wartet, kann der Wert einer günstigeren Antwort durch die Latenz zunichte gemacht werden.

Empfehlung: Optimieren Sie diese Spur durch Modellauswahl, sofortiges Trimmen, Ratenbegrenzungsverwaltung, gegebenenfalls Caching und sorgfältige Wiederholungsversuche. Senden Sie es nicht an eine 24-Stunden-Batch-Warteschlange, es sei denn, das Produkt stellt es ausdrücklich als Hintergrundaufgabe dar.

Spur 2: Nearline-Anfragen, die Minuten warten können

Diese Jobs müssen das Laden einer Seite nicht blockieren, aber sie können dennoch eine Erwartung für die gleiche Sitzung oder die gleiche Stunde haben. Beispiele hierfür sind die Dokumentanalyse nach dem Hochladen, die CRM-Anreicherung nach der Formularübermittlung oder ein Bericht, der den Benutzer benachrichtigen kann, wenn er fertig ist.

Empfehlung: Platzieren Sie Nearline-Arbeit hinter einer Warteschlange mit expliziten Statuszuständen. Abhängig von der Unterstützung des Anbieters und der Frist sollten Sie entweder kleine Batches oder synchrone Worker mit niedrigerer Priorität ausführen. Diese Spur profitiert von Job-IDs, Webhooks und einem für den Benutzer sichtbaren Fortschritt.

Spur 3: Offline-Batch-Anfragen, die bis zu 24 Stunden warten können

Dies ist der Hauptweg zur Kostenoptimierung. Gute Kandidaten sind:

• groß angelegte Evaluierungen;
• Datensatzbeschriftung;
• Katalog- oder CRM-Anreicherung;
• nächtliche Zusammenfassung;
• Compliance-Überprüfungswarteschlangen;
• Backfills einbetten;
• Moderations-Sweeps;
• periodische Berichtserstellung;
• Inhaltsvorverarbeitung vor der Indizierung oder Veröffentlichung.

Fakt: Große Anbieter bieten mittlerweile asynchrone Batch-APIs für geeignete Workloads an. Die Batch-API von OpenAI liest Anfragen aus einer hochgeladenen Datei, schreibt Ergebnisse in eine Ausgabedatei und zielt auf die Verarbeitung innerhalb von 24 Stunden ab. OpenAI gibt an, dass die unterstützte Batch-API-Nutzung im Vergleich zu synchronen APIs mit einem Kostenrabatt von 50 % angeboten wird. Die Message Batches API von Anthropic ist für große Mengen an Nachrichtenanfragen, asynchrone Verarbeitung, höheren Durchsatz und 50 % geringere Kosten konzipiert. Die Gemini Batch API von Google ist für großvolumige asynchrone Anfragen zu 50 % der Standardkosten konzipiert, mit einer Zieldurchlaufzeit von 24 Stunden.

Kompromiss: „bis zu 24 Stunden“ eignet sich hervorragend für Backfills und Auswertungen, ist jedoch für interaktive Workflows inakzeptabel. Batch ist eine Planungsstrategie und kein universeller Ersatz für synchrone Inferenz.

Entwerfen Sie den Batch-Pfad als Joblebenszyklus

Der zu vermeidende Implementierungsfehler besteht darin, Batch als einen einzelnen API-Aufruf zu behandeln. Es ist ein Lebenszyklus: Arbeiten annehmen, validieren, beibehalten, einreichen, abfragen, abgleichen und Ergebnisse offenlegen.

Referenzarchitektur

1. Akzeptieren Sie eine normalisierte Anfrage: Halten Sie die Anfrageform nach Möglichkeit nah an Ihrem vorhandenen OpenAI-kompatiblen API-Format. Fügen Sie Metadaten wie Projekt, Team, Kunde, Idempotenzschlüssel, gewünschte Frist und Kostenstelle hinzu.
2. Klassifizieren Sie die Arbeitslast: Weisen Sie die Anforderung einem Echtzeit-, Nearline- oder Offline-Batch zu. Dies sollte richtlinienbasiert sein und nicht im Anwendungscode versteckt sein.
3. Erstellen Sie eine Job-ID: Geben Sie sofort eine Job-ID für Nearline- und Offline-Arbeit zurück.
4. Kompatibilität überprüfen: Überprüfen Sie, ob der ausgewählte Anbieter und das ausgewählte Modell Batch für den angeforderten Endpunkt, die Modalität, die Dateigröße, die Tools, das Antwortformat und andere Funktionen unterstützen.
5. Anforderungszeilen beibehalten: Normalisierte JSONL-Zeilen oder anbieterspezifische Nutzlasten speichern. Fügen Sie eine stabile Zeilen-ID für den Abgleich hinzu.
6. Senden Sie den Batch: Laden Sie die Anforderungsdatei oder die Inline-Batch-Nutzlast hoch, abhängig von den Anbieterbeschränkungen und der Auftragsgröße.
7. Umfragestatus: Verfolgen Sie Anbieterstatus wie „Validierung“, „In Bearbeitung“, „Abgeschlossen“, „Fehlgeschlagen“, „Abgelaufen“, „Abgebrochen“ und „Abgebrochen“, sofern zutreffend.
8. Ausgabezeilen speichern: erfolgreiche Antworten, Fehler auf Zeilenebene, Token-Nutzung, zwischengespeicherte Token-Zählungen (sofern verfügbar) und Anbieter-IDs schreiben.
9. Verbraucher benachrichtigen: Stellen Sie einen Abrufendpunkt, einen Webhook, eine Dashboard-Benachrichtigung oder eine Telegram-Benachrichtigung bereit.
10. Abrechnung abgleichen: Ordnen Sie die Kosten dem ursprünglichen Projekt, Team, Kunden, API-Schlüssel und der Auftrags-ID zu.

Dieses Muster hält die Anwendung einfach. Produktteams reichen Arbeiten ein und erhalten Jobstatus. Die Gateway- oder Orchestrierungsschicht verwaltet Anbieterunterschiede, Batchdateien, Wiederholungsversuche und Abrechnung.

Verwenden Sie explizite Jobstatus

Definieren Sie interne Zustände, auch wenn jeder Anbieter unterschiedliche Namen verwendet:

• in der Warteschlange: akzeptiert, aber nicht übermittelt;
• Validierung: Anbieter oder Gateway prüft die Datei;
• läuft: übermittelt und verarbeitet;
• abgeschlossen: alle verfügbaren Ergebnisse gesammelt;
• completed_with_errors: Einige Zeilen konnten nicht validiert oder ausgeführt werden;
• abgelaufen: Frist verstrichen, bevor alle Zeilen abgeschlossen sind;
• abgebrochen: durch Benutzer, System oder Richtlinie gestoppt;
• fehlgeschlagen: Fehler auf Jobebene, der ein Eingreifen erfordert.

Fakt: OpenAI dokumentiert Batch-Status, einschließlich „Validierung“, „fehlgeschlagen“, „in_progress“, „abgeschlossen“, „abgelaufen“, „abgebrochen“ und „abgebrochen“. Außerdem wird darauf hingewiesen, dass bereits abgeschlossene Arbeiten zurückgegeben und in Rechnung gestellt werden, wenn ein Stapel abläuft, während verbleibende Arbeiten storniert werden.

Empfehlung: Gehen Sie niemals davon aus, dass es sich bei Batch-Jobs um alles oder nichts handelt. Erstellen Sie von Anfang an eine Statusbehandlung auf Zeilenebene.

Errechnen Sie Einsparungen nach Ausfällen und Gemeinkosten

Ein einfaches Sparmodell reicht für die meisten Teams aus:

baseline_cost = synchronous_input_cost + synchronous_output_cost
Batch_cost = discounted_batch_input_cost + discounted_batch_output_cost
Adjusted_batch_cost = Batch_cost + Orchestration_cost + storage_cost + rerun_cost
geschätzte_Einsparungen = Basiskosten – angepasste_Batchkosten

Berechnen Sie dies dann pro Workload, nicht global. Eine nächtliche Evaluierungssuite kann erhebliche Einsparungen bringen. Ein Nearline-Workflow mit vielen fehlerhaften Zeilen, dringenden Fallbacks oder wiederholten Wiederholungen spart möglicherweise weniger als erwartet.

Verfolgen Sie mindestens diese Messwerte:

• Synchronisierung versus Batch-Token-Ausgaben;
• Eingabe- und Ausgabetokens nach Modell;
• Batch-Job-Anzahl und durchschnittliche Zeilen pro Job;
• Fehlerrate auf Zeilenebene;
• Rate abgelaufener Jobs;
• Wiederholungskosten;
• Fallback-to-Sync-Kosten;
• Kosten nach Team, Projekt, Schlüssel, Kunde und Partnerkonto.

Empfehlung: Behandeln Sie den automatischen synchronen Fallback als Ausnahme und nicht als Standard. Es schützt Fristen, kann aber bei übermäßiger Nutzung die erwarteten Einsparungen zunichte machen. Fügen Sie eine Richtlinie hinzu, beispielsweise „Fallback nur, wenn die Geschäftsfrist innerhalb von zwei Stunden liegt und der Job noch nicht begonnen hat.“

Eingabeaufforderungs-Caching für wiederholte lange Präfixe hinzufügen

Durch die Stapelverarbeitung wird der Stückpreis der förderfähigen Arbeit reduziert. Prompt-Caching reduziert die effektiven Kosten und die Latenz wiederholter langer Eingabeaufforderungen, wenn das Anbieterverhalten dies unterstützt.

Fakt: Das Zwischenspeichern von OpenAI-Eingabeaufforderungen gilt automatisch für Eingabeaufforderungen, die länger als 1.024 Token auf unterstützten Modellen sind, speichert das längste zuvor berechnete Präfix zwischen und meldet cached_tokens in den API-Nutzungsdetails. Laut OpenAI werden Prompt-Caches in der Regel nach 5 bis 10 Minuten Inaktivität gelöscht und innerhalb einer Stunde nach der letzten Verwendung entfernt, und Prompt-Caches werden nicht zwischen Organisationen geteilt.

Das Implementierungsmuster ist unkompliziert: Stabile Inhalte zuerst und flüchtige Inhalte zuletzt.

Bessere Eingabeaufforderungsstruktur für das Caching

Systemanweisungen
Stabiler Richtlinientext
Stabiles Ausgabeschema
Stabile Beispiele
Wiederverwendbarer Referenzkontext
---
Dynamische datensatzspezifische Eingabe
Dynamische Benutzer- oder Zeilenmetadaten

Beispielsweise könnte ein Kataloganreicherungsauftrag dieselbe Taxonomie, dasselbe Ausgabeschema, dieselben Markenregeln und dieselben Beispiele für 50.000 Produkte wiederverwenden. Jede Zeile ändert nur den Produkttitel, die Beschreibung und die Attribute. Durch die Platzierung des wiederverwendbaren Präfixes an erster Stelle hat der Anbieter eine bessere Chance, zwischengespeicherte Berechnungen wiederzuverwenden, sofern dies unterstützt wird.

Kompromiss: Caching ist keine dauerhafte Speicherung und sollte nicht als garantiert betrachtet werden. Cache-Fenster, Isolation, Mindestlänge der Eingabeaufforderung und Berichterstellung unterscheiden sich je nach Anbieter. Messen Sie zwischengespeicherte Token, anstatt von Einsparungen auszugehen.

Validieren Sie die Anbieterunterstützung vor der Einreichung

Batch-APIs unterscheiden sich. Das Gateway sollte die Berechtigung überprüfen, bevor es einen Job übermittelt.

Fakten: Die OpenAI Batch API unterstützt kein Streaming und verfügt über separate Batch-Ratenbegrenzungen. Anthropic dokumentiert Batch-Einschränkungen, einschließlich einer Batchgrößenbeschränkung von 100.000 Anfragen oder 256 MB, einem 24-Stunden-Ablauf, einer Ergebnisverfügbarkeit von 29 Tagen, Ratenlimits und der Möglichkeit, dass Batches die konfigurierten Workspace-Ausgabenlimits leicht überschreiten. Google unterstützt Inline-Batch-Anfragen für kleinere Aufträge unter 20 MB und JSONL-Eingabedateien für größere Batch-Anfragen.

Verwenden Sie eine Kompatibilitätscheckliste:

• Ist das angeforderte Modell über die Batch-API dieses Anbieters verfügbar?
• Wird der Endpunkt unterstützt?
• Erfordert die Anfrage ein Streaming? Wenn ja, Stapel ablehnen.
• Werden Tools oder Nebenwirkungen verwendet, die sofort auftreten müssen?
• Überschreitet die Batchdatei die Anbietergrenzen?
• Ist das erwartete Ergebnis innerhalb des Abschlussfensters des Anbieters noch nützlich?
• Sind die Ausgaben lange genug verfügbar, damit nachgeschaltete Systeme sie abrufen können?
• Kann die Arbeitslast eine teilweise Fertigstellung tolerieren?

Empfehlung: Lassen Sie die Validierung frühzeitig aus einem klaren Grund fehlschlagen. Ein abgelehnter Batch-Kandidat ist günstiger als ein abgelaufener oder fehlerhafter Job, der später überarbeitet werden muss.

Schutzmaßnahmen für Teams, Agenturen und Partner

Batch-Systeme können stillschweigend viel Geld ausgeben, da sie große Dateien im Hintergrund verarbeiten. Fügen Sie vor dem breiten Rollout Steuerelemente hinzu:

• Batch-Budgets pro Team: Getrennte Online- und Offline-Ausgabenlimits.
• Maximale Dateigröße und Zeilenanzahl: Erzwingen Sie Anbieterbeschränkungen und Ihre eigenen Betriebsbeschränkungen.
• Warteschlange für unzustellbare Nachrichten: Bewahren Sie ungültige Zeilen mit Validierungsfehlern zur Überprüfung auf.
• Idempotenzschlüssel: verhindern, dass doppelte Belastungen versehentlich erneut eingereicht werden.
• PII-Überprüfung: Batchdateien können zu neuen Datenaufbewahrungs- und Datenschutzpflichten führen.
• Aufbewahrungsrichtlinie: Definieren Sie, wie lange Anforderungsdateien, Ausgabedateien und Protokolle gespeichert werden.
• Benachrichtigungsrichtlinie: Besitzer benachrichtigen, wenn Jobs fehlschlagen, ablaufen oder das Budget überschreiten.
• Attribution: Projekt, Team, Kunde, API-Schlüssel, Modell, Anbieter, Job-ID und Zeilen-ID aufzeichnen.

Für Agenturen und Wiederverkäufer ist die Namensnennung besonders wichtig. Wenn ein Partner Anreicherungs- oder Evaluierungsjobs für viele Kunden durchführt, sollte das System die Kosten pro Kunde und pro Job melden, nicht nur pro Anbieterrechnung.

Wie dies einem AI-API-Gateway zugeordnet wird

Ein KI-API-Gateway ist ein natürlicher Ort, um dies zu implementieren, da es bereits zwischen Anwendungen und Modellanbietern liegt. Das Gateway kann eine OpenAI-kompatible API-Oberfläche für Entwickler beibehalten und gleichzeitig eine kostenbewusste Planung dahinter hinzufügen.

Zu den nützlichen Gateway-Funktionen gehören:

• Einheitliche Abrechnung: Vergleichen Sie synchrone, Batch-, zwischengespeicherte und Fallback-Ausgaben an einem Ort.
• KI-Nutzungsanalyse: Aufschlüsselung der Nutzung nach Modell, Anbieter, Endpunkt, Team, Projekt und API-Schlüssel.
• Teamkontrollen: Legen Sie separate Budgets für interaktive und Offline-Arbeitslasten fest.
• API-Schlüsselzuordnung: Identifizieren Sie, welcher Dienst oder Kunde jeden Auftrag erstellt hat.
• Statusbenachrichtigungen: Senden Sie Benachrichtigungen, wenn Batch-Jobs abgeschlossen werden, fehlschlagen, ablaufen oder sich einer Frist nähern.
• Partner-API-Workflows: ermöglichen es Agenturen oder Wiederverkäufern, Aufträge zu erstellen und Ergebnisse im Namen von Kunden abzurufen, während die Buchhaltung auf Kundenebene erhalten bleibt.

Vorhersage: Mehr Teams werden die LLM-Kosten mit Planungsrichtlinien verwalten, nicht nur mit Modellersetzungen. Während die Batch-Unterstützung bei allen Anbietern ausgereift ist, wird die siegreiche Architektur nach Dringlichkeit, Funktionskompatibilität und Buchhaltungsanforderungen weitergeleitet, bevor sie nach Modellpreis weitergeleitet wird.

Checkliste für die Implementierung

• 30 Tage LLM-API-Nutzung exportieren.
• Klassifizieren Sie jede Arbeitslast als Echtzeit, Nearline oder Offline.
• Wählen Sie einen Offline-Workload mit klarer Zuständigkeit und einer angemessenen Frist.
• Validieren Sie die Batch-Unterstützung des Anbieters für den erforderlichen Endpunkt und das erforderliche Modell.
• Definieren Sie interne Jobstatus und Status auf Zeilenebene.
• Fügen Sie Idempotenzschlüssel, Job-IDs und IDs pro Zeile hinzu.
• Speichern Sie normalisierte Anforderungs- und Antwortdatensätze mit Aufbewahrungskontrollen.
• Senden Sie den ersten Batch hinter einem Feature-Flag.
• Messen Sie die synchronen Basiskosten im Vergleich zu den angepassten Chargenkosten.
• Restrukturieren Sie wiederholte lange Eingabeaufforderungen, um stabile Präfixe an die erste Stelle zu setzen.
• Verfolgen Sie zwischengespeicherte Token, fehlgeschlagene Zeilen, abgelaufene Jobs und Ersatzausgaben.
• Erweitern Sie die Option erst, wenn Einsparungen und Betriebsverhalten in der Analyse sichtbar sind.

Umsetzbare Schlussfolgerung

Beginnen Sie nicht mit der KI-API-Kostenkontrolle, indem Sie jedes Team auffordern, ein günstigeres Modell zu verwenden. Trennen Sie zunächst dringende Arbeiten von Arbeiten, die warten können. Halten Sie interaktive Anfragen synchron. Verschieben Sie Auswertungen, Anreicherung, Tagging, Backfills, Moderations-Sweeps und Berichte in einen Batch, wenn der Anbietersupport und die Geschäftsfristen passen. Strukturieren Sie wiederholte lange Aufforderungen zum Caching. Messen Sie dann die tatsächlichen Einsparungen nach Ausfällen, Wiederholungen, Speicher- und Fallback-Kosten.

Die beste Implementierung ist absichtlich langweilig: Job-IDs, Validierung, Status auf Zeilenebene, Budgets, Nutzungsanalysen und klare Eigentumsverhältnisse. Diese operative Ebene ist es, die Anbieterrabatte in verlässliche Einsparungen umwandelt.

Verwandte Lektüre

• API-Schlüsselzuordnung und Teamausgabenkontrollen
• Routing-, Wiederholungsversuche und Fallback-Richtlinien für LLM-APIs
• bezogene Hinweise zur Model Gate-Implementierung