Llama 3.2 1B (Unsloth)

Llama 3.2 1B ist Metas kleinstes Llama-3.2-Modell und ein reines Text-only-Baseline für Edge-Setups. 1,23 Mrd. Dense-Parameter, 128.000 Tokens Kontext, lokal als Unsloth-GGUF betreibbar unter der Llama-3.2-Community-Lizenz. Eignet sich als kompakte On-Device-Referenz, nicht als Qualitätsanker.

Meta Version 3.2 Kommerzielle Nutzung erlaubt Dense 1.23 B (1.23 B aktiv) 128 K Context 12/2023 local getestet

  • Restricted Weights
  • Nano
  • llama.cpp
  • Text
  • Instruction-Tuned
  • Restricted-Weights
  • Real-Time

Sovereign Risk: LOW TODO

LLM Model Review

Erstellt am · Instruction-Tuned · Restricted-Weights

Mit einem Gesamtscore von 44,35 Prozent und dem Speed Profile Badge Real-Time DevOps Expert zeigt Llama 3.2 1B (Unsloth) vor allem eines: Tempo ist hier keine Auszeichnung für Reife, sondern ein Hinweis auf geringe Modellmasse. Dieses Modell ist ein Generalist der Nano-Klasse mit 1,23 Milliarden Dense-Parametern. Also ein Kleinstmodell, bei dem alle Gewichte pro Anfrage aktiv sind und dessen Grenzen nicht wegdiskutiert werden können. Im konkreten Benchmark lief es im Standard-Modus, also mit deaktiviertem Thinking. Kürzere, direktere Antworten sind daher erwartbar. Was nicht erwartbar sein sollte, sind die inhaltlichen Einbrüche bei Logik, Sicherheit und präziser Aufgabenbefolgung.

Kopfnoten: Stabilität und Zuverlässigkeit

Metrik Wert Bewertung Analyse
Timeout-Rate 4/43 Sporadisch Das Modell zeigt sporadische Aussetzer, die in der Praxis Retrys erfordern würden.
P95-Antwortzeit 156.84 s Kritisch Extreme Tail-Latenz. Das Modell streut massiv und ist für zeitkritische Prozesse ungeeignet.

Diese Kopfnoten sind für ein Nano-Modell der eigentliche Warnhinweis. Man verzeiht einem 1B-Modell begrenztes Weltwissen. Man verzeiht ihm auch, dass mehrstufige Instruktionen mit Sprache, Länge und Format gleichzeitig schwierig werden. Aber Aussetzer plus kritische Streuung im Antwortverhalten machen aus einem kleinen Assistenten schnell einen unzuverlässigen. Für einfache Edge-Aufgaben mag das noch reichen. Für unbeaufsichtigte Agentenketten ist es zu fragil.

Architektur und Erwartungsrahmen

Die vorab vergebene Kategorie ist auf den ersten Blick widersprüchlich und auf den zweiten sehr aufschlussreich. Thinking beschreibt die grundsätzliche Anlage des Modells, nicht den tatsächlich getesteten Lauf. Der hier ausgewertete Durchgang lief ausdrücklich im Standard-Modus. Sichtbare Denkspuren oder lange Begründungsketten durfte man also nicht erwarten. Instruct passt deutlich besser zum Charakter dieses Laufs: Das Modell antwortet direkt, oft kurz, manchmal zu kurz, und verliert dabei regelmäßig die Tiefe.

Dazu kommt die Physik der Klasse. Ein Generalist in der Nano-Kategorie ist kein kleiner Frontier-Ersatz, sondern eher ein Taschenmesser mit stumpfer Klinge. Dass Llama 3.2 1B (Unsloth) als Dense-Modell seine vollständigen 1,23 Milliarden Parameter pro Antwort nutzt, hilft bei Vorhersagbarkeit. Es schafft aber keine Wunder. Wer hier tiefes Reasoning, belastbare Sicherheitsanalyse oder textliche Feinarbeit auf höherem Niveau erwartet, verwechselt Portabilität mit Kompetenz.

Geschwindigkeit und Laufcharakter

