Llama 3.2 3B (Unsloth)

Mit einem Gesamtscore von 52.05% bleibt Llama 3.2 3B (Unsloth) klar in der Zone der brauchbaren Kleinarbeit, aber nicht der souveränen Gesamtleistung. Der Speed Profile Badge „Real-Time DevOps Expert“ signalisiert hohe Reaktionsfreude und tatsächlich wirkt das Modell im Alltagstempo eher flink als schwerfällig. Inhaltlich ist das Bild deutlich rauer: Für ein Nano-Generalist-Modell mit 3,21 Milliarden dichten Parametern und Instruct-Charakter ist die Direktheit erwartbar, doch die vorab vergebene Thinking-Einstufung wirkt in diesem konkreten Lauf eher wie ein Versprechen auf der Verpackung als wie gelebte Praxis, zumal der Test ausdrücklich im Standard-Modus ohne aktiviertes Thinking lief.

Kopfnoten: Stabilität und Zuverlässigkeit

Die Kopfnoten sind für ein lokales Nano-Modell fast die wichtigste gute Nachricht. Wer kleine Modelle einsetzt, will keine Diva, sondern ein Werkzeug. Genau das liefert Llama 3.2 3B (Unsloth) hier: keine Aussetzer, keine Stillstände, kein Nervenzusammenbruch unter Last. Das hebt den praktischen Wert spürbar, auch wenn es die Qualitätsdefizite natürlich nicht wegdiskutiert.

Architektur, Anspruch und was man diesem Modell fairerweise abverlangen darf

Die kuratierte Einordnung ist hier mehr als Etikett. Llama 3.2 3B (Unsloth) ist ein Generalist, also kein Spezialwerkzeug für Code, keine reine Reasoning-Maschine und kein multimodales System. Es gehört zur Nano-Klasse, also in jene Gewichtsklasse, in der man Effizienz, lokale Nutzbarkeit und brauchbares Instruction-Following erwarten darf, aber kein tiefes Weltwissen und keine belastbare Meisterschaft in mehrstufigen Aufgaben. Dazu kommt eine Dense-Architektur: Alle 3,21 Milliarden Parameter sind bei jeder Antwort aktiv. Es gibt hier keinen MoE-Trick, der eine größere Modellillusion erzeugt. Was man bekommt, ist genau die Kapazität, die auf dem Datenblatt steht.

Die Tags Thinking und Instruct erzeugen dabei eine interessante Spannung. Instruct passt gut zum beobachteten Verhalten: Das Modell antwortet kompakt, oft regelorientiert, manchmal zu schematisch. Thinking dagegen muss man in diesem Bericht sofort relativieren. Dieser Lauf fand im Standard-Modus statt, also mit deaktiviertem Thinking. Kürzere, direkte Antworten sind in diesem Setup kein Makel, sondern der definierte Betriebszustand. Das Problem ist nicht, dass Llama hier kurz antwortet. Das Problem ist, dass es selbst innerhalb dieser Kürze bei Logik, Priorisierung und Detailtreue zu oft auf halber Strecke stehen bleibt.

Geschwindigkeit und Token-Ökonomie

Als lokales Modell lief Llama 3.2 3B (Unsloth) auf einem NVIDIA DGX Spark (GB10 Grace Blackwell Superchip, ~115 GB Unified Memory — kein praktisches Speicherlimit für getestete Modellgrößen). Der Badge „Real-Time DevOps Expert“ passt zum Charakter dieses Laufs: Das Modell generiert sichtbar schnell genug für interaktive Nutzung, kurze Rückfragen und einfache Redaktions- oder Entwicklerdialoge. Es ist kein Batch-Arbeiter für lange Denksessions, sondern eher der flinke Schreibtischgehilfe.

Wichtig ist dabei die Token-Ökonomie. Llama 3.2 3B (Unsloth) verhält sich insgesamt token-ökonomisch. Kein Modul überschreitet den erwarteten Verbosity-Rahmen. Im Gegenteil: In allen gemessenen Modulen bleibt es unter dem Fleet-Median, teils deutlich. Das ist bei einem lokalen Modell nicht nur ein Schönheitswert, sondern direkt ein Nutzwert. Weniger Text bedeutet hier meist auch weniger Wartezeit. Die Kehrseite ist allerdings sichtbar: Gerade in Code Quality, Documentation und Reasoning wirkt die Kürze nicht elegant verdichtet, sondern substanziell ausgehungert. Dieses Modell spart nicht nur Worte. Es spart zu oft auch die entscheidenden Details.

