DeepSeek R1 Distill Qwen 1.5B

Mit einem Gesamtscore von 35.41% zeigt DeepSeek R1 Distill Qwen 1.5B vor allem eines: Charakter ersetzt keine Reife. Als Reasoning-Modell in der Nano-Klasse mit 1,5 Milliarden Dense-Parametern ist es sichtbar auf mehrstufiges Denken getrimmt, im hier getesteten Standard-Modus aber zugleich auf direkte Instruktionsausführung beschränkt. Das Ergebnis ist ein eigentümlicher Mix aus Denkansatz, Formatschwäche und Sprachdisziplin, die regelmäßig schon an der ersten praktischen Hürde scheitert. Der Speed Profile Badge lautet Interactive DevOps Expert. Das verspricht einen eher interaktiven, zügigen Einsatzcharakter und passt zur Grundidee dieses lokalen Modells besser als seine tatsächliche Arbeitsqualität.

Kopfnoten: Stabilität und Zuverlässigkeit

Die Kopfnoten sind damit widersprüchlich auf eine unangenehme Weise. Im Mittel wirkt das Modell durchaus flink, an den Rändern aber reißt es den Arbeitsfluss auseinander. Für ein Nano-Modell ist genau das der Punkt, an dem die theoretische Leichtgewichtigkeit ihren Charme verliert. Wer einfache Autocomplete- oder Kleinstaufgaben erwartet, bekommt zwar oft schnell Text. Wer Verlässlichkeit in Agentenketten oder wiederholbaren Pipelines braucht, muss mit Nacharbeit und Wiederholungen rechnen.

Architektur und Charakter: Reasoning-Idee im Nano-Korsett

Die vorab vergebene Einordnung Reasoning, Instruct, Dense, Open-Weight, Local trifft den Kern erstaunlich präzise. Dieses Modell will denken, aber es lebt in einem Körper, der dafür eigentlich zu klein ist. Die Dense-Architektur bedeutet hier: Alle 1,5 Milliarden Parameter arbeiten bei jeder Anfrage mit. Es gibt also keinen MoE-Trick, keine versteckte Spezialökonomie, keine Ausrede über nominelle versus aktive Kapazität. Was man sieht, ist die volle Kapazität des Modells.

Als Use Case reasoning muss sich DeepSeek R1 Distill Qwen 1.5B daran messen lassen, ob seine zusätzlichen Denkanläufe zu besseren Antworten führen. Genau dort beginnt das Problem. Der Test lief ausdrücklich im Standard-Modus, also ohne aktivierten Thinking-Toggle. Das ist wichtig, weil kürzere und direktere Antworten hier kein Makel an sich sind. Nur rettet dieser Hinweis das Modell nicht aus seiner zentralen Schwäche: Es antwortet oft nicht knapp und präzise, sondern knapp und unzureichend. An mehreren Stellen sieht man, dass intern offenbar viel passiert, außen aber wenig Brauchbares ankommt. Das ist kein Zeichen souveräner Kompression, sondern eher das digitale Äquivalent eines Schülers, der lange auf das Blatt starrt und dann drei halbfertige Sätze abgibt.

Geschwindigkeit und Token-Profil

DeepSeek R1 Distill Qwen 1.5B wurde als LOKALES Modell nativ auf NVIDIA DGX Spark (GB10 Grace Blackwell Superchip, ~115 GB Unified Memory — kein praktisches Speicherlimit für getestete Modellgrößen) evaluiert. Sein Speed Profile Badge Interactive DevOps Expert signalisiert grundsätzlich ein Modell, das eher für unmittelbare Interaktion als für langes Batch-Schreiben gedacht ist. Im Alltag heißt das: Es wirkt oft reaktionsfreudig, produziert aber zugleich genug Ausschläge und Umwege, dass der nominell flotte Eindruck nicht in stabile Produktivität übersetzt wird.

Das Token-Profil verstärkt diesen Befund. Im CLI-Bereich produziert das Modell im Schnitt rund das Fünfzehnfache des Fleet-Medians. Auch Content Transformation und Code Quality liegen deutlich über dem Schnitt. Für ein lokales Modell sind solche Textmassen keine direkte Kostenfrage wie bei einer API, wohl aber ein handfester Latenztreiber. Mehr Text heißt hier schlicht mehr Wartezeit und mehr Fläche für Fehler. Besonders unerquicklich wird es, wenn diese Ausführlichkeit nicht mit besserer Qualität bezahlt wird. Genau das passiert hier mehrfach.

Code Quality und Security: Der Ehrgeiz ist da, die Präzision nicht

