Ornith-1.0 – selbstverbesserndes Open-Source-Modell für agentisches Coding

 (github.com/deepreinforce-ai)
2 Punkte von GN⁺ 4 시간 전 | 1 Kommentare | Auf WhatsApp teilen
  • Ornith-1.0 ist ein selbstverbesserndes Open-Source-Modell für agentisches Coding. Es wird in Konfigurationen mit 9B Dense, 31B Dense, 35B MoE und 397B MoE angeboten und wurde auf Basis von Gemma 4 und Qwen 3.5 nachtrainiert
  • Das Trainings-Framework lernt per Reinforcement Learning, nicht nur Solution-Rollouts zu erzeugen, sondern auch die Scaffolds, die diese Rollouts steuern; dadurch werden Scaffold und resultierende Lösung gemeinsam optimiert
  • Laut README erreicht Ornith-1.0 auf Coding-Benchmarks wie Terminal-Bench 2.1, SWE-Bench, NL2Repo und OpenClaw im Vergleich zu ähnlich großen Open-Source-Modellen State-of-the-Art-Leistung
  • Alle Checkpoints stellen eine OpenAI-kompatible Schnittstelle bereit, unterstützen ein Kontextfenster von 256K Tokens und lassen sich unter anderem mit vLLM, SGLang, Hugging Face Transformers, llama.cpp und Ollama ausführen
  • Das Modell steht unter MIT-Lizenz, ist weltweit ohne regionale Beschränkungen zugänglich und kann über reasoning_content und tool_calls Reasoning-Blöcke und Tool-Aufrufe trennen, um es an Agent-Frameworks und Coding-CLIs anzubinden

Modellüberblick und Trainingsmethode

  • Ornith-1.0 ist eine Familie selbstverbessernder Open-Source-Modelle für agentisches Coding
  • Die angebotenen Modellgrößen sind 9B Dense, 31B Dense, 35B MoE und 397B MoE; sie wurden auf Basis von Gemma 4 und Qwen 3.5 nachtrainiert
  • Das Self-Improvement-Trainingsframework verwendet Reinforcement Learning
    • Das Modell lernt, nicht nur Solution-Rollouts zu erzeugen, sondern auch den Scaffold, der die Rollouts steuert
    • Scaffold und resultierende Lösungen werden gemeinsam optimiert, um bessere Suchtrajektorien und Lösungen höherer Qualität zu finden
  • Die Lizenz ist MIT; der Zugriff ist weltweit möglich und unterliegt keinen regionalen Beschränkungen

Benchmark-Ergebnisse

  • Jedes Modell wurde mit einem größenmäßig passenden Basismodell verglichen; die drei Modelle verwendeten denselben Harness und dieselben Decoding-Einstellungen

  • Ornith-1.0-9B

    • Auf Terminal-Bench 2.1 erzielte es 43,1 nach Terminus-2-Standard und 40,6 nach Claude-Code-Standard
    • Es erzielte 69,4 auf SWE-bench Verified, 42,9 auf SWE-bench Pro und 52 auf SWE-bench Multilingual
    • Es erzielte 27,2 auf NL2Repo und 63,1 im Claw-eval Avg
    • Auf SWE Atlas erzielte es 17,9 bei QnA, 16,6 bei RF und 15,3 bei TW

  • Ornith-1.0-35B

    • Auf Terminal-Bench 2.1 erzielte es 64,2 nach Terminus-2-Standard und 62,8 nach Claude-Code-Standard
    • Es erzielte 75,6 auf SWE-bench Verified, 50,4 auf SWE-bench Pro und 69,3 auf SWE-bench Multilingual
    • Es erzielte 34,6 auf NL2Repo und 69,8 im Claw-eval Avg
    • Auf SWE Atlas erzielte es 37,1 bei QnA, 29,7 bei RF und 27,8 bei TW

  • Ornith-1.0-397B

    • Auf Terminal-Bench 2.1 erzielte es 77,5 nach Terminus-2-Standard und 78,2 nach Claude-Code-Standard
    • Es erzielte 82,4 auf SWE-bench Verified, 62,2 auf SWE-bench Pro und 78,9 auf SWE-bench Multilingual
    • Es erzielte 48,2 auf NL2Repo und 77,1 im Claw-eval Avg
    • Auf SWE Atlas erzielte es 41,2 bei QnA, 42,6 bei RF und 39,1 bei TW

