文章を書かないAI「Jev」はRTX 3090で動く？〜同じ型のローカル版で、1回の判断にかかる時間と選択肢ごとの確率を測った
状態と選択肢を渡すと、文章は書かずに、選択肢の中から答えを選ぶAIがあります。TypeSafe社が2026年9月15日に「判断モデル」として発表したJevがその一例で、公式の案内ではAPIでの提供とされ、重みの公開は書かれていません。一方で、同じ型のローカル版（APUS-OpenJev）がHugging Faceに公開されています。ローカル版が受け付ける選択肢は2〜16個です。
本記事では、このローカル版をRTX 3090のデスクトップPCで動かし、1回の判断にかかる時間と、選択肢ごとの確率が取れるかを測りました。手元のPCで、文章を書かないAIは使い物になるのでしょうか？
2026年10月時点の内容です。
判断モデルのJevとは？
ChatGPTのような文章を書くAIは、答えを1語（トークン）ずつ生成します。判断モデルは文章を生成せず、あらかじめ決めた選択肢（Jev本体は最大255個）のうち、どれが正しいかの確率を返します。たとえば問い合わせメールを「返金」「担当者へ回す」「追加で質問する」のどれかに仕分ける場面です。
TypeSafe社の公式の案内では、入力は100万トークンあたり$0.042、応答は70〜500ミリ秒とされています。これは同社が示す数字で、当ブログでは確かめていません。
今回動かしたのは、Jev本体ではありません。APUS-OpenJev-v1-9Bは、Jevと同じ型の問いを扱う別のモデルです（Apache-2.0、Qwen3.5-9Bを土台に学習）。Jevと同じ精度や速さを持つかは分かりません。
何を測ったのか
同じデスクトップPCで、3択・8択・16択・はい/いいえ・長い文章（約1,600トークン）の5種類の問いを、それぞれ7回ずつ判断させました。測ったのは、1回の判断にかかる時間[ms]と、選んだ選択肢の確率が毎回取れるかです。
使用した機器の概要
使用したデスクトップPCは、下記のとおりです。
| 項目 | 内容 |
|---|---|
| GPU | RTX 3090（VRAM 24GB） |
| OS | Ubuntu |
| 実行環境 | Ollama 0.30.5 |
| モデル | APUS-OpenJev-v1-9B（Q4_K_M、5.2GiB） |
どう測ったのか
問いは、モデルカードが参照する入力形式の文面を読み、標準ライブラリだけのPythonで自作して組み立てました。入力形式では、「Shared state:」の後に状態を書き、続けて選択肢をJSONで並べ、「Answer:」で終えます。外部のプログラムは実行していません。問いの中身は、サポート窓口の対応を選ぶ場面（注文が2日遅れ、商品が壊れていたが少額の値引きなら納得する、という客の書き込み）を使いました。選択肢は「チケットを閉じる」「担当者へ回す」「返金する」などです。
答えは温度0で1トークンだけ出させ、そのトークンに対する上位20件の候補（logprobs）から、選択肢の記号の確率を取り出しました。選択肢の確率は、その記号どうしで合計が1になるよう計算し直しています。
Ollamaは、前回と同じ書き出しの入力を受けると、その部分の処理を使い回します（前置キャッシュ）。そこで「毎回入力を変える」場合と「毎回まったく同じ入力を送る」場合を分けて測りました。入力を変える場合は、各回の先頭に回ごとに違う文字列を足しています。
各条件を7回測り、最も速い値と最も遅い値を1つずつ除いた5回の中央値を使っています。時間は、Pythonからリクエストを送って返事を受け取るまでの経過時間です。呼び出し方は、モデルの入力書式を自分で組む方法（generate）と、Ollamaに任せる方法（chat）の2通りを測り、本文の表はgenerateの値です。
今回のOllamaは0.30.5で、判断モデル専用の呼び出し口はありません。そのため、文章生成用の呼び出し（generate）で1トークンだけ出させ、候補の確率（logprobs）を読む方法で測りました。Ollamaは2026年9月28日の0.35.0で、判断モデル専用の /v1/systemone を追加しています（対応モデルはNimble・Tev1。9月29日の0.35.1でClef・Clef Flashを追加）。本記事のモデルがこの呼び出し口で動くかは確かめていません。
出典: Ollama v0.35.0、v0.35.1、Ollama docs（systemone）
1回の判断にかかる時間は？
毎回入力を変えた場合は、入力が長いほど時間が延びました。同じ入力を繰り返した場合は、入力の長さにかかわらず約0.45秒でした。
| 問い | 入力の長さ[トークン] | 毎回入力を変える[ms] | 同じ入力を繰り返す[ms] |
|---|---|---|---|
| 3択 | 164 | 554.4 | 446.3 |
| 8択 | 273 | 586.8 | 450.0 |
| 16択 | 440 | 626.7 | 447.1 |
| はい/いいえ | 136 | 556.1 | 448.8 |
| 長い文章の3択 | 1,587 | 980.5 | 449.2 |
7回のばらつきは小さく、たとえば3択（毎回入力を変える）は547.0〜565.6ミリ秒でした。chatで呼ぶと、毎回入力を変える場合が512.1〜937.3ミリ秒、同じ入力の場合が398.1〜407.3ミリ秒で、generateより約40〜50ミリ秒短くなりました。
モデルを読み込む最初の1回だけは、4,714ミリ秒かかりました。表の値はすべて、読み込み済みの状態です。
選択肢の確率は取れる？
全条件・全回で、すべての選択肢の記号が候補上位20件に入り、確率を計算できました。選ばれた選択肢の確率は、問いによって差がありました。
| 問い | 選ばれた選択肢の確率（毎回入力を変えた7回の最小〜最大） |
|---|---|
| 3択 | 0.816〜0.903 |
| 8択 | 0.968〜0.979 |
| 16択 | 0.895〜0.924 |
| はい/いいえ | 0.996〜0.997 |
| 長い文章の3択 | 0.906〜0.948 |
同じ入力を繰り返すと、確率は7回とも同じ値でした（3択は0.914）。選ばれた選択肢は全条件・全回で同じ記号でした。
約0.4秒の下限は何から来る？
同じ入力を繰り返したときは、111トークンでも1,562トークンでも約0.45秒で、ほぼ同じです。前置キャッシュで入力の処理が省かれ、答えの1トークンを出すだけになっても、約0.4秒は残りました。
この下限は、GPUの計算ではなく呼び出しごとの固定の手間による可能性があると考えられます。これが本当なら、もっと小さいモデルに替えても下限はほとんど下がらないはずです。小さいモデルでは測っていないため、切り分けはできていません。
切り分けには、同じ呼び方でより小さいモデル（たとえば数百Mパラメータの判断モデル）を測り、下限が下がるかを見る方法が考えられます。
今回確かめていないこと
- 正解率。ローカル版の判断が正しいかは測っていません。ローカル版のモデルカードにある68/80（85.00%）は、開発用の80問での結果で、独立したblind（初見の問い）の評価ではないと、モデルカード自身に書かれています。
- 確率の信頼度。0.9と出た判断が9割当たるかは確かめていません。
- 日本語の問い。今回の問いはすべて英語です。
- Jev本体。API提供のため動かしていません。
- 他のGPU・他のモデル・同時に複数の判断を投げた場合。
第三者の評価としては、Red Hatが2026年10月2日に公表（10月5日更新）した比較があります。分類器やLLMによる判定、他の公開判断モデルを、速さでも精度でも常に上回るわけではなく、content safetyではJevが86.20%で首位、prompt injectionではQwen3.6-35Bが89.31%で上回ったとされています。ローカル版の正確さは、これとは別の話です。
最新情報（2026年10月11日時点）
この記事を書いたあとに出た動きを、事実だけ並べます。以下は当ブログでは動かしていません。
- 2026年10月2日、llama.cppのサーバーにも判断モデル用の /v1/systemone が入りました。公式のGGUFがあるのは、Julia-1（144M）・Laya（421M）・Kev-4B・lev（4B）・OpenJev（27B）・Clefで、RTX PRO 6000での中央値は3〜43ミリ秒/問と公表されています。ここにあるOpenJev 27Bは別の提供元のモデル（CC BY-NC 4.0・非商用のみ）で、本記事のAPUS-OpenJev-v1-9B（Apache-2.0）とは別物です。本記事のモデルは、この一覧に入っていません。
出典: Hugging Face Blog（ggml-org）、ggml-org decision-models - 2026年10月6日、OpenAIがDecisions API（gpt-6-luna）をベータで公開しました。文章と画像から、型の決まった答えを返すAPIです。
出典: OpenAI API changelog - 2026年10月7日、Liquid AIが判断モデルd1-3B（3.12B）と、実験版のd1-omni-600M（587M・文章と画像、または文章と音声）の重みを公開しました（LFM Open License 1.0）。d1-3Bは同社の公表でRTX 4090で8ミリ秒/問、GGUF（Q4_K_M 1.67GB）が配布され、llama.cppの /v1/systemone で動くとされています。d1-omni-600Mは速度の公表がありません。
出典: Liquid AI（Hugging Face Blog）、d1-3B、d1-3B-GGUF - Red Hatの比較では、Jev（API）の中央値は348.1ミリ秒で、うち約56ミリ秒は大西洋越えの通信とされています。本記事のローカル版約450ミリ秒とは、モデルも問いも違うため、直接は比べられません。
出典: Red Hat Developer
まとめ〜RTX 3090で判断モデルは動き、1回は約0.4〜1秒
APUS-OpenJev-v1-9B（Q4_K_M）は、RTX 3090のデスクトップPCで動き、選択肢ごとの確率が全回で取れました。1回の判断は、入力を毎回変えた場合に0.55〜0.98秒、同じ入力を繰り返した場合に約0.45秒でした。これらの値は、今回のPCと呼び出し方で出たもので、Jev本体の速さを示すものではありません。
文章を書かせず、確率を返させて仕分けに使うやり方が、ローカルのAIで成り立つかを見られたのは、ローカルLLMを使い込むうえで一つの収穫でした。ほかのローカルLLMの実測も、あわせて読んでみてください。
判断モデルを試すかどうか、どう決めるか
| こんな人 | 目安 |
|---|---|
| 選択肢が決まった仕分け（問い合わせの分類、処理の振り分け）を自動化したい | 試す価値があります。1回0.4〜1秒なら、1件ずつの処理には使えます |
| 数千件を短時間で処理したい | 今回は同時に複数投げた場合を測っていないため、先に自分の件数で測ってください |
| 判断が正しいことが重要（安全性の判定など） | 正解率は未測定です。自分のデータで正解率を確かめてから決めてください |
| 文章で説明してほしい | 向きません。判断モデルは理由を文章で返しません |
迷ったら、自分の仕分けの例を20件ほど用意し、同じモデルで確率と正解を見比べるところから始めるのが確実です。