Deep Research · Lokale KI · Benchmark

Lokal vs. Frontier bei Deep Research: DeepSeek-V4-Flash gegen GPT-5.5 xhigh

Tom Jansen · 10.07.2026 · 18 Min. Lesezeit

Lokal vs. Frontier ist bei Deep Research mehr als ein Modellvergleich

Bei einer einzelnen Chat-Antwort kann ein lokales Modell schon sehr überzeugend wirken, aber Deep Research umfasst zusätzlich Suchanfragen, Quellenabrufe, wachsende Kontexte und am Ende einen Bericht, der nicht nur gut klingt, sondern die eigentliche Rechercheaufgabe erfüllt. Im Test ist genau dieser vollständige Weg untersucht worden: Wie weit lässt sich Deep Research lokal abbilden, wenn GPT-5.5 xhigh als gehostete Frontier-Referenz danebensteht?

Dahinter stehen zwei Motive, die sich eigentlich kaum trennen lassen: Wissensarbeit soll nicht dauerhaft von den Preisen und Zugriffsregeln weniger Cloudanbieter abhängen, und gleichzeitig gibt es Akten, Verträge oder interne Bewertungen, die eine kontrollierte Umgebung nicht verlassen sollen. Gerade für Kanzleien, Steuerberater, Arztpraxen und Psychologen ist ein lokales Modell deshalb mehr als eine günstigere API, weil sich damit Mandatsakten, Steuerunterlagen, Patientendaten oder Gesprächstranskripte aus psychologischen Sitzungen bearbeiten lassen, die keinem Cloudanbieter überlassen werden sollen. Aber lokal ist die Verarbeitung erst dann wirklich, wenn neben der Modellinferenz auch Tools, Logs, Speicher und Bewertung unter derselben Kontrolle stehen.

Vom X-Post zum DRACO-Test: Audrey Tangs One-Line-Installation

Der Weg zu diesem Setup beginnt mit mehreren Posts auf X. Zuerst ist mit DwarfStar eine native Inferenz-Engine von Salvatore Sanfilippo vorgestellt worden, der online als antirez bekannt und ursprünglicher Entwickler von Redis ist; die erste Version ist speziell für DeepSeek-V4-Flash und Apple Metal optimiert. DwarfStar, im Repository antirez/ds4, ist dabei die Runtime und nicht das Modell.

Kurz danach ist die erste Version von pi-ds4 durch Armin Ronacher veröffentlicht worden, der auf GitHub als mitsuhiko bekannt und unter anderem Schöpfer von Flask und Jinja ist. Damit ist die Verbindung zu Pi hinzugekommen: Über die Extension erfolgt die Kommunikation mit DwarfStar, und DeepSeek-V4-Flash wird in Pi wie ein normaler Modellprovider registriert.

Pi ist der minimale Agent-Harness für das Terminal und von Mario Zechner geschaffen worden. Über Pi erfolgen die Modellsteuerung, die Bereitstellung der Werkzeuge und die Verwaltung der laufenden Konversation, und nach dem späteren Übergang zu Earendil wird das Projekt von Zechner weitergeführt. In der Arbeitsumgebung ist Pi schon ungefähr seit März im Einsatz; Mario Zechners Entwicklung und Armin Ronachers Beiträge in diesem Umfeld sind also bereits bekannt, neu ist hier die lokale Anbindung über DwarfStar.

Ausschlaggebend für den Test ist schließlich ein Post von Audrey Tang, Civic Hacker und Taiwans erste Digitalministerin. In ihrem Fork von pi-ds4 sind DwarfStar, Modellkonfiguration und Installation in einem One-Line-Setup gebündelt worden, und damit liegt erstmals ein Stack vor, der sich einfach genug installieren lässt, um ihn nicht nur zu beobachten, sondern wirklich zu testen.

