はじめに

こんにちは、クラスメソッド製造ビジネステクノロジー部の森茂です。

2026 年 6 月 25 日、DeepReinforce から新しいオープンソース LLM ファミリー Ornith 1.0 がリリースされました。9B Dense / 35B MoE / 397B MoE の 3 サイズ展開、MIT ライセンス、context 262K、そして「agentic coding 特化」を打ち出した尖った設計です。公式ベンチでは Terminal-Bench 2.1 / SWE-Bench Verified / ClawEval などで Claude Opus 4.7 に肉迫するスコアを主張しており、リリース直後から HuggingFace の DL 数も伸びています。

https://deep-reinforce.com/ornith_1_0.html

ただ、これらの公式ベンチはすべて英語タスクです。日本語性能についての主張は LP やモデルカードのどこにもありません。

そこでいつもながらこの記事では、「英語の agentic 特化モデル Ornith 1.0 を、DGX Spark で日本語ベンチに通すと、既存の日本語対応 LLM（Gemma 4 / Nemotron / Qwen3.6 など）と並べて使えるのか」を検証してみることにしました。

検証は次の 5 つで進めてみました。

1. Phase A 軽量定性 — 軽い質問と軽い推論を <think> ブロックの ON / OFF で比較
2. Phase B JCQ — JCommonsenseQA v1.1 の 300 問サブセットで日本語常識を測る
3. Phase C ELYZA-tasks-100 — 自由記述 100 タスクを LLM-as-a-Judge で採点する
4. Phase D 性能実測 — tok/s と GPU メモリを実測し、wesche.com Spark-Bench v2 の公開値と突合せる
5. Phase E BFCL v4 — Tool Calling / Function Calling の標準ベンチで agentic 適性を測る

「agentic 特化なのに日本語ベンチでどれくらい健闘できるのか、それとも公式ベンチの強さは英語限定なのか」。結論を先に書くと、Ornith 1.0 9B が日本語自由記述で 5 モデル中トップに立つ、というなかなか頼もしい結果が出てきました。

Ornith 1.0 の輪郭

DeepReinforce は 5 名の研究者で構成されたチームで、これまでに GrandCode（競技プログラミング向け RL 学習手法）や CUDA-L2（GPU カーネル最適化）といった論文を出してきました。Ornith 1.0 はその流れで、「self-scaffolding」、つまりモデル自身が agentic タスクで使う scaffold（手順や前提の足場）を RL で生成し続ける、という発想で訓練されたモデルファミリーです。

サイズと量子化のラインナップを公式 HuggingFace コレクションから整理すると、以下のようになります。

9B が qwen3_5 系のアーキテクチャ、35B / 397B が qwen3_5_moe 系の MoE アーキテクチャになっていて、Gemma 4 と Qwen 3.5 をベースに post-training を載せた設計と公式 LP に書かれています。

公式 LP の比較表で目を引くのは、35B クラスでの位置取りです。同じ 35B-A3B でも他社の Qwen3.5-35B / Qwen3.6-35B より ClawEval Avg や Terminal-Bench で前に出ていて、35B クラスのフラッグシップである Qwen3.5-397B（パラメータ数 11 倍）に肉迫する数字を出しています。

Ornith-1.0-35B achieves 64.2 on Terminal-Bench 2.1 (Terminus-2) and 69.8 on ClawEval Avg, matching Qwen3.5-397B (53.5 / 70.7).
( 出典: deep-reinforce.com/ornith_1_0.html )

ここで毎度気になるのが、「日本語タスクは想定されているのか」という点です。LP やモデルカードを最後まで読んでも、日本語に関する主張はありません。学習データの言語比率も公開されていません。

つまり、Ornith 1.0 を日本語で使えるかどうかは、実機で試してみないと分からないわけです。

DGX Spark で動かす

NVIDIA DGX Spark（GB10 アーキテクチャ、unified memory 128 GB、aarch64）で Ornith 1.0 をどう動かすかを考えてみました。

DGX Spark 単機で素直に動かすなら 9B bf16 か 35B FP8 の二択になります。今回は両方とも検証対象に入れました。397B は単機では動かないので、公式スコアの引用に留めることにします。

検証環境のセットアップ

