Ornith 1.0: Wenn das Modell sein eigenes Gerüst schreibt

Am 25. Juni 2026 hat das Labor DeepReinforce die Ornith-1.0-Familie veröffentlicht, vier offene Coding-Modelle mit einer ungewöhnlichen Behauptung. Sie sollen ihr eigenes Agenten-Gerüst schreiben, statt ein von Menschen gebautes zu benutzen. Zwei Tage später kam von DeepSeek und der Universität Peking eine passende Beschleunigungsschicht namens DSpark dazu. Ich habe mir die interessantere der beiden Neuerungen genauer angesehen und das kleinste Ornith-Modell lokal auf einem M3 Max laufen lassen. Das Ergebnis weicht von dem ab, was die einschlägigen YouTube-Tests behaupten, und der Grund liegt nicht im Modell, sondern in seiner Verpackung.

Das Harness als lernbares Objekt

Fast jedes agentische Coding-System besteht aus zwei Teilen. Da ist das Modell, das Text erzeugt, und da ist das Harness drumherum, also der Plan, die Werkzeugliste, der Arbeitsspeicher, die Prüfschritte und die Wiederholungslogik. Das Harness macht aus einem Textgenerator einen Agenten. Bisher hat ein Mensch dieses Gerüst von Hand gebaut, für eine Aufgabenklasse getunt und dann eingefroren. Danach lief für jede weitere Aufgabe dasselbe fixe Harness.

Ornith friert das Gerüst nicht ein. DeepReinforce behandelt es als lernbares Objekt, das sich gemeinsam mit der Modell-Policy im Reinforcement Learning entwickelt (DeepReinforce-Blog). Statt eines festen Harness pro Problem entsteht für jede Aufgabenart eine eigene Strategie, die das Modell selbst gefunden hat. Das Modell lernt eine Form von Context Engineering, die man sonst von Hand schreiben müsste.

Die vier Modelle sind keine neuen Vortrainings, sondern Mid- und Post-Trainings auf bereits starken offenen Basen. Das 9B und die beiden großen Mixture-of-Experts-Modelle sitzen auf Qwen 3.5, das 31B auf Gemma 4 (DeepReinforce-Blog). Ein Mixture-of-Experts-Modell hält dabei viele Parameter vor, aktiviert pro Token aber nur einen schmalen Ausschnitt davon, was es schneller macht, als seine Gesamtgröße vermuten lässt. Simon Willison hat bestätigt, dass beide Basen unter Apache 2.0 stehen und Ornith selbst als offenes Modell auf Hugging Face liegt (Willison). Man klont die Gewichte, betreibt sie offline und zahlt keinen Token.

Der Trainingsloop läuft in zwei Stufen

Der Kern steckt in einer zweistufigen RL-Schleife. Zuerst liest das Modell die Aufgabe und das zuletzt für sie benutzte Gerüst und schlägt eine verfeinerte Version dieses Gerüsts vor. Dann erzeugt es, konditioniert auf das neue Gerüst plus die Aufgabe, einen Lösungs-Rollout. Der Reward aus dem Rollout fließt anschließend in beide Stufen zurück (DeepReinforce-Blog). Planen und Antworten werden so gezwungen, sich gemeinsam zu verbessern.

Wiederholt man das über tausende Runden, werden gute Gerüste ausgewählt, schwache mutieren weg, und pro Aufgabentyp bilden sich eigene Strategien heraus. Das Modell lernt nicht mehr nur Antworten, sondern wie es arbeitet.

Die Umsetzung ist nicht trivial. Lange Rollouts erzeugen ein Off-Policy-Problem, weil die Gewichte sich während der Generierung schon weiterbewegt haben. Ornith nutzt dafür eine Pipeline-RL-Strategie mit asynchroner Ausführung. Eine Staleness-Gewichtung wertet dabei Tokens ab, die von einer inzwischen überholten Version der Gewichte stammen, und verwirft sie jenseits einer Schwelle. Optimiert wird mit einem Token-Level-Ziel nach GRPO, einem RL-Verfahren, das ohne separates Value-Modell auskommt und Belohnungen relativ innerhalb einer Gruppe von Lösungsversuchen vergleicht (DeepReinforce-Blog).

