メインコンテンツへスキップ
見出し画像

【徹底比較】Jevと類似OSS 8選 — なぜ1パスの意味的ifが爆速なのか？仕組み・精度・選び方を使って調べた所感です【OpenJev、Jevlike、SimpleJev、NanoJev、Cua、kev、modernbert、nimble】※追記：OpencodeでJev無料枠になっとる

    ゆいまる‐IT界隈以外でAIを使いまくる2005年生まれ

    9月18日時点で半分使ってて、
    19日に半分使って記事書いた感じです。

    nimbleに関してだけは情報のみ乗っけていますがまだお試し出来てません。

    1日校正している間に、更に増えてて乾いた笑いがでちゃう。

    個人的には日本の方がModernbertを元にしたツール作ってたので、むっちゃ気になってます。

    が、今は眼の前の情報を整理したいのです。

    ※追記です。OpencodeでJevが無料枠になっとる。

    LLMを業務システムやワークフローに組み込む際、誰もが一度は次のような悩みにぶつかったことがあるはず。

    • 「JSONフォーマットで出力して」と指示したのに、たまにパースエラーで落ちる

    • たった1つの真偽値（True/False）や分類結果が欲しいだけなのに、トークン生成完了まで数秒待たされる

    • 出力された「確信度（確率）」を信じて分岐させたら、堂々と大嘘をついていた

    実際、2026年現在のAIワークフローにおけるエラーの4割以上が「不正なモデル出力（パース失敗やスキーマ違反）」に起因すると言われています。


    そんな中、TypeSafe社が発表して大きな話題を呼んだのがJev。


    Jevはプロンプトを生成させるのではなく、「非構造な状態 ＋ 型定義された質問」を与えて、1パスで直接クラス分類の確率を返すというアプローチを取っています。


    いわば「自然言語で動く、型安全な意味的if文」。


    んで発表からわずか数日で数多くのOSS再現プロジェクトが登場。

    でも、「本家とOSSは何が違うのか？」「どれが実用レベルなのか？」は情報が錯綜中。

    探しに行くほどわからんくなる。

    なので、信用できる一次情報だけに絞ってリサーチして、比較して使って。そんな感じでお試ししてみましたー。

    本当はJevに特化したベンチマークとかも欲しいんですけども。なっかなかないので拾った数値と実測比べたくらい。実測しきれないのもいっぱいあるので、あくまでも素人の参考値程度に考えてくださいね。


    報告書は一番下にぎゅぎゅっとしたやつを入れておきます。
    ※投稿日にもう一回出し直しました。更新が多すぎる。

    画像

    というわけで。

    この記事では一次情報・論文・ベンチマークをもとに、Jevの仕組みと代表的なOSS 8選の性能・長所・短所を徹底的に比較・調査してみようかなーと思います。

    れでぃごー。

    1. そもそも「Jev」とは何か？ なぜ爆速なのか

    従来のLLM（生成型）との決定的な違い

    従来のLLMで分類を行う場合、プロンプトに対してトークンを1つずつ順番に予測（Auto-regressive Decode）し、文字列として `"true"` や `{"action": "submit"}` を出力させていました。

    一方、Jevおよびその追試OSSはテキスト生成のループ（Decode loop）を一切回しません。

    【従来のLLM】
入力 → Prefill → 1トークン目生成 → 2トークン目生成 → ... → JSON完成（遅い・壊れる）

