KI-Kosten im Shop steuern: Tokens, Caching, Modelle

Die Preise je Token fallen schneller als fast jeder andere IT-Kostenblock: Epoch AI misst über verschiedene Fähigkeitsniveaus hinweg einen Rückgang von im Median 50-fach pro Jahr (Epoch AI). Trotzdem berichtet ein Drittel der deutschen Unternehmen mit KI im Einsatz von deutlich höheren Kosten als erwartet: 33% (Bitkom). Der Widerspruch löst sich auf, sobald man die Rechnung aufschlüsselt. Nicht der Preis je Token treibt die Kosten, sondern Kontextlänge, Ausgabelänge und Aufruffrequenz. Wer KI-Funktionen für Online-Shops vom Prototyp in den Dauerbetrieb bringt, braucht deshalb ein Kostenmodell, das vor dem Livegang steht.

Das Kostenmodell verstehen: Eingabe, Ausgabe, Kontext

Sprachmodelle werden nach Tokens abgerechnet, und zwar getrennt nach Eingabe und Ausgabe. Ein Token entspricht grob drei bis vier Zeichen deutschen Fließtexts. Entscheidend für die Kalkulation sind zwei Eigenschaften dieser Abrechnung: Ausgabe-Tokens kosten bei den gängigen Modellklassen ein Vielfaches der Eingabe-Tokens, typischerweise etwa das Fünffache (Projekterfahrung). Und die Eingabe umfasst nicht nur die aktuelle Frage, sondern den gesamten Kontext, den Sie mitschicken: Systemanweisung, Produktdaten, Verlauf, angehängte Dokumente.

Daraus folgt der wichtigste Satz dieses Artikels: Die Kontextlänge ist der Hauptkostentreiber, nicht die Antwortqualität. Ein Assistent, der bei jeder Nachricht 8.000 Tokens Katalogauszug mitschickt, kostet bei zehn Nachrichten das Zehnfache dieses Kontexts, obwohl sich der Katalog zwischen den Nachrichten nicht geändert hat. Die API ist zustandslos: Jeder Aufruf trägt die komplette Vorgeschichte erneut, und jede Wiederholung wird erneut berechnet.

Aus dieser Struktur ergibt sich die richtige Steuerungsgröße. Eine Monatsrechnung sagt Ihnen, dass etwas teuer war, aber nicht warum. Die belastbare Kennzahl ist die Kosten je Interaktion: je erzeugtem Produkttext, je Chat-Antwort, je klassifiziertem Ticket. Erst diese Größe lässt sich gegen einen Nutzen stellen und erst sie macht Prognosen möglich, wenn das Volumen wächst.

Kosten je Anwendungsfall kalkulieren statt Monatsrechnung deuten

Ein Shop betreibt selten eine KI-Funktion, sondern meist vier bis sechs. Sie unterscheiden sich um Größenordnungen in Kosten und Nutzen, verschwinden in der Sammelrechnung aber hinter einer einzigen Zahl. Der erste Schritt zur Kostenkontrolle ist deshalb banal und wird trotzdem selten gemacht: jede Funktion einzeln kalkulieren, mit Tokens je Vorgang und erwartetem Volumen.

Neben die Kosten gehört der Nutzen, und zwar als Deckungsbeitrag statt als Bauchgefühl. Für die Produkttext-Generierung ist die Rechnung meist eindeutig: Die eingesparte Redaktionszeit je Artikel lässt sich mit einem internen Stundensatz bewerten. Für den Beratungsdialog wird es unschärfer, aber nicht unmöglich: Wenn Sie den Anteil der Sitzungen mit Chat-Kontakt und deren Bestellquote gegen eine Vergleichsgruppe stellen, erhalten Sie eine belastbare Näherung. Diese Denkweise ist dieselbe, die auch bei der Absicherung der Marge im E-Commerce trägt.

Dass diese Rechnung noch selten sauber geführt wird, zeigt der Blick auf die Wirkungsseite. Laut der von Stanford HAI ausgewerteten Unternehmensbefragung berichten Organisationen die größten Kostensenkungen in Software-Entwicklung und Fertigung mit jeweils 56% (Stanford HAI, AI Index 2026), während Umsatzeffekte am häufigsten für Marketing und Vertrieb mit 67% (Stanford HAI, AI Index 2026) sowie für Produktentwicklung mit 62% (Stanford HAI, AI Index 2026) genannt werden. Auf Unternehmensebene berichten hingegen nur 39% (McKinsey) der Befragten eine messbare EBIT-Wirkung, und lediglich rund 6% (McKinsey) ordnen der KI-Nutzung mehr als fünf Prozent ihres EBIT zu.

