Ornith-1.0をローカルで動かすには？9B〜397Bの必要VRAMとGPU選び【Dense/MoE別】

Ornith-1.0とは、コーディングに特化したオープンソースのLLMファミリー。

DeepReinforceが公開したOrnith-1.0は、9B・31B・35B・397Bの4サイズで展開されています。最上位の397BはClaude Opus 4.7に並ぶ性能をうたう一方、最小の9Bは手元のGPUでも現実的に動く。つまり「クラウド最上位に張り合うモデル」と「自分のPCで回せるモデル」が同じ名前で並んでいるわけです。問題は、どのサイズが自分のGPUに載るのか。答えはVRAMとモデルタイプ（Dense / MoE）で決まります。

Ornith-1.0とは — 4サイズ構成とMITライセンスの位置づけ

Ornith-1.0は、AI研究組織のDeepReinforceがオープンモデルとして公開したエージェントコーディング特化のLLMファミリーです。GitHub上の開発履歴によれば、2026年6月下旬（6月21日の初回コミットから6月25日前後にかけて）に公開されています。ベースにはGemma 4とQwen 3.5が使われ、ライセンスはMIT Licenseで配布されています。商用利用も含めて扱いやすいのが特徴です。

Ornith-1.0 spans the full parameter sizes including 9B Dense, 31B Dense, 35B MoE, and 397B MoE.（DeepReinforce公式ブログより。URLは記事末尾の参考資料）

公式説明では、ファミリー構成として4サイズが示されています。Ornith-1.0-9BとOrnith-1.0-31Bは全パラメータを読み込んで処理するDenseモデル、Ornith-1.0-35BとOrnith-1.0-397Bは入力に応じて一部のパラメータだけを活性化するMoE（Mixture of Experts）モデルです。DeepReinforceは397Bを最上位、9Bをエッジデバイス向けと位置づけています。

このファミリーで技術的に目を引くのが、self-scaffolding（自己足場構築）という学習方法です。エージェントAIの動作を決めるスキャフォールドやハーネスは、通常は人間が組み立てます。Ornith-1.0はそのスキャフォールド自体も学習の対象に含め、報酬ハッキング（評価をだます近道を学んでしまう現象）を避けながら足場を最適化することで、エージェントとしての性能を底上げしたと説明されています。

ベンチマーク上の位置づけも公式に公開されています。GitHub公式リポジトリのベンチマーク表によれば、Ornith-1.0-35BはTerminal-Bench 2.1で64.2（Qwen3.6 35Bは52.5、Qwen3.5 35Bは41.4）、SWE-bench Verifiedで75.6（Gemma 4 31Bは52）を記録。最小の9Bですら、Terminal-Bench 2.1で43.1、SWE-bench Verifiedで69.4と、比較的大型なGemma 4 31B（同42.1／52）を上回っています。小さいサイズでも同格以上に競れる、という主張です。ただし、これらはコーディング系ベンチマークでの話。日本語処理や他タスクの適性まで保証するものではない点は、後半で改めて触れます。

DenseとMoEの違いが動作要件を分ける

9B/31BがDense、35B/397BがMoE。この違いは、単なる分類ではなく動作要件を左右します。Denseモデルは推論のたびに全パラメータを使うため、パラメータ数がそのまま計算量とメモリ量に効いてきます。31Bなら31B分をまるごと動かす前提です。

一方のMoEは、モデル内に複数の「エキスパート」を持ち、トークンごとにその一部だけを活性化します。計算量は活性化したパラメータ（active param）分に抑えられるので、総パラメータ数のわりに推論が軽く感じられる。実際、当サイトの検証環境で計測した同規模のMoE型モデル（35B級）は、同じくらいの総パラメータを持つDense型より明らかに高いトークン速度を出しました。ただし、ここに落とし穴があります。速いからといってメモリまで軽いわけではない、という点。これは3つ目のセクションで詳しく扱います。

どのサイズが自分のGPUで動くか — 必要VRAMの早見

「397BがOpus超え」と聞くと期待が膨らみますが、ハードウェアの現実は冷静です。快適に全GPU常駐で動かせるかどうかは、量子化後のモデルサイズとKVキャッシュがGPUのVRAMに収まるかで決まります。VRAMに収まりきらない場合でも、Ollama / llama.cpp系のランタイムでは一部をシステムRAMへオフロードして動かせる場合がありますが、その分速度や余裕は落ちます。以下は4サイズをQ4_K_M量子化で動かす場合の目安をまとめた早見表です。9Bと35Bは当サイトの実測値、31Bと397Bはパラメータ数からの一般目安（未計測）として区別しています。