今回の検証は DGX Spark の上で進めます。Docker、HuggingFace CLI、uv のセットアップから始めて、Ornith 1.0 9B と 35B-FP8 の重みを HuggingFace から取得しました。9B は 4 shard 構成で約 18 GB、35B-FP8 は 30 ファイル / 約 36 GB です。両方とも hf download の並列取得で、それぞれ約 7 分・約 8 分で完了しました。

今回は Docker Hub の vllm/vllm-openai:latest（vLLM 0.23.0）を採用しました。

vLLM の起動コマンドはこんな形になります。

docker run -d \
  --name ornith-vllm-9b \
  --gpus all --shm-size 16g --ipc host \
  -p 8000:8000 \
  -v ~/.cache/huggingface:/root/.cache/huggingface \
  -e VLLM_USE_FLASHINFER_SAMPLER=0 \
  vllm/vllm-openai:latest \
  --model deepreinforce-ai/Ornith-1.0-9B \
  --served-model-name ornith-9b \
  --tensor-parallel-size 1 \
  --max-model-len 32768 \
  --gpu-memory-utilization 0.85 \
  --dtype bfloat16 \
  --reasoning-parser qwen3

9B の場合は --dtype bfloat16、35B-FP8 の場合は --quantization compressed-tensors を明示します。

起動から readiness までの時間は、9B で約 5 分、35B-FP8 で約 7-8 分、Qwen3.6-35B-A3B-FP8 と Nemotron Nano 30B-A3B-NVFP4 でそれぞれ約 8 分・4 分でした。内訳としては、重みのロードに 1.5-3 分、torch.compile で 25-30 秒、CUDAGraph の capture（サイズ 1-512 の 51+35 種類）に 40-60 秒、というところです。

比較対象に並べたモデルを表でまとめておきます。

Ornith の 9B と 35B-FP8 を主役として、9B 級（Nemotron 9B-v2-JP）、30B 級（Nemotron Nano、Gemma 4 26B-A4B、Qwen3.6）を比較対象に並べました。

Phase A — 軽量定性で <think> 常時 ON が発覚

まず Ornith 9B に、軽い質問と軽い推論を 2 種類だけ投げてみました。プロンプトはこんな感じです。

• 軽い質問: 「Ornith 1.0 というモデルが何者なのか、50 字程度で読者に紹介してください」
• 軽い推論: 「リンゴ 3 個とミカン 4 個を 2 人で分けます。1 人あたり何個になるかと、公平な分け方の提案を 100 字以内で答えてください」

それぞれを system prompt で「<think> ブロックは出力しないでください」と指示した条件と、「思考過程を出してから最終回答を出してください」と指示した条件の 2 通りで叩いて、応答字数 / レイテンシ / <think> の有無を比較しました。

結果を表でまとめると、こうなります。

ここで気付いたのが、「<think> を出さないでください」と指示しても、Ornith 9B は内部で <think>...</think> ブロックを生成しているということでした。raw 応答を見ると、think=off の場合でも応答の前半に思考過程の文章が必ず出てきて、</think> 以降に最終回答が続く構造になっています。

軽い質問の think=off で完了トークンが 356 もあるのが、その証です。実際の最終回答は 45 字（数十トークン）なのに、それより 10 倍以上のトークンを「最終回答前」に消費している、ということです。

HuggingFace のモデルカードを念のため確認すると、こう書かれていました。

By default the assistant turn opens with a <think> … </think>. There is no documented switch to disable it.

つまり Ornith 1.0 は <think> 常時 ON が設計上の仕様で、system prompt や API パラメータでは無効化できないモデルです。Sakana Fugu や PLaMo 3.0 Prime のような reasoning_effort での切り替えはありません。

ただ、逃げ道もあります。vLLM の --reasoning-parser qwen3 を有効にすると、API レスポンスが content（最終回答）と reasoning_content（思考過程）に分離されます。実際にテストすると、

{
  "content": "\n\nA",
  "reasoning_content": "Thinking Process:\n1. **Analyze the Request:** ...\n2. **Determine the Correct Answer:** ...\n"
}

のような形で返ってきます。これなら JCQ のように選択肢を 1 文字で取りたいタスクで、content を直接 1 文字パースすればよくなります。後段のベンチではこのフラグを必ず付けて回すことにしました。

