高速判定AI Jevをローカルで再現できないか？〜仕組みから手元のモデルで再現を試みた
「文章を書かない生成AI」が出てきました。TypeSafe AI の Jev というもので、文字の代わりに選択肢と確率を返します。速さは70〜500ミリ秒だそうです。
ただ、これはクラウドのサービスで、手元には置けません。では同じ形は、手元のGPUでどこまで作れるのでしょうか。
目的〜文章を書かせなければ、どれだけ速くなるのか
ローカルLLMを使っていると、待ち時間のほとんどは文章を書いている時間です。ところが「緊急か、様子見か、無視か」を選ばせたいだけなら、文章は要りません。
Jev はそこを捨てた作りでした。公式にはこう書かれています。
Jev gives up string generation
文字を書くのをやめる代わりに、型の付いた答えと確率を返す。それで40〜200倍 速いと公称されています。
この記事で確かめたいのは3つです。手元で同じ速さが出るのか。答えは変わらないのか。そして確率まで取れるのか。
先に、ここで言う「確率」が何なのか
この記事には「確信度80%」のような数字がたくさん出てきます。読み違えると意味が反対になるので、先に何の数字なのかを書いておきます。
例えば、あるログを見せて「これは緊急か。はい か いいえ で答えよ」と聞いたとします。モデルは「はい」と答え、確信度80%と付けてきました。
この80%は、モデルの中で「はい」という語に付いた重みが0.8、「いいえ」が0.2だったという意味です。生成AIは次の1語を選ぶとき、候補の語それぞれに「出やすさ」を付けています。その比を取り出しただけで、計算された実在の数字です。デタラメではありません。
ただし「80%の確からしさで正解」という意味ではありません。この重みは「どれだけ言いたいか」であって、「どれだけ当たるか」として学習されたものではないからです。自信たっぷりに間違えれば、80%と言ったまま外れます。
では、この80%は当てになるのか。測らないと分かりません。「80%と言ったとき、実際に100回中何回 当たったか」を数えて初めて分かります。この一致具合を較正と呼びます。この記事で確かめたかったのは、そこです。
Jev の側はどうか。公式ドキュメントにはこう書かれています。
Confidence is a statistic computed from the probability distribution the answer already gives you.
その分布は「あなたが宣言した選択肢の上に」広がると書かれています。語彙全体ではありません。使い方の目安も示されていて、0.5未満なら人に回せ、0.5〜0.9は注意して進めよ、0.9を超えたら自動で実行してよい、とされています。
手元の確率と Jev の確率は、出どころの形からして別物です。同じ「80%」でも、後者は選択肢の上に直接置かれた数字で、前者は語の出やすさから作った代用品です。
実験内容〜同じ問いを、2つのやり方で解かせる
機材と道具
| 項目 | 内容 |
|---|---|
| 機材 | GeForce RTX 5060 Ti 16GB（26B のみ RTX 3060 12GB を併用） |
| 動かしたもの | llama.cpp b10941（HTTPサーバ） |
| 使った引数 | grammar／n_predict／n_probs／json_schema（すべて標準の機能） |
新しいプログラムは使っていません。llama.cpp に元からある機能だけで組んでいます。
問題
サーバのログを20件 用意し、それぞれ「緊急／様子見／無視」のどれかを当てさせました。正解は 緊急6・様子見6・無視8 です。速さの比較だけは6問で行いました。
比べた2つのやり方
| A 文章で答えさせる | B 選ばせるだけ | |
|---|---|---|
| 渡すもの | ログと問い＋「理由も添えて」 | ログと問い |
| 生成させる量 | 最大160トークン | 8トークン |
| 出せるもの | 制限なし | 選択肢の3語だけ（文法で縛る） |
確率の取り方（4通り）
| 取り方 | 中身 |
|---|---|
| 3択のまま読む | 1回だけ聞いて、上位N語の確率から選択肢を拾う |
| はい・いいえに割る | 「これは緊急か」を選択肢の数だけ聞き、はいの確率を正規化する |
| 温度を上げて数える | 温度0.8で8回引き、出た回数を確率とみなす |
| 公式と同じ定義 | 選択肢を1つに固定して書かせ、その文字列の出やすさを足して比べる |
測り方と、見る数字
1問につき5回。1回目は読み込みを含むので外し、残り4回の中央値を取りました。モデルを入れ替えるたびに、サーバへ問い合わせて実際に載っているモデルを毎回 確認しています。
| 見る数字 | 意味 |
|---|---|
| 正答 | 20問のうち当たった数 |
| 1問あたり | かかった時間の中央値 |
| 較正のズレ | 「言った確信度」と「実際の的中率」の差を帯ごとに重み付き平均。0に近いほど正直 |
実験結果〜速さは追いついた
速さは約20倍になった
| モデル | A 文章で答えさせる | B 選ばせるだけ | 差 |
|---|---|---|---|
| Gemma 4 E4B | 2,963.5 ms | 146.6 ms | 20.2倍 |
| Gemma 4 12B | 3,851.1 ms | 198.2 ms | 19.4倍 |
3秒待っていたものが0.15秒で返ってきます。Jev の公称は70〜500ミリ秒なので、速さという一点では同じ帯に入りました。
答えは6問すべてで一致した
| Gemma 4 E4B | 結果 |
|---|---|
| A 文章で答えさせる | 正答 3/6 |
| B 選ばせるだけ | 正答 3/6 |
| AとBの答えの一致 | 6/6 |
文章を書かせるのをやめても、モデルの判断そのものは変わりませんでした。変わったのは待ち時間だけです。ここまでは、狙いどおりでした。
ところが、確率が取れない
躓いたのはここからです。n_probs で上位N語の確率を返させたところ、こうなりました。
| トークン | 確率 |
|---|---|
| 緊急 | 0.4995 |
| ** | 0.2738 |
| [ | 0.1075 |
| 改行 | 0.0320 |
2位以下が書式の記号で埋まっています。そして「様子見」と「無視」は、上位400個まで広げても出てきませんでした。n_probs が返すのは語彙15万語の上位N個であって、選択肢の確率ではありません。
はい・いいえに割ると、確率が揃う
| やり方 | 確率が全部取れた問題 |
|---|---|
| 3択のまま（日本語） | 0/6 |
| 3択のまま（英語） | 2/6 |
| はい・いいえに割る | 6/6 |
「はい」も「いいえ」も1トークンなので、必ず上位に並びます。英語の選択肢にしても正答は 2/6 のままで、当たらない原因は日本語ではありませんでした。
70%を境に、上は当たり下は外れる
| 言った確信度 | 問数 | 実際に当たった率 |
|---|---|---|
| 90%以上（平均94.4%） | 4 | 100% |
| 80〜90%（平均84.1%） | 5 | 80% |
| 70〜80%（平均76.5%） | 5 | 80% |
| 50〜70%（平均56.2%） | 5 | 0% |
| 50%未満（平均50.0%） | 1 | 0% |
Gemma 4 E4B の結果です。70%を境に、上は14問中12問が当たり、下は6問すべて外れます。数字そのものの精度はともかく、「ここから下は人が見る」という切り分けには使えました。
実験結果〜ところが、モデルで全部ひっくり返る
ここまでは1つのモデルの話です。手元にある他のモデルでも同じことが起きるのかを見たところ、前提が崩れました。
Gemma を下から上まで並べる
| モデル | 容量 | 正答 | 1問あたり | 確信度で「自動／人手」を分けられるか |
|---|---|---|---|---|
| Gemma 4 E2B | 2.7GB | 11/20 | 220.6 ms | 使える（80〜90%と言って83.3%当たる） |
| Gemma 4 E4B | 4.3GB | 12/20 | 337.0 ms | 使える（90%以上→的中100%） |
| Gemma 4 12B（QAT） | 6.5GB | 9/20 | 468.7 ms | 使えない（低いほうに固まる） |
| Gemma 4 12B（非QAT） | 6.8GB | 10/20 | 469.8 ms | 使えない |
| Gemma 4 26B-A4B | 14GB | 12/20 | 415.2 ms | 使えない（20問すべて50%未満） |
26B は E4B と同じ 12/20 でした。容量は3倍以上あります。12B は谷になっていて、量子化の作り方を変えても（QAT／非QAT）変わりませんでした。
他社のモデルも並べる
| モデル | 容量 | 正答 | 1問あたり |
|---|---|---|---|
| MiniCPM5 2B | 1.5GB | 11/20 | 95.6 ms |
| Spark-X2.5 4B | 2.5GB | 12/20 | 212.4 ms |
| Ornith-1.5 9B | 5.4GB | 17/20 | 404.5 ms |
Ornith-1.5 9B が 17/20 で、測った中でいちばん当たりました。MiniCPM5 2B は96ミリ秒と最速でしたが、20問すべてで確信度が50%を下回るため、どこで切っても自動と人手に分かれません。
正常なログを「無視してよい」と言えるか
| 正解が「無視」の8問 | 当たった数 |
|---|---|
| Gemma 4 E4B | 1/8 |
| Ornith-1.5 9B | 6/8 |
Gemma 4 E4B は、バックアップの正常終了も、全ノードが24時間 健康だったことも、証明書の更新成功も「様子見」に格上げしました。同じ問い・同じ聞き方で、Ornith とここまで開きます。
確率の取り方を変えると、何が動くか
| 取り方 | 正答 | 較正のズレ | 1問あたり |
|---|---|---|---|
| ① はい・いいえを1回ずつ | 17/20 | 0.241 | 409 ms |
| ② 問いの言い方を2通りにして平均 | 18/20 | 0.519（悪化） | 792 ms |
| ③ 温度0.8で8回引いて数える | 15/20 | 0.138（最良） | 1,194 ms |
| ④ 公式と同じ定義 | 14/20 | 0.140 | 442 ms |
Ornith-1.5 9B での結果です。正答がいちばん高い①と、確率がいちばん正直な③④が、別々の場所にあります。
④は公式と同じ定義で確率を出したものです。当たり方の中身が①とは違いました。
| 正解 | Ornith-1.5 9B | Gemma 4 E4B |
|---|---|---|
| 緊急 | 6/6 | 6/6 |
| 様子見 | 0/6 | 3/6 |
| 無視 | 8/8 | 5/8 |
| 合計 | 14/20 | 14/20 |
2機種とも「緊急」を6問すべて当てています。崩れ方のほうはモデルによって違い、Ornith は「様子見」を6問とも「緊急」に倒しました。
どこで切ると、何件が自動で回せるか
| 切る値 | 自動に回る | 自動分の精度 | 人に回る |
|---|---|---|---|
| 0.5 | 17件 | 88% | 3件 |
| 0.6 | 10件 | 100% | 10件 |
| 0.7 | 4件 | 100% | 16件 |
| 0.8 | 0件 | — | 20件 |
Ornith-1.5 9B の20問です。確信度0.6で切ると、半分が自動処理に回り、その10件は全部当たっていました。残りの半分は人が見ます。
選択肢を増やすと、時間は比例して増える
| 選択肢 | 1問あたり | 3択を1としたとき |
|---|---|---|
| 3択 | 402.5 ms | 1.0 |
| 5択 | 640.7 ms | 1.6 |
| 8択 | 998.1 ms | 2.5 |
当たり方は10問中9問のままで、増やしても落ちませんでした。増えたのは時間だけです。
型を宣言すると、一度に複数の判定が返る
| 時間 | 結果 | |
|---|---|---|
| 型を宣言して4問を一度に | 762.8 ms | 5回とも型が崩れず、答えも同一 |
| 型を宣言せず文章で同じ4問 | 5,497.9 ms | 見出しだけ出して答えを書かない |
json_schema を使った結果です。1問あたり約190ミリ秒です。
考察〜詰まるのは速さではなくモデル選び
3秒の中身は「書いている時間」だった
答えが6問すべて一致したまま20倍 速くなったということは、あの待ち時間の大半は考えている時間ではなく、文章に起こしている時間だったということです。読む相手が人でなくプログラムなら、その時間は丸ごと要りません。
もし本当に考えている時間なら、生成を止めた分だけ答えが雑になるはずです。そうならなかったので、この読み方で合っていると思います。待ち時間そのものについては、最初の出力までにどれくらいかかるかを測った記事でも追いました。
確信度が使えるかどうかは、モデルの作りで決まる
今回いちばん驚いたのがここです。Gemma を並べると、確信度で自動と人手を分けられたのは、E2B と E4B だけでした。12B と 26B は確信度が低いほうに固まってしまい、どこで切っても両者が分かれません。
E2B と E4B は、他と作りが違います。公式の説明では E は effective、つまり実効の意味で、層ごとに小さな表を持たせて、使うときだけ引く構造だと書かれています。
PLE gives each decoder layer its own small embedding for every token. These embedding tables are large but are only used for quick lookups, which is why the effective parameter count is much smaller than the total.
E2B は実効2.3B（総量5.1B）、E4B は実効4.5B（総量8B）です。この作りの2つだけが、確信度を帯ごとに分けて返しました。ただし、これは5機種を1回ずつ測った並びから見えたことで、作りとの因果を確かめたわけではありません。
大きくしても当たるようにはならない
Gemma の中では 26B（14GB）と E4B（4.3GB）が同点でした。12B はむしろ E2B より下です。容量を3倍にしても、この仕事では返ってきません。
12B が弱いのは量子化の作り方ではありませんでした。QAT版が9/20、非QAT版が10/20で、どちらも同じ水準です。
そして測った中で最良は9BのOrnith（17/20）でした。大きさの順に並べても、当たる順にはなりません。選ぶなら、大きさではなく、実際に測った数字で選ぶしかありません。モデルの選び方そのものは、十数個を動かして5つの軸にまとめた記事で扱っています。
「正常を正常と言えない」はモデルの癖
Gemma 4 E4B は正常なログ8問のうち7問を格上げしました。アラートを減らしたくて入れても、減りません。危険を見逃す方向ではなく安全側に倒れる偏りなので実害は小さいかもしれませんが、「静かにする」目的には使えません。
ただし Ornith は 6/8 でした。生成AI一般の話ではなく、モデルごとの癖です。導入するなら、自分の使うモデルで確かめる必要があります。
正答と、確率の正直さは、別々に動く
取り方を変えると、正答と較正が逆を向きました。言い方を2通りにすると当たる数は増えますが確率は不正直になり、温度を上げて数えると確率は正直ですが当たる数が落ちます。
温度を上げて数えたほうが正直になるのは、筋が通っています。読み取った確率は「当てる確率」として学習されたものではありませんが、実際に8回引いて出た回数は現実そのものだからです。
この2つが同じものなら、逆を向くことはありません。「当たる道具」と「正直な道具」は、別々に選ぶものだと考えたほうがよさそうです。
公式と、いちばん開くところ
選択肢の数に比例して遅くなるのが、手元のやり方の弱点です。3択で402ミリ秒、8択で998ミリ秒。この調子だと255択は30秒を超える計算です。
公式には、選択肢は255まで扱えることと、問いは一度にまとめて評価することが書かれています。数個で済む仕分けなら追いつけますが、数十択・数百択の土俵では勝負になりません。
日本語で組むときの注意
| 選択肢 | トークン数 | 1トークンで止めると |
|---|---|---|
| 緊急 | 2 | 出る |
| 無視 | 2 | 出る |
| 様子見 | 3 | 「様」で切れる |
英語の解説には「1トークンで止めろ」と書かれています。英語の選択肢が1トークンに収まるからです。日本語でそのまま真似すると、長い選択肢だけが途中で切れて消えます。いちばん長い選択肢が何トークンになるかを、先に数えておく必要があります。
この測定で言えないこと
- 速くなっても、当たるようにはなりません。この方式は待ち時間を削るもので、賢くする方法ではありません
- 問題は当方が作った20問です。現場のログではありません。正解も当方が決めたもので、人によって判断が割れる問いが混じっている可能性があります
- 各モデル1回ずつの測定です。測り直せば順位が入れ替わる幅があります
- 確信度の帯によっては4〜6問しかありません。的中率の精度を語れる量ではありません
- 公式と同じ定義での測定は2機種です。「緊急が6/6」は両方で揃いましたが、2つで揃ったというだけです
- 255択は実際には試しておらず、3択から8択までの伸び方から計算しただけです
- 12B の文章生成の正答は測れませんでした。前置きが長く、160トークンの中に答えが出てこなかったためです
- Jev そのものは動かしていません。重みは公開されておらず、手元には置けません。比べたのは公称値とだけです
- Jev と同じ考えの実装がいくつか公開されていますが、当方は動かしていません。llama.cpp の標準の機能だけで組みました
今後の展望〜確信度のズレは、後から直せるか
| 次に確かめたいこと | なぜ |
|---|---|
| 確信度を後から補正できるか | Ornith は控えめすぎて0.8以上が1件も出ません。ズレの形が分かれば、後処理で直せる見込みがあります |
| 問題を100問に増やす | いまは帯ごとに4〜6問しかなく、的中率の数字が粗いためです |
| Eシリーズの作りとの関係 | 確信度が使えたのが E2B と E4B だけでした。他社の同じ作りのモデルでも起きるのかを見たいです |
| 並列に投げたときの速さ | llama.cpp は複数の枠を持っています。まとめて投げれば、選択肢が増えても耐えられるかもしれません |
| 実際のログで試す | いまの20問は当方が作ったものです。現場のログは、もっと判断が割れるはずです |
まとめ〜速さは追いつけた。選ぶべきはモデルだった
選ばせるだけにすると、手元のGPUで約20倍 速くなりました。2,963ミリ秒が146ミリ秒です。しかも答えは6問すべてで同じでした。あの待ち時間の大半は、文章に起こしている時間だったということです。
確率も、問いを「はい・いいえ」に割れば取れました。70%を境に、上は14問中12問が当たり、下は6問すべて外れます。確信度0.6で切れば、20問のうち10問が自動処理に回り、その10件は全部当たっていました。
ところが、どのモデルを選ぶかで結果はまるで変わりました。いちばん大きい26B（14GB）は、E4B（4.3GB）と同じ12/20。測った中で最良は9BのOrnithで17/20でした。確信度で自動と人手を分けられたのは、E2B と E4B の2つだけです。
つまりこの方式で詰まるのは、速さでも仕組みでもなく、モデル選びでした。大きさの順に並べても当たる順にはならないので、自分の仕事で測るしかありません。そして選択肢が数十を超えると、選択肢1つにつき1回 聞くこの組み方は分が悪くなります。
新しい道具は要りません。すでに llama.cpp を動かしているなら、引数を足すだけで試せます。まず自分のログ20件で、確信度と的中率を並べてみることをお勧めします。どこで切れるかは、モデルと仕事の組み合わせで変わるからです。
[kimono_kw name="GeForce RTX 5060 Ti 16GB" kw="RTX 5060 Ti 16GB"]