FinOps für KI-Kosten: Tokens, Caching, Routing und Budgets, die halten

KI-Rechnungen verhalten sich anders als Cloud-Rechnungen. Es gibt keinen ungenutzten Server, den man nachts abschalten kann; jede Frage eines Kunden, jedes Dokument, das ein Agent liest, und jeder Wiederholungsversuch in einer Schleife wird pro Token bezahlt, und eine einzige Funktion mit langem System-Prompt kann leise mehr kosten als der Rest der Plattform. Die gute Nachricht: Dieselbe Disziplin, die Cloud-Kosten senkt, wirkt auch hier, mit ein paar neuen Hebeln. Das ist die Reihenfolge, die ich nutze, mit dem KI-Guide dieser Website als durchgehendem Beispiel.

Dominik Heinrich

8. November 202611 Min. Lesezeit

1. Kosten pro Funktion sehen, nicht pro Anbieter

Die Rechnung eines KI-Anbieters sagt, wie viel ausgegeben wurde, nicht wofür. Jede API-Antwort enthält Token-Zahlen für Eingabe und Ausgabe, und mehr braucht es nicht: diese zusammen mit der Funktion loggen, die den Aufruf gemacht hat, dem Team, dem sie gehört, und in einem mandantenfähigen Produkt dem Kunden. Die Arbeit der FinOps Foundation zu FinOps für KI beginnt an derselben Stelle wie klassisches FinOps: erst zuordnen, dann optimieren.

Sobald dieses Log existiert, ändert ein täglicher Report pro Funktion das Gespräch. Aus "die KI-Kosten sind gestiegen" wird "die Dokument-Zusammenfassung kostet viermal so viel wie der Chat, und das meiste davon ist ein Kunde, der denselben Export immer wieder startet". Das ist ein Satz, mit dem ein Product Owner etwas anfangen kann.

javascript

// One log line per AI call: enough to report cost per feature every day
const res = await callModel(request);
log.info({
  event: "ai_usage",
  feature: "doc-summary",      // which product feature made the call
  team: "documents",
  tenant: request.tenantId,
  model: res.model,
  input_tokens: res.usage.input_tokens,
  output_tokens: res.usage.output_tokens,
  cached_tokens: res.usage.cached_tokens ?? 0,
});

Wie KI-Kosten unter Kontrolle kommen: Produktfunktionen schicken getaggte Anfragen an ein KI-Gateway mit Token-Limits, Budgets, Prompt- und Antwort-Cache und einem Router; der Router schickt einfache Anfragen an ein kleines Modell, schwierige an ein grosses, nicht dringende Arbeit an Batch-APIs und gleichmässiges Volumen an ein selbst betriebenes Modell; der Verbrauch fliesst in ein Kosten-Dashboard pro Funktion mit Budget-Alerts und einem Tagesreport im Team-Chat. — KI-Kosten im Griff: jede Anfrage taggen, im Gateway cachen und routen, batchen, was warten kann, täglich pro Funktion berichten.

2. Wissen, wofür man in einer Token-Rechnung zahlt

Vier Dinge treiben die Rechnung. Eingabe-Tokens: alles, was gesendet wird, inklusive System-Prompt, abgerufener Dokumente und der ganzen Gesprächshistorie, und zwar bei jedem Zug erneut. Ausgabe-Tokens: meist deutlich teurer als die Eingabe. Reasoning- oder "Thinking"-Tokens: Bei Modellen, die vor der Antwort nachdenken, werden auch diese abgerechnet; die Preisliste für Gemini von Google weist den Ausgabepreis inklusive Thinking-Tokens aus. Und gecachte Eingabe, die viel günstiger ist als frische, wenn der Anbieter sie wiederverwenden kann.

Der grösste stille Kostenblock ist meist die Historie. Ein Chat, der zwanzig frühere Züge erneut schickt, bezahlt sie zwanzigmal. Der Guide auf dieser Website behält die letzten zwölf Züge, kürzt einzelne Nachrichten bei 1'500 Zeichen und begrenzt die Antwortlänge; bei Gemini setzt er ausserdem eine niedrige Thinking-Stufe, das ist schnell und für einen Website-Guide genug.

