pplx-decider 對決 Decider：Perplexity 的無聲 27B 對上 Mapika 的開放階梯

目前有兩個決策模型正置於 Hugging Face 上，它們以相同方式回答問題，除此之外幾乎毫無共識。pplx-decider 是 Perplexity 的 27B 檢查點，於 2026-10-01 上線，既沒有公告、沒有部落格文章、沒有定價頁面，也沒有任何推論供應商提供它；其修訂版 pplx-decider-v1.1 於 2026-10-05 接續推出，使用相同骨幹。Decider 是 Mapika 的同類模型系列——從 decider-0.8b 到 decider-35b-a3b，是 System One 譜系中的開放復現，並隨完整訓練筆記一併發布。兩者都接收一組具名問題加上一份文件，並在一次前向傳遞中，為每個答案回傳經過校準的機率。兩者都不會寫出任何一句散文。以下內容是各自實際有紀錄可查的部分，並在紀錄終止之處清楚標示。

首先，那句話裡的「decision model」是在做什麼

這兩者都不是被要求要簡潔的聊天模型。就通常意義而言，它們根本不是語言模型——沒有解碼迴圈，沒有取樣，沒有逐詞元之類的任何東西。對你的文件進行一次前向傳遞，就會為你提供的每個選項回傳一個機率。

這個呼叫的結構，正是讓這樣的比較值得寫下來的原因。你交出一份狀態（一張工單、一筆 JSON 紀錄、一張螢幕截圖、一份合約），以及一串具名問題。每個問題都會指明自己的答案型別：從 2 到 255 個帶標籤的選項中擇一、是／否／未知的讀數，或是在 2 到 10 個各有描述的等級上給一個分數。答案會依你提問的順序回傳，形式是 0 到 1 之間的數字，而這個數字應該被解讀為機率，而不是一個乾淨俐落的標籤——「是否正在要求退款？」得到 0.62 就是全部的輸出，至於門檻則由呼叫端自行決定。

那樣的設計能消除延遲與成本，因為一份含有六十個問題的文件只需一次處理，而不是六十次。這也意味著評判語言模型的常見方式都不適用：沒有推理軌跡可讀，沒有思維鏈可爭論，也沒有辦法請它解釋自己。你得到的只有機率質量，別無其他。兩個專案都明確表示，這就是取捨。

已經推出了什麼，以及沒有人說出口的事

以一個背後沒有發布貼文的模型來說，pplx-decider 儲存庫異常完整。權重採用 Apache-2.0。基礎模型是 Qwen/Qwen3.8-27B，模型卡上有註明。有一個以 bf16 發布的讀出頭，尺寸為 [255, 5120]，這正是在 5,120 維隱藏狀態上對應 255 個可選選項時會預期的形狀。模型卡記載了輸入預算、選項上限、三種問題類型，以及端點形狀——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」，而變成「我在我的文件上要信任哪一種判讀結果」——而這兩個專案以非常不同的方式回答這個問題。

一個檢查點對比一把梯子

結構上的差異是最容易看出來的。Perplexity 只推出單一尺寸。Mapika 則推出了一系列尺寸，並公布了尺寸表：

• 目錄 — pplx-decider：一個 27B 檢查點，外加同一骨幹上的 v1.1 修訂版。Decider：七種以上已發布的尺寸，從 1.4 GB 的 decider-0.8b 起，一路到 decider-2b、decider-2b-vision、decider-4b、decider-12b，以及 bf16 為 65 GB 或 nvfp4 為 19.6 GB 的 decider-35b-a3b。

• 基礎模型 — pplx-decider：Qwen/Qwen3.8-27B，單一譜系。Decider：混合組合 — 小尺寸採用 Qwen3.5-0.8B、Qwen3.5-2B 與 Qwen3.5-4B，大尺寸則為 Qwen3.5-35B-A3B，而聊天變體下則有 gemma-4-12B 與 gemma-4-31B-it。

• 啟用 — pplx-decider：稠密 27B，因此每次呼叫時每個參數都會執行。Decider：decider-35b-a3b 是混合式模型 — 總計 34.7B，其中約 3B 為活躍參數，分佈於 256 個路由專家，每個 token 有 8 個專家生效。

• 視覺 — pplx-decider：多模態，而儲存庫本身也如此標示；文字、JSON 與圖片（包含螢幕截圖、收據與表單），而視覺 token 的成本大約是寬 × 高 / 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.855 與留出 0.810，對照 0.732 的零樣本基準，並在 JevBench 的公開困難分割上為 0.676——低於 Jev 1.13.0 的 0.730。模型卡也指出沒有強化階段，因此抽樣對局落在 86.4%，對比 decider-2b v10 的 93.2%，且該模型在最難的項目上過度自信，困難層級的期望校準誤差為 0.15。decider-2b v11 被回報為任務內 0.802 與留出 0.752，ECE 為 0.156，對照所述發布指引 0.08——未達標，由作者印出。

