Ollama 上的 pplx-decider：Perplexity 的靜默 27B 決策模型現可執行

Perplexity 發布了 pplx-decider-v1.1-27b 的權重，時間為 2026-10-05，以及它所取代的第一個檢查點，pplx-decider（repo 名稱 pplx-decider-v1-27b），於 2026-10-01。兩者都是 Qwen3.8-27B 的微調版本，會以機率而非句子作答，而且兩者與 TypeSafe 的 Jev 1.13 同屬 System One 血統。新穎之處不在於模型：截至今日，pplx-decider 是 Ollama 自家模型庫中的一項條目，可用一行指令安裝。在那份清單出現之前，要執行這個檢查點，意味著需要一張 CUDA GPU，並有大約 49 GiB 的 bf16 權重空間。現在，它是在筆記型電腦上一個 17 GB 的量化下載。這項單一改變就是本頁要談的主題，而它讓變得可執行的模型已有十四天之久。

具體來說，有什麼改變

Ollama 模型庫中的項目名為pplx-decider，而該模型庫整個秋天以來持續收錄決策模型——Laya、Nimble、Kev、Clef、Strands Decider。這個是最新加入的，且在維護中的登錄檔上，它顯示三個標籤（pplx-decider:latest、pplx-decider:27b 與 pplx-decider:27b-q4_K_M），這些標籤都解析到相同的 manifest 摘要。單一構件，而非尺寸階梯。

• 格式 — 由 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 提出是非題、標籤選擇或評分規準分數。那個版本才推出三天；而它讓使用變得更便利的模型則已推出兩週。

儲存庫實際上記錄了什麼

這個檢查點不是搭配簡短提示的聊天模型。它的卡片描述了一種原生決策佈局：以發布類別名稱呈現的 Qwen3.8-27B 主幹，外加一個獨立的 readout.safetensors，內含 bf16 [255, 5120] 決策頭 —— 這是對選項槽進行的 255 路讀出，而不是全詞彙語言頭。沒有解碼迴圈。每個問題的每個選項都在一次前向傳遞中完成評分，這就是回應回報零輸出符元的原因。

卡片中有三個細節比基準測試表更重要，因為它們正是讓樸素整合失敗的關鍵：

• 注意力模式。全注意力層使用已儲存的非因果模式，而模型卡直白指出，預設的因果推論並無法重現受評估的設定。若以現成的因果載入器啟動該檢查點，你得到的數字不會是已公布的那些。

• 校準溫度。 所提供的 DecisionModel.predict 會套用已儲存的溫度。若你直接讀取 logits，請確切只套用一次——套用兩次，或完全不套用，都會使你後續據以分支的每一個機率值尺度錯誤。

• 真正的決策限制。 單一決策的文字與所有圖片必須容納於 8,192 個 token 的預算內，超出上限的輸入會被拒絕，而非遭到截斷。訓練與報告中的評估都將圖片上限設為 512×512；現在可透過 max_image_pixels 調高上限，預設值為 2048×2048，但卡片警告，更高的解析度不在訓練分布範圍內。

對於一個無人宣佈的模型來說，這個儲存庫在其他方面異常完整：十一個 safetensors 分片、一個 decision_config.json、一個聊天範本，以及一個 release-manifest.json，記錄了檔案校驗和與檢查點來源。授權條款為 Apache 2.0。

文件有兩處內容已經出現落差。v1.1 卡片仍要求你向「這個私有儲存庫」進行驗證——但該儲存庫如今已可公開讀取。而較舊的 v1 卡片帶有指向 v1.1 的 new_version 指標，這正是 v1 已被取代的誠實訊號。

在圍繞它做規劃之前，唯一要先確認的一件事

Ollama 的列表頁面標示了 256K 的上下文視窗。那個數字似乎是承襲自基礎模型——Qwen3.8-27B 確實帶有 262,144 個位置——而且它不是決策檢查點為自身記錄的合約。該檢查點會拒絕任何文字加圖片超過 8,192 個 token 的決策。若以 256K 規劃一條管線，餵給它一份 40,000 token 的合約加上四張頁面圖片，請求會失敗，而不是被縮減。較大的數字描述的是架構；較小的數字描述的則是你實際呼叫的 API。

圖像支援也有類似的邊緣情況。pplx-decider 的 Ollama 模型卡顯示了對 /v1/systemone 的圖像請求，但 Ollama 本身針對該端點的功能頁面卻指出圖像「僅限 Clef 模型」。這兩份文件中有一份已經過時。在你親自執行過之前，請將這條路徑上的多模態輸入視為未經驗證——底層檢查點顯然接受圖像，manifest 也顯然隨附投影器，但執行環境所記載的閘門比模型卡所暗示的更狹窄。

一個廠商編號，以及一個不同的號碼

Perplexity 自己針對 v1.1 檢查點所做的評估回報，Decision Index 為 61.56，相較於 Jev 在同一套測試套件上的 57.9，以及它所取代的檢查點的 56.4；其中增幅最大的類別是語言（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 的平衡技能分數，排名第六，而 Jev 以 60.11 排名第十二。同一份資料還顯示出兩件廠商表格未呈現的事：

• 它的強項在哪裡。ARC-Easy 99.3、ARC-Challenge 97.0、函式呼叫是／否判斷（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。艱難的多步推理並非單次讀出所能換得，而一個默默把推理工作導向決策模型的堆疊，只會產出信心滿滿的錯誤分支。

