LLM Model Review
Erstellt am · Instruction-Tuned
Mit einem Gesamtscore von 42,58 Prozent und dem Speed Profile Badge Batch DevOps Expert wirkt DeepSeek R1 Distill Qwen 7B wie ein Modell mit großen Ambitionen und zu wenig Disziplin. Die redaktionelle Einordnung passt trotzdem: Es ist ein auf Schlussfolgern optimiertes Edge-Modell mit 7,6 Milliarden dichten Parametern, lokal betreibbar, instruktionsnah im Auftreten, aber im konkreten Testlauf ausdrücklich im Standard-Modus ohne aktiviertes Thinking. Gerade deshalb fallen die Schwächen beim sichtbaren Endergebnis so hart ins Gewicht: Das Modell denkt viel, liefert aber zu oft entweder zu wenig, das Falsche oder schlicht das Falsche in der falschen Sprache.
Kopfnoten: Stabilität und Zuverlässigkeit
| Metrik | Wert | Bewertung | Analyse |
|---|---|---|---|
| Timeout-Rate | 7/43 | Unzuverlässig | Das Modell ist unzuverlässig und bricht in der Praxis signifikant oft weg. |
| P95-Antwortzeit | 663.47 s | Kritisch | Extreme Tail-Latenz. Das Modell streut massiv und ist für zeitkritische Prozesse ungeeignet. |
Architektur und Erwartungsrahmen
DeepSeek R1 Distill Qwen 7B tritt in einer interessanten Nische an. Der primäre Use Case ist Reasoning, also mehrstufiges Schlussfolgern. Die Size Class ist Edge, damit gelten andere Maßstäbe als bei großen Cloud-Frontier-Modellen. Und die Architektur ist dense, also klassisch: Alle 7,6 Milliarden Parameter sind pro Anfrage vollständig aktiv. Das ist wichtig, weil hier keine MoE-Ausrede greift. Wenn das Modell patzt, dann nicht, weil nur ein Teil der Gewichte wach war.
Hinzu kommt der zweite Rahmen: Die Instruct-Ausrichtung. Ein solches Modell sollte Befehle sauber ausführen, präzise Formate treffen und bei Sprache, Länge und Struktur nicht schon bei der zweiten Nebenbedingung ins Schlingern geraten. Genau dort liegt der Kernkonflikt dieses Kandidaten. Als Reasoning-Modell will es tiefer gehen. Als Instruct-Modell müsste es sich dabei zusammenreißen. Im vorliegenden Standard-Lauf gelingt ihm diese Balance erschreckend oft nicht.
Geschwindigkeit und Laufcharakter
Als lokales Modell lief DeepSeek R1 Distill Qwen 7B auf NVIDIA DGX Spark (GB10 Grace Blackwell Superchip, ~115 GB Unified Memory — kein praktisches Speicherlimit für getestete Modellgrößen). Der Badge Batch DevOps Expert beschreibt den Charakter treffend: kein Sprinter für Dialoge, eher ein Modell für Stapelverarbeitung, längere Aufgaben und Workloads, bei denen Wartezeit nicht sofort den Arbeitsfluss zerstört. Nur macht der Badge hier fast noch einen zu freundlichen Eindruck. Auf dem Testsystem zeigt das Modell kein flottes Batch-Temperament, sondern zähe, stark streuende Laufzeiten.
Auch die Token-Effizienz spricht dieselbe Sprache. Im CLI-Modul produziert es mehr als das Fünfzehnfache des Fleet-Medians. Im Content-Transformation-Bereich fast das Doppelte. Das ist bei einem lokalen Modell vor allem ein Latenzsignal: mehr Text, mehr Wartezeit, mehr Gelegenheit, sich im eigenen Redefluss zu verheddern. Bei Reasoning- und Metacog-Aufgaben ist hohe Ausführlichkeit legitim. Im CLI- oder Transformationskontext ist sie oft nur teure Selbstbeschäftigung.
Reasoning und Logik
Der faire Ausgangspunkt lautet: Dieses Modell ist auf Denken optimiert, und zwar auch dann, wenn der konkrete Lauf im Standard-Modus stattfand. Deshalb wäre es billig, lange interne Denkpfade pauschal gegen es zu verwenden. Interessant ist vielmehr, was beim Nutzer ankommt. Und da zeigt DeepSeek R1 Distill Qwen 7B ein widersprüchliches Profil.
Positiv ist, dass die logische Substanz stellenweise vorhanden ist. Im klassischen Wächter-Rätsel war die Lösung inhaltlich korrekt: Frage den einen Wächter, was der andere sagen würde, und nimm dann die entgegengesetzte Tür. Der Judge bescheinigt dem Modell saubere interne Logik. Was fehlt, ist der letzte, entscheidende Schritt vom richtigen Gedanken zur guten Antwort. Statt sauberer Verifikation, Struktur und begrifflicher Einordnung kommt nur eine knappe Endfassung heraus. Das ist kein Denkfehler. Es ist ein Präsentationsfehler bei einem Reasoning-Modell, und der wiegt schwerer, als es auf den ersten Blick scheint.
Dazu kommt ein strukturelles Problem bei der Sprachinstruktions-Compliance. Über mehrere Reasoning-Aufgaben antwortete das Modell trotz expliziter Deutschvorgabe auf Englisch. Das ist kein isolierter Ausreißer. Im metakognitiven Teil zeigt sich ein konsistentes Muster: Sobald Sprache, Format und Schlussfolgerung gleichzeitig gefragt sind, verliert DeepSeek R1 Distill Qwen 7B die Sprachvorgabe als erste Bedingung. In drei metakognitiven Aufgaben ignorierte es die explizite Sprachanweisung und antwortete auf Englisch. In produktiven Umgebungen mit fester Zielsprache ist das kein Schönheitsfehler, sondern ein Ausschlusskriterium.
Noch problematischer wird es dort, wo das Modell formal Erfolg meldet, aber keinen sichtbaren Text produziert. In einer Reasoning-Aufgabe wurde die Anfrage als abgeschlossen verbucht, obwohl kein auswertbarer Antworttext vorlag. Das bedeutet entweder einen internen Reasoning-only-Ausgang ohne sichtbares Ergebnis, eine stille Verweigerung oder einen Silent-Failure. Für den Nutzer macht das praktisch keinen Unterschied: Es war kein bewertbarer Output vorhanden.
Hinzu kommt ein reasoningspezifischer Grenzfall, der nicht als Defekt missverstanden werden darf, aber trotzdem produktrelevant ist. In einer Aufgabe wurden 25.000 interne Denk-Tokens verbraucht, sodass für sichtbare Ausgabe nichts mehr übrig blieb. Das ist keine inhaltliche Halluzination, sondern eine bekannte Eigenschaft mancher Reasoning-Modelle. Nur hilft dieser Befund dem Anwender wenig. Wer ein Modell fragt, will am Ende Text sehen, nicht nur das gute Gefühl, dass intern vielleicht etwas Kluges passiert ist.
Code Quality und Security
Im Security-nahen Code-Quality-Bereich zeigt DeepSeek R1 Distill Qwen 7B das vielleicht frustrierendste Profil des ganzen Tests. Es erkennt echte Probleme, aber viel zu wenige davon, und erklärt sie zu flach. Im vorliegenden Audit identifizierte das Modell sechs Schwachstellen, während der Golden Standard neunzehn relevante Punkte aufführt. Gerade bei impliziten oder subtilen Lücken, also den Fällen, in denen man ein Sicherheitsmodell wirklich braucht, geht ihm der Blick aus.
Das ist nicht einfach ein Mengenproblem. Die Qualität der Analyse bleibt hinter der Aufgabe zurück. SQL Injection wird erkannt, aber eher auf dem Niveau einer Checkliste. Angriffsketten fehlen. Begründungen bleiben vage. Konkrete Fixes werden in Sätzen wie „Prepared Statements nutzen“ angedeutet, aber nicht in belastbare Reparaturvorschläge übersetzt. Wer damit ein echtes Audit bestreiten wollte, bekäme keine Sicherheitsanalyse, sondern eine Sicherheits-Skizze.
Besonders bitter ist, dass genau in diesem Modul auch ein Fall ohne sichtbare Antwort auftrat. Eine Code-Quality-Aufgabe wurde als erfolgreich markiert, aber das Modell produzierte keinen auswertbaren Text. Auch hier gilt: möglicher interner Reasoning-only-Output, stille Verweigerung oder Silent-Failure. Für die Praxis ist alles davon unbrauchbar.
Dazu kommt ein weiterer reasoningspezifischer Budgetkonflikt. In einer Code-Quality-Aufgabe verdrängten 20.000 interne Denk-Tokens die sichtbare Ausgabe vollständig. Das ist als Modellcharakteristik erklärbar, als Werkzeugcharakter aber unerquicklich. Ein Security-Assistent, der seine Analyse im Kopf behält, ist kein Assistent.
Unterm Strich ist das für ein Edge-Reasoning-Modell ernüchternd. Man darf in dieser Größenklasse keine Forensik auf Serverniveau erwarten. Man darf aber erwarten, dass ein als reasoning-orientiert etikettiertes Modell mehr liefert als oberflächliche Treffer und generische Empfehlungen. Genau das tut DeepSeek R1 Distill Qwen 7B hier nicht.
CLI und Tool-nahe Aufgaben
Der CLI-Bereich ist oft der Ort, an dem kleine Modelle entweder angenehm präzise oder peinlich schwammig werden. DeepSeek R1 Distill Qwen 7B entscheidet sich zu oft für die dritte Option: gar nichts Sichtbares. In einer CLI-Aufgabe wurde Erfolg gemeldet, aber kein sichtbarer Antworttext produziert. Auch hier war für den Judge nichts bewertbar. Das ist für agentische oder teilautomatisierte Workflows besonders heikel, weil solche stillen Null-Antworten ohne zusätzliche Validierung leicht durchrutschen.
Der Tokenverbrauch im CLI-Modul ist zugleich grotesk hoch. Das Modell produziert durchschnittlich ein Vielfaches dessen, was andere Modelle für ähnliche Aufgaben brauchen. Wenn die Qualität parallel glänzen würde, könnte man über Ineffizienz reden. Da sie das nicht tut, bleibt vor allem der Eindruck eines Modells, das bei präzisen Ausführungsaufgaben den Faden verliert und den Leser mit der Rechnung sitzen lässt.
Content Transformation: viel Text, wenig Kontrolle
Nirgends tritt das Grundproblem dieses Modells brutaler zutage als im Content-Transformation-Modul. Hier scheitert DeepSeek R1 Distill Qwen 7B nicht nur qualitativ, sondern auch formal. In einer Aufgabe sollte es erst analysieren und dann eine Transformation in deutscher Sprache mit klarer Struktur und Wortgrenze liefern. Das sichtbare Ergebnis war überwiegend Englisch, ließ die explizit verlangte Analyse im Nutzertext aus und lief anschließend in massive Wiederholungsschleifen.
Das ist nicht bloß schwach. Das ist struktureller Kontrollverlust. Der Judge beschreibt algorithmisches Padding mit dutzendfach wiederholten Outro-Blöcken, minimal veränderten Zeitstempeln und mechanischem Füllmaterial. Der Text endet nicht mit einem gedanklichen Schlusspunkt, sondern bricht nach einer Endlosschleife technisch ab. Im Content-Transformation-Bereich bricht eine Ausgabe mitten in einer strukturierten Skriptsequenz ab. Die Antwort ist technisch abgebrochen, kein inhaltlicher Fehler. Der Abzug im Score resultiert aus der unvollständigen Antwort, nicht aus inhaltlichen Mängeln.
In derselben Aufgabe überschritt das Modell die explizite Wortvorgabe von 900 Wörtern um 368 Prozent beziehungsweise auf 4.216 Wörter. Das System verhängte dafür einen automatischen Abzug von 29,88 Punkten, also 60 Prozent auf den relevanten Teilscore. Die inhaltliche Qualität der Antwort ist damit irrelevant. Die Strafe greift unabhängig davon. Genau so muss ein Benchmark reagieren. Wer ein Limit um den Faktor 4,68 reißt, hat die Aufgabe nicht knapp verfehlt, sondern demonstrativ ignoriert.
Das Sprachversagen ist dabei kein isolierter Ausrutscher. Über mehrere Aufgaben im Content- und Dokumentationsbereich zeigt das Modell ein konsistentes Muster: Bei simultanen Vorgaben aus Sprache, Länge und Format verliert es die Sprachvorgabe als erste Bedingung. Im konkreten Transformationsfall antwortete es überwiegend auf Englisch, obwohl Deutsch Pflicht war. Das ist in Redaktions-, Marketing- oder Lernkontexten kein kleines Ärgernis. Es macht die Antwort direkt unbrauchbar.
UX Writing: verständlich, aber unterkomplex
Das UX-Writing-Modul zeigt die freundliche Seite des Modells, aber auch dort reicht Freundlichkeit nicht bis zur Exzellenz. Die Antworten sind lesbar, formal ordentlich und in Tabellenform strukturiert. Der Judge vergibt hier kein Totalausfallurteil, sondern eher ein schulisches „bemüht“. Das Kernproblem ist fehlende Tiefe. Psychologische Prinzipien werden behauptet, aber nicht sauber umgesetzt. Konkrete Beispiele fehlen. Fortschrittslogik bleibt Behauptung statt Interface-Mechanik. Das Modell liefert eine brauchbare Oberfläche, aber keine sorgfältig komponierte Nutzerführung.
Gerade weil die Instruct-Seite dieses Modells hier eigentlich glänzen könnte, wirkt das Ergebnis blasser als nötig. Zu kurz ist die Antwort nicht im Sinn guter Prägnanz, sondern im Sinn einer unterspezifizierten Bearbeitung. Das ist ein Unterschied, den gute Modelle kennen. Dieses hier kennt ihn nicht zuverlässig genug.
Dokumentation und Sprachdisziplin
Im Dokumentationsbereich setzt sich das Sprachproblem fort. In mindestens einer Aufgabe antwortete das Modell trotz expliziter Deutschvorgabe auf Englisch. Ein dokumentierter Einzelfall wäre ärgerlich. Hier ist es Teil eines größeren Musters. Das Modell zeigt keine katastrophale dokumentarische Unkenntnis, aber es verliert unter Mehrfachanforderungen regelmäßig den Gehorsam gegenüber der Zielsprache.
Für Teams, die interne Dokumentation, Betriebsanleitungen oder Kundenkommunikation in einer festen Sprache erzeugen, ist das ein reales Risiko. Die Qualität einer sachlich brauchbaren Antwort nützt wenig, wenn sie im falschen Sprachraum landet. Instruction-Following ist kein Bonusmerkmal. Es ist die Mindestvoraussetzung.
Cultural Intelligence
Im Cultural-Intelligence-Modul fällt das Urteil gemischt aus. Das Modell versucht, inklusive Sprache und Umformulierungen zu liefern, stolpert aber über Grammatik, Idiomatik und unnötige Meta-Kommentare. Besonders auffällig sind Formulierungen, die wie halbfertige Übersetzungsreste wirken. Ein Wort wie „Intellection“ in einem deutschen Rewriting ist nicht originell, sondern ein Produktionsfehler. Dazu kommen missglückte Konstruktionen und binäre Anreden dort, wo neutrale Formen nahegelegen hätten.
Immerhin: Hier zeigt sich kein kompletter Blindflug. Das Modell erkennt grob die Richtung einer inklusiveren Neufassung. Es verfehlt nur die sprachliche und stilistische Sicherheit, die für kulturell sensible Texte nötig wäre. Für grobe Vorentwürfe reicht das. Für veröffentlichungsreife Fassungen eher nicht.
Datenschutz und Datenhoheit
Da es sich hier um ein rein lokales Open-Weights-Modell handelt, steht nicht die Laufzeit-Infrastruktur eines Cloud-Providers im Zentrum, sondern die Provenienz der Gewichte. Die Lage ist nüchtern: MIT-Lizenz, kommerziell nutzbar, lokal ohne Cloud-Egress betreibbar. Das reduziert operative Datenschutzrisiken deutlich. Der Provenienzfaktor bleibt dennoch relevant, weil die Gewichte von DeepSeek stammen, der Entwickler in Hangzhou, China sitzt und das ausgewiesene Weights-Provenienz-Risiko bei MEDIUM liegt. Für regulierte Einsätze ist das kein pauschales Ausschlussurteil, aber ein Prüfpunkt für Beschaffung, Compliance und interne Freigaben.
Fazit
DeepSeek R1 Distill Qwen 7B ist ein interessantes Versprechen in einem zu kleinen Gehäuse. Als reasoning-orientiertes, lokales Edge-Modell mit dichten 7,6 Milliarden Parametern will es mehr sein als ein flotter Chatbot. Das respektiert man gern. Nur muss ein Modell mit diesem Anspruch seine Gedanken auch in brauchbare Endergebnisse übersetzen. Genau daran scheitert es im Benchmark zu oft. Sprachvorgaben kippen ins Englische, Wortlimits werden brutal ignoriert, Sicherheitsanalysen bleiben flach, und in mehreren Aufgaben gibt es gar keinen sichtbaren Output. Über alle Tests hinweg keine nennenswerten Halluzinationen. Das Modell erfindet lieber nichts, als sich zu blamieren. Leider liefert es dafür mitunter auch einfach nichts.
Für lokale Experimente, Lernzwecke und neugierige Nutzer mit Lust auf Reasoning-Charakter ist das Modell trotzdem nicht wertlos. Man sieht, was es sein will. Aber im Alltag zählt nicht der Wille, sondern die Ausführung. Wer ein verlässliches Edge-Modell für produktive Assistenz, Security-Reviews, strukturtreue Transformation oder sprachstrikte Workflows sucht, bekommt hier mehr Temperament als Präzision. Anders gesagt: ein Denker, der seine Hausaufgaben zu oft in der falschen Sprache und mit zu vielen Seiten abgibt.
Diese Auswertung wurde automatisch auf Grundlage der Benchmark-Daten generiert. Eingesetztes Modell: GPT-5.4 von OpenAI. Die Rohdaten und die vollständige Methodik sind im GitHub-Projekt dokumentiert.