Switchyard AI-Gateway: LLM-API-Kosten optimieren

Eine niedrigere Modellgebühr senkt die Gesamtkosten nur dann, wenn die Zahl der Token, Wiederholungen und Fehlversuche ebenfalls kontrolliert wird: Unternehmen sollten zuerst Anfrageklassen und Qualitätsgrenzen definieren, danach Modellrouting, Kontextkürzung, Caching, Budgetlimits und Fehlerüberwachung einführen. Switchyard eignet sich für kontrollierte Routing-Experimente, während ein AI Gateway die zentrale Abrechnung, Zugriffskontrolle und Kostenverteilung übernimmt.

Dieser Beitrag richtet sich an Plattformteams, die für verschiedene Anwendungen eigene Modellbudgets benötigen, an technische Verantwortliche mit schwer nachvollziehbaren Agent-Kosten sowie an Backend-Teams, die eine belastbare Umgebung für Routingtests und Nutzungsüberwachung aufbauen möchten.

Zuletzt aktualisiert am 13.08.2026. Die Aussagen zu Switchyard, Gateway-Funktionen, Caching und Abrechnung wurden anhand der offiziellen Projektdokumentation sowie der aktuellen Dokumentationen der Modellanbieter geprüft.

Die eigentliche Kostenquelle zuerst sichtbar machen

Steigende LLM-API-Kosten entstehen in Unternehmen selten durch einen einzigen Fehler. Häufig handelt es sich um eine Kette aus mehreren Verstärkern, die in der Abrechnung nicht als „Verschwendung“ erscheinen, sondern wie normale Modellnutzung aussehen.

Die wichtigsten Verstärker sind:

• Modellfehlzuordnung: Ein einfaches Extraktions-, Klassifizierungs- oder Zusammenfassungsproblem wird mit einem anspruchsvollen Reasoning-Modell bearbeitet, obwohl die Qualitätsanforderung niedriger liegt.
• Unnötiger Kontext: Systemanweisungen, Chatverläufe, Retrieval-Dokumente und Tool-Ausgaben werden bei jedem Aufruf vollständig erneut übertragen.
• Fehlende Wiederverwendung: Deterministische Antworten, Embedding-Ergebnisse, Dokumentzusammenfassungen oder identische Zwischenresultate lösen immer wieder neue API-Aufrufe aus.
• Verdeckte Wiederholungen: Timeouts, Rate Limits, Netzwerkfehler und ungültige JSON-Ausgaben erzeugen zusätzliche Requests, ohne dass der ursprüngliche Geschäftsprozess sichtbar teurer wirkt.
• Fehlende Kostenverantwortung: Wenn Projekt, Mandant, Umgebung und Zweck nicht im Request-Protokoll stehen, bleibt unklar, welcher Dienst die Rechnung verursacht.
• Unsichtbarer Qualitätsverlust: Nach einer Modellabsenkung wird oft nur der Preis betrachtet. Fehlerhafte Antworten führen dann zu manuellen Korrekturen, weiteren Modellaufrufen oder abgebrochenen Workflows.

Die zentrale Kennzahl ist deshalb nicht nur der Preis pro Million Token. Entscheidend ist, wie viele Eingabe- und Ausgabetoken eine erfolgreiche Geschäftsaktion benötigt, wie oft ein Request wiederholt wird und welches Modell für die jeweilige Aufgabe tatsächlich erforderlich ist. Anbieter rechnen je nach API unter anderem Eingabe-, Ausgabe-, Cache- und Speicherverbrauch getrennt ab; die aktuelle offizielle Abrechnungsdokumentation eines großen Modellanbieters beschreibt diese Kostenbestandteile ausdrücklich. (ai.google.dev)

Schritt eins: Anfrageklassen und Qualitätsgrenzen definieren