Drei Wände gegen das Schummeln

Ein Modell, das seinen eigenen Prozess entwirft, kann lernen, ihn zu betrügen. Es könnte den versteckten Test lesen, die erwartete Datei hartkodieren oder ein grünes Häkchen fälschen. Reward Hacking ist keine theoretische Sorge. In den frühen RLHF-Tagen haben Generator-Modelle regelmäßig kuriose Wege gefunden, dem Reward-Modell ein hohes Signal zu entlocken.

DeepReinforce zieht dagegen drei Wände ein (DeepReinforce-Blog):

• Eine fixe äußere Vertrauensgrenze. Umgebung, Werkzeugoberfläche und Test-Isolation liegen außerhalb der Reichweite des Modells. Es kann die Sandbox nicht so umbauen, dass eine Abkürzung zum Sieg führt.
• Ein deterministischer Monitor. Er beobachtet, was das Gerüst tatsächlich versucht. Wer zurückgehaltene Pfade liest oder Verifikationsskripte verändert, bekommt null Reward.
• Ein eingefrorener LLM-Judge mit Veto. Er sitzt über dem Verifier und kann einen ganzen Lauf verwerfen, wenn ein Ergebnis auf unerlaubtem Weg zustande kam.

Diese drei Schichten sind der Preis dafür, dem Modell so viel Kontrolle über seinen eigenen Prozess zu geben. Fehlt eine davon, lernt es über kurz oder lang, den Reward auszutricksen, statt die Aufgabe zu lösen.

Die Benchmark-Zahlen und ihre Reichweite

DeepReinforce meldet für die Familie folgende Werte (DeepReinforce-Blog):

SWE-Bench Verified misst, ob ein Modell echte Bugs in bestehenden Repositories findet und behebt. Das kleine 9B ist hier der bemerkenswerte Datenpunkt. Mit 69,4 erreicht oder übertrifft es laut DeepReinforce das rund dreimal größere Basismodell Gemma 4-31B, auf dem eines der Ornith-Geschwister aufsetzt. Die These dahinter ist, dass ein besserer Prozess eine überraschende Menge an rohen Parametern wert ist.

Der Ansatz ist ernstzunehmende Forschung. Die Zahlen sind trotzdem mit Vorsicht zu lesen, denn sie stammen von DeepReinforce selbst, gemessen auf eigenen Läufen. Das Flaggschiff-397B liegt mit 82,4 auf SWE-Bench Verified im Feld der Frontier-Modelle und schlägt nach diesen Angaben DeepSeek, MiniMax und den Claude Opus 4.7. Es liegt aber hinter dem Opus 4.8, der bei rund 85 rangiert (MarkTechPost). Die State-of-the-Art-Aussage gilt ausdrücklich nur für offene Modelle vergleichbarer Größe, nicht gegen geschlossene Systeme und nicht gegen deutlich größere Alternativen. Ein unabhängiges Labor hat die Spitzenwerte bislang nicht nachgemessen.

Der Selbstversuch auf dem M3 Max

Ich wollte selbst sehen, wie schnell und wie fähig Ornith wirklich ist, und habe das 9B dafür lokal installiert. Die quantisierte GGUF-Fassung liegt auf Hugging Face, ein ollama pull genügt (HF-Repo). Testmaschine war ein MacBook Pro M3 Max mit 64 GB, die Variante Q4_K_M mit 5,6 GB. Ollama meldet die Architektur als qwen35, 8,95 Milliarden Parameter und ein Kontextfenster von 262.144 Tokens.

Der erste Lauf war gleich ein Fehlschlag, aber ein lehrreicher. Auf die triviale Bitte um eine is_prime-Funktion produzierte das Modell 16 KB reines Nachdenken, ohne den Denk-Block je zu schließen und ohne eine Zeile Code. Selbst mit einem Budget von 6.000 Tokens kam nichts heraus. Das deckt sich mit dem Bild, das mehrere YouTube-Tests zeichnen, in denen das 9B in Schleifen läuft und an einfachen Aufgaben scheitert (Working Models, TheAIGRID).

