pplx-decider vs Kev：すでにプルできる2システム1モデル

この対決における有益な偶然は、今日の午後には自分のハードウェアで決着をつけられることだ。Perplexityの27B意思決定モデルであるpplx-deciderは、2026-10-01に告知もなく登場し、2026-10-05にv1.1リビジョンが出て、どちらもOllamaライブラリにある。Jared Palmerの再現ラインであるKevは、v2が2026-09-30に登場して以来Ollamaにあり、0.5Bから27Bまでをカバーしている。両者は同じ呼び出し形式をとる——状態と名前付き質問のリスト、1回のフォワードパス、返ってくる確率、生成テキストなし——つまり同じハーネスで両方を実行できる。異なるのはその下にあるすべてだ。出力がどのように生成されるか、著者が何を文書化したか、そしてどれだけGPUを必要とするか。

まず、ベイクオフをそもそも可能にするものから始めよう。どちらのモデルもテキストを書かない。文書を渡し、名前で質問する。各質問は回答タイプを宣言する — 2～255のラベル付き選択肢からの選択、はい／いいえ／不明の読み取り、または2～10の記述されたレベルにわたるスコア。回答は、尋ねた順序で確率として返ってくる。60の質問を含むチケットは、モデルへの1回のパスであり、60回の呼び出しではない。

各モデルが実際に意思決定を行っているのはどの程度なのか

Kevのカードは、内部の書き物以外では珍しいほど、その構築方法について明示的であり、その詳細は、そこから数字を信用する前に読む価値がある。27Bチェックポイントは、Qwen/Qwen3.8-27Bに対するフルウェイトの教師ありファインチューニングであり、その後、重み平均——新しいモデルの0.85とv1の0.15をfp32でブレンドしたもの——が行われる。0.8Bから9Bまでの小さいサイズは、完全なチェックポイントではなく、Qwen3.5ベースのLoRAアダプターとして提供される。

出力の形を決める部分は、言語バックボーンとは別です。Kevはポインターヘッドを備えています — fp32で約2.6Mパラメータ、25.6Bのバックボーンの上に載って26Bになる — これが隠れ状態を、指定した選択肢に対する確率に変換します。pplx-deciderは、公開された [255, 5120] のリードアウトヘッドで同じ役割を果たします。5,120幅の隠れ状態に対する255個の選択肢を、bf16で。

2つのアーキテクチャ、1つのアイデア：言語モデルが読み取り、小さなヘッドが判断する。だからこそ、どちらも散文を生成しないのであり、また、両方が同じ参照モデルに対して示されていても、一方のベンチマークスコアが他方に移行することはないのである。

記録上唯一の直接対決、そしてそれを差し引けない理由

両方のプロジェクトはJevに対して報告しているため、それらを並べて比較したくなります。しかし、そうしてはいけません。

Kev自身のカードには Decision Index 0.2 の行があり、Kev-27B v2 を 52.3 とし、v1 の 50.2、Jev の 54.0、AutoJev-27B の 50.0 と対比している。これはクリーンな、同一スイート・同一バージョンの比較であり、Kev v2 が約2ポイント改善したが、依然として Jev に後れを取っていることを示している。

pplx-deciderのカードは、v1.1についてスイート加重総合61.56を報告しており、v1の56.4、Jevの57.9と対比している。彼ら自身の数字で見れば、それは1回の改訂で5ポイント超の伸びであり、Jevに対する3.5ポイント超のリードである。

その2つの段落は互いに差し引くことはできない。異なるスイート、異なるタスク構成、異なる重み付け — しかもどちらのプロジェクトもその重み付けを公開していない。言えることは、より限定的ではあるが、それでも役に立つ。両方とも同じウィンドウで同じ方向に動き、どちらもバックボーンを入れ替えるのではなく、リードアウトの学習方法を変えることでそれを達成した。そして、pplx-decider が主張する Jev に対する優位幅は、Kev の測定された不足幅よりも大きい。それは pplx-decider を試す理由ではあるが、信じる理由ではない。

