Evaluierungen von DeepSeek V3.2: Was messen die Benchmarks und wie weit sind sie vergleichbar?

Geltungsbereich: Was sich mit der verfügbaren Evidenz aussagen lässt

Ein Benchmarkwert beschreibt ein Modell nicht für sich allein. Um ihn einordnen zu können, braucht man mindestens die getestete Aufgabe, den Testsatz, die Metrik, die Modellvariante und die Ausführungsbedingungen. Ändert sich eines dieser Elemente zwischen zwei Ergebnissen, ist der Vergleich möglicherweise nicht mehr unmittelbar aussagekräftig – selbst wenn beide Zahlen in derselben Tabelle stehen oder als Ergebnisse desselben Systems präsentiert werden.

Diese Prüfung wendet diesen Maßstab auf DeepSeek-V3.2 an. Das verfügbare Material bestätigt, dass es ein Paper mit diesem Namen sowie eine offizielle Mitteilung zur Veröffentlichung gibt, die DeepSeek-V3.2 von DeepSeek-V3.2-Speciale unterscheidet. Außerdem verweist es auf eine Modelldokumentation auf Hugging Face, ein Repository von DeepSeek zu DeepSeek-V3.2-Exp sowie externe Analysen zu V3.2-Exp und zu API-Benchmarks. Die bereitgestellten Auszüge enthalten jedoch weder die vollständigen Tabellen noch die Evaluierungsprotokolle des Papers.

Deshalb nennt dieser Beitrag keine konkreten Punktzahlen und erstellt keine Rangliste von Modellen. Allgemeine Hinweise auf Reasoning, Programmierung oder Tool-Nutzung werden auch nicht in quantitative Ergebnisse umgedeutet. Ziel ist vielmehr, einzugrenzen, was sich aus dem auffindbaren Material ableiten lässt, Quellen unterschiedlicher Art voneinander zu trennen und genau zu benennen, was in den vollständigen Dokumenten geprüft werden muss, bevor ein Wert zur Modellauswahl oder zum Systemvergleich herangezogen wird.

Der Benchmark-Index und die Seite „evaluaciones-deepseek-v32“ bieten thematische Anknüpfungspunkte, um eine solche Prüfung zu strukturieren. Für sich genommen belegen sie jedoch weder, dass ein Test durchgeführt wurde, noch, dass ein Ergebnis reproduzierbar ist. Die für diesen Beitrag relevante Organisation ist DeepSeek; Gegenstand der Prüfung ist DeepSeek-V3.2 und nicht jedes System, dessen Name „DeepSeek“ enthält.

Quelleninventar und was sich damit überprüfen lässt

Das Paper mit dem Titel „DeepSeek-V3.2: Pushing the Frontier of Open Large Language Models“ ist die vorrangige Quelle für die Prüfung der DeepSeek-V3.2 zugeschriebenen Evaluierungen. Der verfügbare Auszug beschreibt eine Arbeit zu DeepSeek-V3.2, deren allgemeiner Schwerpunkt auf Recheneffizienz, Reasoning und Agentenleistung liegt. Aus dieser Zusammenfassung gehen jedoch weder Benchmarknamen noch Punktzahlen, getestete Datensätze oder Ausführungsbedingungen hervor. Sie reicht daher nicht aus, um ein vollständiges Testinventar zu erstellen.

Die offizielle Mitteilung zur Veröffentlichung hilft, Varianten voneinander abzugrenzen: Das bereitgestellte Material unterscheidet V3.2, das im Zusammenhang mit einem ausgewogenen Verhältnis von Inferenz und Ausgabelänge beschrieben wird, von V3.2-Speciale, das als Konfiguration für maximale Reasoning-Fähigkeiten charakterisiert wird. Diese Unterscheidung ist wichtig, belegt aber nicht, welche Variante in einer bestimmten Tabelle des Papers getestet wurde. Um ein Ergebnis eindeutig zuzuordnen, müssen die Tabellenüberschrift, ihre Anmerkungen und der zugehörige Methodenteil geprüft werden.

