Ornith 1.5をRTX 3060で評価：セットアップ方法と46問のテスト結果
社内の検証マシン（GeForce RTX 3060 VRAM 12 GiB）で動かしているOrnith 1.5について、公式情報と導入構成を確認し、回答品質と応答速度を測定しました。
対象は約35BのMoEモデルをQ4_K_M形式に量子化した版です。GeForce RTX 3060のVRAM 12 GiBとホスト側のメモリを併用して動かしています。
今回の小規模テストでは、算数文章題GSM8Kの抽出30問中29問、日本語の読解・指示追従・論理・ツール選択16問中14問が採点条件を満たしました。短い日本語説明文を生成する速度測定では、生成速度の中央値は約57.4 tokens/sでした。いずれもDQNの現在の量子化版・推論設定で得られた結果です。
検証日・公式情報確認日：2026年9月24日（日本時間）。原本の問題、期待値、全リクエスト、回答、採点結果、実行環境はファイルに保存しています。
Ornith 1.5の公式情報
Ornith 1.5は、課題の生成、解き方の組み立て、解答の生成を強化学習のサイクルに組み込むことを特徴とするモデル群です。今回の35B-A3Bは、その中間サイズのMoEモデルです。出典：Ornith公式解説。
| 項目 | 公式モデルの情報 |
|---|---|
| モデルID | ornith-ai/Ornith-1.5-35B-A3B |
| 規模 | 総パラメータ約35B、1トークン当たりの活性パラメータ約3B |
| アーキテクチャ | Qwen3.5系のMixture of Experts（MoE） |
| コンテキスト長 | 262,144トークン |
| 推論方式 | 推論過程と最終回答を分けて返すreasoning model |
| ライセンス表記 | MIT |
仕様の出典は公式モデルカードです。A3Bは推論時に活性化するパラメータ数の目安であり、モデルファイル全体が3B相当になるという意味ではありません。
公式ベンチマーク値は、今回の実測とは別
| 評価 | 公式モデルカードの報告値 |
|---|---|
| SWE-bench Verified | 79.0 |
| Terminal-Bench 2.1（Terminus-2） | 67.8 |
| GPQA Diamond | 89.2 |
上の値は提供元の報告で、本稿では再現していません。今回測るのはQ4_K_M量子化版で、使用する問題、推論エンジン、出力上限も異なります。公式値と今回の正答率を同じ尺度で比較することはできません。
DQNで実際に動いている構成
| 項目 | 確認結果 |
|---|---|
| OS / CPU / メモリ | Ubuntu 24.04.4 LTS / Intel Core i5-12400（6コア・12スレッド）/ 32 GiB |
| GPU | NVIDIA GeForce RTX 3060、VRAM 12,288 MiB |
| GPUドライバー | 580.173.02 |
| CUDA Toolkit / CMake | 12.0.140 / 3.28.3 |
| 推論エンジン | ik_llama.cpp、build 4533 |
| モデル | Ornith-1.5-35B-Q4_K_M.gguf |
| モデルファイル容量 | 21,713,462,848 bytes（約20.22 GiB） |
| サーバー設定 | コンテキスト131,072トークン、同時処理1枠、CPUスレッド8 |
| KVキャッシュ | K/Vともq8_0 |
| モード | reasoning有効、MTP無効 |
| 今回の入力 | テキスト。稼働中APIのvision/audioはともにfalse |
モデルの重みは、起動ログ上でCUDA側が7,878.90 MiB、CUDA_Host側が12,296.81 MiBに配置されています。12 GiBのVRAMだけに約20 GiBのモデル全体を載せているわけではなく、--fit により一部のエキスパート重みをホスト側へ配置する構成です。KVキャッシュや計算用バッファは別に確保されます。
公式モデルには画像を含む利用例もありますが、DQNの現在のサービスは画像入力を有効にしていません。本稿の評価対象は言語モデルとしてのテキスト処理です。
モデルの版をハッシュで特定した
DQNに保存されているGGUFのSHA-256を計算し、公式リポジトリの過去revisionのLFS情報と照合しました。使用中のファイルは次のrevisionと完全一致しました。
GGUF revision: fbbaed45c2f0e200276ffa51701a24d45dc7f57e
GGUF SHA-256: ca6ea26329c88b78ffd90a85163be2e746c2fafd1024f56db47e499f117f9a7f
ik_llama.cpp commit: b3d39cff8bffbd67296d6badd4076a1486a0715c2026年9月24日時点の公式mainにある同名GGUFはハッシュが異なります。したがって、本稿は最新mainの評価とはせず、上記の旧revisionを使った評価として記録します。新旧でどれだけ回答品質が変わるかは今回測っていません。出典：公式GGUFリポジトリとローカルファイルの照合。
同じ構成を再構築するためのセットアップ手順
以下はUbuntu環境に検証時の構成を再構築するための手順です。既存のソースコミット、CMake設定、サービス起動オプションを確認して整理しました。今回の評価自体は、稼働済みのサービスを使って行っています。
1. ビルド環境とCUDAを確認
sudo apt-get update
sudo apt-get install -y build-essential cmake git curl python3
nvidia-smi
nvcc --versionNVIDIAドライバーとCUDA Toolkitはあらかじめ利用可能な状態にします。DQNでは上表の既存環境を使いました。GPU向けビルドにCUDA Toolkitが必要であることは、ik_llama.cppのビルド手順に記載されています。
2. 検証時の推論エンジンをビルド
mkdir -p ~/src
cd ~/src
git clone https://github.com/ikawrakow/ik_llama.cpp.git
cd ik_llama.cpp
git checkout b3d39cff8bffbd67296d6badd4076a1486a0715c
cmake -S . -B build \
-DCMAKE_BUILD_TYPE=Release \
-DGGML_CUDA=ON -DGGML_BLAS=OFF -DLLAMA_CURL=OFF
cmake --build build --config Release -j 6 --target llama-server
./build/bin/llama-server --versionこれは再構築用のコマンド例であり、今回あらためてクリーンビルドを実行したものではありません。DQNの既存ビルドではRelease、CUDA有効、BLASとCURLは無効になっていることを確認しました。
3. 検証した版のGGUFを取得し、照合
mkdir -p ~/models/ornith15
cd ~/models/ornith15
curl --fail --location \
'https://huggingface.co/ornith-ai/Ornith-1.5-35B-A3B-GGUF/resolve/fbbaed45c2f0e200276ffa51701a24d45dc7f57e/Ornith-1.5-35B-Q4_K_M.gguf' \
--output Ornith-1.5-35B-Q4_K_M.gguf
echo 'ca6ea26329c88b78ffd90a85163be2e746c2fafd1024f56db47e499f117f9a7f Ornith-1.5-35B-Q4_K_M.gguf' | sha256sum -c -revisionを固定するのは、同じファイル名でも配布内容が更新されるためです。比較や再検証ではファイル名と量子化名だけでなく、ハッシュも記録します。
4. サーバーを起動
~/src/ik_llama.cpp/build/bin/llama-server \
-m ~/models/ornith15/Ornith-1.5-35B-Q4_K_M.gguf \
--jinja --reasoning on --reasoning-format deepseek \
--no-multi-token-prediction \
--fit --fit-margin 1664 \
--ctx-size 131072 \
--cache-type-k q8_0 --cache-type-v q8_0 \
--no-mmap --mlock --threads 8 \
--temp 0.6 --top-p 0.95 --top-k 20 --min-p 0.0 \
--host 127.0.0.1 --port 8080--fit は利用可能なGPUメモリに応じて配置を決め、--fit-margin 1664 はその余裕をMiB単位で指定します。記事の例は同一マシンから接続するため127.0.0.1を使っています。DQNでは管理ネットワークにバインドしたsystemdサービスとして稼働しています。
--mlock はモデルをRAMに保持する指定です。DQNのsystemd設定は LimitMEMLOCK=infinity になっています。ターミナルや別のサービスで同じオプションを使う場合は、メモリロック上限も整える必要があります。
5. APIの動作確認
curl --fail http://127.0.0.1:8080/health
python3 - <<'PY'
import json
from urllib.request import Request, urlopen
base = "http://127.0.0.1:8080"
with urlopen(base + "/v1/models") as response:
model = json.load(response)["data"][0]["id"]
payload = {
"model": model,
"messages": [{"role": "user", "content": "6×7の答えを短く教えてください。"}],
"temperature": 0.6, "top_p": 0.95, "top_k": 20,
"max_tokens": 2048,
}
request = Request(
base + "/v1/chat/completions",
data=json.dumps(payload).encode(),
headers={"Content-Type": "application/json"},
)
with urlopen(request, timeout=180) as response:
result = json.load(response)
print(result["choices"][0]["message"].get("content", ""))
print(result.get("timings", {}))
PYAPIの応答には最終回答の content と推論用の reasoning_content が分かれて入ります。出力上限は推論トークンにも使われるため、短い最終回答を求める場合でも上限が小さすぎると回答に到達しないことがあります。
評価方法：公開算数30問と日本語16問
回答を眺めるだけの評価にならないよう、問題と期待値を実行前に固定し、数値・JSON・ツール名と引数で自動採点しました。モデルへ送ったのは問題文と必要なツール定義だけで、期待値は渡していません。
| 区分 | 件数 | 評価内容 |
|---|---|---|
| GSM8Kの一部 | 30 | 英語の算数文章題。公式test 1,319問からseed=20260924で重複なし抽出 |
| 日本語・抽出と指示 | 6 | 金額計算、訂正後の注文抽出、未記載値のnull、優先順位、引用文内の命令の扱い、120行の在庫表 |
| 日本語・論理とコード読解 | 6 | Pythonの参照共有・クロージャ、並び順、会議選択、条件判定、論理的含意 |
| ツール選択 | 4 | 適切な関数と引数の選択2問、不要・情報不足時に呼び出さない確認2問 |
GSM8Kの出典は公開元のgrade-school-mathリポジトリです。使用コミットは 3101c7d5072418e28b9008a6636bde82a006892c。日本語16問は今回作成した独自問題です。ツールの選択結果は採点しますが、実際の天気取得や在庫変更は行っていません。
| 測定条件 | 設定 |
|---|---|
| 入力方式 | 会話履歴なしの1問ずつ。例題なし（zero-shot） |
| 生成パラメータ | temperature=0.6、top_p=0.95、top_k=20、min_p=0.0、seed=20260924 |
| 出力上限 | 各問題2,048トークン。推論過程を含む |
| 試行回数 | 各問題1回。再質問・自己修正・良い回答の選別なし |
| 外部支援 | 検索・計算機・コード実行・RAGなし |
| 並列度 | 1。各リクエストの前に空き状態を確認 |
| プロンプトキャッシュ | cache_prompt=false。API報告の最大cached_tokensは0 |
算数は最終回答の #### に続く数値を、通貨記号と桁区切りを除いて期待値と比較しました。日本語の構造化回答はJSONとして完全一致、ツール選択はネイティブな tool_calls の関数名とJSON引数を比較しています。LLMを採点者には使っていません。
回答品質の実測結果
| 区分 | 正答・成功数 | 今回の割合 |
|---|---|---|
| GSM8K-30 | 29 / 30 | 96.7% |
| 日本語・抽出と指示 | 6 / 6 | 100.0% |
| 日本語・論理とコード読解 | 6 / 6 | 100.0% |
| ツール選択 | 2 / 4 | 50.0% |
日本語のテストでは、資料にない売上高を null にする、メール内に埋め込まれた別の指示をデータとして扱う、120行の在庫表から指定行を取り出す、といった条件を満たしました。Pythonの短いコードを読む問題にも回答できています。小さな個別試験の成功であり、日本語全般や安全性全般の保証にはなりません。
ツール選択では、指定の天気取得関数と在庫照会関数を、正しい引数で呼び出す形式を返しました。計算だけの質問や都市未指定の質問では、指示どおり関数を呼び出しませんでした。ただし、この2問では「JSONだけ」という指定に反し、説明文やMarkdownのコード囲みが付いたため不合格です。この4問は単発の選択と出力形式の試験で、実作業を複数ステップ進めるエージェント評価ではありません。
ツールを呼ぶ判断と、出力形式の遵守は別だった
計算問題の最終回答は次の形式でした。値42は合っていますが、全体をそのままJSONとして読み込むことはできません。
6×7 = 42
{"answer": 42}都市未指定の問題でも、missingにcityを挙げた後に説明文を追加していました。関数を呼ぶ／呼ばない判断は4件とも期待どおりでしたが、指定形式を含む厳密な合格は2/4です。ツールを組み込むアプリでは、回答内容だけでなく、受け取った形式の検証も必要だと分かります。
1問は推論中に上限へ達し、最終回答が空
GSM8Kの元データ行119（0始まり）は、生成数が2,048トークンに達し、最終回答のcontentは空でした。所要時間は約37.20秒です。採点上は未回答として失敗に数え、試験対象から外していません。APIのfinish_reasonはstopでしたが、生成数と最終回答の有無も確認してこの状態を記録しました。
この給与比率の設問は、問題文が「AはBより30%高い」とする一方、参照解答は「BはAより30%低い」として計算しており、両者の関係式が一致しません。問題文の A=1.3B に対して、参照解答は B=0.7A を使っています。この不整合も記録しましたが、未回答の原因をそれと断定したり、モデルの計算誤りとして扱ったりはしていません。
採点器の点検では、#### $255 のような通貨記号付き答案を初期の正規表現が拾えないことも見つかりました。3件は同じ保存済み回答を数値として正規化して再採点し、上表に反映しています。初期結果と修正内容の両方を残しており、モデルへの再実行はありません。
応答速度：最初の生成と最終回答の開始を分けて測る
回答品質の46問とは別に、「ローカルとクラウドの言語モデルの違いを日本語300〜400字程度で説明する」という同一の依頼をストリーミングで測定しました。最初の生成データが届く時間と、最終回答の本文が始まる時間を分けて記録しています。
最初は出力上限1,024トークンで3回測りましたが、3回とも本文の途中で上限に達しました。この条件での生成速度の中央値は53.63 tokens/sです。完了までの時間を調べるため、出力上限だけを4,096トークンに変更して同じ依頼を3回追加測定しました。以下は追加測定の結果です。初回のログも保存し、46問の品質スコアにはどちらの速度試験も含めていません。
| 回 | 最初の生成データ | 最終回答本文の開始 | 応答完了 | 生成速度 |
|---|---|---|---|---|
| 1 | 0.282秒 | 15.972秒 | 18.915秒 | 57.37 tokens/s |
| 2 | 0.364秒 | 16.044秒 | 18.986秒 | 57.41 tokens/s |
| 3 | 0.266秒 | 15.925秒 | 19.074秒 | 56.84 tokens/s |
追加測定では、生成トークン数は各回1069、本文は各回339文字で、いずれも4,096トークンの上限に到達せず終了しました。依頼した300〜400字の範囲への適合や文章の内容は、速度試験の採点項目にはしていません。
3回の中央値は、最初の生成データまで0.282秒、最終回答本文の開始まで15.972秒、応答完了まで18.986秒でした。reasoningモデルでは最初に推論用データが出るため、最初のトークンが速く届くことと、ユーザー向けの答えがすぐ始まることは区別する必要があります。
時間はDQN上でHTTPリクエストを開始してから計測しました。生成速度はサーバーが返す timings.predicted_per_second で、推論トークンも含みます。tokens/sは文字数/秒ではありません。モデルは起動済みで、モデルロード時間やアプリ起動時間は含みません。3回だけの測定で、同時利用時や長文での速度を示すものでもありません。
品質試験46問では、リクエスト全体の所要時間の中央値は約5.04秒でした。問題ごとに入力長・生成長が異なるため、単純に1問当たり同じ速さとはなりません。
メモリ使用量と測定後の状態
| 観測項目 | 値 |
|---|---|
| GPU全体の使用量・最大観測値 | 10,105 MiB |
| サーバープロセスのRSS・最大観測値 | 18,047 MiB |
| ホストの利用可能メモリ・最小観測値 | 6,033 MiB |
| サーバープロセスのswap・最大観測値 | 0.00 MiB |
| 監視間隔 | 約1秒 |
GPU使用量、プロセスRSS、ホストの利用可能メモリはそれぞれ定義が異なります。共有のホスト上での観測であり、これらの値を足し合わせてモデルの必要容量とすることはできません。監視間隔より短い瞬間的なピークも含みません。
追加測定も含めた終了後は ik-llama.service=active、APIの /health は status=ok、処理中リクエスト0を確認しました。
この結果から評価できる範囲
今回の構成では、RTX 3060と32 GiBメモリを使って約35Bの量子化モデルを動かし、短い算数問題、条件を明示した日本語処理、単発のツール選択に対応できることを確認しました。推論中に出力予算を使い切るケースもあるため、アプリ側は最終回答が空でないか、生成数が上限に達していないかを確認する必要があります。
GSM8Kは30問の小標本で、しかも公開済みデータです。学習時に同じ問題を見た可能性は確認できていません。独自の日本語16問も特定の能力だけを調べたものです。今回の最大入力は1,974トークンで、設定上の131,072トークン全域の性能を測ったわけではありません。
コード生成の実行テスト、SWE-bench、長時間のエージェント作業、画像理解、多人数の同時利用、別モデルや別量子化との比較は今回の評価に含まれません。この結果は「Ornith全体の総合点」ではなく、DQNで使っている版と設定の動作・応答品質を判断する材料として扱います。
参照資料と保存した検証ファイル
Ornith公式解説 ／ 35B-A3B公式モデルカード ／ 公式GGUF ／ ik_llama.cppのビルド資料 ／ GSM8K公開元。公式情報は2026年9月24日確認。
検証記録には、問題と期待値の cases.json、測定条件の methodology.json、モデルのハッシュを記録した verified-installation.json、全回答の results/responses.jsonl、採点確認後の results/audited-summary.json と results/audited-scores.json、各問の一覧 results/scores.csv、速度測定ログとリソース観測値を保存しました。