KI-Kosten im Team senken: sechs Hebel

Ein Muster, das sich in vielen Teams wiederholt: Im Piloten kostet eine KI-Funktion fast nichts, ein paar Cent pro Anfrage. Dann geht das Feature in Produktion, die Anfrage wird zum Agenten-Workflow mit Tool-Calls und Zwischenschritten, und plötzlich kostet dieselbe Aufgabe das Zehn- bis Fünfzigfache. Die Rechnung am Monatsende erklärt niemand so richtig.

Das Gute daran: Die meisten dieser Kosten sind kein Naturgesetz, sondern eine Folge von Standardeinstellungen. Wer versteht, wofür er zahlt, kann mit ein paar gezielten Eingriffen die Hälfte oder mehr einsparen, ohne dass die Qualität leidet.

Dieser Artikel betrachtet die Team- und Architektur-Ebene: Modellwahl, Caching, Gateways, Self-Hosting. Wer einzelne Chats effizienter führen will (Endlos-Konversationen vermeiden, sauber prompten), findet die Grundlagen im Artikel KI-Tools effizient nutzen. Hier geht es um die Ebene darüber: die API-Rechnung des ganzen Teams.

Was die Rechnung antreibt

Bevor man optimiert, lohnt der Blick auf die drei Stellschrauben, an denen die Kosten wirklich hängen.

Output ist teurer als Input. Bei praktisch allen Anbietern kostet ein Output-Token ein Vielfaches eines Input-Tokens, je nach Modell grob das Vier- bis Achtfache. Eine knappe Antwort ist also nicht nur angenehmer zu lesen, sondern direkt billiger.

Denken kostet, auch wenn man es nicht sieht. Reasoning-Modelle erzeugen interne Thinking-Tokens, bevor sie antworten. Die zählen als Output und tauchen in der Rechnung auf, ohne dass sie im sichtbaren Text stehen. Ein komplexer Aufruf an ein Flaggschiff-Modell mit vollem Reasoning-Aufwand kann zehntausende solcher Tokens verbrauchen.

Agenten vervielfachen alles. Eine einfache Chat-Anfrage ist ein Aufruf. Ein Agent, der ein Ziel verfolgt, macht für dieselbe Aufgabe zehn, zwanzig oder mehr Aufrufe, jeder mit dem kompletten Kontext im Schlepptau. Marktbeobachtungen beziffern den Mehraufwand auf das Fünf- bis Fünfundzwanzigfache gegenüber einem schlichten Chatbot. Genau das ist der Pilot-to-Production-Schock von oben.

Dazu kommt die Spanne zwischen den Modellklassen. Zwischen einem Leichtgewicht und einem Flaggschiff liegt schnell ein Faktor von zwanzig oder mehr pro Token. Ob eine Aufgabe das teuerste Modell braucht oder nicht, ist deshalb die folgenreichste Entscheidung überhaupt.

flowchart TB
  MESS["Erst messen:<br/>wofür geht das Budget drauf?"]
  MESS --> A["Schnelle Gewinne:<br/>Modellrouting, Caching, knappe Outputs"]
  A --> B["Mittlerer Aufwand:<br/>Batch-Jobs, Gateway als Kontrollschicht"]
  B --> C["Bei hohem Volumen:<br/>Self-Hosting kleiner Modelle"]
  classDef start fill:#1A3A4A,stroke:#00BCEC,color:#BAE6FD
  classDef quick fill:#14532D,stroke:#22C55E,color:#86EFAC
  classDef mid fill:#1A3A4A,stroke:#F59E0B,color:#FDE68A
  class MESS start
  class A quick
  class B,C mid

Hebel 1: Das richtige Modell für die Aufgabe

Der häufigste Fehler ist, für alles das beste Modell zu nehmen. Wenn ein Entwickler im Tool standardmäßig Opus oder GPT-5.5 eingestellt hat, läuft auch die simpelste Klassifikation über das teuerste Modell. Das ist, als würde man jeden Brief per Express-Kurier schicken.

Eine grobe Einteilung, an der man sich orientieren kann:

Die Größenordnungen ändern sich laufend, deshalb hier bewusst keine Cent-Beträge. Als Anker: Ein Flaggschiff wie Opus 4.8 oder GPT-5.5 liegt beim Output im Bereich von 25 bis 30 US-Dollar pro Million Tokens, ein Leichtgewicht der Haiku- oder Flash-Klasse grob eine Größenordnung darunter, und sehr günstige Anbieter wie DeepSeek noch deutlich tiefer. Den tagesaktuellen Stand prüft man am besten direkt auf den Pricing-Seiten der Anbieter, denn er bewegt sich schnell, meist nach unten.

Wer das systematisch macht, lässt nicht den Menschen pro Anfrage entscheiden, sondern routet automatisch: einfache Aufgaben an kleine Modelle, harte an große. Forschung zum Thema (das RouteLLM-Projekt) zeigt im Idealfall bis zu 85 Prozent Einsparung bei nahezu gleicher Qualität, in der Praxis berichten Teams eher von 30 bis 70 Prozent. Das ist der Hebel mit dem größten Effekt, und Hebel 4 zeigt, wie man ihn ohne Code-Umbau zieht. Den manuellen Einzelfall behandelt Regel 5 in KI-Tools effizient nutzen.