Tipp aus der Praxis

Pro Funktion eine maximale Ausgabelänge festlegen. Eine Chat-Antwort und eine Vertragszusammenfassung brauchen sehr unterschiedliche Grenzen, und eine unbegrenzte Ausgabe ist der Weg, wie ein schlechter Prompt zu einem teuren Nachmittag wird.

3. Cachen, was sich wiederholt

Der meiste KI-Verkehr wiederholt sich stärker, als es scheint. Prompt-Caching beim Anbieter belohnt einen stabilen Anfang: den langen, unveränderlichen Teil zuerst, Wissensbasis oder Anweisungen, den anfragespezifischen Teil danach. Anthropic rechnet Cache-Lesezugriffe zu einem Bruchteil des normalen Eingabepreises ab, bei den meisten Modellen zu einem Zehntel; OpenAI cacht automatisch und gibt auf wiederverwendete Eingabe-Tokens bis zu 95 Prozent Rabatt; Gemini hat implizites Caching. Nichts davon funktioniert, wenn ganz oben im Prompt ein Zeitstempel oder eine zufällige ID steht.

Der zweite Cache ist Ihr eigener. Viele Besucher stellen dieselbe erste Frage, also hält der Guide auf dieser Website Antworten auf erste Fragen sechs Stunden lang vor und beantwortet seine vorgeschlagenen Einstiegsfragen aus vorbereiteten Antworten, die gar keinen API-Aufruf brauchen. Diese Antworten erscheinen sofort und kosten pro Besuch nichts.

4. Routen: das kleinste Modell, das die Aufgabe schafft

Nicht jede Anfrage braucht das beste Modell. Ein Ticket klassifizieren, ein Datum extrahieren oder eine Frage aus einer kurzen FAQ beantworten geht mit einem kleinen, schnellen Modell zu einem Bruchteil des Preises; das Durchdenken eines langen Vertrags oder die Planung einer mehrstufigen Agenten-Aufgabe braucht vielleicht das grosse. Ein Router vor den Anbietern entscheidet pro Anfrage, nach Funktion, nach Länge oder nach einer kurzen Klassifikation, und eskaliert nur, wenn das kleine Modell nicht gut genug ist.

Mit Daten entscheiden, nicht aus dem Bauch: einen kleinen Satz echter Fragen mit den erwarteten Antworten führen, gegen die infrage kommenden Modelle laufen lassen und die Qualität pro Euro vergleichen. Der Guide auf dieser Website läuft auf einem schnellen Modell mit einem noch leichteren als Fallback; ist das Tageskontingent des kostenlosen Tarifs für das Hauptmodell aufgebraucht, antwortet das leichtere weiter, statt dass der Chat verstummt.

5. Alles batchen, was warten kann

Nächtliche Dokumentverarbeitung, das Neu-Taggen eines Katalogs, die Auswertung der Support-Antworten der letzten Woche: Nichts davon braucht eine Antwort in zwei Sekunden. Batch-APIs nehmen eine Datei mit Anfragen entgegen und liefern die Ergebnisse innerhalb eines Tages, mit Rabatt. Die Batch API von OpenAI nennt 50 Prozent tiefere Kosten bei 24 Stunden Bearbeitungszeit, die Gemini Batch API von Google verarbeitet Anfragen zu 50 Prozent des Standardpreises mit 24 Stunden als Ziel, und auch Anthropic bietet eine rabattierte Batch API.

Das Muster ist einfach: Alles, worauf kein Nutzer wartet, kommt in eine Warteschlange, die Warteschlange wird nach Zeitplan in einen Batch-Job geleert, und die Ergebnisse landen dort, wo der interaktive Weg sie abgelegt hätte. Für eine nächtliche Pipeline halbiert das allein ungefähr die KI-Zeile auf der Rechnung.

6. Limits und Budgets an einem Ort

