Ein KI-Feature, das Nutzer begeistert und bei jeder Anfrage Geld verliert, ist kein Produkt – es ist eine Subvention mit Marketingbudget. Der Unterschied zwischen beidem liegt in vier Architekturentscheidungen, die Sie vor dem Launch treffen, nicht in einem Anbieterrabatt, den Sie danach aushandeln.

Im Pilotmassstab schaut niemand auf die Kosten pro Aufruf. Das Volumen ist winzig, die Rechnung ein Rundungsfehler, und das Team konzentriert sich darauf, ob das Ding überhaupt funktioniert. Dann geht es live, das Volumen wächst, und irgendjemand in der Finanzabteilung fragt, warum die KI-Position auf der Cloud-Rechnung im Quartalsvergleich um 400 % gestiegen ist. Bis dahin ist die Architektur zementiert, und die teuren Entscheidungen wurden längst per Default getroffen.

Die Kosten der LLM-Inference sind kein betriebliches Detail, das man später optimiert. Sie sind ein Designparameter, der die Bruttomarge Ihres Features bestimmt, und er wird durch Entscheidungen festgelegt, die Sie im Voraus treffen. Wir haben genug «erfolgreiche» KI-Features neu architektiert, die still und leise unprofitabel waren, um das Muster zu kennen – und die Einsparungen, wenn man es richtig macht, liegen regelmässig bei 60–90 %, ohne Qualitätsverlust.

Das eigentliche Problem: Die Kosten skalieren mit dem Erfolg, und die Defaults sind teuer

Jeder andere Teil eines KI-Features hat fixe oder unterproportionale Kosten. Inference skaliert linear mit der Nutzung – je mehr die Leute es lieben, desto mehr kostet es, für immer. Das kehrt die übliche Software-Ökonomie um, in der die Grenzkosten gegen null tendieren. Wenn Ihre Unit Economics negativ sind, macht Erfolg das Problem schlimmer, nicht besser.

Und die Defaults sind kostenmässig das Schlechteste, was man wählen kann. Der Reflex ist, jede Anfrage an das leistungsfähigste (teuerste) Modell zu schicken, jedes Mal mit dem vollen Kontext, ohne Caching, mit Retries bei Fehlern. So baut man die Demo richtig und betreibt den Service falsch. Die meisten KI-Features in Unternehmen, die wir auditieren, zahlen für die gelieferte Qualität das 5- bis 10-Fache dessen, was nötig wäre.

Die vier Entscheidungen, die Ihre Bruttomarge bestimmen

1. Model Tiering – hören Sie auf, alles ans Flaggschiff zu schicken

Nicht jede Anfrage braucht Ihr leistungsfähigstes Modell. Klassifikation, Routing, einfache Extraktion und kurze Antworten laufen auf einem kleineren Modell zu einem Bruchteil der Kosten und oft mit gleicher Qualität für die jeweilige Aufgabe. Routen Sie nach Schwierigkeit: Ein günstiges Modell bearbeitet die einfache Mehrheit, das Flaggschiff die schwierige Minderheit, und ein Klassifikator (selbst günstig) entscheidet, was was ist. Bei einem typischen gemischten Workload senkt Tiering allein die Kosten um 50–70 %, weil die einfachen Fälle das Volumen dominieren.

2. Caching – hören Sie auf, zweimal für dieselbe Antwort zu zahlen

Anfragen in Unternehmen wiederholen sich weit häufiger, als Teams erwarten. Cachen Sie identische und semantisch ähnliche Anfragen, und cachen Sie den statischen Teil langer Prompts (Systeminstruktionen, abgerufene Standardtexte) über das Prompt Caching des Anbieters, wo verfügbar. Eine Cache-Hit-Rate von 30–50 % ist bei Support- und internen Wissens-Workloads üblich, und ein Cache-Hit kostet einen Bruchteil einer neuen Generierung – manchmal fast nichts.

3. Kontextdisziplin – hören Sie auf, das Kontextfenster vollzustopfen

Sie zahlen pro Token, auch für jedes Token Kontext, das Sie mitschicken. Teams polstern den Prompt routinemässig «zur Sicherheit» mit den Top-20-Chunks aus dem Retrieval auf, obwohl 5 gererankte Chunks besser antworten würden und ein Viertel kosten. Straffes Retrieval und Reranking sind sowohl ein Qualitäts- als auch ein Kostenhebel. Kürzen Sie Few-Shot-Beispiele, sobald das Modell zuverlässig ist. Jedes Token im Prompt ist ein Token auf der Rechnung, bei jedem einzelnen Aufruf.

