Jevを再現しようとしたモデル6本、設計はどこで割れたか。

新しいモデルが出たとき、たいていクローンは1本か2本、しかも同じ作り方で出てきます。Jevは違いました。公開から2日で6本並んで、しかも6本とも中身の作りがバラバラです。この記事では、その6本がどこで設計を分けたのかをリポジトリまで降りて追います。

公開2日でクローンが6本、何がそんなに刺さったのか

Jevはtypesafe.aiのSystem Oneモデルで、文章を返さずに型の付いた確率を返します。入力は100万トークンあたり0.042ドル、日本円だと約6.3円。出力トークンは無料です。応答は70msから500msを公称しています。

そして重みは公開されていません。AI Gatewayでは公開初日にチームの約13%が触っていて、これはGPT-5.6ファミリーの2倍、Fable 5.1の6倍です。需要はあるのに中身が見えない、という状態が2日続いた結果が6本のクローンでした。

同じゴールに向かったのに、なぜ6本とも作りが違うのか。触った場所がそれぞれ違うからです。エンコーダを取り替えた人、拡散モデルを持ってきた人、LoRAで足した人、そもそも学習を放棄した人、ゼロから組んだ人。この分かれ方そのものが、判断特化モデルの設計余地を可視化しています。

421MのLayaは、エンコーダ1回で答えを出す

いちばん小さい本気の実装がLayaです。ModernBERT-largeをバックボーンにした421Mパラメータ、ライセンスはApache 2.0。非自己回帰で、1回のforward passに約33msしかかけません。

GitHub - NandhaKishorM/laya

Contribute to NandhaKishorM/laya development by creating an account on GitHub.

github.com

学習はstrictly proper scoring rulesに対する強化学習（RLCD）で、GRPO-style policy gradientを使っています。確率を「当てる」のではなく「較正する」ことを報酬に組んでいるわけで、判断モデルとしてはかなり素直な設計です。

チェックポイントは3つあります。layaが421Mで512トークン、laya-multilingualがmmBERT-baseベースの322Mで1024トークン、laya-typed-decisionsが421Mで1024トークン。多言語版はT4で10問を72msで返しています。

26Bの拡散モデルをJevにする、という逆張り

これは正直、最初に見たとき何を言っているのか分かりませんでした。vLLMのプルリクエスト#57250が、nvidia/diffusiongemma-26B-A4B-it-NVFP4 に構造化生成を足して、選択肢付きの判断を返せるようにしています。

[Core] structured generation mode for DiffusionGemma model (Jev-like) by mmastrac · Pull Request #57250 · vllm-project/vllm

Prerequisite PRs A few PRs that can go in on their own merits were split out: [Bugfix] DiffusionGemma: hand out stashed logprobs only on the committing step #57414: hand out stashed logprobs only ...

github.com

性能は単体のDGX Sparkで32並列のとき毎秒162判断。プログラミング言語の判定では p(want)=1.00±0.00 が出ていて、10言語の自然言語判定は9/10でした。迷路をN/E/W/Sの制約付きで解かせるテストも通っています。

ただしこのPRはまだopenのままです。readyラベルは付いていますが、マージ済みではありません。今すぐ本番に入れる話ではなく、拡散モデルでも判断タスクは張れるという実証だと思って見るのが正しいです。

LoRA勢のNimbleとKev、9Bと0.5Bで狙いが違う

いちばん王道なのがLoRAでの微調整です。ただ同じ手法でも、Bespoke Labsとジャレッド・パーマーさんでは狙っている場所が真逆でした。

GitHub - bespokelabsai/nimble: Local typed decisions, contrastive data curation, and model evaluation.

Local typed decisions, contrastive data curation, and model evaluation. - bespokelabsai/nimble

github.com

Bespoke NimbleはQwen3.5-9BへのLoRAアダプタで、Apache 2.0。contrastive data curation（1つの事実だけを入れ替えて正解が反転するペアを作る手法）で2,676例を用意しています。324例のhold-out評価で、素のQwen3.5-9Bが66.36%、Nimbleが90.12%、Jev 1.13.0が93.21%。レイテンシはH100で106.0ms、M5 Pro 64GBのMacで444.0ms、Jevの公式API経由が246.7msです。

Macで444msというのが効きます。9Bでもローカルで回る側に入ってきた、ということなので。

GitHub - jaredpalmer/kev: tiny Jev-like model built on top of Qwen2.5-0.5B you can train and run on your MacBook

tiny Jev-like model built on top of Qwen2.5-0.5B you can train and run on your MacBook - jaredpalmer/kev

github.com

逆にKevは徹底的に削りに行きました。frozenのQwen2.5-0.5B（494M）に r=16 のLoRAアダプタとpointer readout headを足しただけ。Apple M5のMacBookで学習が約1時間45分、6問まとめたリクエストの応答が約160msです。精度はhold-outで0.799、ECEは0.065で、1パラメータのtemperature scalingを掛けると0.031まで下がります。

ここがいちばん実務的だと思うんですが、KevはTypeSafeのSystem One契約に合わせたAPIを持っていて、base_url を差し替えるだけで公式の typesafe-sdk がローカルのkevサーバーに向きます。移行コストがほぼゼロです。

