Was kostet ein LLM im Betrieb wirklich?

Die schnelle Antwort zuerst: Ein Large Language Model kostet im produktiven Betrieb nicht einfach einen festen Betrag pro Monat. Unternehmen bezahlen bei API-basierter Nutzung in der Regel für den tatsächlich verarbeiteten Input sowie den Output des LLM (technisch auch “Tokens” genannt). Hinzu können weitere Modellaufrufe, Tools sowie die verwendete Infrastruktur kommen. Entscheidend für einen belastbaren Business Case ist deshalb nicht der Preis eines KI-Abos. Relevant sind die Kosten eines vollständig bearbeiteten Geschäftsvorgangs und die Frage, welches Setup die benötigte Qualität zuverlässig erreicht. 

Warum ein KI-Abo kein guter Maßstab für API-Kosten ist 

Viele Menschen lernen Large Language Models über ChatGPT, Claude oder vergleichbare Anwendungen kennen. Für einen festen monatlichen Betrag können sie dort umfangreich mit leistungsfähigen Modellen arbeiten. Daraus entsteht schnell die Erwartung, dass eine Unternehmensanwendung mit einem LLM im Hintergrund ähnlich günstig sein müsste. 

Diese Rechnung funktioniert nicht, weil Subscription und API-Nutzung unterschiedlichen Preismodellen folgen. 

Bei einer API wird typischerweise nach der tatsächlichen Nutzung abgerechnet. Die Preise unterscheiden sich zwischen Anbietern, Modellfamilien und teilweise auch nach Art der Verarbeitung erheblich. 

Wie wenig sich der Preis einer Subscription auf die tatsächlichen Rechenkosten übertragen lässt, hat OpenAI selbst gezeigt. CEO Sam Altman erklärte Anfang 2025, dass OpenAI selbst mit dem damals 200 US-Dollar teuren ChatGPT-Pro-Abo Geld verlor, weil Kund:innen den Dienst deutlich intensiver nutzten als erwartet. 

Für Unternehmen folgt daraus eine einfache Konsequenz. Die Kosten eines produktiven LLM-Prozesses müssen aus dessen tatsächlicher Nutzung berechnet werden, nicht aus dem Preis eines Chat-Abos. 

Die Kosten entstehen pro Prozess, nicht pro Mitarbeiter:in 

Für die Kalkulation von API-Kosten sind zunächst zwei Begriffe wichtig. Input-Tokens sind die Textbestandteile, die an das Modell gesendet werden, beispielsweise System-Prompt, Nutzeranfrage und zusätzlicher Kontext. Output-Tokens sind die Bestandteile der Antwort, die das Modell erzeugt. Anbieter rechnen beide Mengen üblicherweise separat ab und verlangen für Output häufig einen anderen Preis als für Input. 

Für eine erste Kostenschätzung braucht es noch kein komplexes FinOps-Modell. Im Kern reichen die Anzahl der Durchläufe sowie die durchschnittlichen Input- und Output-Mengen. 

Anzahl der Durchläufe × durchschnittliche Input-Tokens × Input-Preis 

plus 

Anzahl der Durchläufe × durchschnittliche Output-Tokens × Output-Preis 

Damit wird sichtbar, warum zwei scheinbar ähnliche KI-Anwendungen wirtschaftlich völlig unterschiedlich aussehen können. 

Ein Prozess mit 50 Durchläufen am Tag verhält sich anders als einer mit 50.000. Bei kleinen Volumina kann eine aufwendige Token-Optimierung mehr Aufwand verursachen, als sie an Nutzungskosten einspart. Bei hohen Volumina wird dagegen bereits eine kleine Verbesserung pro Request zu einem relevanten Kostenhebel. 

Unternehmen sollten deshalb nicht nur fragen, was ein Modell kostet. Die wirtschaftlich relevantere Kennzahl lautet Kosten pro erfolgreich bearbeitetem Geschäftsvorgang. 

Das stärkste LLM ist nicht automatisch das richtige 

Eine verbreitete Annahme aus unserer Projektpraxis lautet, dass für eine wichtige oder vermeintlich komplexe Aufgabe auch das leistungsfähigste verfügbare Modell eingesetzt werden sollte. 

Das klingt plausibel, führt aber häufig zu unnötigen Kosten. 

