2 points par GN⁺ 4 시간 전 | 1 commentaires | Partager sur WhatsApp
  • Ornith-1.0 est une famille de modèles open source auto-améliorants pour le codage agentique, disponible en configurations 9B Dense, 31B Dense, 35B MoE et 397B MoE, post-entraînée sur Gemma 4 et Qwen 3.5
  • Son framework d’entraînement repose sur le reinforcement learning et apprend à générer non seulement des rollouts de solution, mais aussi le scaffold qui guide ces rollouts, afin d’optimiser conjointement le scaffold et la solution produite
  • D’après le README, Ornith-1.0 atteint des performances de pointe sur des benchmarks de code comme Terminal-Bench 2.1, SWE-Bench, NL2Repo et OpenClaw face à des modèles open source de taille comparable
  • Tous les checkpoints exposent une interface compatible OpenAI, prennent en charge une fenêtre de contexte de 256K tokens et peuvent être exécutés avec vLLM, SGLang, Hugging Face Transformers, llama.cpp, Ollama, etc.
  • Sous licence MIT, accessible dans le monde entier sans restriction géographique, il permet de séparer le bloc de raisonnement et les appels d’outils via reasoning_content et tool_calls, pour l’intégrer à des frameworks agentiques et à des CLI de codage

Vue d’ensemble du modèle et méthode d’entraînement

  • Ornith-1.0 est une famille de modèles open source auto-améliorants pour le codage agentique
  • Les tailles proposées sont 9B Dense, 31B Dense, 35B MoE et 397B MoE, avec un post-entraînement sur Gemma 4 et Qwen 3.5
  • Le framework d’auto-amélioration utilise le reinforcement learning
    • Le modèle est entraîné à générer non seulement des rollouts de solution, mais aussi le scaffold qui guide ces rollouts
    • Le scaffold et la solution finale sont optimisés ensemble afin de trouver de meilleures trajectoires de recherche et des solutions de plus haute qualité
  • La licence est MIT, avec un accès mondial sans restriction régionale

Résultats de benchmark

  • Chaque modèle a été comparé à un modèle de référence de taille équivalente, et les trois modèles ont utilisé le même harness et les mêmes paramètres de décodage
  • Ornith-1.0-9B

    • Sur Terminal-Bench 2.1, il obtient 43.1 selon Terminus-2 et 40.6 selon Claude Code
    • Il obtient 69.4 sur SWE-bench Verified, 42.9 sur SWE-bench Pro et 52 sur SWE-bench Multilingual
    • Il obtient 27.2 sur NL2Repo et 63.1 de moyenne sur Claw-eval
    • Sur SWE Atlas, il obtient 17.9 en QnA, 16.6 en RF et 15.3 en TW
  • Ornith-1.0-35B

    • Sur Terminal-Bench 2.1, il obtient 64.2 selon Terminus-2 et 62.8 selon Claude Code
    • Il obtient 75.6 sur SWE-bench Verified, 50.4 sur SWE-bench Pro et 69.3 sur SWE-bench Multilingual
    • Il obtient 34.6 sur NL2Repo et 69.8 de moyenne sur Claw-eval
    • Sur SWE Atlas, il obtient 37.1 en QnA, 29.7 en RF et 27.8 en TW
  • Ornith-1.0-397B

    • Sur Terminal-Bench 2.1, il obtient 77.5 selon Terminus-2 et 78.2 selon Claude Code
    • Il obtient 82.4 sur SWE-bench Verified, 62.2 sur SWE-bench Pro et 78.9 sur SWE-bench Multilingual
    • Il obtient 48.2 sur NL2Repo et 77.1 de moyenne sur Claw-eval
    • Sur SWE Atlas, il obtient 41.2 en QnA, 42.6 en RF et 39.1 en TW

