既存の LLM が CPU なら、 Jev はその GPU 版みたいなやつ
Jev を一晩叩いたので、その感想を書きます。タイトルは超大雑把な要約です。
実験結果
まず実験ログを置いておきます。
- 公式のクックブックの条件を変えた追試
- チェス対戦
- 5戦やって、Claude 5 Sonnet には全勝
- LoL をミニマルにしたような MOBA ゲームをリアルタイム操作
- スプリットプッシュのマクロ戦術やタワーダイブのようなミクロ戦術が観察されました
- 集団戦で、誰がタンクするかの判断で協調できないことがありました(人間もやります....)
- eslint のエミュレーション
- 実装抜きにルール名とコードだけで Lint の結果を答えさせて、正答率 86%
- 自然言語による確率的な Lint ルールというのが、比較的現実的です
- Playwirght によるブラウザ自動操作
- 簡単なフォームを作り、商品をカートに入れ、購入する、という一連の画面操作をやらせる
- 判断自体は高速ですが、単独ではエラーから復旧できないのが観測されました。Claude にログを監視させ、補助させることで 96% 以上の精度になりました
わかったこと
- 本当に安い
- MOBA風のゲームを 1戦やらせて、 $0.0001
- 出力無料
- モデルとしての性能自体がすごく高いというわけではない
- 1リクエスト/レスポンスは 500ms ぐらい
- 真価は並列度。256個の質問を同時に投げて、同時にそのスコアが得られる
- confidence 値が便利
- 0.96 以上のときはほぼ確信している
- 0.4 以下は間違ってる可能性が高い
- つまり、0.4 以下だと別のモデルにフォールバックするといい
Claude による詳細レポート
Claude にまとめさせた、 実際に使うときにどう設計するかの
で、Jev は結局何なのの話をします。
Jev の前提: Tool Call の話
Tool Call がなかった時代、エージェントを作るときに我々は「あなたの回答は与えられた jsonschema を満たす, json として、markdown 内の json コードブロックの形で出力してください」という指示を与えていました。
これを一般化したのが LLM によるツール呼び出しであるところの、 Tool Call や MCP です。これにより AI は外界と接続できるようになり、それを IDE と接続したのが Cline や Claude Code のようなコーディングエージェントです。
この能力は、LLM の世界知識というよりは Tool Call のための専用の事後トレーニングを行うことで得られる能力です。jsonschema の解釈能力、それを満たす範囲で自分がやりたいことを json の構造で表現する能力、その呼び出し結果が、自分の意図に沿ったものかを確認する能力が必要になります。
Jev が達成したこと
Jev がやったのは、「自然言語の延長で JSON を出力しなくても、自然言語の生成を介さず、最初からJSONのような構造を出力するように作っておけばいいじゃん」というものです。
モデルの詳細は明らかにされていませんが、文章を解釈する能力は既存のLLMと同じものを使っていて、それを出力する部分(デコーディング層)を構造化データにしています。そのニュアンスで TypeSafe AI を名乗っているのでしょう。
Jev の実際の性能
ここから自分の実測と予想を含みます。
「既存の250倍以上高速」の正体
おそらくこれは Choice が 256 まで同時に Choice を投げられることを意味しています。この用途なら、仕組み的に逐次処理のリクエストに比べて250倍速いとうのは嘘ではないですが、有利な面で勝負しすぎな気がします。
256の選択肢、多いように見えますが、これは 19x19 = 361 の囲碁の盤面は、ある程度枝刈りしないと投げられないことを意味します。設計時に選択肢を絞ることが大事になります。
「400倍以上安い」
深い推論に向いてない、既存と同じユースケースに乗らない、という前提はありつつも、これはある程度本当。
特に出力が無料なのが嬉しいですね。
「ハルシネーションが起きない」
事前に用意したものに対してスコアを付ける形式なので、用意してない選択肢が選ばれることはありません。
ただし、人間が用意した間違った選択肢に高いスコアをつけることはあります。
自分の手元で Playwright のブラウザ自動操作の実験をしたところ、押せないボタンを押し続けました。ハーネスにしていた Claude がそれに気づいて、選択肢自体を削除することで処理を続行することができました。
試しにチェスをプレイさせたところ、ルールに合法手のみを渡したのでそれに制約されます。比較として、Sonnet は一局あたり2回ほどルール違反の手を選ぼうとしました。
「速い」ただし地理的な限界も見える
今の手元の実測だと、1リクエストあたり 500~600ms で、一番遅いときは 1200ms ぐらいかかります。
仮に 500ms と仮定すると、およそ 2fps の判断ができます。60FPSのアクションゲームをプレイさせるには足りないですが、RPGやシミュレーションなら現実的です。Embeddingでない限り、自動運転は厳しいでしょうね。
途中で気づいたのですが、Claude Code Web から試したところ、およそ 350ms ぐらいでレスポンスが返ってくることがわかりました。これはアメリカ西海岸同士で通信してるからだと思われます。
日本から通信することで 120ms ぐらいの遅延が乗っています。これは日本リージョンが出来るまで解決できない遅延です。
Jev の何がゲームチェンジャーか
これは今あるLLMを置き換えるものではありません。どちらかというと補助するものです。
わかりやすい適用例は、危険なコマンドを止めるガードレールの用途でしょう。シェル実行前にYES/NO を判断させる部分を、安価に高速にできます。ある意味、偽陽性の許される Bloomfilter のように扱うのがコスパがいいと思われます。
デモを見ると、大量の skills から適切な skill を選ぶ、ということもできそうです。サンプルでは Hermes Agent は 186個のツールを持っていますが、どれを使うといいかをバッチ一つでスコアリングして、高いものを選ぶ、ということができます。
深い解釈は苦手というか、そういう風に作られていません。事前条件の State に自身の実行ログを追加することで擬似的なReasoning みたいなことはできなくはありませんでした。
が、現時点では最適化されておらず、これによって判断が変わる、ということはあんまりなかったです。
これはオーダーが変わることによる質的な変化です。
ストレージが安価に、回線品質が良くなってYouTubeが普及したように、Web API で許容されるレベルの 500ms のバジェットで、同時に 256個の判断ができるようになったわけですね。
Jev で何ができるようになるか？
まだよくわかりません。既存の発想で考えてると、足をすくわれる気がします。
とりあえず、この条件で考えてください。
- 500msの1リクエストで256個のLLMの回答を得ることができる
- LLMをチャットアシスタントではなく、リアルタイムな計算機として使うことができるようになった
こういうものは今まで存在したことなく、新しい発想が必要になるものです。500ms の遅延は、違和感はありつつも人間とのリアルタイムの対話に使えるレベルです。
公式のロードマップにはありますが、まだ画像入力とすることができません。仮に動画ストリーミングをリアルタイムで処理できるようになると、そこで世界が一つ変わる気はします。
Jev で何が変わるか
おそらく Jev はプログラマ、またはプログラマのようにワークフローを考えられる人にとって大きな意味があります。
今までのLLMを使ったプログラミングは自然言語で投げた回答を、自然言語として無理矢理運用していました。
Jev は最初から構造化して考える必要があるので、プログラミングとの親和性が高いです。
- 事前条件の設計
- 出力構造の設計
- その並列化の設計(New)
...まあ今までと一緒ですが、これを設計する重みが増していきます。「500ms, で 256 並列できる」、これについて深く考える必要があります。
例えるなら、今までの LLM を CPU だとして、 Jev は精度が落ちるが遥かに高速な GPU みたいなものです。
また、仕組みが簡単なので、おそらく大手プレーヤーはすぐに模倣してくるでしょう。今の TypeSafe AI の最適化がどのぐらいものなのかは現時点で予測できませんが、おそらく OpenAI/Anthropic でも、2か月後には似たようなものがローンチされていると思います。
Embedding モデルに使えるか、というと、よくわかりません。
アーキテクチャ的には、Embedding Model に向いてるんですが、たとえば自動運転なんかでは自然言語を介さずもっと決め打ちで最適化されたものを使いますし、LLM の学習された重みを使うわけで、デコーディング層のサイズは小さくなるとしても、どれぐらい小型化できるかはちょっと予想できないです。これはここからの調査を待ちたいところです。
新しいおもちゃなので、こき使っていきたいですね。
Discussion
confidence 0.4 以下でフォールバックする設計、ガードレール用途に効きそうですね。しきい値の使い分けが鍵になりそうです。
JevをCPU/GPUの比喩で整理した説明と検証内容を、下記の記事で出典リンク付きで紹介しました。参考になる実験の共有をありがとうございます。