8 Was LLM-Systeme wirklich kosten

Sie schauen sich die Preistabelle an. OpenAI verlangt 0,03 Dollar pro tausend Input-Tokens für GPT-4. Das klingt günstig. Ein typischer Prompt hat vielleicht 500 Tokens, die Antwort weitere 500. Ein Request kostet also 0,03 Dollar. Ihr System verarbeitet tausend Requests pro Tag. Das sind 30 Dollar täglich, 900 Dollar im Monat. Überschaubar.

Dann bauen Sie das System. Und sechs Wochen später schauen Sie auf Ihre Rechnung und sehen 12.000 Dollar statt 900.

Was ist passiert?

Die einfache Antwort: Ihre Architektur hat sich gegen Sie verschworen. Die komplexere Antwort: Produktive LLM-Anwendungen funktionieren fundamental anders als die Prototypen, mit denen Sie gerechnet haben. Und dieser Unterschied schlägt sich direkt in den Kosten nieder, oft um Faktoren von zehn oder mehr.

Lassen Sie uns verstehen, warum das so ist. Und warum die Zahl auf der Preistabelle oft die unwichtigste Zahl in Ihrer gesamten Kostenrechnung ist.

8.1 Der Unterschied zwischen Demo und Produktion

Ein Beipsiel: Sie bauen einen Prototyp für einen intelligenten Dokumenten-Assistenten. Der Nutzer stellt eine Frage zu einem Dokument, Ihr System schickt die Frage zusammen mit dem relevanten Dokumentausschnitt an ein LLM, bekommt eine Antwort zurück. Ein API-Call pro Anfrage. Sauber, einfach, kalkulierbar.

Dann gehen Sie in Produktion und die Realität setzt ein. Die Kostenmultiplikatoren kommen alle auf einmal:

Diese Tabelle zeigt die schlichte Rechnung der Produktion. Jeder einzelne Faktor wirkt vernünftig und notwendig. Aber zusammen multiplizieren sie Ihre Kosten um ein bis zwei Größenordnungen.

Nutzer führen keine einzelnen Anfragen aus. Sie führen Konversationen. Die zweite Frage bezieht sich auf die erste Antwort, die dritte auf die zweite. Plötzlich müssen Sie bei jedem API-Call nicht nur die aktuelle Frage senden, sondern die gesamte bisherige Konversation als Kontext. Was als 1000 Tokens begann, sind nach fünf Fragen 5000 Tokens. Nach zehn Fragen vielleicht 10.000. Ihre Kosten pro Request haben sich verzehnfacht, nicht weil das Modell teurer wurde, sondern weil die Architektur Kontext akkumuliert.

Dann stellen Sie fest, dass eine einzelne Nutzeranfrage oft nicht mit einem einzigen LLM-Call beantwortet werden kann. Manchmal müssen Sie erst klären, was der Nutzer eigentlich meint. Ist seine Frage mehrdeutig? Dann brauchen Sie einen Call, um die Intention zu verstehen, bevor Sie die eigentliche Antwort generieren. Bezieht sich die Frage auf mehrere Dokumente? Dann müssen Sie möglicherweise für jedes Dokument separat fragen und die Ergebnisse zusammenführen. Was nach außen wie eine einzige Antwort aussieht, sind intern vielleicht drei oder vier API-Calls.

Und dann ist da die Fehlerbehandlung. Ein LLM-Call kann fehlschlagen, ein Timeout produzieren, eine unbrauchbare Antwort zurückgeben. In der Produktion müssen Sie damit umgehen. Das bedeutet Retry-Logik, das bedeutet Validierung von Outputs, das bedeutet manchmal, dass Sie einen zweiten Call mit einem umformulierten Prompt machen müssen. Jeder Retry kostet. Jede Validierung, die selbst ein LLM nutzt, kostet.

8.2 Die Multiplikation durch Architektur

Hier wird es technisch interessant. Die Kosten eines LLM-Systems hängen nicht nur davon ab, wie teuer das Modell ist. Sie hängen fundamental davon ab, wie Sie das System architektonisch aufgebaut haben. Und viele Architekturentscheidungen, die Sie treffen, um das System besser zu machen, multiplizieren Ihre Kosten, ohne dass Ihnen das vorher bewusst war.

