Align DeepSeek and GLM execution with DS4

docs/inference-reference-parity-audit-20260905.md

@@ -7931,6 +7931,19 @@ Verifikation 2026-09-05, ohne GPU-Modelllauf oder breite Gates:
 - `git diff --check`: bestanden. Keine Durchsatzverbesserung aus diesen Tests
   abgeleitet. Vor der neuen DSpark-Messung bleiben P02/P03/P04 maßgeblich.
 
+**Gemeinsamer DS4/GLM-Sampler angeglichen (11.09.):** Der CPU-only-Replay mit
+32 echten GLM-Logit-Zeilen und512 gemessenen Auswahlen zeigte2,645ms pro Schritt
+in Rust gegenüber0,834ms über die originale öffentliche DS4-Funktion. Die Rust-
+Implementierung benutzt nun den begrenzten512-Kandidaten-Heap, originale Logit-
+Tie-Reihenfolge, rohe CDF-Summen und DS4-Fallbacks statt vollständiger Sortierung
+mit erneuter Normalisierung. Initial0,401ms/Schritt bei identischen512 Tokens;
+64 Original-Fixturefälle und17 Sampling-Tests bestanden. Qwens MTPLX-Sampler und
+die separate Verteilungsberechnung für spekulative Korrektur bleiben unverändert.
+Ein kompletter GLM-AR-Chat bewahrt Ausgabe/Thinking/Frontiers und zeigt im einzelnen
+Vorher-/Nachher-Paar5,3–6,6% höheren Decode-Durchsatz. Das ersetzt weder die
+DSpark-Modusabnahme noch die wiederholte Gesamtmatrix. Details im
+[GLM follow-up](glm-scheduling-followup-20260911.md).
+
 ### P14 — GLM-MTP tatsächlich batchen wie DS4
 
 **Produktpfad umgesetzt, Referenz-Performanceabnahme offen (10.09.):**
@@ -7996,6 +8009,61 @@ Priorität P1; nach P04, P13; Quellcodedifferenz belegt.
 
 ### P15 — DS/GLM-Scheduling, Kaltstart und gemeinsame Runtime abgleichen
 