Ursprünglich ist für den lokalen Stack ein Coding-Benchmark vorgesehen gewesen. Im dafür ausgewählten FrontierCode-Benchmark werden Agenten anhand von Aufgaben aus 36 realen Open-Source-Repositories bewertet, die von deren Maintainern entworfen worden sind, zum Schutz vor Kontamination aber nicht öffentlich zugänglich sind. Damit ist ein unabhängiger Lauf nicht möglich, und der Schwerpunkt ist vom geplanten Coding-Vergleich auf die Frage verlagert worden, wie gut derselbe Stack bei Deep Research funktioniert. Mit DRACO ist dafür ein öffentlicher und ausreichend anspruchsvoller Datensatz gefunden worden.

Mit DRACO wird der gesamte Rechercheprozess bewertet, nicht nur die Einzelantwort

DRACO steht für Deep Research Accuracy, Completeness, and Objectivity. Der öffentliche Benchmark enthält 100 Aufgaben aus zehn Domänen, die aus realen Rechercheanfragen abgeleitet sind, und zu jeder Aufgabe gehört eine gewichtete Rubrik. Erfüllte positive Kriterien bringen Punkte für erwartete Inhalte, während negative Kriterien Punkte abziehen, sobald eine Antwort den beschriebenen Fehler tatsächlich begeht; bewertet werden dabei unter anderem Recherche, Quellenarbeit, Vollständigkeit, Faktentreue und Darstellung.

Dadurch zählt nicht nur die schönste Antwort, sondern der vollständige Pfad bis zu einem bewertbaren Bericht, und eine starke Modellgeneration hilft wenig, wenn in einer Fetch-Schleife kein Fortschritt mehr erzielt wird, das Kontextfenster überläuft oder am Ende durch den Harness die falsche Nachricht gespeichert wird. Modell, Runtime, Agent, Tools, Extraktion und Judge bilden deshalb gemeinsam das Messsystem.

Vom Modell bis zum Score greifen mehrere Schichten ineinander

DwarfStar, Pi und pi-ds4 stehen in diesem Setup für völlig verschiedene Schichten, und genau diese Trennung wird später bei der Fehleranalyse wichtig: Trotz starker Modellgeneration können Punkte verloren gehen, wenn die Inferenz in der Runtime scheitert, durch ein Tool zu viel Inhalt zurückgegeben oder am Ende durch den Harness die falsche Nachricht als Antwort gespeichert wird.

Im Hauptlauf ist die Aufgabe über pi-ds4 und DwarfStar an das lokale DeepSeek-Modell übermittelt worden, und bei Anforderung einer Suche oder eines Seitenabrufs sind Anfrage beziehungsweise URL an einen externen Webdienst weitergegeben und dessen Antwort an das Modell zurückgegeben worden. Diese Schleife ist bis zum Abschlussbericht fortgesetzt worden, und erst danach ist der Bericht an den externen GPT-5.5-xhigh-Judge übermittelt worden. Suchbegriffe, URLs und gegebenenfalls Inhalte aus der Aufgabe können den Rechner also schon während der Recherche verlassen.

Für einen zusätzlichen Fusion-Lauf ist das Setup um die Mehrmodell-Erweiterung pi-fusion ergänzt worden; DeepSeek, Gemma und Qwen sind damit zu einem lokalen Panel verbunden und Gemma sowie Qwen über Ollama ausgeführt worden. Die Modellantworten sind lokal entstanden, aber Panelbewertung und Synthese sind in der Cloud mit GPT-5.5 xhigh durchgeführt worden.

Lokaler Lauf des komprimierten 87-GB-Quants auf dem M5 Max

DeepSeek-V4-Flash ist ein Open-Weight-Mixture-of-Experts-Modell mit 284 Milliarden Parametern, von denen pro Token rund 13 Milliarden aktiv sind, und das offizielle Modell unterstützt bis zu eine Million Token Kontext. Auf dem vorhandenen MacBook Pro mit M5 Max und 128 GB RAM ist die 87-GB-Version unter den geprüften lokalen Modellen die stärkste Konfiguration, die sich noch praktisch betreiben lässt.

