Gemma 4 26B A4B vs Ornith 1.5、12GBの答えはどちらか

前回の記事「VRAM 12GBの救世主。Gemma 4 26B は 12B より速くて賢かった」で、VRAM 12GB のカードなら Gemma 4 26B A4B が最適解だと書きました。その翌日に、9B の新しいモデルが出ました。

関連記事としては Bloggemma4:12bはollamaで動かない — 12GB GPUでllama.cpp実測52t/sの最短ルートollamaのHTTP 500やSIGFPEで詰まるgemma4:12bを、llama.cpp経由で12GB GPUに載せる実測手順と判断材料をまとめました。→ もあわせて読むと、今回の論点とのつながりを把握しやすくなります。

正直なところ、またかと思いました。ローカルLLMを触っていると、この「翌日に出る」が本当によく起きます。ただ今回は少し事情が違って、Ornith 1.5 という名前のこのモデル、公式が「Gemma 4-31B を大幅に上回る」と書いているのです。9Bが31Bを、と。

しかも重要なのは、サイズが 5.4GB しかないことでした。12GB のカードなら半分も使いません。前回の 26B A4B は 11.6GB とギリギリまで詰め込んで動かしていたので、もしこれが同じくらい賢いなら、乗り換えるだけで6GBが浮きます。

というわけで、同じ機械に入れて、同じ問題を、同じ採点基準で解かせました。計測はすべて2026年8月29日から30日にかけて、RTX 4070 Ti（VRAM 12GB）の1台で行っています。結論から書くと、勝敗は分野できれいに割れました。そして測っている途中で、前回の記事に書いた結論のひとつが間違っていたことにも気づきました。

日本語で相談したいなら 26B A4B のままがいいです。総合点の差はほぼ日本語力の差で、ここは 15点も開いています。

コードを書かせるなら Ornith 1.5 9B。 コーディング分野は 60点満点、つまり6問すべて完璧でした。26B より上です。9Bのモデルがこの分野で満点を取ったのは、うちの計測では初めてです。

そして 12GB のカードを持っている人にとって地味に大きいのが、VRAMが6GB近く余ることです。うちの環境だと、これは画像生成を同時に立ち上げておける余裕にあたります。片方を落としてから片方を上げる、というあの手間がなくなります。

モデルカードの設定ファイルを開いて、少し意外な気持ちになりました。アーキテクチャ名が qwen3_5 と書いてあります。Qwen3.5 をベースにしたモデルだったわけです。

さらに公式ブログを読むと、前世代の Ornith-1.0 は「Qwen3.5 と Gemma 4 の上に」継続学習を重ねて作られたとありました。つまり今回の対戦相手は、遠い親戚どころか、片方の親にあたります。この事実は後半でもう一度出てきます。

もうひとつ、config を見ていて目に留まったのが注意機構の構成です。層が「軽い方式3つ、重い方式1つ」の繰り返しになっていました。4層に1層だけが従来型で、残り3層は文脈が伸びてもコストがあまり増えない方式です。

これが何を意味するかは、実測するとはっきりしました。

文脈の長さを変えながら起動して、VRAM使用量を見ていきました。

16倍に伸ばして、増えたのは4GB弱です。 普通の構造のモデルなら、文脈長を16倍にすれば作業メモリも概ね16倍に膨らみます。ここが3層に1層しか効かないので、こうなります。

文脈を16倍にしても、埋まり方はここまでしか変わらない。これが軽い注意機構の効きどころ

比較として、26B A4B は文脈を 32,768 に広げようとすると、前回いちばん速かった設定では起動しませんでした。ひとつ譲った設定に戻せば載りますが、速度は 72.9 から 65.3 に落ちます。

長いログを丸ごと投げたい、大きめのソースを読ませたい、という用途なら、この差は点数表よりも効いてきます。

うちで使っている24問のテストにかけました。引っかけ問題・論理パズル・コーディング・日本語力の4分野で、240点満点です。