有兩種有文件記載的失效模式，值得納入你執行的任何評估。依記錄在長 JSON 陣列中的位置來選取它，被描述為該系列所處理的最不準確輸入形狀；而當 independent 旗標關閉時，把數個獨立問題打包進一次呼叫，可能使多達 12% 的答案翻轉。這兩者都是規格表會隱藏、而卡片只提一次的那種事。

運行其中任何一個的成本

• 最小可用的 Decider — decider-0.8b 為 1.4 GB。pplx-decider 沒有小型變體，因此其下限就是完整的 27B。

• 最大的 Decider — decider-35b-a3b 在 65 GB bf16 或 19.6 GB nvfp4 下，每個 token 僅約有 3B 個參數處於啟用狀態。

• 延遲，Decider 端 —— decider-2b 在 B300 上使用 CUDA graphs 時，每個請求為 4 毫秒，低於 eager 模式的 18.9 毫秒，且在批次大小 32 下每秒約有 2,700 次決策。35B 則是另一個世界：一張包含三個問題的 92 個 token 工單約需 47 毫秒，64 張工單則需 368 毫秒。

• 延遲，pplx-decider 端——未公佈任何數據。這些卡片完全沒有提供任何吞吐量或延遲數據，而這對一個尚未推出的儲存庫來說很正常。

• 每次決策的成本 —— 這正是此設計在兩方面都能帶來回報的地方。對同一份文件提出六十個問題，無論哪種方式都只需要一次前向傳遞，因此當你對同一份文件提出越多問題時，每次決策的成本就會隨之驟降。

以下是誠實的路由情況。OrcaRouter 不提供 pplx-decider，也不提供 Mapika 的 Decider 系列——兩者都沒有出現在目錄中，本文中沒有任何內容應被解讀為相反的聲明。這個目錄今天在此類別中確實有的是 typesafe/jev-1.13，一個同樣屬於 System One 型態的決策模型，具有 65,536-token 視窗，並透過相同的 POST /v1/systemone 端點提供，價格為每百萬輸入 token $0.042，這對於經路由的決策模型成本來說是有用的錨點。如果你正在評估像 pplx-decider 這樣未公布的檢查點，要在不把正式營運路徑押在它身上的前提下做到這點，做法就是自己跑它，並與一個經路由的模型並行，置於一個 API 支援 200+ 個模型之後——供應商標價以 0% 加價原樣傳遞，所以當這些專案真的接觸到推論供應商時，這裡的標價當天就是那個價格。在那之前，把自行託管的 pplx-decider 放在經路由的 typesafe/jev-1.13 旁邊，才是真正能告訴你一些事情的比較。

該選哪一個

如果你今天就需要一個決策模型，在你自己的硬體上、以你選擇的規模，附上可供你稽核的訓練筆記，以及一款對你毫無要求的授權條款，那麼答案就是 Decider 檢查點，而唯一真正的問題是要選哪一階。從 decider-2b 開始；v11 的數字顯示，這個系列在正是你會在意的那個困難切分上，相較於它自己的 v10 有所進步，而文件記載的 ECE 落差則告訴你，在生產環境中信任這些機率之前，要先重新擬合一個溫度參數。

如果你想要相同的介面，但背後是更大的稠密模型；如果圖像輸入很重要，而你寧可不要跑第二個檢查點；或者如果你是那種寧可自己評估前沿實驗室的讀出頭，也不願等待一篇可能永遠不會出現的發布貼文的團隊，那就選擇 pplx-decider。它的優勢真實但未經證實：更大的骨幹、一份對它有利的基準測試表，以及一套訓練管線，其文件記錄細到紀錄層級校驗和。

值得關注的不是基準測試，而是 pplx-decider 究竟能不能觸及推論供應商。一個有權重卻沒有公告的儲存庫是訊號，不是產品；當它出現在託管端點的那一刻，Decider 的卡片已經能回答的價格對延遲問題，就會成為真正的比較，而不是一種願景。

在一個路由決策模型旁執行自架的 pplx-decider，該模型背後的依據是以 0% 加成率直接傳遞的供應商標價，因此當任一專案連上推論供應商時，標示價格就是這裡當天的價格。

以公開評比階梯來衡量新的檢查點，也是查核紀錄的好地方：OrcaRouter AI Incident Archive收錄了與此類模型相關且已有紀錄的 AI 事故與代理程式失效，其中每筆條目都附有自己的來源、嚴重程度、信心等級與爭議旗標。