Hebel 2: Caching, der fast geschenkte Rabatt

Wenn dein System jedem Aufruf denselben langen System-Prompt oder dasselbe Referenzdokument voranstellt, zahlst du ohne Caching jedes Mal voll dafür. Caching speichert diesen wiederkehrenden Teil und berechnet ihn beim nächsten Mal stark vergünstigt.

Die Konditionen der drei großen Anbieter (Stand Recherche, am Schreibtag gegenprüfen):

• Anthropic: Gecachte Tokens kosten beim Lesen nur 10 Prozent des Normalpreises, also 90 Prozent Rabatt. Das Schreiben in den Cache kostet einmalig etwas mehr, der Vorteil greift also ab der ersten Wiederholung. (Doku)
• OpenAI: Caching läuft automatisch ab etwa 1.024 Tokens Prefix, ohne dass man etwas konfiguriert, mit 50 Prozent Rabatt auf den gecachten Teil als belegter Standardmechanik. (Ankündigung)
• Google Gemini: Implizites und explizites Caching, bei der aktuellen Modellgeneration bis zu 90 Prozent günstiger auf gecachte Tokens. (Doku)

Caching lohnt sich überall dort, wo viel Kontext stabil bleibt: ein langer System-Prompt, ein Vertrag oder Code, zu dem viele Folgefragen kommen, oder ein Agenten-Workflow mit gleichbleibendem Basiskontext. Bei einmaligen, immer neuen Anfragen bringt es nichts.

Hebel 3: Batch für alles, was warten kann

Nicht jede Anfrage muss in Sekunden beantwortet werden. Für Massenjobs, die auch in ein paar Stunden fertig sein dürfen, bieten alle drei großen Anbieter eine Batch-Verarbeitung mit 50 Prozent Rabatt auf Input und Output (Anthropic, OpenAI, Google). Die Verarbeitung ist asynchron, garantiert meist innerhalb von 24 Stunden, oft schneller, und läuft über ein eigenes Kontingent, das die normalen Rate-Limits nicht belastet.

Typische Kandidaten: nächtliche Auswertungen, Dokumenten-Pipelines (Extraktion, Klassifikation, Zusammenfassung im großen Stil), das Evaluieren von KI-Outputs. Alles, was kein Mensch in Echtzeit erwartet. Bei Anthropic lässt sich Batch mit Caching kombinieren, die Rabatte stapeln sich.

Hebel 4: Ein Gateway als Kontrollschicht

Sobald mehr als eine Person oder mehr als ein Dienst KI nutzt, wird die fehlende Übersicht zum Problem. Ein LLM-Gateway setzt sich als Zwischenschicht zwischen deine Anwendungen und die Anbieter und löst gleich mehrere Dinge auf einmal: einheitliche Schnittstelle für viele Modelle, automatisches Routing pro Aufgabe, Budget-Limits pro Team oder Schlüssel, zentrales Logging und Caching, Fallback bei Ausfällen.

Drei gängige Optionen mit unterschiedlichem Profil:

• LiteLLM ist Open Source (MIT-Lizenz) und selbst hostbar, mit einheitlicher API für über 100 Anbieter, Budget-Limits, Cost-Tracking und einem Plugin zur PII-Maskierung vor dem Versand. Weil alles über den eigenen Server läuft, ist das die datenschutzfreundlichste Variante. (GitHub)
• Cloudflare AI Gateway ist im Grundumfang kostenlos und besonders schlank einzubinden: ein Endpoint-Wechsel, dann hat man Logging, Rate-Limiting, Response-Caching und Fallback. (Doku)
• OpenRouter und Portkey sind SaaS-Lösungen für den schnellen Einstieg, mit einem Schlüssel für alle Anbieter. Portkey bringt zusätzlich semantisches Caching und ein Kosten-Dashboard mit.

Ein Wort zum Datenschutz: Bei den SaaS-Gateways läuft jede Anfrage zusätzlich über deren Server. Das ist ein weiterer Drittland-Transfer neben dem zum Modellanbieter und gehört bei sensiblen Daten geprüft. Wichtig dabei: Eine EU-Region beim Anbieter löst das nicht zuverlässig. US-Unternehmen wie Cloudflare unterliegen dem US Cloud Act, der Behörden Zugriff auf die Daten erlauben kann, egal wo die Server stehen. Wer Drittland-Zugriff strukturell ausschließen will, kommt um selbst gehostete Infrastruktur kaum herum: LiteLLM auf eigenen oder europäischen Servern, oder gleich lokale Modelle. Was BYOK ("Bring Your Own Key") in diesem Zusammenhang bedeutet, steht im Glossar.

Hebel 5: Self-Hosting, aber nur bei echtem Volumen

Der Gedanke liegt nahe: Wenn die API-Rechnung wächst, hostet man das Modell doch einfach selbst. Die Rechnung dahinter ist aber unbequem. Self-Hosting tauscht variable Token-Kosten gegen fixe GPU-Kosten, und eine gemietete High-End-GPU kostet rund um die Uhr Geld, ob ausgelastet oder nicht.

