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 – der Modellverbrauch bleibt im Bereich weniger Dollar im Monat, günstiger als Domain plus Monitoring. In dieser Phase meldet jedes Team 90 % Marge: Im Nenner sitzen noch ungenutzte Fixkosten, und der variable Anteil ist schlicht nicht gewachsen. 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 Sie in den Monaten verankert haben, in denen Kosten niemanden interessierten.
Anders als klassisches SaaS hat KI keine annähernd null Grenzkosten. Jede Interaktion mit dem Modell erzeugt Rechenkosten, und diese bilden variable Kosten pro Anfrage, die es in der Abo-Ökonomie so nicht gab. Deshalb lässt sich finanzielle Skalierbarkeit nicht auf die Reifephase verschieben – sie prägt die Produktarchitektur ab Tag eins. Im Folgenden: wie man Kosten modelliert, Inferenz verbilligt, Preise baut und die Marge im Wachstum hält.
Kosten sortiert man nach der Form der Kurve, nicht nach dem Namen
Nützlicher als die Quelle ist die Frage, wie ein Kostenblock 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 %.
Der sublineare Teil ist Vektorsuche und Indexierung. Der Unterschied in der Abfragezeit zwischen 100 000 und einer Million Vektoren liegt weit unter dem Zehnfachen, und die Fixkosten des Indexaufbaus verteilen sich umso dünner, je mehr Nutzer es gibt.
Der superlineare Teil ist die eigentliche Gefahr: manuelle Moderation, Incident-Bearbeitung, Retries wegen Halluzinationen und alles, was langer Kontext verstärkt. Genau dieser Block zieht die Marge unbemerkt von 72 % auf 41 %, während man auf die linearen Zeilen im Budget schaut.
Separat steht der Lebenszyklus des Modells: Drifterkennung, Retraining, Evaluationsprozesse, redundante Bereitstellung, Sicherheitsmonitoring. In Enterprise-Rollouts bestimmt der Betrieb den TCO, nicht der erste Build – dieser Aufwand verschwindet mit erreichtem PMF nicht, sondern wächst mit der Supportlast.
Rechnen wir eine Sitzung zu Ende
Angenommen 1800 Tokens Input, 400 Output, ein 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 macht 12 Anfragen täglich, 360 im Monat – das sind bereits 4,10 Dollar Inferenz pro Kopf. Bei 19 Dollar Abo frisst das Modell 21,6 %, noch vor Retrieval, Speicher und Zahlungsgebühr. Solange Sie diese Rechnung nicht für Ihre eigene Lastverteilung aufgemacht haben, ist jede Aussage über die Marge haltlos.
Inferenz zu verbilligen wirkt am schnellsten
Modell-Routing ist der erste Hebel. Kaskade small → medium → large, Umschalten nach Confidence, Retrieval-first- und Reasoning-first-Pipelines, Cache für wiederkehrende Antworten. Geben Sie 70 % der Anfragen an ein zehnmal günstigeres Modell – die Rechnung wird 0,7 × 0,1 + 0,3 × 1 = 0,37, eine Ersparnis von 63 %. Doch bei niedriger Confidence muss auf das große Modell zurückgefallen werden: Gehen 12 % der Anfragen diesen Weg, zahlt man doppelt, die reale Rechnung liegt bei 0,49, netto 51 %. Die 12 Punkte Differenz sind die Steuer des Routers selbst – plus zwei Prompt-Sätze, zwei Evaluations-Suiten und die Frage, die niemand gern klärt: Bei einem Fehler in Produktion, war es das Modell oder das Routing. Deshalb schaltet man Routing nicht ohne fertige Evaluations-Suite scharf.
Prompt-Optimierung wirkt ohne Qualitätsrisiko: überflüssigen Kontext streichen, den unveränderlichen Teil in die Systeminstruktion verlagern, auf strukturierten Output wechseln. Hier lebt auch der Prefix-Cache – sind von 1800 Input-Tokens 1200 fester Systemprompt, wird dieser Teil bei Cache-Treffer mit 10 % des Preises berechnet, der Input sinkt von 0,0054 auf 0,0022 Dollar, die Sitzung insgesamt um 28 %.
Die Länge der Ausgabe wird unterschätzt: Lange Antworten sind am teuersten, und ein Stream, den der Nutzer auf halber Strecke abbricht, wird voll berechnet bei null Wert. Messen Sie den Anteil „halb generiert und verworfen“; über 15 % gehören lange Antworten auf schrittweise Bestätigung: erst ein Plan mit 200 Tokens, der Fließtext per Klick.
Retrieval-Optimierung senkt drei Kostenblöcke – Embedding, Vektorsuche, Ranking – über Embedding-Cache, Sparse Indexing und domänenspezifische Kompression. Batching senkt die GPU-Last bei Massenanalyse und Content-Generierung, und asynchrone Abläufe verlagern schwere Workloads aus kritischen User-Flows.
Das Preismodell entscheidet mehr als jede Optimierung
Reine Abos zerbrechen sofort an KI: Sie setzen stabile Kosten pro Nutzer und vorhersehbare Nutzung voraus, KI verletzt beides. Heavy-User vernichten die Marge – bei typischer Verteilung ziehen 5 % der Nutzer über die Hälfte des Inferenzbudgets.
Nutzungsbasierte Abrechnung repariert diese Kopplung – Umsatz wächst mit den Kosten –, schreckt aber den neuen Nutzer ab, der seinen Verbrauch nicht einschätzen kann: 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.
Die Abrechnungseinheit wählt man nicht nach Tokens, die dem Nutzer nichts sagen, sondern nach erledigter Aufgabe – eine Report-Generierung, ein Code-Review, ein Vertragsvergleich. Diese Einheit ist für den Kunden sinnvoll, korreliert mit den realen Kosten meist über 0,8 und erlaubt, im Backend Modell und Cache zu ändern, ohne die Preisliste anzufassen.
Profitabilität lebt an der Schnittstelle von Nutzung, Retention und Kostenkontrolle
Den LTV für KI rechnet man abzüglich der variablen Kosten:
LTV_net = LTV_revenue − Total Variable Cost,
wobei in die variablen Kosten Compute, Support und Infrastruktur eingehen. Auch der CAC ist eigen: Ein neuer Nutzer belastet sofort das Compute, und intensive Free-Tier-Nutzung verlängert den Payback. Richtwerte für die Amortisation: Consumer-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 nach Kohorten, nicht als Gesamtzahl. Self-Serve mit 19-Dollar-Ticket und Enterprise mit 2000 in eine Kennzahl zu gießen, ist die häufigste Selbsttäuschung: Gemittelte 86 % verbergen, dass Self-Serve nach CAC ins Minus rutscht. Bei Enterprise ist der Hauptaufwand ohnehin nicht Inferenz, sondern Rollout, Audit und dedizierter Support – die Modellkosten dort zu drücken, bringt nichts.
Szenarien schlagen die Punktprognose
Wachstum bei KI bricht die Marge nicht dort, wo man es erwartet, also spielt das Team mehrere Szenarien durch: Sprung der Compute-Kosten, beschleunigtes Nutzerwachstum, Missbrauch langer Kontexte, RAG-Überlastung, Free-Tier-Exzesse. Die Sensitivitätsanalyse zeigt, welcher Parameter die Ökonomie am stärksten bewegt – Modellgröße, Kontextlänge, Ausgabelänge, Retrieval-Top-k oder Retries wegen Halluzinationen. In der Prognose setzt man Preissenkungen der Anbieter bewusst auf null: Der Preis fällt in Sprüngen und hört eines Tages auf, das Nutzungswachstum nicht. Eine Marge, die aus billigeren Tokens entstand, ist nicht Ihr Verdienst; Ihrer sind kürzere Prompts, weniger Retries, frühe Abbruchbedingungen.
Die Marge braucht einen konkreten Verantwortlichen
Wenn Kosten am Engineering hängen, der Preis am Marketing und die Retention am Produkt, verantwortet niemand die Marge. Praktikabel ist, sie in die Quartalsziele des PM zu schreiben und ihm zwei echte Befugnisse zu geben: ein Feature zu blockieren, dessen Kosten pro Anfrage über der Schwelle liegen, und Quoten und Routing-Regeln zu ändern, ohne die Preisliste anzufassen. Dazu eine wöchentliche Aufschlüsselung der Rechnung nach Feature, Tarif und Nutzer-Perzentil. Ohne Attribution kürzt das Team das Budget pauschal – und pauschal fällt immer der wertvollste Teil der Experience zuerst.
Die wirtschaftlichen Leitplanken setzt derselbe PM: maximale Kosten pro Anfrage, Free-Tier-Limits, Fallback-Schwellen, Routing-Regeln, akzeptabler Payback. Sie schützen die Marge im Scale-up.
Ein paar unbequeme Antworten
Lohnt sich ein KI-Produkt mit 55 % 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.
Cache oder Routing zuerst
Cache. Er ändert die Ausgabequalität nicht, das Risiko liegt nur in der Konsistenz. Routing ändert die Qualität und braucht eine Evaluations-Suite. Es ohne Evaluation scharfzuschalten, heißt, das Kostenproblem gegen ein teureres Qualitätsproblem zu tauschen.
Schreckt nutzungsbasierte Abrechnung ab
Sie schreckt einen Teil neuer Nutzer ab, die ihren Verbrauch nicht prognostizieren können. Der Hybrid ist robuster: Festpreis mit verständlicher Quote plus Abrechnung darüber und sichtbarem Rest im Interface.
Welche Kennzahl hat finanziell skalierbare KI
Kosten pro erfolgreich erledigter Aufgabe: Im Nenner nur erfolgreiche Aufgaben, das Geld für Retries nach einem Fehler geht in den Zähler. Blinder Fleck – sie ist unempfindlich gegen Aufgabenschwere und verzerrt sich, wenn sich die Nutzerstruktur verschiebt.
Größtes finanzielles Risiko im Scale-up
Unkontrollierte Nutzung – vor allem lange Kontexte und mehrschrittige Abfragen, die die Rechenkosten hochtreiben.