当サイトの検証環境（RTX 5080単体・Q4_K_M）でOrnith-1.0-9Bを動かすと、110.7 tokens/secを記録しました。このときのGPU全体のVRAM使用量は8239MiB（約8.05GiB）です。ここで注意したいのが、この8239MiBはnvidia-smiのmemory.usedによるGPU全体の使用量で、デスクトップ表示などのベースラインを含む値だという点。モデル単体のロード増分ではありません。とはいえ、GPU全体で約8GiBに収まるなら、VRAM 16GB級のGPUには余裕を持って載ります。

中位の35B MoEも見てみましょう。同じRTX 5080単体・Q4_K_Mで73.1 tokens/sec、GPU全体のVRAM使用量は15510MiB（約15.15GiB）でした。ただし、この構成は35Bの全レイヤーがGPUに乗り切った状態ではありません。Ollamaの/api/psで確認すると、GPU常駐は67%にとどまり、残り約33%はシステムRAM側にオフロードされています。16GBカード1枚でも動作はしますが、「収まっている」というより「大部分をGPUに乗せつつ一部はCPU側で補っている」状態で、コンテキストを伸ばすとKVキャッシュ分の余白がほぼ無い点には注意が必要です。GPU温度は59℃、消費電力は119Wと、上限近くまで使っている割には落ち着いた数字でした。

なお当サイトの検証は think=false で統一し、各モデルを複数回計測した中央値を採用しています。計測はOllama 0.30.7・NVIDIA driver 610.47の環境で、計測日は2026年7月。速度はランタイムやモデルの版で変わるため、この数字は計測時点のスナップショットとして見てください。

量子化（4bit等）でVRAM要件がどう下がるか

早見表の数字はすべてQ4_K_M、いわゆる4bit量子化での値です。量子化は各パラメータのビット幅を落としてモデルサイズを圧縮する手法で、Q4系まで落とすとフル精度（FP16）比で3割前後のサイズに縮みます。35B MoEを16GB環境で動作確認できたのも、この圧縮があってこそです。ただし、Q4_K_MのGGUF本体は21.2GBあるため、今回の35B実測は全GPU常駐ではなく、一部をシステムRAM側へオフロードした状態です。

ただし、圧縮すればするほどVRAMは節約できる反面、出力品質への影響が出る可能性はあります。当サイトが計測したのは速度とVRAM使用量であって、量子化ごとの品質差までは検証していません。ここは測っていない領域なので、断定はしません。実務では、まずQ4_K_Mで動かしてみて、コードの正確さに不満が出たらQ5やQ8など上位量子化を試す、という順序が無難でしょう。上位量子化に上げれば当然VRAMも増えるため、そのぶんの余裕をGPU選びで見込んでおくと安心です。

MoEモデルをローカルで回すときの注意点と対策

MoEモデルには、初見だと必ず引っかかる落とし穴があります。「計算は軽いのにVRAMには載らない」という現象です。前述のとおりMoEは推論時に一部のエキスパートしか使いません。だから速い。しかし、どのトークンでどのエキスパートが呼ばれるかは事前にわからないため、全エキスパートをメモリ上に置いておく必要があります。つまり、計算量はactive param分に近づいても、重み自体は総パラメータ分をどこかのメモリ上に保持する必要があります。全GPU常駐で高速に動かすならVRAM側にも総量に近い余裕が必要で、VRAMが足りない場合はシステムRAMへのオフロードで補うことになります。

この非対称を取り違えると、「35B MoEは活性化3B相当だから8GBで動くはず」といった誤解につながります。実際には総パラメータ35B分のメモリが要るので、当サイトの実測でもGPU全体15510MiB（約15.15GiB）を使いました。速さの感覚とメモリの必要量を、別々に見積もる必要があります。

対策の方向は2つあります。1つは自分のVRAMに収まるサイズを選ぶこと。9Bなら16GB級GPUで余裕を持って運用できます。35B MoEも16GB環境で生成確認はできますが、一部RAMオフロード前提になるため、快適さを求めるなら24GB以上を見込む方が安全です。もう1つは、VRAMに収まらない分をシステムRAMへ逃がすオフロードです。llama.cppなどの推論エンジンは、GPUに載り切らないレイヤーをCPU側で処理できます。ただしオフロードした分は速度が大きく落ちるため、快適さを求めるならVRAMに収める設計が基本です。

