pplx-decider 対 Decider：Perplexityのサイレント27B、Mapikaのオープンラダーに対抗

今、Hugging Face上には2つの意思決定モデルがあり、どちらも質問には同じように答えるが、それ以外ではほとんど何も一致しない。pplx-deciderはPerplexityによる27Bのチェックポイントで、2026-10-01に発表もブログ記事も料金ページもなく、またそれを扱う推論プロバイダーもないまま登場した。改訂版のpplx-decider-v1.1が、同じバックボーンで2026-10-05に続いた。Deciderは、同じクラスのモデルにおけるMapikaのファミリーだ。decider-0.8bからdecider-35b-a3bまでがあり、System Oneの系譜におけるオープンな再現で、完全なトレーニングノート付きで公開されている。どちらも、名前付きの質問群と文書を受け取り、1回のフォワードパスで回答ごとに較正された確率を返す。どちらも散文を一行も書かない。以下に示すのは、それぞれについて実際に記録に残っていることであり、記録が途切れる箇所には明確な印を付ける。

まず、その文の中で「decision model」はどんな役割を果たしていますか。

これらのどちらも、簡潔に答えろと要求されたチャットモデルではない。通常の意味での言語モデルですらない——デコーディングループも、サンプリングも、トークン単位の何かも存在しない。あなたの文書に対する1回のフォワードパスが、あなたが与えた選択肢ごとに確率を返す。

呼び出しの形こそが、この比較をわざわざ書く価値のあるものにしている。あなたは状態（チケット、JSONレコード、スクリーンショット、契約書）と、名前付きの質問のリストを渡す。各質問は回答タイプを指定する。2～255個のラベル付き選択肢からの選択、はい/いいえ/不明の読み取り値、または説明付きの2～10段階のスコアである。回答は、質問した順序で、0から1の間の数値として返ってくる。その数値は、きれいなラベルとしてではなく確率として読まれるべきものだ——「返金が要求されているか？」に対する0.62が出力のすべてであり、しきい値を決めるのは呼び出し側である。

その設計は遅延とコストを劇的に抑えます。なぜなら、60個の質問を含む文書でも、60回ではなく1回の処理で済むからです。それはまた、言語モデルを評価する通常の方法が当てはまらないことも意味します。読むべき推論の痕跡もなく、議論の余地のある思考の連鎖もなく、自己説明を求める方法もありません。得られるのは確率質量だけで、それ以外は何もありません。どちらのプロジェクトも、これがトレードオフであると明言しています。

何が出荷され、誰も口にしなかったこと

pplx-decider リポジトリは、ローンチ記事が一切ないモデルとしては異常なほど完成されている。重みは Apache-2.0。ベースはカードに記載されている通り Qwen/Qwen3.8-27B。bf16 のリリース済み読み出しヘッドが [255, 5120] にあり、これは 5,120 幅の隠れ状態上で 255 個の選択可能なオプションを扱う場合にまさに期待される形状だ。カードには入力バジェット、オプション上限、3 つの質問タイプ、そしてエンドポイント形状 — POST /v1/systemone — が記載されている。

そこに欠けているのは、ローンチ投稿なら載せているはずの一文だ。カードにはリリース日も、告知も、Perplexityによるベンチマーク投稿も、価格も、それを提供する第三者のプラットフォームもない。ダウンロード数は、宣伝されたというより、見つけられたリポジトリから得られる程度の規模だ。両者を合わせて読めば、正直な説明はこうなる。成果物は公開されているが、その背後にある意図は公開されていない。以下でpplx-deciderについて述べることはすべて、リポジトリとそのカードに基づいている。以下はいずれも独立に再現されておらず、ラボの外で独自の実行結果を公開した者もいない。

Ollamaライブラリのエントリは、そのずれをささやかに可視化している。そのページではタグを27b、17 GB、256Kコンテキストウィンドウとして掲載している——量子化ビルドであり、bf16重みが占める約49 GiBを大きく下回る——一方、リポジトリはテキストと画像の入力バジェットをはるかに小さく記しており、大きすぎる入力は切り詰められるのではなく拒否されると述べている。これら二つの記述は明らかに同じ制限を説明しているわけではなく、公表されているもののうち両者を整合させるものはない。ランタイムの数値は、ランタイムの主張として扱え。

興味深いのは、二人の見知らぬ人と一つのインターフェース

MapikaのDeciderファミリーとpplx-deciderは、異なる基盤から、異なる理由で、独立に開発され、同じワイヤーフォーマットに収束した。DeciderモデルもSystem Oneのコール形状を話す——名前付きの質問、2～255個の選択肢からの選択、テキスト生成なし、状態はおよそ32kまで受け付ける。一方向けに書かれたクライアントは、ほぼそのままもう一方向けのクライアントになる。