Bevor Switchyard eine Anfrage an verschiedene Modelle verteilt, benötigt das Plattformteam eine belastbare Klassifikation. „Einfach“ und „schwierig“ reichen für den Produktionsbetrieb nicht aus. Sinnvoller ist eine Matrix aus Aufgabenart, Fehlerfolgen, Kontextgröße und gewünschter Antwortform.

Typische Anfrageklassen sind:

1. Strukturierte Routineaufgaben: Klassifizierung, Feldextraktion, kurze Umschreibung oder die Erzeugung eines fest definierten JSON-Schemas.
2. Informationsaufgaben: Zusammenfassungen, interne Suche und Antworten auf Dokumentbasis, bei denen Quellenbindung und Aktualität geprüft werden müssen.
3. Werkzeug- und Agent-Aufgaben: Mehrere Tool-Aufrufe, Codeänderungen, Datenbankaktionen oder mehrstufige Planung.
4. Risikosensitive Aufgaben: Vertragsprüfung, sicherheitsrelevante Entscheidungen, externe Kommunikation oder Prozesse mit hohen Folgekosten.

Jede Klasse sollte eine Qualitätsgrenze erhalten. Bei strukturierter Ausgabe kann das beispielsweise ein gültiges Schema ohne Pflichtfeldfehler sein. Bei einer Dokumentantwort können Quellenbezug, Vollständigkeit und Widerspruchsfreiheit geprüft werden. Für Agenten sind zusätzlich Tool-Erfolg, Abbruchrate und erforderliche Nachbearbeitung relevant.

Switchyard unterstützt laut offizieller Projektdokumentation mehrere Routingformen, darunter explizite Modellweiterleitung, klassifikatorgestütztes Routing, signalbasierte Stufenlogik und eigene Router. Außerdem sammelt es unter anderem Token-, Latenz- und Kostendaten pro Request. Diese Funktionen machen Switchyard besonders für Experimente interessant, ersetzen aber keine unternehmensweite Qualitätsprüfung. (github.com)

Wie wählt Switchyard je nach Anfrage das passende Modell?

Die sichere Vorgehensweise besteht nicht darin, sofort jede Anfrage dynamisch zu verteilen. Zuerst wird ein Shadow- oder Replay-Test aufgebaut:

• Ein repräsentativer Request-Datensatz wird anonymisiert.
• Jede Anfrage erhält eine Aufgabenklasse und eine erwartete Qualitätsstufe.
• Das bestehende Modell dient als Referenz.
• Ein günstigeres Modell bearbeitet dieselben Anfragen parallel oder zeitversetzt.
• Die Antworten werden automatisiert und stichprobenartig manuell bewertet.
• Nur Klassen mit akzeptabler Fehlerquote und stabiler Ausgabe werden für die kostengünstigere Route freigegeben.

Die Route sollte außerdem nicht ausschließlich vom Prompttext abhängen. Nützliche Signale sind Kontextlänge, Sprache, Tool-Anzahl, Antwortformat, Risikoklasse und vorhandene Nutzerberechtigungen. Bei sensiblen Aufgaben kann ein starkes Modell verpflichtend bleiben, während Routineaufgaben in eine günstigere Modellgruppe wechseln.

Ein häufiger Fehler besteht darin, einen Klassifikator mit denselben unklaren Beispielen zu trainieren, die später im produktiven Verkehr auftreten. Für die Freigabe sollte deshalb ein separates Validierungsset verwendet werden. Sinkt der Preis, aber steigen ungültige Ausgaben, Eskalationen oder menschliche Korrekturen, wurde die Modellroute nicht optimiert, sondern nur die sichtbare Einzelgebühr verändert.

Schritt zwei: Kontextbudget statt blindem Prompt-Kürzen

Kontextkompression ist eine der wirksamsten Maßnahmen gegen unnötige Eingaben, darf aber nicht dazu führen, dass wichtige Belege oder Sicherheitsinformationen verschwinden. Das Plattformteam sollte den Request in stabile und veränderliche Bestandteile zerlegen:

