Ornith-1.5は、コーディングやツール利用を主な対象にしたオープンモデル群です。397BのMixture of Experts（MoE）、1トークンあたり約3Bパラメータを使う35B-A3BのMoE、密な9Bモデルという3段階を揃え、各モデルのカードはMITライセンスで公開されています。(Ornith Blog, 35Bモデルカード)
目を引きやすいのはモデル規模やベンチマークですが、この世代の芯は学習の回し方です。用意された問題を解くだけでなく、次に何を学ぶか、その問題をどう解かせて評価するかまで同じループへ入れています。
課題、足場、解答を一緒に更新する
Ornith-1.5の学習は「課題の生成→課題ごとのscaffold（足場）の構築→解答のrollout」という流れです。scaffoldには、指示、使える道具、問題の分割方法、処理の組み立てが含まれます。解答から得た報酬は前段にも戻り、解答だけでなく、学習に向いた課題と足場も改善します。(Ornith Blog)
自己生成した課題は、単に難しければよいわけではありません。報酬は「正しく実行・検証できるか」「現在の能力の境界にあるか」「既存の課題と重複しないか」の3要素で決まります。難易度の目標はrolloutの成功率0.2。まったく解けない問題では学習信号が乏しく、簡単すぎれば伸びしろがないため、少数の成功例が残る場所を狙う設計です。
評価用のharnessにも別の条件があります。課題との整合、解答品質を正しく報酬へ反映する忠実性、reward hackingへの耐性です。課題生成、harness生成、rolloutは、それぞれの報酬を使ってGRPOで最適化されます。自作問題を自作採点器で高得点にするだけの閉じた循環を避けようとしている点が、この仕組みを読むうえで外せません。
小さいモデルでも、動作条件は先に見る
9Bモデルは約19GBのBF16で、公式カードは単一GPUでの配備と、量子化したMobile版による端末上の実行を案内しています。35B-A3BはBF16で約70GB、397Bは約800GBとされ、同じファミリーでも必要な機材は大きく違います。(9Bモデルカード, 35Bモデルカード, 397Bモデルカード)
ネイティブのコンテキスト長は262,144トークン。vLLMやSGLangではreasoningとtool callを分けたOpenAI互換APIを構成できます。YaRNで約100万トークンまで延ばす例もありますが、公式カードは通常の長さの入力で品質が少し落ちる場合があるため、本当に長い文脈が要るときだけ有効にするよう注意しています。
公開ベンチマークはOrnith側の測定値で、結果は5回の平均と説明されています。数字だけでモデルを選ぶより、まず9Bの量子化版か35B-A3Bを実際のコードとツール構成につなぎ、速度、メモリ、tool callの安定性を確かめるほうが判断しやすいはずです。Ornith-1.5で見るべきなのは、最大モデルの順位だけではなく、課題と評価器まで学習対象にしたループが実運用の失敗をどこまで減らせるかです。