Benchmark · KI-Tooling · Werkstattbericht

DS4 auf DRACO: von 42,64 auf 52,36 %

Tom Jansen · 10.07.2026 · 25 Min. Lesezeit

Nach dem Juni-Lauf sah es zuerst so aus, als läge das lokale DS4 deutlich hinter GPT-5.5. Unter demselben strengen Judge blieben davon aber nur 1,19 Prozentpunkte übrig: 48,18 gegen 49,37 %, allerdings mit einem Judge-Lauf bei DS4 und drei bei GPT-5.5. Damit war für mich die Frage nicht mehr, ob das Modell genug weiß. Ich wollte wissen, wo der Harness die Punkte verliert.

Die Antwort war ziemlich konkret: Ein Tool-Aufruf kippte einmal 15,7 MB in den Kontext. Der KV-Cache kam auf 3.102 Verdrängungen bei nur 76 Treffern. Die höchste Denkstufe war gar nicht erreichbar. Und das Zeitlimit produzierte leere Antworten, obwohl im Sitzungsprotokoll teilweise schon ein brauchbarer Bericht lag.

In den folgenden drei Wochen habe ich diese Stellen repariert und in kontrollierten Läufen gemessen. Der neue Stack lag auf denselben 20 Aufgaben rund 6,8 pp über dem Juni-Wert. Wegen der anderen Pi-Version, der Harness-Änderungen und einem statt drei Judge-Läufen ist das ein Vorher/Nachher-Wert, keine isolierte Kausalwirkung. Die kombinierte Konfiguration aus präziserem Quant und höherem Cap lag weitere 2,9 pp darüber. Insgesamt stieg DS4 auf dem bewusst harten Subset von 42,64 auf 52,36 %.

Das ist kein offizieller DRACO-Wert und kein Vergleich mit dem OpenRouter-Leaderboard. Es ist ein interner Mess-Harness, mit dem ich meine eigenen Konfigurationen vergleichen kann. Alle direkten Vergleiche unten nutzen denselben strengen Judge (Pi openai-codex/gpt-5.5:xhigh, criterion-Modus). Wo sich die Zahl der Judge-Läufe oder der Harness unterscheiden, schreibe ich es dazu.

Wie ich die Zahlen vergleiche

Einige Zahlen sehen ähnlich aus, dürfen aber nicht gegeneinander gerechnet werden. Für die Tabellen gelten deshalb diese Regeln:

• Score: DRACO bewertet jede Antwort gegen eine versteckte Rubrik, im Schnitt mit 39,34 binären Kriterien pro Aufgabe und positiven wie negativen Gewichten. Der Judge entscheidet je Kriterium MET oder UNMET; das Ergebnis wird auf 0 bis 100 % normalisiert. Eine leere Antwort bekommt exakt 0 %.
• Judge: Dieselben GPT-5.5-Antworten erreichen 61,77 % mit gpt-4.1-mini und 49,37 % mit dem strengen GPT-5.5-Judge. Nur der Judge wurde ausgetauscht. Absolute Werte über diese Grenze hinweg vergleiche ich nicht. Die Juli-Arme liefen mit dem strengen Judge im criterion-Modus und drei Judge-Läufen. Die DS4-Zahlen aus dem Juni haben nur einen Lauf und sind entsprechend markiert.
• 20-Aufgaben-Subset: Ich habe es am 2.7. eingefroren: 6 pathologische Aufgaben aus den Juni-Totalausfällen, 4 aus schwachen Domänen, 4 aus starken und 6 aus dem Mittelfeld. Es ist absichtlich härter als der 100er-Schnitt. Ein Subset-Wert ist deshalb nicht mit einem 100-Aufgaben-Wert vergleichbar.
• Cap: Das ist das harte Zeitlimit pro Aufgabe: im Juni 7.200 s, ab 2.7. 2.100 s und ab 8.7. 2.500 s. Läuft eine Aufgabe hinein, bricht der Runner ab und versucht Salvage.
• Salvage: Der Runner sucht zuerst den letzten brauchbaren Bericht im Sitzungsprotokoll. Wenn dort nichts liegt, setzt er die Session einmal mit einer erzwungenen Finalisierung fort. Ein geretteter Bericht zählt als Antwort. Schlägt auch das fehl, bleiben 0 %.
• Bench-Zahlen: Prefill und Decode in t/s stammen aus ds4-bench mit identischem Prompt und identischen Parametern. Seit dem 6.7. zählen für mich nur noch verschränkt gemessene Arme, also abwechselnde Läufe im gleichen Messfenster und mit möglichst ähnlichem Warmzustand.

