Ornith-1.0 - エージェント型コーディングのための自己改善オープンソースモデル

 (github.com/deepreinforce-ai)
2 ポイント 投稿者 GN⁺ 4 시간 전 | 1件のコメント | WhatsAppで共有
  • Ornith-1.0は、エージェント型コーディング向けの自己改善オープンソースモデルで、9B Dense、31B Dense、35B MoE、397B MoEの構成を提供し、Gemma 4とQwen 3.5の上でポストトレーニングされている
  • 学習フレームワークは強化学習により、ソリューションのrolloutだけでなくrolloutを導くスキャフォールド（scaffold）まで生成するよう学習し、スキャフォールドと結果ソリューションを一緒に最適化する
  • READMEによると、Ornith-1.0はTerminal-Bench 2.1、SWE-Bench、NL2Repo、OpenClawなどのコーディングベンチマークで、同程度のサイズのオープンソースモデルと比べて最先端の性能を達成している
  • すべてのチェックポイントはOpenAI互換インターフェースを公開し、256Kトークンのコンテキストウィンドウをサポートし、vLLM、SGLang、Hugging Face Transformers、llama.cpp、Ollamaなどで実行可能
  • MITライセンスで、地域制限なく世界中からアクセス可能であり、reasoning_contentとtool_callsにより推論ブロックとツール呼び出しを分離して、エージェントフレームワークやコーディングCLIに接続できる

モデル概要と学習方式

  • Ornith-1.0は、エージェント型コーディングのための自己改善オープンソースモデル群
  • 提供されるモデルサイズは9B Dense、31B Dense、35B MoE、397B MoEで、Gemma 4とQwen 3.5の上でポストトレーニングされている
  • 自己改善学習フレームワークは強化学習を使用する
    • モデルはソリューションのrolloutだけでなく、rolloutを導く**スキャフォールド（scaffold）**も生成するよう学習する
    • スキャフォールドと結果ソリューションを一緒に最適化し、より良い探索軌跡とより高品質なソリューションを見つけるようにする
  • ライセンスはMITで、世界中からアクセス可能かつ地域制限はない

ベンチマーク結果

  • 各モデルはサイズに応じた基準モデルと比較され、3つのモデルは同一のハーネスとデコーディング設定を使用した

  • Ornith-1.0-9B

    • Terminal-Bench 2.1でTerminus-2基準43.1、Claude Code基準40.6を記録
    • SWE-bench Verified 69.4、SWE-bench Pro 42.9、SWE-bench Multilingual 52を記録
    • NL2Repo 27.2、Claw-eval Avg 63.1を記録
    • SWE AtlasはQnA 17.9、RF 16.6、TW 15.3を記録

  • Ornith-1.0-35B

    • Terminal-Bench 2.1でTerminus-2基準64.2、Claude Code基準62.8を記録
    • SWE-bench Verified 75.6、SWE-bench Pro 50.4、SWE-bench Multilingual 69.3を記録
    • NL2Repo 34.6、Claw-eval Avg 69.8を記録
    • SWE AtlasはQnA 37.1、RF 29.7、TW 27.8を記録

  • Ornith-1.0-397B

    • Terminal-Bench 2.1でTerminus-2基準77.5、Claude Code基準78.2を記録
    • SWE-bench Verified 82.4、SWE-bench Pro 62.2、SWE-bench Multilingual 78.9を記録
    • NL2Repo 48.2、Claw-eval Avg 77.1を記録
    • SWE AtlasはQnA 41.2、RF 42.6、TW 39.1を記録

評価設定

  • Terminal-Bench 2.1 Terminus-2評価は、Harbor/Terminus-2フレームワーク、parser=json、temperature=1.0、top_p=1.0、128Kコンテキストウィンドウを使用
    • 各実行は4時間のtimeout、32 CPUコア、48GB RAMを使用し、5回平均
    • Qwen chat templateは学習と推論の一貫性のために調整され、HarborはvLLMのreasoning_contentキーに合わせるよう修正された
  • Terminal-Bench 2.1 Claude Code評価は、Claude Code 2.1.126、parser=json、temperature=1.0、top_p=1.0、max_new_tokens=131072を使用し、5回平均
  • SWE-bench Verified / Pro / Multilingualは、OpenHandsハーネス、temperature=1.0、top_p=0.95、256Kコンテキストウィンドウを使用
  • SWE Atlas QnA / RF / TWは、mini-SWE-agentハーネス、temperature=1.0、top_p=0.95、128Kコンテキストウィンドウを使用し、5回平均
  • NL2Repoは、temperature=1.0、top_p=1.0、400Kコンテキスト、48K出力、anti-hacking filtersを使用
  • ClawEvalは、実際のユーザー作業分布に基づくエージェント型コードベンチマークで、temperature=0.6、256Kコンテキストを使用

