Das LLM-Kostenproblem: Warum KI-Workflows im zweiten Jahr unrentabel werden

Das LLM-Kostenproblem: Warum KI-Workflows im zweiten Jahr unrentabel werden

Vor einem Jahr unterhielt ich mich mit dem Geschäftsführer einer mittelgroßen Steuerberatungskanzlei. Sie hatten eine KI-gestützte Automatisierung gebaut, die eingehende Mandantenanfragen vorqualifiziert und Antwortentwürfe erstellt. Stolz zeigte er mir die OpenAI-Rechnung des ersten Monats: 47 Euro. "Damit sparen wir uns drei Stunden Arbeit pro Tag", sagte er, "die Investition rechnet sich täglich."

Vor zwei Wochen rief er mich an. Die monatliche OpenAI-Rechnung lag bei 1.840 Euro. Die Workflows liefen identisch, die Ersparnis war ähnlich, aber die Kostenseite hatte sich um den Faktor 39 vervielfacht. "Was ist passiert?", fragte er.

Genau das, was bei den meisten KI-Automatisierungen passiert, sobald sie produktiv werden: das Volumen wächst, die Prompts werden länger, die Workflows komplexer. Und plötzlich kostet das, was als Demo brillant funktioniert hat, mehr als die Mitarbeiterstunden, die es ersetzen sollte.

Dieser Artikel erklärt, warum LLM-Kosten in der Realität fast nie der Demo entsprechen, wo die größten Kostentreiber liegen, und welche Architekturentscheidungen Sie heute treffen sollten, damit Ihre KI-Automatisierung in zwei Jahren noch tragfähig ist.

Was eine Demo verschweigt

Eine typische LLM-Demo sieht so aus: ein einzelner Aufruf an GPT-5 oder Claude mit einem 200-Wörter-Prompt, eine schöne Antwort, Stoppuhr aus, Applaus. Der Kostenpunkt wird, wenn überhaupt, mit "ein paar Cent pro Anfrage" angegeben.

Diese Zahl ist nicht falsch. Sie ist nur unvollständig.

In der produktiven Realität sehen Aufrufe anders aus.

Erstens werden System-Prompts mitgeschickt, in denen die Persönlichkeit, das Verhalten und die Regeln des Modells beschrieben sind. Das sind in den meisten produktiven Setups 1.500 bis 3.000 Tokens pro Aufruf. Allein.

Zweitens kommen Few-Shot-Beispiele hinzu, also vier bis acht Beispielanfragen mit Beispielantworten, die dem Modell zeigen, wie es reagieren soll. Das addiert weitere 2.000 bis 5.000 Tokens.

Drittens wird Kontext eingespeist: bei einer E-Mail-Analyse die letzten zehn Mails dieses Mandanten, bei einer Vertragsprüfung der relevante Auszug aus den Mandantenakten, bei einem Chatbot die letzten zehn Gesprächsbeiträge. Das sind oft 3.000 bis 10.000 Tokens, manchmal mehr.

Viertens, und hier wird es interessant, antworten Modelle in der Praxis nicht in 50 Wörtern. Sie antworten in 300 bis 800 Tokens, weil sie zur Vollständigkeit neigen.

Wenn Sie diese vier Schichten addieren, landen Sie bei einer typischen produktiven Anfrage zwischen 8.000 und 18.000 Tokens. Bei den aktuellen Preisen für GPT-5 (Stand 2026: etwa 12 Dollar pro Million Input-Tokens, 48 Dollar pro Million Output-Tokens) reden wir über 11 bis 25 Cent pro Aufruf.

Ein Workflow, der hundert Mal am Tag läuft, kostet bei dieser Rechnung 11 bis 25 Euro. Pro Tag. Bei tausend Aufrufen sind es 110 bis 250 Euro. Pro Tag.

Dazu kommt: in der Demo läuft jeder Aufruf einmal. In der Produktion gibt es Retries (wenn das Modell sich verschluckt), Validierungen (wenn die Antwort nicht parsebar ist), und Cascades (wenn ein erster, billigerer Aufruf scheitert und ein zweiter, teurerer übernimmt).