Allerdings ist auf dem Mac nicht der unveränderte offizielle Checkpoint eingesetzt worden, sondern ein quantisierter GGUF-Ableger der CyberNeurova-Modelllinie, der in Audrey Tangs pi-ds4-Guide vorgesehen ist. Bei einem Quant werden die Gewichte mit geringerer numerischer Präzision gespeichert, damit sie in weniger Arbeitsspeicher passen, und „abliterated“ bedeutet hier, dass erlernte Ablehnungsmuster in den Gewichten abgeschwächt sind. Im direkten Lauf über alle 100 Aufgaben ist dieser 87-GB-Quant mit 256.000 Token Laufzeitkontext eingesetzt worden, während in späteren Kontrollläufen zusätzlich ein 91-GB-Quant und 400.000 Token Kontext geprüft worden sind. Offizielle Modellgrenze, Quantisierung und tatsächlich konfiguriertes Kontextfenster bezeichnen also drei verschiedene Dinge.

Drei getrennte Auswertungsarme: Frontier, lokal und Fusion

„Frontier“ bedeutet in diesem Artikel ganz konkret GPT-5.5 xhigh als gehostete Referenz und nicht eine allgemeine Modellklasse, die sich mit jedem neuen Leaderboard verschiebt. Daneben ist mit DeepSeek-V4-Flash auf demselben DRACO-Aufgabensatz ein lokaler Lauf durchgeführt worden, und in einem zusätzlichen Fusion-Lauf ist die Zusammenarbeit mehrerer lokaler Modelle mit einem externen Judge und Synthesizer geprüft worden.

Für jede Aufgabe werden die Rubrikkriterien einzeln geprüft, und während erfüllte positive Kriterien ihr Gewicht einbringen, wird bei erfüllten negativen Kriterien das jeweilige Gewicht als Strafe wieder abgezogen. Anschließend wird diese Bilanz im Harness durch die Summe aller positiven Gewichte geteilt und auf 0 bis 100 % begrenzt; leere Antworten werden mit 0 % bewertet, und bei mehreren Judge-Läufen wird der Mittelwert als Aufgabenscore verwendet.

Über alle 100 Aufgaben wird hier der ungewichtete Mittelwert der Aufgabenscores verwendet. Bei einer alternativen Aggregation werden zunächst erreichte und mögliche Rubrikgewichte summiert, wodurch Aufgaben mit größerem Gesamtgewicht stärker zählen und der zusammengeführte DeepSeek-Lauf auf 46,61 % käme. Für den hier berichteten Wert sind dagegen nur leere lokale Ausgaben erneut erzeugt und anschließend anstelle ihrer leeren Originalausgabe eingesetzt worden; für GPT-5.5 ist kein entsprechender Retry durchgeführt worden, der vollständige lokale Lauf ist einmal bewertet worden und jeder GPT-5.5-Wert dreimal.

48,18 % und 49,37 % liegen nah, aber nicht unter demselben Protokoll

Mit dem strengen Judge liegen zwischen dem lokalen Lauf nach Retry und der Frontier-Referenz 1,19 Prozentpunkte, was einen kontrollierten Wiederholungslauf rechtfertigt, aber noch keinen Gleichwertigkeitsnachweis. Für leere DeepSeek-Antworten ist nachträglich ein Retry durchgeführt worden, für GPT-5.5 nicht, außerdem unterscheiden sich die Zahl der Judge-Läufe und einzelne Generationserfolge. Für Gleichwertigkeit reicht es nicht.

12,4 Prozentpunkte Unterschied durch den Judge-Wechsel

Unter zwei Judge-Konfigurationen liegen für dieselben gespeicherten GPT-5.5-Antworten deutlich verschiedene Scores vor, obwohl die zugrunde liegende Recherche unverändert ist und sich ausschließlich die Judge-Konfiguration unterscheidet.