Configuration d’évaluation

  • L’évaluation Terminal-Bench 2.1 Terminus-2 utilise le framework Harbor/Terminus-2, parser=json, temperature=1.0, top_p=1.0 et une fenêtre de contexte de 128K
    • Chaque exécution utilise un timeout de 4 heures, 32 cœurs CPU, 48 Go de RAM, et les scores sont des moyennes sur 5 essais
    • Le template de chat Qwen a été ajusté pour assurer la cohérence entre entraînement et inférence, et Harbor a été modifié pour s’aligner sur la clé reasoning_content de vLLM
  • L’évaluation Terminal-Bench 2.1 Claude Code utilise Claude Code 2.1.126, parser=json, temperature=1.0, top_p=1.0, max_new_tokens=131072, avec une moyenne sur 5 essais
  • SWE-bench Verified / Pro / Multilingual utilise le harness OpenHands, temperature=1.0, top_p=0.95 et une fenêtre de contexte de 256K
  • SWE Atlas QnA / RF / TW utilise le harness mini-SWE-agent, temperature=1.0, top_p=0.95, une fenêtre de contexte de 128K, avec une moyenne sur 5 essais
  • NL2Repo utilise temperature=1.0, top_p=1.0, un contexte de 400K, une sortie de 48K et des filtres anti-hacking
  • ClawEval est un benchmark de code agentique fondé sur la distribution de tâches d’utilisateurs réels, avec temperature=0.6 et un contexte de 256K

Exécution et checkpoints

  • Ornith-1.0 est un reasoning model et, par défaut, le tour assistant commence par un bloc <think> … </think> avant de renvoyer la réponse finale
  • La recette de serving active un reasoning parser pour renvoyer la chaîne de pensée dans un champ reasoning_content séparé, ainsi qu’un parser d’appels d’outils pour exposer les blocs <tool_call> sous forme de tool_calls au style OpenAI
  • Les versions d’exécution requises sont les suivantes
    • Transformers ≥ 5.8.1
    • vLLM ≥ 0.19.1
    • SGLang ≥ 0.5.9
  • Les paramètres d’échantillonnage recommandés sont temperature=0.6, top_p=0.95, top_k=20
    • Pour reproduire les réglages des benchmarks rapportés, il faut utiliser temperature=1.0
  • Tous les checkpoints exposent la même interface compatible OpenAI et prennent en charge une fenêtre de contexte de 256K, soit 262,144 tokens
    • Le Dense 9B convient à un unique GPU de 80 Go
    • Les checkpoints MoE sont répartis sur des nœuds multi-GPU via tensor parallelism
  • Checkpoints disponibles
    • Ornith-1.0-9B : Dense ~9B, bf16, pour serving sur GPU unique et fine-tuning
    • Ornith-1.0-9B-GGUF : Dense ~9B, quantification GGUF, pour inférence locale avec llama.cpp / Ollama
    • Ornith-1.0-35B : MoE 35B, bf16, pour serving full-precision sur plusieurs GPU
    • Ornith-1.0-35B-FP8 : MoE 35B, FP8, pour réduire d’environ moitié la VRAM sur des GPU compatibles FP8
    • Ornith-1.0-35B-GGUF : MoE 35B, quantification GGUF, pour inférence locale avec llama.cpp / Ollama
    • Ornith-1.0-397B : MoE 397B, bf16, pour serving full-precision sur nœuds multi-GPU
    • Ornith-1.0-397B-FP8 : MoE 397B, FP8, pour un serving plus efficace en mémoire sur des GPU compatibles FP8

API compatible OpenAI et usage agentique

  • Une fois le serveur vLLM ou SGLang lancé, il est possible d’appeler l’endpoint /v1/chat/completions avec un client compatible OpenAI
  • L’exemple de serveur local utilise base_url="http://localhost:8000/v1";, api_key="EMPTY", model="Ornith-1.0"
  • Dans le message de réponse, reasoning_content contient la trace de raisonnement <think>, tandis que content contient la réponse finale
  • Si des outils sont fournis, Ornith-1.0 génère des appels de fonction bien formés, que le serveur analyse dans le champ standard tool_calls
  • Les SDK compatibles OpenAI peuvent utiliser le même endpoint en Python, Node.js, curl, etc.