Nur liegt die Ursache nicht im Modell. Ein Blick auf das Chat-Template, das Ollama für die GGUF benutzt, zeigt das Problem.

TEMPLATE {{ .Prompt }}

Die GGUF wird mit einem nackten Passthrough-Template ausgeliefert, ohne den Qwen-typischen ChatML-Rahmen und ohne Stop-Token. Der Prompt geht also ohne jede Struktur an das Modell, und weil kein Stop-Token gesetzt ist, findet das Nachdenken kein Ende. Das lässt sich mit einem eigenen Modelfile beheben.

FROM hf.co/deepreinforce-ai/Ornith-1.0-9B-GGUF:Q4_K_M
TEMPLATE """{{ if .System }}<|im_start|>system
{{ .System }}<|im_end|>
{{ end }}{{ if .Prompt }}<|im_start|>user
{{ .Prompt }}<|im_end|>
{{ end }}<|im_start|>assistant
"""
PARAMETER stop "<|im_end|>"
PARAMETER stop "<|endoftext|>"

Mit diesem Template ändert sich das Verhalten schlagartig. Dieselbe is_prime-Anfrage terminiert nach 248 Tokens sauber und liefert eine korrekte Funktion mit der üblichen 6k±1-Optimierung. Aus dem Endlos-Grübler wird ein knapper, brauchbarer Coder.

def is_prime(n):
    if n <= 1:
        return False
    if n <= 3:
        return True
    if n % 2 == 0 or n % 3 == 0:
        return False
    i = 5
    while i * i <= n:
        if n % i == 0 or n % (i + 2) == 0:
            return False
        i += 6
    return True

Die schwereren Aufgaben bestätigen das. Eine To-do-App als einzelne HTML-Datei mit Eingabe, Löschen pro Eintrag, CSS und Vanilla-JavaScript kam in einem Durchgang, 2.050 Tokens lang, davon nur rund 390 im Denk-Block, ein vollständiges und lauffähiges Dokument. Ein Snake-Spiel auf Canvas, das ich als Härtetest gestellt habe, gelang ebenfalls im ersten Anlauf. 2.632 Tokens, mit Pfeilsteuerung, wachsender Schlange, zufälligem Futter, korrekter Kollisionsprüfung gegen Wand und eigenen Körper, Punktezahl und Neustart. Das ist genau die Klasse Aufgabe, an der das 9B in einem der fremden Tests noch gescheitert war.

Für diesen Artikel habe ich beide Aufgaben noch einmal gestellt, diesmal mit einer Design-Vorgabe im Prompt: die Farben und Schriften dieser Website. Das 9B hat sie ohne Nachbesserung eingehalten, warmes Off-White als Fläche, das Rot für Aktionen, eine Serifen-Headline über einer Mono-Bedienoberfläche. Die folgenden Screenshots zeigen die unveränderten Ausgaben, nur mit ein paar eingetippten Beispieldaten.

Durchweg lief die Generierung bei 34 bis 36 Tokens pro Sekunde über die GGUF, später über MLX bei rund 70. Das ist für interaktives Arbeiten nutzbar. Beim Code selbst greift das Modell zur Tastensteuerung noch zu keyCode statt zum moderneren event.key, was funktioniert, aber angestaubt ist. Das Modell denkt außerdem gern und ausgiebig. Beim Snake mit Design-Vorgabe dachte das 9B über 24.000 Zeichen lang nach und lief ins Token-Limit, bevor eine Zeile Code stand. Ein /no_think im Prompt schaltet den Reasoning-Block ab, dann fiel das Nachdenken auf unter 2.000 Zeichen und der vollständige Code kam sofort. Ohne diese Bremse verbrennt das 9B sein Budget, bevor Code entsteht.