Realer Kostenfaktor in der Produktion: drei- bis fünfmal so hoch wie die ersten Erfahrungswerte aus der Pilotphase. Das ist keine Schätzung, sondern mein Erfahrungswert aus Projekten, in denen ich später hinzugezogen wurde, um das Kostenproblem zu lösen.

Wo die Kosten wirklich entstehen

Wer LLM-Kosten kontrollieren will, muss verstehen, wo sie eigentlich entstehen. Es gibt drei dominante Treiber, die in fast allen Setups auftauchen.

Der größte Treiber ist der System-Prompt, der bei jedem Aufruf neu mitgeschickt wird.

Stellen Sie sich vor, Sie haben einen Workflow, der eingehende Support-Tickets klassifiziert. Der System-Prompt beschreibt Ihre 14 Kategorien, gibt Beispiele für jede, definiert Edge Cases, erklärt das gewünschte JSON-Format. Das sind 2.500 Tokens.

Bei 800 Tickets pro Tag werden diese 2.500 Tokens 800 Mal pro Tag verschickt. Das sind zwei Millionen Tokens pro Tag, allein für Inhalte, die sich nicht ändern. Bei aktuellen Preisen reden wir über 24 Dollar pro Tag, also 720 Dollar pro Monat, nur für die Wiederholung des immer gleichen Prompts.

Die Lösung heißt Prompt Caching, und sie wird in der Praxis fast nie genutzt. Anthropic, OpenAI und Google bieten alle Caching-Mechanismen an, die wiederholte Prompt-Teile zu einem Bruchteil des Preises verarbeiten. Wer Caching aktiviert und richtig nutzt, reduziert Input-Kosten oft um 80 bis 90 Prozent.

Der zweite Treiber sind unnötige Output-Tokens.

LLMs sind freundlich. Sie erklären, wenn Sie nicht ausdrücklich sagen, dass sie nicht erklären sollen. Sie geben Kontext. Sie wiederholen die Frage. Das ist in der Konversation angenehm und in der Automatisierung teuer.

Ich habe Workflows gesehen, in denen das Modell für eine Ja/Nein-Klassifikation 400 Tokens lang über die Begründung räsoniert, dann das Ergebnis liefert, dann nochmal zusammenfasst. Was in der Verarbeitung gebraucht wird: ein Wort. Was bezahlt wird: 400 Tokens.

Bei den heutigen Output-Preisen ist jeder unnötige Token vier bis acht Mal teurer als ein Input-Token. Output-Disziplin ist daher der Hebel mit der höchsten Rendite.

Der dritte Treiber ist Modellüberschuss.

Die meisten Workflows nutzen das beste verfügbare Modell, weil es das einfachste ist. Wer Claude Opus 4.7 oder GPT-5 verwendet, weil "das ist halt das beste", hat oft den teuersten Hammer für eine Schraube gewählt.

Eine Klassifikation in zwei Kategorien braucht kein Frontier-Modell. Das schafft Claude Haiku 4.5, das schafft GPT-5 Mini, das schafft sogar ein lokal gehostetes Llama 3.3 in vielen Fällen. Der Kostenunterschied zwischen einem Top-Modell und einem mittleren Modell liegt in der Größenordnung von Faktor 10 bis 30.

Wer alle Aufgaben mit dem Top-Modell macht, weil es bequem ist, zahlt eine Bequemlichkeitssteuer.

Warum das Volumen explodiert

Ein Effekt, den die meisten unterschätzen: KI-Automatisierungen werden im ersten Jahr fast immer ausgebaut, nicht abgebaut.

Was im Pilot mit hundert Aufrufen pro Tag startet, wird, wenn der Pilot funktioniert, in mehrere Use-Cases übertragen. Was als Antworthilfe für eingehende E-Mails begonnen hat, wird zur Erstellung von Angebotsentwürfen, zur Vorqualifizierung von Leads, zur Auswertung von Berichten. Jeder Use-Case multipliziert das Volumen.

