Was ein KI-Feature wirklich kostet: Die Unit Economics der Inferenz

Das Wochenend-Feature und die Rechnung am Monatsende

Ein KI-Feature zu bauen ist heute eine Sache des Wochenendes. Ein paar API-Calls, ein Prompt, ein bisschen Glue-Code – und schon beantwortet der Chatbot Support-Fragen, fasst der Assistent Dokumente zusammen, schreibt das Tool Produktbeschreibungen. Der Prototyp wirkt wie Magie, und das verleitet zu einem gefährlichen Schluss: dass das Schwerste geschafft sei.

Ist es nicht. Das Bauen war nie das Teure. Das Teure ist, das Feature bei jedem Nutzer, jeden Tag, für immer laufen zu lassen. Genau diese Rechnung machen die wenigsten auf, bevor sie ausrollen. Sie machen sie auf, wenn die erste richtige Cloud-Rechnung kommt – und dann ist das Produkt schon live, schon im Preis kalkuliert, schon dem Kunden versprochen.

Die unbequeme Wahrheit hinter jedem KI-Produkt: Jeder Token kostet Geld. Und anders als bei klassischer Software summiert sich das nicht zu null, sondern mit jedem einzelnen Klick.

Der Bruch im Kostenmodell

Um zu verstehen, warum KI hier anders tickt, muss man sich kurz daran erinnern, warum klassisches SaaS so ein traumhaftes Geschäft war.

Bei normaler Software liegen die Grenzkosten für den nächsten Nutzer nahe null. Der Code ist geschrieben, die Server laufen ohnehin – ob der zehnte oder der zehntausendste Nutzer eine Seite aufruft, kostet praktisch dasselbe, nämlich fast nichts. Das ist der Grund, warum Wachstum bei SaaS reines Oberwasser ist: Jeder neue Kunde bringt Umsatz, aber kaum zusätzliche Kosten. Die Marge steigt, je größer man wird.

KI dreht dieses Prinzip um. Jede Interaktion ruft ein Modell auf, und jeder Modellaufruf kostet Geld – pro Token, bei jeder einzelnen Anfrage. Der zehntausendste Nutzer ist nicht gratis. Er kostet exakt so viel wie der erste, multipliziert mit der Zahl seiner Anfragen. Skalierung vervielfacht hier nicht nur den Umsatz, sondern auch die Kosten. Wer mit der SaaS-Intuition „mehr Nutzer = mehr Gewinn" an ein KI-Produkt herangeht, rechnet die Hälfte der Gleichung nicht mit.

Die Rechnung, die niemand aufmacht

Die Mathematik ist nicht kompliziert. Genau deshalb ist es so erstaunlich, wie selten sie jemand hinschreibt. Die Kosten eines KI-Features ergeben sich grob aus:

(Input-Tokens + Output-Tokens) × Preis pro Token × Calls pro Aufgabe × Aufgaben pro Nutzer × Nutzer.

Spielen wir das mit runden, illustrativen Zahlen durch. Nehmen wir eine einfache Anfrage: 2.000 Tokens gehen rein (Frage plus etwas Kontext), 500 kommen raus. Bei einem Modell, das grob 3 € pro Million Input-Tokens und 15 € pro Million Output-Tokens kostet, landet eine einzelne Anfrage bei etwa 1,5 Cent. Lächerlich wenig. Hier hört das mentale Rechnen der meisten Teams auf – und genau hier fängt das Problem erst an.

Jetzt schichten wir die Realität darüber:

• Langer Kontext und RAG. Damit das Modell gute Antworten gibt, stopft man relevante Dokumente in jeden Call. Aus 2.000 Input-Tokens werden schnell 20.000. Die Anfrage kostet jetzt eher 7 Cent statt 1,5 – Faktor fünf, nur durch Kontext.
• Agentische Schleifen. Moderne KI-Features bestehen selten aus einem Call. Der Agent plant, ruft ein Tool auf, bewertet das Ergebnis, korrigiert sich, ruft das nächste Tool auf. 20 Modellaufrufe für eine einzige Aufgabe sind keine Seltenheit. Plötzlich kostet diese eine Aufgabe nicht 7 Cent, sondern 1,40 € – das Zwanzigfache der naiven Schätzung.
• Retries. Ein Timeout, eine abgeschnittene Antwort, ein fehlgeschlagener Tool-Call – jeder Wiederholungsversuch kostet erneut. In schlecht abgesicherten Systemen verdoppeln Retry-Stürme die Rechnung im Stillen.

Jetzt multiplizieren wir nach oben. Ein aktiver Nutzer löst vielleicht 10 solcher Aufgaben am Tag, an 20 Arbeitstagen im Monat – das sind 200 Aufgaben zu je 1,40 €, also 280 € pro Nutzer und Monat. Wenn das Produkt für 29 € im Monat verkauft wird, verliert man mit jedem aktiven Nutzer rund 250 €. Nicht bei Missbrauch. Bei normaler Nutzung.