ここまでで分かった Ornith 1.0 9B の素の挙動は、次の通りです。

• <think> は常時 ON、無効化できない
• 軽い質問でも 26-56 秒かかる（thinking の長さに依存）
• max_tokens が小さいと <think> で食い潰して最終回答が空になる
• --reasoning-parser qwen3 で content と reasoning を機械的に分離できる

これは後段の JCQ / ELYZA / BFCL で max_tokens 設計に直接効いてくる重要な前提です。max_tokens を 1024 以上に取らないと、選択肢タスクですら「考えてる途中で切れて回答ゼロ」というエラーパターンが出ます。

Phase B — JCommonsenseQA で 6 モデル横並び

日本語常識の基礎体力を見るため、leemeng/jcommonsenseqa-v1.1 の validation split（1,119 問）から seed 固定で 300 問サブセットを取り、6 モデルで横並びベンチを取りました。3-shot、temperature=0、max_tokens=1024、system prompt で「A〜E のアルファベット 1 文字だけを返してください」と指示し、reasoning-parser qwen3 で content 側を 1 文字パースする構成です。

結果はこちらです。

Ornith に関係するところを読み取ると、こうなります。

Ornith 1.0 9B が 93.0% で、日本語特化の Nemotron 9B-v2-Japanese を 5.7 ポイント上回ったことが、個人的には一番の発見でした。agentic coding 特化のモデルが、日本語常識問題で「日本語専用に SFT したモデル」に勝つというのは、率直に言って予想外です。ベースの Qwen 3.5 / Gemma 4 が事前学習段階で日本語をかなり含めていて、それが Ornith の self-scaffolding RL を経ても残っていた、と解釈するのが自然です。9B Dense として 93.0% は、エッジ向けモデルとして十分実用域のラインです。

Ornith 1.0 35B-FP8 も 92.0% で 9B と同レベルを出してきました。MoE Active 3B + FP8 でこの数字なら、35B クラスの日本語常識タスクとしては十分です。<think> を 1024 トークン以内に収めて答え切るタイプの問題では、9B と 35B どちらも安定して動くことが確認できました。

参考までに、Gemma 4 26B-A4B-NVFP4 が 97.7% を 0.1 秒・2 トークンで出しているのは、Gemma 4 が thinking を持たず A のような最小限の応答を直接出す設計だからです。選択肢タスクではこの direct 系が最強になりますが、後の章で見るように自由記述では別の話になります。

JCQ という枠で見れば、Ornith 1.0 は 9B / 35B どちらも日本語常識で実用域に入っている、という最初の答えがここで出ました。「英語 agentic 特化なのに、日本語でも普通に使える」。これだけでも、DGX Spark などでローカルで置く候補としては合格点だと思います。

ただ、JCQ は選択肢タスクなので、長文生成での品質はまた別軸です。次の章で ELYZA-tasks-100 を回したところ、Ornith 1.0 9B はさらに面白い結果を出してきました。

Phase C — ELYZA-tasks-100 で Ornith 9B が日本語自由記述トップ

次は ELYZA-tasks-100 です。100 タスクの自由形式日本語応答を LLM-as-a-Judge で 1〜5 点採点する、日本語 LLM 自由記述評価の定番ベンチです。今回は judge を Anthropic の claude-haiku-4.5（API 経由）にして、参考対象の 4 モデルと並べました。max_tokens は thinking 込みで 1,024 に揃えています。

Ornith 1.0 9B が avg 3.89 で 5 モデル中トップでした。5 点が 47 件、4 点と 5 点を合わせると 67 件、十分実用水準です。参考までに ELYZA-Llama-3-8B の公開値が avg 3.0 程度、GPT-3.5 系が 3.5 程度なので、それを上回り、GPT-4 系の 4.5 にはやや届かない、というラインです。

これは率直に予想を超える結果でした。Ornith は agentic coding 特化を謳う英語ベースの 9B モデルで、日本語特化の SFT を受けたわけではありません。それでもこの数字が出るのは、ベースの Qwen 3.5 / Gemma 4 が事前学習段階で日本語をかなり含めていて、self-scaffolding RL がその知識を保持したまま agentic タスクへ伸ばした、と読むのが自然です。「Qwen 3.5 / Gemma 4 系の日本語素地は post-training を経ても残る」という、運用設計の上では地味に重要な観察です。