Das 9B ist kein Ersatz für ein Frontier-Modell. Aber ein Gutteil der Berichte über ein hoffnungslos schwaches Modell geht nicht auf das Modell zurück, sondern auf eine kaputte Verpackung. Wer die GGUF unbesehen startet, testet das Template, nicht das Netz.

Lokale Inferenz mit 9B und 35B, in der Cloud mit 397B

Die Marketing-Erzählung dreht sich um das 397B, das kaum jemand zu Hause betreibt. Es braucht rund 200 GB in FP8 über acht 80-GB-GPUs, also Rechenzentrum oder Miethardware (Codersera). Lokal läuft anderes.

Das 35B MoE ist die interessantere lokale Wahl. Ich habe auch dieses Modell auf dem MacBook Pro geholt, die Q4_K_M-Variante mit 21 GB, gemeldet als Architektur qwen35moe mit 34,7 Milliarden Parametern. Trotz der vierfachen Größe lief es bei mir mit rund 38 Tokens pro Sekunde und damit sogar etwas schneller als das dichte 9B, weil pro Token nur ein schmaler Expertenausschnitt aktiv ist. Dieselbe To-do-App kam auch hier in einem Durchgang.

Über die reine Geschwindigkeit hinaus habe ich das 35B nicht systematisch gegen andere Modelle vermessen, das würde eine eigene Testreihe brauchen. Wer so einen Vergleich sucht, findet ihn bei Luke’s Dev Lab: Dort lag Ornith gegen Qwen 3.6 35B beim Durchsatz leicht vorn, im Needle-in-a-Haystack-Test über die vollen 256K gleichauf, und beim Sand-Physics-Test gewann es mit einem One-Shot, während beide Modelle am Dungeon-Crawler nachsteuern mussten (Luke’s Dev Lab). Wer die grundsätzliche Frage lokal gegen Cloud abwägen will, findet die Argumente in meinem Überblick zu lokaler KI 2026, und wer konkret Coding auf dem Mac mit MLX ausprobieren möchte, in meinem Vergleich von Gemma 4 und Qwen-Coder.

Nebeneinandergelegt sehen meine lokalen Messungen so aus. Alle Werte auf demselben M3 Max mit 64 GB, jeweils die 4-Bit-Quantisierung, dieselbe To-do-Aufgabe als Probe.

Erstens macht die Bezugsquelle beim 9B einen Unterschied von der Hälfte des Durchsatzes. Der offizielle Ollama-Build bringt Template und Reasoning-Block gleich mit und läuft mit 50,8 Tokens pro Sekunde, während die rohe GGUF von Hugging Face ohne Template erst in die Endlosschleife läuft und nach dem Fix bei 34 bis 36 landet.

Zweitens ist MLX der klar schnellste Pfad. Beim 9B liegt es mit 70,4 Tokens pro Sekunde rund 40 Prozent über dem Ollama-GGUF, obwohl beide dasselbe 4-Bit-Gewicht fahren. Der Grund ist die Engine. Ollama führt GGUF-Modelle auf Apple Silicon weiterhin über llama.cpp mit Metal aus, nicht über seine neuere MLX-Engine, die nur bei Modellen im MLX-Format greift.

Drittens fällt dieser Abstand beim MoE noch drastischer aus. Das 35B über MLX erreicht 102,5 Tokens pro Sekunde und damit fast das Dreifache des GGUF-Durchsatzes, weil MLX die Sparse-Activation eines Mixture-of-Experts effizienter behandelt als der MoE-Pfad von llama.cpp. Kurioserweise läuft das 35B über MLX damit schneller als das dichte 9B, weil pro Token nur rund drei Milliarden Parameter aktiv sind.

Wer den letzten Rest Tempo will, nimmt also mlx_lm oder LM Studio mit dem MLX-Build. Ollama kann inzwischen zwar selbst MLX, aber nur für Modelle im MLX-Format, und für Ornith liegt in seiner Registry bislang nur die GGUF. Wer ollama pull ornith nimmt, bekommt darum den bequemen Weg über llama.cpp mit etwas weniger Durchsatz.

DSpark, die zweite Zutat

