RSI-Jev vs Jev 1.13：一方はダウンロード、一方は呼び出し

を並べてみるとRSI-Jev v6.1-VL 4BとJev 1.13、まず呼び出し側が気づくのは、両者が同じリクエストだということです。どちらかに状態と型付きの質問群——はい/いいえ、k個から1つ選ぶ、ルーブリックで評価する——を渡すと、どちらもすべての選択肢について較正済みの確率を、1回のフォワードパスで、解析すべき生成テキストなしに返します。これは偶然ではありません。RSI-Jevは意図的にJevのワイヤフォーマットを話すように作られているので、TypeSafeのAPI向けに書かれたクライアントはベースURLを変えるだけでこれに対して動作します。同じでないのは、呼び出しを取り巻くすべてです。Jev 1.13はTypeSafeのクローズドな商用モデルで、従量課金のエンドポイントから提供されます。RSI-Jev v6.1-VLは、Apache-2.0の重みの下にある4.69Bパラメータのチェックポイントで、自分でダウンロードして自分のハードウェア上で提供します。どちらかが他方のリブランドではなく、どちらのベンダーも他方を推奨しておらず、この比較のほぼすべての数値は、それを作成した当事者から来ています。

対象の日付は重要である。なぜなら、このプロジェクトはほぼ毎日リリースを出しているからだ。RSI-Jev v6.1-VL 4Bは2026-10-07に、第三者の Shanghua-Gao/RSI-Jevプロジェクト——Jev方式の意思決定モデルを訓練し、失敗したすべてのアームを成功したアームとともに公開する自己改善型の研究ループ——によって公開された。それはその系列における13日間で8番目のリリースであり、前回リリースと、同じQwen3.5-4B-Baseの2回目のファインチューンとの重み平均である。Jev 1.13はTypeSafe AIのモデルで、2026-09-15にローンチされ、2026-09-24から当社のカタログに掲載されている。以下の比較では両方の日付が重要である。なぜなら、毎日のように動くプロジェクトとの比較は、賞味期限が日単位で測られるからだ。

2つが実際に何なのかを、それぞれ1行で

Jev 1.13は専用エンドポイントの背後に置かれたホスト型の意思決定モデルです——POST /v1/systemone、非ストリーミング、ステートとあなたのすべての質問を合わせておよそ64,000トークンの入力バジェット、価格は入力100万トークンあたり$0.042で、出力トークンが存在しないため出力の課金はゼロです。そのアーキテクチャ、パラメータ数、トレーニング計算量は非公開です。TypeSafeは詳細を伏せており、論文が後日出るかもしれないと述べています。あなたがこれを実行するのではありません。あなたはこれを呼び出すのであり、その呼び出しはすべて従量制のネットワークリクエストです。

RSI-JI v6.1-VL がその構成の全容です。これは 3.5-4B-Base タワーをエンドツーエンドでファインチューニングしたもので、層16、20、32に決定ヘッドを備え、自己完結型で bf16 で 9.7 GB のチェックポイントから提供されます。パラメータ数は 4.69B で、それがどこに割り当てられているかを知っておく価値があります。32個のデコーダ層に 3.57B、トークンに 0.64B、ビジョンタワーに 0.33B、メイン決定ヘッドに 0.05B、2つのアーリーイグジットヘッドに 0.10B です。エキスパート混合はなく、第2のモデルもありません。リポジトリから pip コマンドでインストールし、そのサーバーを実行すれば、その時点から決定があなたのインフラストラクチャの外に出ることはありません。

• 誰が実行するのか — あなたが管理していない従量制のホスト型エンドポイントか、それとも自分のGPU、Apple Silicon、CPU上の9.7 GBのチェックポイントか。

• 価格の構造 — 入力トークン100万あたり$0.042、出力は無料、呼び出しごとの課金か、限界的にはゼロにマシンと運用のコストを加えたものか。

• 入力バジェット — ホステッドモデルでは1リクエストあたり約64,000トークン、チェックポイントでは32,768テキストトークンに加えて画像バジェットがあり、それを超えるものは切り詰められるのではなく拒否されます。

• 重みとライセンス — 非公開・サイズ非開示 対 Apache-2.0 の重み、MIT コード、46.9億パラメータ。

• モダリティ — Jev の契約ではテキストのみであるのに対し、RSI-Jev ビジョンリリースではリクエストごとにテキストと最大 4 枚の画像を使用。

• 所有権 — TypeSafe AIの商用モデルと、自らのライセンス条項に「Not affiliated with TypeSafe AI」と明記している第三者による研究プロジェクトとの比較。