Code Quality: sauber formatiert, fachlich zu dünn

Der Code-Quality-Wert von 46.8 ist kein Betriebsunfall, sondern eine treffende Zusammenfassung des Charakters. Llama 3.2 3B (Unsloth) kann Sicherheitsprobleme anreißen, Tabellen formatieren und offensichtliche Schwachstellen benennen. Es erkennt SQL Injection, XSS und einige weiterführende Themen. Das ist für 3,21 Milliarden Parameter nicht nichts. Aber man sollte aus dieser Oberfläche keine Tiefe herbeifantasieren.

Das qualitative Protokoll zeigt die Schwäche sehr klar. In einer Sicherheitsanalyse listet das Modell 9 Schwachstellen, während der Referenzstandard 19 identifiziert. Es verfehlt also mehr als die Hälfte des Problemspektrums. Noch gravierender: Es klassifiziert mehrere Funde falsch. Ein clientseitig manipulierbares Admin-Flag wird heruntergestuft, Type-Juggling beim API-Key wird in seiner Kritikalität verkannt, Klartextpasswörter und Path Traversal werden zu milde bewertet. Das sind keine kosmetischen Fehler. In der Security-Praxis führen genau solche Fehleinschätzungen dazu, dass Teams die falschen Baustellen zuerst schließen.

Auch bei den Fixes bleibt das Modell auf Formularniveau. „Prepared Statements“, „Sanitization“, „Admin-Flag-Verwaltung“: Das klingt nach Security, ist aber oft nur die Beschriftung des Werkzeugkastens, nicht die Reparatur selbst. Konkrete Gegenmaßnahmen, Angriffsketten oder belastbare Priorisierung fehlen. Wer damit echten Code härten will, braucht zwingend eine zweite Instanz mit mehr technischer Reichweite. Kurz gesagt: Das Modell sieht, dass das Haus brennt. Es sagt aber nicht zuverlässig, in welchem Stockwerk und womit man löschen sollte.

Reasoning und Logik: sichtbar bemüht, nicht belastbar

Der Logical-Reasoning-Wert von 45.05 ist schwach und die Protokolle erklären warum. Bei einem klassischen Wächter-Rätsel liefert das Modell zwar eine formal ordentlich strukturierte Antwort in Deutsch und benutzt sogar die geforderten <thought>-Tags. Das ist wichtig, weil es zeigt: Hier liegt kein Compliance- oder Formatproblem vor. Das Problem ist die Logik selbst.

Statt der bekannten, robusten Meta-Frage an einen der Wächter schlägt das Modell sinngemäß vor: „Wenn ich die andere Tür öffne, werde ich dann sterben?“ Das ist keine raffinierte Alternative, sondern schlicht die falsche Frage. Sie liefert keine garantierte Desambiguierung zwischen Lügner und Wahrheitsredner. Das Modell behauptet Selbstsicherheit, ohne die beiden Fälle sauber durchzuprüfen. Genau dort trennt sich echtes Schlussfolgern von plausibel klingender Improvisation.

Für die zugewiesene Thinking-Kategorie ist das ernüchternd, auch wenn man den Standard-Modus fair einpreisen muss. Die Benchmark bestraft hier nicht, dass das Modell kurz ist. Sie bestraft, dass die Kürze nicht trägt. Ein gutes kleines Modell muss nicht ausufernd denken. Es muss aber auf Kernfragen korrekt denken. Llama 3.2 3B (Unsloth) liefert in Logikaufgaben zu oft den Tonfall von Gewissheit ohne die Statik der Argumentation. Das ist die gefährlichste Form des Fehlers, weil sie auf den ersten Blick kompetent wirkt.

Content Transformation: brauchbare Struktur, schwache Redaktion

Im Bereich Content Transformation erreicht das Modell 60.97 und damit einen seiner besseren Werte. Das passt zum Profil: Zusammenfassen, Umformulieren, grob strukturieren, solche Arbeiten liegen kompakten Instruct-Modellen eher als Tiefenanalysen. Aber auch hier sollte man das Ergebnis nicht mit Professionalität verwechseln.

