Eine Anfrage an ein KI-Modell der Mittelklasse kostet gut einen Cent. Bei hundert Nutzern fällt das niemandem auf, bei hunderttausend entscheidet es über die Bruttomarge. Ob sie hält, entscheidet vor allem der technische Aufbau des Produkts. Dort wird festgelegt, welche Kosten im gleichen Tempo wie die Nutzung wachsen und welche schneller. Das geschieht lange bevor jemand die Rechnung genau liest.
Die Marge bei 100 Nutzern beweist nichts
Bei einem frühen KI-Produkt ist die Inferenzrechnung so klein, dass niemand sie prüft. Hundert Nutzer, drei Anfragen pro Tag: Bei gut einem Cent pro Anfrage sind das rund hundert Dollar Modellverbrauch im Monat, ein Rundungsfehler neben den Gehältern. In dieser Phase meldet jedes Team 90 Prozent Marge. Die Kosten, die mit jeder Anfrage steigen, sind schlicht noch zu klein, um aufzufallen. Die eigentliche Frage stellt sich zwei Jahre später, wenn der Traffic um das Tausendfache steigt: Um wie viel steigt die Rechnung? Die Antwort hängt davon ab, welche Strukturen das Team in den Monaten verankert hat, in denen Kosten niemanden interessierten.
Klassische Software kommt dem Ideal von null Grenzkosten nahe. KI nicht. Jede Interaktion mit dem Modell erzeugt Rechenkosten, und daraus entstehen variable Kosten pro Anfrage, die es in der Abo-Ökonomie so nicht gab. In der GuV steht dieser Bruch bei den Herstellkosten: Jede zusätzliche Anfrage kauft Rechenzeit ein, und diese Ausgabe wächst mit dem Umsatz mit. Die Bruttomarge eines KI-Produkts beginnt deshalb tiefer als bei reiner Software. Finanzielle Skalierbarkeit lässt sich also nicht auf die Reifephase verschieben, sie prägt die Produktarchitektur ab dem ersten Tag.
Kosten sortiert man nach der Form der Kurve
Wichtiger als die Herkunft eines Kostenblocks ist die Frage, wie er mit der Nutzung wächst.
Der lineare Teil ist planbar: Logging, Objektspeicher, ausgehender Traffic. Jeder neue Nutzer addiert einen festen Anteil, der Prognosefehler bleibt selten über 10 Prozent.
Der sublineare Teil wächst langsamer als die Nutzerzahl. Dazu gehören Vektorsuche und Indexierung. Die Abfragezeit bei einer Million Vektoren liegt weit unter dem Zehnfachen derjenigen bei 100.000, und die Fixkosten des Indexaufbaus verteilen sich umso dünner, je mehr Nutzer es gibt.
Gefährlich wird der superlineare Teil, der schneller wächst als die Nutzerzahl: manuelle Moderation, Bearbeitung von Störungen, Wiederholungsanfragen wegen Halluzinationen und alles, was langer Kontext verstärkt. Das liegt daran, dass mit der Reichweite auch der Anteil schwieriger Fälle steigt: Wer zehntausend Kunden hat, bekommt täglich Beschwerden, die ein Mensch lesen muss. Genau dieser Block drückt die Marge unbemerkt, während man auf die linearen Zeilen im Budget schaut.
Ein Block passt in keine der drei Kurven, weil er mit dem Alter des Produkts wächst. Das ist die Pflege des Modells: merken, wenn seine Antworten mit der Zeit schlechter werden, es neu trainieren, seine Qualität laufend prüfen, Ersatzsysteme für Ausfälle bereithalten und die Sicherheit überwachen. In Konzernprojekten bestimmt der laufende Betrieb die Gesamtbetriebskosten (TCO) stärker als die erste Entwicklung. Dieser Aufwand verschwindet auch nach dem Product-Market-Fit nicht, er wächst mit der Supportlast weiter.
Rechnen wir eine Sitzung zu Ende
Angenommen, eine Anfrage umfasst 1800 Tokens Input und 400 Output auf einem Modell der mittleren Klasse: Input 3 Dollar je Million Tokens, Output 15. Dann kostet eine Anfrage 1800 / 1.000.000 × 3 + 400 / 1.000.000 × 15 = 0,0054 + 0,006 = 0,0114 Dollar. Wirkt vernachlässigbar. Doch ein aktiver Nutzer stellt 12 Anfragen täglich, 360 im Monat, das sind bereits 4,10 Dollar Inferenz pro Kopf. Bei einem Abo von 19 Dollar frisst das Modell 21,6 Prozent, noch vor Suche, Speicher und Zahlungsgebühr.
Für ein deutsches Verbraucherprodukt ist selbst diese Zahl geschönt. Ein Abo für 19 Euro ist ein Bruttopreis, nach 19 Prozent Umsatzsteuer bleiben 15,97 Euro netto. Rechnet man die Inferenz der Einfachheit halber 1:1 in Euro um, frisst das Modell 25,7 statt 21,6 Prozent des Umsatzes. Wer Preise aus einem US-Benchmark übernimmt, verliert hierzulande gut vier Punkte Marge, bevor das erste Feature live ist.
Dazu kommt die Verteilung. Nehmen wir 2.000 zahlende Nutzer zu 15,97 Euro netto, also 31.940 Euro Umsatz im Monat: 1.900 Nutzer kosten im Schnitt 1,20 Euro Inferenz, zusammen 2.280 Euro. Die übrigen 100 kosten je 40 Euro, zusammen 4.000 Euro. Fünf Prozent der Kunden verursachen damit 64 Prozent der Modellkosten, die Inferenzmarge liegt bei 80,3 Prozent. Begrenzt man die Vielnutzer auf 15 Euro Kosten pro Kopf, sinkt die Rechnung auf 3.780 Euro und die Marge steigt auf 88,2 Prozent. Acht Punkte, ohne dass sich für 95 Prozent der Kunden etwas ändert.
Solange Sie diese Rechnung nicht für Ihre eigene Lastverteilung aufgemacht haben, ist jede Aussage über die Marge haltlos. Das Beispiel zeigt außerdem, dass eine Obergrenze für die Vielnutzer mehr bringt als jede Optimierung beim Durchschnittskunden.
Erst messen, dann cachen, Routing kommt zuletzt
Die 0,0114 Dollar pro Anfrage hängen an drei Stellschrauben: welches Modell antwortet, wie viel es liest und wie viel es schreibt. Drehen lässt sich jede. Die Reihenfolge entscheidet aber darüber, ob man nebenbei die Qualität beschädigt.
Am Anfang steht eine Messung, die nichts kostet außer Disziplin: die Rechnung nach Feature, Tarif und Nutzergruppe aufschlüsseln, von den sparsamsten bis zu den intensivsten Nutzern. Erst dann sieht man, dass etwa ein Drittel des Budgets an einer Funktion wie dem Hochladen langer PDFs hängen kann, die nur jeder zwölfte Nutzer verwendet.
Beim Input setzt man am billigsten im Prompt selbst an. Überflüssigen Kontext streichen, den unveränderlichen Teil in die Systeminstruktion verlagern, auf strukturierte Ausgabe wechseln: Das senkt Kosten, muss aber an Aufgaben geprüft werden, bei denen Vollständigkeit zählt. Hier wirkt auch der Prefix-Cache: Der Anbieter speichert den Teil der Anfrage, der sich nie ändert, und berechnet ihn bei Wiederverwendung viel günstiger. Sind von 1800 Input-Tokens 1200 fester Systemprompt, wird dieser Teil bei einem Cache-Treffer mit 10 Prozent des Preises berechnet, der Input sinkt von 0,0054 auf 0,0022 Dollar, die Sitzung insgesamt um 28 Prozent. Die Rechnung unterstellt eine verbreitete Preisstruktur: Lesen aus dem Cache zu 10 Prozent des Basis-Input-Preises, das erste Schreiben mit 25 Prozent Aufschlag. Wer einen anderen Anbieter nutzt, setzt dessen Sätze ein; die Logik bleibt dieselbe.
Wann sich das lohnt, lässt sich ausrechnen. Das Schreiben der 1200 Tokens kostet rund 0,0009 Dollar mehr als normaler Input, jeder Treffer spart etwa 0,0032 Dollar. Schon der zweite Aufruf innerhalb der Cache-Lebensdauer spielt den Aufschlag also wieder ein. Bei seltenen Einzelanfragen dagegen zahlt man nur den Aufschlag.
Die dritte Stellschraube, die Länge der Ausgabe, wird am häufigsten unterschätzt. Ein Output-Token kostet hier das Fünffache eines Input-Tokens, und ein Stream, den der Nutzer auf halber Strecke abbricht, wird voll berechnet, obwohl er nichts wert ist. Messen Sie den Anteil „halb generiert und verworfen“. Liegt er über 15 Prozent, gehören lange Antworten auf schrittweise Bestätigung: erst ein Plan mit 200 Tokens, der Fließtext per Klick. Eine harte Obergrenze für die Antwortlänge kostet eine Zeile in der Systeminstruktion.
Nicht jede Anfrage braucht einen wartenden Menschen. Nächtliche Zusammenfassungen, Massenverschlagwortung, Berichte für den nächsten Morgen laufen oft über denselben teuren Echtzeitkanal wie der Chat. Viele Anbieter rechnen Stapelverarbeitung deutlich günstiger ab, wenn das Ergebnis bis zu 24 Stunden später kommen darf. Die Faustregel: Stört eine Antwort nach sechs Stunden niemanden, gehört sie in die Batch-Warteschlange. Bei der Suche lassen sich drei weitere Posten drücken, nämlich Embeddings, Vektorsuche und Ranking, über einen Embedding-Cache, dünn besetzte Indizes und domänenspezifische Kompression.
Erst danach ist das Modell-Routing dran: Einfache Anfragen gehen an ein kleines, günstiges Modell, schwierige an ein großes. Es ist der wirkungsvollste Hebel und trotzdem der letzte, und die Rechnung zeigt, warum. Geben Sie 70 Prozent der Anfragen an ein zehnmal günstigeres Modell, dann wird die Rechnung 0,7 × 0,1 + 0,3 × 1 = 0,37, eine Ersparnis von 63 Prozent. Bei geringer Modellsicherheit muss aber auf das große Modell zurückgefallen werden. Gehen 12 Prozent der Anfragen diesen Weg, zahlt man doppelt, die reale Rechnung liegt bei 0,49, netto bleiben 51 Prozent. Die 12 Punkte Differenz sind die Steuer des Routers selbst. Dazu kommen zwei Prompt-Sätze, zwei Testsuiten und die Frage, die niemand gern klärt: War es bei einem Fehler in Produktion das Modell oder das Routing?
Der Rückfall kostet außerdem Zeit: Wer zuerst das kleine Modell fragt und dann beim großen nachfasst, wartet auf zwei Antworten, und bei 12 Prozent der Anfragen spürt der Nutzer genau diese Pause. Deshalb geht Routing erst mit einer fertigen Evaluations-Suite live: einigen hundert bewerteten Beispielen, die häufige und seltene Anfragen abdecken. Ohne sie lässt sich die Frage „Die Hälfte gespart, wie viel Qualität verloren?“ nur über Supporttickets beantworten, Wochen zu spät.
Das Preismodell entscheidet mehr als jede Optimierung
Die beste Kostenoptimierung hilft wenig, solange der intensivste Nutzer genauso viel zahlt wie der sparsamste. Reine Abos zerbrechen deshalb an KI: Sie setzen stabile Kosten pro Nutzer und vorhersehbare Nutzung voraus, und KI verletzt beides. Die Verteilung oben hat gezeigt, dass fünf Prozent Vielnutzer fast zwei Drittel des Inferenzbudgets ziehen.
Nutzungsbasierte Abrechnung repariert diese Kopplung, weil der Umsatz mit den Kosten wächst. Sie schreckt aber neue Nutzer ab, die ihren Verbrauch nicht einschätzen können: Niemand weiß, wofür eine Million Tokens reicht. Für die meisten KI-Produkte ist deshalb der Hybrid optimal: Festpreis mit klarer Quote plus Abrechnung darüber hinaus, und der Rest der Quote als Zahl im Interface, die der Nutzer ständig sieht.
Eine Quote wird akzeptiert, wenn sie nicht wie eine Strafe wirkt. Drei Eigenschaften machen den Unterschied. Der Nutzer sieht den Rest, bevor er anstößt. Nach dem Limit wird die Funktion schwächer (kleineres Modell, kürzere Antwort, Warteschlange), sie verschwindet nicht. Und das Limit setzt am selben Tag zurück wie die Abrechnung. Liegt die Grenze deutlich über dem 95. Perzentil der Nutzung, also über dem Wert, den 95 von 100 Kunden nicht erreichen, trifft sie nur wenige Kunden und kappt den teuersten Teil der Kurve. Stilles Drosseln mit der Meldung „System ausgelastet“ ist die schlechteste Variante, weil der Nutzer das Produkt für kaputt hält.
Am besten rechnet man nach erledigter Aufgabe ab: ein erstellter Bericht, ein Code-Review, ein Vertragsvergleich. Tokens sagen dem Nutzer nichts. Die Aufgabe ist für den Kunden verständlich, hängt meist eng mit den realen Kosten zusammen und erlaubt, im Backend Modell und Cache zu tauschen, ohne die Preisliste anzufassen.
Der Netto-LTV zeigt, ob sich ein Kunde wirklich lohnt
Den LTV für KI rechnet man abzüglich der variablen Kosten:
LTV_net = LTV_revenue minus variable Gesamtkosten,
wobei Rechenleistung, Support und Infrastruktur in die variablen Kosten eingehen. Der Abstand kann entscheiden. Rechenbeispiel für ein B2B-Werkzeug: 49 Euro netto im Monat, 20 Monate durchschnittliche Laufzeit, also 980 Euro Umsatz über die Lebensdauer. Kosten Inferenz, Suche und Support zusammen 9 Euro im Monat, bleiben nach 180 Euro variablen Kosten 800 Euro LTV_net. Bei 300 Euro CAC ergibt der Umsatz-LTV ein Verhältnis von 3,3, der Netto-LTV nur 2,7. Die gängige SaaS-Faustregel verlangt einen LTV von mindestens dem Dreifachen des CAC. Nach Umsatz besteht das Produkt diese Prüfung, nach Deckungsbeitrag fällt es durch.
Auch der CAC ist eigen: Ein neuer Nutzer belastet sofort die Rechenleistung, und intensive Nutzung im Gratistarif verlängert die Amortisation. Als grobe Orientierung für den Payback, keine feste Norm: Verbraucher-KI bis 6 Monate, Prosumer 6-9, B2B-KI-SaaS 12-18. Der Payback gibt das sichere Skalierungstempo vor. Solange LTV_net nicht stabil ist, ist es zu früh, Go-to-Market hochzufahren.
Die Marge rechnet man getrennt nach Kohorten. Self-Service mit 19-Dollar-Ticket und Großkunden mit 2.000 Dollar in eine Kennzahl zu gießen, ist die häufigste Selbsttäuschung: Gemittelte 86 Prozent verbergen, dass Self-Service nach CAC ins Minus rutscht. Bei Großkunden fließt der Hauptaufwand ohnehin in Einführung, Audit und dedizierten Support. Dort an den Modellkosten zu sparen, bringt kaum etwas.
Szenarien schlagen die Punktprognose
Wachstum bricht die Marge bei KI selten dort, wo man es erwartet. Das Team spielt deshalb mehrere Szenarien durch: Sprung der Rechenkosten, beschleunigtes Nutzerwachstum, Missbrauch langer Kontexte oder des Gratistarifs. Die Sensitivitätsanalyse zeigt, welcher Parameter die Ökonomie am stärksten bewegt: Modellgröße, Kontextlänge, Ausgabelänge, Zahl der Suchtreffer im Prompt oder Wiederholungen wegen Halluzinationen. Preissenkungen der Anbieter setzt man in der Prognose bewusst auf null. Der Preis fällt in Sprüngen und hört eines Tages auf zu fallen, das Nutzungswachstum nicht. Eine Marge, die aus billigeren Tokens entstand, ist nicht Ihr Verdienst. Ihrer sind kürzere Prompts, weniger Wiederholungen und frühe Abbruchbedingungen.
Bleibt die Frage nach dem Zeitpunkt. Kostenarbeit vor dem Product-Market-Fit gilt vielen als verfrühte Optimierung. Solange niemand das Produkt dringend will, verschiebt jede Woche am Cache nur den Moment, in dem man das merkt. Für ein Produkt mit ein paar hundert Nutzern stimmt das, und deshalb hilft eine feste Schwelle: Messen ab Tag eins, weil es fast nichts kostet. Optimieren erst, wenn die Inferenz mehr als 15 Prozent des Nettoumsatzes frisst oder ein Vielnutzer im 95. Perzentil mehr als das Zwanzigfache des Medians kostet. Vorher ist jede Stunde in der Discovery besser angelegt.
Die Marge braucht einen konkreten Verantwortlichen
Wenn die Kosten beim Engineering liegen, der Preis beim Marketing und die Retention beim Produkt, verantwortet niemand die Marge. Praktikabel ist, sie in die Quartalsziele des PM zu schreiben und ihm zwei echte Befugnisse zu geben. Er darf ein Feature stoppen, dessen Kosten pro Anfrage über der Schwelle liegen. Und er darf Quoten und Routing-Regeln ändern, ohne die Preisliste anzufassen. Dazu gehört eine wöchentliche Aufschlüsselung der Rechnung nach Feature, Tarif und Nutzer-Perzentil. Ohne diese Zuordnung kürzt das Team pauschal, und pauschal fällt immer der wertvollste Teil des Produkts zuerst.
Die wirtschaftlichen Leitplanken setzt derselbe PM: maximale Kosten pro Anfrage, Limits im Gratistarif, Schwellen für den Rückfall auf das große Modell, akzeptabler Payback. Jede davon steht als Zahl im Konzept. Ein Feature-Vorschlag ohne Antwort auf die Frage „Wie viele Punkte Marge kostet das?“ kommt nicht durch das Review.
Ein paar unbequeme Antworten
Lohnt sich ein KI-Produkt mit 55 Prozent Marge?
Ja, wenn Sie erklären können, wodurch sie steigt, und einen Termin nennen. „Wächst mit der Skalierung“ zählt nicht: Skalierung verschlimmert gerade die superlinearen Zeilen des Budgets. Hilfreich ist der Blick zurück: Schon eine viel zitierte Analyse von 2020 zum Geschäftsmodell von KI-Firmen beschrieb die niedrigere Marge als normale Folge der Inferenzkosten. Entscheidend ist, ob die Marge über Kohorten stabil bleibt und den CAC deckt. 55 Prozent bei berechenbaren Kosten pro Aufgabe sind gesünder als 80 Prozent, die nur halten, solange der Traffic klein ist.
Welche Kennzahl taugt für finanziell skalierbare KI?
Kosten pro erfolgreich erledigter Aufgabe: Im Nenner stehen nur erfolgreiche Aufgaben, das Geld für Wiederholungen nach einem Fehler geht in den Zähler. Der blinde Fleck: Die Kennzahl ist unempfindlich gegen Aufgabenschwere und verzerrt sich, wenn sich die Nutzerstruktur verschiebt. Daneben gehört deshalb das Verhältnis der Kosten im 95. Perzentil zum Median.
Was ist das größte finanzielle Risiko beim Wachstum?
Unkontrollierte Nutzung, vor allem lange Kontexte und mehrschrittige Abfragen, die die Rechenkosten hochtreiben. Die erste Verteidigung ist billig: eine Obergrenze für die Eingabegröße und für die Zahl der Schritte pro Aufgabe, gesetzt, bevor der erste Großkunde ein Archiv mit zehntausend Seiten hochlädt.