D2. Kosten und FinOps für KI
KI verursacht Kosten an vielen Stellen zugleich, von der Datenaufbereitung über Training und Betrieb bis zum Personal. Die Besonderheit gegenüber klassischer Software ist die Inferenz, der produktive Modellbetrieb: Jede einzelne Anfrage kostet Rechenleistung, die laufenden Kosten wachsen deshalb mit der Nutzung. Ein FinOps-Ansatz überträgt erprobte Prinzipien des Cloud-Kostenmanagements auf KI: Ausgaben sichtbar machen, Verantwortung zuordnen, Kosten fortlaufend mit dem Geschäftsnutzen abgleichen.
Was dieses Kapitel liefert: die laufende Kostensteuerung für den Budgetrahmen aus Kapitel B1. Zuerst stellt es die acht Kostenfelder vor, in denen KI-Kosten entstehen. Darauf bauen zwei Vorlagen auf: das Kostenmodell je Anwendungsfall und das Unit-Economics-Worksheet für die Wirtschaftlichkeit pro Anfrage. Danach folgen die Kostenhebel zum Senken der Kosten und die FinOps-Praxis, die die Kosten dauerhaft im Griff behält.
Die acht Kostenfelder
Jeder KI-Anwendungsfall verursacht Kosten in denselben acht Feldern. Wer alle acht kennt, übersieht keine versteckten Kostenblöcke und kann Anwendungsfälle sauber vergleichen:
| Kostenfeld | Was dazugehört | Wovon die Höhe abhängt |
|---|---|---|
| Datenakquise und -aufbereitung | Daten beschaffen, bereinigen, kennzeichnen und rechtlich klären | Datenvolumen, geforderte Qualität |
| Entwicklung / Training | Experimente, Modelltraining, Fine-Tuning und Evaluierung bis zur einsatzreifen Lösung | Zahl der Experimente, GPU-Stunden |
| Inferenz / API | der produktive Betrieb: Rechenleistung oder API-Gebühren für jede einzelne Anfrage | Anfragen × Tokens |
| Infrastruktur / Speicher | Rechenkapazität, Datenspeicher, Netzwerk und Umgebungen für Entwicklung und Betrieb | Datenmenge, geforderte Verfügbarkeit |
| Lizenzen / Plattform | Software- und Modell-Lizenzen, Plattform- und Werkzeug-Abonnements | Zahl der Nutzer:innen, gebuchte Module |
| Betrieb / Monitoring | Deployment, Überwachung, Fehlerbehebung und regelmäßiges Nachtraining | Komplexität der Lösung, zugesagte Servicelevel (SLA) |
| Sicherheit / Compliance | Schutzmaßnahmen, Audits und Dokumentationspflichten | Schutzbedarf, Zahl der Audits |
| Personal | interne Rollen und externe Unterstützung über alle Phasen hinweg | benötigte Rollen, Aufwand |
Ein Feld fällt aus der Reihe: Die Inferenz wächst als einziges Feld direkt mit der Nutzung, denn jede Anfrage kostet erneut. Ein erfolgreicher Anwendungsfall wird dadurch teurer, nicht günstiger. Genau deshalb reicht eine einmalige Budgetschätzung bei KI nicht aus.
Vorlage: Kostenmodell je Anwendungsfall
Für jeden Anwendungsfall werden alle acht Kostenfelder geschätzt, getrennt nach einmalig und laufend. Die Spalte Kostentreiber benennt, wovon die Höhe abhängt; ändert sich der Umfang, lässt sich die Schätzung damit nachvollziehbar anpassen. Wichtig: Ein leeres Feld bedeutet ungeprüfte Kosten, nicht null Kosten.
| Kostenfeld | Einmalig | Laufend pro Jahr | Kostentreiber |
|---|---|---|---|
| Datenakquise und -aufbereitung | Volumen, Qualität | ||
| Entwicklung / Training | Experimente, GPU-Stunden | ||
| Inferenz / API | Anfragen × Tokens | ||
| Infrastruktur / Speicher | Datenmenge, Verfügbarkeit | ||
| Lizenzen / Plattform | Nutzer:innen, Module | ||
| Betrieb / Monitoring | Komplexität, SLA | ||
| Sicherheit / Compliance | Schutzbedarf, Audits | ||
| Personal | Rollen, Aufwand | ||
| Summe |
Vorlage: Unit-Economics-Worksheet
Die Gesamtkosten allein zeigen nicht, ob sich ein Anwendungsfall rechnet. Das Worksheet rechnet die Wirtschaftlichkeit deshalb auf die einzelne Anfrage herunter; so wird sichtbar, ob der Anwendungsfall mit steigender Nutzung besser oder schlechter wird. Dieselben Einheitenkennzahlen dienen später der laufenden Steuerung: Kosten pro Anfrage, pro Trainingslauf und pro Nutzer:in; besonders aussagekräftig sind Kosten je Ergebnisqualität (z. B. pro Prozentpunkt Genauigkeit).
| Größe | Wert | Berechnung |
|---|---|---|
| Kosten pro Anfrage | laufende Kosten ÷ Anfragen | |
| Nutzen pro Anfrage | eingesparte Zeit und Kosten oder Mehrumsatz | |
| Deckungsbeitrag pro Anfrage | Nutzen minus Kosten | |
| Break-even-Volumen | Einmalkosten ÷ Deckungsbeitrag | |
| Skalierungseffekt | Kostenentwicklung bei 2-, 5- und 10-fachem Volumen |
Beispielrechnung für den Anwendungsfall „Antwortvorschläge Kundenservice" (fortgeführt aus Kapitel B2): 200.000 Anfragen pro Jahr, laufende Kosten von 30.000 Euro pro Jahr, Einmalkosten von 60.000 Euro.
| Größe | Wert | Rechenweg |
|---|---|---|
| Kosten pro Anfrage | 0,15 Euro | 30.000 Euro ÷ 200.000 Anfragen |
| Nutzen pro Anfrage | 1,00 Euro | rund 1,5 Minuten gesparte Bearbeitungszeit |
| Deckungsbeitrag pro Anfrage | 0,85 Euro | 1,00 Euro minus 0,15 Euro |
| Break-even-Volumen | rund 71.000 Anfragen | 60.000 Euro ÷ 0,85 Euro; bei diesem Volumen nach gut vier Monaten erreicht |
| Skalierungseffekt | Deckungsbeitrag bleibt positiv | bei steigendem Volumen sinkt der Fixkostenanteil je Anfrage, Caching senkt die Inferenzkosten zusätzlich |
Der Fall trägt sich also ab rund 71.000 Anfragen und wird mit steigender Nutzung wirtschaftlicher. Fiele der Deckungsbeitrag negativ aus, gälte die umgekehrte Logik des folgenden Warnsignals.
Warnsignal: Wenn der Deckungsbeitrag pro Anfrage negativ ist, skaliert der Anwendungsfall in die Verlustzone. Höhere Nutzung verschlimmert das Problem, statt es zu lösen.
Kostenhebel
Fällt das Worksheet zu teuer aus, muss der Anwendungsfall nicht sterben. Die folgenden Hebel senken die Kosten, ohne den Nutzen zu beschneiden; die rechte Spalte zeigt, auf welches Kostenfeld ein Hebel vor allem wirkt. Kostenoptimierung ist dabei ein laufender Prozess, kein einmaliges Projekt (Begriffe wie RAG in Kapitel A2).
| Hebel | So wirkt er | Wirkt vor allem auf |
|---|---|---|
| Caching | bereits berechnete Antworten wiederverwenden statt neu erzeugen | Inferenz |
| Batching | viele Anfragen bündeln und gemeinsam verarbeiten | Inferenz |
| Prompt- und Kontextoptimierung | kürzere Eingaben und schlankerer Kontext senken die Token-Menge je Anfrage | Inferenz |
| RAG | belegte Antworten reduzieren teure Fehlantworten und Nacharbeit | Inferenz |
| Kompaktere Modelle | Quantisierung speichert Modellgewichte mit geringerer Zahlengenauigkeit, Distillation lässt ein kleineres Modell das Verhalten eines großen nachlernen; beides macht Modelle kleiner und schneller | Inferenz, Infrastruktur |
| Effizientere Trainingsverfahren | gezielter experimentieren, bereits trainierte Modelle wiederverwenden | Entwicklung / Training |
| Günstige Rechenzeitfenster | Off-Peak-Training in Zeiten geringer Auslastung; Spot-Instanzen sind kurzfristig verfügbare, deutlich günstigere Cloud-Kapazität, die der Anbieter bei Bedarf zurückzieht, geeignet für unterbrechbare Trainingsläufe | Entwicklung / Training |
| Spezialisierte Hardware | auf KI-Last zugeschnittene Prozessoren rechnen pro Ergebnis günstiger | Entwicklung / Training, Inferenz |
| Aufräumen | ungenutzte Ressourcen abschalten, selten genutzte Daten archivieren | Infrastruktur / Speicher |
Die FinOps-Praxis: Kosten dauerhaft steuern
Eine einmalige Schätzung veraltet schnell, denn Nutzung, Preise und Modelle ändern sich laufend. Die FinOps-Praxis verankert deshalb feste Gewohnheiten in der Organisation:
| Praxis | So funktioniert sie |
|---|---|
| Kostentransparenz | alle Aufwendungen granular nach Projekt, Abteilung und Technologie erfassen; verhindert, dass versteckte Cloud- oder Personalkosten unterschätzt werden |
| Kostenallokation | Kosten verursachungsgerecht den Geschäftsbereichen und Produkten zuordnen statt pauschal der IT. Showback zeigt jedem Bereich seine verursachten Kosten, Chargeback belastet sie ihm tatsächlich weiter |
| Budgets und Genehmigungen | festlegen, wer Budgets freigibt, welche Schwellenwerte gelten und ab wann eine Genehmigung nötig ist; Quoten je Bereich, einheitliche Standards für Kostenberichte |
| Automatisiertes Monitoring | Kosten in Echtzeit erfassen, Alarme bei Überschreitung auslösen, notfalls automatisch drosseln; besonders wichtig bei nutzungsbasierten Cloud- und API-Preisen |
| Prognosen und Budgetplanung | Szenarien (Best, Average, Worst) und saisonale Effekte einplanen; macht Investitionen planbar |
| Kosten-Nutzen-Bewertung | je Anwendungsfall Rendite (ROI), Total Cost of Ownership (Gesamtkosten über die Lebensdauer, nicht nur der Anschaffungspreis) und Break-even (Punkt, ab dem der Nutzen die Einmalkosten deckt) prüfen; Grundlage für die Priorisierung zwischen Anwendungsfällen |
| Kostenbewusstsein | schulen, dass jeder Trainingslauf und jede Abfrage Geld kostet; Richtlinien für kosteneffiziente Entwicklung etablieren |
Sichtbares Ergebnis dieser Praxis ist die monatliche Kostenübersicht je Anwendungsfall mit Prognose und Abweichung. Sie speist das Berichtswesen aus Kapitel D4.
Beschaffung, Partner und Exit-Strategie
Externe Abhängigkeiten werden häufig unterschätzt. Klare Kriterien bei Auswahl und Vertrag (Anbieterauswahl im Detail: Kapitel B3):
- Datenstandorte entsprechen den rechtlichen Anforderungen
- Kundendaten werden nicht für fremdes Training verwendet
- Schnittstellen sind offen dokumentiert
- Eigentum an Daten und Artefakten bleibt beim Unternehmen
- Preisgleitklauseln und Audit-Nachweise vertraglich verankert
- Exit-Plan: Export von Daten, Merkmalen und Modellen geregelt, Ersatzlösung benannt, Rollback organisiert
So bleibt das Risiko einer Anbieterabhängigkeit (Vendor Lock-in, die Lage, in der ein Wechsel praktisch unbezahlbar wird) beherrschbar und die langfristige Handlungsfähigkeit gesichert.
Checkliste: FinOps-Reife
Die Checkliste folgt dem Weg des Kapitels vom Schätzen bis zum dauerhaften Steuern; offene Punkte sind die nächsten Ausbauschritte:
- Alle acht Kostenfelder je Anwendungsfall geschätzt, getrennt nach einmalig und laufend
- Einheitenkennzahlen definiert (Kosten pro Anfrage, Trainingslauf, Nutzer:in)
- Unit Economics je Anwendungsfall positiv oder bewusst akzeptiert
- Kostenhebel als laufender Prozess verankert: Caching, Batching, Prompt- und Kontextoptimierung, kompaktere Modelle, günstige Rechenzeitfenster
- Kosten verursachungsgerecht zugeordnet, Showback oder Chargeback etabliert
- Budgets, Quoten und Genehmigungsschwellen gesetzt
- Automatisiertes Kostenmonitoring mit Alarmen aktiv
- Budgetprognose mit Szenarien (Best, Average, Worst) und saisonalen Effekten erstellt
- Kosten-Nutzen-Bewertung mit ROI, Total Cost of Ownership und Break-even gerechnet
- Monatliche Kostenübersicht mit Prognose und Abweichung etabliert
- Kostenbewusstsein geschult: Jeder Trainingslauf und jede Abfrage verursacht Kosten
- Beschaffungs- und Exit-Regeln vertraglich verankert