LLM-Kosten im Research kontrollieren bevor die API-Rechnung explodiert.
Wer LLMs ernsthaft im Trading-Research einsetzt, merkt schnell: Die erste Demo ist billig, die produktive Pipeline ist es nicht. Sobald täglich hunderte Filings, Earnings-Calls und News-Artikel durch ein Modell laufen, wächst die API-Rechnung vierstellig — und niemand hat es kommen sehen, weil im Prototyp alles ein paar Cent kostete. Das Problem ist nicht das einzelne Token, sondern die Multiplikation: viele Dokumente, lange Kontexte, wiederholte Aufrufe. Die gute Nachricht ist, dass sich der Großteil dieser Kosten mit einer Handvoll Techniken um einen erheblichen Faktor senken lässt, ohne die Ergebnisqualität anzutasten — durch Prompt-Caching, Batch-Verarbeitung, Modell-Routing und konsequente Vorfilterung. Dieser Beitrag erklärt, wo das Geld tatsächlich verbrennt, welche Hebel wie viel bringen und welche Rechenbeispiele realistisch sind. Es geht nicht um Sparen um jeden Preis, sondern darum, eine Research-Pipeline so zu bauen, dass sie auch bei wachsendem Volumen bezahlbar bleibt — und man die Rechnung vorhersagen kann, statt sich am Monatsende zu erschrecken.
Wo die Kosten wirklich entstehen.
LLM-Kosten setzen sich aus Eingabe- und Ausgabe-Tokens zusammen, und beide werden unterschiedlich abgerechnet — Ausgabe ist je nach Modell um ein Mehrfaches teurer als Eingabe. Im Research-Kontext dominiert aber meist die Eingabeseite, weil die Dokumente lang sind und die Ausgaben — ein Sentiment, ein Ereignis, eine Kennzahl — kurz.
Der erste Schritt ist deshalb, die Pipeline zu vermessen, nicht zu schätzen. Wie viele Tokens gehen pro Dokument hinein? Wie oft wird derselbe Kontext — etwa ein System-Prompt mit Anweisungen — bei jedem Aufruf erneut mitgeschickt? Wie viele Aufrufe entfallen auf Dokumente, die für die eigentliche Frage irrelevant sind?
In den meisten ungeoptimierten Pipelines stecken drei Verschwender: ein langer, bei jedem Aufruf wiederholter Prompt-Vorspann, das Durchjagen aller Dokumente durch das teuerste Modell, und Echtzeit-Verarbeitung dort, wo Stapelverarbeitung gereicht hätte. Genau hier setzen die folgenden Hebel an.
Prompt-Caching: den wiederholten Vorspann nur einmal bezahlen.
Der größte und am leichtesten zu hebende Posten ist meist der wiederholte Kontext. Wenn jeder Aufruf einen ausführlichen System-Prompt, ein Klassifikationsschema oder Few-Shot-Beispiele mitschickt — und das tut er fast immer — zahlen Sie diesen Vorspann bei jedem einzelnen Dokument erneut.
Prompt-Caching durchbricht das. Der stabile Anfang der Anfrage wird einmal verarbeitet und zwischengespeichert; folgende Aufrufe mit demselben Vorspann lesen aus dem Cache, statt ihn neu zu verarbeiten. Die Ersparnis auf dem gecachten Teil ist erheblich — gelesene Cache-Tokens kosten nur einen Bruchteil des normalen Eingabepreises.
Der Haken liegt im Detail: Caching ist ein Präfix-Abgleich. Schon ein einziges geändertes Byte am Anfang — ein Zeitstempel, eine wechselnde ID, eine umsortierte Reihenfolge — macht den Cache wertlos. Die Konsequenz für den Bau der Pipeline: Stabiles zuerst, Variables ans Ende. Der unveränderliche Prompt-Vorspann kommt vor das jeweilige Dokument, nicht hinter es. Wer das missachtet, hat das Feature aktiviert und trotzdem null Treffer.
Batch-Verarbeitung für alles, was nicht sofort sein muss.
Ein großer Teil der Research-Arbeit ist nicht latenzkritisch. Das nächtliche Durcharbeiten der Tagesmeldungen, das Klassifizieren eines Quartals-Stapels von Filings, das Vorberechnen von Sentiment für ein ganzes Universum — all das muss nicht in Echtzeit geschehen.
Für genau solche Lasten gibt es Batch-Schnittstellen, die Anfragen asynchron verarbeiten und dafür einen deutlichen Rabatt auf den Token-Preis gewähren — typischerweise rund die Hälfte. Man reicht den gesamten Stapel ein, fragt periodisch den Status ab und holt die Ergebnisse ab, sobald sie fertig sind. Die meisten Stapel sind innerhalb einer Stunde durch, garantiert wird ein Fenster von bis zu einem Tag.
Die Regel ist einfach: Alles, was bis morgen früh Zeit hat, gehört in den Batch. Nur was ein Mensch oder ein Handelssystem in dem Moment braucht, läuft synchron. Diese Trennung allein halbiert bei research-lastigen Pipelines oft einen Großteil der Kosten — ohne jeden Qualitätsverlust, weil dasselbe Modell rechnet.
Modell-Routing: nicht jede Aufgabe braucht das stärkste Modell.
Der teuerste Reflex ist, alles durch das leistungsfähigste Modell zu schicken. Viele Research-Teilaufgaben — eine Meldung als relevant/irrelevant einsortieren, ein grobes Sentiment vergeben, eine Entität extrahieren — bewältigt ein kleineres, günstigeres Modell ebenso gut, oft zu einem Bruchteil der Kosten.
Sinnvoll ist eine Routing-Logik mit klaren Stufen:
| Aufgabe | Modellklasse | Begründung |
|---|---|---|
| Grobe Relevanz-Filterung | klein/günstig | einfache Klassifikation, hohes Volumen |
| Entitäts- und Kennzahl-Extraktion | klein bis mittel | strukturierte, eng umrissene Aufgabe |
| Nuancierte Tonanalyse, Zusammenfassung | mittel | Verständnis nötig, aber keine Spitzenleistung |
| Komplexe Synthese, Memo-Erstellung | stark | mehrstufiges Schließen, Qualität entscheidend |
Wer 80 Prozent des Volumens — die Vorfilterung — auf ein kleines Modell legt und nur die wenigen wirklich anspruchsvollen Fälle ans Spitzenmodell weiterreicht, senkt die Gesamtkosten massiv, ohne dort zu sparen, wo Qualität zählt.
Vorfilterung: gar nicht erst durchs Modell schicken.
Das günstigste Token ist das, das nie verarbeitet wird. Ein erheblicher Teil der Dokumente, die in eine Research-Pipeline fließen, ist für die konkrete Frage irrelevant — und lässt sich mit billigen, klassischen Mitteln aussortieren, bevor ein LLM überhaupt anläuft.
Schlüsselwort-Filter, Dubletten-Erkennung, Längen- und Sprachfilter, einfache Relevanz-Heuristiken: Diese Schritte kosten praktisch nichts und reduzieren das Volumen, das tatsächlich ein Modell sieht, oft um die Hälfte oder mehr. Erst was den Vorfilter passiert, geht in die teure Verarbeitung.
Ebenso wirksam ist es, lange Dokumente zu kürzen, bevor sie ins Modell gehen — nur die relevanten Abschnitte eines Geschäftsberichts statt der vollen hundert Seiten. Das erfordert etwas Vorarbeit, zahlt sich aber bei jedem einzelnen Aufruf aus, weil die Eingabe-Tokens den Preis dominieren.
Ein Rechenbeispiel und die Grenzen des Sparens.
Nehmen wir eine Pipeline, die täglich tausend Dokumente verarbeitet, jedes mit einem langen Prompt-Vorspann und vollem Text durch das Spitzenmodell. Ungeoptimiert summiert sich das schnell auf eine vierstellige Monatsrechnung. Mit Vorfilterung, die die Hälfte aussortiert, Routing, das die Vorfilterung selbst auf ein kleines Modell legt, Caching für den wiederholten Vorspann und Batch-Verarbeitung für den asynchronen Teil lässt sich diese Rechnung in der Praxis um einen Faktor von mehreren reduzieren — ohne dass die finalen Analysen schlechter werden.
Die ehrliche Grenze: Diese Optimierungen kosten Entwicklungs- und Wartungsaufwand. Eine Routing-Logik will gepflegt, ein Vorfilter justiert, ein Caching-Layout überwacht werden. Bei kleinem Volumen lohnt der Aufwand nicht — da ist die simple, teure Pipeline die wirtschaftlichere Wahl. Der Punkt, ab dem sich die Optimierung rechnet, liegt dort, wo die monatliche API-Rechnung spürbar wird. Und ein Restrisiko bleibt: Aggressive Vorfilterung kann relevante Dokumente verwerfen. Wer zu scharf filtert, spart an der falschen Stelle. Die Filter gehören regelmäßig gegen das geprüft, was sie aussortieren.
Ihre LLM-Research-Rechnung wächst schneller als das Volumen, und Sie wollen wissen, wo die Hebel liegen? Unverbindlich anfragen — wir analysieren gemeinsam, wo in Ihrer Pipeline die Tokens verbrennen, und priorisieren die Maßnahmen nach Ersparnis und Aufwand.