Im Juni war der Judge größer als der Modellabstand

Bevor ich am Stack weitergebaut habe, musste ich die Juni-Zahlen erst richtig sortieren:

Die beiden GPT-5.5-Balken zeigen das eigentliche Problem: dieselben Antworten, 12,4 pp Unterschied, nur weil der Judge wechselt. Mit dem gleichen strengen Judge lag DS4-256k nach dem Empty-Retry noch 1,19 pp hinter GPT-5.5 direkt und gewann 52 von 100 Aufgaben im direkten Vergleich. Der Vergleich ist wegen eines Judge-Laufs bei DS4 gegen drei bei GPT-5.5 nicht perfekt, aber er war gut genug für die nächste Entscheidung: Der größte sichtbare Verlust lag nicht im Modellwissen. Er lag in 12 leeren Antworten, Tool-Schleifen und Kontextüberläufen.

Am 2. Juli habe ich den Lauf auseinandergenommen

Ich habe Server, Adapter, Ergebnisse, Fusion und Harness parallel von acht Agenten untersuchen lassen: fünf lasen Code und Laufartefakte, zwei prüften die Dokumentation und einer führte die Befunde zusammen. Daraus kam diese Fehlerliste, sortiert nach den wahrscheinlich verlorenen Punkten:

Ein zweiter Befund kam direkt von der Hardware. Beim Decode liest dieses Quant ungefähr 10,4 GB pro Token, davon rund 83 % aus den Q8-Nicht-Experten-Gewichten. Bei etwa 546 GB/s Speicherbandbreite liegt die theoretische Obergrenze um 52 t/s; frisch gemessen waren 37 t/s. Kleinere Experten-Quants ändern daran kaum etwas. Spekulatives Decoding blieb damit als ein plausibler Weg übrig, mehr als diese 37 t/s zu erreichen.

Ich habe am selben Tag zuerst die Stellen repariert, die Antworten direkt zerstörten: Tool-Ausgaben wurden bei 30k Zeichen gedeckelt und bekamen Paging, das KV-Budget stieg von 8 auf 64 GB und Think Max wurde überhaupt erst erreichbar. Der Trimmer arbeitet seitdem klebrig: Einmal gekürzte Nachrichten bleiben byte-identisch, damit der KV-Prefix erhalten bleibt.

Im Runner kamen Salvage, ein Cap von 2.100 s und ein eigenes Timeout für Fusion-Kinder dazu. Der Systemprompt verlangt klare Struktur, rohe https-URLs, Primärquellen, ein begrenztes Tool-Budget und eine echte Finalisierung. Außerdem blockiert der Harness die Rubrik-Domains. Und dann musste ich noch den Juni-Overflow-Patch wiederherstellen, den das Pi-Update von 0.79.4 auf 0.80.2 still gelöscht hatte. Alle Änderungen stehen mit Datum im Repo.

Steering: Meine Hypothese ließ sich nicht bestätigen

Aus der Rubrik-Analyse hatte ich abgeleitet, dass die „Hedging“-Richtung des Steering-Vektors auf der Faktenachse 2 bis 8 pp kosten könnte. Also habe ich genau diese eine Variable getestet: uncertainty_ablit_imatrix mit ffn = −0,75, dem Default, gegen ffn = 0.