Nehmen wir Retrieval-Augmented Generation, eine der wichtigsten Techniken für produktive LLM-Systeme. Sie haben eine große Wissensdatenbank, sagen wir tausende von Dokumenten. Der Nutzer stellt eine Frage, und statt dem LLM die gesamte Datenbank zu geben – was unmöglich wäre – suchen Sie zuerst die relevanten Dokumente heraus und geben nur diese dem LLM. Das funktioniert gut. Es macht Ihre Antworten akkurater, weil das LLM auf echten Daten basiert statt auf seinem Training.

Aber es kostet. Denn bevor Sie überhaupt den Haupt-LLM-Call machen können, müssen Sie die Suche durchführen. Moderne Vektorsuchen nutzen Embeddings, und diese Embeddings werden oft auch von LLMs generiert. Sie nehmen die Nutzeranfrage, lassen sie durch ein Embedding-Modell, suchen in Ihrer Vektordatenbank, holen die relevanten Dokumente, fügen sie dem Kontext hinzu, und erst dann kommt der eigentliche LLM-Call. Das sind mindestens zwei API-Calls statt einem – einer für das Embedding, einer für die Antwort.

Embedding-Modelle sind günstiger als große Sprachmodelle, sicher. Aber sie sind nicht kostenlos. Und wenn jede Nutzeranfrage ein Embedding braucht, summiert sich das schnell. Tausend Anfragen pro Tag bedeuten tausend Embedding-Calls zusätzlich zu den tausend LLM-Calls.

Und dann gibt es Architekturen, die noch komplexer sind. Stellen Sie sich ein System vor, das nicht nur antwortet, sondern Aufgaben ausführt. Der Nutzer sagt: “Finde alle Meetings nächste Woche, die mit dem Projekt X zu tun haben, und schicke den Teilnehmern eine Zusammenfassung.”

Das ist nicht ein LLM-Call. Das ist eine Kette von Operationen, die sich schnell zu einem kostspieligen Prozess aufbaut:

Solche Systeme nennt man oft Agents. Sie sind mächtig, weil sie autonom Entscheidungen treffen und mehrere Schritte ausführen können. Aber sie sind auch teuer. Ein einzelner User-Request kann fünf, zehn, manchmal zwanzig LLM-Calls triggern. Wenn Sie mit 0,03 Dollar pro Request gerechnet haben und plötzlich sind es 0,30 bis 0,60 Dollar, weil Ihr System intern zehn- bis zwanzigmal das LLM aufruft, dann ist Ihre Kostenprojektion um den Faktor zehn bis zwanzig falsch.

8.3 Kontext ist teuer

Einer der größten Kostentreiber in LLM-Systemen ist etwas, das zunächst unscheinbar wirkt: Kontext-Management. Wie viel Kontext geben Sie dem Modell bei jedem Call?

In Ihrer Demo haben Sie vielleicht nur die aktuelle Frage gesendet. Das Modell hat geantwortet, fertig. Aber in der Produktion brauchen Sie mehr. Sie brauchen die Konversationshistorie, damit das Modell auf vorherige Fragen Bezug nehmen kann. Sie brauchen möglicherweise Systemanweisungen, die dem Modell erklären, wie es sich verhalten soll. Sie brauchen vielleicht Beispiele – Few-Shot-Learning – um das Modell zu leiten. Sie brauchen die relevanten Dokumente aus Ihrer Datenbank. All das ist Kontext, und all das kostet.

Lassen Sie uns die Anatomie eines typischen Produktions-Requests betrachten:

Die Kosten wachsen linear mit der Länge der Konversation, und lange Konversationen sind genau das, was gute Nutzererfahrung ausmacht. Bei GPT-4 mit 0,03 Dollar pro 1000 Input-Tokens kostet ein Request nach zwanzig Turns etwa 0,39 Dollar nur für den Input – mehr als zehnmal so viel wie Ihr erster Turn.

Sie könnten versuchen, das zu begrenzen. Nur die letzten drei Turns behalten, den Rest wegwerfen. Aber dann verliert das Modell Kontext, und die Qualität der Antworten leidet. Sie könnten versuchen, die Konversation zu komprimieren – den bisherigen Verlauf zusammenfassen und nur die Zusammenfassung behalten. Das hilft, aber die Zusammenfassung selbst kostet einen LLM-Call. Sie optimieren die Kosten an einer Stelle und erzeugen sie an einer anderen.

