「pplx-decider on Ollama」と書かれたタイトルカード。サブタイトルは「Perplexity は2026年10月5日にチェックポイントを公開——今日ではワンコマンドのローカル pull」、3つのチップには「q4_K_M で 17 GB」「Qwen3.8-27B バックボーン」「8,192トークンの意思決定バジェット」と表示され、ダウンロード矢印が付いたモデルファイルのフラットなラインアイコンの横に並んでいる。OrcaRouter のロゴが右下隅に合成されている。
Engineering & Research

「Ollama上のpplx-decider:Perplexityのサイレント27B意思決定モデルが実行可能に」

著者

Alistair Wren

公開日

最新モデル · 20すべてのモデルを見る →
ベンチマーク:Artificial Analysis · 毎日更新
すべての記事に戻る

Perplexity はpplx-decider-v1.1-27b の重みを 2026-10-05 に公開し、それが取って代わった最初のチェックポイントであるpplx-decider(リポジトリ名 pplx-decider-v1-27b)を 2026-10-01 に公開しました。どちらもQwen3.8-27B のファインチューニング版で、文ではなく確率で答えるものであり、どちらも TypeSafe のJev 1.13 と同じ System One 系譜に位置します。新しいのはモデルそのものではありません。今日現在、pplx-decider は Ollama 自身のモデルライブラリのエントリであり、1 つのコマンドでインストールできます。その掲載が現れる前は、このチェックポイントを実行するには、およそ 49 GiB の bf16 重みを収める余裕のある CUDA GPU が必要でした。今ではノート PC で 17 GB の量子化済みプルです。このページが扱っているのはその単一の変化であり、それが実行可能にするモデルは 14 日前のものです。

具体的に何が変わったのか

Ollama ライブラリのエントリ名は pplx-decider で、このライブラリは秋を通じて意思決定モデルを着実に集めてきた — Laya、Nimble、Kev、Clef、Strands Decider。今回のこれは最新の追加で、保守されているレジストリ上では3つのタグ(pplx-decider:latest、pplx-decider:27b、pplx-decider:27b-q4_K_M)を公開しており、それらはすべて同じマニフェストダイジェストに解決される。サイズの階層ではなく、単一のアーティファクトだ。

• 形式 — llama.cpp で提供される GGUF と、Hugging Face 上の bf16 safetensors シャードの対比

• ダウンロードサイズ — q4_K_M では約 17 GB。一方、bf16 チェックポイントでは重みが約 49 GiB に加えて作業メモリも必要

• ビジョンレイヤー — マニフェストにはモデルレイヤーとは別に約927 MBのプロジェクターが含まれているため、画像入力はテキストの重みとともにパッケージ化されています

• ハードウェア — CUDA マシンではなくコンシューマー向けマシン

このインターフェースは Ollama の/v1/systemoneエンドポイントです。これは v0.35.0 で追加され、v0.35.1 で Clef モデル向けに拡張されました。また、コマンドラインフロントエンドも新たに備えました。2026-10-12 にリリースされた v0.40.4 では、ollama run に意思決定モデルが追加されたため、--ask、--choice、--level を使って、はい/いいえの質問、ラベル選択、ルーブリックのスコアを端末から直接尋ねることができます。そのリリースは3日前のもので、それが手軽に使えるようにしたモデルは2週間前のものです。

A headless capture of the Ollama library page for pplx-decider, showing the library header, the model name and description, the 'latest' tag, the parameter and quantization labels, and the pull command for the 27b q4_K_M artifact.

リポジトリが実際に文書化している内容

このチェックポイントは、簡潔なプロンプトを与えるチャットモデルではない。そのカードには、ネイティブな意思決定レイアウトが記述されている。公開されたクラス名での Qwen3.8-27B バックボーンに加え、bf16 [255, 5120] の決定ヘッドを保持する別個の readout.safetensors がある。これは選択肢スロットに対する 255-way 読み出しであり、全語彙の言語ヘッドではない。デコーディングループは存在しない。すべての質問のすべての選択肢が 1 回のフォワードパスでスコアリングされる。そのため、応答では出力トークン数がゼロと報告される。

