Die Nichtdeterministik von GPT-4 liegt an Sparse MoE

• Das Phänomen, dass GPT-4 und GPT-3.5-turbo selbst bei temperature=0 für dieselbe Eingabe jedes Mal unterschiedliche Ausgaben liefern, ist ein ungewöhnliches Verhalten, das bei bisherigen dichten Decoder-Modellen nicht auftritt
• Bislang wurde die Ursache der Nichtdeterministik mit der Instabilität von CUDA-Gleitkommaoperationen erklärt, doch das allein reicht als Erklärung nicht aus
• In der Struktur der batched inference einer Sparse-MoE-Architektur entsteht Nichtdeterministik, weil Tokens aus verschiedenen Sequenzen innerhalb desselben Batches um Plätze im Expert-Buffer konkurrieren
• In einem Experiment mit 30 wiederholten Aufrufen erzeugte GPT-4 im Vergleich zu anderen Modellen mit Abstand die meisten einzigartigen Ausgaben und stützt die Hypothese damit empirisch
• Dass das Modell nicht auf Sequenzebene, sondern nur auf Batch-Ebene deterministisch ist, ist die zentrale Ursache für die Zuverlässigkeitsprobleme der GPT-4-API

---

Problemstellung — Warum ist die Ausgabe trotz temperature=0 jedes Mal anders?

• Dass GPT-4/GPT-3.5-turbo selbst bei temperature=0.0 nicht deterministisch sind, ist bereits weithin bekannt
  • Bei dichten decoder-only-Modellen bedeutet temp=0 greedy sampling, was eigentlich zu vollständiger Deterministik führen sollte
  • Denn die Logits des nächsten Tokens sind eine reine Funktion der Eingabesequenz und der Modellgewichte
• Antwort des technischen Teams beim OpenAI World Tour Developer Roundtable
  • Sinngemäß: „Ehrlich gesagt sind wir selbst verwirrt. Es könnte ein Systemfehler sein oder die Nichtdeterministik optimierter Gleitkommaberechnungen.“
• Dass dieses Verhalten trotz Hinweisen bereits seit zwei Jahren nicht behoben wurde, wirft Fragen auf
  • Da OpenAI Zuverlässigkeit betont und keinen offensichtlichen Grund hätte, Nichtdeterministik absichtlich beizubehalten, galt zunächst eine unüberwindbare Hardware-Grenze als plausibelste Erklärung

Neue Hypothese — Ein Hinweis aus dem Soft-MoE-Paper

• In Abschnitt 2.2 des Soft MoE-Papers findet sich ein entscheidender Zusammenhang
  • Unter Kapazitätsbeschränkungen (capacity constraints) routen alle Sparse-MoE-Verfahren Tokens in Gruppen fester Größe und erzwingen oder fördern Ausgewogenheit innerhalb der Gruppe
  • Wenn eine Gruppe Tokens aus unterschiedlichen Sequenzen/Eingaben enthält, konkurrieren diese Tokens um freie Plätze im Expert-Buffer
  • Das Ergebnis: Das Modell ist auf Sequenzebene nichtdeterministisch und nur auf Batch-Ebene deterministisch, und manche Eingabesequenzen beeinflussen die endgültige Vorhersage anderer Eingaben
• Dass GPT-4 ein Mixture of Experts-Modell ist, ist bereits öffentlich bekannt
  • GPT-4 wurde vor dem zweiten Quartal 2022 trainiert, und Sparse MoE existierte schon davor
• Die zentrale Hypothese lautet
  • Die GPT-4-API wird auf einem Backend mit batched inference gehostet
  • Andere Faktoren mögen ebenfalls einen gewissen Einfluss haben, doch der Großteil der API-Nichtdeterministik entsteht dadurch, dass die Sparse-MoE-Architektur keine sequenzweise Deterministik erzwingen kann

Überprüfung — Bestätigung, dass es kein Hardwareproblem ist

• Zur Überprüfung der Hypothese wurde GPT-4 direkt gebeten, ein Testskript zu schreiben
  • Für Chat-Modelle (gpt-4, gpt-3.5-turbo) und Completion-Modelle (text-davinci-003/001, davinci-instruct-beta, davinci) wurde derselbe Prompt mit temperature=0 wiederholt aufgerufen und die Anzahl einzigartiger Ausgaben gezählt