MoE推論のランタイム側も進化しています。llama.cppは2026年7月のリリースで、特定のエキスパート数を持つMoEモデル向けにCUDAのtopk-moe融合処理を拡張し、浅いコンテキストでのデコード処理をわずかに高速化しました。効果は構成やコンテキスト長で変わり、深いコンテキストでは頭打ちになるとされています。とはいえ、MoEをローカルで回す土台が着実に整いつつあるのは確かです。

もう1点、見落としやすいのがコンテキスト長とKVキャッシュです。扱うトークンが増えるほどKVキャッシュなどの確保分でVRAMは膨らみます。早見表の目安はあくまで標準的なコンテキストでの値であり、長文を大量に流し込む使い方では、実際の使用量はこれより増えると考えておくべきです。公称のモデルサイズだけを見て「16GBに収まる」と決めつけず、コンテキスト分の余白も込みで見積もってください。

用途別の現実的な構成例（エッジ / 個人開発 / 大規模）

サイズと必要VRAMがわかったところで、用途別にどんな器が合うかを整理します。「速度と品質の最高峰が欲しい」なのか「とにかく手元で動けばいい」なのかで、選ぶハードは変わってきます。

エッジ向けには9Bが向いています。Ryzen 7 7735HSにメモリ32GBを組み合わせたGMKtec K16のようなミニPCが、679ドル程度で報じられた価格帯で流通しています（販売時期・構成により変動）。こうしたミニPCは内蔵GPUやNPUが中心で、大型モデルの推論には力不足ですが、9Bクラスの軽量モデルを補助的に回すには十分な器になります。省スペースでローカルAIを常時待機させたい人には現実的な選択肢です。

個人開発のデスクトップなら、VRAM 16GB級のGPUが軸になります。当サイトの実機であるRTX 5080（16GB）ではOrnith-1.0-9Bも35Bも動きました。RTX 5070 TiやRTX 5060 Ti 16GBも同じ16GBクラスで、9Bなら余裕を持って扱いやすく、35B MoEも一部オフロード前提で試せる可能性があります。RTX 5060 Ti 16GBは16GB VRAMのGPUとして最安クラスで、AI入門から中級までをカバーできる。予算と相談しながら、まず16GBを確保する、という考え方が扱いやすいでしょう。

大規模の397Bは、器の話が一段変わります。RTX 5090はGDDR7を32GB積むハイエンドですが、それでも397Bを1枚で抱えるのは無理。複数GPUで分散させるか、96GB級のプロ向けGPU、あるいはクラウドに頼ることになります。個人が常用するモデルではなく、性能の上限を確認するためのリファレンス、という位置づけで捉えるのが妥当です。

配布はHugging Faceで行われています。Ollamaを使うなら、GGUF版を次のように指定して起動できます。

ollama run hf.co/deepreinforce-ai/Ornith-1.0-9B-GGUF:Q4_K_M

35Bを試したい場合は、モデル名の9Bを35Bに差し替えるだけ。まず9Bで挙動と品質を確かめ、物足りなければ35Bに上げる流れが、VRAMを無駄にせず試すコツです。

GPUを積まずに使う選択肢

「そもそもGPUを増設したくない」という人にも道はあります。コーディング用途に限れば、モデルをローカルで動かさず、クラウド側でホストされた最上位モデルやAPI経由で使う手が現実的です。手元のPCはエディタとネットワークだけあればよく、AI推論用のGPUは不要になります。

実際、API課金型のAIコーディング支援ツールは、GPUなしのノートPCでも快適に動きます。効いてくるのはCPU・RAM・SSDの速度で、GPUではありません。ローカルで397B級を回す代わりにクラウドの最上位を叩く、という割り切りは、初期投資を抑えたい人には合理的な選択です。ローカルの9B/35Bで日常のコード補完をこなし、難しい設計判断だけクラウド最上位に投げる、といった使い分けもできます。

「Claude超え」ベンチマークの読み方

Ornith-1.0の話題の中心は「397BがClaude Opus 4.7を上回った」という一点です。ここは冷静に読み解いておきたいところ。この比較は、2026年6月時点で、特定のコーディング系ベンチマークで測った結果です。「あらゆる面でClaudeを超えた」という無条件の一般化ではありません。

