temperature: 0 heißt nicht deterministisch

Der Messaufbau

temperature: 0 wird oft als Schalter für reproduzierbare LLM-Ausgaben verstanden. Das ist zu kurz gedacht. Die Einstellung reduziert die Zufallsauswahl bei der Decodierung. Sie garantiert aber nicht, dass zwei API-Aufrufe tatsächlich unter identischen technischen Bedingungen laufen.

Ich habe einen Klassifikations-Lauf über OpenRouter zweimal mit identischen 18 Eingaben ausgeführt. Beide Aufrufe verwendeten temperature: 0 und top_p: 1. Trotzdem wichen 4 von 18 Einzelurteilen ab. Dadurch kippte auch das Gesamturteil der Klassifikation.

Das ist kein Argument gegen LLMs. Es ist ein Architekturthema: Wer LLM-Urteile in Produktlogik, Freigaben oder automatisierte Entscheidungen einbaut, muss LLM Reproduzierbarkeit explizit herstellen.

Warum LLM temperature 0 nicht genügt

Die Temperatur beeinflusst, wie ein Modell aus möglichen nächsten Tokens auswählt. Bei temperature: 0 wird typischerweise die wahrscheinlichste Option gewählt. Das hilft bei stabileren Antworten, fixiert aber weder die ausführende Infrastruktur noch alle numerischen Details der Inferenz.

Die entscheidende Frage lautet deshalb nicht nur: Welcher Modell-Slug wurde aufgerufen? Sondern auch: Bei welchem Provider, auf welcher Infrastruktur und mit welcher Modellvariante lief dieser konkrete Request?

Ursache 1: OpenRouter Provider Routing

Hinter einem Modellnamen können mehrere Host-Anbieter stehen. Beim OpenRouter Provider Routing kann ein Request also heute bei einem anderen Anbieter landen als der nächste, obwohl Modell, Prompt und Parameter gleich bleiben.

Das ist relevant, weil sich die Ausführungsumgebung unterscheiden kann. Beispiele sind andere Hardware oder eine andere Quantisierung des bereitgestellten Modells. Schon kleine numerische Unterschiede können bei knappen Token-Wahrscheinlichkeiten eine andere Auswahl auslösen. Bei einer Klassifikation reicht dann unter Umständen ein abweichendes Token, damit ein Grenzfall anders bewertet wird.

Für nichtkritische Funktionen ist diese Flexibilität oft sinnvoll: Routing verbessert Verfügbarkeit und kann Ausfälle abfedern. Für reproduzierbare Bewertungspipelines ist sie dagegen eine zusätzliche Variable, die kontrolliert werden sollte.

Ursache 2: Mixture-of-Experts und Batch-Effekte

Bei Mixture-of-Experts-Modellen kommt eine weitere Variable hinzu. Solche Modelle aktivieren je nach Eingabe nur einen Teil ihrer Experten. Welcher Experte für ein Token ausgewählt wird, hängt vom Routing ab.

In der Praxis kann dieses Routing auch vom Batch beeinflusst werden, also davon, welche weiteren Anfragen gleichzeitig verarbeitet werden. Selbst wenn ein einzelner Request aus Anwendungssicht identisch ist, kann seine Umgebung auf Inferenzebene variieren.

Damit ist ein LLM nicht automatisch deterministisch, nur weil temperature: 0 gesetzt ist. Das gilt besonders für Entscheidungen nahe einer Grenze: etwa wenn zwei Kategorien ähnlich plausibel sind oder eine Begründung nur schwach in eine Richtung weist.

Provider festnageln

Der erste konkrete Schritt ist Provider-Pinning. Statt nur einen Modell-Slug zu senden, wird eine feste Provider-Reihenfolge vorgegeben und Fallback deaktiviert. Das Schema sieht beispielsweise so aus:

{
  "model": "modell-slug",
  "temperature": 0,
  "top_p": 1,
  "provider": {
    "order": ["provider-id"],
    "allow_fallbacks": false
  }
}

Damit wird ein Request nicht unbemerkt auf einen anderen Host umgeleitet. Der Preis ist bewusst gewählt: Ist der festgelegte Provider nicht verfügbar, schlägt der Request fehl. Für kritische Klassifikationen ist ein sichtbarer Fehler häufig besser als ein Ergebnis, das unter veränderten Bedingungen entsteht.

Provider-Pinning beseitigt nicht jede Quelle von Varianz. Es reduziert aber eine zentrale, vermeidbare Variable und macht Fehleranalyse wesentlich klarer.

Wann Mehrfachabfrage reicht

Für wichtige Urteile empfehle ich zusätzlich Mehrfachabfragen. Dieselbe Klassifikation wird mehrfach ausgeführt, anschließend wird etwa über Mehrheitsentscheidung oder einen klar definierten Konfliktstatus entschieden.

Das macht den Fehler allerdings nur einseitig kleiner, nicht verschwunden. Eindeutige Fälle sind typischerweise stabil. Grenzfälle bleiben Grenzfälle und können auch bei Wiederholung auseinanderlaufen. Eine Mehrheitsentscheidung darf daher nicht als Beweis für Wahrheit behandelt werden.

Praktisch ist eine dreistufige Behandlung: stabile Übereinstimmung automatisiert weiterverarbeiten, abweichende Wiederholungen markieren und für unklare Fälle einen expliziten Prozess vorsehen. Welche Folge daraus entsteht, hängt vom Risiko der jeweiligen Produktentscheidung ab.

Fazit

temperature: 0 ist eine sinnvolle Einstellung für konsistentere Ausgaben, aber keine Garantie für deterministische LLM-Inferenz. Modellname und Prompt allein sind kein vollständiger Reproduzierbarkeitsvertrag. Provider, Fallback-Verhalten und bei MoE-Modellen die Inferenzumgebung gehören zur technischen Realität.

Prüft eure LLM-Pipeline: Ist der Provider festgenagelt oder nur das Modell?