Ornith-1.5 必要スペック早見表

Ornith-1.5はVRAM 8GB〜800GBの幅で動く。オンデバイス検証なら9BをQ4量子化で8GB級GPUから動かせ、個人・小規模チームのローカルエージェント用途では35B-A3BのQ4で24〜32GB級が現実的な第一候補になる。

上表は262,144トークンのcontextを使い切らない、短〜中程度のcontextを前提にした目安である。262K contextを実際に使うとKVキャッシュが重みとは別に大きく積み上がるため、長context運用ではVRAMをさらに上積みするか、KVキャッシュ量子化の併用を検討してほしい。量子化後サイズはあくまで概算であり、実際の消費量は実装・バッチサイズ・context長で変動する。

DeepReinforce（Hugging Face org: ornith-ai）が2026年8月20日に公開したオープンウェイトLLMシリーズ。35Bの重みは8月19〜20日にHugging Faceへ掲載された。ライセンスはMIT。ラインナップはDenseの9B、MoEの35B-A3B（総パラメータ約35B・活性パラメータ約3B）、MoEの397Bの3サイズで、いずれもQwen3.5およびGemma 4をベースに継続事前学習と強化学習を行っている。context長は3サイズとも262,144トークンで、YaRN factor 4.0適用でおよそ1Mトークンまで拡張可能。9BにはさらにiOS / Android向けのOrnith-1.5-9B-Mobileバリアントがあり、35B-A3Bは79種類の量子化版がllama.cpp / Ollama / LM Studio互換で公開されている。

Ornith-1.5の核は自己改善（self-improving）ループにある。訓練中にモデル自身が「①自分の解答履歴を分析してより難しいタスクを自分で生成する」「②そのタスク専用のscaffold（指示・ツール・分解戦略）を自分で構築する」「③その scaffold のもとで実際に解く」という3つの工程を同時に学習し、解答に対する報酬がGRPOでこの3段階すべてに逆伝播する。開発元はこの仕組みを「data flywheel」と呼んでいる。

前世代のOrnith-1.0は「解のrolloutに加えてscaffolding自体も最適化する」設計だったが、Ornith-1.5はそれをタスク生成そのものまで拡張した点が最大の進化点である。モデルが解くべき問題の難易度を自ら引き上げながら学習ループを回すため、人手によるタスク設計への依存が減る構造になっている。

- タスク生成：解答履歴を分析し、現状より難しいタスクを自ら作る
- scaffold構築：そのタスク専用の指示・ツール・分解戦略を自ら設計する
- 求解：構築したscaffoldのもとで実際に問題を解く
- 上記3段階すべてにGRPOで報酬を逆伝播する

前世代Ornith-1.0は2026年6月26日に公開された。1.5との最大の違いは、35Bクラスの内部構造の開示レベルにある。1.0の35BはMoEではあったが活性パラメータ数が公表されておらず、1.5で初めてA3B（活性パラメータ約3B）であることが明示された。これにより「総パラメータは大きいが生成速度は3B級」という35B-A3Bの特性がユーザー側からも把握しやすくなっている。

開発元は397BのTerminal-Bench 2.1スコア86.1が、Claude Opus 4.8の85.0を「わずかに上回る」と主張しており、この値は「5回の独立実行の平均」だと注記している。また35B-A3Bは同サイズのQwen3.6-35B-A3Bを公開済みのコーディング・エージェント系ベンチ全項目で上回り、Gemma 4-31BやMuse Glimmer-30Bといったより大きなdenseモデルにもエージェンティック・コーディングで差をつけると主張している。ただしこれらはいずれも開発元自身の測定値であり、第三者による独立検証はまだ確立していない点に注意が必要である。

- 9B：単体GPUでの検証・オンデバイス用途向け。Mobileバリアントを含め、まず動作を試す入り口として最適
- 35B-A3B：個人・小規模チームの本命。総パラメータは大きいが活性パラメータが約3Bのため、Q4量子化なら24〜32GB級GPUやMacの統合メモリでも実用速度が出る
- 397B：データセンター前提。TP=8構成の1ノード（例: 8× H200 141GB）を要し、個人利用の対象外

重みサイズの概算は「パラメータ数 × ビット幅 ÷ 8」で求められる（bf16=16bit、Q8=8bit、Q4系はおよそ4〜5bit相当）。MoE構成の35B-A3Bや397Bでは、メモリに載せる重みサイズは総パラメータ数で決まる一方、トークン生成速度は活性パラメータ数で決まる点を混同しないことが重要である。35B-A3Bが「大きいのに速い」のはこの分離構造のためだ。

手元のGPU・想定モデル・量子化方式から必要VRAMを試算したい場合は、VRAM計算ツールにモデルサイズと量子化方式を入力すると目安値と動作可能なGPU/Macの候補を確認できる。

- Ollamaの場合：公式ライブラリに掲載されていればタグ指定で ollama run できる。掲載前でも Hugging Face の GGUF を ollama run hf.co/<repo>:<quant> の形で直接指定して動かせる（リポジトリ名・量子化タグは配布元の実際の表記を確認すること）
- llama.cpp（GGUF）の場合：Hugging Faceのornith-ai組織からGGUF版をダウンロードし、llama-server -m ornith-1.5-9b.Q4_K_M.ggufのように起動する
- vLLMの場合：vLLM ≥ 0.19.1（SGLangなら≥ 0.5.9、Transformersなら≥ 5.8.1）を用意し、OpenAI互換エンドポイントとしてサーブする

推論結果はchain-of-thoughtをreasoning_contentフィールドに分離して返す仕様のため、通常の応答本文と思考過程を混在させたくないアプリケーションでも扱いやすい。function calling / tool useにも対応しており、OpenAI互換API経由でエージェント用途に組み込める。

Qwen系・GLM系との詳細な必要スペックは、Qwen3.8-27B 必要スペック早見表とGLM-5.2 必要スペック早見表をあわせて参照してほしい。

- 本記事のベンチマーク数値はすべて開発元DeepReinforceの自己申告値であり、第三者による独立検証は未確立
- Claude Opus 4.8との比較を含む対クローズドモデルの優位性主張は、コミュニティの一部から懐疑的な見方も出ている
- 量子化版（FP8/INT4/Q4等）の実効的な出力品質は、bf16版とは別途の検証が必要
- VRAM目安は短〜中context前提であり、長context運用では別途増加を見込む必要がある
- 数値・仕様はすべて2026年8月時点の公開情報に基づく