Die teuren Vorfälle bei KI sind Schleifen: ein Agent, der immer wieder ein Tool aufruft, ein Skript, das ohne Backoff wiederholt, ein Bot, der einen öffentlichen Chat flutet. Ein Gateway zwischen Apps und Anbieter stellen und ihm harte Grenzen geben: Tokens pro Minute und ein Kontingent pro Schlüssel oder pro Funktion. In Azure API Management ist das die Policy llm-token-limit, und llm-emit-token-metric schickt den Token-Verbrauch mit eigenen Dimensionen an Azure Monitor. Die Schlüssel bleiben im Gateway, nie in den Apps.

Drumherum die klassischen FinOps-Kontrollen: Budgets mit Prognose-Alerts im Kostenmanagement Ihrer Cloud, Ausgabelimits beim Anbieter, wo es sie gibt, und derselbe kurze tägliche Kostenreport im Team-Chat, der auch bei Cloud-Kosten funktioniert. Öffentliche Endpunkte brauchen einen eigenen Schutz: Der Guide auf dieser Website erlaubt 20 Fragen pro Besucher in zehn Minuten, was kein echter Besucher erreicht und jeder Scraper.

xml

<!-- Azure API Management, inbound: hard limits per key, usage per feature -->
<llm-token-limit counter-key="@(context.Subscription.Id)"
                 tokens-per-minute="20000"
                 token-quota="2000000" token-quota-period="Monthly"
                 estimate-prompt-tokens="false" />
<llm-emit-token-metric namespace="ai-usage">
  <dimension name="Feature" value="@(context.Request.Headers.GetValueOrDefault(&quot;x-feature&quot;, &quot;unknown&quot;))" />
  <dimension name="Subscription ID" />
</llm-emit-token-metric>

7. Wissen, wann sich Selbstbetrieb lohnt

Ab einem gewissen Volumen verliert ein Preis pro Token gegen eine eigene Maschine: gleichmässiger, planbarer Verkehr, ein Modell, das als Open-Weight-Version gut genug ist, und oft Daten, die das eigene Netz ohnehin nicht verlassen sollen. Unterhalb dieses Volumens gewinnt die API bei den Kosten, beim Tempo von Änderungen und bei den Leuten, die man für den Betrieb nicht braucht. Der ehrliche Vergleich enthält Strom, Betrieb und die Zeit, um Modelle aktuell zu halten, nicht nur die Hardware.

Das Tool unten liefert die erste Zahl für diese Entscheidung: Modellgrösse und Anzahl Nutzer wählen, und es zeigt den nötigen Speicher und die kleinste Maschine, die ihn bietet. Mein Artikel dazu, welchen Server man für ein lokales LLM kauft, geht den Rest durch.

Interaktiv

Welches Gerät für ein lokales LLM?

Wählen Sie ein Modell und wie Sie es nutzen. Sie sehen, wie viel Speicher es braucht, und die kleinsten Geräte, die es tragen, vom Mini-PC bis zum GPU-Server.

Ausgangspunkt

Modellgrösse (Milliarden Parameter)70B

Mixture-of-Experts-Modell

Genauigkeit

Wer es nutzt

≈ 42 GB

Speicher nötig

128 GB

Speicher im kleinsten passenden Setup

Kleinstes Setup, das passt

Mini-PC mit AMD Ryzen AI Max+ 395

Der günstigste Weg zu viel Speicher: bis 128 GB 256-Bit-LPDDR5x-8000 (rund 256 GB/s), geteilt mit der Radeon-8060S-Grafik, 45 bis 120 W. Läuft mit llama.cpp, LM Studio und Ollama.

≤ 7 Tokens/s, Obergrenze für eine Person auf diesem Gerät

Alle Optionen, grob von kleiner zu grosser Investition