なお、Ornith 35B-FP8 は自身の 9B より avg が下になりましたが、これは max_tokens=1,024 という単一条件で並べた結果です。35B-FP8 でも 5 点を 24 件出していて、生成品質そのものは安定して出せています。長文タスクで Ornith 35B-FP8 を本気で使うなら max_tokens を 2,048-4,096 に取る運用設計 を前提に組むのが良さそうです。<think> 常時 ON 系の reasoning モデルを長文に投入するときは、コードでもインフラでも、token 予算を一段増やしておくのが安全策です。

ベンチの数字を踏まえた実感はシンプルで、Ornith 1.0 9B が「DGX Spark で日本語自由記述を実用域に持っていける」一番素直な選択肢、ということです。MIT ライセンス、bf16 で 18 GB、<think> でじっくり考えてから答えてくれて、ELYZA で平均 3.89 が出ます。手元の DGX Spark に常駐させるオープンソース日本語 LLM の候補として、十分なラインです。

Phase D — tok/s 実測 と wesche.com 公式値との突合せ

品質の話だけでなく、速度・メモリの話も整理しておきます。長めのプロンプト（約 100 字）+ max_tokens=512 で warmup 1 + 5 runs の単純なベンチを 5 モデルで取りました。

Ornith に関わる読みどころを整理しておきます。

Ornith 1.0 35B-FP8 は MoE Active 3B の効率を活かして、35B 級としては 37.5 tok/s と出ました。bf16 の Dense 9B（12.65 tok/s）から見ると 3 倍速、ELYZA 100 タスクで gen latency 22 秒というのは、reasoning モデル + 35B 級としては実用域です。Ornith 公式 HF には FP8（compressed-tensors）として提供されていて、--quantization compressed-tensors を付けて vLLM 0.23.0 + vllm/vllm-openai:latest でそのまま動かせます。「公式提供の量子化で、DGX Spark 単機 35-40 GB に収まって 37 tok/s が出る」という実用性は、35B クラスを手元に置きたい運用にとって嬉しいラインだと思います。

Ornith 1.0 9B は Dense なので、35B-FP8 の 1/3 の 12.65 tok/s です。長文 reasoning でじっくり考えるタイプなので、対話的な用途では応答待ちが入りますが、その分 ELYZA 3.89 / JCQ 93.0% / BFCL simple_python 90.25% という質を出してきます。

ここで「では結局どちらを使うか」を品質と速度の両面で並べると、こうなります。

ざっくり言うと、Ornith 1.0 9B は「品質を取りたい場面のスイートスポット」、Ornith 1.0 35B-FP8 は「速度を取りたい場面のスイートスポット」、というすみ分けです。同じファミリーで質と速度をフェイクなしに選べるのは、運用設計の上で素直に嬉しい構図です。

ひとつ補足しておくと、35B-FP8 の ELYZA 2.61 は今回の max_tokens=1,024 という単一条件で取った数字です。35B-FP8 でも 5 点を 24 件出していて、生成品質そのものは安定して出せています。長文タスクで 35B-FP8 を本気で使うなら max_tokens を 2,048-4,096 に取って <think> を出し切らせる設計にすれば、速度のアドバンテージを保ったまま品質も伸びるはずです。改めて実機で運用しながら確認したいテーマです。

なお、wesche.com Spark-Bench v2 が公開している Ornith-1.0-35B の 66.9 tok/s は NVFP4 量子化で測られた値です（"Local models: served via llama.cpp (Q4_K_M quantization) or vLLM (NVFP4)"、出典: wesche.com/dgx/）。公式 HuggingFace の Ornith コレクションには現状 NVFP4 版がないので、wesche 側で自前 NVFP4 量子化したものが計測されたという構図です。Ornith 公式に NVFP4 版が出てくれば、35B クラスでも 60 tok/s 帯に届く見通しが立ちます。手元の DGX Spark で別途 Nemotron 3 Nano 30B-A3B-NVFP4 を測ると 59.81 tok/s（同 30B 級 MoE Active 3B + NVFP4）で、wesche のオーダーと整合する数字でした。