Beide Arme bekamen dieselben 20 Aufgaben, denselben Stack und denselben strengen Judge mit drei Läufen. Zwischen den Armen wurde der Server neu gestartet. Vorher hatte ich festgelegt, dass |Δ| < 2 pp als kein Effekt zählt.

Mit Steering erreichte DS4 49,44 %, ohne Steering 47,98 %. Das sind gepaart +1,46 pp bei einer Streuung von 18,41 und 12 von 20 Siegen. Für die vorhergesagten Hedging-Kosten gab es in diesem Test keinen messbaren Beleg.

Die Laufzeit erklärt den kleinen Unterschied nicht: Beide Arme verhalten sich mit 10,0 gegen 10,5 Stunden Wall-Zeit und 11 gegen 14 Aufgaben am Cap ähnlich. Die großen Ausreißer sind dagegen klar: je ein Salvage-Totalausfall pro Arm. Ohne diese beiden Aufgaben bleiben +1,99 pp, also weiterhin Rauschen.

Ich lasse den Vektor an. Einen messbaren Netto-Schaden sehe ich nicht, und laut Adapter-Dokumentation schützt er die Tool-Grammatik. Wichtiger war etwas anderes: Ein einzelner Salvage-Fehlschlag kostet auf der betroffenen Aufgabe ungefähr 45 pp. Das war der nächste Hebel.

Das 91-GB-Quant brauchte ein anderes Zeitlimit

Am 3.7. veröffentlichte der pi-ds4-Upstream ein neues Standard-GGUF für Macs mit 128 GB RAM. Es nutzt dieselbe abliterierte Modelllinie, quantisiert aber die Routed Experts der Layer 37 bis 42 mit Q4_K statt mit 2 Bit. Damit bekommen sechs späte Expertenschichten mehr Präzision. Das Modell wächst von 87 auf 91 GB und decodiert ungefähr 15 % langsamer. Ich wollte wissen, ob die zusätzliche Präzision diesen Verlust wert ist.

Für den ersten Lauf hielt ich Subset, Stack, Judge und das Cap von 2.100 s konstant. Das ist ein fairer Vergleich der beiden Konfigurationen unter demselben Zeitbudget, aber kein reiner Qualitätstest: Das langsamere Modell kann vor dem gleichen Wall-Time-Limit weniger Tokens erzeugen. Diesen Confound habe ich während des Laufs notiert, bevor die Scores da waren. Meine Entscheidungsregel war ebenfalls vorher klar: Verliert das 91-GB-Quant hauptsächlich auf Aufgaben am Cap, erhöhe ich das Cap, statt das Quant zu verwerfen.

Der Rohwert lag zunächst bei 48,70 % und damit 0,74 pp unter dem 87-GB-Modell. Auf den 17 Aufgaben, in denen beide Arme eine Antwort produzierten, lag das 91-GB-Quant aber 4,41 pp vorn. Auf den fünf Aufgaben ganz ohne Cap-Kontakt waren es 6,94 pp. Zwei Finance-Aufgaben liefen leer ins Cap und danach auch mit der Salvage-Fortsetzung ins Limit. Sie bekamen 0,0 %, wo das 87-GB-Modell 35,7 und 53,9 % erreicht hatte. Gegenüber diesen beiden 87-GB-Scores entstand dadurch ein Defizit von 4,48 pp im Gesamtmittel.

Daraufhin habe ich das Cap von 2.100 auf 2.500 s und das Salvage-Limit von 1.800 auf 2.400 s angehoben. Der Lauf vom 8./9.7. vergleicht deshalb zwei vollständige Betriebskonfigurationen, nicht nur zwei Quants:

