TypeSafe JevとLLMの77倍高速化比較で見えた構造的課題

• TypeSafe AIが文章生成を排除し、ソフトウェア向けの判断と確率を高速返却する新モデル「Jev」を公開した。
• KV Cache再利用と1stトークンLogit抽出により、Gemma3 270MでもJSON出力を77倍高速化可能と判明した。
• 単純な推論速度だけでなく、選択肢順序バイアスを排除した「確率校正（Calibration）」の精度が採用基準となる。

深夜の障害対応で、LLMが吐き出すJSONフォーマット崩れに頭を抱えた経験はエンジニアなら一度や二度ではないだろう。閉じ括弧が抜けただけで後続のパイプラインがデッドロックに陥り、パーサーが構文エラーを吐き出す。そもそも、あらかじめ「approve」「reject」「escalate」の三択しかないビジネスロジックの判定に対して、なぜ我々は「{ “decision”: “approve” }」という冗長な文字列を1トークンずつ自己回帰的に生成させ、無駄なレイテンシとGPUリソースを消費し続けているのか。TypeSafe AIが発表した「Jev」は、テキスト生成を潔く切り捨て、ソフトウェアがそのまま消費できる判断と確率をミリ秒単位で返すモデルとして登場した。しかし、技術コミュニティに身を置く私のような天邪鬼なエンジニアなら、まずこう疑うはずだ。「それ、既存のオープンモデルでも工夫次第でできるのではないか？」と。

結論から言えば、アーキテクチャの工夫次第で既存LLMでも圧倒的な速度向上が可能だ。LLMに律儀にJSON全文を出力させるから遅いのであって、分類問題であれば回答位置に現れる最初の1トークンのLogit（未正規化の対数確率）を取り出し、コード側でJSONを組み立てれば済む話である。さらに共通のプロンプト（コンテキスト）部分はKV Cacheを再利用し、複数の質問をバッチとして束ねて1回のforward passに流し込む。検証として「Gemma3 270M」を用い、この並列Logit抽出パイプラインを組んだところ、愚直にJSONを文字列生成させた場合と比較して実に77倍もの高速化を叩き出した。入力コンテキストをKV Cacheに固定し、分岐する判定を1回の計算で回収するこの構成は、推論コストを最小化する極めて現実的なプラクティスである。Jevの高速性を単なる「JSON出力の短縮」という表層だけで捉えるなら、我々はすでに手元にある軽量オープンモデルの組み合わせで十分に戦えてしまう。

Jevのもう一つのショーケースが、リアルタイムにDOOMやスーパーマリオをプレイするという制御デモだ。ゲームの状態を構造化データに変換するハーネスを介し、100ms前後のレイテンシで次の一手をモデルに判断させる。フレームが落ちれば即座にゲームオーバーとなる過酷な環境において、この応答速度は極めて刺激的に映る。だが、実際に公開ハーネスを用いて同一環境下で検証を試みると、リアルな現実が浮かび上がってきた。測定環境のネットワークやホスト要因によりレイテンシがデモ時の約3倍に膨らむと、Jevであってもマリオのプレイ精度は目に見えて劣化する。リアルタイム制御の命綱は、アルゴリズムの優秀さ以前に「確実な低レイテンシの担保」にあるという当たり前の事実を痛感させられる。

さらに深い問題は、この土俵で既存LLMと比較検証しようとした際に直面する「現代LLM APIのブラックボックス化」という壁だ。前述した「最初の1トークンのLogitを抽出するハック」を成立させるには、プロバイダ側がAPI経由でLogitやlogprobsを完全な形で露出していなければならない。しかし、OpenAIのo1やo3といった近年の推論モデル（Thinking Models）や、各社が性能を競い合う最新プロプライエタリモデルの多くは、推論プロセスを隠蔽しLogit取得インターフェースを塞ぎつつある。結果として、客観的な比較実験に持ち出せるのは旧世代の非推論モデルに限定されてしまう。一方でオープンモデル陣営に目を向ければ、例えばDeepSeek V4 FlashのようにNVIDIA B300単体でTTFT（Time To First Token）が約90msに達するモンスターモデルが台頭している。インフラさえ自前で用意できるなら、既存LLMでも100msの壁は突破可能な射程に入りつつあるのだ。

では、Jevのような判断特化型モデルの存在意義はどこにあるのか。単なる「Logit抽出と並列化のラッパー」に過ぎないのかといえば、話はそう単純ではない。開発元とのディスカッションでも浮き彫りになった決定的な論点は、出力される数値が「統計的に校正された信頼できる確率（Calibrated Probability）」であるかどうかという点だ。既存のLLMに単一トークンを判定させた場合、そこから得られるLogitは一見すると確信度のように見える。しかし実態は、プロンプト内での選択肢の並び順に引きずられる「Position Bias（順序バイアス）」や、トークナイザの切り出し粒度による歪み、そして自己回帰モデル特有の「Overconfidence（過信）」に激しく冒されている。数値として0.9と出たからといって、現実世界で90%の確率で正しいとは到底言えないのが既存LLMの宿痾である。

もしJevが、ECE（Expected Calibration Error：期待校正誤差）を徹底的に抑え込み、モデルが「80%の確信度」と判定した事象が統計的に正確に80%の確率で的中するようチューニングされているのだとすれば、その価値は跳ね上がる。金融の与信判断や医療トリアージ、自律型エージェントのクリティカルな分岐において、エンジニアが喉から手が出るほど欲しいのは「流暢な言い訳」ではなく「数学的に信用できる推定量」だからだ。だが、この問いを開発元だけに投げかけて終わるわけにはいかない。我々実務家は明日から、自前でLogitを叩いて77倍の速度を得るハックを試しつつ、その背後にある順序バイアスを自前の較正層で補正するアーキテクチャを組むべきか、それともJevのような特化型APIに賭けるべきか。テキスト生成の熱狂が一段落した今、システムの本質的な信頼性をどのレイヤーで担保するのかという、極めて泥臭いアーキテクチャ設計の覚悟が問われている。