RSI-Jev自身のボードにおけるスコア、そしてそれが比較の半分にすぎない理由

プロジェクトが最初に示す数字は、そのDecision Index 0.3スコアである。v6.1-VL 4Bで50.98、前リリースの46.23からの上昇だ。これはデフォルト構成でのフルラン——140,178リクエスト、カバレッジ1.0——であり、プロジェクト自身の公開ボード（2026-10-06付）では、そのボード最良の4Bモデルと並んでいる（50.98に対しezjev 4B s2が50.82で、キットはこれを0.25でのタイとして扱う）。全体では113件中27位だ。旧Decision Index 0.2.1では50.74で、v6.0-VLの46.24と対比される。15ベンチマークのスイートは、学習行との重複が判明したopen_jev_oodタスクを除いて報告されており0.793、ホールドアウトセットは0.729である。

それらの数値はすべて RSI-Jev 自身のもので、RSI-Jev のハーネス上で測定されたものです。Decision Index は公開ベンチマークボードですが、そこに Jev 1.13 の測定値はありません。なぜなら、このプロジェクトのスイートはオープンな意思決定チェックポイントを採点するために作られており、Jev はクローズドなエンドポイントだからです。したがって、typed-decisions ベンチマークで 50.98 を Jev の 0.727 と対置し、勝者を宣言したくなる誘惑は、まさに避けるべき誤りです。それら二つの数値は異なるハーネス、異なるサンプルサイズ、異なるデータから来ており、誰も単一のハーネスを両方のモデルに対して実行していないのです。

唯一存在する直接比較はLayaのものであり、RSI-Jevのものではない。

公開された比較のうち、実際にオープンチェックポイントの隣にJev数値を並べているものは1つだけあり、それはここにいるどちらの当事者によって実施されたものでもない。Laya意思決定モデルの開発元であるConvai Innovationsは、TypeSafeが公開したJev 1.13.0の数値を自社の数値と並べて表にまとめ、その限界を自ら指摘した。Jevの数値は第三者によって公開されたもので、Convaiが測定したことは一度もなく、サンプルサイズとプロンプトは異なり、さらにそのベンダーはモデルについて自社のベンチマークを公表していない。あの表は較正のために読む価値はあるが、判定を下すためのものではない——そして、公開された時点でRSI-Jevは存在しなかったため、RSI-Jevはまったく含まれていない。

それが示しているのは、読者が実際に天秤にかけているホスト型対オープン型という問いの輪郭だ。選択肢の空間が大きく、モデルが幅広い回答セットを安定して保持しなければならない場面ではホスト型モデルが優位に立ち、呼び出しごとの生のレイテンシでは、経路にネットワークがないためオープンモデルが勝つ。ただしそのパターンのどこを見ても、この2つの特定モデルのどちらがあなたのタスクに優れているかは分からない。そして正直に言えば、その答えはまだ公には存在しない。

チェックポイントがもたらす、エンドポイントにはもたらせないもの

RSI-Jev の最強の論拠は、スコアではない。それは、重みがあなたのディスク上に存在することだ。医療記録、法律文書、あるいは顧客の口座履歴に基づいて下されるルーティング判断にとって、「データは決してこの建物から出ない」というのは、ベンチマークの1点と引き換えにするような選好ではない — それは厳格な要件であり、どのような価格であっても、ホスト型エンドポイントはそれに応えられない。同じ特性がレート制限を取り除く。ホスト型モデルに関するベンダー自身のドキュメントには、その制限は動的に調整されており、予告なしに変更される可能性があると記されている。そして、セルフホストのチェックポイントには、あなたのハードウェア以外にそのような上限は存在しない。

チェックポイントがもたらす2つ目のものは深さ制御であり、それは異例だ。判定ヘッドが3つの深さに位置するため、effort設定は、リクエストが使用できる層数を選ぶ：lowは層16で停止し、中央値は約23 ms、mediumは層20で27 ms、highは層32で約40 ms、そしてautoは、十分な確信度に達した最初の出口で応答し、プロジェクトのスイートでは32層のうち平均19.5層を使用する。これらのレイテンシは、単一のH200上でbf16で計測されたプロジェクト自身の数値であり、いかなるホスト型の数値とも混ぜ合わせるべきではない — ローカルのフォワードパスと従量制のAPI呼び出しは同じ測定ではなく、RSI-Jev自身のドキュメントは、Jevが公表したレイテンシとの以前の比較が、ローカルGPUの処理をネットワークの往復と突き合わせたものだったと明言している。