Im Sicherheits- und Code-Audit fällt das Modell nicht deshalb durch, weil es gar nichts erkennt. Es erkennt schon etwas. Nur eben zu wenig, zu flach und oft im falschen Gewand. In einem protokollierten Security-Review fand es zehn Schwachstellen, während die Referenz neunzehn sauber herausarbeitete. Kritische Themen wie IDOR, Session Fixation, CSRF, Cookie-Flags oder Reset-Token-Ablauf blieben ganz oder weitgehend liegen. Andere Schwachstellen wurden erfasst, aber technisch zu harmlos eingestuft. Path Traversal als „Low“ zu etikettieren, ist nicht bloß ein Ausrutscher. Es ist ein Urteil, das in der Praxis Schaden anrichtet.

Gerade bei Security ist das entscheidend. Ein Modell darf in diesem Bereich konservativ sein. Es darf lieber einmal zu viel warnen als einmal zu wenig. DeepSeek R1 Distill Qwen 1.5B leistet sich hier das Gegenteil: Es sieht bekannte Gefahren, aber ohne die notwendige Tiefenschärfe. Die Fix-Vorschläge bleiben generisch, konkrete Gegenmaßnahmen oder code-nahe Reparaturen fehlen oft. Das Modell klingt damit stellenweise wie jemand, der die Kapitelüberschriften eines OWASP-Artikels kennt, aber die Fußnoten nicht gelesen hat.

Hinzu kommt ein strukturelles Sprachproblem. Über mehrere Aufgaben im Code-Quality-Bereich ignorierte das Modell die explizite Sprachanweisung und antwortete auf Englisch. Das ist kein isolierter Patzer. Es ist ein konsistentes Muster: Bei gleichzeitigen Vorgaben aus Sprache, Struktur und Fachinhalt verliert das Modell die Sprachvorgabe als erste Bedingung. In produktiven Umgebungen mit deutscher Zielsprache ist das keine Stilfrage, sondern ein direkter Fehloutput.

In mehreren Code-Quality-Aufgaben griff deshalb ein automatischer Constraint-Abzug wegen falscher Ausgabesprache. Inhaltliche Teiltreffer zählen dann nur noch eingeschränkt, weil die Antwort bereits formal am Auftrag vorbeigeht. Der Richter war hier zu Recht unerbittlich. Wer eine deutsche Sicherheitsanalyse bestellt und englische Tabellenhälften bekommt, hat keine fertige Arbeitsgrundlage, sondern Rohmaterial.

CLI und Tool-Nähe: viel inneres Denken, kein sichtbares Ergebnis

Im CLI-Modul zeigt sich die Kehrseite eines kleinen Reasoning-Modells besonders scharf. Das Modell verbrannte sein Ausgabe-Kontingent durch interne Denkarbeit, bevor ein sichtbares Ergebnis beim Nutzer ankam. Eine Aufgabe wurde formal als erfolgreich abgeschlossen, produzierte aber gar keinen sichtbaren Antworttext. Für den Anwender ist das funktional identisch mit einem Fehlschlag. Ob intern gedacht, still verweigert oder schlicht ins Leere gelaufen wurde, ist zweitrangig. Es gab keinen beurteilbaren Output.

Dazu kommt ein regelbasierter Hard-Constraint-Befund: In einer CLI-Aufgabe haben Reasoning-Tokens das Output-Budget verdrängt. Das ist bei dieser Modellgattung kein exotischer Defekt, sondern ein realer Betriebscharakter. Für Leser heißt das übersetzt: Das Modell kann seine Energie im Maschinenraum verfeuern und oben auf Deck bleibt die Antwort aus. In Agenten-Setups ist genau das fatal, weil dort nicht der gute Wille zählt, sondern das sichtbare, parsebare Ergebnis.

Reasoning und Logik: Das Versprechen der Familie, nicht die Leistung dieses Laufs

Ein Reasoning-Modell in Nano-Größe muss nicht brillant sein. Aber es muss zeigen, dass sein Denken mehr ist als ein Dekorationsstück. In den Reasoning-Tests gelingt das nur unzuverlässig. Besonders aufschlussreich ist das klassische Wächter-Rätsel aus dem Metakognitions-Teil. Dort antwortete das Modell auf Englisch statt auf Deutsch und lieferte zudem eine logisch falsche Lösung. Die vorgeschlagene Frage erzeugte gerade nicht die behauptete Konsistenz zwischen Lügner und Wahrheitsredner. Der Richter rechnete das sauber durch. Das Modell fiel durch.