その収束こそが、この比較で役に立つ事実だ。どちらを選ぶにしても、書き直しではなく、ベースURLとモデル文字列を差し替えるだけである。興味深い問いは「どのAPIを統合するか」ではなくなり、「自分の文書について、どの読み取り結果を信頼するか」になる——そして、この2つのプロジェクトはその問いに大きく異なる仕方で答えている。

ラダーに対する1つのチェックポイント

構造上の違いは最も分かりやすい。Perplexityは単一サイズを投入した。Mapikaは複数サイズを投入し、サイズ表を公開した：

• カタログ — pplx-decider：1つの27Bチェックポイント、さらに同じバックボーン上のv1.1リビジョン。Decider：7つ以上の公開済みサイズ。decider-0.8b（1.4 GB）から、decider-2b、decider-2b-vision、decider-4b、decider-12b、そしてdecider-35b-a3b（65 GB bf16、またはnvfp4で19.6 GB）まで。

• ベース — pplx-decider: Qwen/Qwen3.8-27B、単一の系統。Decider: 混合構成 — 小さいサイズには Qwen3.5-0.8B、Qwen3.5-2B、Qwen3.5-4B、大きいものには Qwen3.5-35B-A3B、そしてチャットバリアントには gemma-4-12B-it と gemma-4-31B-it。

• アクティベーション — pplx-decider：密な27Bなので、呼び出しごとにすべてのパラメータが実行されます。Decider：decider-35b-a3b は Mixture で、合計34.7B、256のルーティングされたエキスパート全体で約3Bがアクティブ、トークンごとにそのうち8つが稼働します。

• Vision — pplx-decider：マルチモーダルであり、リポジトリもそう明記しています。テキスト、JSON、およびスクリーンショット、領収書、フォームを含む画像を扱い、ビジョントークンのコストはおおよそ幅 × 高さ / 1024 です。Decider：メインライン上のフラグではなく、別個の decider-2b-vision チェックポイントなので、画像作業は異なる引数ではなく、異なるモデル選択となります。

• ライセンス — どちらも Apache-2.0 で、この比較で唯一退屈なのはここだけだ。

• トレーニング開示 — pplx-decider: Bespoke LabsのBespoke Nimbleを基盤とするデータパイプラインで、ベンチマークのサブセットはレコードIDとチェックサムによって固定され、v1.1の成果は因果マスクの除去とtasksourceを含むデータの追加によるものとされている。Decider: バージョンごとの注記にはアイテム数、ハードウェア、ウォールクロックが含まれ — decider-35b-a3bは4× B300上で394分間にわたり1,543,567アイテムを学習 — さらに、名称が付された失敗モードと、実際に学習されたパラメータの割合、34.7Bのうち2.45Bが含まれる。

そのどちらも決定的な優位性ではありません。単一のチェックポイントは、考えるのがより簡単で、提供しやすく、サイズを小さくすることは不可能です。ラダーを使えば、decider-0.8b を安価なプレフィルターの後ろに置き、必要な項目にだけ 35B を使えます — ただし、どちらがどちらなのかを判断するルーティングロジックを維持する覚悟がある場合に限ります。

数字、そしてそれを生み出したのは誰か

主要な数値はいずれもベンダーによる報告であり、どちらにも独立した再現研究が添えられていない。この点は、通常よりもここで重要な意味を持つ。画像や言語のアリーナと同格の、第三者の意思決定モデル・リーダーボードが存在しないからだ。

Perplexity自身によるpplx-deciderの数値では、11の公開ベンチマーク全体で85.7%となり、Jevの84.5%、学習元となったQwen3.8-27Bベースの74.8%に対する結果となっている。報告されている個別行には、RAGTruth 88.8、FinancialPhraseBank 84.2、TabFact 90.6、JudgeBench 78.3、WinoGrande 83.3が含まれ、より完全なセットはCirca、Belebele、TruthfulQA binary、BBH、ContractNLI、およびJevBenchの公開ハード分割に及ぶ。v1.1改訂版は、スイート加重の総合で61.56を報告しており、v1の56.4、Jevの57.9に対する結果である。単一カテゴリでの最大の伸びは言語タスクにある。Jevとの比較はベンダー自身によるもので、ベンダー独自のスイート上で計算されており、重み付けは公開されていない。

Mapikaの報告は趣が異なる：数値は、それを弱める但し書きが付いて示される。decider-35b-a3bは、0.732のゼロショットベースに対して、in-taskで0.855、held-outで0.810を報告しており、JevBenchの公開ハードスプリットでは0.676 — Jev 1.13.0の0.730を下回る。カードには、強化学習段階が存在しないことも記載されているため、サンプルプレイは、decider-2b v10の93.2%に対して86.4%にとどまり、また、モデルは最も難しい項目で過信しており、ハード層での期待キャリブレーション誤差は0.15である。decider-2b v11は、in-taskで0.802、held-outで0.752と報告されており、ECEは0.156で、公表されているリリースガイドラインの0.08に対して外れている — 著者らによって明記された失敗である。

