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

 (thinkingmachines.ai)
2 Punkte von GN⁺ 2025-09-12 | 1 Kommentare | Auf WhatsApp teilen
  • 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}
}

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-09-12
Hacker-News-Kommentare

  • Selbst wenn man die „theoretische“ Nichtdeterministik bei vollständig abgeschlossenen einzelnen Eingabe-Ausgabe-Paaren beseitigt, bleiben in der Praxis zwei nichtdeterministische Probleme bestehen: dass dieselbe Eingabe je nach vorherigem Kontext unterschiedliche Ergebnisse liefert, und dass leicht veränderte Eingaben nicht entsprechend korrekt veränderte Ergebnisse liefern. Solange diese Probleme nicht gelöst sind, ist Nichtdeterministik in einem geschlossenen System nicht besonders hilfreich, außer in Fällen, in denen auch eine einfache Nachschlagetabelle ausreichen würde. Für nicht getestete Eingaben lässt sich mit „korrekten“ Unit-Tests oder Evaluations-Sets kaum irgendetwas beweisen

    • Die Situation, dass bei „exakt derselben Eingabe je nach unterschiedlichem vorherigem Kontext andere Ergebnisse herauskommen“, existiert in Wirklichkeit nicht. Der vorherige Kontext ist selbst Teil der Eingabe. Wenn bei einem bestimmten Eingabe-Prompt immer dasselbe Ergebnis herauskommt, kann man davon ausgehen, dass der Kontext ignoriert wird. Das ist also gleichbedeutend damit, unabhängig vom Sitzungszustand immer mit leerem Kontext zu starten. Was manche Leute eigentlich wollen, ist,

      • dass verschiedene Prompt-Formulierungen mit gleicher Bedeutung (z. B. "What is the capital of France" und "What is France's capital") exakt dieselbe Antwort liefern
      • dass der vorherige Kontext das Ergebnis nicht beeinflusst, wenn er mit der Frage überhaupt nicht interagiert. Zum Beispiel sollte auf den Prompt "what is 2 + 2" immer dieselbe Antwort kommen und sich nur dann ändern, wenn im Kontext festgelegt wurde, dass 2 + 2 = 5 ist. Diese Forderungen zeigen, dass das Wesen von LLMs missverstanden wird

    • Warum soll es ein Problem sein, dass „vorheriger Kontext“ unterschiedliche Ergebnisse erzeugt? Wenn der Kontext das Ergebnis nicht beeinflusst, kann man ihn einfach wegwerfen. Warum sollte man ein solches Verhalten überhaupt wollen? Bei realen Werkzeugen erwartet man doch auch, dass sie abhängig von meiner Absicht oder einem Moduswechsel unterschiedlich reagieren (z. B. in vim nach dem Wechsel in den Insert-Modus). Ich möchte auch, dass Intelligenz so funktioniert. Kontext zu ignorieren wirkt eher wie eine extreme Form von Confirmation Bias

    • Beim Reproduzieren von Bugs ist das extrem nützlich

    • Bis zu dem Punkt „nicht besonders hilfreich“ hatte ich zugestimmt. Vermutlich war damit eher gemeint: „löst das Problem nicht vollständig“

  • Ich frage mich, warum man sich bei einem probabilistischen System so sehr um Determinismus sorgt. Aus Sicht der Nutzer bringt es wenig, wenn auf die Eingabe "How do I X?" immer dieselbe deterministische Antwort kommt, aber auf semantisch gleiche Eingaben wie "how do i x?", "how do I x" oder "how do I X??" völlig andere Ergebnisse folgen. Was bei LLMs wirklich gebraucht wird, ist die Fähigkeit zu garantieren, dass semantisch gleiche Eingaben auch immer semantisch gleiche Ausgaben erzeugen. Das ist ein völlig anderes Konzept als das, was wir bei Algorithmen normalerweise Determinismus nennen

    • Nicht alle LLM-basierten Anwendungen bestehen nur aus einer Chat-Oberfläche, in die Nutzer spontan hineinschreiben. Wenn man zum Beispiel Tool-Calls zehnmal hintereinander zu Evaluationszwecken ausführt oder mit Tools wie dem DSPy Optimizer Link Prompts fortlaufend testet und man die Eingabe bis auf Token-Ebene vollständig kontrollieren kann, dann ist es wichtig, Unvorhersehbarkeit zu reduzieren. In solchen Umgebungen kann man, wenn sich Variabilität auf Token-Ebene eliminieren und damit nur die Mehrdeutigkeit der Eingabe übrig bleibt, das Verhalten des Systems viel verlässlicher auf baum- oder graphartige Strukturen abbilden

    • Du liegst nicht falsch, aber das bedeutet nicht, dass diese Art von Determinismus nutzlos ist. Wenn selbst bei exakt denselben Eingabe-Token jedes Mal ein anderes Ergebnis herauskommt, ist es schwierig, Ergebnisse gemeinsam mit Kollegen reproduzierbar zu teilen oder Situationen zu testen, in denen ein LLM sehr seltene und schwer vorhersagbare Ausgaben erzeugt, etwa beim Red Teaming

    • Ich arbeite an einem Projekt, das Informationen per Steganografie in LLM-Ausgaben einbettet: innocuous. Wir extrahieren und verwenden nur ungefähr die Top-10-Token des Modells, und da wir meist mit CPU-basierten 8B-Modellen testen, ist die Sorge geringer, dass sich die Token-Reihenfolge durch Hardware-Einflüsse ändert. Ich plane aber trotzdem, irgendwann Guard-Bedingungen einzubauen, damit sich durch winzige Präzisionsverluste die Auswahl nicht verändert

    • Für Kunden von AI-Plattformen kann das sehr nützlich sein. Man kann einen Prompt mehrfach mit Temperature 0 ausführen und prüfen, ob stets dasselbe Ergebnis herauskommt, um zu verifizieren, ob ein AI-Anbieter heimlich das PRO-Modell durch ein billigeres anderes Modell ersetzt hat

    • Zum Reproduzieren von „Bugs“ ist das zwingend notwendig. Wenn man bei identischem Eingabestring jedes Mal dieselbe fehlerhafte oder ungewöhnliche Ausgabe reproduzieren kann, wird Debugging viel einfacher. Wenn das Ergebnis nur jedes hundertste Mal abweicht, ist es deutlich schwieriger

  • (Erfahrung mit JAX/XLA) Das ist ziemlich gut bekannt. Ich bin selbst schon mehrfach auf dieses Phänomen gestoßen (Variabilität auf Batch-Ebene) und habe in den folgenden Issues Erklärungen dazu gefunden: penzai issue #82, jax issue comment

    • Ich finde, das sollte der Top-Kommentar sein

  • Manchmal liegt die Ursache der Nichtdeterministik in Implementierungsdetails. Zum Beispiel wird im GPT-2-Quellcode selbst dann, wenn man in der GUI die Temperature auf 0 setzt, tatsächlich ein von 0 verschiedenes "epsilon" (eine sehr kleine Zahl) verwendet. Das ist nachvollziehbar, weil damit ein Division-by-zero-Fehler vermieden wird. Nichtdeterministik ist in vielen Anwendungen „nutzlos“. Das ist auch bei LDA-Topic-Modellen ein altes Problem. Besonders im Rechts-, Finanz- und Regulierungsbereich kann der Einsatz nichtdeterministischer Methoden sogar illegal sein. Oder es entstehen unerwünschte zusätzliche Pflichten, etwa sämtliche Bildschirmaufzeichnungen aufzubewahren, damit sich später jeder einzelne Vorgang rekonstruieren lässt

  • Es wird erwähnt, dass jemand „mit anderen bei Thinking Machines arbeitet“. Das weckt bei mir Nostalgie an die Zeit, als ich die Maschine mit den leuchtenden roten LED-Würfeln noch direkt vor dem MIT AI Lab sehen konnte. Richard Feynman hat dort wirklich großartige Arbeit geleistet, dazu gibt es auch einen Text: Feynman and the Connection Machine. In den USA war die Marke „THINKING MACHINES“ nicht auf Hillis persönlich, sondern auf das von ihm gegründete Unternehmen eingetragen und wurde 1998–1999 gelöscht. Die Firma ging 1994 bankrott, und ihre Vermögenswerte gingen unter anderem an Sun Microsystems (später Oracle) über. Thinking Machines Lab Inc., gegründet von Amira Murati, betreibt 2025 eine neue Markenanmeldung für „THINKING MACHINES“

    • Jedes Mal, wenn ich diesen Firmennamen sehe, komme ich auf genau diese Verwechslung

  • Es ist wirklich schön, in letzter Zeit so viele hochwertige forschungsnahe Diskussionen im Blog-Stil zu sehen. Anthropic treibt diese Kultur voran, und ich hoffe sehr, dass sie sich weiter verbreitet. Früher, in der RL-Forschungsphase, war OpenAI auch so

  • Natürliche Sprache ist von Natur aus mehrdeutig. Sie muss es auch sein. Ich halte diesen Ansatz hier, also den Versuch, „einen Kreis quadratisch zu machen und dann zu erklären, warum das so sein muss“, für falsch. Solche Diskussionen werden sich letztlich dahin entwickeln, Sprache und Zufälligkeit in ihrem Wesen besser zu akzeptieren und Sprache auf einer Ebene jenseits von Mini-Grammatik-Submustern wie QKV projection matrix zu interpretieren

    • Das stimmt. Determinismus ist aber nicht dasselbe wie Mehrdeutigkeit. Determinismus bedeutet: „Für genau diese Eingabe muss genau diese Ausgabe garantiert werden.“ Wenn ich demselben Modell dieselbe Frage stelle, erwarte ich unbedingt dieselbe Antwort. Natürlich verstehe ich vollkommen, dass bei leicht anders formulierten Fragen auch etwas andere Antworten herauskommen können

  • Mir gefällt der Firmenname immer noch nicht. Ich frage mich, warum sich solche Namensgebungen ständig wiederholen. Vielleicht steckt der Wunsch dahinter, dass der Charakter einer legendären Organisation irgendwie auf ein junges Venture übergeht. Aber nur weil man sein nächstes Startup PARC nennt, folgt daraus ja nicht automatisch eine Revolution im Networking

    • Meinst du die Firma „Thinking Machines“, die 1994 verschwunden ist? Ich musste erst nachschlagen, um das einzuordnen, und so berühmt ist sie offenbar nicht, daher ist das vermutlich nicht die Absicht. Ich halte den Namen einfach für cool und intuitiv

    • Allein durch die Namensgebung kommt Marketing quasi gratis mit, was im Grunde auch dem ursprünglichen Zweck des Markensystems entspricht

  • Wirklich interessant. Für diejenigen, die es nicht wissen: Dieses Unternehmen wurde von der früheren OpenAI-CTO Mira Murati gegründet