Viele Aufgaben in Unternehmensprozessen sind für aktuelle LLMs weniger anspruchsvoll, als sie zunächst erscheinen. Dazu gehören beispielsweise die Klassifikation von Texten, die Extraktion bestimmter Informationen, die Erzeugung strukturierter Daten, Zusammenfassungen oder die Vorbereitung standardisierter Antworten. Für solche Aufgaben kann ein kleineres Modell bereits die erforderliche Qualität erreichen. 

Hinzu kommt nach unserer Erfahrung ein weiterer Faktor. Kleinere Modelle antworten bei vielen Workloads schneller. Wenn ein Mensch unmittelbar auf das Ergebnis wartet, ist diese Latenz selbst ein Qualitätsmerkmal. 

Die Modellauswahl ist deshalb keine Rangliste. Sie ist eine Optimierungsaufgabe zwischen Qualität, Kosten, Geschwindigkeit sowie technischen und regulatorischen Anforderungen. 

Ohne messbares „gut genug“ lässt sich kein Modell sinnvoll auswählen 

Damit entsteht eine entscheidende Frage. Wann reicht ein kleineres Modell tatsächlich aus? 

„Die Antworten sehen ganz gut aus“ ist dafür kein belastbares Kriterium. 

Wir empfehlen deshalb, vor der Modellauswahl ein Testset mit etwa 20 bis 40 realen Fällen aufzubauen. Für jeden Fall sollte definiert sein, welches Ergebnis erwartet wird oder anhand welcher Kriterien eine Antwort akzeptiert werden kann. 

Anschließend lässt sich bewusst mit einer wirtschaftlichen Modellvariante beginnen. 

1. Ein günstigeres Modell gegen das Testset laufen lassen. 
2. Die Ergebnisse anhand der definierten Kriterien bewerten. 
3. Prompt und Kontext optimieren. 
4. Erst bei unzureichender Qualität ein größeres Modell testen. 

Damit kehrt sich eine häufige Vorgehensweise um. Statt mit dem stärksten Modell zu starten und später nach Einsparpotenzial zu suchen, beginnt die Evaluation mit der wirtschaftlichsten Variante, die für den Anwendungsfall realistisch geeignet sein könnte. 

Das Ziel ist nicht das billigste Modell. Gesucht wird das günstigste Setup, das die definierte Qualität zuverlässig erreicht. 

Bei hohen Volumina wird Prompt-Optimierung zur Kostenoptimierung 

Sobald ein Prozess regelmäßig und in größerem Umfang läuft, wird relevant, welche Informationen bei jedem Request an das Modell übertragen werden. 

Ein langer System-Prompt verursacht bei jedem Aufruf erneut Input. Dasselbe gilt für vollständige Dokumente, obwohl möglicherweise nur einzelne Abschnitte für die Aufgabe relevant sind. Auch unnötiger Kontext oder ausführliche Freitextantworten können Kosten erzeugen, ohne die Qualität des Ergebnisses zu verbessern. 

Bei einem einzelnen Request fällt ein überflüssiges Token kaum ins Gewicht. Bei Tausenden oder Millionen wiederkehrenden Aufrufen verändert sich die Rechnung. 

Kürzere Kontexte, kompaktere Outputs, Caching und eine präzisere Auswahl der tatsächlich benötigten Informationen können deshalb einen erheblichen wirtschaftlichen Effekt haben. Bei zeitunkritischen Prozessen kommen außerdem Batch-Verarbeitung oder günstigere Service-Tiers infrage. 

Prompt-Optimierung ist damit bei produktiven Anwendungen nicht nur eine Frage der Antwortqualität. Bei ausreichendem Volumen wird sie zu einem direkten Kostenhebel. 

Agenten machen die Kosten schwerer vorhersehbar 

Besonders aufmerksam sollten Unternehmen bei agentischen Systemen kalkulieren. 

Ein einzelner LLM-Aufruf lässt sich vergleichsweise einfach berechnen. Ein Agent kann dagegen mehrere Schritte ausführen, Tools aufrufen, Zwischenergebnisse bewerten und anschließend erneut ein Modell befragen. Gleichzeitig kann der Kontext im Verlauf eines Runs wachsen und in späteren Schritten erneut verarbeitet werden. 

Die Kosten eines Agenten skalieren deshalb nicht zwangsläufig linear mit der Anzahl der sichtbaren Aufgaben. Ein einzelner Geschäftsvorgang kann intern eine ganze Kette von Modellaufrufen auslösen. 