カード内の3つの詳細は、ベンチマーク表よりも重要です。なぜなら、それらこそが素朴な統合を壊すものだからです:

• アテンションモード。全アテンション層は保存された非因果モードを使用しており、カードには、デフォルトの因果推論では評価対象の構成が再現されないとはっきり記されています。チェックポイントを既製の因果ローダーで起動すると、公開されているものとは異なる数値が得られます。

• キャリブレーション温度。提供されている DecisionModel.predict は、保存された温度を適用します。ロジットを直接読む場合は、必ず一度だけ適用してください。二度適用しても、まったく適用しなくても、その後に分岐の判断に使うすべての確率のスケールがずれます。

• 実際の判断上限。 1つの判断に用いるテキストとすべての画像は8,192トークンの予算内に収まる必要があり、上限を超えた入力は切り詰められるのではなく拒否されます。トレーニングと報告された評価では画像が512×512に制限されていました。上限の引き上げは max_image_pixels で設定可能になり、デフォルトは2048×2048ですが、カードはより高い解像度がトレーニング分布の外にあると警告しています。

そのモデルは誰も発表していないにもかかわらず、リポジトリは異例なほど完備されている。11個のsafetensorsシャード、decision_config.json、チャットテンプレート、そしてファイルのチェックサムとチェックポイントの来歴を記録したrelease-manifest.jsonが含まれている。ライセンスはApache 2.0である。

ドキュメントの2か所が既に実態とずれています。v1.1 のカードは今も「このプライベートリポジトリ」に対して認証するよう促していますが、そのリポジトリは現在公開されています。そして古い v1 のカードには v1.1 を指す new_version ポインタがあり、これは v1 が置き換えられたことを示す正直なシグナルです。

A headless capture of the Hugging Face model card for pplx-decider-v1.1-27b, showing the checkpoint description, the decision-head documentation and the vendor benchmark block including the Decision Index figure of 61.56.

それを前提に計画を立てる前に確認すべきたった1つのこと

Ollamaの掲載情報は256Kのコンテキストウィンドウをうたっています。その数値はベースモデルから引き継がれたもののようで——Qwen3.8-27Bは確かに262,144ポジションを備えています——それは、意思決定チェックポイントが自身について記録している契約ではありません。チェックポイントは、テキストと画像を合わせて8,192トークンを超える意思決定を拒否します。256Kを前提にパイプラインを計画し、40,000トークンの契約書と4枚のページ画像を投入すると、リクエストは切り詰められるのではなく失敗します。大きい方の数値はアーキテクチャを説明しており、小さい方の数値は、実際に呼び出しているAPIを説明しています。

画像サポートにも同様の際どい点がある。pplx-decider の Ollama モデルカードには、/v1/systemone に対する画像リクエストが示されているが、そのエンドポイントについての Ollama 自身の機能ページには、画像は「Clef モデル専用」と記載されている。この2つの文書のどちらか一方は古い。自分で実行して確認するまでは、この経路でのマルチモーダル入力は未検証として扱うこと — 基盤となるチェックポイントが画像を受け取ることは明らかで、マニフェストがプロジェクターを同梱していることも明らかだが、ランタイムの文書化されたゲートは、モデルカードが示唆するよりも狭い。

ベンダー番号と、それとは別の番号

Perplexity自身によるv1.1チェックポイントの評価では、同一スイート上でJevの57.9、置き換えられたチェックポイントの56.4に対して、Decision Indexは61.56と報告されており、カテゴリ別では言語(69.45)と検索(61.26)の伸びが最も大きい。これらの数値はベンダー報告であり、Perplexity側で算出されたものだ。以前のチェックポイントについては、モデルカードはさらに踏み込み、結果はPerplexity APIを通じて測定されたと述べている。それは公表するには正当だが、依拠するには弱いものだ。