コーディングが満点でした。FizzBuzzの拡張、クロージャの罠、SQLインジェクション、再帰の計算量、Pythonの可変デフォルト引数、正規表現。どれも過不足なく答えています。とくに正規表現の問題では、一見不正なメールアドレスが「この正規表現では弾けない」という引っかけに正しく気づいていました。ここは前回 26B A4B も正解していますが、Ornith は説明の切れ味が一段良かったです。

引っかけ問題も 57点で上回りました。「花子がりんごを取りました。りんごの行方は？」という多義性を問う設問で、きちんと「わからない」を選んでいます。断定したがるモデルが多いなかで、これは好印象でした。

一方、日本語力は 35点と苦戦しています。俳句「古池や」の季語を夏と答えました。正解は春です。作者が芭蕉であることは当てているので、知識がないというより日本語圏の常識が薄い印象でした。思考の過程を覗くと全部英語で考えていたので、まあそうなるだろうな、という感じです。

論理・推論の 47点は、少し事情が違います。5問は満点で、12枚のコインを天秤3回で判定する1問だけが 0点でした。間違えたのではありません。答えを書かずに力尽きたのです。

前回、26B A4B の弱点として「難しい問題になると内部で延々考え込み、出力の上限に達したところで答えを一文字も書かないまま終わる」と書きました。これは事実です。

今回 Ornith を測り始めたとき、最初の結果ではこの症状が2問しか出ませんでした。それを見て「なるほど、こちらは必ず答えを返すタイプか。失敗の質が正反対だ」と、記事の見出しまで考えていました。

間違いでした。

原因は私の設定です。Ornith には作業領域を 8,192 しか与えていませんでした。前回 26B A4B を測ったときは 32,768 です。つまり3分の1の狭さで戦わせていたわけで、そもそも比較になっていません。しかも狭いせいで早めに打ち切られ、結果として「短いけれど一応の答え」が出ていたのです。

条件を揃えて測り直したら、無回答が2問から4問に増えました。

考える余地を与えたほうが、答えに辿り着かなくなる。直感に反しますが、実際にそうなりました。あるモデルは思考だけで82,000字を書き連ねた末に、回答欄は空でした。原稿用紙200枚ぶん悩んで白紙で出してくる、と言えば伝わるでしょうか。

そして D3 と E2 が両モデルで重なっています。片方は9Bの新参、片方は26BのMoE。まったく別の設計に見えて、Ornith は Gemma 4 の血を引いている。他人の空似ではなく、親から受け継いだ癖である可能性のほうが高いと思っています。

新しいモデルだから古い弱点は直っている、とは限らない。 これが今回いちばんの収穫でした。

正直に書いておくと、この比較は3回やり直しています。毎回モデルを疑って、毎回自分の計器が狂っていました。

1回目は先ほど書いた作業領域の広さ違いです。2回目は、900秒のタイムアウトを指定したのに4問がぴったり300秒で切れました。調べると、応答を一括で待つ方式だと通信層が300秒で見切りをつける仕様で、長考するモデルは必ずここで落ちます。逐次受信に切り替えたら解決しました。ちなみにこの罠、うちの計測スクリプトにコメントで書いてありました。過去の自分が引っかかって、ちゃんとメモまで残していたわけです。

このとき速度も 25.9 tok/s と表示されていました。空転した300秒×4問が分母に入っただけの数字です。あのまま記事にしていたら、Ornith は遅いモデルということになっていました。

「無回答」を実力と判定する前に、それが打ち切りでないことを確かめる。 当たり前のようでいて、3回とも最初はモデルのせいだと思っていました。

日本語で壁打ちしたい、文章を直させたい、雑談混じりに相談したい。この用途なら 26B A4B です。日本語力の15点差は、使っていて体感でわかるレベルの差でした。

コードを書かせる、長いファイルを読ませる、VRAMを空けておきたい。この用途なら Ornith 1.5 9B です。コーディング満点・80 tok/s・5.9GB・文脈13万という組み合わせは、12GBのカードでは他に見当たりません。

両方入れても16GB弱です。うちは結局そうしました。用途で切り替えるのがいちばん賢い、という身も蓋もない結論ですが、片方に絞る理由が見つかりませんでした。