Hinzu kommt: das Verhalten der Nutzer ändert sich. Im ersten Monat schicken Mitarbeiter zehn Anfragen in den KI-Assistenten, weil sie ihm noch nicht trauen. Im sechsten Monat schicken sie hundert. Was effizienter ist, wird häufiger genutzt. Das ist gut für die Nutzer und teuer für die Rechnung.

Ich habe ein Projekt erlebt, in dem ein Pilot mit 50 Aufrufen pro Tag startete. Nach drei Monaten waren es 380. Nach sieben Monaten 2.100. Die Funktionalität war im Wesentlichen dieselbe geblieben, aber die Akzeptanz war gewachsen. Die Rechnung folgte.

Wer plant, LLM-basierte Automatisierungen einzuführen, sollte deshalb mit dem Mehrfachen des Pilotvolumens rechnen, nicht mit dem Pilotvolumen selbst.

Die ehrliche TCO-Rechnung

Eine seriöse Wirtschaftlichkeitsrechnung für eine KI-Automatisierung berücksichtigt drei Kostenarten, von denen die LLM-Tokens nur eine sind.

Direkte Token-Kosten. Die monatliche Rechnung von OpenAI, Anthropic, Google oder Azure. Klar messbar.

Infrastruktur und Tooling. Vector-Datenbank, falls RAG genutzt wird. Logging-Tools für die Nachvollziehbarkeit. Monitoring für Halluzinationen. Ein Self-hosted-Setup für die Datenverarbeitung, wenn Datenschutz Cloud-Services ausschließt. Diese Kosten liegen in der Größenordnung von 200 bis 800 Euro pro Monat, je nach Komplexität.

Pflege und Anpassung. Modelle ändern sich. OpenAI veröffentlicht ein neues GPT, und die alten Prompts funktionieren nicht mehr gleich. Anthropic stellt ein Modell ein, und Sie müssen migrieren. Eine API ändert ihre Antwortstruktur, und Ihr Parser bricht. Plus: Ihre Anforderungen ändern sich, neue Edge Cases tauchen auf, das Setup muss nachjustiert werden. In der Praxis sind das ein bis zwei Personentage pro Monat für jeden produktiven LLM-Workflow.

Wenn Sie diese drei Posten addieren, ist die monatliche Rechnung selten nur die Token-Kosten. Sie ist Token-Kosten mal zwei bis drei.

Bei einer geplanten Ersparnis von 5.000 Euro pro Monat (etwa eine halbe Vollzeitstelle, die ersetzt wird) liegen die ehrlichen Gesamtkosten oft bei 1.500 bis 2.500 Euro pro Monat. Ein guter Business Case, aber nicht der "ein paar Cent pro Anfrage"-Case, mit dem das Projekt verkauft wurde.

Architekturentscheidungen, die Geld kosten

Bestimmte Architekturentscheidungen treiben die Kosten überproportional, ohne dass es jemandem auffällt. Vier davon sehe ich besonders häufig.

Eine Pipeline aus mehreren LLM-Aufrufen, wo einer reichen würde.

Ein typisches Muster: Aufruf 1 extrahiert Entitäten aus einer E-Mail. Aufruf 2 klassifiziert die Anfrage. Aufruf 3 entscheidet die nächste Aktion. Aufruf 4 erstellt einen Antwortentwurf. Vier Aufrufe pro Mail, je 5.000 Tokens, summiert sich.

In den meisten Fällen lassen sich diese Schritte zu einem einzigen Aufruf zusammenfassen, der die gleiche Aufgabe in einem Schritt löst. Der Token-Verbrauch sinkt um 60 bis 75 Prozent, weil System-Prompt und Kontext nur einmal mitgeschickt werden.

Die Ausnahme: wenn Sie unterschiedliche Modelle für unterschiedliche Schritte brauchen, etwa ein günstiges Modell für die Klassifikation und ein teures für die Antwortgenerierung, ist die Kette sinnvoll. Aber dann ist sie eine bewusste Entscheidung, keine Standardarchitektur.

Das gesamte Mandantengespräch im Kontext.

Bei Chat-Workflows wird häufig der gesamte Verlauf der Konversation bei jedem Aufruf mitgeschickt, damit das Modell den Kontext kennt. Bei einer Konversation mit zwanzig Wechseln summieren sich die Tokens schnell auf 30.000 bis 50.000 pro Aufruf, allein für die Historie.