Evaluationssetup

  • Die Bewertung mit Terminal-Bench 2.1 Terminus-2 verwendet das Harbor/Terminus-2-Framework, parser=json, temperature=1.0, top_p=1.0 und ein Kontextfenster von 128K
    • Jeder Lauf nutzt ein Timeout von 4 Stunden, 32 CPU-Kerne und 48GB RAM; berichtet wird der Durchschnitt aus 5 Läufen
    • Das Qwen chat template wurde für Konsistenz zwischen Training und Inferenz angepasst, und Harbor wurde so modifiziert, dass es zum reasoning_content-Key von vLLM passt
  • Die Bewertung mit Terminal-Bench 2.1 Claude Code verwendet Claude Code 2.1.126, parser=json, temperature=1.0, top_p=1.0, max_new_tokens=131072 und den Durchschnitt aus 5 Läufen
  • SWE-bench Verified / Pro / Multilingual verwendet den OpenHands-Harness, temperature=1.0, top_p=0.95 und ein Kontextfenster von 256K
  • SWE Atlas QnA / RF / TW verwendet den mini-SWE-agent-Harness, temperature=1.0, top_p=0.95 und ein Kontextfenster von 128K; berichtet wird der Durchschnitt aus 5 Läufen
  • NL2Repo verwendet temperature=1.0, top_p=1.0, 400K Kontext, 48K Ausgabe und anti-hacking filters
  • ClawEval ist ein agentischer Code-Benchmark auf Basis der Verteilung realer Nutzeraufgaben und verwendet temperature=0.6 sowie 256K Kontext

Ausführung und Checkpoints

  • Ornith-1.0 ist ein reasoning model; standardmäßig beginnt der assistant turn mit einem <think> … </think>-Block und gibt danach die endgültige Antwort zurück
  • Das Serving-Rezept aktiviert den reasoning parser, damit Chain-of-Thought in einem separaten Feld reasoning_content zurückgegeben wird, und den tool-call parser, damit <tool_call>-Blöcke als OpenAI-artige tool_calls offengelegt werden
  • Die erforderlichen Runtime-Versionen sind:
    • Transformers ≥ 5.8.1
    • vLLM ≥ 0.19.1
    • SGLang ≥ 0.5.9
  • Empfohlene Sampling-Parameter sind temperature=0.6, top_p=0.95, top_k=20
    • Um die berichteten Benchmark-Einstellungen zu reproduzieren, wird temperature=1.0 verwendet
  • Alle Checkpoints stellen dieselbe OpenAI-kompatible Schnittstelle bereit und unterstützen ein Kontextfenster von 256K, also 262.144 Tokens
    • Dense 9B eignet sich für eine einzelne 80GB-GPU
    • MoE-Checkpoints werden per tensor parallelism auf Multi-GPU-Knoten geshardet
  • Verfügbare Checkpoints
    • Ornith-1.0-9B: Dense ca. 9B, bf16, für Single-GPU-Serving und Fine-Tuning
    • Ornith-1.0-9B-GGUF: Dense ca. 9B, GGUF-Quantisierung, für lokale Inferenz mit llama.cpp / Ollama
    • Ornith-1.0-35B: MoE 35B, bf16, für Full-Precision-Serving auf mehreren GPUs
    • Ornith-1.0-35B-FP8: MoE 35B, FP8, für Serving mit etwa halbiertem VRAM-Bedarf auf GPUs mit FP8-Unterstützung
    • Ornith-1.0-35B-GGUF: MoE 35B, GGUF-Quantisierung, für lokale Inferenz mit llama.cpp / Ollama
    • Ornith-1.0-397B: MoE 397B, bf16, für Full-Precision-Serving auf Multi-GPU-Knoten
    • Ornith-1.0-397B-FP8: MoE 397B, FP8, für speichereffizientes Serving auf GPUs mit FP8-Unterstützung

OpenAI-kompatible API und Agent-Nutzung

  • Sobald ein vLLM- oder SGLang-Server läuft, kann der Endpoint /v1/chat/completions mit einem OpenAI-kompatiblen Client aufgerufen werden
  • Das Beispiel für einen lokalen Server verwendet base_url="http://localhost:8000/v1";, api_key="EMPTY" und model="Ornith-1.0"
  • In der Antwortnachricht enthält reasoning_content den <think>-Reasoning-Trace, während content die endgültige Antwort enthält
  • Wenn Tools übergeben werden, erzeugt Ornith-1.0 wohlgeformte Funktionsaufrufe, und der Server parst sie in das standardisierte Feld tool_calls
  • OpenAI-kompatible SDKs können denselben Endpoint aus Python, Node.js, curl und anderen Umgebungen nutzen