3つ目は画像です。Jevの契約はテキスト入力、構造化JSON出力です。RSI-Jevのビジョンリリースは、リクエストごとに1～4枚の画像をbase64データURLとして受け取り、stateは各画像をマーカーで参照し、v6.1-VLはプロジェクトのホールドアウト画像セットで0.834を記録します。あなたの判断が「その写真に目視可能な損傷が写っているか」であるなら、それはホスト型契約がまったく提供していない機能です。

あなたが犠牲にするものも現実であり、プロジェクトはそれを公表している。このリリースではキャリブレーションは改善するどころか悪化した。最終的な期待キャリブレーション誤差は、レイヤ32で0.048、そしてオート使用時で0.055、前回リリースの0.036と0.024に対して。デフォルトの単一しきい値0.95は、明示的に未確認のまま出荷される — これは選択ルールのフォールバックであり、そのルール自身の選択である0.85は、開発データの半分でプロジェクトの深さ上限に達しなかった。早期終了はテキストのみを読み取るため、画像を含む質問は、エフォートに関係なく32層すべてを実行する。また、画像学習ソースの5つは非商用または研究専用であり、プロジェクトは、非商用データでトレーニングされた重みがそれらの条件を継承するかどうかは確定していないと明言している。

どこでホスト版を呼び出すべきか、そしてどこで呼び出すべきでないか

これは私たちが利害関係を持つ比較の部分であり、正確を期す価値があります。私たちはTypeSafeの商用モデルをtypesafe/jev-1.13として専用のsystemoneエンドポイントで提供しています — OpenAIのchat-completions形式ではなく/v1/systemoneへのPOST、非ストリーミングで、私たちのカタログに記載されている65,536トークンのコンテキストに対応します。これはRSI-Jevが実装しているのと同じリクエストと回答の形式であり、プロジェクトがその契約をコピーしたモデルによるものです。RSI-Jev自体は私たちはホストしていません。私たちのカタログにrsi-jev idもshgao idも存在せず、そのモデルを求める読者は自分でダウンロードすることになります。

ここでその区別が重要になる理由は、限定的かつ具体的です。意思決定レイヤーがワークフロー全体を占めることはほとんどなく、通常は返信や要約、コードを生成するモデルの隣に位置します。これは歴史的に2つの契約を意味してきました。ホスト型の半分については、もはやその必要はありません。Jev 1.13は、200以上の他のモデルと同じキー上にあり、料金はプロバイダー表示価格を0%のマークアップでそのまま適用したものです。したがって、TypeSafeが料金を変更すれば、その変更は次の請求サイクルではなく、当社側で当日に有効になります。セルフホスト型の半分にはそもそもその問題はありません。なぜなら、プロバイダーはあなた自身だからです。両者を選ぶ明快な方法は、まず自分のラベル付きケースをいくつか使って商用契約を試し、そのまま使える挙動が自動化に十分かどうかを確認し、その後になって初めて、4.69Bチェックポイントを自分で運用することが運用コストに見合うかどうかを検討することです。

実際にどれを選ぶべきか

意思決定があなたの境界内に留まらなければならないなら、テキストだけでなく画像についても判断が必要なら、選択肢セットが数百に及ぶなら（このチェックポイントは質問ごとに最大5,120個の選択肢を受け付ける）、あるいはリクエストごとに深さとレイテンシを調整したいなら、RSI-Jev v6.1-VL 4Bを選びましょう。13日間で8回変わったプロジェクトを採用すること、その最新リリースがキャリブレーションを犠牲にして精度を優先したこと、そしてそれ自身のカードが確認できなかった終了ポリシーの部分を明記していることを承知のうえで臨んでください。

サービングスタックなしで意思決定を機能させたいなら、誰か他の人が維持してくれるエンドポイントを重視するなら、そして出力トークンを計量する必要がない $0.042/100万入力という価格があなたの呼び出し量に対して安いなら、Jev 1.13 を選びましょう。ただし、サイズが非公開のクローズドモデルを呼び出しており、レート制限は予告なく変わりうるし、公開されているベンチマークは自分で再実行できるものではないことを承知のうえで進んでください。

両者に共通する点は、両者を分かつ点よりも有用であり、このような比較をわざわざ書く価値がある理由でもある。どちらのモデルもテキストを生成しないため、波括弧を閉じ忘れたり、フィールドをでっち上げたりするモデルに由来する種類の障害を、どちらも持ち込まない。どちらも確率を返し、どちらの場合も、その確率こそが、自動化に踏み切る前に自分のラベル付きデータで検証しなければならない部分である——レイテンシはすでにコモディティ化しており、信頼度の値はデプロイごとに勝ち取らなければならないものだ。ダウンロードか呼び出しか、どちらの側に立つとしても、まずキャリブレーションをテストせよ。