Dabei reichen meistens die letzten drei bis fünf Wechsel plus eine kompakte Zusammenfassung der älteren Beiträge. Diese Zusammenfassung wird einmal generiert und dann immer wieder verwendet. Das spart in einer 30-Wechsel-Konversation locker 80 Prozent der Tokens.

Der RAG, der zu viel zurückgibt.

Retrieval-Augmented Generation ist eine elegante Lösung, um aktuelle Daten in LLM-Aufrufe einzuspeisen. Sie wird teuer, wenn der Retrieval-Schritt zu großzügig konfiguriert ist.

Ein typischer Fall: das System sucht nach einer Frage und findet die zehn relevantesten Textabschnitte aus der Wissensdatenbank. Jeder Abschnitt umfasst 500 Tokens. Macht 5.000 Tokens, die pro Anfrage zusätzlich verschickt werden, obwohl meistens drei Abschnitte ausreichen würden.

Die Disziplin, das Retrieval auf die wirklich nötige Tiefe zu beschränken, fehlt fast immer. Drei statt zehn Abschnitte sparen 70 Prozent der Kontext-Tokens, ohne die Antwortqualität spürbar zu reduzieren.

Das Modell, das schlauer sein soll, als nötig.

Ich habe Implementierungen gesehen, in denen für einfache Datenextraktion (Adresse, Telefonnummer, Auftragsnummer aus einer E-Mail extrahieren) GPT-5 verwendet wurde. Diese Aufgabe schafft jedes günstige Modell, mit identischer Genauigkeit.

Der Reflex, immer das beste Modell zu nehmen, kostet ohne Mehrwert. Eine Faustregel: wenn die Aufgabe klar formuliert und reproduzierbar ist, gehört sie auf das günstigste Modell, das sie löst. Nur die wirklich anspruchsvollen Schritte bekommen das Top-Modell.

Wie ehrliche Kostenkontrolle aussieht

Wer LLM-Kosten in den Griff bekommen will, braucht drei Dinge: Transparenz, Disziplin und Limits.

Transparenz heißt: Sie wissen, welcher Workflow wie viel kostet.

Bei den meisten Anbietern können Sie Kosten nach Projekt, API-Key oder Tag aufschlüsseln. Tun Sie das. Wenn ein Workflow die Hälfte der monatlichen Rechnung verursacht, sollten Sie das wissen, bevor die Rechnung kommt.

Konkret: jeder produktive LLM-Workflow bekommt seinen eigenen API-Key oder Tag. In der Anbieter-Konsole läuft täglich ein Report, der die Kosten pro Workflow zeigt. Das deckt unangenehme Überraschungen früh auf.

Disziplin heißt: Sie behandeln Tokens als Ressource, nicht als Selbstverständlichkeit.

Jeder Prompt sollte mit der Frage entwickelt werden: was ist der minimale Input, mit dem das Modell die Aufgabe lösen kann? Jede Antwort sollte mit der Frage konfiguriert werden: was ist die kürzeste Form, die noch nutzbar ist?

In der Praxis bedeutet das: System-Prompts überprüfen, ob alle Beispiele wirklich nötig sind. Output-Format strikt einschränken, etwa durch Constrained Generation oder JSON-Schema. Und ja, im Notfall in den Prompt schreiben "Antworte mit maximal einem Wort", wenn das die Aufgabe ist.

Limits heißt: Sie haben harte Stopps, bevor die Rechnung weh tut.

Tagesbudgets pro Workflow konfigurieren, wo möglich. Bei OpenAI gibt es projektbezogene Spend-Limits. Bei Anthropic können Sie Workspaces mit Budgets versehen. Sobald das Limit erreicht ist, stoppt das System, statt weiter zu produzieren.

Ein hartes Limit fühlt sich erst unangenehm an, bis der Tag kommt, an dem ein Bug in einem Workflow eine Endlosschleife produziert und das System tausendfach API-Aufrufe macht. Dann kostet das fehlende Limit drei- bis fünfstellige Beträge in einer Nacht. Solche Vorfälle sind nicht hypothetisch. Sie passieren regelmäßig.

