Wie sich Nichtdeterminismus bei LLM-Inferenz überwinden lässt

• Bei der LLM-(Large Language Model)-Inferenz tritt das Problem des Nichtdeterminismus (nondeterminism) auf, bei dem selbst bei identischer Eingabe und identischen Bedingungen unterschiedliche Ergebnisse entstehen
• Bisher galten vor allem Nebenläufigkeit (concurrency) und Nichtassoziativität von Gleitkommaoperationen (floating-point non-associativity) als Hauptursachen des Nichtdeterminismus
• Die tatsächlich entscheidende Ursache liegt jedoch in Änderungen der Reihenfolge interner Berechnungen im Kernel (Ausführungscode), die durch Änderungen der Batch-Größe (batch size) ausgelöst werden
• Wenn alle Operationen innerhalb des Kernels so implementiert werden, dass sie Batch-Invarianz (batch invariance) besitzen, lässt sich vollständige Reproduzierbarkeit (reproducibility) garantieren
• Mit datenparallelen Operationen, Split-Reduction, Strategien mit fester Split-Größe usw. lassen sich für zentrale Operationen (RMSNorm, matmul, attention) batch-invariante Kernel erstellen

---

Einleitung und Problemüberblick

• Reproduzierbarkeit, ein Kernelement wissenschaftlichen Fortschritts, ist bei der LLM-(Large Language Model)-Inferenz nur unzureichend gewährleistet
• Selbst wenn man ChatGPT mehrfach dieselbe Frage stellt, entstehen häufig unterschiedliche Antworten
• Der Grund dafür ist, dass die Sampling-Phase in LLMs auf einer Wahrscheinlichkeitsverteilung basiert und dadurch stochastische Auswahl erfolgt
• Doch selbst wenn temperature auf 0 gesetzt wird, ist eine LLM-API in der Praxis nicht zwingend deterministisch (das heißt, sie liefert bei gleicher Eingabe nicht immer dasselbe Ergebnis)
• Das Problem des Nichtdeterminismus besteht auch bei Open-Source-Inferenzbibliotheken (vLLM, SGLang usw.) und beim Betrieb auf eigener Hardware

Bisherige Hypothesen und ihre Grenzen

• Weit verbreitete Hypothese: Nichtdeterminismus entsteht durch Nebenläufigkeit + Nichtassoziativität von Gleitkommazahlen
  • Gleitkommaoperationen auf GPUs liefern je nach Berechnungsreihenfolge und Abschlussreihenfolge der Threads leicht unterschiedliche Resultate
• Tatsächlich erhält man jedoch immer dasselbe bitweise identische Ergebnis (bitwise equal), selbst wenn dieselbe Matrixmultiplikation mit denselben Daten wiederholt ausgeführt wird
• Um die wahre Ursache zu verstehen, ist eine tiefergehende Analyse nötig

Tiefenanalyse der Ursachen von Nichtdeterminismus bei der LLM-Inferenz

Das Wesen der Nichtassoziativität von Gleitkommaoperationen

• Für Gleitkommaoperationen gilt die Beziehung (a+b)+c ≠ a+(b+c)
• Bei Operationen mit Werten unterschiedlicher Größenordnung (Exponent) treten Präzisionsverlust und Informationsverlust auf, sodass sich das Ergebnis je nach Reihenfolge der Operationen ändert
• Da sich die Reihenfolge von Operationen ändern kann, führen wiederholte zufällige Summierungen zu unterschiedlichen Ergebnissen (auch experimentell bestätigt)

Änderung der Operationsreihenfolge im Kernel und Nebenläufigkeit

• Als Hauptursache für Nichtdeterminismus werden üblicherweise Nebenläufigkeitsprobleme wie atomic add genannt
• Die meisten in der LLM-Inferenz verwendeten Kernel (insbesondere im Forward Pass) funktionieren jedoch auch ohne atomic add
• Mit geeigneten Parallelisierungsstrategien und Split-(Reduction)-Verfahren lässt sich dieselbe Operationsreihenfolge sicherstellen

Die eigentliche Kernursache: fehlende „Batch-Invarianz (batch invariance)“

• Einzelne Kernel liefern bei identischer Eingabe stets dasselbe Ergebnis (run-to-run deterministic)
• Da sich jedoch gleichzeitige Anfragen mehrerer Nutzer und damit die Batch-Größe nichtdeterministisch ändern, bleiben die Ergebnisse für einzelne Anfragen in der Praxis nicht konstant
• Je nach Batch-Größe wird intern die Reihenfolge verändert, in der Berechnungen aufgeteilt oder zusammengeführt werden, wodurch Nichtdeterminismus entsteht
• Der eigentliche Kern des Problems ist also, dass Serverlast und Parallelität (Batch-Größe) nicht deterministisch waren

Design batch-invarianter Kernel und Beispiele zentraler Operationen

RMSNorm