• Probleme beim Schreiben des Skripts
  • Die Antworten der OpenAI-API waren sehr langsam; selbst Aufrufe von 3.5 turbo hatten fast 10 Sekunden Verzögerung. Durch zusätzliches Timestamp-Logging wurde bestätigt, dass es kein eigener Fehler war
  • Einige Completion-Modelle schnitten die Antwort früh ab; das wurde durch Anwendung von logit bias auf das EOS-Token korrigiert
  • Auf das <|im_end|>-Token (100265) der Chat-Modelle ließ sich kein entsprechender Bias anwenden, weil die API einen Schlüssel-Fehler für Werte über dem Maximum 100257 zurückgab
    • Da die meisten Completions ohnehin die maximale Tokenlänge erreichten und die Chat-Modelle bereits deutlich nichtdeterministischer waren, wurde diese Einschränkung als nebensächlich bewertet

Empirische Ergebnisse

• Einzigartige Ausgaben (Durchschnitt/30) unter den Bedingungen 3 Durchläufe, N=30, max_tokens=128
  • gpt-4: 12, 11, 12 — Durchschnitt 11.67
  • gpt-3.5-turbo: 4, 4, 3 — Durchschnitt 3.67
  • text-davinci-003: 3, 2, 4 — Durchschnitt 3.00
  • text-davinci-001: 2, 2, 2 — Durchschnitt 2.00
  • davinci-instruct-beta: 1, 1, 1 — deterministisch, Ausgabe kollabierte in eine Wiederholungsschleife
  • davinci: 1, 1, 1 — deterministisch, Ausgabe kollabierte in eine Wiederholungsschleife
• Ergebnisse vor Entdeckung des logit_bias-Problems bei max_tokens=256
  • gpt-4: 30, gpt-3.5-turbo: 9, text-davinci-003: 5, text-davinci-001: 2

Interpretation der Ergebnisse

• Die Zahl einzigartiger Ausgaben von GPT-4 ist ungewöhnlich hoch; bei längeren Ausgaben ist es faktisch fast immer nichtdeterministisch
• Andere Modelle, die nicht in Wiederholungsschleifen kollabierten, zeigen ebenfalls ein gewisses Maß an Nichtdeterministik; das passt zu der öffentlichen Aussage, dass instabile GPU-Berechnungen einen Teil der Zufälligkeit verursachen
• Offene Fragen bleiben
  • Warum die Zufälligkeit von text-davinci-001 bis gpt-3.5-turbo schrittweise zunimmt, ist nicht klar erklärt
  • Es lässt sich auch nicht vollständig ausschließen, dass die starke Nichtdeterministik von GPT-4 eher an der bloßen Parameterzahl als an MoE liegt; allerdings widerspricht diesem Erklärungsansatz, dass das schnellere Turbo nichtdeterministischer als davinci ist

Implikationen

Wir liegen zu weit zurück

• Wenn Nichtdeterministik eine inhärente Eigenschaft von batched inference in Sparse MoE ist, müsste das für Fachleute in diesem Bereich eigentlich offensichtlich sein
• Dass die meisten GPT-4-Nutzer die Ursache der API-Instabilität nicht kennen, deutet darauf hin, dass entweder die Hypothese falsch ist oder zu wenige Menschen MoE-Modelle gut genug verstehen, damit diese Erklärung öffentlich breiter diskutiert wird
• Google Deepmind wusste davon offenbar und behandelte es im Paper mit einem beiläufigen Satz, was Anlass gibt, in Deepmind mehr Optimismus zu setzen als in andere Organisationen, die nur mit dichten Modellen arbeiten

GPT-3.5-Turbo könnte ebenfalls ein MoE sein

• Es gibt Gerüchte, dass 3.5-turbo dieselbe Architektur wie GPT-4 teilt, aber mit deutlich weniger Parametern
• Dass derzeit 70B Parameter nötig wären, um die Leistung von Turbo zu erreichen, lässt sich angesichts der von OpenAI verarbeiteten Traffic-Menge und Geschwindigkeit schwer mit einem einzelnen dichten Modell erklären
• Turbo ist in der API das einzige andere Modell, bei dem logprobs nicht öffentlich verfügbar sind
  • Die bisherige Erklärung war, damit die Genauigkeit von Distillation nicht steigt, doch Beispiele wie Orca machen diese Begründung weniger überzeugend
  • Dass OpenAI öffentlich angekündigt hat, an der Integration von logprobs in ChatCompletions zu arbeiten, spricht eher für die Interpretation „technisch schwer stabil zu realisieren, weil das Modell inhärent zu zufällig ist“ als für „Schutz vor Distillation“

