Zuerst die Schlussfolgerung: Wenn Kundenservice-Bots Geld verbrennen, liegt es zu 80 % nicht am hohen Stückpreis des Modells, sondern an der Art und Weise, wie die Aufrufe erfolgen. Ein interner After-Sales-Q&A-Bot mit einigen Tausend täglichen aktiven Nutzern hat im ersten Monat nach dem Start die Rechnung direkt auf das Dreifache des Budgets getrieben. Bei der Analyse stellte sich heraus: Der Modell-Stückpreis hatte sich kein bisschen verändert – es waren alles verborgene Kosten in der Aufrufstruktur. Dieser Artikel dokumentiert den Analyseprozess. Wer sich mit LLM-API-Kostenoptimierung beschäftigt, kann die eigene Rechnung Punkt für Punkt durchgehen.
Wie sich eine auffällige Rechnung zeigt
Das Merkmal einer Anomalie ist nicht „hohe Gesamtsumme", sondern „seltsame Struktur". Wir haben die täglichen Aufrufdetails herausgezogen und drei Unstimmigkeiten gefunden: An den Tagen mit dem höchsten Aufrufvolumen stieg die durchschnittliche Token-Zahl pro Anfrage; der Anteil der Wiederholungsversuche lag bei fast 20 %; bei derselben Nutzerfrage reichte die Spanne von einigen Hundert Token bis zu über zehntausend Token – extrem hohe Varianz. Diese drei Punkte zusammen genügen, um zu erkennen, dass das Problem nicht auf der Modellseite liegt, sondern in unserer eigenen Aufrufkette.
Vier verborgene Kostenfaktoren, einer versteckter als der andere
Erstens: Das Flaggschiffmodell erledigt grobe Arbeit. Anfangs sind wir den bequemen Weg gegangen und haben alle Anfragen einheitlich über das Flaggschiffmodell laufen lassen. Doch im Kundenservice-Szenario sind über 70 % Aufgaben wie Intent-Erkennung und feste Textbausteine – etwa „Wo ist meine Bestellung" oder „Wie funktioniert die Rücksendung". Für solche Aufgaben reicht ein kleines Modell völlig aus, bei einer Kostenersparnis um eine Größenordnung. Das Flaggschiffmodell „Öffnungszeiten" beantworten zu lassen, ist wie mit einem LKW Essen auszuliefern.
Zweitens: Kontext bläht sich unkontrolliert auf. In mehrstufigen Dialogen haben wir den gesamten Nachrichtenverlauf wieder mit hineingepackt. Wenn der Nutzer bis zur zehnten Runde chattet, macht der Verlauf allein schon den Großteil der Token aus. Noch problematischer: Vieles aus dem Verlauf hat mit der aktuellen Frage überhaupt nichts zu tun und läuft einfach mit. Kontext wird nicht klüger, je länger er ist – ab einer bestimmten Länge ist der Genauigkeitsgewinn begrenzt, die Kosten steigen aber linear.
Drittens: Retry-Sturm. Wir hatten einen einfachen Retry bei Fehlern eingerichtet, aber ohne Backoff und Circuit Breaking. Bei gelegentlichen Upstream-Timeouts wurde dieselbe Batch von Anfragen immer wieder draufgeprügelt – einmal fehlgeschlagen, einmal wiederholt, der Retry schlägt wieder fehl, nochmal wiederholt. Diese Aufrufe auf der Rechnung sind komplett umsonst, und der Nutzer sieht trotzdem nur eine Fehlermeldung.
Viertens: Doppelte Abrechnung von Streaming und Non-Streaming. Das wird am leichtesten übersehen. Einige unserer Ketten haben für die Nachbearbeitung mit vollständigem Ergebnis einen Non-Streaming-Aufruf gemacht; das Frontend wollte aber den Typewriter-Effekt, also nochmal ein Streaming-Aufruf. Dieselbe Frage, zwei Rechnungen. Später haben wir auf Streaming-Empfang mit lokalem Zusammensetzen umgestellt – erst dann verschwand diese doppelte Kostenposition.
Wie man hierarchisches Routing umsetzt
Der Ansatz ist nicht kompliziert: nach Aufgabenschwierigkeit aufteilen. Intent-Erkennung, Slot-Extraktion, feste Textbausteine laufen über leichte Modelle; wirklich komplexe Konversationen, die Reasoning, mehrstufige Entscheidungen und emotionale Beruhigung erfordern, gehen erst an das Flaggschiffmodell. Dazwischen kommt eine Modell-Gateway-Schicht, die die Entscheidung trifft: Die Anfrage kommt herein, durchläuft zuerst einen Klassifikator, bekommt ein Aufgaben-Tag und wird dann je nach Tag an das entsprechende Modell geroutet.
Wir nutzen die Logik der automatischen Auswahl des optimalen Modells je Aufgabe und haben auf dem Multi-Modell-Routing von SiCore TokenWorks eine Vergleichsrunde laufen lassen. Nach dem Umschalten einfacher Aufgaben auf leichte Modelle gingen die Gesamtkosten deutlich zurück, und die Antworten wurden schneller. Der Schlüssel liegt hier nicht darin, „welches Modell man verwendet", sondern darin, dass die Mapping-Tabelle „welche Aufgabe bekommt welches Modell" kontinuierlich nachjustiert wird. Anfangs haben wir nach Erfahrung konfiguriert; nach zwei Wochen Laufzeit haben wir anhand der tatsächlichen Trefferraten neu kalibriert – das Ergebnis war viel besser als die Pi-mal-Daumen-Konfiguration. Der Vorteil der einheitlichen Multi-Modell-Anbindung zeigt sich genau hier: Für einen Wechsel der Routing-Strategie muss kein Business-Code geändert werden, ein Adjustment in der Gateway-Schicht genügt.
Rechnungsvergleich vor und nach der Optimierung
Keine konkreten Zahlen, nur Verhältnisse. Das Gesamtaufrufvolumen blieb unverändert, weil die Nutzerzahl unverändert blieb. Die Gesamtkosten sanken um etwa 60 %, wobei der Anteil der Flaggschiffmodell-Aufrufe von nahezu 100 % auf rund 30 % fiel; der Rest wurde auf leichte Modelle umgeleitet. Retry-bezogene Aufrufe wurden von fast 20 % auf einen einstelligen Prozentbereich gedrückt. Die durchschnittliche Token-Zahl pro Anfrage sank um etwa 40 %, hauptsächlich durch Kontext-Kürzung. Die doppelte Streaming-Abrechnung ging direkt auf null. Unterm Strich: von dreifach über Budget zurück ins Budget – mit Reserve.
Wie man Monitoring und Alarme konfiguriert
Das Eingesparte muss man verteidigen – und das geht über Monitoring, nicht über Selbstdisziplin. Wir haben vier Alarme eingerichtet: Auslösung, wenn die Token-Zahl einer einzelnen Anfrage einen Schwellenwert überschreitet – Schutz vor Kontext-Außer-Kontrolle; Auslösung, wenn die Retry-Rate einen festgelegten Anteil überschreitet – Schutz vor Retry-Stürmen; Auslösung, wenn der Anteil der Flaggschiffmodell-Aufrufe anomal steigt – ein Zeichen dafür, dass das Routing möglicherweise versagt; Auslösung, wenn der tägliche Kostenanstieg im Vergleich zum Vortag einen Schwellenwert überschreitet. Diese vier müssen nicht komplex sein – Tagesaggregation und Alarm bei Überschreitung reichen aus. Im Token-Abrechnungsmodell akkumulieren sich die Kosten in Echtzeit; wer bis zum Monatsende auf die Rechnung wartet, um dann zu optimieren, hat das Geld bereits ausgegeben.
In einem Satz zusammengefasst: Der größte Kostenblock beim Kundenservice-Bot liegt in der Aufrufstruktur, nicht im Modell-Stückpreis. Wenn man die vier Dinge – Layered Routing, Kontext-Kürzung, Retry-Kontrolle und Streaming-Vereinheitlichung – solide umsetzt, sinkt die Rechnung von selbst. Und als Erweiterung: Falls in Ihrem Szenario auch RAG-Retrieval zum Einsatz kommt, lohnt es sich, die Anzahl der abgerufenen Vektoren aus der Vektordatenbank nach derselben Logik ebenfalls einmal zu überprüfen.