校準值得獨立成行，因為這正是回傳機率而非標籤的模型的重點所在。在 34,829 個獨立評分的決策上，該檢查點的平均準確率為 76.1%，而平均信心度為 82.9%——期望校準誤差為 0.071，Brier 分數為 0.335，其中 2.0% 的案例信心度高於 0.95 卻仍然錯誤。這是一個可用但並非完美的機率曲面，而且在同一個評測板上，它的校準明顯優於 Jev 的 0.074 ECE。如果你設定 0.9 的閾值並把它當作近乎確定，那麼那 2% 就是你在設計時必須納入考量的數字。

在相同硬體上，110,000 次決策的延遲中位數為 104 毫秒、p95 為 835 毫秒，這正是以決策模型取代居於閘控位置的小型語言模型的實務論據：真正該看的是 p95，而不是平均值。

一個決定的代價

Perplexity 為這些檢查點運行自家託管的 Decisions API——POST https://api.perplexity.ai/v1/decisions，預設模型 ID 為 pplx-decider-v1.1-27b，而較早的檢查點仍可存取。該定價頁面列出每百萬輸入 token 0.02 美元、輸出 token 免費，且不收每次請求費用，上限為每次請求 128 個問題、262,144 個輸入 token，以及每個組織每秒 10 次請求。

相較之下，一旦那 17 GB 到位，本地路徑每次決策都不花任何成本。對於每張工單執行少量具型別問題的分流佇列來說，這道算術會自行得出結論——而且值得注意，託管服務的 262,144 個輸入 token 上限，並不是你的本地副本會強制執行的限制，因為檢查點本身的預算是 8,192。

本地路徑不是答案的地方，在於決策周遭其餘的技術堆疊。這是一個 27B 模型，每個選項只回傳一個機率；它不會起草回覆、摘要工單或呼叫工具。如果你想要用一把金鑰同時搞定決策與撰寫，那正是 OrcaRouter 的用途——一套 API 橫跨 200 多個模型，以供應商定價原價轉供，不收取任何按 token 計價的加價，另外當你想把決策模型與撰寫模型組成單一次呼叫時，還有路由 DSL可用。這個特定故事的其中兩塊已經在平台上：基礎檢查點以 Qwen3.8-27B 提供服務，因此你可以在同一把金鑰上，將微調版本與它自己的基礎版本互相比較；而用來衡量它的參考模型則以 Jev 1.13 透過同一個 systemone 端點形式提供服務。Perplexity 的決策器並非我們所提供的項目——它可透過 Perplexity 自家的 API 以及數個第三方平台取得——所以如果你特別需要它，前述的本地拉取與 Perplexity 的端點就是你的途徑。

儲存庫沒有回答的三個問題

量化產物裡是哪個檢查點？Ollama 函式庫中的條目是以系列命名，而非某個版本，而它的基準測試區塊連結的是v1儲存庫——那張 11 項基準測試表顯示 85.7%，這是 v1 模型卡的整體數字，而非 v1.1 的 Decision Index 測試套件。按 Perplexity 自家的說法，v1.1 才是較強的檢查點，而它未必就是你正在拉取的那個。在你依據這個假設展開建置之前，先檢查雜湊摘要。

Perplexity 究竟是否有意讓這一切公開？針對這些權重，至今沒有出現任何公告、部落格文章、更新日誌項目或 API 可用性通知。這些檢查點已被數千人閱覽——撰寫本文時，v1 有 2,740 次下載，v1.1 有 3,154 次——但模型卡上的關注並不等同於供應商表示其受到支援。請將公開儲存庫視為權威產物，其餘一切則視為推論。

是否會推出由供應商託管、正式對外宣布的版本？未知。Perplexity 端存在一份有文件記載、標有價格的 Decisions API，這顯示託管路線才是預定的產品，而權重則位於其上游。但這是對意圖的猜測，並非來自文件的事實，而且已標明為猜測。

誰應該搬家，誰不應該

如果你的管線已經會依據有型別的供應商決策進行分支——例如工單路由、退款偵測、代理步驟閘控——這是一個已發布兩週的檢查點，分數可獨立重現，採用 Apache 2.0 授權，而且截至今日，有一條 17 GB 的路徑可部署到你擁有的硬體上。這份評估顯示，它比參考模型校準得更好，在公開排行榜上大約高出兩個名次，而本地副本則完全消除了每次決策的費用。把它拉下來，用你自己標註的範例跑一遍，並和你現在使用的任何方案比較。首先該拿來測試的限制是 8,192 個 token 的決策預算，而不是上架資訊所宣傳的 256K。

如果你需要的是推理而非分類，那就再等等。獨立評測小組在困難知識基準測試上，把這個檢查點評在十幾個百分點的低段；而一個對自己其實答不出來的問題仍表現得信心十足的機率曲面，在生產環境中比一個先思考的慢速模型還糟。支持決策模型的理由，在於 104 毫秒的中位數，以及六十道問題只需跑一次——但只要答案錯了，這些都無濟於事。

在自己的硬體上執行決策步驟時，也是檢視這類系統已出過哪些問題的好時機：涉及決策模型的已記錄 AI 事件與代理程式失效案例，都收錄在OrcaRouter AI Incident Archive，其中每個條目都附有自己的來源、嚴重程度、信心等級與爭議旗標。