Ornith-1.0-35B: Die Qualität eines dichten 27B als MoE auf dem MacBook

Ein dichtes 27B-Modell ist ein schwerer Brocken für den täglichen Betrieb, selbst ein gutes wie Qwen3.6-27B. Ornith-1.0-35B geht einen anderen Weg. Es hat insgesamt 35 Milliarden Parameter, weckt aber pro Token nur etwa 3 Milliarden davon, passt auf Consumer-Hardware und kommt beim Programmieren und bei der Tool-Nutzung nah an dichte 27B-Modelle heran. Außerdem gibt es das Modell als GGUF, also steht weder ein llama.cpp-Upgrade noch ein spezieller Serving-Stack im Weg. Herunterladen, laden, loslegen. Und schnell ist es auch.

Was Ornith-1.0-35B ist

Ornith-1.0 ist eine Modellfamilie von DeepReinforce. Sie baut auf vortrainierten Gewichten von Qwen 3.5 auf und wird mit der hauseigenen Methode des Labors feinjustiert, einem Reinforcement Learning mit selbst erzeugten Gerüsten (Self-Scaffolding RL). Das 35B-Mitglied ist ein Mixture-of-Experts-Design (MoE): Es gibt 35B Parameter, an der Verarbeitung eines einzelnen Tokens sind aber nur rund 3B beteiligt.

Man stelle sich ein großes Gehirn vor, in dem bei jedem Gedanken nur die zuständige Region aufleuchtet, während der Rest ruht und Rechenleistung spart. Das Ergebnis ist eine Qualität nahe an einem dichten 27B bei etwa 3B aktiver Rechenlast. Für lokale KI ist das eine attraktive Balance.

Die Zahlen

Ein Benchmark für gemischte Fähigkeiten namens spark-bench, veröffentlicht unter github.com/Weschera/spark-bench, umfasst 57 Szenarien in 10 Bereichen. So schnitt Ornith gegen die Qwen3.6-Familie ab:

Model                     Overall   Coding   Math   Tool Use   Reasoning
Ornith-1.0-35B            41.07     62.26    47.29  58.14      38.92
Qwen3.6-27B (dense)       43.12     64.18    49.87  56.32      41.05
Qwen3.6-35B-A3B (MoE)     39.84     59.47    44.12  52.88      37.21

Einige Punkte fallen auf.

Ornith schlägt Qwen3.6-35B-A3B in allen Bereichen. Das ist sein engster Verwandter, denn beide sind 35B-MoE-Modelle mit rund 3B aktiven Parametern. Self-Scaffolding RL verschafft Ornith einen klaren Vorsprung beim Programmieren (+2,8 Punkte), bei der Tool-Nutzung (+5,3) und beim logischen Schließen (+1,7).

Ornith liegt auch nah an Qwen3.6-27B. Das dichte Modell führt insgesamt noch mit 2,05 Punkten, doch beim Programmieren schrumpft der Abstand auf 1,92, und bei der Tool-Nutzung dreht sich das Bild: Ornith liegt 1,82 vorn. Bei Mathematik und reinem logischen Schließen gewinnt weiterhin das dichte Modell. Für agentisches Programmieren ist Ornith aber gut konkurrenzfähig.

Test auf einem MacBook

Mit dem Modell als Grundlage eines Agenten auf einem MacBook umfasste ein vollständiger Arbeitszyklus Websuche, Code schreiben und Dateien bearbeiten. Im Alltag fühlte es sich an wie Qwen3.6-27B, nur schneller.

Der Grund liegt in der Architektur. Da pro Token nur etwa 3B Parameter aktiv sind, braucht eine Q4_K_M-Quantisierung unter llama.cpp pro Token viel weniger Rechenleistung als ein dichtes 27B, obwohl die Gesamtzahl der Parameter höher ist.

Model                     Q4_K_M Size   Active Params   Est. tok/s (M4 Max 64GB)
Ornith-1.0-35B (MoE)      21.2 GB       ~3B             ~75-85 tok/s
Qwen3.6-27B (dense)       16.5 GB       27B             ~15-18 tok/s
Qwen3.6-35B-A3B (MoE)     20.5 GB       ~3B             ~65-75 tok/s

Das Ornith-GGUF belegt bei Q4_K_M 21,2 GB, etwas mehr als die 16,5 GB von Qwen3.6-27B, doch die aktive Rechenlast pro Token ist etwa neunmal geringer. Das ist der MoE-Tausch: Man zahlt einmal mit Speicher, um alle Experten zu laden, und dann pro Token nur für 3B an Rechenleistung.

Auf einem M4 Max mit 64 GB belegt der Q4_K_M-Build insgesamt etwa 25 GB Speicher, inklusive Gewichten, KV-Cache und Laufzeit, sodass reichlich Platz für Kontext und andere Anwendungen bleibt.

Kein llama.cpp-Upgrade nötig

Ornith-1.0-35B läuft direkt auf dem aktuellen llama.cpp. Es verwendet dieselben Tags <think> und </think> wie die Qwen-Modelle, und llama.cpp routet die Experten nativ. Keine Patches, keine Forks und kein Warten auf Upstream-Support.

Nachdem der Agent auf das heruntergeladene GGUF zeigte, wurden die Thinking-Tags korrekt geparst, Tool-Aufrufe funktionierten und mehrstufige Agenten-Schleifen liefen ohne Probleme.

Stärken und Grenzen

Programmieren und Tool-Nutzung sind sein Heimspiel. Das Self-Scaffolding-RL-Training zielte gezielt auf agentische Coding-Workflows, und im Test schrieb das Modell sauberen Code, bewältigte Änderungen über mehrere Dateien und wählte seine Werkzeuge (Websuche, Shell-Befehle) mit Bedacht.

Das logische Schließen ist solide, liegt aber eine Stufe unter Qwen3.6-27B. Bei reiner Mathematik oder verschachtelter Logik behält das dichte Modell die Nase vorn. Für das Schließen, auf das es beim Programmieren ankommt, also Debugging, Architekturentscheidungen und Code-Reviews, ist Ornith mehr als fähig.

Langer Kontext wird über 200K Tokens hinaus unterstützt. Bis ans Limit wurde das nicht getrieben, aber bei 32K bis 64K kommt es mit großen Codebasen und RAG über mehrere Dokumente klaglos zurecht.

Ein Ersatz für Qwen3.6-27B ist es nicht, wenn man maximale Tiefe beim Schließen oder Mathematik braucht. Besteht die Hauptlast aus Programmieren, Tool-Nutzung und Agenten-Schleifen, bekommt man etwa 90 % der Qualität für einen Bruchteil der Rechenleistung.

Fazit

Ornith-1.0-35B ist die Art Modell, die das Wettrennen um Parameterzahlen weniger wichtig erscheinen lässt: 35B insgesamt, 3B aktiv pro Token, nahezu die Qualität eines dichten 27B bei Code und Tool-Nutzung, Consumer-Hardware, kein spezielles Serving. Auf einem MacBook ist das der ideale Punkt.

Sie nutzen Qwen3.6-35B-A3B? Wechseln Sie zu Ornith. Sie arbeiten mit Qwen3.6-27B und wollen schnellere Inferenz, ohne viel Qualität aufzugeben? Probieren Sie es aus. Das GGUF liegt auf Hugging Face, die Unterstützung in llama.cpp läuft rund, und die Ergebnisse halten.

Lokale Open-Source-KI wird immer besser, und dass ein MoE-Modell auf diese Weise zulegt, deutet auf reichlich Spielraum nach oben hin. Der nächste Meilenstein, den man im Blick behalten sollte, ist Qwen3.7-27B.