Für die Kostenkontrolle reicht es daher nicht, den Preis eines einzelnen Prompts zu kennen. Gemessen werden müssen die durchschnittlichen Gesamtkosten eines vollständigen Agent-Runs, einschließlich Wiederholungen, Tool-Nutzung und zusätzlicher Kontextverarbeitung. 

Compliance kann die wirtschaftlich beste Option ausschließen 

Kosten und Qualität sind nicht die einzigen Kriterien für die Modellauswahl. Ein Modell kann für einen Anwendungsfall technisch geeignet und wirtschaftlich attraktiv sein und trotzdem nicht eingesetzt werden können. 

Relevant wird das beispielsweise bei Anforderungen an Data Residency. Cloud-Plattformen und Modellanbieter unterscheiden teilweise zwischen regionaler Verarbeitung und Routing über größere geografische Gebiete. Ist für einen Prozess verbindlich festgelegt, dass bestimmte Daten innerhalb der EU verarbeitet werden müssen, reduziert das die Menge der tatsächlich nutzbaren Modelle und Deployment-Varianten. 

Damit wird Compliance zu einem Bestandteil der wirtschaftlichen Bewertung. Ein günstiges oder leistungsfähiges Modell ist keine Option, wenn seine Bereitstellungsform die Anforderungen des Prozesses nicht erfüllt. 

Modellverfügbarkeit und Data Residency gehören deshalb bereits in die Modellauswahl und nicht erst in die abschließende Datenschutzprüfung. 

Modellwechsel gehören zu den laufenden Betriebskosten 

Ein produktives LLM-Setup bleibt nicht über Jahre unverändert. 

Anbieter veröffentlichen neue Modelle, verändern Angebote und nehmen ältere Varianten aus dem Portfolio. Ein Modellwechsel kann jedoch selbst bei identischem Prompt andere Ergebnisse produzieren. Nach einer Migration muss deshalb erneut geprüft werden, ob die zuvor definierte Qualitätsschwelle erreicht wird. 

Dieser Aufwand wird in Business Cases leicht übersehen. Zu den Betriebskosten eines LLM gehören nicht nur Tokens. Evaluation, Monitoring, Prompt-Anpassungen und wiederkehrende Modellmigrationen sind ebenfalls Teil des Betriebs. 

Das Testset aus der initialen Modellauswahl bekommt dadurch eine zweite Funktion. Es dient später als Regressionstest und ermöglicht es, neue Modelle gegen dieselben fachlichen Anforderungen zu prüfen. 

So entsteht ein belastbarer LLM-Business-Case 

Ein belastbarer Business Case beginnt nicht mit der Suche nach dem leistungsfähigsten Modell. Er beginnt mit dem konkreten Prozess. 

Zunächst werden die erwartete Frequenz sowie die durchschnittlichen Input- und Output-Mengen geschätzt. Danach entsteht aus realen Geschäftsfällen ein Testset mit einer messbaren Qualitätsschwelle. Auf dieser Basis können zunächst wirtschaftlichere Modelle getestet werden. Leistungsfähigere und teurere Varianten kommen erst dann zum Einsatz, wenn die geforderte Qualität anders nicht zuverlässig erreicht wird. 

Im produktiven Betrieb sollten anschließend Kosten pro Vorgang, Tokenmengen, Antwortqualität und Latenz beobachtet werden. Bei hohen Volumina lohnt sich eine regelmäßige Überprüfung von Prompt, Kontext, Caching und Output. Gleichzeitig sollte der Business Case berücksichtigen, dass Modelle wechseln und Evaluationen wiederholt werden müssen. 

Damit wird aus der abstrakten Frage „Was kostet uns KI?“ eine konkrete wirtschaftliche Entscheidung. Welche Qualität braucht dieser Prozess und welches Setup erreicht sie dauerhaft zu vertretbaren Kosten? 

Wenn Sie für einen konkreten Anwendungsfall herausfinden möchten, welche Modellarchitektur fachlich und wirtschaftlich sinnvoll ist, können wir den Prozess gemeinsam bewerten. they consulting unterstützt bei der Evaluation, Modellauswahl und Konzeption produktiver LLM-Anwendungen. 

Über den Autor: Pablo Heimplatz begleitet bei they consulting mittelständische Unternehmen bei der Einführung produktiver KI-Systeme – von der Auswahl des richtigen Anwendungsfalls bis zur nachhaltigen Verankerung im Team.