Ornith 1.0 9B (Unsloth)

Mit einem Gesamtscore von 65,86 % und dem Speed Profile Badge Batch Tool Expert zeigt Ornith 1.0 9B (Unsloth) sehr klar, was es sein will: kein flinkes Plaudermodell, sondern ein reasoning-zentriertes Open-Weight-System mit Hang zur gründlichen, oft schwerfälligen Bearbeitung. Als Reasoning/Deep-Thinking-Modell in der editorial kuratierten Desktop-Klasse und mit 9,4 Milliarden Dense-Parametern tritt es mit anderen Maßstäben an als ein Chat-Allrounder. Es denkt sichtbar, löst Logikaufgaben meist sauber und verliert sich zugleich regelmäßig in seinem eigenen Aufwand. Das ist nicht charmant exzentrisch, sondern im Alltag teuer.

Kopfnoten: Stabilität und Zuverlässigkeit

Diese Kopfnoten sind kein kosmetischer Makel, sondern das erste echte Einsatzsignal. Ornith 1.0 9B (Unsloth) ist ein lokales Open-Weight-Modell, und gerade deshalb wiegt diese Instabilität schwer: Wer es in Agenten-Workflows, Batch-Pipelines oder halbautomatisierte Review-Ketten einspannt, muss mit Retrys, Ausreißern und einzelnen Komplettausfällen rechnen. Für ein Thinking-Modell sind längere Denkphasen legitim. Elf Aussetzer in 49 Tests sind es nicht.

Architektur und Profil: Thinking mit echtem Charakter, aber ohne Disziplin

Die vorab zugewiesene Architektur-Kategorie passt erstaunlich gut zum beobachteten Verhalten. „Thinking“ und „Reasoning“ sind hier keine Marketing-Etiketten, sondern operative Realität. Dieser konkrete Testlauf fand explizit im Thinking-Modus statt, also mit aktivierter Denklogik. Entsprechend sind längere, ausführlich begründete Antworten nicht nur erwartbar, sondern gewollt. Wo andere 9B-Modelle gerne abkürzen, versucht Ornith lieber noch eine Schleife mehr. Das kann bei Logik helfen. Es kann aber auch die Antwort auffressen, bevor sie überhaupt beim Nutzer ankommt.

Dass das Modell als Dense klassifiziert ist, ist ebenfalls relevant. Hier gibt es keinen MoE-Trick, keine versteckte Expertenauswahl, keine aktive Kapazität unterhalb der Nennzahl. Die 9,4 Milliarden Parameter sind komplett die Arbeitsmasse des Modells. Für ein kompaktes, lokal betreibbares Reasoning-System ist das respektabel. Für echte Robustheit unter komplexen Formatvorgaben reicht es nur teilweise.

Die Tags Tool-Use und Multimodal sollte man nüchtern einordnen. Im Text-Benchmark zeigt sich Tool-Nähe durchaus punktuell. Die Multimodalität dagegen bleibt in diesem Testpfad praktisch unsichtbar. Das ist kein Skandal, aber ein wichtiger Kalibrierungspunkt: Dieser Report bewertet Textleistung. Wer aus dem Multimodal-Label eine Bildkompetenz im Alltag ableiten will, hat an dieser Stelle schlicht zu viel hineininterpretiert.

Geschwindigkeit und Token-Ökonomie

Das lokale Modell wurde auf NVIDIA DGX Spark (GB10 Grace Blackwell Superchip, ~115 GB Unified Memory — kein praktisches Speicherlimit für getestete Modellgrößen) evaluiert. Der Speed Profile Badge Batch Tool Expert ist dabei die treffendste Kurzbeschreibung: Ornith 1.0 9B (Unsloth) wirkt nicht wie ein interaktiver Assistent für schnelle Dialoge, sondern eher wie ein Modell für stapelbare, asynchrone Arbeitslasten, bei denen man auf eine fundierte Antwort wartet, statt sie im Gesprächsfluss zu erwarten.