Cache, Cache, Cache

Wenn ich nur einen einzigen Hebel benennen dürfte, wäre es Prompt Caching. Es ist die Maßnahme mit dem besten Verhältnis aus Aufwand und Wirkung, und sie wird systematisch übersehen.

Anthropic bietet seit 2024 Prompt Caching an, OpenAI seit Anfang 2025, Google seit Mitte 2025. Das Prinzip ist überall ähnlich: wiederholte Teile eines Prompts (System-Prompt, Few-Shot-Beispiele, statischer Kontext) werden vom Anbieter zwischengespeichert und für nachfolgende Aufrufe zu einem Bruchteil des normalen Preises verarbeitet.

Bei Anthropic kostet ein Cache-Hit etwa 10 Prozent des regulären Input-Preises. Bei OpenAI etwa 50 Prozent. Bei Google etwa 25 Prozent. Wenn Ihr System-Prompt 80 Prozent der Input-Tokens ausmacht (typischer Wert), und Sie diesen System-Prompt cachen, sinken Ihre Input-Kosten um 70 bis 90 Prozent.

In Zahlen: ein Workflow, der ohne Caching 2.000 Euro pro Monat kostet, kostet mit gut konfiguriertem Caching 400 bis 600 Euro pro Monat. Bei gleichem Volumen, gleicher Funktionalität.

Die Implementierung ist nicht trivial, aber überschaubar. Im Code muss der zu cachende Block (System-Prompt, Few-Shot-Beispiele) korrekt markiert werden, damit der Anbieter ihn als statisch erkennt. Dann läuft der Rest automatisch.

Ich treffe regelmäßig Setups, in denen jemand viele Stunden in Prompt-Optimierung gesteckt hat, um zwei Sätze zu kürzen, aber das Caching nicht aktiviert ist. Reihenfolge falsch.

Kleinere Modelle, größere Disziplin

Eine zweite Disziplin, die oft unterbleibt: das richtige Modell für die richtige Aufgabe.

GPT-5 oder Claude Opus 4.7 sind großartig, wenn die Aufgabe Nuancen erfordert. Sie sind verschwenderisch, wenn die Aufgabe routinisiert ist.

Ein praxistaugliches Schema:

Top-Modell (Claude Opus, GPT-5, Gemini Pro): Aufgaben, die echtes Verständnis brauchen. Antworten formulieren, längere Texte zusammenfassen, mehrstufige Argumentationen prüfen.

Mittleres Modell (Claude Sonnet, GPT-5 Mini, Gemini Flash): Aufgaben mit klarer Struktur. Klassifikationen mit fünf bis zwanzig Kategorien, Datenextraktion aus halbstrukturierten Quellen, einfache Zusammenfassungen.

Schmales Modell (Claude Haiku, GPT-5 Nano, lokales Llama): hochfrequente, klar umrissene Aufgaben. Binärklassifikationen, simple Extraktionen, Routing-Entscheidungen.

Die Kostenunterschiede zwischen diesen Klassen liegen typisch bei Faktor 5 bis 20 zwischen Mittel und Top, weiteren Faktor 3 bis 5 zwischen Schmal und Mittel. Wer alle drei Klassen einsetzt, statt für alles das Top-Modell zu nehmen, kann seine Gesamtkosten halbieren.

Die Investition ist der Test: jede Aufgabe einmal mit dem schmaleren Modell durchspielen, Qualität messen, entscheiden. Das sind ein bis zwei Stunden pro Use-Case, und es ist Geld wert.

Wann Self-Hosting sich rechnet

Eine Frage, die spätestens bei einer monatlichen LLM-Rechnung von 2.000 Euro aufkommt: wäre ein selbst gehostetes Open-Source-Modell günstiger?

Die ehrliche Antwort: meistens nein, manchmal ja.

Wann es sich lohnt: wenn Sie hohes, gleichmäßiges Volumen haben (deutlich über 5 Millionen Tokens pro Tag), die Aufgabe mit einem mittleren oder schmalen Modell lösbar ist, und Sie ohnehin IT-Kapazität haben, um eine GPU-Infrastruktur zu betreiben. Bei diesen Voraussetzungen ist ein lokal betriebenes Llama 3.3 oder Mistral Large oft 50 bis 70 Prozent günstiger als die entsprechende API-Nutzung.