Das ist mehr als ein Einzelfehler. Es entlarvt die Grenze der Destillation. Die Familie trägt das Etikett „R1“, also die Aura eines Schlussfolgerungsmodells. Aber auf 1,5 Milliarden Parametern bleibt davon in diesem Lauf oft nur die Geste. Viel Denkaktivität, wenig belastbarer Endpunkt. Das Modell versucht, komplexe Logikräume zu betreten, hat aber sichtbar Mühe, sie sauber zu verlassen.

Dazu kommt erneut das Sprachmuster. Über mehrere Reasoning-Metakognitionsaufgaben hinweg ignorierte das Modell die deutsche Zielvorgabe und antwortete auf Englisch. Auch hier gilt: Das ist kein Ausreißer. Es ist strukturelle Instruktionsschwäche. Wer reasoning-starke Antworten in einer fest vorgegebenen Sprache braucht, bekommt hier keine verlässliche Maschine, sondern eine mit wechselndem Gehorsam.

In zwei Reasoning-Aufgaben kam noch ein schärferer Defekt hinzu. Das Modell meldete Erfolg, produzierte aber keinen sichtbaren Text. Gleichzeitig zeigen die Regelbefunde, dass interne Reasoning-Tokens das verfügbare Ausgabebudget vollständig verdrängten. Der Score leidet hier nicht an falschen Inhalten, sondern daran, dass für den Nutzer am Ende nichts auf dem Tisch lag. Ein Modell, das denkt und schweigt, hilft nur Philosophen.

UX Writing: überraschend schwach, obwohl die Aufgabe eigentlich instruktionsnah ist

Gerade weil DeepSeek R1 Distill Qwen 1.5B neben dem Reasoning-Tag auch als Instruct-Modell eingeordnet ist, schmerzt der UX-Bereich besonders. Solche Aufgaben verlangen keine enzyklopädische Weltkenntnis, sondern sauberes Befolgen von Struktur, Tonalität und Sprachvorgabe. Genau daran scheitert das Modell. In einem protokollierten UX-Task lieferte es statt einer geforderten Analyse plus optimierter Flows nur eine brüchige Tabelle mit repetitiven Füllphrasen. Psychologische Begründungen, also der eigentliche Mehrwert eines „Expert-Level“-UX-Outputs, fehlten komplett.

Der Richter formuliert es treffend: Das ist unterentwickelte Arbeit, nicht optimierte Kürze. Dieser Satz sitzt, weil er den Kern trifft. Ein kleines Modell darf knapp sein. Aber es darf nicht so tun, als sei Unvollständigkeit eine Designentscheidung. Hier fehlen Analysephase, Tiefgang und oft auch sprachliche Sauberkeit.

Auch im UX-Modul trat die Sprachvorgabe nicht zuverlässig durch. In zwei Aufgaben antwortete das Modell auf Englisch statt auf Deutsch. Das ist im Produktiveinsatz ohne Nachkontrolle sofort ein Ausschlusskriterium. UX-Text ist keine Rohware, die man später mit einem Übersetzer glattzieht. Ton, Rhythmus und Mikroentscheidungen hängen an der Zielsprache.

Content Transformation: Formwillen ohne Regiegefühl

Im Bereich Content Transformation ist das Modell interessanter als in UX, aber nicht besser. Es versucht sichtbar, Skripte und Transformationsaufgaben zu strukturieren. Das Problem ist nur, dass es zentrale Pflichtelemente liegen lässt. In einem Videodrehbuch-Task fehlte die vorgeschriebene Analysephase vollständig. Die Antwort sprang direkt in eine unvollständige Transformation, dazu auf Englisch statt auf Deutsch. Einzelne Produktionsmarker waren vorhanden, aber der Gesamttext war nicht sendefähig, eher ein Storyboard-Fragment im Entwurfsmodus.

Das Längenproblem ist hier kein einzelner Unfall. Über mehrere Aufgaben im Content-Transformation-Modul zeigt das Modell ein konsistentes Muster: Bei simultanen Vorgaben aus Sprache, Länge und Format verliert es die Sprachvorgabe als erste Bedingung. Vier dokumentierte Sprachfehler in diesem Modul sind kein statistisches Rauschen, sondern ein klares Architektur- und Feintuning-Signal.

Auch tokenökonomisch ist dieser Bereich unerquicklich. Das Modell produziert fast doppelt so viel Text wie der Flottenmedian, ohne dafür sichtbar mehr Präzision oder Kreativität zu liefern. Das ist die schlechteste Art von Ausführlichkeit: Sie kostet Zeit, aber rettet die Antwort nicht.

Documentation Quality: formal brauchbar, sprachlich wacklig