【Jevアプローチ】
入力（状態＋質問＋選択肢） → Prefill（1回） → Readout Head（数値を直接読み出し） → 確率分布

    なぜ速く、壊れないのか？

    Jevのアーキテクチャ（リバースエンジニアリング論文等による推定）の核心は以下の3点にあります。

    1. Shared-state Prefix（KVキャッシュの共有）
      長いドキュメントや状態（State）を1回だけ事前計算（Prefill）し、KVキャッシュに保持。複数の質問が同じキャッシュを同時に参照します。

    2. Isolated Branches（並列分岐）
      質問や選択肢ごとの処理をブロック因果マスク（Block-Causal Mask）等で並列評価。質問同士が干渉しません。

    3. Readout（読み出しヘッド）
      最後の隠れ状態（Hidden State）から、選択肢ごとのLogitsを直接取得してSoftmaxを取るだけ。パースエラーが原理的に発生しません。

    これにより、従来のデコーダー比で数倍〜数十倍のレイテンシ削減と、100%スキーマ準拠を両立。

    2. Jev系OSS 8選のスペック・比較一覧

    現在公開されている主要なOSSは、大きく3系統に分かれます。

    「① 既存モデルのLogits直接読み取り型」
    「② 分類ヘッドを事後学習させた型」
    「③ 超小型・特化型」

    一応、画像で貼っておきますが、コピーして使う場合もあるかなーとも思うのでテキストも無理やり乗っけておきます。

    テキストは正直、人が見る部分では無いと思ってます。

    画像
    Nimbleも入れたけど、お試ししきってないのでテキストでは省いています。

    プロジェクト | ベースモデル・方式 | 特徴 / 代表精度（※条件付き） | 遅延の目安 | API互換 | 向いている環境 
    本家Jev(TypeSafe) | 疎MoE推定RLCD較正 | dev精度: 0.845OOD精度: 0.855 | 70〜500ms(API経由) | 本家 | クラウドAPI
    OpenJev SemIf(TheoLeeCJ) | Qwen3.5-4B凍結Direct Logits | 自作144件: 0.813WANLI: 0.637 | 21判定で1.02s(RTX 3090) | CLI / WebGPU | 開発・検証(学習不要)
    openjev NLI v2(AlexWortega) | Qwen3.5-4BNLI Cross-Encoder | MNLI: 0.904Doom: 11.0 kills | 57ms/判定(画像: 101ms) | 独自 | ゼロショット判定マルチモーダル
    Jevlike(vinnylarouge) | byte埋込 / 凍結Enc+ Scorer学習 | 合成: 98%Wiki: 26〜29% | Decoder比約100倍高速 | ライブラリ | CPU運用アルゴリズム学習
    SimpleJev(featherless-ai) | HuggingFace互換Logits読み取り | ベースモデル依存(RFDT訓練) | モデル依存 | `/v1/classifier` | 既存HFモデルのAPIサーバー化
    NanoJev(TianyuCodings) | Qwen3-0.6B+ Decision Heads | 迷路: 95%OOD: 90% | 複数問を1 forwardで一括判定 | 独自常駐デーモン | エッジ・軽量BotゲームAI
    Cua S1-Forms(cua-ai) | 706k params 特化型(Jevlike派生) | 自社フォーム: 99.7%(条件付き) | 7〜9ms(ローカル実行) | ドライバ統合 | 定型業務フォームCPU・組込み
    kev (0.5b/0.6b/4b)(jaredpalmer) | Qwen + LoRA r16+ Pointer Head | 4b dev: 0.8434b OOD: 0.759 | packed batchで2倍高速化 | 本家API完全互換 | 本家Jevの代替自前ホスティング
    ModernBERT系(ModernCE等) | ModernBERT-large(395M) NLI | MNLI: 0.909SNLI: 0.927 | 540 samples/s(超高スループット) | 各自 | 大量バッチ分類省コスト運用

    (※注: Nimble (Bespoke/9B) なども公開されていますが、わたしがお試しできてなくって。上記8つが現在実用・検証でよく話題に上る代表株。各精度数値は評価スイートが異なるため、横並びの単純比較には注意が必要)

    3. 各OSSの個別評価：長所と短所

    画像

    ① OpenJev (SemIf) — 学習不要で今すぐ試せる筆頭

    • 長所: 重みの追加学習が一切不要。Qwen3.5-4BのベースLogitsをそのまま読み出すため、スクリプト1つで即座に動きます。WebGPUやMLXによるMacローカル動作もサポート。

    • 短所: 較正（キャリブレーション）がされていないため、選択肢の順番を入れ替えると判定が反転する「Option Reversal」が起きやすい。

    • おすすめ: 「まず手元のGPUでJev的なアーキテクチャの速度感を試してみたい」とき。

    ② kev (0.5b / 0.6b / 4b) — Jev API完全互換＆最も誠実な検証

    • 長所: 本家Jevの `/v1/systemone` と同一のインターフェース。固定10,000件のマルチシードテストを実施しており、4bモデルの分布内精度は0.843と本家Jev（0.845）に肉薄。選択肢の並び替えによるフリップ率も0.00%と極めて堅牢。

    • 短所: 0.6b以下の小型モデルは未知データ（OOD）で精度60%前後の壁にぶつかる。また、日付計算などの合成推論では本家に劣る。

    • おすすめ: 「本家JevのAPI仕様のまま、社内GPUサーバーに切り替えたい」とき。

    画像

    ③ openjev NLI v2 — 画像入力・ゼロショット制御に強み

    • 長所: 自然言語推論（NLI）ベースでチューニングされており、画像入力（Doomのゲーム画面など）からダイレクトに行動を決定可能。

    • 短所: プロンプト（仮説文）の言い回しに精度が強く依存する（仮説の書き方次第でゲームのスコアが10倍以上変動する）。

    • おすすめ: エージェントのガードレール、リランキング、画像を含むマルチモーダル判定。

    ④ Cua S1-Forms — わずか2.8MB、7msで動く特化モデル

    • 長所: パラメータ数はわずか70万（約2.8MB）。CPU環境で7〜9msという超高速で動作。Webフォームの入力補助・スキップ判定に特化。

    • 短所: フォーム操作専用。新しい概念や自由記述の理解はできず、汎用性はゼロ。

    • おすすめ: RPAや定型ブラウザ操作をミリ秒単位でさばきたいとき。

    画像

    ⑤ ModernBERT系 (ModernCE) — コストパフォーマンス最強の枯れた技術

    • 長所: 395MクラスのEncoderモデルで、秒間540サンプルを処理可能。VRAMも2GB未満。

    • 短所: 生成モデルベースのような柔軟なコンテキスト読解や複雑な推論は苦手。

    • おすすめ: 大量のテキスト分類、コンテンツモデレーションをCPUや安価なGPUで大量処理したいとき。

    画像
    画像
    画像

    4. 運用前に知るべき「確率」の罠

    ここが現場導入における最大の注意点。

    Hacker News等のコミュニティでも強く指摘されていますが、OSS版のJevクローンは「型エラー（無効な出力）は出さないが、有効な顔をして間違った値を出す」傾向があります。

    ハルシネーションではないけど、間違った選択をしてしまうということです。すっごい大事な事。

    でも、人間すらも【全てを完璧に正しい選択】というものを知らない以上、ここを100％にすることもできない。果たして、現在間違いとされている選択が本当に間違っているのか、という話らしい。

    人から見ての正しい選択は、モデルから見て正しいのか。
    うーん、難しい。

    まぁ、正しい形が決まっている事務作業でも誤選択は産まれているので、そもそも正答を選び続けるのも出来ていないのも、また事実。

    大事なのは「どんな理由にせよ、誤りは生まれるという事実」です。

    Softmaxの確率は「正解の確信度」ではない

    OSSモデルが出力する確率は、単に「与えられた選択肢の中でどれが相対的に高かったか」を示すSoftmax値に過ぎません。

    本家JevはRLCD（Reinforcement Learning from AI/Constitutional Feedback on Decision）などの非公開手法で「確率0.8なら、本当に80%の確率で正解する」ように較正（キャリブレーション）されています。

    でも、大半のOSSは学習時にこの較正が施されていないため、「大嘘なのに確率0.99」を平気で出力（確信過剰）します。

    実運用に載せるための3大鉄則

    1. 選択肢に必ず「該当なし / 情報不足（insufficient）」を含める
      文脈に答えがない場合、モデルは無理やりどれかの選択肢に高い確率を割り振ってしまいます。

    2. 温度スケーリング（Temperature Scaling）を行う
      自社のテストデータを用いて出力温度 $T$ を調整し、BrierスコアやECE（Expected Calibration Error）を最小化する。

    3. 撹乱テスト（Permutation Test）を実施する
      選択肢の順番（A/B/C → C/B/A）を入れ替えても、同じ結果・確率が維持されるか必ず検証する。

    5. 【目的別】結局どれを選べばいいのか？

    採用基準をフローチャート形式でまとめました。

    画像
    Q1. インフラの制約は？
 ├─ CPUのみ / 超低スペック → 【Cua S1】(定型フォーム用) または 【ModernBERT系】(汎用分類)
 ├─ Macローカル (Apple Silicon) → 【kev-0.5b (MPS)】 または 【SemIf (MLX)】
 └─ GPUあり (RTX 3090 / A100 / H100等) → Q2へ