Im Fließbetrieb macht sich vor allem seine Wortfülle bemerkbar. Das Modell ist in mehreren Modulen deutlich gesprächiger als der Fleet-Median, ohne dass der Qualitätsgewinn proportional mitwächst. Besonders auffällig ist das in Content Transformation mit dem Faktor 2,81 gegenüber dem Median, in UX Writing mit 2,49 und in Cultural Intelligence mit einem absurden Faktor von 10,43. Bei einem lokalen Modell heißt das nicht API-Rechnung, sondern Wartezeit, längere Ketten, mehr Angriffsfläche für Abbrüche und eine höhere Wahrscheinlichkeit, dass internes Reasoning das sichtbare Ergebnis verdrängt.

Das Gegenbild dazu liefert Code Quality. Dort bleibt Ornith mit 1,01× fast genau auf Median-Niveau. Wenn es um technische Audit-Tabellen geht, schreibt es also nicht deshalb zu viel, weil es grundsätzlich geschwätzig wäre. Es schreibt zu viel, wenn die Aufgabe offen ist. Das ist eine Charakterfrage des Modells, keine naturgegebene Grenze.

Reasoning und Logik: die beste Seite dieses Modells

Im Reasoning-Bereich zeigt Ornith 1.0 9B (Unsloth), warum man sich ein solches Modell überhaupt ansieht. Der Logiktest mit den zwei Wächtern wird korrekt gelöst, auf Deutsch, mit sauberer Struktur, nachvollziehbaren Fallunterscheidungen und einem sichtbar brauchbaren Denkpfad. Der Judge attestiert eine klare, richtige Lösung mit guter Schrittfolge. Hier arbeitet Ornith nicht brillant im Sinn von elegant oder knapp. Aber es arbeitet ernsthaft, und das ist in dieser Klasse bereits etwas wert.

Gerade im Vergleich zu vielen kompakten Reasoning-Ablegern fällt auf, dass Ornith nicht nur auf die Endantwort springt. Es baut die Argumentation auf, benennt die Doppelverneinung als Strategie und trennt Lösungsweg und Ergebnis. Das ist didaktisch nützlich und für Nutzer, die Reasoning-Modelle nicht als Orakel, sondern als Arbeitswerkzeug einsetzen, ein echtes Plus.

Der Haken folgt sofort. In einer Metakognitions-Aufgabe im Reasoning-Modul meldete das Modell Erfolg, produzierte aber keinen sichtbaren Output. Zugleich ist dokumentiert, dass in dieser Aufgabe 25.000 interne Reasoning-Tokens verbraucht wurden, bevor überhaupt ein auswertbarer Antworttext erschien. Das ist kein klassischer Denkfehler, sondern ein operatives Versagen: Das Modell hat die Aufgabe als abgeschlossen gemeldet, aber keinen sichtbaren Antworttext produziert. Das bedeutet entweder einen rein internen Reasoning-Only-Output oder einen stillen Fehlschlag. Für den Nutzer ist das Ergebnis identisch: nichts.

In genau diesem Punkt zeigt sich die Kehrseite des Thinking-Profils. Ausführliches Denken ist eine Stärke, solange am Ende eine Antwort steht. Wenn die Denkphase das gesamte Ausgabe-Kontingent verschlingt, ist nicht die Logik schlecht, sondern die Produktreife. Und Produktreife ist im Alltag oft wichtiger als der schönere innere Monolog.

Code Quality: brauchbarer Auditor mit klaren blinden Flecken

Der Code-Quality-Wert ist ordentlich, aber nicht überragend. Die qualitative Auswertung zeigt ein Modell, das viele Schwachstellen zuverlässig erkennt, Tabellen sauber formatiert und brauchbare Fix-Vorschläge liefert. SQL-Injection, Plaintext-Passwörter, XSS, Session Fixation, Path Traversal, schwache Zufallsquellen und mehrere implizite Lücken werden erkannt. Das ist für ein kompaktes lokales Reasoning-Modell absolut respektabel.

