pplx-decider vs Kev：兩套系統、一款模型，你已經可以拉取

這場對決中有個有用的巧合：你今天下午就能用自己的硬體把它解決。pplx-decider 是 Perplexity 的 27B 決策模型，於 2026-10-01 無預警現身，沒有任何公告，並在 2026-10-05 推出 v1.1 修訂版，兩者都在 Ollama 函式庫上。Kev 是 Jared Palmer 的復現系列，自 v2 於 2026-09-30 登場以來就一直在 Ollama 上，涵蓋 0.5B 到 27B。它們採用相同的呼叫形式——一個狀態加上一串具名問題、一次前向傳遞、回傳一個機率、不生成文字——這表示同一套測試框架可以同時跑兩者。不同的是底下的一切：輸出如何產生、作者記錄了什麼，以及需要多少 GPU。

先從讓一場模型較勁得以成立的根本說起。兩個模型都不會生成文字。你把一份文件交給它，然後按名稱提出問題；每個問題都會宣告自己的答案類型——從 2 到 255 個有標籤的選項中擇一、是／否／未知的讀出值，或在 2 到 10 個已描述等級之間給分。答案會以機率的形式回傳，並依你提問的順序排列。一份帶有六十個問題的工單，只需對模型進行一次傳遞，而不是六十次呼叫。

每個模型實際上有多少部分真的在做決定

Kev 的模型卡對其建構方式說得十分明確，這種程度在內部文件之外相當罕見，而在你信任其中任何數字之前，這些細節值得一讀。27B 檢查點是在 Qwen/Qwen3.8-27B 上進行的全權重監督式微調，之後再進行權重平均——以 fp32 將新模型的 0.85 與 v1 的 0.15 混合。較小的尺寸，從 0.8B 到 9B，是以 Qwen3.5 基礎模型上的 LoRA 適配器形式推出，而非完整檢查點。

決定輸出如何成形的部分，與語言主幹是分開的。Kev 帶有一個指標頭——約 2.6M 個 fp32 參數，疊在 25.6B 主幹之上，構成 26B——正是它把隱藏狀態轉換成你具名選項上的機率。pplx-decider 則以一個已釋出的讀出頭 [255, 5120] 做同樣的事：在 5,120 維隱藏狀態上的 255 個選項，採用 bf16。

兩種架構，一個構想：語言模型負責讀取，小型頭部負責決定。這就是為什麼兩者都不會生成散文，也是為什麼其中一者的基準分數無法轉移到另一者，即使兩者都是以同一個參考模型作為對照。

唯一正式記錄在案的正面對決，以及為何你不能將它減去

這兩個專案都以 Jev 為基準來報告，這讓人不免想把它們並列比較。不要這麼做。

Kev 自己的評測卡上有一列 Decision Index 0.2 的數據，顯示 Kev-27B v2 為 52.3，對比 v1 的 50.2、Jev 的 54.0，以及 AutoJev-27B 的 50.0。那是一組乾淨、同一測試套件、同一版本的比較，結果顯示 Kev v2 進步了約兩分，但依然落後於 Jev。

pplx-decider 的卡片顯示，v1.1 的套件加權總分為 61.56，相較之下 v1 為 56.4，Jev 為 57.9。就他們自己的數字來看，這代表在一次修訂中提升了超過五點，並領先 Jev 超過三點半。

那兩段不能彼此相減。不同的測試套件、不同的任務組合、不同的加權方式——而且兩個專案都沒有公布加權。你能說的雖然更狹窄，卻仍然有用：兩者在同一個時間窗內朝同一個方向變動，兩者都是透過改變讀出層的訓練方式，而不是更換主幹來達成，而且 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 個問題進行了一個 epoch，標籤由 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 糟了兩到四倍；它還在自己的評估中點出選擇樂觀偏誤。pplx-decider 的 v1.1 表格顯示，工具從 79.3 下滑至 78.88，而其他每個類別都上升，但卡片對此隻字未提。

• 失效模式 — Kev 的卡片列出了污染篩檢範圍，以及其已公布數字是在哪些條件下產生的。Decider 系列，也就是 Mapika 的產品線，更進一步點名了會使其失效的特定輸入形狀；pplx-decider 對此問題則保持沉默。

這一切都不代表 pplx-decider 比較差。文件不等於能力——一個發布文還躺在草稿裡的實驗室，和一個把筆記發布到 Hugging Face 的個人，兩者的誘因並不相同。但當兩個模型都宣稱達到同一類結果，而只有其中一個告訴你它的 temperature，會告訴你的那一個，才是你這個月就能投入生產的那一個。

脈絡核算，這正是兩者分歧最劇烈之處