+**Numerische GLM-Abweichung reproduziert (Fortsetzung11.09.):**
+64 modellfreie Original-DS4-Sampler-Fälle sichern Tokens und RNG-Zustand ab;
+Greedy-Tie/RNG- und Seed0-Abweichungen sind korrigiert, ohne Qwen zu ändern.
+Die verwendeten positiven Seed42-Benchmarkfälle waren davon nicht betroffen.
+Der neue feste-Historie-Test auf32 echten Original-DS4-Logit-Zeilen trennt die
+Ursachen: Rust-Sampling derselben Zeilen liefert32/32 identische Tokens; Rust-
+GPU-Ausführung derselben Eingaben liefert bereits nach Prefill max5,722/RMS0,851
+Logit-Abweichung und bei Schritt17 ein anderes Sample. Der Test bleibt bewusst
+rot und ignoriert für normale modellfreie Läufe. Die Referenz selbst bewahrt
+den vollständigen AR-Chat exakt trotz optionalem Trace. Nächste Priorität ist
+die erste divergierende HC/KDA/DSA/FFN-Stufe, nicht das Durchsatzetikett auf
+auseinanderlaufenden Chathistorien. Belege/Kommandos und Grenzen stehen im
+[GLM follow-up](glm-scheduling-followup-20260911.md).
+
+**Fortsetzung 11.09.:** Der Benutzer bestätigt jetzt normalen GLM-Decode und
+benutzbaren, aber gegenüber Qwen weniger geschmeidigen Prefill. Kein vollständiger
+Freeze behauptet. Die unten am10.09. identifizierte residente skalare Flush-
+Abweichung ist in beiden GLM-Schleifen korrigiert (periodisch alle4, ohne letzten
+Layer/SSD-Streaming); Prefill-Fortschritt meldet nur abgeschlossene bestehende
+Drains und den Batchabschluss. Frische vollständige AR/MTP-Vorher-/Nachher-Chats
+bewahren Tokens/Text/Thinking/EOS ohne beobachtete harte Regression; einzelne
+Laufpaare sind kein kontrollierter Speedup-Beweis. Der ausdrücklich genehmigte
+Standalone-DS4-Benchmark benutzt originale DS4-Objekte ausschließlich außerhalb
+des Produkts und reproduziert Low, separaten Bootstrap und laufende Chathistorie.
+Die separate Canary-Prozessplatzierung war kein fairer Vergleich zum internen
+Canary: gleichzeitig intern490,740ms versus extern höchstens3,331ms. Neue native
+Metal-Zeitstempel lokalisieren eine300ms-Prefill-Probe fast vollständig vor dem
+GPU-Start, nicht in der Host-Rückmeldung. Dieselbe Probe innerhalb des originalen
+DS4-Prozesses reproduziert264,292ms Prefill-Spitze, ebenfalls vor dem GPU-Start;
+771/771 Datensätze sind nach Korrektur der Watchdog-Ausgabeweiterleitung sauber
+auswertbar. Die restliche Kosten-/Latenzdifferenz und weitere Abnahme bleiben in
+[GLM follow-up](glm-scheduling-followup-20260911.md). P15 bleibt offen.
+
+**GLM-Ausführungsursache lokalisiert (11.09.):** Rust übernahm die GLM-5.2-
+Top-k-Chunkgrenze für GLM5.3: nach9 Bootstrap-Tokens2039 statt der originalen2048
+Tokens. Nun bleiben GLM5.3-Chunks wie im aktiven DS4-Pfad vollständig; nur die
+Attention-Slices werden an der Dense/Sparse-Grenze geteilt, auch für kreuzende
+Verifier-Paare. Im unverändert vorgegebenen32-Schritt-Replay sind danach alle
+Logit-Vektoren bitidentisch zur Originalreferenz, vorher lagen deutliche Fehler
+bereits im ersten Vektor vor. Vollständige AR/MTP-Chats, Grenzfall-Livetest und
+Performance-Neumessung bleiben erforderlich; dies allein schließt P15 nicht.
+
+**Nachprüfung desselben Tages:** Der vollständige AR-Chat stimmt nun in allen
+drei Antworten samt Thinking, Tokenzahlen und Prompt-/Cache-Grenzen überein.
+Bei MTP wurde zusätzlich ein im gemeinsamen UI-/Harness-Consumer behaltenes
+Stop-Token gefunden: der zweite Prompt hatte3249 statt3248 Tokens. Der Consumer
+nutzt nun GLMs vorhandenen Zwei-Zeilen-Rollback, analog zur Stop-Behandlung des
+originalen DS4-Agenten. Danach stimmt auch der vollständige MTP-Chat in allen
+drei Antworten und Grenzen überein (593/872/167 ausgegebene Tokens). Der
+Attention-Grenzfall4095+2 wurde live geprüft. Der strikte32-Logit-Replay und die
+großen Layer0-Tensorvergleiche sind bitidentisch. Einzelne neue Geschwindigkeits-
+paare und diese konkrete Workload schließen nicht die gesamte2%-Matrix oder
+alle Interaktionsfälle ab; P15 bleibt offen. Ergebnisse und Einschränkungen im
+[GLM follow-up](glm-scheduling-followup-20260911.md).
+
 **Aktiver GLM-Pfad und durchgehender Canary geprüft (10.09.):**
 `local-eval-results/glm-scheduling-canary-20260910.T1ABR1/{manifest.md,comparison.json}`
 enthält zwei vollständige AR/MTP-Chats bis EOS bei Power100/Low und Canary an.
@@ -8061,6 +8129,61 @@ Priorität P1; nach P01, P04, P13; Source-Inventar vorhanden, Detailbeweis offen
 
 Priorität P1; nach den relevanten P01–P15; offen.
 