Wann es sich nicht lohnt: wenn Ihr Volumen schwankt, Sie Spitzen haben, die Top-Modell-Qualität verlangen, oder Sie keine Kapazität für GPU-Operations haben. Bei sporadischer Nutzung sind die Fixkosten der Server höher als die variable API-Rechnung.

In der Praxis ist Self-Hosting eine Lösung für die wenigen Aufgaben mit hohem Volumen und stabiler Anforderung. Für den Mix typischer Geschäfts-Use-Cases ist es zu schwer, zu pflegen und zu skalieren.

Wer dennoch testen möchte: vLLM oder Text Generation Inference von Hugging Face sind die typischen Frameworks. Eine A10G- oder L4-GPU kostet etwa 250 bis 400 Euro pro Monat in Cloud-Umgebungen. Damit lassen sich Modelle bis 70 Milliarden Parameter mit vernünftiger Geschwindigkeit betreiben.

Was Sie diese Woche tun sollten

Wer heute KI-Automatisierungen plant oder im Einsatz hat, sollte die folgenden Schritte nicht später einplanen, sondern jetzt:

Erstens: Kosten transparent machen. Pro Workflow einen eigenen API-Key oder Tag, wöchentliche Auswertung der Kosten. Wenn Sie nicht wissen, welcher Workflow wie viel kostet, können Sie nicht steuern.

Zweitens: Caching aktivieren. Bei Anthropic, OpenAI und Google in den jeweiligen API-Aufrufen die Cache-Marker setzen. Das ist die Maßnahme mit dem besten Aufwand-Nutzen-Verhältnis.

Drittens: Modellwahl überprüfen. Jeden produktiven Workflow einmal mit dem nächst-kleineren Modell testen. Wenn die Qualität reicht, wechseln. Sie werden überrascht sein, wie oft das funktioniert.

Viertens: Output-Disziplin. System-Prompts so anpassen, dass das Modell maximal kompakt antwortet. JSON-Schemas, Stop-Tokens, klare Längenvorgaben.

Fünftens: Limits setzen. Tagesbudget pro Workflow, hartes Stopp bei Überschreitung. Das verhindert die Endlosschleife, die zur überraschenden Rechnung führt.

Diese fünf Maßnahmen reduzieren in den meisten Setups die monatlichen LLM-Kosten um 40 bis 70 Prozent, ohne dass die Funktionalität leidet. Der Aufwand: ein bis zwei Tage pro Workflow.

Die Frage, die niemand stellt

Bevor Sie die nächste KI-Automatisierung einführen, stellen Sie sich folgende Frage: Was kostet diese Automatisierung pro Aufruf, wenn sie sich verzehnfacht?

Lautet die Antwort "ein paar Cent pro Aufruf, das skaliert problemlos", haben Sie wahrscheinlich nur an die Token-Kosten der ersten Schicht gedacht. Multiplizieren Sie das Ergebnis mit drei bis fünf, addieren Sie Infrastruktur und Pflege, dann haben Sie den realistischen Wert.

Lautet die Antwort "weiß ich nicht, wir lassen uns überraschen", wird die Überraschung kommen. Sie wird in einer Excel-Tabelle vom Controller landen, zwei Quartale nach Go-Live, mit der Frage, warum die Cloud-Kosten so explodiert sind.

Lautet die Antwort "wir haben Caching aktiviert, das richtige Modell gewählt, Output-Disziplin in den Prompts und harte Limits", dann haben Sie eine Automatisierung gebaut, die auch im zweiten Jahr noch wirtschaftlich ist.

Diese Frage zu stellen ist mühsam. Sie nicht zu stellen ist deutlich teurer.

Wer wissen möchte, wie wirtschaftlich die eigenen KI-Workflows wirklich sind und wo die größten Kostenhebel liegen, bekommt im kostenlosen Automations-Check in etwa 30 Minuten ein klares Bild.