二つのうち、その数値のいずれかに独立した再現が付いているのは一方だけだ。KevのOllamaタグは、タグごとにJevBenchの合格件数を公開している——kev:27b-nvfp4は231件中205件、ハード分割では111件中86件を含み、kev:0.8bでは231件中146件まで下がる——ただし、これらは利用できない303件の封印タスクまたはジャッジ採点タスクを除外しており、公式リーダーボードのスコアではないという明示的な注記付きだ。それは自己実行だが、繰り返せる自己実行だ。pplx-deciderには、同等のものは何も存在しない。

Kevがドキュメント化しているが、pplx-deciderはしていないこと

• 温度 — Kev は T = 1.32（90%区間 [1.20, 1.45]）で提供され、ロード時に適用されるため、出力される確率はすでにスケーリング済みです。pplx-decider のカードは温度を一切公開していないため、必要なキャリブレーションは自分でフィットさせることになります。

• トレーニング記録 — Kev v2 は、8× H200 上での 129 GPU 時間、145,840 件のレコードと 337,130 件の質問にわたる 1 エポックで、ラベルは GLM-5.3、DeepSeek-V4-Pro、Inkling、Mistral Large 3、gpt-oss-120b、MiMo-V2.6-Pro によって生成され、Jev の出力は一切使用されておらず、102 の評価パーティションにわたる 6,388 件のレコードを除去した混入スクリーニングも行われた。pplx-decider は、Bespoke Labs の Bespoke Nimble 上に構築され、ベンチマークのサブセットをレコード ID とチェックサムで固定したパイプラインを文書化しており、v1.1 の改善は因果マスクの除去と追加のトレーニングデータによるものとしている — しかし、レコード数、GPU 時間、ラベラー一覧のいずれも公開していない。

• 正直なリグレッション報告 — Kevのカードは自らの失敗を明記している。transfer-v4は0.8ポイント低下で確定、CUADは1.6低下、breadth-v1の期待キャリブレーション誤差は0.015で、CUADでは0.053、v1より2〜4倍悪く、しかも自らの評価における選択楽観性を明記している。pplx-deciderのv1.1の表では、toolsが79.3から78.88へ低下している一方、他のすべてのカテゴリは上昇しているのに、カードにはそれについて何も言及がない。

• 障害モード — Kevのカードには、混入スクリーニングの対象範囲と、公表された数値がどのような条件下で算出されたかが記載されている。Deciderファミリー、すなわちMapikaの製品ラインはさらに踏み込み、それが破綻する具体的な入力形状を明示している。pplx-deciderはこの問題について何も述べていない。

これはどれも、pplx-decider が劣っていると言っているわけではない。ドキュメントは能力ではない——ローンチ記事を下書きしているラボと、Hugging Face にノートを公開する個人とでは、インセンティブが異なる。しかし、2つのモデルが同種の結果を主張し、そのうち片方だけが自身の temperature を明かしているなら、明かしているほうこそ、今月プロダクションに投入できるものだ。

コンテキスト会計——ここが両者の最も大きく乖離する点だ

• Kev — 65,536トークンの状態、さらに質問あたり少なくとも8,192トークン、トレーニングは最大32,768。64k状態では、常駐フットプリントはピーク時に約87.1 GBに達し、モデル時間は9.4秒、キャッシュヒット時は733 ms、単一クライアントでは毎秒21.1リクエスト、64では36.4。

• pplx-decider — テキストと画像を合わせて8,192トークンで、大きすぎる入力は切り詰められるのではなく拒否されます。Ollamaビルドは256Kのコンテキストウィンドウを記載していますが、これはリポジトリ内のどこにも説明がなく、モデルカード自体の上限とも整合しません。

その差は、実際のワークロードにおいて両者の間で最も重大な単一の違いです。Kev は長い状態と、それらに対する多くの質問のために作られています。pplx-decider は、比較的小さな入力バジェットを持つ dense な 27B であり、そのため短い文書、画像、そして数千トークン以内に収まる質問へと向かうことになります。

• 言語 — 両方とも英語のみ、両方とも制限事項として明記。

• ビジョン — pplx-decider はテキスト、JSON、画像を扱え、ビジョントークンのコストはおおよそ幅 × 高さ ÷ 1024 で、評価設定は 512×512 が上限です。Kev は 27B 系ではビジョン非対応です。