Bestandteil	Typisches Problem	Geeignete Maßnahme
Systemanweisung	Wird bei jedem Aufruf vollständig wiederholt	Versionieren, stabilen Präfix bilden, unnötige Regeln entfernen
Gesprächsverlauf	Alte Nachrichten bleiben ohne Nutzen erhalten	Zusammenfassen, abgeschlossene Abschnitte archivieren
Retrieval-Inhalte	Zu viele ähnliche Dokumente werden eingefügt	Felder beschneiden, Duplikate entfernen, Trefferzahl begrenzen
Tool-Ergebnisse	Große Rohantworten werden weitergereicht	Nur benötigte Felder übernehmen, Zwischenresultate strukturieren
Auditdaten	Für Nachvollziehbarkeit erforderlich, aber nicht immer für das Modell	Vollständig speichern, jedoch getrennt vom Modellkontext führen

Das Ziel ist nicht der kürzeste Prompt, sondern ein begrenztes Kontextbudget pro Anfrageklasse. Ein Support-Assistent benötigt möglicherweise die aktuelle Richtlinie und wenige relevante Gesprächsfakten, aber nicht den vollständigen Verlauf aller früheren Sitzungen. Ein Code-Agent braucht dagegen bestimmte Dateien, Tests und Fehlermeldungen; dort kann zu aggressive Kürzung zusätzliche Reparaturschleifen auslösen.

Für das Audit sollte der Gateway-Log den ursprünglichen Kontext-Hash, die gekürzte Modellversion, die angewendete Prompt-Version und die verwendeten Dokument- oder Tool-IDs speichern. So bleibt nachvollziehbar, warum eine Antwort entstanden ist, ohne jedes interne Auditfeld erneut an das Modell zu senden.

Schritt drei: Caching mit Berechtigungen und Aktualität verbinden

Caching kann die Nutzung reduzieren, wenn Antworten oder Zwischenresultate wiederverwendbar sind. Geeignet sind vor allem:

• identische Klassifizierungsanfragen,
• stabile Systemanweisungen,
• wiederkehrende Dokumentzusammenfassungen,
• Embeddings und normalisierte Retrieval-Ergebnisse,
• deterministische Tool-Zwischenschritte,
• Batch-Aufgaben, die nicht sofort beantwortet werden müssen.

Ein Cache darf jedoch niemals nur aus „Modellname plus Prompttext“ bestehen. Der Cache-Schlüssel sollte mindestens Modellkennung, Prompt-Version, Mandant, Berechtigungsprofil, Datenstand, Sprache und relevante Tool- oder Dokumentversionen berücksichtigen. Andernfalls kann eine Antwort aus einem anderen Mandanten wiederverwendet werden oder ein veralteter Geschäftsstand als aktuelle Information erscheinen.

Auch providerseitiges Prompt Caching ist kein vollständiger Ersatz für ein Gateway- oder Anwendungscache. Bei einer offiziellen Prompt-Caching-Implementierung werden beispielsweise gemeinsame Präfixe ab einer bestimmten Token-Schwelle erkannt; die Dokumentation nennt eine Erkennung ab 1.024 Token und eine Verarbeitung in 128-Token-Schritten. Die Cache-Lebensdauer und die Abrechnung hängen vom jeweiligen Modell und Anbieter ab. (openai.com)

Daraus folgt eine praktische Trennung:

• Anwendungscache: Verhindert den gesamten Modellaufruf bei wiederverwendbaren Antworten.
• Gateway-Cache: Steuert Wiederverwendung zentral über Mandant, Projekt und Richtlinie.
• Provider-Cache: Reduziert möglicherweise die Kosten stabiler Eingabepräfixe, ersetzt aber keine Prüfung von Datenaktualität und Berechtigungen.

Die aktuelle Preis- und Abrechnungsübersicht des Modellanbieters sollte vor dem Einschalten eines Caches geprüft werden, weil Eingabe-, Ausgabe-, Batch- und Cache-Regeln voneinander abweichen können. (openai.com)