+**Original-DS4-Vergleich erweitert (11.09.):** GLM-AR/MTP bewahren nach dem
+CPU-Sampler-Abgleich in je zwei vollständigen Paaren Ausgabe/Thinking/Frontiers.
+Die umgekehrte Reihenfolge zeigt dennoch AR-Decode-Rückstände bis15,23% und
+MTP-Summary-Prefill bis4,38%; auch die Originalreferenz schwankt stark. Kein
+Median-Pass, keine thermische Erklärung ohne Taktbeleg. Details und unveränderte
+Command-Buffer-Zahlen im [GLM follow-up](glm-scheduling-followup-20260911.md).
+
+Der erste DeepSeek-Vergleich ist ausdrücklich ungültig: Der Referenztreiber
+forderte2048 statt des UI-/DS4-Automatikwerts4096 an. Zusätzlich fügte der
+gemeinsame Produkt-Renderer bei einem reinen Bootstrap-Cache fälschlich EOS vor
+dem ersten User-Prompt ein (2742 statt2741 Tokens). Der Tokenizer selbst stimmt.
+Ein gezielter CPU-Test reproduziert diesen UI-/Headless-Fehler vor der Korrektur;
+nach dem Nichtleer-History-Guard bestehen DeepSeek- und GLM-Originalfixtures.
+Referenztreiber auf Automatik angeglichen, keine Produkt-Chunkverkleinerung.
+Das korrigierte vollständige DeepSeek-AR-Paar stimmt nun in allen Antworten,
+Thinking-, Token- und Cache-Feldern überein, verfehlt aber im Einzelpaar noch
+das Durchsatzziel. Das neue DSpark-Paar scheitert funktional: erste Antwort
+bereits647 statt1208 Tokens bei identischem Prompt; anschließend jeweils ein
+zusätzlich behaltenes EOS im Rust-Cache. Die normale Beendigung und bestandene
+Python-Tests ändern diesen roten Vergleich nicht. Nächste zusammenhängende
+DSpark-Einheit: erster divergenter Proposal-/Verify-Zyklus, Stop-/Capture-Frontier
+und zusätzliche Vollvokabular-Readbacks gemeinsam gegen Original DS4 prüfen
+und angleichen, dann neu messen. Konkrete Quellen, Rohdaten und Tests im
+[DeepSeek follow-up](deepseek-reference-followup-20260911.md).
+
+**DSpark-Zyklus-/Zustandsabgleich fortgesetzt:** Der neue vollständige
+Diagnoselauf stimmt jetzt in allen1755 Originalzyklen einschließlich Warmup,
+Antworten, Thinking und Cachepositionen überein. Ursachen waren fehlende
+HC-/Attention-Norm beim Support-KV-Aufbau, der abweichende Einzeldraft-Verifier,
+Seed-/Teilannahme-Capture, Cachefenster-/Scheduler-/EOS-Übergänge und fehlende
+Aktivierungsquantisierung des tatsächlich installierten Q8-Confidence-Kopfs.
+Zusammenhängende Quellen-/Taskliste und Rot→Grün-Belege stehen im verlinkten
+Follow-up. Early-Confidence-Gate und Verifier-Readbacks/Submission sind inzwischen
+ebenfalls angeglichen; alle1755 Originalzyklen bleiben exakt gleich. Noch keine
+Leistungsabnahme: saubere Wiederholungspaare zeigen starke zeitliche Drift in
+beiden Implementierungen. Die CPU-Worker-Policy ist ebenfalls angeglichen:
+dauerhafte12 Threads inklusive Aufrufer, weiterhin1755 identische Zyklen.
+Ein CPU-only-Dispatchvergleich zeigt einen kleinen Gewinn, keine Erklärung für
+den verbleibenden Gesamtgap. Verifier-/Frontier-Puffer werden inzwischen über
+Zyklen wiederverwendet; der32-Zyklen-Test prüft Pufferidentität und bytegenaue
+Rücknahme, der vollständige Chat weiterhin alle1755 Originalzyklen. Auch der
+Exact-Sampling-Test besteht. Die jüngsten beiden Paare verfehlen jedoch weiter
+Teile des Durchsatzziels; kein belegter Gesamtgewinn durch diese Änderung.
+
+**Messbedingung nach Nutzerklarstellung (11.09.):** Parallel laufen Videos und
+beanspruchen einen Teil der GPU. Die genaue zeitliche Überlappung früherer
+Messungen ist unbekannt. Die jüngsten seriellen Paare bleiben als Rohdaten
+erhalten, gelten aber nicht als kontrollierte2%-Abnahme oder kausaler
+Vorher/Nachher-Beleg. Weder alle Differenzen auf Videos schieben noch thermische
+Drosselung behaupten. Keine weiteren Durchsatzserien während dieser Nutzung;
+Funktionsprüfungen und Code-Abgleich bleiben möglich. Die vollständige
+Sechsfeldmatrix, Responsivitätsabnahme und Zähler-Scope-Bereinigung bleiben offen.
+Der Nutzer hat den Abschluss und Commit/Push dieses Zwischenstands freigegeben;
+die vorgeschriebenen Commit-Gates umfassen auch den erneuten Bundle-Bau.
+
 **Aktuelles interaktives Test-Bundle bereitgestellt (10.09.,22:32):**
 `make bundle` und strikte Codesign-Prüfung bestanden. Das Bundle enthält den
 zuletzt vermessenen Release-Code und identische Metal-Ressourcen; der genaue