KI-Engineering · Tag 7: LLM-Kosten & Latenz im Griff

Willkommen zu Tag 7 unserer Serie KI-Engineering. Der Prototyp lief im Meeting, alle waren begeistert — und dann kam die erste Cloud-Rechnung. Ein internes Support-Tool, das im Test 40 Euro im Monat kostete, verschlang plötzlich 2.800 Euro, weil ein paar hundert Nutzer es gleichzeitig verwendeten. Willkommen in der Realität. Heute geht es darum, LLM-Kosten senken zu einer planbaren Ingenieursdisziplin zu machen — ohne dass die Qualität eurer Antworten leidet und ohne dass die App sich anfühlt, als würde sie durch Sirup laufen.

Die unangenehme Wahrheit vorweg: Die meisten Teams zahlen das Zwei- bis Fünffache dessen, was sie müssten, und das nicht wegen des Modellpreises, sondern wegen schlechter Architektur-Entscheidungen. Genau diese Entscheidungen schauen wir uns heute im Detail an, mit echten Rechnungen und den Trade-offs, die niemand gern ausspricht.

Warum LLM-Kosten so schnell explodieren

Anders als bei klassischer Infrastruktur zahlt ihr bei einem LLM nicht pro Server, sondern pro verarbeitetem Token. Ein Token ist grob ein Wortteil — im Deutschen rund vier Zeichen. Ihr zahlt zweimal: einmal für die Eingabe (euer Prompt plus Kontext) und einmal, oft deutlich teurer, für die Ausgabe, die das Modell generiert. Diese Token-Kosten sind der Hebel, an dem fast alles hängt.

Die drei Kostentreiber

Es gibt im Kern nur drei Größen, die eure Rechnung bestimmen — und alle drei sind steuerbar:

• Modellgröße: Das größte Frontier-Modell kann leicht das Zwanzig- bis Dreißigfache eines kleinen, schnellen Modells kosten. Der Reflex, immer das stärkste Modell zu nehmen, ist der teuerste Reflex überhaupt.
• Kontextlänge: Jeder Token, den ihr mitschickt, wird bezahlt — bei jedem einzelnen Aufruf. Wer die komplette Wissensdatenbank oder den gesamten Chatverlauf in jeden Prompt kippt, zahlt dafür pausenlos.
• Anzahl der Aufrufe: Agenten-Architekturen, die eine Aufgabe in fünf, zehn oder zwanzig Modellaufrufe zerlegen, multiplizieren die Kosten still und leise. Ein Feature, das im Demo einen Aufruf machte, macht in Produktion vielleicht acht.

Das Tückische: In der Entwicklung testet ihr mit fünf Anfragen am Tag, da fällt nichts auf. Der Multiplikator wird erst sichtbar, wenn echter Traffic drauf ist — und dann ist es eine Feuerwehrübung statt einer Design-Entscheidung.

Ein konkretes Praxisbeispiel: Wie aus 40 Euro 2.800 werden

Nehmen wir das eingangs erwähnte Support-Tool und rechnen es sauber durch. Nutzer stellt eine Frage, das System zieht passende Artikel aus der Wissensdatenbank und generiert eine Antwort. Klingt harmlos.

Die naive Implementierung

Das erste Team baut es so: Jede Anfrage geht an das größte verfügbare Modell. Um sicherzugehen, dass die Antwort stimmt, wird die komplette Wissensdatenbank — 30 Artikel, rund 20.000 Token — in jeden Prompt gepackt. Dazu der bisherige Gesprächsverlauf, weitere 3.000 Token. Die Antwort ist im Schnitt 600 Token lang.

Rechnen wir mit realistischen Preisen eines großen Modells von etwa 12 Euro pro Million Eingabe-Token und 60 Euro pro Million Ausgabe-Token. Pro Anfrage sind das rund 23.000 Eingabe-Token, macht 0,276 Euro, plus 600 Ausgabe-Token für 0,036 Euro. Zusammen etwa 0,31 Euro pro Anfrage.

Bei 300 aktiven Nutzern, die jeweils 30 Anfragen im Monat stellen, sind das 9.000 Anfragen. Mal 0,31 Euro ergibt rund 2.790 Euro monatlich. Genau die Böse-Überraschung-Rechnung.

Dieselbe Funktion, sauber gebaut

Jetzt dieselbe Aufgabe mit den Hebeln, die wir gleich einzeln durchgehen. Erstens: Statt der ganzen Wissensdatenbank holt ein Retrieval-Schritt nur die drei wirklich relevanten Artikel — rund 2.500 statt 20.000 Token. Zweitens: Der Gesprächsverlauf wird auf die letzten zwei Turns plus eine kurze Zusammenfassung gekürzt, etwa 800 Token. Drittens: Die Aufgabe — eine faktische Support-Antwort aus gegebenem Kontext — braucht kein Frontier-Modell. Ein mittelgroßes Modell zu vielleicht 0,8 Euro pro Million Eingabe- und 4 Euro pro Million Ausgabe-Token reicht völlig.