Frameworks pris en charge et CLI de codage

  • Ornith-1.0 est optimisé pour les appels d’outils et les capacités de codage agentique
  • Comme il fournit un endpoint compatible OpenAI et le tool calling, il peut être utilisé avec des frameworks agentiques standards
  • Le README inclut des exemples de connexion d’outils via un serveur MCP et un exemple d’appel de l’outil de fonction run_shell
  • Les harness et runtimes agentiques proposés en exemple sont les suivants
    • Hermes Agent : configuration OPENAI_BASE_URL, OPENAI_API_KEY, MODEL="Ornith-1.0"
    • OpenHands : utilisation du chemin openai/Ornith-1.0 de LiteLLM et d’une base URL locale
    • llama.cpp / Ollama : chargement des builds GGUF 9B et 35B pour l’inférence locale
    • Unsloth Studio : inférence locale ou fine-tuning avec FastLanguageModel.from_pretrained
    • OpenClaw : définition de l’endpoint compatible OpenAI vers un serveur Ornith
  • Les CLI de codage peuvent s’y connecter en pointant OPENAI_BASE_URL et OPENAI_API_KEY vers l’endpoint Ornith-1.0
  • L’exemple OpenCode enregistre un provider local Ornith dans ~/.config/opencode/opencode.json et utilise le modèle Ornith-1.0