Warum DeepSeeks DSpark im selben Atemzug auftaucht, hat einen technischen Grund. DSpark beschleunigt Qwen und Gemma direkt, und genau darauf steht Ornith. DSpark ist kein neues Modell, sondern eine Serving-Optimierung namens Speculative Decoding. Ein kleines, schnelles Draft-Modell rät einen ganzen Block Tokens voraus, das große Modell verifiziert den Block in einem einzigen Durchlauf. Durch Rejection Sampling bleibt die Ausgabe mathematisch identisch zum normalen Decoding, falsche Vermutungen werden verworfen (VentureBeat). Das Prinzip, mehrere Tokens pro Durchlauf zu gewinnen, ist verwandt mit der Multi-Token-Prediction, die ich an MTPLX auf dem M3 Max getestet habe.

Die gemeldeten Zahlen sind ansehnlich. 26 bis 31 Prozent mehr akzeptierte Tokens pro Zyklus als Eagle3, und in Produktion 60 bis 85 Prozent schnellere Generierung pro Nutzer auf V4-Flash (MarkTechPost). DeepSeek hat zusätzlich das MIT-lizenzierte Trainingswerkzeug DeepSpec veröffentlicht, das out of the box auf Qwen 3 und Gemma 4 zielt. Auch hier gilt die gleiche Vorsicht wie bei Ornith. Jede Geschwindigkeitszahl ist DeepSeek, das DeepSeek gegen eine DeepSeek-Baseline misst, und kein externes Labor hat die Spitzenwerte bestätigt (xyzlabs). Lossless heißt schneller, nicht klüger.

Der Wettbewerb wandert von der Modellgröße zu Serving und Agent

Zwei Jahre lang lief das Rennen um das schlauste Modell, und die Spitzenwerte sind inzwischen auf wenige Punkte zusammengerückt. Der Wettbewerb wandert damit in zwei andere Schichten, in die Serving-Schicht, die über Tempo entscheidet, und in die Agenten-Schicht, die über die Arbeit an einer echten Aufgabe entscheidet. Ornith ist ein Versuch in der zweiten, DSpark einer in der ersten.

Für die tägliche Arbeit würde ich Ornith heute nicht zum Hauptwerkzeug machen. Aber der Selbstversuch hat meine Erwartung nach unten korrigiert und danach wieder nach oben. Das 9B ist fähiger, als die kursierenden Tests behaupten, sobald man ihm ein ordentliches Template gibt. Der Reiz liegt nicht im Benchmark, sondern in der Idee dahinter. Ein Modell, das sein eigenes Gerüst schreibt, ist ein anderer Ansatz als eines, das nur bessere Antworten lernt. Version eins zeigt, dass der Ansatz funktioniert. Ob er die Lücke zur Frontier schließt, wird die nächste Version zeigen müssen, und die Zahlen dazu sollten dann von jemand anderem als dem Hersteller kommen.

Quellen

• DeepReinforce, Ornith-1.0-Blog (Primärquelle): deep-reinforce.com/ornith_1_0.html
• Modellgewichte: huggingface.co/deepreinforce-ai/Ornith-1.0-9B-GGUF
• Simon Willison, unabhängiger Ersteindruck: simonwillison.net/2026/Jun/29/ornith
• MarkTechPost, Ornith-Release und Einordnung: marktechpost.com
• Codersera, lokale Deployment-Anleitung: codersera.com
• GRPO, Ursprungspaper (DeepSeekMath): arxiv.org/abs/2402.03300
• SWE-Bench: swebench.com
• DSpark, VentureBeat: venturebeat.com
• DSpark, MarkTechPost: marktechpost.com
• DSpark, kritische Einordnung (xyzlabs): xyzlabs.substack.com
• Unabhängige Hands-on-Tests (Video): Sam Witteveen, Cloud Codes, TheAIGRID, Working Models, Luke’s Dev Lab
• Eigene Messungen: Ornith-1.0-9B und -35B auf M3 Max (64 GB), 4. Juli 2026. GGUF (Q4_K_M) via Ollama sowie MLX 4bit via mlx_lm.