Unterstützte Frameworks und Coding-CLIs

  • Ornith-1.0 ist für Tool-Aufrufe und agentische Coding-Funktionen optimiert
  • Da es einen OpenAI-kompatiblen Endpoint und Tool Calling bereitstellt, kann es mit Standard-Agent-Frameworks verwendet werden
  • Das README enthält Beispiele für Tool-Anbindungen über MCP-Server sowie für Tool-Aufrufe der Funktion run_shell
  • Als Beispiele genannte Agent-Harnesses und Runtimes sind:
    • Hermes Agent: Konfiguration von OPENAI_BASE_URL, OPENAI_API_KEY, MODEL="Ornith-1.0"
    • OpenHands: Nutzung des LiteLLM-Pfads openai/Ornith-1.0 und einer lokalen Base URL
    • llama.cpp / Ollama: Laden der 9B- und 35B-GGUF-Builds für lokale Inferenz
    • Unsloth Studio: lokale Inferenz oder Fine-Tuning mit FastLanguageModel.from_pretrained
    • OpenClaw: Festlegen des OpenAI-kompatiblen Endpoints auf den Ornith-Server
  • Coding-CLIs können angebunden werden, indem OPENAI_BASE_URL und OPENAI_API_KEY auf den Ornith-1.0-Endpoint gesetzt werden
  • Das OpenCode-Beispiel registriert in ~/.config/opencode/opencode.json einen lokalen Ornith-Provider und verwendet das Modell Ornith-1.0

Verwandte Beiträge