なお公式が言う「Gemma 4-31B を大幅に上回る」は、英語のコーディング系ベンチマークでの話です。日本語で負けたことをもって公式が誇張している、という話ではありません。測っている土俵が違うだけで、コーディングに関してはうちの計測でも確かに上回っていました。

そして両方とも、難しい問題では黙り込みます。そこは期待しないでください。

先に、この記事の数字がどこまで言えるものかを書いておきます。

24問テストはうちで作った独自のセットで、業界標準のベンチマークではありません。日本語での実用感を見るための道具であって、公式が使う Terminal-Bench や SWE-bench とは測っているものが違います。公式の「Gemma 4-31B を上回る」という主張と、この記事の日本語スコアは矛盾しません。

もうひとつ、実行ごとのブレが大きいという制約があります。同じ問題で正答と誤答が入れ替わる場面が実際にありました。1回の結果でモデルの実力を断定するのは危険です。ここに出した数字も、1回の通し計測の結果であることは差し引いて読んでください。

速度についても、llama.cpp で測った値であることを添えておきます。Ollama で同じモデルを動かすと数字が変わります。別の実行環境で測った速度と並べて比較しないでください。

比較はすべて同じ機械・同じ設問・同じ採点基準で行いました。あとから見返せるよう条件を残しておきます。

• 機体は RTX 4070 Ti（VRAM 12GB）1台、実行環境は llama.cpp。Ornith は Q4_K_M（5.4GB）、Gemma 4 26B A4B は q4_0 QAT
• 作業領域 32,768・生成上限 24,000トークン・温度 0.3 で両モデルを揃えた（2026-08-30 実施）
• 速度の 80.0 tok/s は作業領域 8,192・定常状態での3回計測。29問の通し平均は 75.7 tok/s
• 計測日は 2026-08-29（速度・文脈長）と 2026-08-30（24問テスト本番）

モデルの取得と起動はこれだけです。同じカードをお持ちなら、そのまま試せます。

# GGUF を取得（Q4_K_M・5.4GB）
curl -L -o Ornith-1.5-9B-Q4_K_M.gguf \
  https://huggingface.co/ornith-ai/Ornith-1.5-9B-GGUF/resolve/main/Ornith-1.5-9B-Q4_K_M.gguf

# 文脈13万トークンで起動（VRAM 9.8GB）
llama-server --model Ornith-1.5-9B-Q4_K_M.gguf --ctx-size 131072 -ngl 99

一次情報は 2026年8月30日時点のものです。

• Ornith-1.5: From Self-Scaffolding to Self-Improvement（公式ブログ）
• ornith-ai/Ornith-1.5-9B（モデルカード・設定ファイル）
• ornith-ai/Ornith-1.5-9B-GGUF（量子化版の配布）

ライセンスは MIT、HuggingFace への公開日は 2026年8月18日です。仕様や配布形式は更新される可能性があるので、導入前に上記のモデルカードを見ておくことをおすすめします。

• Bloggemma4:12bはollamaで動かない — 12GB GPUでllama.cpp実測52t/sの最短ルートollamaのHTTP 500やSIGFPEで詰まるgemma4:12bを、llama.cpp経由で12GB GPUに載せる実測手順と判断材料をまとめました。→
• BlogOllama導入の罠と解決手順——GPU認識・日本語チャットまでの全記録と結論RTX 4070 Ti搭載の自宅サーバーにOllamaをSSHでセットアップした実録。非対話環境でのインストール罠、バイナリ直接DL、systemdサービス化、qwen2.5:7bでの日本語チャットまで。→
• BlogGEMMA4-12B-CODERは何に使うべきか：コード55/60、総合B評価の実測結論GEMMA4-12B-CODERをRTX 4070 Ti 12GBで実測。54.6 tok/s、24問160/240、コード55/60。Gemma 4 12B/E2B/E4Bとの使い分けとMTP可否を整理します。→

• 実際の構成を探すなら、GPU 比較ページやローカルLLM向け構成記事もあわせて見ると判断しやすいです。
• ハードウェア候補は用途別の AI 構成ガイドからたどると、単体製品より違和感なく検討できます。

• META-MARK