実行とチェックポイント

  • Ornith-1.0はreasoning modelであり、デフォルトではassistant turnが<think> … </think>ブロックで始まった後、最終回答を返す
  • サービングレシピはreasoning parserを有効化してchain-of-thoughtを別個のreasoning_contentフィールドとして返し、tool-call parserを有効化して<tool_call>ブロックをOpenAIスタイルのtool_callsとして公開する
  • 必要なランタイムバージョンは以下の通り
    • Transformers ≥ 5.8.1
    • vLLM ≥ 0.19.1
    • SGLang ≥ 0.5.9
  • 推奨サンプリングパラメータはtemperature=0.6、top_p=0.95、top_k=20
    • 報告されたベンチマーク設定を再現するにはtemperature=1.0を使用する
  • すべてのチェックポイントは同じOpenAI互換インターフェースを公開し、256K、つまり262,144トークンのコンテキストウィンドウをサポートする
    • Dense 9Bは単一の80GB GPUに適している
    • MoEチェックポイントはtensor parallelismによりマルチGPUノードにshardされる
  • 提供チェックポイント
    • Ornith-1.0-9B: Dense約9B、bf16、単一GPUサービングとファインチューニング向け
    • Ornith-1.0-9B-GGUF: Dense約9B、GGUF量子化、llama.cpp / Ollamaローカル推論向け
    • Ornith-1.0-35B: MoE 35B、bf16、full-precisionマルチGPUサービング向け
    • Ornith-1.0-35B-FP8: MoE 35B、FP8、FP8対応GPUでVRAMを約半分に削減するサービング向け
    • Ornith-1.0-35B-GGUF: MoE 35B、GGUF量子化、llama.cpp / Ollamaローカル推論向け
    • Ornith-1.0-397B: MoE 397B、bf16、マルチGPUノードでのfull-precisionサービング向け
    • Ornith-1.0-397B-FP8: MoE 397B、FP8、FP8対応GPUでのメモリ効率の高いサービング向け

OpenAI互換APIとエージェント利用

  • vLLMまたはSGLangサーバーが実行されると、OpenAI互換クライアントで/v1/chat/completionsエンドポイントを呼び出せる
  • ローカルサーバー例ではbase_url="http://localhost:8000/v1";、api_key="EMPTY"、model="Ornith-1.0"を使用する
  • 応答メッセージでreasoning_contentは<think>推論traceを含み、contentは最終回答を含む
  • ツールを渡すとOrnith-1.0はwell-formedな関数呼び出しを生成し、サーバーはこれを標準のtool_callsフィールドとしてパースする
  • OpenAI互換SDKはPython、Node.js、curlなどから同じエンドポイントを使用できる

対応フレームワークとコーディングCLI

  • Ornith-1.0はツール呼び出しとエージェント型コーディング機能に最適化されている
  • OpenAI互換エンドポイントとtool callingを提供するため、標準的なエージェントフレームワークと併用できる
  • READMEにはMCPサーバーを通じたツール接続例とrun_shell関数ツール呼び出し例が含まれる
  • 例として提示されているエージェントハーネスとランタイムは以下の通り
    • Hermes Agent: OPENAI_BASE_URL、OPENAI_API_KEY、MODEL="Ornith-1.0"を設定
    • OpenHands: LiteLLMのopenai/Ornith-1.0パスとローカルbase URLを使用
    • llama.cpp / Ollama: 9Bと35BのGGUFビルドをロードしてローカル推論
    • Unsloth Studio: FastLanguageModel.from_pretrainedでローカル推論またはファインチューニング
    • OpenClaw: OpenAI互換エンドポイントをOrnithサーバーに指定
  • コーディングCLIはOPENAI_BASE_URLとOPENAI_API_KEYをOrnith-1.0エンドポイントに指定して接続できる
  • OpenCodeの例では~/.config/opencode/opencode.jsonにOrnithローカルproviderを登録し、Ornith-1.0モデルを使用する

関連記事