Ein konkreter Anker: Eine leistungsfähige GPU (etwa eine H100) kostet gemietet rund 2,50 bis 3,50 US-Dollar pro Stunde, im Dauerbetrieb also grob 1.800 bis 2.500 Dollar im Monat, ausgelastet oder nicht (Break-even-Analyse, tokenmix.ai). Ob sich das gegen eine API rechnet, hängt stark davon ab, welches Modell man ersetzt. Gegen ein sehr günstiges offenes Modell wie DeepSeek (Größenordnung 0,15 Dollar pro Million Input-Tokens) müsste die eigene GPU Milliarden Tokens im Monat verarbeiten, bevor sich der Fixpreis gegenüber der API lohnt. Gegen Flaggschiff-Preise (20 bis 30 Dollar pro Million Output-Tokens) kippt die Rechnung deutlich früher. Als grobe Orientierung: Wer unter etwa hundert Millionen Tokens im Monat liegt und ohnehin günstige Modelle nutzt, fährt mit der API fast immer billiger.

Sinnvoll wird Self-Hosting meist als Hybrid: kleine offene Modelle (etwa über Ollama) lokal für hochvolumige, einfache Aufgaben, das Flaggschiff per API für die harten Fälle. Der zweite, oft wichtigere Grund ist gar nicht der Preis, sondern die Datenhoheit: Lokal verarbeitete Daten verlassen das Haus nicht, was im DACH-Raum für sensible Inhalte ein starkes Argument ist. Den Einstieg dazu beschreibt der Artikel zu Ollama und lokaler KI.

Dass die API-Preise gerade massiv fallen, verschiebt diese Rechnung übrigens weiter Richtung "lieber mieten". DeepSeek etwa hat seine Preise für das offene V4-Modell aggressiv gesenkt und treibt damit einen Preiskrieg, der den Eigenbetrieb rein wirtschaftlich seltener lohnenswert macht. Übrig bleibt das Datenschutz-Argument, und das wiegt für viele schwerer.

Hebel 6: Knappe Outputs, zugeschnittene Aufgaben

Der letzte Hebel kostet nichts außer etwas Disziplin im Prompt. Weil Output teurer ist als Input, senkt jede vermiedene Zeile direkt die Rechnung.

• Output deckeln. Ein gesetztes max_tokens-Limit verhindert ausufernde Antworten. Eine Format-Vorgabe ("Antworte in höchstens drei Punkten", "nur JSON, kein Fließtext") wirkt in dieselbe Richtung.
• Reasoning nur, wo es zählt. Wo das Modell einen Aufwand für seinen Denkprozess steuern lässt, etwa der effort-Parameter bei Claude Opus 4.8, gehört der nicht pauschal auf Maximum. Für einfache Aufgaben reicht weniger, und der versteckte Thinking-Token-Verbrauch sinkt deutlich.
• Kontext schlank halten. Statt 200 Seiten in den Prompt zu kippen, nur die relevanten Abschnitte per Retrieval einspeisen. Das spart Input-Tokens bei jedem einzelnen Aufruf, und in Agenten-Loops summiert sich das schnell.

Erst messen, dann optimieren

Der wichtigste Schritt steht am Anfang, nicht am Ende: Solange niemand weiß, wofür das Budget draufgeht, optimiert man blind. Bevor du einen der sechs Hebel ansetzt, brauchst du Sichtbarkeit, idealerweise Kosten getaggt pro Team, Feature und Nutzer.

Genau hier zahlt sich ein Gateway doppelt aus, denn es ist auch die natürliche Messstelle. LiteLLM kann pro Schlüssel und Team taggen und harte Budget-Grenzen ziehen, Langfuse (Open Source) verfolgt einzelne Aufrufe quer durch verschachtelte Agenten-Workflows, und das Cloudflare-Gateway protokolliert Token und Kosten pro Aufruf kostenlos. Mit dieser Basis lässt sich eine simple Governance aufsetzen: Budgets mit Alerts, eine Modell-Policy (welcher Use-Case darf welches Modell), und die Agenten-Kosten getrennt ausweisen, damit der Vervielfacher-Effekt sichtbar wird.

Womit anfangen?

Wenn du nur eine Sache tust, dann miss zuerst. Danach bringen in der Regel Modell-Routing und Caching den schnellsten Ertrag bei geringem Aufwand, am elegantesten kombiniert über ein Gateway, das beides erledigt und gleich die Zahlen liefert. Batch ist ein müheloser Gewinn für alle Jobs, die nicht sofort fertig sein müssen. Output-Disziplin kostet nichts und wirkt überall. Und Self-Hosting ist die langfristige Option, die sich erst bei echtem Volumen oder aus Datenschutzgründen lohnt, nicht als erster Reflex.

Keiner dieser Hebel verlangt, dass du Qualität gegen Geld eintauschst. Sie sorgen nur dafür, dass du für gute Qualität nicht den Express-Kurier-Preis zahlst, wo die Postkarte gereicht hätte.