実行するあらゆる評価に持ち込む価値のある、文書化された失敗モードが 2 つあります。長い JSON 配列内の位置でレコードを選択することは、このファミリーが扱う中で最も精度の低い入力形状と説明されています。また、複数の独立した質問を 1 回の呼び出しにまとめると、independent フラグがオフの場合、回答の最大 12% が反転する可能性があります。どちらも、仕様書には隠され、カードには一度だけ言及される類のものです。

どちらか一方を稼働させるのにいくらかかるか

• 最小の実用的なDecider — decider-0.8b は 1.4 GB。pplx-decider には小型版がないため、その下限はフル27Bです。

• 最大の Decider — decider-35b-a3b は bf16 で 65 GB、nvfp4 で 19.6 GB、トークンあたり約 3B のパラメータのみがアクティブ。

• レイテンシ、Decider 側 — decider-2b は B300 上で CUDA グラフを使って 1 リクエストあたり 4 ms で動作し、eager の 18.9 ms から短縮、バッチ 32 で毎秒約 2,700 件の意思決定を行います。35B は別世界です。3 つの質問を含む 92 トークンのチケットで約 47 ms、64 チケットで 368 ms です。

• レイテンシ、pplx-decider 側 — 何も公開されていません。カードにはスループットやレイテンシの数値が一切示されておらず、これは公開されなかったリポジトリとしては普通のことです。

• 決定あたりのコスト — ここでこの設計が両面で効果を発揮する。1つの文書に対する60の質問は、どちらのやり方でも1回のフォワードパスで済む。そのため、同じ文書に対してより多く質問するほど、決定あたりのコストは激減する。

これが正直なルーティングの状況です。OrcaRouterはpplx-deciderを提供しておらず、MapikaのDeciderファミリーも提供していません。どちらもカタログには掲載されておらず、この記事のいかなる記述もそれに反する主張として読まれるべきではありません。現在このクラスでカタログに掲載されているのはtypesafe/jev-1.13で、同じSystem One形状の意思決定モデルであり、同じPOST /v1/systemoneエンドポイントを通じて65,536トークンのウィンドウを公開しており、入力トークン100万あたり$0.042です。これはルーティングされた意思決定モデルのコストを知る上で有用な基準となります。pplx-deciderのような未発表のチェックポイントを評価する場合、本番経路をそれに賭けることなく行う方法は、200以上のモデルに対応する単一のAPIの背後で、ルーティングされたモデルと並べて自分で実行することです — プロバイダーの定価が0%のマークアップでそのまま適用されるため、これらのプロジェクトが推論プロバイダーに到達したときには、定価が同じ日にここでの価格となります。それまでは、セルフホストのpplx-deciderをルーティングされたtypesafe/jev-1.13と並べて比較することが、実際に何かを教えてくれる比較となるでしょう。

どちらを選ぶべきか

今日、自分のハードウェア上で、自分で選んだサイズで、監査できるトレーニングノートと、あなたに何も要求しないライセンスを備えた意思決定モデルが必要なら、答えは Decider チェックポイントだ。唯一の本当の問いは、どの段階から始めるかである。まずは decider-2b から始めよう。v11 の数値は、まさにあなたが気にかけるであろう難しい分割において、このファミリーが自身の v10 に対して改善していることを示しており、文書化された ECE ギャップは、本番で確率を信頼する前に温度を再フィットすべきだと教えてくれる。

pplx-decider に手を伸ばすべきなのは、同じインターフェースのまま、その背後により大きな密なモデルが欲しい場合、画像入力が重要で、2つ目のチェックポイントを走らせたくない場合、あるいは、来るかどうかもわからないローンチ記事を待つよりも、フロンティアラボの読み出しヘッドを自分たちで評価したいタイプのチームである場合だ。その利点は本物だが未検証でもある。より大きなバックボーン、それを美しく見せるベンチマーク表、そしてレコード単位のチェックサムまで文書化されたトレーニングパイプラインだ。

注目すべきはベンチマークではない。pplx-deciderがそもそも推論プロバイダーに到達するかどうかだ。重みがあり告知がないリポジトリはシグナルであり、製品ではない。ホスト型エンドポイントに現れた瞬間、Deciderのカードがすでに答えている価格対レイテンシーの問いは、願望ではなく現実の比較になる。

セルフホスト型の pplx-decider を、ルーティングされた意思決定モデルの隣で、プロバイダー定価を 0% のマークアップでそのまま適用した 価格体制のもとで実行してください。そうすることで、どちらのプロジェクトが推論プロバイダーに到達した場合でも、表示価格はその日のここでの価格と同一になります。

公開されたラダーに対して測定された新しいチェックポイントは、記録を確認するのにも適した場所です。このクラスのモデルに関する文書化されたAIインシデントとエージェント障害は、OrcaRouter AI Incident Archiveに集められており、各エントリにはそれぞれの出典、重大度、信頼度グレード、異議ありフラグが付いています。