Das ist kein konstruiertes Extrem. Es ist die ganz normale Eskalation von „funktioniert im Prototyp" zu „läuft in Produktion" – und sie passiert leise, Schicht für Schicht, bis die Rechnung kommt.

Das All-you-can-eat-Problem

Selbst wenn die Durchschnittskosten stimmen, lauert die nächste Falle in der Verteilung. Denn Nutzer sind nicht gleich. Bei fast jedem Produkt folgt die Nutzung einer brutalen Schieflage: Ein kleiner Prozentsatz der Power-User erzeugt einen Großteil der Last.

Bei klassischem SaaS ist das egal – der Vielnutzer kostet ja nichts extra. Bei KI ist es fatal. Wer eine Flatrate verkauft und auf Power-User trifft, hat ein All-you-can-eat-Restaurant eröffnet, in dem ein paar Gäste das gesamte Buffet leerräumen. Die schwersten 5 % der Nutzer können mehr Inferenzkosten verursachen als die anderen 95 % zusammen.

Die Rechnung mittelt sich nicht weg. Sie wird vom Vielnutzer dominiert. Und der teuerste Kunde ist nicht der, der am wenigsten zahlt, sondern oft der, der das Produkt am meisten liebt – der es den ganzen Tag benutzt, weil es so gut ist. Bei einem Festpreis kostet der treueste Fan mehr, als er einbringt. Man bestraft sich für den eigenen Erfolg.

Wo sich die Kosten verstecken

Die meisten Kostenexplosionen sind keine Naturgesetze, sondern vermeidbare Entscheidungen. Die üblichen Verdächtigen:

• Kontext-Aufblähung. Bei jedem Call wird die komplette Gesprächshistorie oder die halbe Wissensdatenbank erneut mitgeschickt. Bezahlt wird der gesamte Kontext bei jeder einzelnen Anfrage – auch der Teil, der seit zehn Nachrichten unverändert ist.
• Kein Caching. Derselbe System-Prompt, dieselben Dokumente, dieselben Anweisungen gehen tausendfach unverändert über die Leitung und werden jedes Mal voll abgerechnet, obwohl das Ergebnis identisch wäre.
• Frontier-Modell für Trivialitäten. Das größte, teuerste Modell klassifiziert eine E-Mail nach „dringend/nicht dringend" oder extrahiert ein Datum aus einem Satz. Aufgaben, die ein zehnmal günstigeres Modell genauso gut erledigt.
• Keine Output-Begrenzung. Ohne Limit schreibt das Modell drei Absätze, wo einer gereicht hätte – und Output-Tokens sind in der Regel die teuersten.
• Agentische Schleifen ohne Budgetdeckel. Ein Agent, der sich verrennt, ruft das Modell so lange auf, bis er fertig ist – oder bis er es nie wird. Ohne harte Obergrenze für Calls pro Aufgabe ist das ein offener Geldhahn.
• Retry-Stürme. Schlägt ein Call fehl und das System versucht es aggressiv erneut, ohne Backoff und ohne Deckel, vervielfachen sich die Kosten genau dann, wenn ohnehin gerade etwas schiefläuft.

Keiner dieser Punkte ist im Prototyp sichtbar. Jeder einzelne wird in Produktion zur Rechnung.

Die Hebel

Die gute Nachricht: Jeder dieser Kostentreiber hat einen Gegenhebel. Wer Unit Economics ernst nimmt, baut sie von Anfang an ein – nicht als Notoperation, wenn die Rechnung schon weh tut.

1. Das Modell auf die Aufgabe zuschneiden. Nicht jede Aufgabe braucht das Flaggschiff. Ein kleines, günstiges Modell für Klassifikation, Extraktion und einfache Antworten; das Frontier-Modell nur dort, wo es sich seinen Preis verdient. Allein diese Staffelung senkt die Kosten oft um eine Größenordnung.
2. Caching nutzen. Prompt-Caching für stabile System-Prompts und Dokumente, Ergebnis-Caching für wiederkehrende Anfragen. Was sich nicht ändert, soll nicht jedes Mal neu bezahlt werden.
3. Kontext und Output deckeln. Nur die wirklich relevanten Teile in den Call geben, nicht die ganze Historie. Eine harte Obergrenze für die Antwortlänge setzen.
4. Budgetgrenzen pro Nutzer und pro Aufgabe. Eine maximale Zahl an Calls pro Aufgabe, ein maximales Token-Budget pro Nutzer und Tag. So wird die Worst-Case-Rechnung kalkulierbar statt unendlich.
5. Batchen, wo es geht. Was nicht in Echtzeit passieren muss, lässt sich gebündelt und oft deutlich günstiger verarbeiten.
6. Bei hohem, stabilem Volumen: Self-Hosting prüfen. Ab einer gewissen Dauerlast kann ein selbst betriebenes Open-Weight-Modell günstiger sein als der API-Zähler – sofern man die Betriebskosten ehrlich mitrechnet.
7. Preis an den Verbrauch koppeln. Nutzungsbasiert oder gestaffelt statt flat. Wenn der Umsatz mit den Kosten mitwächst, kann der Power-User nicht mehr zur Verlustquelle werden.