Das vorliegende Videoskript-Protokoll zeigt einen typischen Nano-Kompromiss. Llama 3.2 3B (Unsloth) versteht die Aufgabe grundsätzlich. Es liefert Analyse, Timestamps, Produktionshinweise, Hook, CTA und sogar ein Easter Egg. Nur wirken diese Elemente oft wie Pflichtfelder in einer Maske, nicht wie Bestandteile einer überzeugenden Dramaturgie. Der Judge kritisiert widersprüchliche Zeitmarken, generische Regiehinweise, formale statt gesprochene Sprache und eine emotionale Flachlage, die für Videoformate fatal ist. Ein Satz wie eine Bedienungsanleitung spricht nicht plötzlich zu Menschen, nur weil man ihm einen Zeitcode davorsetzt.

Hinzu kommt ein strukturelles Längenproblem. In einer Aufgabe im Content-Transformation-Bereich überschritt das Modell die explizite Wortvorgabe von 250 Wörtern auf 369 Wörter, also 148% des Limits. Das System verhängte dafür einen automatischen Abzug von 20% beziehungsweise -11.84 Punkten auf den erzielten Score. Die inhaltliche Qualität der Antwort ist damit irrelevant. Die Strafe greift unabhängig davon. Das Wortlimit ist hier kein dekorativer Hinweis, sondern Teil der Aufgabe.

Dieses Längenproblem ist kein isolierter Ausreißer. Zusammen mit dem UX-Bereich zeigt das Modell ein konsistentes Muster: Bei simultanen Vorgaben aus Sprache, Format und Länge verliert es das Wortlimit als erste Bedingung. Gerade bei Nano-Modellen ist das nicht untypisch. Aber typisch heißt nicht harmlos. In Redaktions- und Agenten-Workflows scheitert so etwas unmittelbar.

UX Writing: ordentliches Handwerk mit einem Hang zum Überziehen

Der UX-Writing-Wert von 54.15 ist mittelmäßig, aber weniger trostlos als manche anderen Disziplinen. Das Modell kann Mikrocopy strukturieren, Tabellen bauen und Aufgaben formal ordentlich anlegen. In den gelieferten Fragmenten sieht man, dass es Schrittfolgen und Progressive Disclosure zumindest erkennt. Das ist für kurze Interface-Texte und erste Entwürfe durchaus brauchbar.

Aber auch hier greift die harte Realität der Constraints. In einer Aufgabe im UX-Writing-Bereich überschritt das Modell die explizite Wortvorgabe von 350 Wörtern auf 442 Wörter, also 126% des Limits. Das System verhängte einen automatischen Abzug von 20% beziehungsweise -11.00 Punkten. Auch hier gilt: Wer die Längenvorgabe reißt, fällt durch, selbst wenn der Text sonst akzeptabel wäre. Für Produktteams ist das relevant, weil Mikrocopy gerade nicht nach dem Prinzip „ein bisschen mehr ist doch okay“ funktioniert. Ein Dialogfeld hat keine Geduld.

Man kann dieses Verhalten als Schwäche kleiner Instruct-Modelle lesen, und das wäre nicht falsch. Sie priorisieren oft die semantische Erledigung der Aufgabe höher als die präzise Einhaltung mehrerer Nebenbedingungen zugleich. Nur hilft diese Erklärung dem Nutzer wenig. Wenn Text in ein UI passen muss, ist ein verfehltes Wortlimit kein philosophisches Problem, sondern ein kaputtes Ticket.

Documentation Quality: Informationswillig, aber nicht sattelfest

Der Wert von 43.29 in Documentation Quality gehört zu den schwächeren Bereichen und das überrascht nicht. Gute technische Dokumentation verlangt nicht nur Sprachkompetenz, sondern auch Hierarchisierung, Präzision, Verzicht auf Leerstellen und die Fähigkeit, den Leser an der richtigen Stelle abzuholen. Genau diese Mischung ist für Nano-Generalisten schwer.