Es gibt keine perfekte Lösung. Jede Entscheidung ist ein Trade-off zwischen Qualität und Kosten. Aber diese Trade-offs müssen Sie verstehen und aktiv treffen, nicht zufällig entdecken, wenn die Rechnung kommt.

8.4 Die versteckten Calls

Eines der tückischsten Probleme bei modernen LLM-Architekturen ist, dass sie eine Menge Komplexität abstrahieren. Das ist gut für Entwicklungsgeschwindigkeit, aber schlecht für Kostentransparenz. Sie schreiben Code, der scheinbar einfach ist, und unter der Haube passieren Dinge, die Sie nicht sehen.

Angenommen, Sie bauen ein System, das E-Mails kategorisiert und beantwortet. Sie bekommen eine E-Mail rein, das System soll sie lesen, verstehen, in die richtige Kategorie einordnen, und basierend auf der Kategorie eine passende Antwort generieren. Klingt nach zwei, vielleicht drei LLM-Calls, richtig?

Hier ist, was tatsächlich passiert, wenn Sie das System robust bauen:

Was Sie sich als zwei Calls vorgestellt haben, sind plötzlich sechs oder sieben. In einem gut gebauten, robusten System kann eine scheinbar simple Operation leicht zehn LLM-Interaktionen umfassen. Und wenn Sie das nicht monitoren, nicht messen, nicht explizit tracken, merken Sie es erst, wenn die Rechnung kommt.

8.5 Rate Limits und Skalierung

Es gibt noch eine andere Art von Kosten, die nicht direkt auf der Rechnung steht, aber real ist: Opportunity-Kosten durch Limitierungen.

Die meisten LLM-APIs haben Rate Limits. Sie dürfen pro Minute nur eine bestimmte Anzahl an Requests machen, oder pro Tag nur eine bestimmte Menge an Tokens verarbeiten. Das ist verständlich – die Anbieter müssen ihre Kapazität managen. Aber es bedeutet, dass Ihr System möglicherweise nicht alle Anfragen bedienen kann, die reinkommen.

Was passiert, wenn Sie das Limit erreichen? Der API-Call schlägt fehl. Sie müssen warten, es nochmal versuchen. Das bedeutet Latenz für den Nutzer. Im schlimmsten Fall bedeutet es, der Nutzer bekommt gar keine Antwort, weil Ihr System überlastet ist. Das sind verlorene Requests, verlorene Nutzer, verlorener Umsatz.

Sie könnten das Limit erhöhen, indem Sie auf einen teureren Tier upgraden. Aber das kostet. Oft deutlich mehr. Der Sprung von Standard zu Enterprise kann Ihre Kosten verdoppeln oder verdreifachen. Ist das gerechtfertigt? Kommt darauf an, wie viel Ihnen die zusätzliche Kapazität wert ist. Aber es ist eine Entscheidung, die Sie treffen müssen, und sie basiert nicht nur auf der Anzahl der Requests, sondern auf der Architektur Ihres Systems.

Wenn Ihr System für jeden User-Request fünf interne LLM-Calls macht, erreichen Sie das Rate Limit fünfmal schneller als ein System, das nur einen Call macht. Ihre Architektur bestimmt direkt, wann Sie an Grenzen stoßen. Und Grenzen zu überwinden kostet Geld.

8.6 Monitoring als Kostenfaktor

Hier ist etwas, das viele nicht auf dem Radar haben: Um die Kosten zu kontrollieren, müssen Sie wissen, was passiert. Das bedeutet Monitoring, Logging, Observability. Und das kostet auch.

Sie müssen jeden API-Call loggen – wann wurde er gemacht, mit welchem Input, was kam zurück, wie viele Tokens wurden verbraucht. Sie müssen diese Logs speichern, durchsuchbar machen, analysieren können. Bei hohem Volumen sind das gigabytes an Daten pro Tag. Die Infrastruktur dafür ist nicht trivial:

Speicherplatz kostet. Die Tools, um diese Daten zu analysieren, kosten auch. Aber ohne dieses Monitoring haben Sie keine Ahnung, wo Ihre Kosten herkommen. Sie sehen nur die Gesamtrechnung. Sie wissen nicht, dass 80 Prozent Ihrer Kosten von 20 Prozent Ihrer Features kommen. Sie wissen nicht, dass ein bestimmter Prompt-Typ unverhältnismäßig teuer ist, weil er immer zu langen Antworten führt. Sie wissen nicht, dass Ihr Retry-Mechanismus in bestimmten Situationen in eine Schleife gerät und dutzende redundante Calls macht.

Monitoring gibt Ihnen Transparenz. Transparenz erlaubt Optimierung. Optimierung spart Kosten. Aber der Aufbau und Betrieb des Monitoring-Systems selbst ist ein Kostenfaktor, den Sie einplanen müssen. Es ist eine Investition, die sich auszahlt, aber es ist eine Investition.

8.7 Caching als Strategie

Eine der effektivsten Methoden, Kosten zu senken, ist Caching. Die Idee ist simpel: Wenn Sie die gleiche Frage schon einmal gestellt haben, speichern Sie die Antwort und liefern sie direkt, statt einen neuen API-Call zu machen. Ein Cache-Hit kostet fast nichts. Ein Cache-Miss kostet den vollen API-Call.

Aber Caching ist komplizierter, als es klingt. Verschiedene Cache-Strategien haben unterschiedliche Trade-offs:

Exakte String-Matches helfen wenig, weil Nutzer die gleiche Frage auf hundert verschiedene Arten formulieren. Sollten Sie semantische Ähnlichkeit nutzen? Dann brauchen Sie wieder Embeddings, und die kosten – wenn auch deutlich weniger als ein voller LLM-Call. Sollten Sie nur Teile des Inputs cachen – etwa abgerufene Dokumente? Dann wird die Cache-Logik komplex, aber die Einsparungen können erheblich sein.

Und dann ist da die Frage, wie lange Cached-Antworten gültig bleiben. Bei statischen Informationen vielleicht ewig. Bei dynamischen Daten – Börsenkurse, Wetter, aktuelle Events – vielleicht nur Minuten. Sie müssen Cache-Invalidierung bauen, und das ist nie trivial.

Aber wenn Sie Caching richtig machen, können Sie Ihre Kosten halbieren oder mehr. Bei Anfragen, die häufig wiederholt werden – FAQ-artige Fragen, gängige Support-Anfragen – können Cache-Hit-Raten von 60 oder 70 Prozent realistisch sein. Das bedeutet, Sie machen nur 30 Prozent so viele API-Calls wie ohne Cache. Bei 10.000 Dollar monatlichen API-Kosten sparen Sie 7000. Das rechtfertigt durchaus die Komplexität eines guten Cache-Systems.

8.8 Die Latenz-Kosten-Gleichung

Es gibt noch einen Trade-off, der oft übersehen wird: Latenz versus Kosten. Schnellere Systeme sind teurer. Günstigere Architekturen sind langsamer. Und Latenz hat ihren eigenen Preis.

Wenn Ihr System drei Sekunden braucht, um zu antworten, werden manche Nutzer abspringen. Jeder abgesprungene Nutzer ist verlorener Umsatz. Wie viel ist Ihnen eine Sekunde Latenz-Reduktion wert? Das hängt von Ihrer Nutzerbasis und Ihrem Geschäftsmodell ab, aber es ist real. Studien zeigen, dass jede zusätzliche Sekunde Ladezeit die Conversion-Rate um mehrere Prozentpunkte senken kann.

Um Latenz zu reduzieren, können Sie mehrere Dinge tun. Sie können kleinere, schnellere Modelle nutzen – die sind günstiger pro Call, aber Sie brauchen vielleicht mehr Calls, weil die Qualität schlechter ist. Sie können parallelisieren – mehrere Calls gleichzeitig machen statt sequenziell – aber dann riskieren Sie, Rate Limits zu erreichen. Sie können aggressiv cachen, aber das erhöht die Komplexität. Sie können auf On-Premise-Modelle gehen, die Sie selbst hosten und optimieren können, aber das bringt komplett andere Kostenstrukturen mit sich.

Es gibt keine universelle Lösung. Jedes System muss seinen eigenen Sweet Spot finden zwischen Kosten, Latenz und Qualität. Aber um diesen Sweet Spot zu finden, müssen Sie verstehen, wie diese drei Dimensionen zusammenhängen. Und das setzt voraus, dass Sie messen, was wirklich passiert.