Diese kombinierte Konfiguration erreichte 52,36 gegen 49,44 %, also +2,92 pp, und lag bei 13 von 20 Aufgaben vorn. Die beiden zusätzlichen Nullen aus dem ersten 91-GB-Lauf verschwanden mit den höheren Limits: 342b15b8 stieg von 0,0 auf 45,2 % und 72e81ce6 von 0,0 auf 52,5 %. Damit waren diese Nullen klar Cap-/Salvage-Artefakte des ersten Laufs. Wie das 91-GB-Modell mit ausreichend Zeit abgeschnitten hätte, lässt sich im Nachhinein aber nicht beobachten. Deshalb kann ich den Anteil des Quants am Endgewinn nicht isolieren.

Mit n = 20 und einer Streuung von 18,9 ist das außerdem kein Beweis auf Aufgabenebene. Neben großen Gewinnen in Finance, General Knowledge und Law gibt es drei Aufgaben, die über beide 91-GB-Läufe hinweg fallen: b8ff32b6 in Medizin von 76,6 über 50,3 auf 25,1 %, 4b089235 in Shopping von 78,4 über 52,5 auf 48,4 % und 78bfa372 ebenfalls in Shopping von 43,7 über 36,9 auf 33,7 %. 10e75d21 blieb in allen drei Läufen bei 0,0. Trotzdem ist die Entscheidung für den Betrieb klar genug: Seit dem 9.7. läuft das 91-GB-Modell mit Cap 2.500 als Standardkonfiguration.

Wie stark das Cap in diese Läufe eingreift, zeigt die Salvage-Übersicht:

Beim Speed-Benchmark driftete die Maschine

Am 6.7. habe ich zuerst die drei Metal-Modi auf dem alten Server-Pin vermessen. Für den MPP-Fastpath waren auf anderer Hardware 6 bis 19 % mehr Prefill dokumentiert. In meinen drei noch nicht verschränkten Vormittagsläufen war er an jeder der acht Kontexttiefen langsamer. Wegen der später erkannten Messdrift ist das kein sauber isolierter A/B-Beweis.

Für den Betrieb habe ich den Modus nach diesem Ergebnis verworfen. Messen schlägt Dokumentation, aber ein sauberer kausaler Nachweis bräuchte hier einen verschränkten Re-Test. Beim anschließenden Server-Update hätte ich die nächste Messung dann fast falsch gelesen.

Der erste Vergleich nach dem Pin-Bump auf c1f4aa22 sah bei kurzen Kontexten wie eine Regression von 30 bis 48 % aus. Der Kontrolllauf mit dem alten Code am selben Abend zeigte aber dieselbe Drift: Im Mittel lag er 27,9 % unter seinem eigenen Vormittagslauf. Ich habe keine Temperatur- oder Leistungswerte aufgezeichnet, kann die Ursache also nicht als Thermik beweisen. Gemessen ist nur ein starker Reihenfolge- beziehungsweise Warmzustandseffekt nach mehreren langen GPU-Sweeps.

Verschränkt am selben Abend war der neue Pin im ersten Prefill-Lauf 9,6 % schneller als der alte, in der Wiederholung 0,7 % langsamer. Beim Decode waren es +13,7 und +0,7 %. Das widerlegt die scheinbare 30-bis-48-%-Regression, belegt aber keinen stabilen Speed-Gewinn. Seitdem verschränke ich Bench-Arme und vergleiche sie nicht mehr über mehrere Stunden hinweg.

Das alte KV-Default-Budget von 8 GB stammte aus einer Zeit vor Kontextfenstern mit 400k Tokens. Mein Befund von 3.102 Verdrängungen bei 76 Treffern ging als Issue an den Upstream. Am 7.7. wurde die Änderung „Raise KV disk cache default by RAM tier“ übernommen.

DSpark: Der Basis-Draft brachte keinen Speedup

Nach dem Bandbreitenbefund war spekulatives Decoding der plausibelste verbleibende Kandidat für mehr Decode-Speed. Im besten Fall hätte es auch die ungefähr 15 % Decode-Verlust des 91-GB-Quants zurückgeholt.

