The Playbook
ai-pricing

AI FinOps: Wie du als CPTO den Token-Wahnsinn einfängst — Modelle, Tools, Metriken

Von

ai-finops ai-pricing ai-optimization cpto token-economics litellm cloudzero finout torii

Stell dir die Szene vor: Der CFO eines DACH-Mittelständlers sitzt im Büro des CPTO, hält die Anthropic-Rechnung des letzten Monats hoch. Sechsstellig. „Sag mal, wie viel davon ist Produkt und wie viel ist Engineering, das mit Claude rumspielt?” Antwort: keine. Nicht ungefähr — gar nicht. Keine Tags, keine Cost-Center-Allocation, keine Per-Customer-Attribution. Ein API-Key, der seit Monaten durch alle möglichen Subsysteme fließt.

Diese Szene ist 2026 kein Einzelfall. Sie ist der Punkt, an dem AI-Strategie entweder operativ wird oder als Marketing-Hülle endet. Wer als CPTO den Token-Verbrauch nicht auf Kunden-Ebene allokieren kann, hält am Quartalsende eine Cloud-Rechnung in der Hand, die er weder einem Produkt noch einem Kunden zuordnen kann — und damit auch nicht ins Pricing zurückrechnen.

In DACH-Mittelstands-CPTO-Runden dominiert seit Monaten ein Thema: AI-Kosten unter Kontrolle bringen, bevor die Margen aufgefressen werden. Niemand hat das früh im Griff. Alle holen jetzt nach.

Der ungemütliche Kontext: Warum AI-FinOps so schmerzhaft ist

Im klassischen SaaS-FinOps weißt du, was eine VM kostet, weil sie eine Rechnungs-ID hat. AWS taggt dir das, du allokierst nach Produkt, fertig. AI-Kosten verhalten sich anders. Sie sind:

  • Pro Request volatil: Ein Customer-Service-Bot, der heute 80 Token braucht, braucht morgen 8000, weil ein Kunde plötzlich seine ganze Vertragshistorie reinkippt.
  • Cross-Cutting: Derselbe API-Key wird in Production, Staging, im Engineering-Chat-Tool und vom Sales-Team für Demo-Skripte genutzt — wer das nicht früh trennt, allokiert nichts mehr sauber.
  • Modell-abhängig: GPT-4o kostet 2,50 USD pro Mio. Input-Tokens, Claude Sonnet 4.7 kostet 3 USD, Haiku 4.5 kostet 0,25 USD. Falscher Model-Pick = 10-12x Mehrkosten ohne Mehrwert.
  • Latenz-verzerrt: Frontier-Modelle sind langsam, manche Workflows brechen ein, also baut jemand Caching ein, das vielleicht 30% der Calls erspart — aber misst keiner.

Wer das nicht beobachtet, sieht in der Monatsrechnung nur das Endprodukt — und kann es nicht zurückrechnen.

So könnte es typischerweise laufen: Ein PE-finanziertes DACH-Mittelstandsunternehmen baut ein AI-Feature, das einkommende Tickets automatisch klassifiziert. Drei Monate Produktion. Cost-per-Ticket liegt bei 0,42 EUR. Der Kunde zahlt 0,15 EUR Subscription-Anteil pro Ticket. Verlust bei jedem Ticket — und niemand merkt es, weil niemand die Token-Kosten an die Kunden-ID gehängt hat.

Das ist 2026 in einem Großteil der B2B-SaaS-Unternehmen der Status quo. Nicht weil die Leute dumm sind, sondern weil das Tooling neu ist und niemand vorher Erfahrung hatte, wie schnell sich variable Inferenzkosten in eine fixe Subscription fressen.

Modell-Routing: Wann frontier, wann small, wann lokal

Die erste FinOps-Hebel-Frage ist nicht Tooling. Es ist Modell-Wahl pro Use-Case. Frontier-Modelle (Claude Opus 4.7, GPT-5, Gemini 2.5 Pro) sind 10-20x teurer als ihre kleineren Geschwister. Wer alles per Default auf Frontier läuft, verbrennt 80% der Kosten ohne Qualitätsgewinn.

Eine grobe Heuristik, die sich in DACH-Setups bewährt:

Use-CaseEmpfohlenes ModellTierCost/Mio Token (Input)Cost/Mio Token (Output)
Embedding-Generierung für RAGEmbedding-spezifisch (text-embedding-3-small)Klein0,02 USDn/a
Klassifikation (Ticket → Kategorie)Haiku 4.5 / GPT-4o miniKlein0,25 USD1,25 USD
Strukturierte Extraktion (JSON aus PDF)Sonnet 4.6 / GPT-4oMittel3 USD15 USD
Code-Generierung / Agentic WorkflowsOpus 4.7 / GPT-5Frontier15 USD75 USD
Customer-facing Chatbot (Latenz-kritisch)Haiku 4.5 oder lokales Llama 3Klein/lokal0,25 / ~0 USD1,25 / ~0 USD
Sales-Demo (Wow-Effekt-driven)Opus 4.7Frontier15 USD75 USD

Lokale Modelle (Llama 3.3, Gemma, Mistral via Ollama oder vLLM) sind 2026 endlich produktiv brauchbar geworden — vorausgesetzt, du hast einen Use-Case, der Quantisierung verträgt und Latenz unter 500ms braucht.

So könnte ein realistischer Business-Case aussehen: Interne Reporting-Workflows mit konstantem Volumen wandern auf self-hosted Llama 3.3 70B. Hardware-Investment ca. 30-40.000 EUR einmalig. Amortisation über eingesparte API-Calls in 4-8 Wochen. Wenn die Volumina-Annahme stimmt, ist das die schönste CFO-Konversation des Quartals.

Die Falle: Lokal lohnt sich nur, wenn du konstante Volumen hast. Burst-Traffic in lokale Inferenz reinpressen ist die schmerzhafteste Variante, einen GPU-Cluster zu überlasten. Für Customer-facing-Features mit unbekannten Volumen-Spitzen bleibt Cloud-API der richtige Default.

Tooling: Was funktioniert, was ist Marketing-Hülle

Das Tooling-Feld hat sich 2026 grob in zwei Lager gespalten: LLM-Gateways für Routing und Observability, und AI-FinOps-Plattformen für Cost-Attribution und Forecasting.

LLM-Gateways

LiteLLM ist 2026 der Open-Source-Gewinner. Erfahrungswerte aus DACH-Mittelstands-Setups: 2-3 Tage von „läuft im Docker” bis „läuft in Produktion mit Cost-Tracking pro Customer-ID”. Vorteile: Modell-Provider sind austauschbar (Anthropic, OpenAI, Bedrock, lokale Models alle hinter einer OpenAI-kompatiblen API), Tags pro Request für Cost-Center-Allocation, Budgets pro Team/Key. Nachteile: Eigenes Hosting, Latenz-Overhead (10-30ms), eigenes Caching-Layer notwendig.

Portkey ist die Managed-Variante mit besserer UI und mehr Provider-Coverage. 19 USD pro Monat für die kleine Plan, skaliert nach Volume. Wenn dein Team kein DevOps-Team hat, ist das der schnellere Pfad.

Helicone und Langfuse spielen eher im Observability-Bereich — sie sehen, was passiert, machen aber keine Routing-Entscheidungen für dich. Gute Ergänzung, nicht Alternative.

AI-FinOps-Plattformen

CloudZero ist der enterprise-orientierte Player. Wer schon AWS-Cost-Attribution per Tagging laufen hat, kann seine AI-Kosten nahtlos dazu legen. Stärke: Unit-Economics-Reports (Cost per Customer, Cost per Feature) out-of-the-box. Schwäche: Nicht billig — sechsstellig pro Jahr ab mittlerer Größe.

Finout ist die direkte CloudZero-Alternative aus Israel, vermutlich 30-40% günstiger, bei vergleichbarer Funktionalität.

Torii ist eigentlich SaaS-Management (welche Tools haben deine Mitarbeiter gekauft), hat aber AI-Tool-Discovery erstaunlich gut hingekriegt. Wer wissen will, wie viele Cursor-Lizenzen tatsächlich aktiv genutzt werden vs. wie viele Engineering bezahlt: Torii zeigt das in zehn Minuten. Erfahrungswert: das deckt in den meisten Setups einen vierstelligen monatlichen Posten an inaktiven Lizenzen auf.

Was du wirklich brauchst — Minimum-Viable-FinOps-Stack

Wenn du heute anfangen willst und kein Budget für Enterprise-Tooling hast:

  1. LiteLLM self-hosted als zentraler Gateway, alle Calls gehen dadurch
  2. Tag jeden Call mit customer_id, feature_name, environment (prod/staging/dev)
  3. Wöchentlicher Report per einfachem Python-Skript auf die LiteLLM-Postgres-DB
  4. Budget-Alarm ab 10% Abweichung vom Vormonat per Slack-Webhook