Eine KI-Funktion ohne Kosten je Vorgang ist ein Experiment. Erst mit dieser Zahl wird sie ein Produkt, das man skalieren oder abschalten kann.

XICTRON Entwicklungsteam

Sieben Hebel, die die Rechnung wirklich senken

Die folgenden sieben Maßnahmen wirken unterschiedlich stark, aber sie wirken in dieser Reihenfolge am schnellsten. Wichtig ist die Reihenfolge deshalb, weil die ersten drei rein technisch sind und keine fachliche Abstimmung brauchen, während die letzten vier Entscheidungen über Verhalten und Qualität verlangen.

1. Prompt-Caching wiederkehrender Kontexte. Systemanweisung, Rechtstexte, Versandregeln und Katalogausschnitte ändern sich zwischen zwei Aufrufen typischerweise nicht. Wird dieser Präfix zwischengespeichert, fällt er beim nächsten Aufruf zu einem Bruchteil des Eingabepreises an.
2. Ergebnis-Caching identischer Anfragen. Dieselbe Frage zu denselben Daten erzeugt dieselbe Antwort. Ein Cache-Schlüssel aus normalisierter Frage plus Datenstand fängt einen erheblichen Teil der Anfragen ab, bevor ein Modell überhaupt aufgerufen wird.
3. Batch-Verarbeitung für Massenläufe. Alt-Texte, Kategorietexte oder Datenanreicherung sind nicht zeitkritisch. Asynchrone Sammelverarbeitung wird deutlich günstiger abgerechnet als Einzelaufrufe in Echtzeit, bei den gängigen Anbietern in der Größenordnung der Hälfte.
4. Modell-Routing je Aufgabe. Klassifizierung, Extraktion und Kurzentscheidungen brauchen kein großes Modell. Ein kleines Modell für strukturierte Aufgaben und ein großes nur für Freitext senkt die Rechnung ohne spürbaren Qualitätsverlust an der Kundenoberfläche.
5. Kontext gezielt kürzen statt Katalog anhängen. Statt 200 Produkte mitzuschicken, liefert eine semantische Produktsuche die fünf relevanten. Das ist der Hebel mit dem besten Verhältnis von Aufwand zu Wirkung.
6. Vorab-Filter gegen sinnlose Aufrufe. Leere Eingaben, Dubletten innerhalb weniger Sekunden, offensichtliche Bot-Muster und Anfragen außerhalb des fachlichen Rahmens sollten vor dem Modellaufruf abgewiesen werden, nicht danach.
7. Ausgabelänge begrenzen. Ein hartes Token-Limit plus ein validiertes Ausgabeschema verhindert ausufernde Antworten. Weil Ausgabe-Tokens die teuersten sind, wirkt diese Maßnahme überproportional.

Beim Prompt-Caching lohnt ein genauerer Blick, weil die Mechanik oft missverstanden wird. Zwischengespeichert wird ein Präfix, also der Anfang der Anfrage in exakt gleicher Byte-Folge. Ändert sich irgendetwas davor, fällt alles danach aus dem Cache. Ein in die Systemanweisung eingesetzter Zeitstempel, eine nicht sortierte JSON-Serialisierung oder ein pro Nutzer variierender Werkzeugsatz reichen aus, um die Trefferquote auf null zu drücken. Stabiles zuerst, Variables zuletzt lautet die Regel.

Batch-Verarbeitung ist der am häufigsten übersehene Hebel, weil sie eine Umstellung im Ablauf verlangt. Massenläufe gehören in eine Warteschlange und nicht in den Request-Zyklus des Shops. Wie ein solcher Aufbau produktiv sauber läuft, beschreibt der Beitrag zu Message Queue und Workern im Produktivbetrieb. Der Nebeneffekt ist wichtiger als der Rabatt: Sammelläufe sind planbar, unterbrechbar und lassen sich mit einem Kontingent deckeln.

Budget-Governance: Limits, Kostenstellen, Alarme

Technische Hebel senken den Preis je Vorgang. Sie schützen aber nicht gegen den Fall, dass die Menge der Vorgänge unerwartet steigt. Genau dafür braucht es Governance, und die ist im Kern unspektakulär: Jede KI-Funktion bekommt ein eigenes Limit, eine eigene Kostenstelle und einen eigenen Alarm.