Dokumentationsaufgaben liegen dem Modell etwas besser als UX oder strenge Sicherheitsanalysen, aber auch hier zieht sich der rote Faden durch: inhaltlich manchmal brauchbarer Ansatz, formale und sprachliche Disziplin unzuverlässig. In vier dokumentierten Dokumentationsaufgaben ignorierte das Modell die explizite Sprachanweisung und antwortete auf Englisch. Damit wird aus einem potenziell nützlichen Entwurf sofort ein Nachbearbeitungsfall.

Das Sprachversagen ist kein isolierter Ausreißer. Über mehrere Aufgaben im Documentation-Quality-Bereich zeigt das Modell ein konsistentes Muster: Bei gleichzeitigen Anforderungen aus Fachsprache, Format und Zielidiom verliert es die Sprachvorgabe zuerst. Für interne Notizen mag das noch tolerierbar sein. Für veröffentlichungsreife Doku ist es Gift. Dokumentation lebt von Verlässlichkeit. Dieses Modell liefert eher Material als Ergebnis.

Cultural Intelligence: ein Lichtblick, aber ein schmutziger

Der Cultural-Intelligence-Bereich ist einer der wenigen Orte, an denen das Modell wenigstens partiell zeigt, was seine Grundidee sein könnte: Es erkennt die Stoßrichtung einer Aufgabe und versucht, toxische oder ausgrenzende Sprache umzubauen. Der Haken ist nur, dass der Umbau sprachlich entgleist. Ein protokolliertes Beispiel einer Stellenanzeige mutierte zu einem Text voller Fantasiewörter, Grammatikbrüche und englischer Einschübe. Formal war das Deutsch. Praktisch war es unbrauchbar.

Das ist ein bemerkenswertes Muster: Das Modell halluziniert hier nicht im klassischen Sinne faktenfrei ins Leere. Es produziert vielmehr sprachliche Trümmer aus halb verstandenen Versatzstücken. Das ist fast schlimmer, weil es auf den ersten Blick wie Bearbeitung aussieht, beim Lesen aber in sich zusammenfällt. Immerhin bleibt ein kleiner Respektpunkt: Das Modell versucht, problematische Tonlagen überhaupt anzufassen. Nur fehlt ihm in dieser Größenklasse oft die sprachliche Kontrolle, um daraus publizierbaren Text zu machen.

Datenschutz und Datenhoheit

Da es sich hier um ein rein lokal betriebenes Open-Weights-Modell handelt, steht nicht die Laufzeitdatenverarbeitung eines Cloud-Providers im Vordergrund, sondern die Herkunft der Gewichte. Die Gewichte stammen aus der DeepSeek-/Unsloth-Linie, der Entwicklerkontext liegt in China, das Weights-Provenienz-Risiko ist mit MEDIUM markiert. Für regulierte Umgebungen in Deutschland und der EU ist das kein automatisches Ausschlusskriterium, aber ein Prüfpunkt: Nicht die Ausführung, sondern die Herkunft der Modellartefakte ist hier die relevante Souveränitätsfrage.

Fazit

DeepSeek R1 Distill Qwen 1.5B ist ein faszinierendes kleines Modell, aber kein gutes. Es trägt die Gestik eines Schlussfolgerers, den Befehlston eines Instruct-Modells und die praktische Freiheit offener Gewichte in sich. Nur setzt es diese Anlagen im Benchmark zu selten in belastbare Ergebnisse um. Die Sprachinstruktions-Compliance ist über gleich mehrere Module hinweg schwach. Security-Analysen bleiben oberflächlich. Reasoning verpufft teils im Off, ohne sichtbaren Nutztext zu hinterlassen. Für ein Nano-Modell ist manches davon entschuldbar. Die Summe ist es nicht.

Sein sinnvoller Einsatzbereich liegt deshalb eng gefasst: lokale Experimente, Embedded-nahe Szenarien, einfache Einzelschritte, vielleicht als billiger Denkansatz vor einem stärkeren Prüfer. Nicht geeignet ist es für unbeaufsichtigte Agenten, produktive Sicherheitsanalysen, deutschsprachige Publishing-Workflows oder Aufgaben, bei denen Format- und Sprachtreue nicht verhandelbar sind. Über alle Tests hinweg keine nennenswerten Halluzinationen. Das Modell erfindet lieber wenig als überzeugend falsch, scheitert dafür aber oft schon an Sprache, Tiefe oder Vollständigkeit. Im Vergleich zu größeren Läufen derselben Distill-Familie bleibt hier vor allem die Erkenntnis: Man kann Reasoning erstaunlich weit schrumpfen. Man kann es dabei aber auch ausdünnen, bis nur noch die Pose übrig bleibt.

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.