• Anwendung einer datenparallelen (data-parallel) Strategie: Jedes Batch-Element wird unabhängig von einem einzelnen Kern verarbeitet
• Bei großer Batch-Größe bleibt genügend Parallelität erhalten, sodass die Parallelisierungsstrategie konstant bleibt und Batch-Invarianz erreicht wird
• Bei sehr kleiner Batch-Größe werden alternative Strategien wie Split-Reduction verwendet, wobei in diesem Fall ein Teil der Batch-Invarianz aufgegeben wird

Matrixmultiplikation (matmul)

• Nutzung einer datenparallelen Strategie durch Parallelisierung nach Tiles
• Um die Nutzung von Tensor Cores zu optimieren, ist eine Aufteilung in 2D-Tiles erforderlich; bei sehr kleinen Batches sind spezielle Strategien wie split-K nötig
• Bei Verwendung von split-K kann die Batch-Invarianz verletzt werden
• Selbst wenn dafür etwas Leistung geopfert wird, lässt sich durch Erzwingen derselben Kernel-Konfiguration eine konstante und damit reproduzierbare Operationsreihenfolge sichern

Attention

• In FlashAttention2 und ähnlichen Verfahren wird Batch-Invarianz durch Parallelisierung in Query-Richtung und gleichzeitige Reduction über Key/Value erreicht
• Ändert sich die Reihenfolge der Reduction je nach Batch-Größe oder Sequenzaufteilung (chunked prefill, prefix caching usw.), geht die Invarianz verloren
• Bei Split-Reduction-Strategien wie split-KV (FlashDecoding) bleibt die Operationsreihenfolge gleich, indem eine feste Split-Größe (fixed split-size) verwendet wird
• Intern müssen Key/Value-Cache und neue Token konsistent behandelt werden; dazu darf man sie nicht getrennt verarbeiten, sondern muss in allen Operationen ein einheitliches Key/Value-Layout beibehalten

Implementierung

• Mit vLLM und torch.Library wird eine Demo für deterministische Inferenz mit batch-invarianten Kerneln bereitgestellt
• Ersetzungskernel für die betreffenden Operationen sind im GitHub-Repo thinking-machines-lab/batch-invariant-ops verfügbar

Experimente und Leistung

Experiment zur Messung von Nichtdeterminismus

• Mit dem Modell Qwen/Qwen3-235B-A22B-Instruct-2507 wurden unter temperature 0 1000 Generierungen mit demselben Prompt („Tell me about Richard Feynman“) ausgeführt
• Es entstanden 80 unterschiedliche Vervollständigungen (trotz identischem Prompt also vorhandener Nichtdeterminismus)
• Die ersten 102 Token waren identisch, die erste Verzweigung trat beim 103. Token auf („Queens, New York“ vs „New York City“)
• Bei Verwendung batch-invarianter Kernel waren alle 1000 Ergebnisse identisch, womit vollständige Reproduzierbarkeit erreicht wurde

Leistungsbewertung

• Auf 1 GPU, mit Qwen-3-8B und 1000 Anfragen mit Sequenzlängen von jeweils 90 bis 110
  • vLLM Standard: 26 Sekunden
  • Nicht optimiertes deterministisches vLLM: 55 Sekunden
  • Mit verbessertem Attention-Kernel: 42 Sekunden
• Die Optimierung ist noch begrenzt, doch die Leistung bleibt auf einem praktisch nutzbaren Niveau

Nutzen für On-policy RL

• Bisher ließ sich On-policy RL wegen kleiner numerischer Unterschiede zwischen Training und Inferenz nicht exakt umsetzen
• Mit deterministischer Inferenz lassen sich Sampling und Training bitweise identisch ausführen, sodass echtes On-policy RL möglich wird
• Bei wichtigen Metriken wie KL-divergence und Reward wurde vollständige Übereinstimmung der Ergebnisse bestätigt

Fazit

• In LLM-Inferenzsystemen werden Nichtdeterminismus und numerische Fehler leicht übersehen, doch wenn man die Grundursache (fehlende Batch-Invarianz) identifiziert und behebt, lassen sich vollständige Reproduzierbarkeit und Determinismus erreichen
• Diese Arbeit zeigt einen Weg zur Lösung des Nichtdeterminismusproblems bei der LLM-Inferenz auf und hilft Entwicklerinnen und Entwicklern, in ihren eigenen Systemen vollständige Reproduzierbarkeit zu erreichen

Zitationshinweis

• Für die Zitierung dieser Arbeit sollen die folgenden Angaben verwendet werden

He, Horace and Thinking Machines Lab, "Defeating Nondeterminism in LLM Inference", 
Thinking Machines Lab: Connectionism, Sep 2025.

oder

@article{he2025nondeterminism,
  author = {Horace He and Thinking Machines Lab},
  title = {Defeating Nondeterminism in LLM Inference},
  journal = {Thinking Machines Lab: Connectionism},
  year = {2025},
  note = {https://thinkingmachines.ai/blog/…},
  doi = {10.64434/tml.20250910}
}