• Limit je Funktion, nicht je Konto. Ein Tages- und ein Monatslimit pro Feature verhindert, dass ein außer Kontrolle geratener Massenlauf das Budget des Kundendialogs aufbraucht.
• Kostenstelle je Feature mitführen. Jeder Modellaufruf wird mit Feature-Kennung, Modell, Eingabe-, Ausgabe- und Cache-Tokens protokolliert. Ohne diese Zuordnung ist jede spätere Optimierung Ratespiel.
• Alarm bei Ausreißern statt Monatsbericht. Sinnvoll sind zwei Schwellen: eine absolute (Tagesbudget zu 80 Prozent ausgeschöpft) und eine relative (Kosten je Vorgang weicht um mehr als ein Drittel vom Mittelwert ab).
• Abschaltpfad ohne Deployment. Jede KI-Funktion braucht einen Konfigurationsschalter, mit dem sie sich in Minuten deaktivieren oder auf ein günstigeres Modell umlenken lässt.
• Degradationsstufe definieren. Was passiert, wenn das Limit erreicht ist? Fehlermeldung, klassische Suche, Kontaktformular oder Warteschlange sind vier vertretbare Antworten, ein stiller Ausfall ist keine.
• Kosten in der Definition of Done. Ein KI-Feature gilt erst als fertig, wenn Kosten je Vorgang, Limit, Kostenstelle und Degradationsstufe dokumentiert sind.

Der häufigste Fehler ist ein Limit ohne definierte Reaktion. Wenn das Budget greift und die Funktion dann kommentarlos abbricht, entstehen Supportfälle, deren Bearbeitung mehr kostet als die eingesparte Inferenz. Die Degradationsstufe ist deshalb Teil der fachlichen Anforderung, nicht ein technisches Detail. Für wiederkehrende Abläufe gilt dasselbe Prinzip wie bei jeder anderen Prozess-Automatisierung: Der Ausnahmefall gehört in den Entwurf.

Missbrauchsschutz für öffentliche KI-Endpunkte

Ein KI-Endpunkt, den jeder Besucher ohne Anmeldung aufrufen kann, ist aus Sicht eines Angreifers kostenlose Rechenleistung. Wer ihn ungeschützt betreibt, bezahlt fremde Inferenz. Der Angriff braucht keine Raffinesse: Ein Skript, das den Chat-Endpunkt in einer Nacht zehntausendfach aufruft, erzeugt eine Rechnung, die den Monatsplan sprengt, ohne dass ein Alarm im klassischen Sicherheitsmonitoring anschlägt.

• Rate-Limit pro IP und pro Sitzung, mit unterschiedlichen Schwellen: eine kurze (Aufrufe pro Minute) und eine lange (Aufrufe pro Stunde und Tag).
• Sitzungskontingent statt reiner Frequenzbremse. Ein Beratungsdialog braucht selten mehr als etwa zwanzig Antworten. Ein hartes Kontingent je Sitzung begrenzt den Schaden, auch wenn die Frequenz unauffällig bleibt.
• Eingabelänge begrenzen. Ein Feld ohne Längenbegrenzung lädt dazu ein, den Kontext mit Fremdtext zu fluten und so die Kosten je Aufruf zu vervielfachen.
• Herkunft prüfen. Same-Origin-Prüfung, kurzlebige Tokens und ein serverseitiger Proxy verhindern, dass der Endpunkt aus fremden Anwendungen heraus genutzt wird.
• Kosten pro Sitzung protokollieren. Wer die teuersten Sitzungen eines Tages sehen kann, erkennt Missbrauchsmuster typischerweise binnen Stunden statt am Monatsende.
• Anonyme Nutzung begrenzen, angemeldete Nutzung großzügiger behandeln. Diese Abstufung schützt das Budget, ohne echte Kunden auszubremsen.

Make or Buy: ab wann Eigenbetrieb rechnerisch interessant wird

Sobald die Rechnung sichtbar wird, kommt die Frage nach dem Eigenbetrieb. Sie ist berechtigt, wird aber meist zu früh gestellt und mit den falschen Zahlen geführt. Der Vergleich lautet nicht API-Preis gegen Serverpreis, sondern API-Rechnung gegen Vollkosten eines dauerhaft betriebenen Modells.

Rechnerisch interessant wird der Eigenbetrieb erst, wenn zwei Bedingungen gleichzeitig erfüllt sind: Die monatliche Schnittstellenrechnung übersteigt die Vollkosten einer dauerhaft vorgehaltenen Beschleuniger-Kapazität deutlich, und die Auslastung liegt stabil oberhalb von etwa 40 Prozent (Projekterfahrung). Unterhalb dieser Schwelle bezahlen Sie Leerlauf. Für die meisten mittelständischen Shops ist das ein klares Argument gegen den Eigenbetrieb des Sprachmodells, während kleinere Spezialmodelle für Klassifizierung oder Einbettungen durchaus im eigenen Hosting sinnvoll laufen können.