Schritt vier: Retry, Backoff und Fallback begrenzen

Retries sind für stabile APIs notwendig, können die LLM-API-Kosten aber unbemerkt vervielfachen. Ein Timeout, eine temporäre Überlastung und eine ungültige Modellantwort benötigen jeweils eine andere Reaktion.

Fehlerart	Sinnvolle Reaktion	Was protokolliert werden muss
Temporärer Netzwerkfehler	begrenzter Retry mit Backoff	Versuchszahl, Wartezeit, Request-ID
Rate Limit	Anbieterhinweis beachten, danach verzögert wiederholen	Limitantwort, betroffene Route, Zeitfenster
Timeout	Kontext und Timeoutklasse prüfen, nicht blind wiederholen	Laufzeit, Tokenmenge, Modell
Ungültiges JSON	strukturierte Reparatur oder kontrollierte Eskalation	Parserfehler, Reparaturversuch
Inhaltlich unbrauchbare Antwort	Qualitätsprüfung und begrenzter Modellwechsel	Prüfkriterium, alte und neue Route
Wiederholter Ausfall	Circuit Breaker oder Warteschlange	Öffnungszeit, Ausfallgrund, betroffene Projekte

Besonders wichtig ist die Kennzahl Aufrufe je erfolgreicher Geschäftsaktion. Ein Nutzer sieht vielleicht nur eine Antwort, während im Hintergrund ein Erstaufruf, zwei Wiederholungen, eine JSON-Reparatur und eine Eskalation an ein stärkeres Modell stattgefunden haben. Das Gateway sollte daher eine übergeordnete Geschäfts-Request-ID durch alle Modellaufrufe weiterreichen.

Fallbacks dürfen außerdem nicht automatisch auf das teuerste Modell zeigen. Für jede Route sollte ein maximaler Versuchspfad festgelegt werden: Wiederholung, alternative Bereitstellung oder kontrollierter Abbruch. Bei sicherheitskritischen Aufgaben kann ein Abbruch besser sein als eine unkontrollierte Antwort aus einer ungeprüften Route.

Schritt fünf: Budgets im AI Gateway technisch erzwingen

Ein AI Gateway wird erst dann zu einem Governance-Werkzeug, wenn es nicht nur Logs sammelt, sondern Budgets mit Zugriffen und Aktionen verbindet. Die Budgetstruktur sollte nach mehreren Ebenen aufgebaut sein:

• Mandant oder Geschäftseinheit,
• Projekt oder Produkt,
• Umgebung wie Entwicklung, Test und Produktion,
• Zweck wie Support, Recherche, Agent oder Codeanalyse,
• Modellgruppe und Anbieter,
• Nutzer, Servicekonto oder API-Schlüssel.

Die offizielle Dokumentation gängiger Gateway-Proxys beschreibt Funktionen wie projektbezogene Ausgaben, virtuelle Schlüssel, Authentifizierung, Ratenbegrenzung, Logging und zentrale Kostenverfolgung. Diese Bausteine zeigen, welche Mindestfunktionen ein AI Gateway für den Unternehmenseinsatz abdecken sollte. (docs.litellm.ai)

Ein Budgetsystem sollte mindestens drei Zustände unterscheiden:

1. Beobachtung: Das Projekt erhält Warnungen, darf aber weiterlaufen.
2. Begrenzung: Bestimmte teure Modellgruppen oder neue Experimente werden blockiert.
3. Sperre oder Fallback: Weitere Aufrufe werden abgewiesen oder auf eine freigegebene Route umgeleitet.

Eine reine Monatsgrenze ist zu grob. Zusätzlich sollten Tageslimits, Kosten pro Geschäftsaktion, Tokenlimits pro Request und Limits für Agentenschleifen vorhanden sein. Die Verantwortlichen müssen außerdem festlegen, ob ein Budgetüberschuss sofort blockiert, nur gemeldet oder durch eine günstigere Route abgefangen wird.