1 commentaires

 
GN⁺ 4 시간 전
Avis sur Hacker News
  • Discussion précédente : https://news.ycombinator.com/item?id=48709744
    https://swelljoe.com/post/will-it-mythos/ : « Les performances sont plutôt mauvaises : il n’a trouvé qu’un seul bug, que presque tous les modèles avaient trouvé. Et ce malgré d’excellents résultats sur d’autres benchmarks au regard de sa taille. […] Il est aussi mauvais en chat sans outils, et hallucine assez activement. Je suis en train de reproduire les tests en lui donnant un accès complet aux outils, dont bash/Python ; dans ce cas, ce modèle pourrait être compétitif »

    • C’est étrange qu’en 2026 on dise sérieusement « il est mauvais en chat sans outils ». Je ne sais pas si ce fine-tuning est bon, je ne l’ai pas essayé moi-même, mais tester un modèle agentique sans accès aux outils et espérer que ça marche n’a clairement aucun sens, non ? Je ne vois pas ce qui a été testé, au juste
    • Ce benchmark place Kimi K2.6 et K2.7 Code presque tout en bas. Les deux sont classés sous Ornith 35B, et Gemma 4 26B y est évalué bien au-dessus de GLM-5.2. Les résultats ne me paraissent pas très convaincants
  • C’est le premier fine-tuning de Qwen qui n’a pas été rejeté immédiatement par la communauté des LLM locaux, et qui est même recommandé dans certains cas. D’après mon usage limité, il est correct et propose des solutions créatives aux problèmes de code. Je ne m’attends pas à ce qu’un modèle 9–35B me crée une application entière en un clic. La plupart des critiques semblent venir de ce genre d’attentes

    • La communauté des LLM locaux a été envahie par d’anciens vendeurs de cryptomonnaies/NFT, qui ont apporté avec eux la culture de l’exagération de leurs communautés précédentes. Il reste encore des techniciens solides, mais ils sont de plus en plus noyés sous un marketing creux
    • Malheureusement, c’est comme ça depuis le début. Il n’y a rien de nocif à tester des modèles locaux sur des tâches locales, avec des garde-fous raisonnables
      Pour la plupart des modèles comme Qwen, Gemma, Llama ou gpt-oss, trouver les petits pièges liés aux tokens spéciaux, à la structure des prompts et aux préférences du modèle est aujourd’hui vraiment fastidieux. Mais on peut quand même obtenir un modèle qui fonctionne très bien dans un environnement d’exécution agentique ajusté avec des prompts et des paramètres appris à la dure
    • Ça ne s’est pas amélioré. La majorité de la communauté LocalLLama n’apprécie pas vraiment ça ; seuls quelques nouveaux venus publient à ce sujet
    • On dirait que nous sommes dans des communautés différentes. Les modèles Qwen font partie des modèles les plus recommandés parmi ceux qu’on peut réellement faire tourner sur du matériel local accessible au grand public
  • Pourquoi ces modèles à « auto-amélioration » ne finissent-ils jamais par s’améliorer au point de dépasser les modèles de pointe ?

  • D’après mes propres tests, Ornith-1.0 35B était légèrement meilleur que Qwen-3.6 35B
    Mes tests consistent à ajouter ou modifier des fonctionnalités dans une grosse base de code C++. Ce qui est intéressant, c’est que ce modèle est beaucoup plus rapide que Qwen3.6 35B. Ornith semble produire des chaînes de pensée plus courtes
    Dans mes tests, il générait les réponses jusqu’à 3 fois plus vite. Je l’utilise avec llamacpp et codex-cli

  • J’ai testé Ornith-1.0 35B avec une quantification par blocs FP8 que j’ai faite moi-même, et il me plaît. Sur une RTX PRO 6000 (sm120), j’obtiens plus de 200 tokens/s avec vLLM, et ces derniers jours j’ai fait passer plus de 140 millions de tokens en cache sur des tâches de codage agentique
    Il me semble se situer à peu près entre Qwen 3.6 35B-A3B et 27B, mais le point positif, c’est qu’il réfléchit beaucoup moins à l’excès et tombe beaucoup moins souvent dans la même boucle que Qwen 3.6. En regardant la trace de raisonnement, j’aime bien son modèle d’approche par décomposition
    Sur une base de code Go de taille moyenne, il s’en est bien sorti pour l’analyse de base, le traitement de tâches et certaines modifications frontend/backend, mais il a complètement atteint ses limites sur une tâche plus longue de simple implémentation de kernel. Dans l’environnement d’exécution Pi Agent, il a échoué après environ 100 itérations ; c’est le genre de tâche que des modèles ouverts plus puissants comme Kimi K2.6 ou GLM 5.2 peuvent réussir

    • À cette taille de modèle, l’environnement d’exécution m’a semblé plus important. Personnellement, avec qwen3.6 27b, je suis passé de pi brut à little-coder ; ça vaut le coup d’y jeter un œil
  • Quelqu’un peut-il expliquer ce qui s’est passé ici ? Est-ce simplement Qwen avec une couche de rebranding ? Qui est deepreinforce-ai, et pourquoi ce modèle n’apparaît-il pas sur leur site web ?
    Je me demande en quoi consiste l’auto-amélioration. Le modèle sur disque change-t-il, ou ne s’améliore-t-il que pendant une exécution dans un contexte unique ?

    • Il ne s’auto-améliore pas. Le titre est trompeur
      À mon avis, ils ont entraîné Qwen et Gemma 4 avec leur propre apprentissage par renforcement. Je ne sais pas comment ils ont combiné les poids des deux, ni même s’ils ont pris Qwen comme base et utilisé Gemma 4 comme aide à l’entraînement. Ici, « auto-amélioration » semble désigner le processus d’entraînement, pas la manière dont les poids sont utilisés
  • Ceux-là ressemblent simplement à des versions de Qwen ou Gemma 4 optimisées pour les benchmarks

    • Si c’est le cas, c’est impressionnant d’avoir encore poussé Qwen, qui est déjà assez optimisé pour les benchmarks
  • « Un modèle dense 9B tient sur un seul GPU de 80 Go »
    Les gens ordinaires comme nous ne peuvent pas l’utiliser

    • Ça semble bizarre. Un modèle 9B tient généralement sur un GPU de 24 Go même sans quantification
    • Il existe déjà des versions quantifiées
  • J’ai beaucoup utilisé de modèles locaux et ils m’ont tous donné l’impression d’être des jouets. Mais celui-ci m’a paru réellement utile. J’ai aussi entendu dire que Qwen 36-A3B était bon, mais je ne l’ai pas encore essayé

  • Les systèmes auto-améliorants sont intéressants, mais ils rendent le suivi de provenance et la gouvernance beaucoup plus difficiles. Si un agent peut modifier son comportement au fil du temps, comprendre pourquoi il a agi d’une certaine manière devient de plus en plus important