Q2. 最優先事項は？
 ├─ 「学習なしで今すぐ動かしたい」 → 【OpenJev SemIf】
 ├─ 「本家JevのAPIと差し替えてセルフホストしたい」 → 【kev-4b】
 ├─ 「多少重くてもオープンな最高精度がほしい」 → 【Nimble (9B)】
 ├─ 「画像入力やゲーム・強化学習的な制御をしたい」 → 【openjev NLI v2】
 └─ 「手持ちのファインチューニング済みHFモデルを使いたい」 → 【SimpleJev】

    わたしのPCで実測した数値なども報告書にまとめています。

    miniPCなので正直参考になりきるのかはわかんないですけど、取り敢えず乗っけておこうかなーと思いまして。
    要らなかったらスルーして下さい。以下はその一部です。
    nimbleに関しては一次情報から引っこ抜いてます。

    画像
    画像

    周辺エコシステムと時系列

    画像で貼っておきます。こんな感じ。

    画像
    画像

    6. まとめ：モデルは「生成する時代」から「1パスで分岐する時代」へ

    うーん、むっちゃ使っていくのは楽しかったです。

    Jevが登場した本質的な価値は、モデルを推論エンジンではなく、安全で爆速なルーティング装置（意味的if文）として再定義したこと。

    • すべての処理を重いデコードループで回す必要はない。

    • ドキュメントのルーティング、ガードレール、フォームの入力判定などは事前計算KVキャッシュ ＋ 1パス判定で十分＆その方が圧倒的に堅牢。

    何かに導入する際は、まずは学習不要の SemIf やAPI互換の kev でプロトタイプを作り、必ず自前データでのキャリブレーション（較正）を挟んだ上で、信頼性の高いワークフローを構築してみてくださいねー。

    良ければスキ、待ってますーっ

    出典・ライセンス注意

    TypeSafe公式launch・Apidog代替品総括・TheoLeeCJ/SemIf（RESULTS/METHOD/REPRODUCE 09-18版）・AlexWortega/openjevモデルカード＋commit履歴（MNLI/Doom/Flappy/MLP表）・vinnylarouge/jevlike・featherless-ai/simple-jev DeepWiki・TianyuCodings/NanoJev＋aaroncool9 mirror・rongxinzy/LightJev・cua-ai/cua-s1-forms＋RuntimeWire/HN・jaredpalmer/kev-0.5b/0.6b/4bカード（decision-v4/transfer-v4・Brier・seed・locked test）・Archer Hume「Jev's Architecture Unmasked」・Latent.Space 6 clones・Bespoke Nimble発表・dleemiller ModernCE-large/base＋tasksource・mini-jev（CLINC150・prereg）・bnsd55/jevmlx・Shopify Reflex・vLLM PR #57250・Viswa Kumar RLCD解説・ConfidenceBench/Calibration論文。

    重み・データは各ライセンス（MIT/Apache-2.0/Qwen/CC-BY等）に従うこと。数値は2026-09-18〜20時点の報告。

    以下は報告書ですー。

    あなたへのおすすめ