Der ehrliche Einwand: nicht zu früh optimieren

So weit die Kostenpredigt – und jetzt der Gegeneinwand, denn sonst zieht man die falschen Schlüsse.

Kosten auf einem Produkt zu optimieren, das noch keine Nutzer hat, ist verschwendete Zeit. In der frühen Phase zählen zwei Dinge: Funktioniert es überhaupt, und will es jemand? Korrektheit und Product-Market-Fit schlagen Effizienz. Ein teurer Prototyp, der beweist, dass Menschen das Feature lieben, ist unendlich wertvoller als ein billiger, den niemand will. Wer in Woche eins über Token-Caching grübelt, statt das Produkt scharfzustellen, optimiert die falsche Variable.

Dazu kommt ein struktureller Trost: Die Preise pro Token fallen über die Zeit verlässlich. Was heute „zu teuer für diesen Anwendungsfall" ist, kann in einem Jahr selbstverständlich sein. Manche Idee, die heute an der Inferenzrechnung scheitert, wird schlicht durch Abwarten rentabel. Das ist real und sollte den Mut nicht nehmen.

Aber – und das ist der entscheidende Punkt – das ist kein Freibrief, die Unit Economics zu ignorieren. Es ist ein Argument für die richtige Reihenfolge: erst beweisen, dass es funktioniert und gewollt ist, dann die Kosten verstehen, bevor man skaliert. Die Katastrophe passiert nicht beim teuren Prototyp. Sie passiert, wenn man ein Produkt mit negativer Marge auf zehntausend Nutzer hochfährt, ohne die Stückkosten je gerechnet zu haben. Skalierung macht ein gutes Geschäft besser und ein kaputtes schneller kaputt.

Die unbequemen Fragen

Bevor ein KI-Feature in die Breite geht, lohnt ein nüchterner Check. Fünf Fragen, die ehrlich beantwortet sein wollen:

1. Kennst du deine Kosten pro Anfrage und pro aktivem Nutzer? Nicht geschätzt, sondern gemessen. Wer diese Zahl nicht nennen kann, fliegt blind.
2. Was kostet dein Worst-Case-Nutzer? Nimm die schwersten 5 % und rechne sie durch. Das ist deine echte Risikozahl, nicht der Durchschnitt.
3. Deckt dein Preis diesen Nutzer? Wenn der teuerste Kunde mehr kostet, als er zahlt, ist das Preismodell kaputt – nicht der Kunde.
4. Wo versteckt sich Kontext-Aufblähung? Schickst du bei jedem Call die ganze Historie und die halbe Wissensbasis mit? Cachst du, was sich nicht ändert?
5. Zahlst du für ein Frontier-Modell, wo ein kleines genügt? Geh jeden Modellaufruf durch und frag, ob er das teuerste Werkzeug wirklich braucht.

Wer alle fünf sauber beantwortet, hat ein Produkt, das mit dem Wachstum profitabler wird statt gegen eine Kostenwand zu fahren.

Fazit

Klassische Software wurde mit jedem Nutzer günstiger pro Kopf. KI wird das nicht – jeder Nutzer, jede Anfrage, jeder Token hat einen echten, wiederkehrenden Preis. Das ist kein Grund, keine KI-Produkte zu bauen. Es ist ein Grund, sie mit offenen Augen zu bauen.

Die Unit Economics sind keine Aufgabe für später, wenn das Wachstum kommt. Sie sind eine Entscheidung am ersten Tag des Designs: welches Modell, wie viel Kontext, welcher Deckel, welches Preismodell. Wer das von vorne mitdenkt, baut ein Produkt, das mit der Skalierung verdient. Wer es ignoriert, baut eines, das mit der Skalierung blutet – und es erst merkt, wenn die Rechnung kommt.

Genau hier setzen wir bei nh labs an: KI-Produkte von Tag eins so zu entwerfen, dass die Stückkosten stimmen. Nicht damit das Feature im Demo glänzt, sondern damit es bei zehntausend Nutzern noch Geld verdient. Das Bauen ist billig geworden. Das Betreiben mit Verstand bleibt die eigentliche Kunst.