ここまでで Ornith 1.0 9B / 35B の「日本語性能」と「速度・バランス」が出揃いました。最後に agentic タスクへの適性を、自前 BFCL v4 評価と公式 LP の Terminal-Bench / SWE-Bench / ClawEval スコアの両面から見ます。

Phase E — BFCL v4 で Ornith 9B の tool calling 適性を測る

BFCL（Berkeley Function Calling Leaderboard）は、Tool Use / Function Calling の実力を測る、業界デファクトの評価ベンチです。最新の v4 では single-turn の simple 系から、parallel、irrelevance reject、live（実世界クエリ）、multi_turn、web_search まで 20 カテゴリ以上をカバーしています。

Ornith は BFCL のカタログに登録されていないため、vLLM の --served-model-name を Qwen/Qwen3-8B に書き換えて、BFCL の Qwen/Qwen3-8B-FC handler を流用しました。Qwen 3.5 ベースなのでチャットテンプレートが同型で、handler の _format_prompt も問題なく動きます。--skip-server-setup + REMOTE_OPENAI_BASE_URL で外部 vLLM endpoint を直接指す形です。

simple_python / multiple / parallel / parallel_multiple / irrelevance / live_simple / live_relevance / live_parallel の 8 カテゴリ・1,514 件を num_threads=4 で並列実行し、1 時間 42 分で完走しました。

Ornith 1.0 9B の結果がこちらです。

ここから読み取れることを 3 つ。

1 つめは、Non-Live 系（人手で書いたカテゴリ）が安定して 78-92% あることです。simple_python が 90%、multiple が 92%、parallel_multiple が 87%。「tool spec を読んで該当関数を選び、引数 JSON を埋める」という一番ベーシックな agentic 動作は、9B Dense でも実用水準（80% 以上）で動くことが分かりました。

2 つめは、Live 系（実世界クエリ）で全カテゴリ 10〜16 ポイント下がることです。simple_python 90.25% に対して live_simple は 74.42%。「文法的にきれいな human-crafted な関数仕様」と「実プロダクトで使われそうな雑な仕様」では、後者で大きく崩れることが見えます。これは Ornith に限らず、BFCL の Live カテゴリ全体で見られる傾向ではあるのですが、9B Dense モデルでもこのギャップが小さくないことは、運用設計の上では知っておいた方が良い数字です。

3 つめは、parallel と live_parallel が低め（78.50% と 68.75%）なことです。並列に複数の tool call を出す必要があるタスクは、<think> が長くなって構造化が崩れやすい傾向が出ました。これは「<think> 常時 ON」の reasoning モデルが構造化出力で時々ふらつく、という業界共通の現象に Ornith も例外ではない、ということです。

他のモデルとの並列評価をやりたいところでしたが、4 モデル分すべて回すとさらに約 16 時間以上かかりそうだったため、今回の公開ペースには乗りません。比較対象は BFCL 公式リーダーボード（gorilla.cs.berkeley.edu/leaderboard.html）から、Qwen3-8B-FC や Qwen3-30B-A3B-Instruct-2507-FC の公式スコアを参照しました。Ornith 9B の今回の結果は、Qwen3-8B-FC の公式スコアと概ね同水準で、agentic coding 特化を謳う割には突き抜けて強いというよりは「Qwen 3.5 8B 級として標準的」というのが率直な所感です。

これは agentic 軸での Ornith の真価が、ベース 8B クラスではなく、397B フラッグシップで公式の LP でも謳っているように Claude Opus 4.7 / 4.8 に並びにいく設計だから、と読むのが自然かもしれません。

公式 agentic スコアを引用しておく（Terminal-Bench / SWE-Bench / ClawEval / NL2Repo）

Ornith 公式 LP に掲載されているサイズ別比較表から、特に強い数字をいくつか抜き出しておきます。

397B フラッグシップモデルは、Claude Opus 4.7 をいくつかのカテゴリで上回っています。

Ornith-1.0-397B posts 77.5 on Terminal-Bench 2.1 and 82.4 on SWE-Bench Verified, surpassing Claude Opus 4.7 on both benchmarks.
( 出典: deep-reinforce.com/ornith_1_0.html )

35B-MoE もこのクラスとしては破格の数字です。

同じ 35B クラスで Qwen3.6-35B より 11.7 ポイント前に出て、フラッグシップ Qwen3.5-397B（パラメータ 11 倍）に肉迫している、という構図です。