独立した全体像のほうがより有用だ。このモデルクラス向けのオープンなコミュニティリーダーボードであるJev Decision Indexは、独自のパネルでpplx-decider-v1.1-27bを採点しており、その2026-10-14データリリースは、単一のRTX PRO 6000上で42のベンチマークにわたる採点対象110,201件のうち110,179件をこのチェックポイントが完了したと報告している。そのボードで、このモデルはバランス技能スコア62.75で6位に入り、Jevは60.11で12位となっている。ベンダーの表が示していない2つのことが、同じデータから明らかになる:

• 強みを発揮する領域。ARC-Easy 99.3、ARC-Challenge 97.0、関数呼び出しの yes/no 判定(BFCL)97.2、FinEntity 95.4、BPoMP 95.2、CLINC150 91.5。古典的な分類・検索タスクこそ、このチェックポイントが真価を発揮する領域です。

• 当てはまらない領域。Humanity's Last Exam 16.2、ChessBench 17.7、SATA-Bench 28.2、ACOS 28.2、スキーマ誘導型対話セット 33.2、BRIGHT 50.9、GPQA Diamond 56.1。難しい多段階推論は、1回の読み出しで手に入るものではない。そして、推論作業をひそかに判断モデルへ回すスタックは、自信たっぷりの誤った分岐を生み出す。

キャリブレーションには独自の行を割く価値がある。ラベルではなく確率を返すモデルでは、それが核心だからだ。独立に採点された34,829件の判断で、チェックポイントは平均76.1%の精度だったのに対し、平均信頼度は82.9%でした — 期待キャリブレーション誤差は0.071、ブライアスコアは0.335で、2.0%のケースは信頼度0.95を超えていながら依然として誤っていました。これは使えるが完璧ではない確率曲面であり、同じボード上でのJevのECE 0.074よりも測定可能なほどよくキャリブレーションされています。0.9のしきい値を設定し、それをほぼ確実とみなしているなら、その2%が設計で織り込むべき数値です。

同じハードウェアでのレイテンシは、110,000件の判断にわたって中央値104 ms、p95が835 msでした。これは、ゲーティング位置における小型言語モデルよりも決定モデルを選ぶ実用的な根拠です。予算は平均値ではなくp95なのです。

A single-column scoreboard titled 'pplx-decider — the scoreboard', with six rows: Decision Index 61.56, vendor-reported; Balanced skill 62.75, independent; Calibration ECE 0.071, independent; Median latency 104 ms across 110k decisions; Independent rank 6th with Jev 12th; Decision budget 8,192 tokens, rejects rather than truncates. A footer reads 'Vendor figure unreproduced; independent figures per the Jev Decision Index, 2026-10-14.' The OrcaRouter logo is composited in the bottom-right corner.

決断の代償

Perplexity はこれらのチェックポイント向けに、自社ホスト型の Decisions API を運用しています — POST https://api.perplexity.ai/v1/decisions。デフォルトのモデル ID は pplx-decider-v1.1-27b で、以前のチェックポイントも引き続き指定できます。その料金ページには、入力トークン 100 万あたり $0.02、出力トークンは無料、リクエストごとの料金なしと記載されており、上限は 1 リクエストあたり 128 問、262,144 入力トークン、組織ごとに 1 秒あたり 10 リクエストです。

それに対して、17 GB がダウンロードされてしまえば、ローカルパスは決定ごとにコストがかからない。チケットごとに少数の型付き質問を実行するトリアージキューにとって、その計算は自ずと決まる — そして、262,144 入力トークンというホスト型の上限は、あなたのローカルコピーが適用する制限ではないことに気づく価値がある。なぜなら、チェックポイント自体のバジェットは 8,192 だからだ。