1件のコメント

 
GN⁺ 4 시간 전
Hacker News の意見

  • 以前の議論: https://news.ycombinator.com/item?id=48709744
    https://swelljoe.com/post/will-it-mythos/: 「性能はあまり良くなく、ほぼすべてのモデルが見つけたバグを1つ見つけただけだった。サイズ比で見ると他のベンチマーク性能は優れているにもかかわらずだ。[…] ツールなしのチャットでも性能が悪く、ハルシネーションもかなり激しい。現在は bash/Python を含む完全なツールアクセス権を与えた状態で再現を進めており、それならこのモデルにも競争力があるかもしれない」

    • 2026年に「ツールなしのチャットで性能が悪い」という言い方が真面目に出てくるのは変だ。このファインチューニングが良いかどうかは自分で使っていないので分からないが、明らかにエージェント型モデルをツールアクセスなしでテストして、うまくいくと期待するのはおかしくないか？ いったい何をテストしたのか分からない
    • そのベンチマークは Kimi K2.6 と K2.7 Code をほぼ最下位に置いている。どちらも Ornith 35B より低く、Gemma 4 26B を GLM-5.2 よりはるかに高く評価している。結果にはあまり納得できない

  • これはローカル LLM コミュニティで即座に拒否されなかった初の Qwen ファインチューニングで、場合によっては推奨までされている。限られた範囲で使った限りでは良く、コーディング問題に創造的な解法を出してくれる。9〜35B モデルがワンクリックでアプリ全体を作ってくれるとは期待していない。不満を言っていた人の多くは、そういう期待値から来ているように見える

    • ローカル LLM コミュニティには、昔の暗号資産/NFT の商売人たちが押し寄せてきて、以前のコミュニティの誇大宣伝文化まで一緒に持ち込んでいる。まだ深い知識を持つ技術者たちは残っているが、中身のないマーケティングの声にだんだん埋もれつつある
    • 残念ながら、最初からずっとこんな感じだった。ローカルモデルをローカル作業に、適切なガードレール付きで試してみること自体に害はない
      Qwen、Gemma、Llama、gpt-oss のようなモデルの多くは、特殊トークン、プロンプト構造、モデルの好みといった細かな落とし穴を見つけるのが、今は本当に面倒だ。それでも苦労して身につけたプロンプトとパラメータで調整したエージェント実行環境では、とてもよく動くモデルを得られる
    • 良くなったわけではない。LocalLLama コミュニティの大多数はこれをあまり好んでおらず、新しく来た数人が投稿している程度だ
    • 別々のコミュニティにいるようだ。Qwen モデルは、一般の人が手に入れられるローカルハードウェアで実際に動かせるモデルの中で、最もよく推奨される部類だ

  • こういう「自己改善」モデルは、なぜ結局、最先端モデルを上回るところまで改善されないのだろう？

  • 自分でテストした限りでは、Ornith-1.0 35B は Qwen-3.6 35B より少し良かった
    私のテストは、大きな C++ コードベースに機能を追加したり修正したりする作業だ。興味深いのは、このモデルが Qwen3.6 35B よりずっと速いこと。Ornith はより短い思考過程を作るようだ
    私のテストでは、回答生成速度が最大3倍速かった。llamacpp と codex-cli で使っている

  • Ornith-1.0 35B を自作の FP8 ブロック量子化でテストしてみたが気に入っている。RTX PRO 6000(sm120) 上の vLLM で 200トークン/秒以上出ており、ここ数日でエージェント式コーディング作業としてキャッシュ済みトークンを1.4億個以上回した
    だいたい Qwen 3.6 35B-A3B と 27B の中間くらいに見えるが、良い点は Qwen 3.6 より過剰に考えたり同じループにはまったりすることがずっと少ないことだ。思考トレースを見ると、分解アプローチのテンプレートが気に入っている
    中規模の Go コードベースでは、基本的な分析、タスク処理、一部のフロントエンド/バックエンド変更はうまくこなしたが、より長い単純なカーネル実装作業では完全に限界にぶつかった。Pi Agent 実行環境で約100回反復したが失敗し、こうした作業は Kimi K2.6 や GLM 5.2 のような、より強力な公開モデルならこなせるタイプのものだ

    • このモデルサイズでは、実行環境の方がより重要に見えた。個人的には qwen3.6 27b では生の pi ではなく little-coder に移ったが、一度見てみる価値はある

  • ここで何が起きているのか説明してくれる人はいる？ 単に Qwen の外側だけを変えたものなのか？ deepreinforce-ai とは誰で、なぜこのモデルが彼らのウェブサイトにないのだろう？
    どうやって自己改善するというのか気になる。ディスク上のモデルが変わるのか、それとも単一コンテキストの実行中だけ良くなるのか？

    • 自己改善はしない。タイトルが誤解を招く表現だ
      私には、Qwen と Gemma 4 の上に独自の強化学習を走らせて訓練したように見える。両者の重みをどう結合したのかは分からないし、Qwen をベースにして Gemma 4 を訓練補助に使ったのかも確かではない。ここでいう「自己改善」は重みの使い方ではなく、訓練プロセスを指しているようだ

  • これらは単に Qwen や Gemma 4 をベンチマーク最適化した版に見える

    • だとすれば、すでにベンチマークにかなり最適化されている Qwen をさらに押し進めたという点は印象的だ

  • 「密な 9B が単一の 80GB GPU に収まる」
    私たちのような普通の人には使えなさそうだ

    • 変に見える。9B モデルなら普通、24GB GPU にも非量子化のまま収まる
    • すでに量子化版が出ている

  • ローカルモデルをたくさん使ってみたが、どれもおもちゃのように感じた。だがこれは実際に役に立つという感じがした。Qwen 36-A3B も良いと聞いているが、まだ試せていない

  • 自己改善システムは興味深いが、出所追跡とガバナンスをはるかに難しくする。エージェントが時間とともに自分の行動を変えられるようになると、なぜ特定の方法で振る舞ったのかを理解することがますます重要になる