1 Kommentare

 
GN⁺ 4 시간 전
Hacker-News-Kommentare

  • Frühere Diskussion: https://news.ycombinator.com/item?id=48709744
    https://swelljoe.com/post/will-it-mythos/: „Die Leistung ist eher schwach, es wurde nur ein einziger Bug gefunden, den fast jedes Modell gefunden hat. Gemessen an der Größe sind die Ergebnisse in anderen Benchmarks hervorragend, trotzdem ist das hier so. […] Selbst im Chat ohne Tools ist die Leistung schlecht, und das Modell halluziniert ziemlich fleißig. Ich reproduziere das Ganze gerade mit vollständigem Tool-Zugriff einschließlich bash/Python; dann könnte dieses Modell auch konkurrenzfähig sein.“

    • Es ist schon seltsam, dass man im Jahr 2026 ernsthaft sagt: „Im Chat ohne Tools ist die Leistung schlecht.“ Ich weiß nicht, ob dieses Fine-Tuning gut ist, weil ich es selbst nicht benutzt habe, aber ein klar agentisches Modell ohne Tool-Zugriff zu testen und zu erwarten, dass es gut abschneidet, ergibt doch keinen Sinn. Ich verstehe nicht, was da überhaupt getestet wurde
    • Dieser Benchmark setzt Kimi K2.6 und K2.7 Code fast ans Ende. Beide liegen unter Ornith 35B, und Gemma 4 26B wird deutlich höher bewertet als GLM-5.2. Die Ergebnisse wirken nicht besonders plausibel

  • Das ist das erste Qwen-Fine-Tuning, das in der lokalen LLM-Community nicht sofort abgelehnt wurde, und in manchen Fällen wird es sogar empfohlen. Nach meiner begrenzten Nutzung ist es ordentlich und liefert kreative Lösungen für Coding-Probleme. Ich erwarte nicht, dass ein 9- bis 35B-Modell mit einem Klick eine ganze App baut. Die meisten Beschwerden scheinen aus genau solchen Erwartungen zu kommen

    • In die lokale LLM-Community sind frühere Krypto-/NFT-Händler hineingeströmt und haben die Übertreibungskultur ihrer alten Community gleich mitgebracht. Es gibt dort immer noch technisch versierte Leute, aber sie gehen zunehmend im leeren Marketing-Lärm unter
    • Leider war es von Anfang an mehr oder weniger so. Es schadet nicht, lokale Modelle für lokale Aufgaben mit angemessenen Schutzmechanismen auszuprobieren
      Bei den meisten Modellen wie Qwen, Gemma, Llama oder gpt-oss ist es momentan wirklich mühsam, all die kleinen Fallstricke bei Spezial-Token, Prompt-Struktur und Modellpräferenzen herauszufinden. Aber in einer mühsam erlernten und über Parameter abgestimmten agentischen Laufzeitumgebung kann man ein Modell bekommen, das sehr gut funktioniert
    • Es ist nicht besser geworden. Die Mehrheit der LocalLLama-Community mag das nicht besonders, und nur ein paar Neuankömmlinge posten dazu
    • Wir scheinen in unterschiedlichen Communities zu sein. Qwen-Modelle gehören zu den am häufigsten empfohlenen Modellen, die man auf für die breite Masse zugänglicher lokaler Hardware tatsächlich betreiben kann

  • Warum verbessern sich solche „selbstverbessernden“ Modelle am Ende nie so weit, dass sie besser werden als Spitzenmodelle?

  • Nach meinen eigenen Tests war Ornith-1.0 35B etwas besser als Qwen-3.6 35B
    Meine Tests bestehen aus Aufgaben, bei denen in einer großen C++-Codebasis Funktionen ergänzt oder geändert werden. Interessant ist, dass dieses Modell viel schneller ist als Qwen3.6 35B. Ornith scheint kürzere Denkprozesse zu erzeugen
    In meinen Tests war es bei der Antworterzeugung bis zu dreimal schneller. Ich nutze es mit llamacpp und codex-cli

  • Ich habe Ornith-1.0 35B mit einer selbst erstellten FP8-Blockquantisierung getestet und bin zufrieden. Auf einer RTX PRO 6000(sm120) erreiche ich mit vLLM über 200 Token/s und habe in den letzten Tagen bei agentischem Coding mehr als 140 Millionen gecachte Token verarbeitet
    Es wirkt ungefähr zwischen Qwen 3.6 35B-A3B und 27B, aber positiv ist, dass es deutlich seltener übermäßig nachdenkt oder in derselben Schleife hängen bleibt als Qwen 3.6. Wenn man die Trace des Denkprozesses ansieht, gefällt mir die Vorlage für den zerlegenden Ansatz
    In einer mittelgroßen Go-Codebasis hat es grundlegende Analyse, Aufgabenbearbeitung und einige Frontend-/Backend-Änderungen gut erledigt, ist aber bei längeren Aufgaben zur Implementierung einfacher Kernel komplett an seine Grenzen gestoßen. Ich habe es in der Pi-Agent-Laufzeitumgebung etwa 100 Mal probiert, und es hat versagt; solche Aufgaben schaffen stärkere offene Modelle wie Kimi K2.6 oder GLM 5.2

    • Bei dieser Modellgröße schien mir die Laufzeitumgebung wichtiger zu sein. Ich persönlich bin bei qwen3.6 27b von rohem pi auf little-coder umgestiegen; einen Blick ist das wert

  • Kann jemand erklären, was hier eigentlich passiert ist? Ist das einfach nur Qwen mit neuer Verpackung? Wer ist deepreinforce-ai, und warum ist dieses Modell nicht auf deren Website zu finden?
    Mich interessiert, wie genau die Selbstverbesserung funktionieren soll. Ändert sich das Modell auf der Festplatte, oder wird es nur innerhalb einer einzelnen Kontextausführung besser?

    • Es verbessert sich nicht selbst. Der Titel ist irreführend formuliert
      Soweit ich es sehe, haben sie ihr eigenes Reinforcement Learning auf Qwen und Gemma 4 laufen lassen und darauf trainiert. Ich weiß nicht, wie sie die Gewichte der beiden kombiniert haben, und auch nicht sicher, ob Qwen die Basis ist und Gemma 4 nur als Trainingshilfe diente. „Selbstverbesserung“ bezieht sich hier offenbar auf den Trainingsprozess, nicht auf die Art, wie die Gewichte verwendet werden

  • Das sieht einfach nach auf Benchmarks optimierten Versionen von Qwen oder Gemma 4 aus

    • Falls ja, ist es schon beeindruckend, dass sie ein ohnehin bereits stark benchmark-optimiertes Qwen noch weiter pushen konnten

  • „Ein dichtes 9B passt auf eine einzelne 80-GB-GPU“
    Also nichts für normale Leute wie uns

    • Wirkt seltsam. Ein 9B-Modell passt normalerweise auch unquantisiert auf eine 24-GB-GPU
    • Es gibt bereits quantisierte Versionen

  • Ich habe viele lokale Modelle benutzt, und alle wirkten wie Spielzeug. Dieses hier fühlte sich aber tatsächlich nützlich an. Qwen 36-A3B soll auch gut sein, aber ich habe es noch nicht ausprobiert

  • Selbstverbesserungssysteme sind interessant, machen Herkunftsnachverfolgung und Governance aber viel schwieriger. Wenn Agenten ihr Verhalten im Laufe der Zeit selbst verändern können, wird es immer wichtiger zu verstehen, warum sie sich auf eine bestimmte Weise verhalten haben