SemIfは、そもそも学習していない

6本の中でいちばん発想が違ったのがSemIfでした。旧名OpenJev、作者はセオドア・リーさん、ライセンスはMITです。

GitHub - TheoLeeCJ/SemIf: Semantic ifs from open models, on a 3090 at home. Independent; not affiliated with Jev or TypeSafe.

Semantic ifs from open models, on a 3090 at home. Independent; not affiliated with Jev or TypeSafe. - TheoLeeCJ/SemIf

github.com

何をしているかというと、モデルを一切訓練しません。frozenのQwen3.5-4Bに問いと選択肢を投げて、許可した答えそれぞれの確率をlogitから直接読むだけ。出力トークンはゼロです。JSONを生成して壊れたら直す、というループが丸ごと消えます。

効果は数字にはっきり出ていて、RTX 3090の1枚で21個の二値判定を1.023秒。同じケースを自己回帰でJSON生成させると5.332秒なので、約5倍です。TypeSafeの102行サブセットでの一致率は0.845、同じケースでのJevが0.883でした。

判定の中身を変えるたびに学習し直すのはしんどくないか、と思いますよね。SemIfは判定基準も選択肢の説明もリクエストに同梱するので、判断の定義がファインチューンに焼き付きません。実行時に差し替えられます。これがHacker Newsで621ポイント（2026年9月18日）を取った理由だと思っています。

ゼロから作るjevlikeは、どこまで削れるか

もう一方の極がjevlikeです。MITライセンスで、デフォルトではバイト埋め込みをゼロから学習します。事前学習済みモデルに乗らないという選択です。

GitHub - vinnylarouge/jevlike

Contribute to vinnylarouge/jevlike development by creating an account on GitHub.

github.com

仕組みはoption-attentionと呼ばれていて、選択肢ごとにqueryベクトルを作り、それがコンテキストのトークンにattention重みを割り振り、選択肢とコンテキストのペアを共有のdot productで1つのスコアにして、最後に選択肢方向のsoftmaxを取ります。frozenの事前学習済みエンコーダを使うオプションもあります。

精度は正直きついです。Wikispeediaでの実験は26〜29%でした。パラメータ規模を40Kとする集計記事もありますが、リポジトリ側に明記がないので数値としては確認できていません。本番投入の候補というより、判断モデルの最小構成を手で確かめるための教材として見るのが実際的です。

学習データは合成100%ではなかった

6本の共通点として「学習データは全部合成」という話がよく出ます。リポジトリを1本ずつ開くと、そうなっていませんでした。実際は3通りに割れています。

• 完全に合成: Bespoke Nimble。リポジトリに「ラベルはすべて合成であり、モデルが検証しただけで人間はレビューしていない」と明記されています
• 公開データセットの変換: Kev。Banking77、BoolQ、AG News、MNLI、SST-5、Yelp Review Fullの6つから各1,500件を取り、9,000レコード13,500問に変換して2エポック回しています
• そもそも学習しない: SemIf。訓練データという概念がありません

Layaは合成ワークフローと公開ベンチマーク（MASSIVE intent、XNLI、AG News、BoolQ等）の両方を参照していて、中間です。

では、合成に寄るチームはなぜ寄るのか。Jevの出力そのものを教師にできないからです。Nimbleは「Jevの確率は将来のsoft-target蒸留用に保存してあるが、現在の学習目標はJev由来ではないhardラベルを使う」とわざわざ書いています。ここを踏み越えると再現ではなく蒸留になる、という線引きを各チームが自分で引いている。

そして判断タスクは、選択肢が有限なぶん正解ラベルが安く作れます。文章生成の再現より合成データが機能しやすい領域だった、というのが6本並んだ本当の理由です。

ローカルで動かすなら、どれを選ぶか

で、結局どれを触ればいいのか。手元の環境とやりたいことで素直に割れます。

• MacBookで学習まで完結させたい: kev。0.5Bベース、Apache 2.0、M5で1時間45分。typesafe-sdk がそのまま向くのも強い
• 学習せずに今日動かしたい: SemIf。MIT、RTX 3090クラス1枚、frozenモデルのまま
• とにかく軽くて速い推論が要る: Laya。421MでApache 2.0、1回のforwardが約33ms
• 精度を90%台に乗せたい: Bespoke Nimble。Apache 2.0、ただし9BなのでH100で106ms、Macなら444ms
• 拡散モデルの判断が気になる: vLLMのPR #57250。マージ待ちなので今は追うだけ
• 最小構成を自分の手で組み立てたい: jevlike。MIT、精度は期待しない

ライセンスで詰まる心配はあるのか。ここは拍子抜けするくらい平和で、出てきたのはApache 2.0とMITだけでした。商用で使う前提でも6本とも検討の土俵に乗ります。

今日いちばん低コストで試せるのはSemIfだと思います。学習が要らないぶん、手元のGPUに載せて自分のユースケースで一致率を測るところまで、その日のうちに行けます。そこで型付き判断の手触りを掴んでから、常用したくなったらkevかNimbleへ移る。この順番がいちばん事故りません。