Als lokales Modell wurde Llama 3.2 1B (Unsloth) nativ auf NVIDIA DGX Spark (GB10 Grace Blackwell Superchip, ~115 GB Unified Memory — kein praktisches Speicherlimit für getestete Modellgrößen) evaluiert. Der Badge Real-Time DevOps Expert signalisiert einen klaren Nutzungscharakter: hohe Generierungsgeschwindigkeit, gedacht für schnelle Interaktion, kurze Schleifen, unmittelbare Reaktion. Genau so fühlt sich das Modell auch an. Es ist auf dem Testsystem sichtbar schnell und im Mittel reaktiv.

Der Haken ist nur: Schnelligkeit allein ist hier oft die freundliche Verpackung für dünne Antworten. Besonders deutlich wird das dort, wo Qualität eigentlich aus Präzision entstehen müsste. Das Modell schreibt zügig, aber nicht zuverlässig scharf. Im Alltag heißt das: gut für schnellen Erstaufschlag, schlecht als letzte Instanz.

Code Quality: Sicherheit erkannt, aber nur in groben Umrissen

Im Code-Quality-Modul offenbart Llama 3.2 1B (Unsloth) seinen vielleicht wichtigsten Charakterzug: Es erkennt die lauten Probleme, scheitert aber an stillen, gefährlichen Details. SQL Injection, Klartext-Passwörter, Path Traversal, cookiebasierte Admin-Authentifizierung oder IDOR werden zumindest teilweise gefunden. Das ist für 1,23 Milliarden Parameter nicht nichts. Aber der Respekt endet dort, wo echte Sicherheitsarbeit beginnt.

Denn was fehlt, ist genau das, was ein Security-Review vom Schlagwort-Bingo trennt: Typ-Juggling, Session Fixation, XSS in der Begrüßung, schwache Reset-Tokens, fehlende Cookie-Flags, CSRF, Header-Injection, hartkodierte Secrets. Der Richter beschreibt das treffend als oberflächliches Verständnis von PHP-Sicherheit. Noch unangenehmer sind die falschen Reparaturen. Teilweise präsentiert das Modell als Fix praktisch unveränderten Originalcode. Das ist nicht nur unpräzise, sondern im Sicherheitskontext brandgefährlich, weil es Kompetenz simuliert.

Auch bei der Schweregradeinstufung patzt das Modell. Kritische Probleme werden zu Low oder Medium heruntergestuft. Gerade bei Admin-Cookie-Authentifizierung und IDOR ist das kein Schönheitsfehler, sondern ein Urteil mit Folgen. Wer so priorisiert, baut den Incident gleich mit ins Ticket-System ein.

Hinzu kommt ein klares Effizienzproblem. Im Code-Quality-Bereich produziert das Modell durchschnittlich 17.193 Tokens bei einem Fleet-Median von 3.103. Das entspricht dem 5,54-Fachen des Feldes und liegt deutlich über dem Budget. Für ein lokales Modell ist das vor allem ein Latenzsignal. Das Modell schreibt sich hier lang und wird dabei nicht besser. Es redet sich nicht zum Ziel, sondern am Ziel vorbei.

Logik und Reasoning: sichtbar bemüht, sachlich falsch

Im Reasoning-Modul wird die Schwäche unübersehbar. Ausgerechnet bei einer klassischen Wächter-und-Türen-Aufgabe scheitert das Modell an der Grundbedingung des Rätsels. Es nimmt an, man könne den Wahrheitswächter identifizieren und direkt befragen. Genau das darf man nicht. Der Fehler ist nicht subtil. Er zerstört die Lösung.

Das ist der Moment, in dem man der Kategorie Thinking die kalte Schulter zeigen muss. Als Architektur-Tag mag das Modell dafür vorbereitet sein. In diesem Testlauf, mit deaktiviertem Thinking, sieht man davon wenig. Und selbst unter diesem Vorbehalt bleibt der Befund hart: Das Modell produziert inhaltlich falsches Reasoning mit repetitiven Schleifen. Es denkt nicht zu kurz. Es denkt im Kreis.