Übersehen werden regelmäßig dieselben Fixkosten: Bereitschaft außerhalb der Geschäftszeiten, Modell- und Treiberpflege, Lastspitzen-Reserve, ein zweiter Standort für die Ausfallsicherheit sowie der Personalaufwand für Qualitätsvergleiche bei jedem Modellwechsel. Wer diese Positionen in die Rechnung aufnimmt, verschiebt den Break-even meist deutlich nach oben. Eine nüchterne Beratung zur Architekturentscheidung spart hier mehr als jede Preisverhandlung.

Durchgerechnet: ein mittelständischer Shop

Zum Abschluss ein durchgerechnetes Beispiel. Ausgangslage ist ein Shop mit rund 45.000 Sitzungen im Monat, etwa 18.000 Artikeln und vier KI-Funktionen im Betrieb. Alle Werte sind Beispielwerte auf Basis typischer Mengengerüste und sollen das Rechenraster zeigen, nicht Ihre Zahlen ersetzen.

Die Ersparnis beträgt rund 62 Prozent, ohne dass eine Funktion abgeschaltet oder die Antwortqualität an der Kundenoberfläche verändert wurde. Sie entsteht aus der Summe der Hebel: Prompt-Caching des gemeinsamen Vorspanns im Dialog, Ergebnis-Cache für wiederkehrende Fragen, Batch-Läufe für Alt-Texte und Produkttexte, ein kleines Modell für die Ticket-Klassifizierung sowie ein knapperer Kontext durch semantische Vorauswahl statt Katalogauszug.

Interessanter als die Ersparnis ist die zweite Zahl. Ohne Rate-Limit und Sitzungskontingent kann ein einzelner automatisierter Zugriff auf den öffentlichen Chat-Endpunkt in einer Nacht 40.000 zusätzliche Antworten auslösen. Zum Basispreis wären das 320 Euro an einem einzigen Tag und damit mehr als die gesamte geplante Monatsrechnung. Der Missbrauchsschutz ist in dieser Rechnung also nicht der letzte Punkt der Liste, sondern derjenige mit dem größten Einzelhebel auf das Risiko.

KI-Funktionen mit Kostenkontrolle von Anfang an bauen

Die Verbreitung sorgt dafür, dass diese Frage kein Sonderthema mehr ist. 41% (Bitkom) der deutschen Unternehmen ab 20 Beschäftigten setzen KI bereits ein, nach 17% (Bitkom) im Vorjahr, weitere 48% (Bitkom) planen oder diskutieren den Einsatz. International liegt der Anteil der Organisationen mit KI in mindestens einem Geschäftsbereich bei 88% (Stanford HAI, AI Index 2026) nach 78% (Stanford HAI, AI Index 2026) im Vorjahr, in Europa sogar bei 91% (Stanford HAI, AI Index 2026). Wer heute eine KI-Funktion baut, baut sie in ein Umfeld, in dem der Wettbewerb dieselbe Technik nutzt. Der Unterschied entsteht nicht durch den Zugang, sondern durch die Wirtschaftlichkeit.

Die gute Nachricht: Kostenkontrolle ist kein Nachrüstprojekt, sondern eine Entwurfsentscheidung. Eine Caching-Schicht, ein Modell-Router, eine Kostenprotokollierung je Feature und ein Limit mit definierter Degradation sind zusammen ein überschaubarer Baustein, wenn sie von Beginn an vorgesehen sind. Nachträglich in eine gewachsene Integration eingezogen, kosten dieselben Bausteine ein Vielfaches, weil Prompt-Aufbau, Datenzugriff und Fehlerbehandlung neu geschnitten werden müssen.

XICTRON entwickelt KI-Funktionen für Online-Shops mit genau dieser Aufstellung: Prompt- und Ergebnis-Caching als eigene Schicht, Modell-Routing je Aufgabe, Batch-Pfade für Massenläufe, Budget-Limits mit Degradationsstufe je Feature sowie ein Reporting, das Kosten je Vorgang und Feature sichtbar macht. Damit steht die Wirtschaftlichkeit einer KI-Funktion vor dem Livegang fest und nicht erst mit der ersten Rechnung.

Häufig gestellte Fragen