Nach dem Pin-Bump war die DSpark-Laufzeit im Server vorhanden und das verlustfreie B2-Rejection-Sampling lag im Engine-Code. Ich habe außerdem das Draft-GGUF aus dem Hugging-Face-Repo gebaut. Praktisch dabei: Alle 4.705 Draft-Tensoren lagen in den letzten 4 von 48 Shards. Damit musste ich ungefähr 16 GB statt 167 GB laden. Vor dem vollständigen Server-Patch blieb nur ein Ein-Zeilen-Gate.

Bevor ich dieses Gate patche und den Pin einfriere, habe ich die billigere Greedy-Probe gemacht: isolierter Server auf Port 8077, eigener Scratch-KV, Temperatur 0 und je ein Lauf mit demselben 500-Token-Prompt.

Der Draft lud korrekt (kind=dspark, runtime_mtp=yes), trotzdem fiel der Decode von 37,62 auf 36,37 t/s. Die Probe enthält keinen eigenen Acceptance-Zähler. Der fehlende Speedup und das beobachtete Fortschreiten um jeweils nur ein Token passen aber zu der naheliegenden Erklärung, dass fast keine Draft-Tokens akzeptiert wurden.

Die naheliegende Erklärung liegt in den Gewichten: Der Draft wurde aus der Basis-Variante von DeepSeek-V4-Flash konvertiert, während der Server das abliterierte Quant ausführt. Abliteration verschiebt genau die Ausgabeverteilung, die ein Draft vorhersagen muss. Die vorhandenen Artefakte liefern deshalb keine brauchbare Kombination. Ein passender Draft wäre ein eigenes Trainingsprojekt.

Damit war der Test für mich beendet, für weniger als einen Dollar Strom und bevor ich den Server gepatcht und den Pin eingefroren hätte. Die Skripte bleiben liegen, falls irgendwann ein Draft für die abliterierten Gewichte existiert.

Was mir die Messung unterwegs kaputtgemacht hat

Fast jeder größere Lauf hat noch eine neue Fehlerklasse gefunden. Das waren die wichtigsten:

1. 17.6.: Billiges Task-Batch-Judging überbewertete dieselbe Antwort um rund 24 pp (83,79 gegen 59,35 %). Seitdem ist der criterion-Modus Standard.
2. 23.6.: Pi erkannte DS4-Kontextüberläufe nicht als solche; dazu ein libmalloc-SIGTRAP nach Aufgabe 55. Patches mitten im Lauf.
3. 26.6.: Node/V8-OOM (Killed: 9) beendete den Retry-Lauf nach drei Aufgaben – der Orchestrator starb, nicht das Modell.
4. 28.6.: --no-extensions deaktiviert eingebaute Tools nicht: die Fusion-Reparatur recherchierte munter frisch per bash. Methodisch ungültig; Neustart mit --no-tools.
5. 2.7.: Pi-Update löschte still den Overflow-Patch. Antwort: Patch-System mit Selbstheilung und Preflight-Guard.
6. 2.7.: Die Regel „prüfe dich vor dem Abschluss“ im Systemprompt brachte das Modell dazu, mit einer Statusnotiz zu enden. Der Harness speicherte 486 Zeichen Kommentar statt des 24k-Berichts (Judge: 7,5 %). Zwei Fixes: Promptregel und Extraktions-Fallback.
7. 6.7.: pi-ds4 v0.4 setzte den Adapter-Checkout hart zurück – alle fünf lokalen Patches weg. Antwort: Patches leben jetzt als idempotenter Applier im eigenen Repo, nicht im fremden Arbeitsverzeichnis.
8. 6.7.: Der gleiche Code lag am Abend im paarweisen Mittel 27,9 % unter seinem Vormittagslauf. Ohne Sensorwerte bleibt die Ursache offen; die Messreihenfolge war damit als Vergleich unbrauchbar.
9. 6.-7.7.: Der Download wurde ohne Anmeldung auf 0,6 bis 3 MB/s gedrosselt und brach mehrfach mit EOF ab. Ein Quoting-Fehler machte aus dem Auth-Header eine „URI“ (Unrecognized URI or unsupported protocol: Bearer\), dazu kamen 67 TLS-Handshake-Fehler. Gelöst wurde es mit dem Token in einer 0600-Conf-Datei und Retry-Schleifen.
10. 7.7.: Ein fremder Prozess hielt Port 8000. Der Server versuchte 40 Starts in 10 Minuten, mappte jedes Mal 93 GB in Metal und scheiterte danach am Bind. Der erste Quant-Arm produzierte nichts Verwertbares. Der Port ist im Adapter hart kodiert.
11. 8.7.: Der Cap-Starvation-Confound wurde während des Quant-Laufs notiert, bevor die Scores feststanden.
12. 9.7.: ds4-bench kennt kein --mtp. Speculative Decoding ist ein reines Server-Feature; der geplante Bench-Test war damit nicht möglich. Die Server-Probe lieferte keinen Speedup und stützte die Hypothese, dass Basis-Draft und abliteriertes Modell nicht zusammenpassen.