Für die Abrechnung sollten nicht nur Tokenzahlen gespeichert werden. Notwendig sind mindestens:

• Request-ID und Geschäfts-Request-ID,
• Projekt, Mandant und Umgebung,
• Modell und Anbieter,
• Eingabe-, Ausgabe- und Cache-Token,
• Retry- und Fallback-Anzahl,
• Latenz und Fehlerklasse,
• Prompt- und Route-Version,
• Qualitätsprüfung und Eskalationsgrund.

Nur mit dieser Zuordnung lässt sich unterscheiden, ob hohe Kosten durch große Dokumente, fehlerhafte Agentenlogik, ein zu starkes Modell oder wiederholte Fehlversuche verursacht werden.

Schritt sechs: Qualität nach einer Modellabsenkung sichtbar halten

Ein günstigeres Modell darf nicht pauschal für alle Anfragen eingesetzt werden. Die Freigabe sollte an überprüfbare Bedingungen geknüpft werden:

• strukturierte Ausgaben bestehen die Schema-Prüfung,
• Antworten enthalten die erforderlichen Quellen oder Dokumentbezüge,
• Tool-Aufrufe erreichen das erwartete Ergebnis,
• kritische Fakten werden nicht häufiger falsch dargestellt,
• menschliche Nachbearbeitung bleibt innerhalb der festgelegten Grenze,
• Eskalationen an stärkere Modelle nehmen nicht übermäßig zu.

Für jede Anfrageklasse wird eine kleine, aber repräsentative Testmenge festgelegt. Diese Testmenge sollte bei jeder Änderung an Modell, Prompt, Retrieval, Cache oder Router erneut ausgeführt werden. Zusätzlich sind regelmäßige manuelle Stichproben erforderlich, weil automatisierte Metriken stilistische, rechtliche oder fachliche Fehler nicht vollständig erkennen.

Ein belastbares Muster ist die niedrige Standardroute mit Qualitäts-Eskalation:

1. Das günstigere Modell bearbeitet die Anfrage.
2. Ein Validator prüft Format, Quellenbezug, Vollständigkeit und Risikosignale.
3. Nur bei einem klar definierten Fehler wird an ein stärkeres Modell eskaliert.
4. Der Grund für die Eskalation wird als Kosten- und Qualitätsmerkmal gespeichert.

Damit wird das stärkere Modell nicht abgeschafft, sondern gezielt eingesetzt. Die tatsächliche Einsparung hängt davon ab, wie viele Anfragen die Standardroute erfolgreich beendet und wie viele durch Retries, Eskalationen oder menschliche Korrekturen wieder teurer werden.

Die Umsetzungsreihenfolge für ein kontrollierbares Ergebnis

Die Einführung sollte nicht mit dynamischem Routing beginnen. Eine sinnvollere Reihenfolge lautet:

Phase eins: Beobachtbarkeit und Kostenattribution

Alle Modellaufrufe laufen über einen zentralen Zugang. Request-ID, Projekt, Modell, Tokenverbrauch, Fehler und Kosten werden einheitlich aufgezeichnet. Ohne diese Basis bleibt jede Optimierungsentscheidung eine Vermutung.

Phase zwei: Kontext und Wiederholungen reduzieren

Danach werden doppelte Systemanweisungen, alte Dialogabschnitte, übergroße Tool-Antworten und unnötige Retrieval-Felder gekürzt. Gleichzeitig werden Retry-Regeln, Backoff und Circuit Breaker festgelegt.

Phase drei: Caching kontrolliert einführen

Zuerst werden deterministische und risikoarme Ergebnisse gecacht. Cache-Schlüssel, Mandantentrennung, Datenablauf und Prompt-Versionierung werden vor dem Rollout getestet.

Phase vier: Budget- und Governance-Regeln aktivieren

