TypeSafeのJevを正しく驚く、それってLLMでできませんか？
Jevとは？
TypeSafe AIの「Jev」は、文章を生成する代わりに、ソフトウェアがそのまま使える判断と確率を高速に返すモデルです。
詳しい説明に関しては公式サイトに譲ります
これをみて正直なところ「それは既存のLLMでもできるのでは？」と思ってしまいました。
JSON出力
まず注目したのはこのデモです。
LLMでJSON出力するのに比べてJevを使って並列に推論することで大幅に高速化したとのことです。
LLMで再現するには？
LLMでJSONを出力させる場合、通常は{やキー名、値、カンマ、}までを1トークンずつ自己回帰的に生成していきます。
しかし、今回のように出力候補があらかじめ決まっている場合、必ずしもJSON全体を生成させる必要はありません。
例えば、
true
false
のように回答候補を単一トークンに対応させ、回答位置におけるtrueとfalseのlogitだけを見れば、その質問に対するモデルの判断を1回のforward passで取り出せます。
選択肢が複数ある場合も同様で、
A: approve
B: reject
C: escalate
のように候補を短いIDに割り当て、最初の1トークンのlogitを比較すればよいわけです。最終的なJSONはモデルに文字列として生成させず、得られた結果をコード側で組み立てます。
また、複数の独立した質問がある場合は、それぞれを別の入力としてまとめてbatch推論できます。共通部分の長いプロンプトについてはKV Cacheを再利用することで、毎回同じprefixを最初から計算する必要もありません。
つまり、
共通コンテキスト
↓
KV Cache
↙ ↓ ↘
Q1 Q2 Q3
↓ ↓ ↓
logit logit logit
↘ ↓ ↙
コード側でJSON化
という構成にできます。
この方法であれば、JSONを最後まで自己回帰生成する場合と比べて、出力トークン数に比例する待ち時間を大きく減らせます。
検証
これを利用してGemma3 270Mを使ってこの並列推論する方式とJSON出力とを比較しました。
プロンプトについては先ほどのデモと出力が同じになるようにこちらで適当に推定したものを使用しました。
その結果がこちらです。
これによりJSON出力と比較して、77倍の高速化することができました。
LLMとの比較をするとすればこのやり方と比較しないとフェアとはいえないでしょう。
ゲームのプレイ
DOOM
次に注目したのが、JevでリアルタイムにDOOMをプレイするデモです。
ここで重要なのは、100ms前後の短い時間で判断を返せるため、リアルタイム制御に使えるという点です。
ただしJevは画像入力には対応していないため、ゲーム状態を構造化データに変換するハーネスを介して操作していると考えられます。
マリオで検証
同様に、これは第三者による検証かと思いますがJevでマリオをプレイするデモとハーネスもありました。こちらはハーネスが公開されていたのでこれを用いてJevとOpenRouter経由で複数のLLMを使って結果を比較してみました。
まず自分の環境で動かしたJevは、公開デモほどはうまくプレイできませんでした。
公開デモと比べると、自分の環境ではおよそ3倍程度のレイテンシがありました。そのため、このレイテンシ差がプレイ結果にも影響している可能性があります。
一方で、同じ環境でのLLMとの比較ではJevが最も良い結果になりました。
とはいえLlama、Gemmaもかなり近いスコアとなりました。
| モデル | 平均応答 | 到達地点 |
|---|---|---|
| TypeSafe Jev | 276ms | 1,226 |
| Llama 3.1 8B | 356ms | 1,138 |
| Gemma 4 26B A4B | 572ms | 1,127 |
| Qwen3 235B A22B Instruct 2507 | 593ms | 686 |
| Gemini 2.5 Flash-Lite | 719ms | 296 |
また今回比較できたLLMには制約があります。
前章で使った「最初の1トークンのlogitを見る」という方法には、APIからlogitやlogprobsを取得できるモデルが必要です。現在の高性能モデルの多くは推論モデルですが、こうしたモデルではAPIから必要なlogitを取得できないことが多いため、今回の比較では主に旧世代の非推論モデルを使用しました。
そのため、今回の結果だけで「Jevは最新のLLMより優れている」と言い切ることはできません。
Jevの強みとは？
ここまでの検証から、Jevの特徴を単純に「既存LLMではできないことを実現した」と捉えるのは少し違うように思います。
とはいえこのような確率を出力するインターフェイスをAPIとして提供したというのは実用的な価値があるとはいえるでしょう。
またレイテンシについても、最新の高速な非推論モデルは100ms前後の領域に入りつつあります。
例えばDeepSeek V4 Flashでは、NVIDIA B300 1基でTTFTが約90msという測定結果があります。
LLMそのものの推論コストとレイテンシも急速に改善していますし、おそらくOpenAI、Anthropicが同様のインターフェースで単純にLLMのAPIを提供すれば、近しいことはできてしまいます。
そのため、この専用化による優位性が今後どれだけ大きな価値を持つのかについては、まだ分からないというのが現時点での感想です。
追記1
自分が見落としていた点についてご指摘いただいたのでそのコメントを引用する形で追記させていただきます。
開発元によると、既存LLMではプロンプト内の選択肢の順序バイアス（Position Bias）、トークナイザの切り出し方、モデルの過信（Overconfidence）などの影響を強く受け、現実世界の確実性と一致する「正しい確率（Calibrated Probability）」にはなっていないとのことです。
それに対しJevでは、単に数値を出すことではなく、その数値が確率論的・統計的に適切に校正（Calibration）された信頼できる推定量であることというのが大きなメリットであると開発元は主張しています。
この点について「正しい確率」が必要となる用途や、そもそもLLMに簡単なキャリブレーションを追加した時との比較などについては今後の課題とさせてください。
追記2
Jevの「正しい確率（Calibrated Probability）」について検証した記事をコメントにてご共有いただきました。 やはりこれを見る限り、Jevの出力する確率を現実世界に即する確率であるという前提でプロダクトに組み込むことには慎重になるべきだと思いました。
Discussion
技術的に興味深い記事を描いていただきましてありがとうございます。
たた、開発元によると、既存LLMではプロンプト内の選択肢の順序バイアス（Position Bias）、トークナイザの切り出し方、モデルの過信（Overconfidence）などの影響を強く受け、現実世界の確実性と一致する「正しい確率（Calibrated Probability）」にはなっていないとのことです。
それに対しJevでは、単に数値を出すことではなく、その数値が確率論的・統計的に適切に校正（Calibration）された信頼できる推定量であることというのが大きなメリットであると開発元は主張しています。
そのあたりの主張も書いていただけましたら、より良い記事になると思います。
重要なご指摘ありがとうございます。
コメントを引用する形で追記させていただきました。
もし問題がありましたら削除させていただきますのでコメントください。
ロジット抽出だけでは順序バイアスや過信は残るため、校正の主張はECEなど誤差指標で検証すると説得力が増しそうです。
記事を拝見しました。コメント欄で「Jevの確率は較正されている」という点が話題になっていたので、関連する実験の結果を共有します。
Jevの較正が崩れるケースです。結果を伏せたサイコロの出目をChoiceで聞くと、400件すべてで「1」を選び、報告確率は平均83%でした(本来は1/6)。一方、Noulで「出目は1か」と聞いた場合は平均19%で、1/6に近い値になります。
詳細とコード、データを公開しました。 記事の中で、こちらの記事を引用させていただきました。
ご共有ありがとうございます。
大変興味深い検証でした。
追記にて紹介させていただきました。