Fazit

• Dass OpenAI-GPT-Modelle bei temperature=0 nichtdeterministisch sind, ist allgemein bekannt
• Als übliche Ursache wird die Ungenauigkeit optimierter CUDA-Gleitkommaberechnungen genannt
• Die hier vorgestellte alternative Hypothese lautet: Batched inference in Sparse-MoE-Modellen ist die grundlegende Ursache der Nichtdeterministik der GPT-4-API und erklärt das Phänomen sauberer als die bisherige Deutung
• Es wird empirisch gezeigt, dass API-Aufrufe von GPT-4 (und einigen 3.5-Modellen) deutlich nichtdeterministischer sind als bei anderen OpenAI-Modellen
• Aus Geschwindigkeit, Nichtdeterministik und dem Entfernen von logprobs wird abgeleitet, dass GPT-3.5-turbo ebenfalls ein MoE sein könnte

[GN⁺]

Hacker-News-Meinungen

• Gleitkommafehler sind normalerweise deterministisch: Wenn man dieselbe Berechnung zweimal ausführt, sollte bis auf Bitebene dasselbe Ergebnis herauskommen.
  Dass Ergebnisse auseinanderlaufen, passiert nur, wenn es andere Zustände oder Entropiequellen gibt, etwa wenn Puffer nicht korrekt mit Nullen initialisiert werden, Race Conditions vorliegen oder Rundungsmodus-Flags nicht konsistent gesetzt werden.
  Wenn man sich die Qualität des im AI/ML-Ökosystem hastig zusammengezimmerten Codes ansieht, würde ich vermuten, dass alle drei Dinge passieren – vielleicht sogar noch mehr.

  • Auf GPUs ist das nicht so: https://www.twosigma.com/articles/a-workaround-for-non-deter...
    In diesem Fall ist wegen der GPU-Parallelität die Reihenfolge, in der Zahlen addiert werden, nichtdeterministisch, und das Ergebnis kann sich leicht unterscheiden.
    Man sollte es eher vermeiden, den Code anderer schlechtzureden, wenn er auf Systemen geschrieben wurde, die man nicht gut versteht.
    Bei CPUs kann durch Parallelverarbeitung zwar dasselbe passieren, aber die meisten einzelnen CPU-Instruktionen sind deterministisch, während CUDA nichtdeterministische Grundoperationen bereitstellt.
    Das ist beabsichtigtes Design, weil sie schneller sind als ihre deterministischen Gegenstücke; problematisch ist, dass es so dargestellt wurde, als sei es ein durch schlechten Code verursachter Bug.
  • Sobald Parallelität ins Spiel kommt, kann diese Aussage nicht mehr gelten.
    Beispielsweise gilt bei einigen Gleitkommaoperationen wie Addition oder Multiplikation das Assoziativgesetz nicht, sodass das Ergebnis davon abhängt, in welcher Ausführungsreihenfolge eine Reduction abgeschlossen wird.
    In parallelen Situationen gibt es Implementierungen, die die Reihenfolge der Reduction aus Performance-Gründen nichtdeterministisch machen, und dadurch wird auch das Endergebnis nichtdeterministisch.
  • Mathematisch ist die Berechnung deterministisch, aber das physische Gerät, das die tatsächliche Berechnung ausführt, kann Software-Ergebnisse auf verschiedene Weise zu einer Funktion der Zeit machen.
    Schon ein Aufruf von GetTimeOfDay() reicht dafür aus, ebenso kann Clock-Frequency-Drift zwischen mehreren Prozessoren dazu führen.
  • Ich frage mich, ob eine n-stufige Simulation von Alhazens kreisförmigem Billardproblem bei mehreren Ausführungen dasselbe Ergebnis liefert.
    https://forumgeom.fau.edu/FG2012volume12/FG201216.pdf
  • In großem Maßstab reicht schon das Fehlen von gutem ECC-Speicher, um Entropie zu erzeugen.

