LLM-Determinismus im Trading wenn dieselbe Frage zwei Antworten gibt.

Ein LLM bekommt zweimal dasselbe Quartals-Filing vorgelegt und stuft es einmal als „leicht positiv“, einmal als „neutral“ ein. In einem Chatbot ist das harmlos. In einem Trading-System, das aus dieser Klassifikation ein Long-Signal ableitet, ist es ein echtes Problem: Der Backtest, mit dem Sie die Strategie validiert haben, ist dann nicht mehr reproduzierbar, und Live-Signal und historische Auswertung driften auseinander. Dieser Beitrag erklärt, woher die Schwankungen kommen — von der Sampling-Temperatur über nicht-deterministische GPU-Kernel bis zu stillen Modell-Updates beim Anbieter — und welche Stellschrauben tatsächlich helfen. Es geht um Temperatur und Seeds, um Self-Consistency-Voting, um das Einfrieren von Modellversionen und um die Frage, wann man Determinismus wirklich braucht und wann eine gut kalibrierte Wahrscheinlichkeit der bessere Weg ist. Außerdem ehrlich: Volle bit-genaue Reproduzierbarkeit ist über fremd gehostete APIs kaum erreichbar — und welche pragmatischen Alternativen bleiben.

Warum dasselbe Prompt zwei Antworten liefert.

Nicht-Determinismus bei LLMs hat mehrere, voneinander unabhängige Ursachen — und nur ein Teil davon liegt in Ihrer Kontrolle. Die offensichtlichste ist das Sampling: Bei einer Temperatur über null zieht das Modell den nächsten Token aus einer Wahrscheinlichkeitsverteilung, statt immer den wahrscheinlichsten zu nehmen. Schon ein einziger anders gewürfelter Token früh in der Antwort kann die ganze Klassifikation kippen.

Weniger bekannt: Auch bei Temperatur null sind Antworten über fremd gehostete APIs nicht garantiert identisch. Floating-Point-Operationen auf GPUs sind nicht assoziativ, und je nach Batch-Größe, Hardware-Generation oder paralleler Reduktionsreihenfolge ändern sich die letzten Nachkommastellen der Logits. Liegen zwei Tokens nah beieinander, entscheidet dieses Rauschen, welcher gewinnt.

Die dritte Ebene ist die unangenehmste: stille Modell-Updates. Wer gegen einen Alias wie ein generisches „latest“-Modell arbeitet, bekommt ohne Vorwarnung ein anderes Modell, sobald der Anbieter nachschiebt. Der Prompt ist gleich, das Verhalten nicht. Für ein produktives Trading-System ist das die gefährlichste Quelle, weil sie unsichtbar ist.

Temperatur, Top-p und Seeds richtig setzen.

Die erste Maßnahme ist banal und wird trotzdem oft vergessen: Für klassifikatorische Aufgaben — Sentiment, Themen-Tagging, Ereignis-Extraktion — gehört die Temperatur auf null oder sehr nah daran. Kreativität ist hier kein Wert, sondern ein Defekt. Auch top_p sollte eng stehen, damit das Modell nicht in den langen Schwanz unwahrscheinlicher Tokens greift.

Manche Anbieter bieten einen Seed-Parameter an, der Sampling-Entscheidungen reproduzierbar machen soll. In der Praxis hilft das innerhalb derselben Modellversion und Infrastruktur oft — aber es ist eine Best-Effort-Zusage, keine Garantie. Sobald der Anbieter die Bedienung im Hintergrund verschiebt, kann derselbe Seed andere Resultate liefern.

Eine nüchterne Einordnung, was die einzelnen Hebel leisten:

Die Tabelle macht klar: Es gibt keine einzelne Stellschraube, die das Problem löst. Reproduzierbarkeit entsteht aus der Kombination — und aus realistischen Erwartungen.

Self-Consistency: Mehrheitsentscheid statt Einzelschuss.

Wenn man Determinismus nicht erzwingen kann, kann man die Streuung wenigstens nutzen. Self-Consistency bedeutet: Dieselbe Frage wird drei- bis fünfmal gestellt, und das Ergebnis ist die Mehrheitsentscheidung. Schwankt das Modell zwischen „positiv“ und „neutral“, gewinnt die häufigere Antwort — und gleichzeitig liefert die Streuung selbst ein Maß für die Sicherheit.

Praktisch interessant ist die abgeleitete Konfidenz: Stimmen fünf von fünf Läufen überein, ist die Klassifikation belastbar. Geht es drei zu zwei aus, ist der Fall unsicher und sollte vielleicht gar kein Signal erzeugen. Diese Information ist im Trading wertvoller als die nackte Klasse, weil sie direkt ins Position-Sizing einfließen kann.

Der Preis ist offensichtlich: Drei bis fünf Aufrufe statt einem bedeuten drei- bis fünffache Kosten und Latenz. Für ein langsam laufendes Research-Signal, das einmal pro Tag oder pro Filing erzeugt wird, ist das vertretbar. Für hochfrequente Anwendungen ist es das nicht — dort braucht es entweder ein kleineres, lokal kontrolliertes Modell oder einen ganz anderen Ansatz.

Versionierung als Disziplin, nicht als Feature.