Die Modelldokumentation auf Hugging Face ist eine Primärquelle des Anbieters und bestätigt, dass eine Seite mit der Bezeichnung DeepSeek-V3.2 existiert. Der bereitgestellte Auszug beschreibt kein vollständiges Benchmarkprotokoll. Daneben bezieht sich die externe Rezension „DeepSeek V3.2-Exp Review“ ausdrücklich auf V3.2-Exp und erwähnt allgemein Programmier-Benchmarks. Ihre Aussagen dürfen nicht automatisch auf V3.2 übertragen werden.

Auch das Repository DeepSeek-V3.2-Exp betrifft eine experimentelle Variante. Dem Auszug zufolge wurden deren Trainingskonfigurationen an diejenigen von V3.1-Terminus angeglichen, um die Wirkung der sparsamen Attention zu untersuchen. Das beschreibt den genannten experimentellen Zweck, belegt aber nicht, dass Ergebnisse von Exp mit Ergebnissen des Modells V3.2 gleichzusetzen sind. Die Analyse von DeepInfra wiederum konzentriert sich laut Titel und Beschreibung auf API-Benchmarks, Latenz und Durchsatz. Das sind andere Messgrößen, die ohne Prüfung der Methodik nicht mit Fähigkeitstests vermischt werden sollten.

Welche Angaben ein Benchmark-Steckbrief enthalten sollte

Eine nachvollziehbare Ergebnistabelle muss in jeder Zeile den Test benennen und erläutern, welche Aufgabe er stellt. Eine Bezeichnung wie „Reasoning“ oder „Programmierung“ genügt nicht: Sinnvoll sind Angaben zum Datensatz oder zur Benchmarkversion, zu Ein- und Ausgabetypen und zum Bewertungskriterium. Außerdem ist festzuhalten, ob es sich um einen direkten Modelllauf, eine Konfiguration mit Tools oder ein System aus Modell und Umgebung handelt.

Die Metrik sollte benannt und definiert werden, statt lediglich als Zahl wiedergegeben zu werden. Eine Trefferquote, ein aggregierter Score und eine Latenzmessung beantworten unterschiedliche Fragen. Werden mehrere Metriken ausgewiesen, muss klar sein, welche für den Hauptvergleich herangezogen wurde und wie sie berechnet wurde. Bei wiederholten Testläufen ist die Zahl der Durchläufe und die Art ihrer Zusammenfassung relevant. Wird nur ein einzelnes Ergebnis genannt, darf man nicht unterstellen, dass es sich um einen Mittelwert handelt oder dass dazu eine statistische Unsicherheit veröffentlicht wurde.

Auch das Modell muss präzise identifiziert werden. „DeepSeek“ kann sich auf verschiedene Generationen beziehen; V3.2, V3.2-Speciale und V3.2-Exp sind keine austauschbaren Bezeichnungen. Eine API-Version, eine Überarbeitung der Gewichte oder eine Konfiguration mit Tools kann verändern, was tatsächlich geprüft wird. Wenn die Quelle das genaue Artefakt nicht nennt, sollte diese Einschränkung sichtbar bleiben, statt sie durch Schlussfolgerungen zu überbrücken.

Die verfügbaren Auszüge enthalten nicht die Zeilen, die für einen solchen Steckbrief nötig wären. Eine quantitative Ergebnistabelle wäre zum jetzigen Zeitpunkt daher unvollständig. Die oben dargestellte Evidenztabelle bildet absichtlich nur die Verfügbarkeit von Informationen ab: Sie verhindert, dass etwas als bestätigt erscheint, das erst durch Prüfung und Abgleich des vollständigen Papers belegt werden müsste.

Protokoll und Vergleichbarkeit: Warum zwei Zahlen nicht unbedingt gleichwertig sind