4. Output-Limits und Streaming – hören Sie auf, für Ausschweifungen zu zahlen

Output-Tokens kosten oft ein Mehrfaches der Input-Tokens. Begrenzen Sie die maximale Output-Länge, instruieren Sie auf Prägnanz und vermeiden Sie es, das Modell den Input wiederholen zu lassen. Bei interaktiven Features streamen Sie, damit Nutzer Geschwindigkeit wahrnehmen, ohne dass Sie ein schnelleres, teureres Modell brauchen.

Praxisbeispiel: die Unit Economics eines Support-Assistenten

Der Support-Assistent eines SaaS-Unternehmens bearbeitete 60’000 Anfragen pro Monat. Die Launch-Architektur: Flaggschiff-Modell für alles, voller abgerufener Kontext (rund 6k Tokens), kein Caching, grosszügiger Output. Gemischte Kosten ≈ CHF 0.21 pro Anfrage → rund CHF 12’600 pro Monat, wachsend mit der Nutzung.

Wir haben die vier Entscheidungen angewendet, ohne das Nutzererlebnis zu verändern:

• Tiering: Ein günstiger Klassifikator leitete 64 % der Anfragen (FAQ-artig, einfache Nachschlagefälle) an ein kleines Modell; nur komplexe Fälle gingen ans Flaggschiff. −58 % auf dem gerouteten Anteil.
• Caching: 38 % semantische Cache-Hit-Rate bei häufigen Fragen, dazu Prompt Caching der Systeminstruktionen. Cache-Hits kosten rund CHF 0.005 pro Stück.
• Kontextdisziplin: Reranking senkte den durchschnittlichen Kontext von 6k auf 1,8k Tokens – und die Antwortgenauigkeit stieg um 3 Prozentpunkte, weil das Modell nicht mehr von marginalen Chunks abgelenkt wurde.
• Output-Limits: begrenzt und per Prompt auf Prägnanz getrimmt, was den durchschnittlichen Output um rund 35 % kürzte.

Neue gemischte Kosten ≈ CHF 0.046 pro Anfrage → rund CHF 2’760 pro Monat. Eine Reduktion um 78 %, bei leichter Qualitätsverbesserung. Das Feature ging von einer negativen zu einer komfortabel positiven Bruttomarge, und mit dem Volumen wachsen nun die Einsparungen statt der Rechnung.

Das Detail, bei dem es sich zu verweilen lohnt: Kontextdisziplin verbesserte Qualität und Kosten gleichzeitig. Die kostenoptimierte Architektur war zugleich die leistungsfähigere, weil straffes Retrieval dem Modell hilft, sich zu fokussieren. Kosten und Qualität sind nicht immer ein Zielkonflikt; hier zeigten sie in dieselbe Richtung.

Die Falle, für die heutigen Preise zu optimieren

Inference-Preise sinken stetig, und das verleitet manche Teams zum Schluss, Kostenoptimierung sei verschwendete Mühe – «das Modell wird ohnehin billiger». Das ist eine bequeme Geschichte und eine falsche, aus zwei Gründen. Erstens wächst Ihr Volumen fast immer schneller, als die Stückpreise fallen; ein Feature, das Erfolg hat, erzeugt mehr Anfragen, längere Kontexte und reichhaltigere Outputs, sodass die Gesamtausgaben steigen, selbst wenn die Kosten pro Token sinken. Zweitens belohnen fallende Preise genau jene Teams, welche die austauschbare Architektur aus der Tiering-Diskussion gebaut haben – sie nehmen jede Preissenkung mit, indem sie zum jeweils günstigsten Modell routen, während ein Team, das fest an ein Modell und eine Stufe verdrahtet ist, darauf wartet, dass genau dieser Anbieter genau diesen Preis senkt.

Der tiefere Punkt: Die vier Hebel – Tiering, Caching, Kontextdisziplin, Output-Limits – sind keine einmaligen Optimierungen, die man anwendet und vergisst. Es sind architektonische Eigenschaften, die sich weiter auszahlen, während sich die Landschaft verschiebt. Eine Caching-Schicht rentiert immer mehr, je repetitiver Ihr Traffic wird; eine Routing-Schicht erlaubt Ihnen, ein neu erschienenes günstiges Modell in der Woche seines Releases einzusetzen; Kontextdisziplin hält Ihre Kosten flach, selbst wenn Sie weitere Quellen ins Retrieval aufnehmen. Sie wegzulassen, weil «die Preise ja sinken», ist, als würde man bei einer Datenbank auf Indizes verzichten, weil «die Disks schneller werden» – technisch korrekt, für das strukturelle Problem irrelevant.