Allein durch diesen Wechsel ist der Score um 12,4 Prozentpunkte verschoben worden und damit um mehr als den gemessenen Abstand zwischen lokalem Modell und Frontier-Referenz. Der Judge steht also nicht am Rand der Auswertung, sondern ist ein fester Teil des Benchmarks, und veröffentlichte DRACO-Werte mit anderem Judge oder anderem Tooling gehören nicht einfach in dieselbe Rangliste.

Als Ausgangspunkt für den Fusion-Versuch dient die öffentliche OpenRouter-Auswertung, aber wegen eines anderen Judges, anderer Tools und sieben gefilterter Aufgaben lässt sie sich nicht direkt mit den beiden Werten vergleichen.

Zwölf fehlende Antworten bereits vor der Bewertung

Der Rohstand der 100 lokalen Aufgaben umfasst 12 leere Antworten, jeweils sechs nach einem Timeout oder einem Stopp in pi-ds4. Zur Diagnose sind in acht getrennten Läufen Server, Adapter, Ergebnisse, Fusion und Harness untersucht worden, und dadurch sind mehrere Nullen technischen Fehlern zugeordnet worden, die schon vor der inhaltlichen Bewertung aufgetreten sind. Von besonderer Bedeutung ist dabei der KV-Cache, in dem bereits berechnete Kontextzustände vorgehalten werden; sobald seine Checkpoints verdrängt werden, müssen lange Teile des bisherigen Kontexts erneut durch die Runtime eingelesen werden.

Aus den Laufnotizen stammen sowohl die Zuordnung von 42 der 48 Fusion-Fehler zum Kontextlimit als auch die 3.102 KV-Verdrängungen und 76 Treffer. Weil das rotierte Server-Rohlog nicht mehr vorhanden ist, lassen sich diese Zähler heute nicht noch einmal unabhängig aus dem Log rekonstruieren.

Die Gegenmaßnahmen ergeben sich daraus ziemlich direkt: In der neuen Konfiguration sind Tool-Ausgaben auf 30.000 Zeichen begrenzt, Paging ergänzt, Kontextüberläufe korrekt klassifiziert, das KV-Budget erhöht und Think Max freigeschaltet worden. Alte Nachrichten sind beim Trimming nur noch so verändert worden, dass der stabile Prefix erhalten geblieben ist, und bei weiterhin fehlender Abschlussantwort ist der letzte substantielle Bericht per „Salvage“ gesichert worden. Die Verbesserungen betreffen damit den Agentenlauf und nicht die Modellgewichte.

Bestätigung des Coverage-Problems im Fusion-Lauf

Im diagnostischen Fusion-Lauf ist mit DeepSeek über pi-ds4 und DwarfStar sowie mit Gemma und Qwen über Ollama ein lokales Panel betrieben worden, während Panelbewertung und Synthese des finalen Berichts in der Cloud mit GPT-5.5 xhigh durchgeführt worden sind.

Das Gesamtergebnis wirkt mit 100 von 100 abgeschlossenen Aufgaben zunächst vollständig, darunter stehen aber nur 49 auf fusion_status=ok und 51 auf partial. Für DeepSeek liegen 52 gültige Panelantworten vor, während 48 Panelstufen einen Fehler aufweisen und in den Laufnotizen 42 davon dem Kontextlimit zugeordnet werden. Wertet man nur die 52 gültigen Antworten aus, ergeben sich 48,21 % bei 52 % Coverage; zählen alle 48 Fehler als null, bleiben 25,07 %.

Beide Werte beantworten also unterschiedliche Fragen: 48,21 % beschreiben nur die erfolgreichen lokalen DeepSeek-Stufen, während 25,07 % den vollständigen Lauf abbilden, sobald jeder technische Ausfall mit null eingeht. Ohne die Angabe 52/100 sehen sie wie zwei konkurrierende Scores aus, obwohl eigentlich die Coverage ihre unterschiedliche Aussage erklärt.

Änderungen in Pi und pi-ds4 infolge der Fehler

Für die nicht erkannten Kontextfehler ist ein Bug-Ticket im Pi-Repository entstanden, denn die Überläufe sind von DwarfStar in einer Form gemeldet worden, die zu keinem der vorhandenen Erkennungsmuster passt:

Prompt has 256468 tokens, but the configured context size is 256000 tokens

Die Meldung ist deshalb als allgemeiner Provider-Fehler behandelt und der Turn ohne Kompaktierung beendet worden. Mit einem zusätzlichen Erkennungsmuster ist die Meldung der richtigen Fehlerklasse zugeordnet worden, und im späteren Empty-Retry sind 11 der 12 leeren Antworten wiederhergestellt worden; eine ist leer geblieben.

Beim KV-Cache ist ein zweites Problem sichtbar geworden, weil das pauschale 8-GB-Disk-Budget für 400k-Kontexte auf einer Maschine mit 128 GB RAM einfach zu klein dimensioniert ist. Mit Version 0.4.1 ist deshalb ein RAM-abhängiger Standard eingeführt worden: 64 GB ab 128 GB Arbeitsspeicher, 32 GB zwischen 96 und 127 GB und sonst weiterhin 8 GB. Audrey Tangs Release-Notiz nennt den Beitrag mit @tjansn, und durch das größere Budget bleiben bei langen Sitzungen mehr Prefix-Checkpoints auf Disk, sodass teure Neueinlesungen seltener werden.

Öffentlich nachprüfbar sind der spätere Commit und die Release-Notiz mit @tjansn; zum ursprünglichen X-Post liegt in den Artefakten dagegen kein direkter Link mehr vor. Laut Arbeitsnotiz ist Audrey Tang dort markiert worden; anschließend ist der Beitrag von ihr gelikt und die Übernahme der Änderung in das nächste Release öffentlich angekündigt worden. Ein privater oder vorab abgestimmter Maintainer-Kontakt ist nicht erfolgt; als Kommunikationswege sind das öffentliche GitHub-Ticket zum Kontextfehler und der öffentliche X-Post zum KV-Befund dokumentiert.

Prüfung der Reparaturen im 20er-Subset, nicht der Rangliste

Ein neuer Lauf über alle 100 Aufgaben ist für jede technische Hypothese zu langsam und zu teuer, deshalb besteht das Entwicklungsset aus 20 festen Aufgaben: sechs pathologischen Fällen aus den Juni-Totalausfällen, jeweils vier aus schwachen und starken Domänen und sechs aus dem Mittelfeld. Die Auswahl ist darauf ausgelegt, bekannte Fehler möglichst zuverlässig zu provozieren, und ist dadurch weder ein zufälliges Sample noch ein Holdout; mit dem 100-Aufgaben-Schnitt lässt sie sich nicht vergleichen.

In der Tabelle stehen die Konfigurationen in ihrer zeitlichen Entwicklungsreihenfolge, wobei „Think Max“ die höchste Denkstufe bezeichnet und bei fehlendem Abschluss über „Salvage“ der letzte substantielle Bericht gesichert wird; Aufgaben- und Rettungslimit begrenzen jeweils die Laufzeit. Zusätzlich ist im Adapter ein Steering-Vektor gegen ausweichende Formulierungen und für stabilere Tool-Syntax aktiv, der sich mit ffn=0 abschalten lässt.

Mit deaktiviertem Vektor ist die vermutete Verschlechterung im A/B-Test nicht bestätigt worden, denn der einzelne 20-Aufgaben-Lauf ist vollständig mit Rauschen vereinbar und belegt weder einen Nettoeffekt noch dessen Abwesenheit. Das Steering bleibt deshalb aktiv.

Auch die 52,36 % aus dem letzten Arm sind kein isolierter Modellvergleich, weil Aufgaben- und Rettungszeitlimit gleichzeitig erhöht worden sind. Dadurch sind beide zuvor leeren Aufgaben wiederhergestellt worden, während eine andere in allen Läufen bei null geblieben ist, und bei den ausgewählten Problemfällen zeigen die Reparaturen Wirkung. Der Wert ist aber weder ein offizieller DRACO-Score noch ein Beleg für eine Überlegenheit gegenüber dem 100-Aufgaben-Lauf.