Ein fairer Vergleich erfordert mehr, als denselben Benchmarknamen zu verwenden. Die Version des Datensatzes, die Anweisungen, der Prompt, der Harness und die Bewertungsmethode können das Ergebnis beeinflussen. Auch verfügbare Tools sind relevant: Ein Agent mit Zugriff auf Suche, Codeausführung oder andere Ressourcen wird nicht zwingend unter denselben Bedingungen gemessen wie ein Modell ohne solche Hilfsmittel. Diese Variablen müssen in der Quelle beschrieben oder beim Vergleich kontrolliert werden.

Das Tokenbudget ist eine weitere wichtige Bedingung. Darf ein Lauf mehr Tokens erzeugen, zusätzliche Schritte ausführen oder mehr Versuche unternehmen, hat er möglicherweise mehr Gelegenheiten, eine Aufgabe zu lösen. Das macht die Evaluierung nicht ungültig, verpflichtet aber dazu, das Budget anzugeben und das Ergebnis nicht so darzustellen, als sei es mit gleichwertigen Ressourcen erzielt worden. Entsprechendes gilt für Zeitlimits, Sampling-Parameter und Regeln für Wiederholungen.

Die bereitgestellten Auszüge nennen weder Prompt noch Harness, Tools, Tokenbudget oder Anzahl der Durchläufe für die Tests im Paper. Sie zeigen auch nicht, ob die Punktzahlen von DeepSeek und anderen Modellen mit identischen Benchmarkversionen und gleichwertigen Verfahren ermittelt wurden. Auf Grundlage dieses Materials lässt sich deshalb weder behaupten, ein bestimmter Vergleich sei fair, noch, er sei unfair. Die zutreffende Aussage lautet, dass dies hier nicht verifiziert ist.

Bei API-Analysen ist eine zusätzliche Trennung nötig. Eine Latenzmessung kann von Region, Auslastung des Dienstes, Eingabegröße und Antwortlänge abhängen. Der Durchsatz kann die Kapazität eines Dienstes unter einer festgelegten Last abbilden. Solche Beobachtungen können für die Bewertung einer Implementierung nützlich sein, ersetzen aber keinen Fähigkeitstest des Modells und sollten ohne begründeten Zusammenhang nicht in eine Reasoning-Rangliste aufgenommen werden.

Datenkontamination, Reproduzierbarkeit und Grenzen der Evidenz

Eine Kontamination des Testsatzes durch Trainingsdaten kann die Interpretation eines Scores beeinträchtigen. Sie darf jedoch nicht allein daraus abgeleitet werden, dass ein Ergebnis hoch erscheint oder ein Benchmark bekannt ist. Eine belastbare Aussage über Kontamination erfordert Belege und eine Erklärung der Methode, mit der sie erkannt oder begrenzt wurde. Anhand des verfügbaren Materials lässt sich nicht bestätigen, welche Prüfungen das Paper beschreibt oder welche Belege es zu Überschneidungen vorlegt.

Reproduzierbarkeit setzt voraus, dass genügend Informationen veröffentlicht werden, um die Evaluierung nachzustellen: Modellversion, Code oder Harness, Anweisungen, Konfiguration, Zugang zu den Testfällen und Ausführungsbedingungen. Dass eine Modellseite oder ein Repository existiert, belegt für sich genommen nicht, dass all diese Bestandteile für jeden Benchmark zugänglich sind. Ebenso beweist die Beschreibung einer experimentellen Variante nicht, dass sich ihre Evaluierungen unter identischen Bedingungen wiederholen lassen.

Der Detailgrad ist in dieser Prüfung uneinheitlich. Das Material reicht aus, um die Quellen nach Gegenstand zu trennen – Paper zum Modell, Veröffentlichungsmitteilung, Modellseite, experimentelle Variante und API-Messungen. Es reicht jedoch nicht aus, um das vollständige Testinventar zu bestätigen, die Scores zu reproduzieren oder die Kontaminationsprüfungen zu bewerten. Der Unterschied zwischen „die Quelle existiert“ und „das Protokoll ist verifiziert“ muss in jeder späteren Zusammenfassung erhalten bleiben.