PC mit GeForce RTX 5090Zu klein
Schnell für Modelle, die in 32 GB passen. Eine Consumer-Karte: laut, heiss, ohne ECC-Speicher, 575 W Grafikleistung.
Mini-PC mit AMD Ryzen AI Max+ 395Passt · 128 GB
Der günstigste Weg zu viel Speicher: bis 128 GB 256-Bit-LPDDR5x-8000 (rund 256 GB/s), geteilt mit der Radeon-8060S-Grafik, 45 bis 120 W. Läuft mit llama.cpp, LM Studio und Ollama.
≤ 7 Tokens/s, Obergrenze für eine Person auf diesem Gerät
NVIDIA DGX SparkPasst · 128 GB
GB10-Superchip mit 128 GB Unified Memory und vollem CUDA-Stack. 273 GB/s bremsen grosse dichte Modelle; stark bei Mixture-of-Experts-Modellen, Entwicklung und Fine-Tuning-Experimenten.
≤ 8 Tokens/s, Obergrenze für eine Person auf diesem Gerät
Mac Studio M5 MaxPasst · 128 GB
Bis 128 GB Unified Memory mit 460 bis 614 GB/s, und leise. MLX, llama.cpp, Ollama und LM Studio laufen gut darauf.
≤ 13–18 Tokens/s, Obergrenze für eine Person auf diesem Gerät
Workstation oder Server mit RTX PRO 6000 Blackwell (1–2)Passt · 96 GB
96 GB ECC-GDDR7 mit 1'792 GB/s und 600 W pro Karte: am schnellsten pro Person. Eine oder zwei davon mit vLLM ergeben einen Server fürs Team.
≤ 51 Tokens/s, Obergrenze für eine Person auf diesem Gerät
Rack-Server mit 2× L40SPasst · 96 GB
Zwei Rechenzentrums-GPUs mit je 48 GB und vLLM davor: das andere Team-Setup aus dem Artikel für 30B- bis 70B-Modelle.
Mac Studio M5 UltraPasst · 512 GB
Bis 512 GB Unified Memory mit 1,2 TB/s, maximal 480 W Dauerleistung: der einfachste Weg, ein sehr grosses Modell auf den Schreibtisch zu bringen.
≤ 34 Tokens/s, Obergrenze für eine Person auf diesem Gerät
NVIDIA DGX Station (GB300)Passt · 748 GB
Ein Gerät neben dem Schreibtisch mit GB300-Superchip und 748 GB kohärentem Speicher, davon 252 GB HBM3e.
GPU-Server mit H200 (bis 8)Passt · 141 GB
141 GB HBM3e mit 4,8 TB/s und bis 700 W pro GPU; acht davon ergeben über ein Terabyte. vLLM verteilt das Modell auf die GPUs.
NVIDIA DGX B200Passt · 1'440 GB
Acht B200-GPUs mit zusammen 1'440 GB HBM3e und 64 TB/s, rund 14,3 kW für das System. Strom, Kühlung und Betrieb werden zum grösseren Projekt.

Planungswert, kein Benchmark. Speicher = Parameter × Bytes pro Parameter, plus rund 20 % für den KV-Cache (lange Dokumente oder wenige Personen: +50 %, ein Team: +100 %, grobe Faktoren). Geräte mit Unified Memory behalten rund 10 % für das System. Die Tempo-Grenze ist Speicherbandbreite geteilt durch die pro Token gelesenen Gewichte (bei Mixture-of-Experts nur die aktiven); echte Werte liegen darunter. Gerätedaten aus den Datenblättern der Hersteller, wie im Artikel verlinkt (Ryzen-Bandbreite berechnet aus AMDs 256-Bit-LPDDR5x-8000). Vor dem Kauf: Modell und Prompts zwei Wochen auf gemieteten GPUs testen.

Hilfe bei der Hardware-Wahl Alle Rechner und Checklisten

Fazit
KI-FinOps ist FinOps mit Tokens: jeden Aufruf zuordnen, weniger senden, zum kleinsten passenden Modell routen, batchen, was warten kann, und alles in einem Gateway begrenzen.

Echte Projekte dazu

Selbst ausprobieren

Das für Ihr Unternehmen? Sprechen wir mail@dominikheinrich.ch

Quellen und offizielle Leitfäden