• サービングの最低要件 — Kev-27B には 80 GB クラスの GPU が必要です。bf16 の重みが 51.3 GB、常駐メモリが約 65.5 GB、64k 状態では 87.1 GB になり、KEV_API_KEY が設定されていない限り、そのサーバーはオープンにバインドします。pplx-decider の bf16 の重みは約 49 GiB なので、最低要件は同程度です。量子化された Ollama ビルドは 17 GB に収まり、これはまったく別のマシンになります。

• 段階 — Kevは0.5B、0.6B、0.8B、4B、8B、9B、27Bにまたがり、小さいサイズはLoRAアダプターです。pplx-deciderは単一サイズで、2回改訂されています。

それに賭けずにベイクオフを実行する

両モデルはローカルウェイトとして利用可能であり、これはまさにルーティング層がその存在価値を発揮する状況です。OrcaRouter は pplx-decider を提供しておらず、Kev も提供していません — どちらもカタログに存在せず、ここに書かれている内容は、当社がそれらをホストしているという主張として読まれるべきではありません。このクラスで当社が扱っているのは typesafe/jev-1.13 で、同じ POST /v1/systemone 呼び出し形式を通じて、入力トークン100万個あたり $0.042 で公開されており、これは自然な対照アームです。同じインターフェース、同じ質問タイプ、自前の GPU は不要です。

その構成なら三者比較のベイクオフを安価にセットアップできる。同じハーネスの背後にローカルの pplx-decider とローカルの Kev を置き、ルーティングされた typesafe/jev-1.13 と対戦させ、3つすべてを自分のドキュメントで採点すれば、両者の不一致が、しきい値が実際どこにあるかを教えてくれる。この構成では自動フェイルオーバーがいつも以上に重要になる。単一カード上のローカル 27B はチェーン内で最も信頼性の低いコンポーネントだからだ。フォールバックを200以上のモデルに対応する1つのAPI（プロバイダーの定価をそのまま、マークアップ0%）経由でルーティングすれば、実験が障害に変わるのを防げる。そして pplx-decider のようなモデルがやがてホスト型エンドポイントに到達したとき、対照群を動かしているのと同じキーでそれを動かせる。2つ目の契約もコード変更も不要だ。

何が答えを変えるだろうか

4つの事柄があり、それらはすべて好みの問題ではなく検証可能だ。

pplx-deciderが推論プロバイダーに到達すれば、その未検証のベンチマーク表は価格対レイテンシーの問題になり、ドキュメントのギャップは問題にならなくなる——あなたはホストされた読み出し結果にお金を払うことになり、自分で維持するのではない。独立した第三者が、公開されたハーネス上でどちらかのモデルのJevBench数値を再現すれば、比較全体は互換性のない2つのスイートではなく、単一のスイートに絞り込まれる。

Kev の CUAD における文書化された ECE の弱点が、再トレーニングではなく再フィットで修正可能だと判明するなら、それに対するキャリブレーション上の反論はほぼ消える。なぜなら Kev はすでにその温度パラメータを備えて出荷されており、その故障モードも既知の要素だからだ。また、2枚ではなく1枚のカード上で意思決定モデルが必要なら、ここでは pplx-decider の 17GB 量子化ビルドが唯一の選択肢だ。それはより優れているからではなく、bf16 の 27B が収まらない場所に収まるからである。

それらのどれかが起こるまでは、実用的な見立ては地味だ。Kev は、今日すぐに同じ数字を再現でき、文書化されていると信頼できるキャリブレーションを持つほうだ。pplx-decider は、主張されている上限はより高いが、裏付けとなる記録が弱いほうだ。今月リリースするなら、前者を選べ。静かなリリースを測定するほうが、ローンチ投稿を待つよりよいというタイプのチームなら、後者を同じハーネスに引き入れろ。

を経由してフォールバックをルーティングすることは、0%のマークアップでそのまま渡されるプロバイダーのリスト価格ローカルチェックポイントがチェーン内で最も信頼性の低いコンポーネントである場合に、三者間の比較検証が障害に発展するのを防ぎます。

三者によるベイクオフは、このクラスでこれまでに何が失敗してきたかを問いかけるのにも適した機会です。意思決定モデルが関わる、記録に残っているAIインシデントやエージェントの失敗は、OrcaRouter AI Incident Archiveに集約されており、各エントリには独自の出典、重大度、信頼度グレード、および論争中フラグが付随しています。