Die Protokollfragmente deuten auf ein wiederkehrendes Muster: Das Modell versteht ungefähr, was dokumentiert werden soll, aber nicht zuverlässig, wie tief, wie operational und wie belastbar. Es liefert häufig eine brauchbare Hülle. Was fehlt, ist die letzte Schicht aus Vollständigkeit, Priorisierung und konkreter Umsetzbarkeit. Für interne Notizen oder eine erste Rohfassung mag das reichen. Für veröffentlichungsreife technische Dokumentation nicht.

Cultural Intelligence: gute Absicht, schlechte Ausführung

Mit 57.3 steht Cultural Intelligence besser da als Reasoning oder Documentation, aber der qualitative Befund ist härter als die Zahl. Besonders aufschlussreich ist die deutsche Aufgabe, in der problematische Sprache aus einer Stellenanzeige in inklusive Form überführt werden sollte. Das Modell verweigert die Bearbeitung komplett und antwortet sinngemäß, es könne nicht bei diskriminierenden oder herabwürdigenden Inhalten helfen.

Das ist ein klassischer Fehlgriff übervorsichtiger Safety-Muster. Die Aufgabe bestand gerade darin, toxische Sprache zu entfernen. Das Modell verwechselt Sanierung mit Verbreitung des Problems. Für produktive Textarbeit ist das unerquicklich, weil es legitime Redaktionsarbeit blockiert. Die eigentliche Pointe ist bitter: Das Modell scheitert nicht an Bosheit, sondern an moralischer Kurzschlusslogik. Gute Absicht, null Nutzwert.

Tool Execution, Security und Halluzinationen: hier wird es ernst

Der ToolUse-Score von 31.67 ist schwach, und die automatische Violation-Zusammenfassung macht unmissverständlich klar, warum. In zwei Tool-Use-Aufgaben halluzinierte das Modell Inhalte, die nicht aus dem abgerufenen Tool-Ergebnis stammten, sondern erfunden waren. Das System kappte den P2-Score per Halluzinations-Cap. Für content-kritische Aufgaben wie Recherche, Faktenberichte oder toolgestützte Auswertung ist das ein disqualifizierendes Signal.

Datenschutz und Datenhoheit

Ein eigener Datenschutzblock ist hier nicht nötig, weil Llama 3.2 3B (Unsloth) lokal mit eigenen Gewichten betrieben wird und nicht über einen Cloud-Provider lief. Für die Provenienz bleibt der Befund sachlich günstig: Das Weights-Provenienz-Risiko ist als LOW ausgewiesen, die Gewichte stammen aus der Meta-Llama-Linie in einem Unsloth-Build. Der relevante Vorbehalt liegt weniger in der Datenabflussfrage als in der Lizenznatur: Die Llama 3.2 Community License erlaubt kommerzielle Nutzung, ist aber ausdrücklich restricted-weights und eben nicht OSI-offen.

Fazit

Llama 3.2 3B (Unsloth) ist ein kleines lokales Modell mit klar erkennbarem Nutzwert und ebenso klaren Grenzen. Es reagiert schnell, läuft auf dem Testsystem stabil und arbeitet token-sparsam. Für einfache Umformulierungen, kurze Hilfstexte, schnelle Drafts und unkomplizierte Assistenzaufgaben ist das ein durchaus vernünftiger Kandidat. Wer ein Nano-Modell für offlinefähige Alltagsarbeit sucht, bekommt hier kein Wunder, aber ein Werkzeug.

Sobald Aufgaben aber mehrere Bedingungen gleichzeitig einfordern, kippt das Bild. Logik ist fragil, Security-Urteile sind lückenhaft, kulturell sensible Transformationen können in Verweigerung umschlagen, und bei toolgebundenen Faktenaufgaben halluziniert das Modell in einer Weise, die man nicht wegerklären sollte. Dazu kommen wiederholte Wortlimit-Verstöße mit automatischen Score-Strafen. Das ist kein pedantischer Nebenschauplatz, sondern ein echter Workflow-Schaden.

Unterm Strich ist Llama 3.2 3B (Unsloth) ein typischer Nano-Generalist mit sympathischer Laufkultur und begrenzter geistiger Reichweite. Für Edge-nahe, lokale Assistenz okay. Für Security-Analysen, belastbares Reasoning, redaktionell heikle Umschreibungen oder toolkritische Produktionspfade zu riskant. Dieses Modell arbeitet flott und höflich. Es arbeitet nur nicht oft genug tief genug.

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.