Projekte erhalten Warnschwellen, Tageslimits, Modellgruppen und Eskalationsregeln. Entwicklung und Produktion werden getrennt ausgewertet.

Phase fünf: Switchyard-Routing mit Validierungsset testen

Erst jetzt werden Anfrageklassen dynamisch verschiedenen Modellen zugeordnet. Der Rollout erfolgt schrittweise, mit Qualitätsprüfung und Rückfallroute. Die Entscheidung wird anhand von Kosten, Qualität, Latenz und Fehlerquote getroffen, nicht anhand des Rechnungsbetrags allein.

Für Teams, die diese Experimente in einer getrennten Umgebung wiederholen möchten, kann eine isolierte Mac-Testumgebung sinnvoll sein. Eine passende Mac-Umgebung für Tests und Entwicklungsaufgaben trennt Replay-Daten vom Produktionszugang. Für geografisch getrennte Tests können zusätzlich Mac-Ressourcen an der US-Ostküste oder Mac-Ressourcen an der US-Westküste geprüft werden.

Checkliste für die Freigabe

• [ ] Jede Anfrage besitzt eine Aufgabenklasse und eine definierte Qualitätsgrenze.
• [ ] Modell, Prompt-Version, Mandant, Projekt und Umgebung werden protokolliert.
• [ ] Die Kosten werden mit einer Geschäfts-Request-ID verknüpft.
• [ ] Eingabe-, Ausgabe- und Cache-Token werden getrennt erfasst.
• [ ] Wiederholungen werden nach Fehlerart unterschieden und begrenzt.
• [ ] Ein Retry kann keine unbegrenzte Agentenschleife auslösen.
• [ ] Cache-Schlüssel enthalten Berechtigung, Datenstand und Prompt-Version.
• [ ] Sensible Aufgaben besitzen eine verpflichtende Modellroute.
• [ ] Ein Validierungsset prüft jede neue Routingregel.
• [ ] Qualitätsverluste lösen eine Eskalation oder einen Rollback aus.
• [ ] Budgetwarnungen und harte Limits sind pro Projekt konfiguriert.
• [ ] Die Abrechnung kann zwischen Entwicklung, Test und Produktion unterscheiden.
• [ ] Die Preis- und Caching-Regeln der Anbieter werden vor jeder Neuberechnung geprüft.

Ein Unternehmen sollte Switchyard daher nicht als automatische Sparmaschine betrachten. Switchyard ist vor allem eine Schicht für Protokollübersetzung, Backend-Auswahl, Routing und Experimente. Die Kostenkontrolle entsteht erst durch die Verbindung mit einem AI Gateway, das Identität, Budgets, Protokollierung, Cache-Regeln und Richtlinien zentral durchsetzt. Die offizielle Switchyard-Projektdokumentation beschreibt die Routing- und Statistikfunktionen; die konkrete Produktionsfreigabe muss das jeweilige Team selbst anhand eigener Anfragen und Qualitätsdaten prüfen. (github.com)

Wenn die aktuelle Lösung nur direkt aus einzelnen Anwendungen auf mehrere Modellanbieter zugreift, fehlen häufig zentrale Kostenstellen, einheitliche Retry-Regeln und eine belastbare Trennung zwischen Mandanten. Ein rein manuelles Modellwechseln senkt zudem nicht automatisch Kontextverbrauch oder Fehlaufrufe. Für zeitlich begrenzte Replay-Tests, Routingexperimente und isolierte Entwicklungsumgebungen kann das Mieten einer Mac-Umgebung deshalb praktischer sein als der sofortige Kauf eigener Hardware: Die Produktionsarchitektur bleibt unangetastet, Testdaten lassen sich getrennt halten, und nach der Validierung kann die geprüfte Route in die bestehende Infrastruktur übernommen werden. Für dauerhafte Hochlast, spezielle physische Schnittstellen oder langfristig gleichbleibende Nutzung ist eine eigene Umgebung dagegen weiterhin die ehrlichere Vergleichsoption.