Neue Rechnung: rund 3.300 Eingabe-Token mal 0,8 Euro pro Million macht 0,0026 Euro, plus 600 Ausgabe-Token für 0,0024 Euro. Zusammen etwa 0,005 Euro pro Anfrage. Bei 9.000 Anfragen sind das 45 Euro im Monat. Dieselbe Nutzererfahrung, dieselbe Antwortqualität für diese Aufgabenklasse — ein Faktor von rund sechzig. Nicht sechzig Prozent. Sechzig mal.

Der Punkt ist nicht die exakte Zahl, die schwankt mit Anbieter und Modell. Der Punkt ist die Größenordnung: Kontext klein halten und das richtige Modell wählen sind zusammen die mit Abstand wirksamsten Hebel.

Die Hebel, um LLM-Kosten zu senken

Schauen wir uns die einzelnen Werkzeuge an, mit denen ihr systematisch die LLM-Kosten senken könnt. Keiner davon ist exotisch, aber in Kombination entfalten sie ihre Wirkung.

Das richtige Modell je Aufgabe

Die wichtigste Entscheidung. Nicht jede Aufgabe braucht dasselbe Modell. Klassifizierung, Extraktion, Umformulierung oder das Beantworten einer Frage aus gegebenem Kontext gelingen kleinen Modellen zuverlässig. Komplexe Planung, mehrstufiges Schlussfolgern oder anspruchsvolles Coding rechtfertigen ein großes Modell. Behandelt die Modellwahl als das, was sie ist: eine Design-Entscheidung pro Aufgabentyp, nicht ein globaler Default.

Der ehrliche Trade-off: Kleine Modelle scheitern subtiler. Sie liefern eine plausibel klingende, aber falsche Antwort, wo ein großes Modell die Lücke erkannt hätte. Deshalb gehört zur Modellwahl immer eine Evaluierung an echten Beispielen — dazu gleich mehr.

Günstiges Modell mit Eskalation

Ein besonders eleganter Ansatz: Standardmäßig das günstige Modell einsetzen und nur bei Bedarf zum teuren eskalieren. Das günstige Modell darf signalisieren, dass es unsicher ist — etwa über einen niedrigen Confidence-Wert oder ein explizites „das kann ich nicht sicher beantworten“. Nur diese Fälle gehen ans große Modell. Wenn 85 Prozent der Anfragen einfach sind, zahlt ihr den hohen Preis nur für die restlichen 15 Prozent.

Kontext klein halten

Wie das Beispiel zeigt, ist aufgeblähter Kontext ein Dauerkostenfaktor. Schickt nur, was der aktuelle Schritt wirklich braucht. Nutzt Retrieval statt Alles-Reinkippen. Fasst lange Gesprächsverläufe zusammen, statt sie vollständig mitzuschleppen. Jeder eingesparte Kontext-Token spart bei jedem Aufruf.

Caching nutzen

Wenn ein großer Teil eures Prompts stabil ist — etwa eine umfangreiche System-Anweisung, ein festes Regelwerk oder ein gleichbleibender Dokumentenkontext — unterstützen viele Anbieter Prompt-Caching. Der wiederkehrende Teil wird nur einmal teuer verarbeitet und danach stark vergünstigt wiederverwendet, oft zu einem Zehntel des Preises. Bei Anwendungen mit großem, stabilem Vorspann ist das ein sofortiger, risikoarmer Gewinn.

Batching und kürzere Prompts

Zwei kleinere, aber lohnende Hebel. Wo Antworten nicht in Echtzeit gebraucht werden — nächtliche Auswertungen, Massenklassifizierung, Anreicherung von Datensätzen — bieten viele Anbieter einen Batch-Modus mit deutlichem Rabatt gegen längere Laufzeit. Und schließlich: Kürzere Prompts. Viele System-Anweisungen sind historisch gewachsene Textwüsten mit Wiederholungen und totem Ballast. Wer sie strafft, spart bei jedem Aufruf und bekommt oft sogar bessere Antworten, weil das Modell klarere Anweisungen erhält.

Latenz senken, ohne mehr zu zahlen

Kosten sind die eine Hälfte, Latenz die andere. Ein Nutzer, der fünf Sekunden auf den ersten Buchstaben wartet, empfindet die App als kaputt — selbst wenn die Antwort exzellent ist. Und Latenz hängt eng mit den Kostenentscheidungen zusammen: Kleinere Modelle antworten schneller, kürzerer Kontext wird schneller verarbeitet.

Streaming

Der größte wahrgenommene Gewinn kostet fast nichts: Streamt die Antwort Token für Token, statt zu warten, bis sie komplett fertig ist. Die tatsächliche Gesamtdauer ändert sich nicht, aber die Zeit bis zum ersten sichtbaren Zeichen sinkt von mehreren Sekunden auf Millisekunden. Gefühlt wird die App dadurch dramatisch schneller. Bei allem, was ein Mensch live liest, ist Streaming Pflicht.