まず時点。AIモデルは更新が速く、比較対象が上位版に差し替われば結果は変わります。「6月時点で公開されたベンチマークでは上回った」という限定を外さないことが大事です。実際、公式表に掲載されたClaude Opus 4.8との比較では、SWE-Bench VerifiedでOrnith-1.0-397Bのスコアが下回っており、「Opus超え」はOpus 4.7限定の話だと分かります。次に射程。測られたのはコーディング能力であって、日本語の自然さ、事実確認の堅さ、長い対話での安定性といった別のタスクは、このスコアからは何も言えません。本記事でもそこは未評価です。

当サイトが計測したのは速度とVRAM使用量だけで、出力品質そのものは検証していません。9Bで110.7 tokens/sec、35Bで73.1 tokens/secという数字は「手元でどれくらいの速さで動くか」を示すものであって、「Claudeと同じ品質のコードが出る」ことを保証する数字ではない。速度は測った、品質は測っていない。この線引きははっきりさせておきます。

新しいモデルだけに、第三者による実測の蓄積はまだこれから。自分のタスクで本当に使えるかは、実際に9Bあたりをダウンロードして、いつも書いているコードで試してみるのが一番確実です。ベンチマークの順位は入口の判断材料。最終的な合否は、ご自身の手元のコードで決めてください。

まとめ

Ornith-1.0を手元で動かせるかは、サイズとモデルタイプで決まります。優先順位をつけるなら、まず自分のGPUのVRAMを確認し、次にサイズを選ぶ、という順序。VRAM 16GB級を持っているなら、9Bは快適に動き、35B MoEもRTX 5080 16GB環境で生成確認できました。ただし35Bは全GPU常駐ではなく一部RAMオフロード前提のため、16GBは試用・軽めの運用ラインで、余裕を見た運用には24GB以上が安全です。当サイトの検証環境（RTX 5080単体）では、9Bは110.7 tokens/sec、35Bは73.1 tokens/secで動作を確認しました。

31Bは近日公開予定で、Denseゆえに24GB級以上のVRAMが現実的。397Bは総パラメータ分のメモリが数百GB級必要で、単体の家庭用GPUでは動かせず、複数GPUかクラウドが前提になります。「MoEだから軽い」という感覚を、VRAMの必要量にそのまま当てはめないこと。ここが最大の分かれ目です。

手元で試すなら、まずは9BをOllamaで動かしてみる。それがVRAMを無駄にせず、Ornith-1.0の使い勝手を確かめる最短ルートです。

よくある質問（FAQ）

Q. Ornith-1.0はVRAM 16GBで動きますか？

9Bは動きます。35B MoEも当サイトのRTX 5080 16GB環境では生成を確認できましたが、全レイヤーがVRAMに常駐した状態ではなく、Ollamaの/api/psではGPU常駐67%・残りはシステムRAM側へのオフロードでした。したがって、35Bを快適に使うなら16GBは下限寄りで、長文コンテキストや全GPU常駐を狙うなら24GB以上を見込む方が安全です。31Bと397Bは16GBでは足りません。

Q. どのサイズがどのGPUで動くのか、目安を教えてください。

9BはVRAM 8GB級から動き、12〜16GBで快適。35B MoEはRTX 5080 16GB環境で生成確認できていますが、全GPU常駐ではなく一部RAMオフロード前提のため、余裕を見るなら24GB以上が安全です。31B Dense（近日公開予定）は20GB前後を要し24GB級以上が現実的で、これらは一般目安です。397Bはデータセンター級で、RTX 5090（32GB）1枚でも収まらず、複数GPUかクラウドが前提になります。

Q. GPUがなくてもOrnith-1.0のようなモデルを使えますか？

コーディング用途なら、クラウドでホストされた最上位モデルやAPI経由で使えばGPUは不要です。手元のPCはCPU・RAM・SSDが効き、AI推論用GPUは要りません。ローカルで動かしたい場合のみ、9Bや35Bに合わせたVRAM 16GB級GPUを検討する形になります。

Q. Ornith-1.0は商用利用できますか？

ライセンスはMIT Licenseで、商用利用を含めて扱いやすい条件です。ただし利用時は配布元のライセンス表記を必ず確認してください。ベースにGemma 4とQwen 3.5が使われているため、実運用ではベースモデル側の利用条件も併せて確認しておくと安全です。

参考資料

• GitHub: deepreinforce-ai/Ornith-1
• Hugging Face: Ornith-1.0 Collection（配布ページ）
• llama.cpp: Releases（MoE推論最適化の更新履歴）
• NVIDIA公式: GeForce RTX 5090 製品ページ
• Ollama公式サイト（GGUFモデルの実行環境）