Das ist 1-2 Wochen Engineering-Aufwand. Es ersetzt kein CloudZero, aber es macht den Unterschied zwischen „wir wissen nichts” und „wir sehen das Wichtigste”. Der Anthropic-CFO-Moment aus der Eröffnungsszene wäre damit nicht passiert.

Die Metriken, die wirklich zählen

Tooling allein bringt nichts, wenn niemand auf die Zahlen schaut. Die Metriken, die ein CPTO wöchentlich reviewen sollte:

Cost per Customer (CpC) — Tokens × Token-Preis, allokiert per Customer-ID. Sortiert nach Verbrauch. Top-20 wird untersucht. Klassisches Muster: 2-4 Customers verursachen 30-50% der gesamten AI-Kosten, weil ein Edge-Case in deren Daten-Migration einen Loop produziert oder eine spezifische Integration ausartet. Ohne CpC nie entdeckt. Konsequenz: nachträglich Volume-Tier in den Vertrag.

Cost per Developer (CpD) — Cursor, Claude Code, Copilot, alle internen Tools zusammengerechnet. Aktueller Branchen-Benchmark: 80-150 EUR pro Developer pro Monat. Wer drüberliegt, sollte sich fragen warum. Häufiges Muster: Multi-Subscriptions („Cursor für mich, Claude Code als Backup, Copilot weil der Arbeitgeber das früher bezahlt hat”). Cleanup bringt typisch 30-40% Reduktion bei null Produktivitätsverlust.

Cost per Workflow — Pro automatisiertem Business-Workflow, was kostet die Ende-zu-Ende-Ausführung. Beispiel: „Rechnungs-Eingangs-Erkennung” = 0,03 EUR pro Rechnung. Kunde zahlt 0,10 EUR im Subscription-Anteil. Marge: 70%. Wenn diese Marge unter 50% rutscht, wird der Workflow überarbeitet (kleineres Modell, Caching, anderer Prompt).

Cost per Feature — Aggregiert über alle Customers, was kostet ein Feature pro Monat. Hilft beim AI-Pricing-Playbook (siehe Pricing von AI-Funktionen für SaaS), weil du sonst kein Per-Seat-Tier definieren kannst.

Hit-Rate auf Caching-Layer — Unter 30% Hit-Rate spart das Caching kaum noch Cloud-Calls und trägt seinen Namen zu Unrecht. Realistischer Zielwert auf typischen Customer-Service-Workflows: 50-60%. Das spart pro Monat ungefähr den Preis eines Junior-Engineers.

DACH-Realität: Wo Mittelstand wirklich steht

Was sich aus CPTO-Gesprächen der letzten sechs Monate als Muster herauskristallisiert:

Die Vorreiter (geschätzt 5-10% des DACH-B2B-Mittelstands) haben AI-FinOps als KPI im Engineering-OKR. Cost-per-Active-Customer oder Cost-per-Active-Employee als interne Steuerungsgröße. Klar zugeordnete Verantwortung, wöchentliches Reporting, LLM-Gateway als Pflicht-Layer.

Die Spezialfälle mit hohem Volumen (Process-Mining, Search, Embedded-Analytics) laufen zunehmend komplett auf eigenem Inference-Stack. Custom-Training auf historischen Daten, lokale Inferenz, klassisches Build-statt-Buy auf der AI-Seite — funktioniert nur, weil das Volumen es trägt.

Das gesunde Mittelfeld baut gerade auf: LLM-Gateway, Cost-Attribution-Tool, lokale Modelle für interne Workloads. Cost per Customer wandert wöchentlich aufs CTO-Dashboard. Nicht ideal, aber weiter als 80% der Branche.

Die Nachzügler — und das ist die Mehrheit — haben null AI-FinOps, bis die Quartalsrechnung den CFO erschreckt. Dann Damage-Control mit Portkey + Slack-Alerts. Klassischer Reaktivansatz. Wenn du den Punkt erreichst, bist du schon ein Vierteljahr zu spät.