Was fehlt, ist die Schärfe bei Priorisierung und Ausbeutungskette. Besonders deutlich wird das bei Type Juggling in PHP. Der Goldstandard bewertet die lose API-Key-Prüfung als kritisch. Ornith stuft sie nur als mittel ein und bleibt bei der Erklärung zu flach. Genau dort trennt sich Security-Katalog von Security-Verständnis. Ebenso wird ein IDOR-Pfad nicht als eigener kritischer Eintrag sauber herausgearbeitet, sondern nur implizit gestreift. Und bei den hartkodierten Datenbank-Credentials fehlt der Verweis auf weitergehende Rechteeskalation über Root-Privilegien.

Das ist nicht harmlos. In Security-Reviews ist die korrekte Gewichtung oft wichtiger als die bloße Erkennung. Eine Schwachstelle, die auf dem Papier auftaucht, aber im Schweregrad zu niedrig taxiert wird, ist im Unternehmensalltag schnell dieselbe Schwachstelle, die im Sprint nie priorisiert wird.

Trotzdem: Als technischer Erstprüfer liefert Ornith hier nützliche Arbeit. Die Tabellenstruktur sitzt, die Sprache ist sauber, die Fixes sind meist brauchbar. Wer einen lokalen Vorfilter für Code-Audits sucht, bekommt Substanz. Wer einen belastbaren Security-Lead-Ersatz erwartet, bekommt eine höfliche Absage in Tabellenform.

Content Transformation: viel Handwerk, dann ein grober Patzer

Im Modul Content Transformation zeigt Ornith eine der frustrierendsten Kombinationen, die man bei einem KI-Modell sehen kann: erkennbares Können und ein vermeidbarer Totalausfall in der Instruktions-Compliance. In einem Videodrehbuch-Task liefert es inhaltlich vieles richtig. Die Struktur stimmt, die Produktionshinweise sind brauchbar, das Timing ist realistisch, CTA und Easter Egg sind vorhanden. Das Modell versteht also, wie ein solches Format funktioniert.

Dann antwortet es auf Englisch, obwohl die Aufgabe explizit Deutsch verlangt. Das Modell ignorierte die klare Sprachanweisung und antwortete in der falschen Sprache. In produktiven Umgebungen mit fixer Zielsprache ist das kein kleiner Schönheitsfehler, sondern ein direkter Fehlschlag. Gerade bei Content-Transformation, wo Sprache oft selbst das Produkt ist, disqualifiziert so etwas den Output trotz handwerklich brauchbarer Struktur.

Hinzu kommt ein zweiter, strukturell anderer Befund: In einer weiteren Aufgabe im Content-Bereich meldete das Modell Erfolg, produzierte aber gar keinen sichtbaren Antworttext. Gleichzeitig ist dokumentiert, dass 12.000 interne Reasoning-Tokens das gesamte Ausgabebudget verdrängt haben. Kein Richter kann eine nicht vorhandene Antwort bewerten, und kein Nutzer kann mit einer unsichtbaren Antwort arbeiten. Das ist kein Qualitätsurteil über den Inhalt. Es ist ein technischer Komplettverlust.

Das Sprachversagen ist dabei kein bloßer Einzelunfall im Vakuum, sondern ein Warnsignal für komplexe Mehrfachvorgaben. Sobald Sprache, Format, Analysepflicht und Produktionsstil gleichzeitig verlangt werden, verliert Ornith offenbar zuerst die Sprachschiene. Ein Modell, das auf Thinking optimiert wurde, sollte mehrstufige Constraints eigentlich besser halten. Hier stolpert es ausgerechnet über eine der banalsten.

UX Writing: wenn Denken die Ausgabe verdrängt