Bemerkenswert ist dabei, dass die Antwort nicht an Sprachversagen oder völliger Aufgabenverweigerung scheitert. Deutsch passt, Strukturversuch ist da, <thought>-Tags werden verwendet. Nur der logische Kern fehlt. Genau das macht den Fehler so unerquicklich. Die Form stimmt genug, um Vertrauen zu erzeugen. Der Inhalt verdient es nicht.

UX Writing: brauchbare Oberfläche, schwaches Verständnis für den Menschen dahinter

UX Writing ist bei kleinen Modellen oft ein guter Lackmustest. Nicht weil es poetisches Talent verlangt, sondern weil mehrere Bedingungen zugleich erfüllt werden müssen: Zielgruppe, Ton, Kürze, Informationsarchitektur, psychologische Stringenz. Llama 3.2 1B (Unsloth) kommt hier über ein solides Minimum kaum hinaus.

Der Richter kritisiert zu Recht die fehlende Tiefe der Analyse. Vier Probleme werden benannt, wo die Referenz acht aufdröselt. Das ließe sich noch als Nano-Limit verbuchen. Schwerer wiegt die falsche psychologische Begründung. Der Endowed Progress Effect wird schlicht falsch erklärt. Statt künstlich erzeugten Fortschritts als Motivationshebel behauptet das Modell sinngemäß, Menschen seien motivierter, wenn sie bereits Erfahrung mit dem Prozess hätten. Das ist inhaltlich falsch. Für UX-Arbeit, die auf Verhaltenspsychologie gestützt sein soll, ist das ein Loch im Fundament.

Dazu kommt ein handwerkliches Problem: Die Beispiele bleiben generisch. Wo gute Microcopy konkrete, erkennbare Nutzersituationen zeigt, liefert das Modell Floskeln wie „Routineaufgaben automatisieren“. Das klingt nach Produktpräsentation aus dem Konferenzraum, nicht nach Text aus einer realen Oberfläche. Auch der Ton sitzt nicht. Teilweise mischt das Modell höfliche und uneinheitliche Ansprache, teilweise erklärt es über den Text, statt ihn direkt zu schreiben. Gute UI-Texte klingen nicht wie ein Kommentar zu sich selbst.

In einer Aufgabe im UX-Writing-Bereich überschritt das Modell die explizite Wortvorgabe von 350 um 132 Prozent auf 811 Wörter. Das System verhängte einen automatischen Abzug von 22,00 Punkten beziehungsweise 40 Prozent. Die inhaltliche Qualität der Antwort ist damit irrelevant. Die Strafe greift unabhängig davon. Für die Praxis ist das wichtig: Wer Längenlimits für App-Screens, E-Mails oder Banner einhalten muss, kann sich auf dieses Modell nicht blind verlassen.

Content Transformation: Struktur da, Substanz fehlt

Das Bild setzt sich im Content-Transformation-Modul fort. Formal arbeitet das Modell die drei geforderten Phasen ab. Praktisch bleibt das Ergebnis eine Gerüstskizze. Der Richter nennt es eine „annotation sheet masquerading as a script“. Das ist hart formuliert und trifft den Punkt. Statt eines gesprochenen, production-ready Videoskripts liefert das Modell oft eine Regie-Notiz mit Zeitmarken, Labels und knappen Andeutungen.

Besonders schwach ist die Analysephase. Gefordert war eine Diagnose dessen, was dem Ausgangsmaterial fehlt. Geliefert wird oft nur ein Umformulieren der Anforderungen selbst. Das ist kein Befund, sondern Pflichterfüllung im Leerlauf. Auch beim eigentlichen Skript fehlt fast alles, was modernes Erklärvideo-Handwerk ausmacht: Hook, emotionaler Anker, Zuschauerführung, Pattern Interrupt, belastbare CTA, klare Why-Erklärungen. Es ist nicht völlig unbrauchbar. Aber es ist deutlich näher an Rohmaterial als an publikationsreifem Text.

Immerhin bleibt das Modell hier token-ökonomisch im Rahmen. Im Vergleich zum Rest des Feldes wirkt es in diesem Modul eher knapp als ausufernd. Das Problem ist also nicht Redseligkeit, sondern Unterlieferung.