Falls das vollständige Dokument Anhänge, Tabellenanmerkungen oder Links zu Code enthält, könnten diese einen Teil der offenen Fragen klären. Bis diese Inhalte geprüft wurden, darf das Fehlen einer Angabe in den vorliegenden Auszügen nicht in die Behauptung umgewandelt werden, DeepSeek habe sie nicht veröffentlicht. Die präzise und engere Formulierung lautet: Hier liegt nicht genügend Evidenz vor, um den Punkt zu überprüfen.

Varianten und Zugriff: Modell, Experiment und Dienst

Die offizielle Mitteilung zur Veröffentlichung unterscheidet DeepSeek-V3.2 von DeepSeek-V3.2-Speciale. Diese Unterscheidung genügt, um zu verlangen, dass jeder Wert einer eindeutig identifizierbaren Variante zugeordnet wird. Sie reicht aber nicht aus, um festzustellen, welche Variante in jedem Test verwendet wurde. Vor einem Ergebnisvergleich sind daher der Name in der Originaltabelle und alle Anmerkungen zur Konfiguration zu prüfen. Steht in der Tabelle lediglich „V3.2“, darf daraus nicht automatisch Speciale oder V3.2-Exp gemacht werden.

V3.2-Exp ist gesondert zu behandeln. Die DeepSeek-Quelle zu dieser Variante ordnet sie einer Untersuchung der sparsamen Attention zu und erwähnt eine Angleichung der Trainingskonfigurationen an V3.1-Terminus. Das hilft zu verstehen, weshalb eine Evaluierung von Exp Teil eines spezifischen Vergleichsexperiments sein könnte. Es rechtfertigt nicht, ihre Ergebnisse so zu V3.2 hinzuzurechnen, als handele es sich um dieselbe Version.

Auch Modellgewichte und die Zugriffsbedingungen über eine API sollten auseinandergehalten werden. Die bereitgestellte Antwort kann von einer ausgerollten Version, betrieblichen Grenzwerten und Serviceparametern abhängen. Eine externe Analyse zu Latenz und Durchsatz kann das Verhalten einer API unter den von den Messenden gewählten Bedingungen beschreiben. Ohne Angaben zu dieser Umgebung sollte ein Unterschied nicht ausschließlich der Architektur oder der allgemeinen Leistungsfähigkeit des Modells zugeschrieben werden.

Für Einkaufsverantwortliche verhindert diese Trennung eine häufige, aber wenig belastbare Schlussfolgerung: eine Konfiguration auszuwählen, weil ihr der Score einer anderen Variante oder eine Servicemessung zugeschrieben wird, die eine andere Frage beantwortet. Für die Entscheidung müssen das genaue Produkt, die Zugriffsart und die tatsächliche Deployment-Aufgabe identifiziert werden. Außerdem ist zu prüfen, ob die Evaluierung die Einschränkungen und Tools widerspiegelt, die das System in der Produktion haben wird.

Was die Tests aussagen können – und was außerhalb ihrer Reichweite liegt

Wenn ein Score verifiziert ist, muss die Schlussfolgerung auf die Aufgabe, den Testsatz und die Bedingungen beschränkt bleiben, unter denen er erzielt wurde. Ein Ergebnis in einem Programmier-Benchmark würde nicht automatisch ein allgemein hohes Programmierniveau für alle Sprachen, Repositories oder Arbeitsabläufe belegen. Ebenso beweist eine Reasoning-Evaluierung für sich genommen weder Sicherheit noch dauerhafte Zuverlässigkeit, die Qualität von Quellenangaben, die Anpassung an eine Organisation oder die Leistung im Produktivbetrieb.