UX Writing ist für Thinking-Modelle oft eine kleine Gemeinheit. Die Aufgaben verlangen Präzision, Tonalität, Kürze und kulturelles Fingerspitzengefühl zugleich. Genau dort fällt Ornith ab. Der Modulwert ist schwach, und die qualitative Spur ist eindeutig: Das Modell kann grundsätzlich umformulieren, verfehlt aber häufig die letzte Meile aus Wärme, Idiomatik und psychologischer Einladung.

Ein Beispiel aus den Protokollen zeigt das gut. Bei der Überarbeitung eines problematischen Job-Texts produziert Ornith eine korrekte, inklusive deutsche Fassung, entfernt toxische und gendercodierte Elemente und bleibt formal innerhalb des Rahmens. Was fehlt, ist der menschliche Takt. Begriffe wie „Tatkraft“, „Leidenschaft“ oder „Eigeninitiative“, die im deutschen HR-Kontext weich und motivierend wirken, ersetzt es durch sachlichere, härtere Wendungen wie „Durchsetzungsvermögen“. Das Ergebnis ist nicht falsch. Es klingt nur so, als hätte jemand den Text entgiftet, aber nicht wirklich entkrampft.

Schwerer wiegt ein technischer Ausfall im selben Modul. In einer UX-Aufgabe meldete das Modell Erfolg, lieferte aber keinen sichtbaren Text. Auch hier wurden 12.000 interne Reasoning-Tokens verbraucht, ohne dass ein auswertbares Ergebnis erschien. Der Score-Verlust ist folgerichtig. Für den Nutzer zählt am Ende nicht, wie intensiv ein Modell nachgedacht hat, sondern ob auf dem Bildschirm etwas steht, das man freigeben kann.

Documentation Quality: Substanz, aber keine Verlässlichkeit

Dokumentationsaufgaben profitieren grundsätzlich von gründlichen Modellen, und Ornith bringt die nötige Denktiefe mit. Die Token-Nutzung ist hier erhöht, aber noch im grünen Bereich. Das Problem liegt auch in diesem Modul nicht primär im inhaltlichen Niveau, sondern in der Zuverlässigkeit des Auslieferns.

In einer Dokumentationsaufgabe meldete das Modell Erfolg, erzeugte jedoch keinen sichtbaren Antworttext. Parallel dazu ist auch hier festgehalten, dass 12.000 interne Reasoning-Tokens das sichtbare Output-Budget vollständig verdrängt haben. Das Modell hat also eine Aufgabe formal abgeschlossen, ohne ein Ergebnis zu liefern, das ein Mensch lesen könnte. Kein bewertbarer Output bedeutet in der Praxis: keine Dokumentation.

Für produktive Doku-Workflows ist das ein besonders unangenehmer Fehler. Dokumentation lebt von Vollständigkeit, nicht von guten Absichten. Ein Modell, das ausgerechnet in textlastigen Langformaten gelegentlich leer ausgibt, ist als unbeaufsichtigter Schreiber schlicht nicht vertrauenswürdig.

Cultural Intelligence: ordentliches Gespür, etwas mechanisch

Im Bereich Cultural Intelligence schneidet Ornith vergleichsweise gut ab. Das qualitative Material zeigt ein Modell, das problematische Sprache zuverlässig entschärft, inklusive Formulierungen findet und deutsche Zieltexte sprachlich korrekt hält. Gerade bei Bias-Reduktion, Entgiftung und neutraler Umformulierung leistet es saubere Arbeit.

Gleichzeitig bleibt der Stil oft eine Spur zu mechanisch. Die Urteile des Judges sind hier aufschlussreich: Ornith erledigt die Aufgabe, aber der Goldstandard klingt wärmer, einladender und kulturell idiomatischer. Das Modell kann also soziale Schieflagen erkennen und beheben. Es klingt dabei nur gelegentlich so, als hätte die Compliance-Abteilung den letzten Satz geschrieben.

Dass es in diesem Modul massiv mehr Tokens als der Median produziert, verschärft den Eindruck. Mehr Text führt hier nicht automatisch zu mehr Feingefühl. Der eigentliche Nutzen bleibt trotzdem real: Für sensible Umformulierungen, erste Lokalisierungsschritte und Bias-Bereinigung ist Ornith nützlich. Für Tonalität auf Kampagnenniveau braucht es meist noch ein menschliches Finish.