ローカルルートが答えにならないのは、判断を取り巻くスタックの残りの部分です。これは選択肢ごとに1つの確率を返す27Bモデルであり、返信の下書きをしたり、チケットを要約したり、ツールを呼び出したりはしません。判断と執筆をひとつのキーの下で手に入れたいなら、それこそがOrcaRouterの役割です — 200以上のモデルにまたがる単一のAPIで、プロバイダーの定価をトークン単位のマークアップなしでそのまま適用、さらに判断モデルと執筆モデルを1回の呼び出しに組み合わせたいときのルーティングDSLを備えています。この話のうち2つの要素はすでにプラットフォーム上にあります。ベースチェックポイントはQwen3.8-27Bとして提供されているので、同じキーでファインチューンとその基盤を比較でき、比較対象となる参照モデルはJev 1.13として同じsystemoneエンドポイント形状で提供されています。Perplexityの判定器は当社が提供するものではありません — Perplexity自身のAPIおよびいくつかのサードパーティプラットフォームを通じて利用できます — ので、それが特に必要な場合は、上記のローカルプルとPerplexityのエンドポイントが選択肢となります。

リポジトリが答えていない3つの問い

量子化されたアーティファクト内のチェックポイントはどれですか?Ollamaライブラリのエントリは、バージョンではなくファミリー名で命名されており、そのベンチマークブロックはv1リポジトリにリンクしています — 11ベンチマークの表は85.7パーセントを示しており、これはv1カードの総合値であり、v1.1のDecision Indexスイートの値ではありません。v1.1は、Perplexity自身の集計によればより強力なチェックポイントであり、あなたがプルしているものがそれであるとは明らかではありません。その前提に基づいて構築する前に、ダイジェストを確認してください。

Perplexityはこのうちのどれかを公開するつもりだったのだろうか? これらの重みに関する発表、ブログ記事、変更履歴の項目、APIで利用可能であることの通知は一切出てきていない。チェックポイントは何千人もの人に閲覧されている——執筆時点でv1は2,740ダウンロード、v1.1は3,154ダウンロード——が、モデルカードへの注目は、ベンダーがサポートしていると明言することと同じではない。公開リポジトリを信頼すべき成果物と見なし、それ以外はすべて推測として扱うこと。

ベンダーがホストする、公式に発表されたバージョンは登場するのか?不明である。Perplexity側に文書化され、価格が設定されたDecisions APIが存在することは、ホスト型の経路が意図された製品であり、重みはその上流にあることを示唆している。しかしそれは意図に関する推測であり、文書から得られた事実ではなく、そのように明示されている。

誰が引っ越すべきで、誰が引っ越すべきでないのか

あなたのパイプラインがすでに型付きのプロバイダー判断 — チケットルーティング、返金検出、エージェントステップのゲーティング — で分岐しているなら、これは独立に再現されたスコア、Apache 2.0 ライセンス、そして今日時点で、あなたが所有するハードウェアに載せられる 17 GB の経路を備えた、2週間前のチェックポイントです。評価によれば、参照モデルよりもキャリブレーションが良く、公開ボードではおよそ2ランク上で、ローカルコピーなら判断あたりの価格が完全になくなります。取得して、自分のラベル付き例に対して実行し、今使っているものと比較してください。まず検証すべき制約は、リスティングが宣伝する 256K ではなく、8,192 トークンの判断バジェットです。

分類ではなく推論が必要なら、待つべきだ。独立した評価パネルは、このチェックポイントを難関知識ベンチマークで10%台前半と評価しており、実際には答えられない質問に対して自信を示す確率曲面は、本番環境では、まず考える遅いモデルよりも悪い。決定モデルを支持する根拠は、中央値104 msと、60問が1回のパスで済むという事実にある——だが、答えが間違っている場面では、そのどれも役に立たない。

意思決定ステップを自分のハードウェアで実行することは、このクラスでこれまでに何がうまくいかなかったかを確認するのにも良い機会です。意思決定モデルに関わる文書化されたAIインシデントやエージェント障害は、以下に収集されています:OrcaRouter AI Incident Archive。各エントリには、それぞれ独自の出典、重大度、信頼度グレード、異議フラグが付いています。