Der wirksamste Schritt gegen unbemerkte Drift kostet kein Geld: gegen eine fest benannte Modellversion arbeiten, niemals gegen einen gleitenden Alias. Datierte oder versionierte Modell-Identifier ändern ihr Verhalten nicht über Nacht; generische „neueste“-Aliasse tun es.

Versionierung muss aber tiefer gehen als nur das Modell. In einem reproduzierbaren Setup gehören mindestens diese Bestandteile in eine Art Manifest, das pro erzeugtem Signal mitgeschrieben wird:

• Modell-ID und Version — exakt, nicht „das aktuelle“.
• Prompt-Version — denn ein umformulierter Prompt ist ein anderes Experiment.
• Parameter — Temperatur, top_p, Seed, max_tokens.
• Eingabe-Hash — um identische Eingaben zweifelsfrei wiederzuerkennen.
• Zeitstempel und rohe Antwort — für spätere Audits.

Wer das konsequent protokolliert, kann später jeden einzelnen Trade auf die Frage zurückführen: Welches Modell hat mit welchem Prompt aus welcher Eingabe dieses Signal erzeugt? Ohne diese Spur ist ein LLM-getriebenes System nicht auditierbar — und damit für ernsthaftes Kapital ungeeignet.

Backtest und Live müssen dasselbe Modell sehen.

Eine subtile, teure Falle: Sie validieren eine Strategie historisch mit Modellversion A, gehen live, und einige Monate später läuft das System gegen Version B, weil der Alias nachgezogen ist. Der Backtest beschreibt jetzt ein System, das es nicht mehr gibt. Die im Test gemessene Trefferquote ist nicht mehr gültig, und niemand hat es gemerkt.

Sauber ist nur, was reproduzierbar dieselbe Pipeline durchläuft. Das heißt konkret: Die LLM-Klassifikationen für den historischen Zeitraum werden mit exakt der Modellversion und denselben Parametern erzeugt, die auch live arbeiten. Wird das Modell gewechselt, ist das ein neues Strategie-Release — mit eigenem Backtest, eigener Validierung, eigener Freigabe.

Es lohnt sich, die LLM-Ausgaben zu cachen: Einmal pro Eingabe-Hash klassifizieren, Ergebnis speichern, im Backtest aus dem Cache lesen. Das spart nicht nur Kosten, sondern erzwingt auch Konsistenz, weil derselbe Input zwangsläufig dasselbe Label liefert — unabhängig davon, wie das Modell sich zwischenzeitlich verhalten würde.

Wann lokale Modelle den Aufwand wert sind.

Volle Kontrolle über Determinismus bekommt man erst, wenn man das Modell selbst hostet — fixe Gewichte, fixe Hardware, fixe Inferenz-Konfiguration. Bei deterministischen Kerneln und kontrollierter Batch-Größe ist dann nahezu bit-genaue Reproduzierbarkeit erreichbar. Für regulierte Umgebungen oder hohe Auditanforderungen kann das den Ausschlag geben.

Der Preis ist allerdings real: Betrieb von GPU-Infrastruktur, Modellpflege, schwächere Sprachfähigkeit kleinerer Open-Modelle gegenüber den großen gehosteten Spitzenmodellen. Für viele mittelständische Anwendungen rechtfertigt der Konsistenzgewinn diesen Aufwand nicht — die Kombination aus gepinnter Version, Caching und Self-Consistency reicht aus.

Die ehrliche Faustregel: Lokal lohnt sich, wenn Reproduzierbarkeit ein regulatorisches Muss ist oder wenn die Aufrufvolumina so hoch sind, dass API-Kosten und Latenz ohnehin zum Problem werden. Geht es nur um „etwas weniger Schwankung“, ist es überdimensioniert.

Wo Determinismus das falsche Ziel ist.

Es gibt Fälle, in denen das Streben nach bit-genauer Reproduzierbarkeit in die Irre führt. Wenn ein Modell zwischen zwei sinnvollen Antworten schwankt, ist das oft kein Bug, sondern ein ehrliches Signal dafür, dass der Fall tatsächlich uneindeutig ist. Ein Filing, das mal als „leicht positiv“, mal als „neutral“ klassifiziert wird, ist eben genau das: ein Grenzfall.

Statt Schwankung zu unterdrücken, kann man sie als Konfidenzmaß lesen. Eindeutige Fälle klassifiziert das Modell stabil; uneindeutige nicht. Eine gut kalibrierte Wahrscheinlichkeit ist hier informativer als ein erzwungen deterministisches Label — und sie schützt davor, auf wackligen Klassifikationen zu handeln, als wären sie sicher.

Determinismus ist also Mittel, nicht Zweck. Das Ziel ist ein System, dessen Verhalten man versteht und reproduzieren kann — und das ehrlich kommuniziert, wann es unsicher ist. Reproduzierbarkeit der Pipeline und Kalibrierung der Unsicherheit zusammen ergeben ein belastbares System; reiner Determinismus ohne Kalibrierung kann sogar trügerische Sicherheit erzeugen.

Sie setzen LLMs für Research- oder Signal-Klassifikation ein und Ihre Backtests lassen sich nicht sauber reproduzieren? Unverbindlich anfragen — wir schauen gemeinsam auf Versionierung, Caching und Self-Consistency und bauen eine Pipeline, deren Signale Sie auditieren und im Backtest exakt nachstellen können.