Tool-Use und Halluzinationen: hier endet das Vertrauen

Tool-Use gehört laut Metadaten zur Identität des Modells. Der Benchmark signalisiert jedoch eine unschöne Wahrheit: Die Tool-Nähe ist vorhanden, aber nicht belastbar genug für faktenkritische Workflows. Im Tool-Use-Bereich wurde mindestens ein klarer Halluzinationsfall detektiert. Das Modell generierte Inhalte, die nicht aus dem abgerufenen Tool-Ergebnis stammten, sondern hinzuerfunden wurden. Der Score wurde deshalb durch ein Halluzinations-Cap begrenzt.

Das ist kein Randnotizchen. Für Recherche, Aktenzusammenfassungen, Security-Reports oder agentische Tool-Ketten ist das ein disqualifizierendes Signal. Ein Modell darf bei Tool-Use viele Dinge sein: langsam, umständlich, wortreich. Es darf aber nicht so tun, als habe das Tool etwas gesagt, was es nie gesagt hat. Genau das zerstört die Verlässlichkeit der ganzen Kette.

Ornith bleibt damit in einem heiklen Zwischenzustand. Es plant und argumentiert wie ein Tool-Modell. Es liefert aber nicht die nötige epistemische Disziplin, um Tool-Ergebnisse immer sauber vom eigenen Ergänzungsdrang zu trennen.

Datenschutz und Datenhoheit

Da Ornith 1.0 9B (Unsloth) als lokale Open-Weights-Variante betrieben wird, liegt die Datenschutzrealität weitgehend beim Betreiber selbst. DeepReinforce sitzt in Santa Clara, California, USA, stellt laut Vendor Card aber keinen eigenen Cloud-Inferenz-Dienst bereit; die Modelle werden als Open-Weight-Downloads verteilt. Sovereign Risk: LOW: DeepReinforce veröffentlicht Ornith 1.0 unter der permissiven MIT-Lizenz, und Unsloth stellt die lokale GGUF-Paketierung für Offline-Inferenz bereit. Das Modell hat offene Gewichte, kann vollständig lokal betrieben werden und trägt daher ein geringes operatives Provenance-Risiko. Für europäische Unternehmen heißt das konkret: Nicht der Modellaufruf selbst, wohl aber Beschaffung, Hosting-Umgebung und mögliche Drittanbieter-Deployments müssen sauber geprüft werden. Ein eigener DSGVO-Auftragsverarbeitungsvertrag ist hier naturgemäß nicht einschlägig, weil DeepReinforce keine Nutzeranfragen verarbeitet.

Fazit

Ornith 1.0 9B (Unsloth) ist ein interessantes Modell mit erkennbarer Identität. Die MIT-lizenzierten, lokal betreibbaren Gewichte tragen laut Card ein LOW Weights-Provenienz-Risiko, und genau das macht das Modell attraktiv für Teams, die Reasoning lieber unter eigener Kontrolle als hinter fremden APIs betreiben wollen. Seine Stärken liegen in Logik, strukturiertem Denken und brauchbarer technischer Erstbewertung. Seine Schwächen liegen in operativer Disziplin: zu viele Aussetzer, zu viel Token-Hunger, zu viele Fälle, in denen internes Denken die sichtbare Antwort verdrängt.

Wer einen kompakten lokalen Reasoner für explorative Analysen, Code-Vorsichtung oder Denkaufgaben sucht, kann mit Ornith arbeiten. Wer dagegen verlässliche Produktionspipelines für UX-Texte, Dokumentation, sprachkritische Content-Adaptionen oder toolgestützte Faktenarbeit bauen will, sollte vorsichtig sein. Dieses Modell hat Charakter. Aber Charakter ersetzt keine Zuverlässigkeit.

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.