Es gibt auch ein Argument der Margentransparenz, das in der Geschäftsleitung verfängt. Ein KI-Feature mit ungeprüften Unit Economics ist ein finanzieller blinder Fleck: Niemand kann sagen, ob die millionste Anfrage profitabel ist. Wenn Sie Kosten pro Anfrage und Bruttomarge pro Feature instrumentieren, wird KI von einer unbegrenzten Zeile auf der Cloud-Rechnung zu einer Erfolgsrechnung, die Sie steuern können – mit der bewussten Entscheidung, welche Features das Flaggschiff-Modell verdienen und welche schlank laufen sollen. Diese Transparenz trennt, mehr als jede einzelne Optimierung, ein KI-Portfolio, das nachhaltig skaliert, von einem, das im Quartal nach seinem Erfolg zum Budgetnotfall wird.

Stolpersteine

• Kosten auf Pilotvolumen modellieren. Rechnen Sie auf realistischen Massstab hoch; lineare Kosten bestrafen Optimismus.
• Flaggschiff als Default. Die grösste Einzelverschwendung. Die meisten Anfragen brauchen Ihr bestes Modell nicht.
• Kein Caching, weil «alle Anfragen einzigartig sind». Messen Sie, bevor Sie annehmen; das sind sie selten.
• Kontext zur Sicherheit aufpolstern. Mehr Kontext bedeutet mehr Kosten und oft schlechtere Antworten. Reranken und kürzen.
• Kosten ohne Eval-Set optimieren. Sie brauchen Evals, um zu belegen, dass ein günstigeres Modell die Qualität hält – sonst raten Sie.

Entscheidungs-Checkliste

1. Wie hoch sind unsere Kosten pro Anfrage im prognostizierten Massstab, nicht im Pilotmassstab?
2. Routen wir nach Schwierigkeit, oder schicken wir alles ans Flaggschiff?
3. Wie hoch ist unsere Cache-Hit-Rate, und cachen wir statische Prompt-Teile?
4. Wie gross ist unser durchschnittlicher Kontext, und kann Reranking ihn verkleinern?
5. Sind Output-Längen begrenzt und wird Prägnanz durchgesetzt?
6. Ist die Bruttomarge des Features positiv – und verbessert oder verschlechtert sie sich mit dem Volumen?
7. Haben wir Evals, die bestätigen, dass Kostensenkungen uns keine Qualität gekostet haben?

Die gridz-Sicht

Behandeln Sie Inference-Kosten als Architekturentscheidung, und Sie können sie in der Regel um 60–90 % senken, bei gleichbleibender oder besserer Qualität; behandeln Sie sie als Problem für später, und der Erfolg wird zur Budgetkrise. Die vier Hebel – Tiering, Caching, Kontextdisziplin, Output-Limits – sind unspektakulär, und genau dort liegt die Marge. Wir gestalten KI-Features so, dass sie vom ersten Tag an im grossen Massstab profitabel sind, mit dem Evaluation Harness als Beleg, dass die günstigere Architektur weiterhin liefert. Ein KI-Feature ohne Unit-Economics-Modell ist eine Subvention, die nur darauf wartet, entdeckt zu werden.

Die schnellste Diagnose, die Sie heute durchführen können: Nehmen Sie ein KI-Feature in Produktion, berechnen Sie seine tatsächlichen Kosten pro Anfrage beim aktuellen Volumen und rechnen Sie sie auf das Volumen in einem Jahr hoch. Wenn Ihnen diese Zahl Unbehagen bereitet, werden die vier Hebel sie mit ziemlicher Sicherheit um mehr als die Hälfte senken, ohne dass die Nutzer es bemerken – und Sie haben eine still wachsende Zeile auf der Cloud-Rechnung in eine Marge verwandelt, die Sie aktiv steuern. Profitabilität im grossen Massstab ist kein Problem, das man nach dem Launch löst; sie ist eine Architektur, die man davor wählt – und diese Wahl liegt bei Ihnen, solange sie noch günstig ist. Wenn Sie diese Rechnung mit Ihren echten Zahlen machen möchten, sprechen Sie uns an.