Lokale Inferenz verlagert Kosten und Abhängigkeiten

Für die lokale DeepSeek-Inferenz fallen 0 $ Modell-API-Kosten an, aber natürlich ist der Lauf deshalb nicht kostenlos: Für das Setup sind ein MacBook Pro Mac17,6 mit M5 Max, 18 CPU-Kernen und 128 GB RAM sowie Strom, Laufzeit und Arbeit am Harness erforderlich. Auch Web-Recherche, Fusion-Judge, Synthese und DRACO-Bewertung bleiben externe Dienste.

Die gemessene Decodierrate der 87- und 91-GB-Quants liegt je nach Kontext und Zustand der Maschine auf dem M5 Max grob zwischen 18 und 37 Token pro Sekunde, sodass Speicherbandbreite, KV-Cache und Zeitlimits weiterhin ganz praktische Grenzen setzen. Die Kostenstruktur verschiebt sich damit weg von der Modell-API und hin zu Hardware, Energie, Zeit und eigener Betriebsarbeit, und die lokale Pipeline wird dadurch weder unendlich schnell noch wartungsfrei.

Nächster Schritt: kontrollierter 100-Aufgaben-Lauf unter identischen Regeln

Nach dem Empty-Retry liegt für 99 von 100 Aufgaben eine nicht-leere lokale DeepSeek-Antwort vor, und der zusammengeführte Score beträgt 48,18 %, womit er genau 1,19 Prozentpunkte unter dem direkten GPT-5.5-xhigh-Lauf liegt. Das ist nah genug für einen neuen kontrollierten Lauf, aber wegen unterschiedlicher Retry-Regeln und Judge-Wiederholungen noch kein Gleichwertigkeits- oder Produktionsnachweis.

Bevor der nächste vollständige Lauf mit der neuen Standardkonfiguration startet, müssen deshalb Tool-Blocklisten, Output-Caps sowie Retry- und Salvage-Regeln feststehen, und für Frontier wie lokal braucht es denselben Judge, gleich viele Judge-Läufe und dieselbe Behandlung leerer Antworten. Neben dem Score gehören außerdem Coverage, Kosten, Tokens und Fehlerklassen, denn erst dann lässt sich sagen, wie viel von den 1,19 Prozentpunkten unter identischen Regeln noch übrig bleibt.

Und für die eigentlich wichtigere Frage nach vertraulicher Deep Research reicht auch dieser Vergleich noch nicht, weil Suchdienste, Seitenabrufe, Telemetrie, Protokolle, Bewertung und Ablage ebenfalls kontrolliert werden müssen. In den beschriebenen Läufen befinden sich Webdienste und Judge weiterhin außerhalb der lokalen Umgebung, weshalb Mandatsakten, Steuerunterlagen, Patientendaten oder Gesprächstranskripte aus psychologischen Sitzungen erst infrage kommen, wenn auch diese Teile lokal laufen oder vertraglich kontrolliert sind.

Quellen und Artefakte

• Pi: minimaler Agent-Harness · Herkunft und Übergang zu Earendil
• antirez: DwarfStar Runtime
• Armin Ronacher: ursprüngliche pi-ds4-Extension
• Audrey Tang: pi-ds4 Fork · Installations- und Release-Guide · RAM-tiered-KV-Commit mit @tjansn
• DeepSeek-V4-Flash: offizielles Modell · getestete quantisierte Modelllinie
• Cognition: FrontierCode und Zugangsmodell
• DRACO Paper: A Cross-Domain Benchmark for Deep Research Accuracy, Completeness, and Objectivity
• Perplexity Research: Evaluating Deep Research Performance in the Wild with the DRACO Benchmark
• DRACO Dataset auf Hugging Face
• OpenRouter: Surpassing Frontier Performance with Fusion
• pi Issue #6262: DS4 context overflow errors not detected by auto-compaction
• Abgeleitete lokale Kennzahlen des Juni-Runs
• Abgeleitete Daten der Juli-Optimierung