Kosten der Juli-Validierung

Die Juni-Läufe waren deutlich teurer: Allein das Judging der Fusion-Reparatur kostete 255,42 $, die GPT-5.5-Generierung 612,60 $. Mit dem eingefrorenen 20-Aufgaben-Subset konnte ich im Juli vier kontrollierte Arme für zusammen 272,68 $ Judge-Kosten ausführen.

Was diese Zahlen nicht zeigen

• 52,36 % ist kein offizieller DRACO-Wert und kein OpenRouter-Vergleich. Judge, Tooling und teilweise auch die Modellvariante unterscheiden sich.
• Das Subset ist absichtlich hart; 52,36 % dort entspricht nicht 52,36 % auf allen 100 Aufgaben. Ein voller 100er-Lauf mit der Standardkonfiguration steht aus.
• Bei n = 20 und Streuungen um 18 bis 20 sind einzelne Aufgaben sehr laut. Auch die gepaarten Mittel sind Richtungswerte, kein statistischer Beweis.
• Der Vergleich von Juni zu Juli kreuzt Pi-Versionen (0.79.4 → 0.80.2), die Zahl der Judge-Läufe und mehrere Harness-Änderungen. Am saubersten isoliert ist das Steering-A/B. Die Quant-Läufe bleiben durch das effektive Tokenbudget beziehungsweise den Cap-Wechsel konfundiert.
• Gerettete Antworten haben oft schwächere Zitate. Salvage verhindert 0 %, maximiert aber nicht den Score.
• Eine Medizin-Regression (76,6 → 25,1, monoton) ist unerklärt und für einen Re-Judge vorgemerkt.

Die Konfiguration, die jetzt läuft

Seit dem 9.7. läuft diese Standardkonfiguration: 91-GB-Quant, 400k Kontextfenster mit offenem Think-Max-Gate, 64 GB KV-Budget, klebriges Trimmen, gedeckelte Tool-Ausgaben, Salvage, Cap 2.500 s und Steering an.

Als Nächstes kommen der volle 100-Aufgaben-Lauf, die hartnäckige 0,0-Aufgabe 10e75d21 und der Re-Judge der Medizin-Regression. Ein abliterierter DSpark-Draft wäre später noch interessant, falls ihn jemand trainiert. Decode bleibt bis dahin bandbreitenlimitiert bei 18 bis 37 t/s. Die Physik verhandelt nicht.

Quellen und Artefakte

• Teil 1: DRACO mit pi und pi-fusion (Juni-Werkstattbericht)
• Abgeleitete Daten dieses Berichts als JSON (Arm-Scores je Aufgabe, Bench-Kurven und weitere ausgewählte Messwerte)
• DRACO: Datensatz · Paper
• ds4/pi-ds4: Server · Pi-Extension
• Projektnotizen (lokal): Studien-, Validierungs- und Speed-Vektoren-Notizen mit Änderungs-Manifest, Fehlerindex, Chronik und den Pfaden zu den Rohdaten.