9B (Dense) はエッジ向けですが、それでも 35B クラスの Qwen3.5-9B（Dense）を大きく引き離しています。

9B Dense が 31B Dense（Gemma 4-31B）と Terminal-Bench でほぼ並ぶのは率直に面白い結果です。Qwen 3.5 9B から大きく伸ばしているので、self-scaffolding RL の効果が特に小規模モデルで効きやすい、という仮説も立てられそうです。

まとめ — Ornith 1.0 の何が嬉しいのか

英語 agentic coding 特化モデルとしてリリースされた Ornith 1.0 を、DGX Spark で日本語 4 軸 + agentic 1 軸に通してみた結論を整理します。

Ornith 1.0 で個人的に嬉しい点はこんなところです。

• 9B Dense でも日本語常識・自由記述・tool calling が実用域に入る。JCQ 93.0%、ELYZA-tasks-100 avg 3.89（5 モデル中トップ）、BFCL v4 simple_python 90.25%。エッジ向けと位置付けられている 9B でこの数字なので、DGX Spark に常駐させるローカル LLM の候補としては十分のラインです。
• 35B-FP8 が公式 HF から MIT で提供されていて、DGX Spark 単機でそのまま 37 tok/s が出る。vllm/vllm-openai:latest + --quantization compressed-tensors で簡単に立ち上がり、MoE Active 3B の効率も活きています。
• <think> を vLLM の --reasoning-parser qwen3 で content / reasoning に切り分けられる。reasoning モデルを構造化タスクに組み込むときの取り回しが標準化されていて、運用設計に余計な工夫が要りません。
• 公式 LP で 397B が Claude Opus 4.7 に並ぶことを主張している。Terminal-Bench 2.1 で 77.5、SWE-Bench Verified で 82.4、ClawEval Avg で 77.1。35B クラスでも ClawEval 69.8 / Terminal-Bench 64.2 と、Qwen3.5-397B（11 倍のパラメータ）に肉迫する数字です。
• MIT ライセンス + Qwen 3.5 / Gemma 4 ベースで、ベース由来の日本語素地と self-scaffolding RL による agentic 能力がうまく両立しています。今後の派生モデルや fine-tune ベースとしても扱いやすいです。

DGX Spark で動かすときの品質と速度の選び方は、用途で決まります。

「9B Dense は質、35B-FP8 は速さ」 という、同じファミリーの中で素直なすみ分けが用意されているのが Ornith 1.0 の良い点で、運用設計の段階でモデルを乗り換える必要がないのは率直にありがたいです。日本語自由記述の最終品質が要るタスクは 9B、対話的なやり取りが多いタスクは 35B-FP8、と裏のサービス層でルーティングしてやれば、両方の良いとこ取りもできます。

<think> 常時 ON は長文タスクで max_tokens を 2,048-4,096 に取る設計を要求しますが、これは Qwen 3.5 / Gemma 4 / DeepSeek 系の reasoning モデルすべてに共通する前提なので、Ornith に固有の負担ではありません。むしろ、その thinking の長さに見合うだけのスコアが 9B から出てくる、というのが Ornith の面白さです。

引き続き調査検証していきたいテーマ

• Ornith 35B-FP8 を max_tokens 4,096 に増やして、長文タスクでの本気の品質を見たい
• Ornith 9B を Hermes Agent や Claude Code Router に常駐させて、1 週間の routing ログから reasoning モデルの実運用の手触りを記事化したい
• Ornith 公式に NVFP4 版が出るタイミングで、35B-NVFP4 / 397B-NVFP4 を DGX Spark で動かして速度・品質の伸びを確認したい
• Terminal-Bench 2.1 を DGX Spark に常設し、Ornith 9B / 35B / 他 OSS モデルを定期的に走らせる検証基盤にしたい

参考リンク

• Ornith-1.0: Self-Scaffolding LLMs for Agentic Coding | DeepReinforce Blog
• HuggingFace deepreinforce-ai/Ornith-1.0-9B
• HuggingFace deepreinforce-ai/Ornith-1.0-35B-FP8
• wesche.com Spark-Bench v2
• Berkeley Function Calling Leaderboard (BFCL)
• ELYZA-tasks-100
• JCommonsenseQA v1.1