Parallele Schritte

Wenn eine Aufgabe mehrere unabhängige Modellaufrufe braucht — etwa drei Dokumente gleichzeitig zusammenfassen — führt sie parallel aus statt nacheinander. Drei sequenzielle Aufrufe zu je zwei Sekunden ergeben sechs Sekunden; parallel bleibt es bei zwei. Der Trade-off: höhere gleichzeitige Last und etwas komplexere Fehlerbehandlung. Für spürbar schnellere Antworten meist ein leichter Preis.

Kleinere Modelle für Zwischenschritte

In mehrstufigen Abläufen muss nicht jeder Schritt das große Modell bemühen. Routing-Entscheidungen, das Umschreiben einer Suchanfrage oder das Filtern von Kandidaten erledigt ein kleines, schnelles Modell in Sekundenbruchteilen. Das große Modell kommt nur für den einen Schritt zum Einsatz, der wirklich Denkleistung braucht. Das senkt Kosten und Latenz gleichzeitig.

So gehst du vor

Genug Theorie. Hier ist die konkrete Reihenfolge, mit der wir bei Forge12 an ein Kosten- und Latenzproblem herangehen — von der Messung bis zur laufenden Überwachung.

Schritt 1: Messen, bevor du optimierst

Ihr könnt nicht steuern, was ihr nicht seht. Loggt für jeden Modellaufruf die Eingabe- und Ausgabe-Token, das verwendete Modell, die Latenz und die Aufgabenart. Ohne diese Daten optimiert ihr im Nebel. In fast jedem Projekt fördert allein diese Messung eine Handvoll Überraschungen zutage — ein Schritt, der zehnmal so viel Kontext zieht wie gedacht, oder ein Aufruf, der versehentlich doppelt passiert.

Schritt 2: Die teuersten Pfade identifizieren

Sortiert nach Gesamtkosten, nicht nach Kosten pro Aufruf. Ein günstiger Aufruf, der millionenfach passiert, schlägt einen teuren, der selten vorkommt. Konzentriert euch zuerst auf die zwei, drei Pfade, die 80 Prozent der Rechnung ausmachen.

Schritt 3: Baseline für Qualität festlegen

Bevor ihr etwas ändert, legt eine Sammlung echter Beispiele mit gewünschten Ergebnissen an — euer Eval-Set. Nur so könnt ihr messen, ob ein günstigeres Modell oder ein kleinerer Kontext die Qualität wirklich hält. „Fühlt sich noch gut an“ ist keine Metrik. Ohne Eval-Set optimiert ihr Kosten blind gegen Qualität.

Schritt 4: Einen Hebel nach dem anderen ziehen

Ändert nie mehrere Dinge gleichzeitig. Erst das Modell tauschen und gegen das Eval-Set prüfen. Hält die Qualität, den Kontext kürzen und erneut prüfen. Dann Caching, dann Eskalation. So wisst ihr genau, welcher Hebel wie viel bringt — und könnt einen rückgängig machen, der die Qualität kippt.

Schritt 5: Überwachen und Alarme setzen

Kosten und Latenz sind keine Einmalaufgabe. Ein neues Feature, ein geändertes Prompt oder ein Anbieter-Update können die Rechnung über Nacht verändern. Richtet ein Dashboard mit täglichen Token-Kosten und Latenz-Perzentilen ein, und setzt Alarme, wenn ein Wert aus dem Rahmen fällt. So bemerkt ihr die nächste Kosten-Explosion am selben Tag — nicht erst auf der Monatsrechnung.

Fazit

LLM-Kosten und Latenz sind kein Schicksal, sondern das Ergebnis von Design-Entscheidungen. Die größten Hebel sind die einfachsten: das richtige Modell je Aufgabe, den Kontext klein halten und messen, was ihr tut. Streaming macht die App gefühlt schnell, Caching und Eskalation senken die Rechnung ohne Qualitätsverlust. Wer diese Disziplin von Anfang an mitdenkt, zahlt oft ein Bruchteil dessen, was unkontrollierte Systeme kosten — und liefert trotzdem schnellere, verlässlichere Antworten. Der Faktor sechzig aus unserem Beispiel ist keine Ausnahme, sondern die Regel für Systeme, die nie auf Kosten und Latenz hin gebaut wurden.

Das war Tag 7 unserer Serie KI-Engineering. In der Serien-Übersicht findest du alle bisherigen Episoden — von den Grundlagen bis zu den Themen, die noch kommen. Wenn ihr ein KI-Feature plant oder ein bestehendes System eure Cloud-Rechnung sprengt, helfen wir euch, es kostenkontrolliert und schnell zu bauen: Mehr dazu unter KI-Engineering bei Forge12. Und wenn ihr konkret über euer Vorhaben sprechen wollt, meldet euch einfach über unser Kontaktformular — wir schauen gemeinsam auf eure Zahlen.