Im konkreten Fall erlauben die bereitgestellten Auszüge keine quantitativen Schlussfolgerungen zu DeepSeek-V3.2. Sie belegen auch nicht, dass das Modell einen bestimmten Wettbewerber in einem bestimmten Benchmark übertrifft. Sie helfen jedoch dabei, die richtigen Fragen zu strukturieren: Welche Variante wurde getestet? Welche Aufgabe und Metrik wurden verwendet? Welche Ressourcen waren zugelassen? Und wer hat den Test durchgeführt? Außerdem zeigen sie, dass die Rezension zu V3.2-Exp und die Analyse von API-Benchmarks das Protokoll des Papers nicht ersetzen.

Eine betriebliche Bewertung sollte veröffentlichte Benchmarks durch eigene Tests mit repräsentativen Aufgaben und vorab festgelegten Kriterien ergänzen. Bei einer internen Evaluierung sollten neben dem besten Ergebnis auch Fehler, Schwankungen, Kosten und Laufzeiten berücksichtigt werden. Werden Tools eingesetzt, muss die Evaluierung das Gesamtsystem messen und dokumentieren, welcher Anteil der Leistung vom Modell und welcher von der Umgebung abhängt.

Es lässt sich nicht behaupten, dass eine veröffentlichte Evaluierung allein das Verhalten von DeepSeek-V3.2 in allen Kontexten vorhersagt. Wie gut sich ein Ergebnis übertragen lässt, hängt davon ab, wie nahe die Testaufgabe am tatsächlichen Einsatz liegt. Diese Einschränkung entwertet Benchmarks nicht. Sie grenzt vielmehr die Frage ein, die sie beantworten, und verhindert, dass aus einer begrenzten Messung eine allgemeine Aussage über Fähigkeiten wird.

Fazit: verifizierte Ergebnisse und offene Fragen

Die belastbarste Schlussfolgerung aus dem verfügbaren Material ist methodischer Natur. Es gibt ein Paper zu DeepSeek-V3.2, eine offizielle Mitteilung, die V3.2 von V3.2-Speciale unterscheidet, sowie Materialien zu einer Variante V3.2-Exp und zu API-Messungen. Diese Quellen sind nicht austauschbar: Jede behandelt einen anderen Gegenstand oder eine andere Fragestellung. Der hier verfügbare Auszug aus dem Paper enthält weder die Tabellen noch das vollständige Protokoll. Damit fehlt eine ausreichende Grundlage für eine verifizierte quantitative Rangliste.

Bevor Ergebnisse in einen Vergleich aufgenommen werden, sollte als Nächstes das vollständige Paper geprüft und jeder Test mit Version, Variante, Metrik und Bedingungen erfasst werden. Anschließend sind Tabellenanmerkungen und Anhänge abzugleichen und offizielle Ergebnisse von externen Evaluierungen zu trennen. Fehlt eine Bedingung in der Quelle, muss sie als unbekannt gekennzeichnet werden; sie darf nicht anhand der Modellseite, einer Rezension oder der Beschreibung einer anderen Variante ergänzt werden.

Für Leserinnen und Leser des Benchmark-Index gilt als praktische Regel: Ein Score lässt sich nur dann vergleichen, wenn Aufgabe und relevante Bedingungen hinreichend übereinstimmen. Teams, die DeepSeek-V3.2 bewerten, sollten auf die Originaltabelle zurückverfolgbare Angaben verlangen und eigene Tests mit genau dem Produkt und der Konfiguration durchführen, die tatsächlich eingesetzt werden sollen. Auf Grundlage der hier bereitgestellten Evidenz müssen konkrete Ergebnisse weiterhin dokumentarisch verifiziert werden.

Weiter entdecken

Korrekturen und Transparenz

Wenn du falsche oder veraltete Angaben findest, sende uns die Seite und die zu prüfende Quelle.