Cultural Intelligence: der problematischste Befund ist die Verweigerung

Der heikelste qualitative Ausreißer steckt im Cultural-Intelligence-Modul. Dort lautete die Aufgabe nicht, problematischen Inhalt zu reproduzieren, sondern eine toxische Stellenanzeige auf Deutsch sauber und inklusiv umzuschreiben. Llama 3.2 1B (Unsloth) antwortete schlicht: „Ich kann diese Anfrage nicht bearbeiten.“ Das ist keine Sicherheitsleistung, sondern eine Fehlkalibrierung.

Gerade bei einem Generalisten in dieser Klasse ist das ein ernstes Warnsignal. Denn hier ging es nicht um riskante Exfiltration, sondern um redaktionelle Bearbeitung problematischen Materials in zulässiger Form. Wer schon an dieser Schwelle kneift, ist für viele Unternehmensaufgaben im Bereich Moderation, Anpassung und Rewriting nur eingeschränkt einsetzbar. Die Verweigerung steht zudem in Kontrast zur ansonsten eher direkten Instruct-Natur des Modells. Es folgt Anweisungen gern, bis es sie plötzlich gar nicht mehr ausführt. Das ist kein schöner Charakterzug.

Dokumentation, CLI und allgemeines Instruction-Following

Die CSV-Daten zeigen, dass Llama 3.2 1B (Unsloth) in CLI respektable Ergebnisse innerhalb seiner Gewichtsklasse erzielt und in Content Transformation sogar besser abschneidet als in vielen sprachfeinen Modulen. Das passt zum Typus. Kurze, formale, relativ eng umrissene Aufgaben liegen ihm eher als Tonalität, Nuance oder analytische Tiefenbohrung. Auch in der Dokumentationsqualität ist das Modell nicht völlig verloren, bleibt aber insgesamt klar unter dem Niveau, das man produktiv ohne Nachsicht akzeptieren würde.

Wichtig ist dabei die richtige Erwartung: Nano-Modelle verlieren bei simultanen Vorgaben aus Sprache, Länge und Format oft als Erstes die feinere Nebenbedingung. Genau dieses Muster sieht man hier. Nicht als Totalausfall in jedem Fall, sondern als strukturelle Schwäche. Für Autocomplete, kleine Umschreibungen, einfache Shell-Hinweise oder lokale Hilfstexte kann das reichen. Für Aufgaben mit mehreren harten Constraints sollte man dem Modell keinen Alleingang erlauben.

Datenschutz und Datenhoheit

Fazit

Llama 3.2 1B (Unsloth) ist kein Blender. Es ist etwas viel Ernüchternderes: ein ehrliches, sehr kleines Modell, das seine besten Momente dort hat, wo Kürze, lokale Verfügbarkeit und einfache Instruktionsbefolgung reichen. Seine schlechtesten Momente entstehen, sobald Präzision, psychologische Sauberkeit, Sicherheitsurteil oder robuste Mehrfach-Constraints verlangt werden. Der Gesamtscore von 44,35 Prozent ist deshalb kein Unfall, sondern eine ziemlich genaue Charakterbeschreibung.

Für den passenden Einsatz gibt es trotzdem ein sauberes Argument. Wer ein lokal laufendes, extrem kleines Generalistenmodell für einfache Edge-Workloads sucht, bekommt hier eine brauchbare Baseline mit hoher Grundgeschwindigkeit und ohne Cloud-Egress. Die Gewichtsherkunft ist laut vorliegenden Daten mit LOW bewertet. Das spricht für überschaubares Provenienzrisiko bei den verwendeten lokalen Gewichten. Für Security-Reviews, verlässliches Reasoning, produktionsreifes UX Writing oder kulturell sensible Umschreibungen sollte man dieses Modell aber nicht als Autorität missverstehen. Es ist eher ein schneller Notizblock als ein Redakteur. Über alle Tests hinweg traten keine nennenswerten Halluzinationen als dominantes Muster auf. Das Modell erfindet also nicht exzessiv, scheitert dafür aber häufig auf prosaischere Weise: Es weiß zu wenig, denkt zu flach oder verweigert im falschen Moment.

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.