• Ich bin mir nicht sicher, ob ich den Auszug aus dem referenzierten Paper richtig verstanden habe.
  Bedeutet das, dass ein Teil der effizienteren Inferenz davon abhängt, Tokens aus völlig anderen Eingaben beizumischen, etwa aus Eingaben anderer Nutzer? Und dass je nach den anderen Eingaben, die zufällig im selben Bündel landen, die Zuteilungsquote der „Experten“ anders ausfällt und damit auch die finale Vervollständigung?
  Wenn ja, würde das nicht nur Nichtdeterminismus einführen, sondern die Antwortqualität könnte auch von der Zahl gleichzeitiger Anfragen abhängen, die um dieselbe Expertenzuweisung konkurrieren.
  Zum Beispiel könnte der Teil des Systems, der Hindi gut übersetzt/interpretiert, zu indischen Stoßzeiten schlechtere Ergebnisse liefern, weil dann viele Eingaben gleichzeitig um dieselbe Fähigkeit konkurrieren.
  Das könnte eine weitere Erklärung dafür sein, warum man mit der Zeit einen Qualitätsabfall wahrnimmt. Früher bestand ein bestimmter Test zuverlässig, weil die relevanten Experten wenig ausgelastet waren; heute gibt es mehr gleichzeitige Nutzung, sodass derselbe Test nicht mehr genug Leistung dieses Experten erhält.
  Wenn ein bestimmter Sub-Experte in einem Bereich anfangs beeindruckend gut ist, kann außerdem mehr Nutzung genau in diesen Bereich strömen; durch die neue Überlastung erhalten Nachahmer-Nutzungen dann nicht mehr dieselbe Expertenzuweisung, wodurch die anfangs beeindruckende Leistung in diesem Sumpf abfällt.
  Wenn der Effekt stark ist und OpenAI davon wusste, ohne es offenzulegen, könnte man es als eine Art Lockangebot ansehen: Nutzer werden zunächst mit der nicht repräsentativen Spitzenleistung eines nicht überlasteten Mixture-of-Experts-Systems angelockt und erhalten später die qualitativ schlechteren Ergebnisse eines stärker überlasteten Systems.

  • Das Ergebnis scheint im Kern 12 eindeutige Antworten in 30 Versuchen zu zeigen; das wäre nicht das zu erwartende Ergebnis, wenn Tokens gemischt würden.
    Wahrscheinlich werden die Batches unterschiedlich gruppiert. Wenn man 10 Batches in 2 Gruppen zu je 5 aufteilt, hängt die Antwort davon ab, ob mein Prompt in der ersten oder zweiten Gruppe landet; befindet er sich an derselben Position innerhalb des Batches, bekommt man dieselbe Antwort.
    Bei demselben Batch, also gleicher Sequenz und Reihenfolge, ist der gesamte Batch deterministisch; mischt man die Batches, geht diese Determiniertheit verloren.
  • Das ist ein plausibles Ergebnis, und falls es stimmt, könnten OpenAI-Modelle gegenüber Konkurrenzmodellen oder Open-Source-Modellen stark ins Hintertreffen geraten.
    Schon jetzt ist Zuverlässigkeit eines der zentralen Hindernisse für eine breite Einführung von LLMs in vielen geschäftskritischen Workflows.
    Wenn die Gerüchte stimmen, dass GPT-4 im Kern nichtdeterministisch und instabil ist, sind die meisten Unternehmen besser damit bedient, ein Open-Source-LLM mit ähnlicher Leistung für eine bestimmte Domain feinzujustieren.
    Domainspezifische Modelle liefern immer eine bessere Leistung als Allzweckmodelle, also ist auch der Performance-Gewinn dort größer.

• Wenn GPT-3.5 ein MoE-Modell ist, ist das nicht ein ziemlich hoffnungsvolles Signal für die Open-Source-Szene?
  Wenn ein gutes Open-Source-MoE-Modell erscheint, vielleicht in Form einer Variante bestehender Decoder-Modelle, hieße das, dass man mit deutlich weniger Ressourcen deutlich mehr leisten kann.
  Ich weiß nicht, ob man ein MoE-Modell von Grund auf trainieren muss.

  • Zustimmung, und ich hoffe wirklich, dass Meta in diese Richtung etwas macht.
    Ansätze, die das FLOPs:Speicher-Verhältnis senken, etwa Soft MoE, könnten Inferenz auch auf CPUs oder zumindest auf Apple Silicon deutlich sinnvoller machen.
  • Für eine Inferenzumgebung auf einer einzelnen Consumer-GPU könnte das schlecht sein.