Meine Perspektive 🎯

  • Ein LLM-Gateway gehört 2026 zur AI-Basis-Architektur. Direkt-Calls aus Application Code gegen Anthropic/OpenAI sind Anti-Pattern: kein Provider-Swap, keine Messung, keine Resilience.
  • Modell-Routing ist 80% der Optimierung. Das richtige Modell pro Use-Case einzusetzen spart mehr als jedes Caching-Layer. Default-on-Frontier ist die teuerste Entscheidung im AI-Stack.
  • Lokal lohnt sich bei konstantem Volumen. Self-hosted Llama für interne Workloads mit hohem konstantem Verbrauch amortisiert sich in Wochen. Für customer-facing Burst-Workloads bleibt Cloud-API der richtige Default.
  • Cost per Customer ist die belastbarste Metrik. Wer CpC nicht aufschlüsseln kann, fliegt beim Pricing blind und merkt erst am Quartalsende, welche Kunden Geld kosten.
  • Die Tools für AI-FinOps sind alle da. Was meistens fehlt, ist die Disziplin, wöchentlich draufzuschauen und Entscheidungen zu treffen.

Was bedeutet das für den CPTO?

Architektur: Setze einen LLM-Gateway als Pflicht-Layer durch — kein Application-Code spricht direkt mit Provider-APIs. LiteLLM für Open-Source-Pfad, Portkey für Managed. Caching-Layer (Redis oder eingebaut) für deterministische Calls. Trenne Production-Keys hart von Dev/Test-Keys, sonst kannst du Engineering-Spielwiese nicht von Kunden-Last unterscheiden.

Pricing: Ohne Cost-per-Customer kein AI-Feature-Pricing. Pflicht-Tagging jeder Inference-Call mit customer_id. Per-Seat-Tier nur dann definieren, wenn du die durchschnittliche AI-Last pro Seat mindestens drei Monate beobachtet hast. Volume-Tiers (>1 Mio Calls/Monat) in den Vertrag, sonst zahlt ein Power-User die Cloud-Rechnung für deine ganze Customer-Base.

Team: AI-FinOps ist ein 0,2-FTE-Job, kein eigener Mitarbeiter — aber er muss klar zugeordnet sein. Typischerweise beim Lead-DevOps-Engineer. Bei größeren Unternehmen wandert das in die FinOps-Funktion (wo bereits AWS-FinOps existiert). Wer keinen FinOps-Lead hat, lässt den CPTO die Reports lesen — bei kleinem Stack akzeptabel, bei wachsendem Stack nicht skalierbar. Cursor- oder Claude-Code-Subscriptions managed der Engineering-Lead, nicht Procurement.

Failure-Modes:

  • Engineering-Account hat unbegrenzten API-Key → einer baut Side-Project, monatliche Rechnung verdoppelt sich. Fix: Pro-Key-Budget mit Hard-Limit, nicht Soft-Warning.
  • Customer-Service-Bot in Loop, weil Edge-Case nicht abgefangen → 50.000 EUR an einem Wochenende verbrannt. Fix: Per-Customer-Rate-Limit auf Gateway-Ebene.
  • Default-Modell ist Opus 4.7, weil Engineer „bessere Qualität” wollte → 10x Kosten gegenüber Sonnet, ohne Qualitätstest. Fix: Model-Approval-Process im Pull-Request-Template.
  • Caching deaktiviert in Production, weil Engineering das in Staging vergessen hat zu testen → Hit-Rate sinkt von 60% auf 0%. Fix: Caching-Hit-Rate als CloudWatch-Alarm.

Fazit: Der AI-FinOps-Operator-Stack 2026

Wenn du heute Montag anfangen willst und keinen Stack hast:

  1. Woche 1: LiteLLM lokal aufsetzen, einen Use-Case migrieren, Tagging testen
  2. Woche 2: Alle Produktions-Calls über Gateway routen, Customer-ID-Tagging Pflicht
  3. Woche 3: Wöchentlicher Cost-per-Customer-Report ans Engineering-Lead
  4. Woche 4: Budget-Alarme einrichten, Hard-Limits pro Key
  5. Monat 2: Modell-Routing pro Use-Case durchgehen, Default auf Sonnet/Haiku setzen
  6. Monat 3: Lokales Modell evaluieren für High-Volume-Workloads, Build-vs-Buy-Entscheidung
  7. Monat 4: CloudZero/Finout evaluieren, wenn AI-Kosten >50.000 EUR/Monat
  8. Monat 6: Cost-per-Customer im Steering-Dashboard, Pricing-Review

Das ist kein Mega-Projekt. Das ist Operating Discipline. Und es ist 2026 unverhandelbar — der CFO wartet sonst nicht weitere sechs Monate.

Weiterführend

Verwandte Insights mit CPTO-Brille:

Quellen