8.9 Architekturen für Kosteneffizienz

Wenn Sie verstehen, wie Kosten in LLM-Systemen entstehen, können Sie bewusst Architekturen wählen, die diese Kosten minimieren. Nicht alle Anfragen brauchen das stärkste Modell. Nicht alle Anfragen brauchen den vollen Kontext. Nicht alle Operationen müssen sofort passieren.

Hier sind bewährte Strategien mit ihren jeweiligen Trade-offs:

Model Tiering ist eine besonders elegante Lösung. Einfache Anfragen werden an ein kleines, schnelles, günstiges Modell geschickt. Nur wenn das nicht ausreicht, eskalieren Sie zu einem größeren Modell. Das bedeutet, Sie brauchen eine Heuristik oder einen Classifier, der entscheidet, welche Anfrage welches Tier braucht. Das ist wieder Komplexität, aber es kann Ihre durchschnittlichen Kosten pro Request dramatisch senken. Ein System, das 70 Prozent der Anfragen mit einem günstigen Modell beantwortet und nur 30 Prozent eskaliert, kann die Kosten um 50 Prozent oder mehr reduzieren.

Eine andere Strategie ist asynchrone Verarbeitung. Nicht alle Antworten müssen sofort kommen. Wenn Sie einen Report generieren oder eine große Menge an Dokumenten analysieren, kann das Batch-Processing sein. Sie sammeln Anfragen, verarbeiten sie nachts, wenn die Last niedriger ist, vielleicht sogar mit günstigeren Modellen oder On-Premise-Hardware. Das erhöht die Latenz, aber senkt die Kosten.

Und dann ist da die Strategie, LLMs nur dort einzusetzen, wo sie wirklich nötig sind. Viele Aufgaben, die ein LLM lösen kann, können auch durch traditionelle Algorithmen gelöst werden – vielleicht nicht ganz so flexibel, aber gut genug. Keyword-Suche statt semantische Suche, regelbasierte Kategorisierung statt LLM-basierte, Template-basierte Antworten statt generierte. Diese Hybrid-Ansätze sind oft die kosteneffizientesten, weil sie das Beste aus beiden Welten kombinieren.

8.10 Die Perspektive

Was bedeutet all das? Es bedeutet, dass die Kostenkalkulation für LLM-Systeme komplex ist. Viel komplexer, als die einfache Token-Preis-Rechnung suggeriert. Die Architektur Ihres Systems bestimmt fundamental, wie viel es kostet – nicht nur das Modell, das Sie wählen.

Wenn Sie ein LLM-System bauen, müssen Sie von Anfang an über Kosteneffizienz nachdenken. Nicht als nachträgliche Optimierung, sondern als Teil des Designs. Wie viele Calls macht Ihr System pro User-Request? Wie wächst der Kontext über Zeit? Wo können Sie cachen? Welche Teile können mit traditionellen Methoden gelöst werden?

Diese Fragen zu beantworten setzt voraus, dass Sie verstehen, was in Ihrem System passiert. Das bedeutet Monitoring, Logging, Analyse. Das bedeutet, Sie müssen messen, bevor Sie optimieren können. Und das bedeutet oft, dass Sie Tools und Abstraktionen brauchen, die Ihnen helfen, diese Komplexität zu managen.

Denn das ist die Herausforderung: LLM-Systeme sind von Natur aus komplex. Sie verketten mehrere Operationen, managen Kontext über Zeit, integrieren verschiedene Komponenten. Diese Komplexität zu verstehen und zu kontrollieren ist der Schlüssel zu kosteneffizienten Architekturen.

Im nächsten Schritt werden wir schauen, wie Frameworks und Tools Ihnen helfen können, genau das zu tun – diese Komplexität zu managen, Kosten transparent zu machen, und Systeme zu bauen, die gleichzeitig leistungsfähig und bezahlbar sind.

Aber die Basis ist das Verständnis, das wir hier aufgebaut haben: Was kostet wirklich, und warum. Mit diesem Verständnis können Sie informierte Entscheidungen treffen. Ohne dieses Verständnis tappen Sie im Dunkeln, bis die Rechnung kommt.