• Wenn Sequenzen innerhalb eines Batches das Routing der jeweils anderen beeinflussen können, fühlt sich das nach der Möglichkeit eines seltsamen und schwer umzusetzenden Seitenkanalangriffs an.

  • Scheint so. Allerdings dürfte es in der Praxis sehr schwer auszunutzen sein.

• Wirklich hervorragende Arbeit. Ich war aus mehreren Gründen stark gegen MoE eingestellt, aber das ist das erste Mal, dass ich überzeugende Belege sehe, statt Substack-Artikeln oder wiederholten Gerüchten
  Mir war überhaupt nicht bewusst, dass GPT-4 nichtdeterministisch ist, obwohl ich es etwa 2 Stunden am Tag nutze
  Ich verstehe, warum das bei oberflächlicher Betrachtung schwer zu bemerken ist. In der Erinnerung fühlt es sich ähnlich an und verwendet viele ähnliche Wörter, aber die Form ist völlig anders, während einige Schlüsselwörter gleich bleiben und andere wie Synonymphrasen ausgetauscht werden

  • Ich bin kein MoE-Forschungsexperte, aber nach dem, was im Soft-MoE-Paper steht, hatte ich das Gefühl, dass man das überprüfen sollte
    Wenn man sich das verlinkte Gist-Beispiel ansieht, sind die nichtdeterministischen Ausgaben wirklich ähnlich: https://gist.github.com/152334H/047827ad3740627f4d37826c867a...
    Da die Zufälligkeit begrenzt sein muss, ist dieser Teil zumindest nicht überraschend
    Ich glaube, OpenAI wird irgendwann einen Weg finden, diese Zufälligkeit zu reduzieren. Umso plausibler ist das, weil es auch die öffentliche Zusage gibt, logprobs wieder zu ChatCompletions hinzuzufügen
  • Wenn du den GPT-4-Webchat zwei Stunden am Tag nutzt, kann das sein
    Wenn man dagegen per API wiederholt mit derselben Eingabe Aufrufe macht, um ein Programm zu entwickeln, ist die Nichtdeterministik schwer zu übersehen
  • Mich würde interessieren, warum du MoE so stark abgelehnt hast
  • Mich würde interessieren, wofür du es nutzt. Auch, ob du viele Plugins verwendest
    Ich wäre gespannt, welche Einsichten jemand, der es so intensiv nutzt, auch im Hinblick auf das Funktionspaket gewonnen hat, das diese Woche erschienen ist

• MoE steht für Mixture of Experts, also eine Mischung von Experten

  • Danke. Ich dachte, es hieße Margin of Error
    Erst etwa in der Mitte des Artikels wird die Abkürzung fast beiläufig ausgeschrieben; die anvisierte Leserschaft scheint mit Mixture of Experts gemeint gewesen zu sein, und ich gehörte nicht dazu

• Die davinci-instruct-beta-Modelle von GPT-3.0 gaben schon seit Anfang 2021 nichtdeterministische logprobs zurück
  Das ist Spekulation, und CUDA selbst hat auch häufig Nichtdeterminismus-Bugs
  text-davinci-001 und text-davinci-002 wurden mit FeedMe und SFT trainiert, text-davinci-003 mit RLHF
  Auch das Modell selbst hat bei hoher Temperatur eine größere Varianz

  • Wie sieht es mit den Basismodellen aus, also davinci und code-davinci-002?

• Wenn „diese Tokens oft miteinander um die verfügbaren Plätze im Expertenpuffer konkurrieren“, ist das dann auch der Grund, warum ChatGPT, wenn ich langen Code anfordere, anstelle von Funktionen häufig nur Platzhalter einsetzt?

• „Diese Tokens konkurrieren oft miteinander um die verfügbaren Plätze im Expertenpuffer“ – heißt das, dass sich die Ergebnisse bei hoher Last ändern?
  Lässt sich das Gefühl, dass die Ausgabequalität manchmal schwankt, ebenfalls durch hohe Last erklären?

• MoE steht für Mixture of Experts