• Kev — 65,536 個 token 的狀態，外加每個問題至少 8,192 個 token，訓練時最高可達 32,768。在 64k 狀態下，常駐記憶體佔用量在尖峰時達到約 87.1 GB，模型時間為 9.4 秒，快取命中時為 733 毫秒，且在單一用戶端下每秒為 21.1 次請求，相較於 64 個用戶端時的 36.4。

• pplx-decider — 文字與圖像合計 8,192 個 token，過大的輸入會被拒絕，而非遭到截斷。Ollama 建置版本列出 256K 的上下文視窗，但儲存庫中沒有任何內容解釋這一點，而且這與該模型卡本身的限制並不一致。

對真實工作負載而言，那道差距是兩者之間最具決定性的單一差異。Kev 是為長狀態以及針對這些狀態提出大量問題而打造。pplx-decider 是稠密的 27B 模型，輸入預算相對較小，這使它更適合短文檔、圖像，以及能在數千個 token 內完成的提問。

• 語言 — 兩者均僅限英文，並在兩者上皆註明為限制。

• 視覺 — pplx-decider 可接受文字、JSON 與圖片，視覺 token 的成本大約是寬 × 高 / 1024，且評估設定上限為 512×512。Kev 在 27B 系列中不具備視覺能力。

• 服務下限 — Kev-27B 需要一張 80 GB 等級的 GPU：51.3 GB 的 bf16 權重、約 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 為單一尺寸，修訂過兩次。

舉辦烘焙大賽，但不為它下注

這兩個模型都能以本機權重的形式取得，而這正是路由層得以證明自身價值的典型情境。OrcaRouter 不提供 pplx-decider，也不提供 Kev——兩者都不在目錄中，此處任何內容都不應被解讀為我們託管它們的主張。我們在此類別中確實提供的是 typesafe/jev-1.13，透過相同的 POST /v1/systemone 呼叫形式暴露，價格為每百萬輸入 token $0.042，而它是天然的對照組：相同介面、相同問題類型，無需你自己的 GPU。

這樣一來，要設置三方評比就變得很便宜。把本機的 pplx-decider 和本機的 Kev 放在同一個測試框架下，對上一個經路由的 typesafe/jev-1.13，用你自己的文件為這三者評分，再讓它們之間的分歧告訴你，你的門檻實際上落在哪裡。在這種安排下，自動容錯移轉比平時更重要，因為單張卡上的本機 27B 是整條鏈中最不可靠的環節；把備援導向 一個 API 就能使用 200+ 個模型——供應商定價原樣傳遞、0% 加價——能讓這個實驗不至於變成一場服務中斷。而當像 pplx-decider 這樣的模型最終登上託管端點時，用來跑對照組的同一把金鑰就能跑它，不需要第二份合約，也不必修改程式碼。

什麼會改變答案？

四件事，而且它們全都是可查證的，而不是品味問題。

如果 pplx-decider 接觸到推論供應商，其未經驗證的基準測試表就會變成價格與延遲的取捨問題，而文件落差也不再重要——你付費換取的會是託管式讀出，而不是自行維護一份。如果有獨立第三方在已公開的測試框架上重現任一模型的 JevBench 數據，整個比較就會縮小到單一測試套件，而不是兩個互不相容的套件。

如果 Kev 在 CUAD 上已記錄的 ECE 弱點，結果證明能透過重新擬合而非重新訓練來修復，那麼反對它的校準論據大致上就會消失，因為 Kev 已經隨附它的溫度參數，而且它的失效模式都是已知量。而如果你需要在單張卡而非兩張卡上跑一個決策模型，pplx-decider 的 17 GB 量化版本是這裡唯一的選項——不是因為它更好，而是因為它裝得下，而 bf16 的 27B 裝不下。

在這些事情之一發生之前，實際的解讀並不光鮮。Kev 是那種你今天就能重現其數字、而且其校準過程可信地留有紀錄的選項；pplx-decider 則是宣稱上限更高、但書面痕跡較弱的那一個。如果你這個月就要出貨，選第一個。如果你們是那種寧可量測一次低調發布、也不願等一篇發布貼文的團隊，那就把第二個拉進同一套測試框架裡。

將備援導向以 0% 加成原樣傳遞的供應商牌價，可在本地檢查點是整條鏈路中最不可靠的環節時，避免三方評比演變成服務中斷。

三方模型評比也是一個合理的時機，可以追問這一類系統中已經有哪些失敗案例：涉及決策模型的已記錄 AI 事故與代理故障，都收錄於 OrcaRouter AI Incident Archive，其中每筆條目都附有自己的來源、嚴重程度、信心等級與爭議標記。