pplx-decider-flash 與 pplx-decider：4B 比較便宜，直到你問三個問題為止

在價目表上，pplx-decider-flash-v1.2的價格是pplx-decider-v1.2的一半：每百萬輸入 token 為 $0.01，對比 $0.02。按照計費規則，這項折扣恰好只維持一個問題。對同一個狀態問兩個問題，兩個模型的費用就相同。問三個問題時，4B 模型反而更貴，因為 Flash 每問一個問題就會再次對該狀態計費，而 27B 只計費一次。只有當你一次只問它一個小問題時，較便宜的模型才真的比較便宜。

這種反轉是這項比較中有價值的地方。其餘則是熟悉的規模取捨：一個 4B 檢查點在延遲與記憶體上勝過一個 260 億參數模型，而後者在準確度上勝出；兩者都在相同的 Apache-2.0 授權條款與相同的 262,144 個 token 預設上下文下提供。

兩個檢查點，一次發佈，不同任務

Perplexity 於 2026 年 10 月 15 日同時發布兩者：大型模型於 UTC 07:40 發布，Flash 則於 16:57 發布。兩者採用相同設計：以 Qwen 為主幹、以 255 路讀出頭取代語言模型頭、非因果全注意力層，以及預先儲存的校準溫度。但兩者不共用主幹。pplx-decider-v1.2以 Qwen3.8-27B 為基礎建構，BF16 版本約 52 GiB。pplx-decider-flash-v1.2以 Qwen3.5-4B 為基礎建構，約 9 GiB。

命名比數字來得寬鬆。大型模型以 27B 販售，但它自己的模型卡在 BF16 下寫的是 26B。Flash 在 API 文件中以 4B 販售，而其模型卡標頭在 BF16 下寫的是 5B，且其主幹是 4B 模型。這兩個差異都不會改變部署決策；但在容量規劃中引用參數數量之前，兩者都值得了解。

價目表，星號之前

• 輸入價格 — pplx-decider-flash-v1.2 每百萬個 token 為 $0.01，對比 pplx-decider-v1.2 的 $0.02。

• 輸出價格 — 兩者皆免費，且不收取按請求費用。每個問題僅在帳務核算時計為一個輸出 token。

• 速率限制 — 每分鐘 4,000,000 個 token、每小時 240,000,000 個，且在組織層級共用每秒 10 次請求的上限，兩款模型皆包含在內。

• 別名 — pplx-decider-flash-latest 和 pplx-decider-latest 都會指向最新版本，因此針對某一版本調校的閾值，可能會在不知不覺間套用到另一個版本上。

那個星號並沒有被藏起來。Perplexity 的文件明確指出，Flash 是為每次請求只處理一個問題而設計；送出多個問題會產生彼此獨立、互不干擾的答案，而且每個問題都會再就該狀態計費一次。它甚至還示範了這個例子：在一個 10,000 個 token 的狀態上問三個問題，大約會花費 30,000 個輸入 token。

第二個問題會抹除折扣的地方

一般形式很簡單。對於一個有 s 個 token 和 q 個問題的狀態，Flash 的成本為 q × s × 每百萬 $0.01，而 27B 的成本為 s × 每百萬 $0.02。Flash 的費用會在第三個問題時超過大型模型。

• 一個問題，10,000 個 token 的狀態 —— Flash $0.0001 對比 27B $0.0002。Flash 以一半成本勝出。

• 兩個問題，同一狀態 — Flash $0.0002 對 27B $0.0002。平手，不是折扣。

• 三個問題 — Flash $0.0003 對比 27B $0.0002。4B 貴了 50%。

• 五個問題 — Flash $0.0005 對比 27B $0.0002。4B 的價格是兩倍半。

以絕對值來看，這些只是幾分之一美分，這就是為什麼這條規則容易被忽略，也是為什麼它會在大規模時複合放大。一個閘門針對 10,000 token 的狀態執行一百萬次三問題請求，在 Flash 上約花費 $300，在 27B 上約花費 $200。看似便宜 50% 的模型，在批次處理通常會是一項最佳化的工作負載下，實際上卻貴了 50%。

Perplexity 的文件指出，當問題達三個以上時，較大的模型「通常比 Flash 便宜」。確切的交叉點是兩個。如果你的問題確實彼此耦合——也就是同一個決策中「可複選」的各個面向——那麼聯合路徑也是準確的做法。如果它們是彼此獨立的候選項評分，文件建議將其拆成個別請求，這會進一步推高 Flash 的費用，而 27B 的費用則保持不變。

準確度差距，逐類別檢視

兩個模型都以 Decision Index 0.3 評分，這是 Perplexity 自家的綜合指標。主要數字是：Flash 每次請求一題時為 60.05，而 27B 使用合併請求時為 68.09。類別細分以合併執行對合併執行相比，顯示出 9.2 分的合併執行差距從何而來。

• 知識 — 42.0 對 56.3。14.3 分的差距，而這點應該會決定大多數部署的選擇。如果問題需要的是知道某件事，而不是評判某件事，那麼 4B 並非替代方案。

• 語言 — 63.3 對 72.8。

• 檢索——64.8 對 68.4。差距最窄，僅 3.6 分。判斷某段文字是否支持某項主張，正是 Flash 專為之打造的任務，而數字也反映了這一點。

• 工具 — 76.7 對 84.4。就絕對值而言，兩個模型在此都最強，這符合路由使用情境。

• 文科 — 46.8 對 56.2。

• 視覺 — 在視覺決策指數上為 72.53 對 77.43，4.9 點的差距小於文字項目的差距，使 Flash 在圖像上比在純文字上更具競爭力。

上述每一個數字都適用一項顯而易見的提醒：這項基準屬於廠商，且尚無第三方重現。27B 的模型卡指出，訓練工作包含數項 Decision Index 任務的官方訓練分割，並已針對測試集進行去汙染；這是廠商聲明的做法，而非經稽核的做法。請將類別輪廓視為關於各模型強項所在的假設——27B 強於知識與藝術，兩者皆強於檢索與工具——而非實測結果。

聯合請求的不對稱性

將問題分組對大型模型有幫助，卻對小型模型有害，而 Perplexity 自己的數據也證實了這一點。

• pplx-decider-v1.2 — 每次請求聯合為 68.09，單獨為 67.75。分組增加了 0.34 分。

• pplx-decider-flash-v1.2 — 聯合處理為 58.88，相較於每個請求各自處理的 60.05。分組合併會損失 1.17 分。

文件說明了這個機制：4B 在同時回答多個問題時會損失準確度，因此每次請求只問一個問題是建議的預設做法。這些數字補充的是，這種損失大到會反映在整體分數上，而不只是出現在邊緣案例中。這款模型以單次處理速度作為賣點，但在不使用單次處理時表現更好。如果你為了追求吞吐量仍然將問題分組，你等於為速度付了兩次代價——一次在 token 上，一次在準確度上。

校準：比準確率差距所暗示的更接近

兩張卡都誠實公布校準結果，這種做法相當罕見，值得一提。

• 已儲存的溫度 — Flash 上為 1.554，27B 上為 1.382。

• 開發集準確率 — 在 1,497 個問題上，Flash 為 88.8%，而 27B 為 91.3%。

• 溫度調整後的期望校準誤差 — Flash 為 0.021，27B 則為 0.014。

• Brier 分數 — 0.163 對 0.134。

Flash 的準確度較低，校準也較差，這在以七分之一規模運行時是預期之中的；但校準差距只有 0.007 ECE——小到在 27B 上調整出的閾值往往可以沿用。27B 的模型卡也坦承，留出的決策資料仍有些過度自信，ECE 約為 0.05，因此這兩個模型都不能取代在你自己的資料上擬合閾值。Perplexity 的文件正是這麼說的：在你預期的閾值下，用有標籤資料對兩者進行基準測試，並且只有在 Flash 達到你的準確度目標時才保留它。

自架主機：9 GiB 對比 52 GiB

兩者皆採用 Apache-2.0，因此託管價格只是提供便利，而非造成鎖定。硬體差異是它們之間最鮮明的分野。

• 權重 — Flash 約 9 GiB BF16，27B 則約 52 GiB，兩者還需額外的工作記憶體。

• 硬體 — Flash 可放進 16 GB 的消費級顯示卡；27B 則需要專業級加速器，或以多 GPU 拆分執行。

• 服務——兩者都無法原封不動地套用到現成的因果伺服器上。全注意力層以非因果方式運作，而為 v1.1 撰寫的提示也無法沿用。

• 上下文 — 兩者預設皆為 262,144 個 token，但訓練僅驗證至約 32,000，且規格卡警告較長輸入的測試較少。

自行託管 Flash 是這項比較中唯一讓 4B 無條件勝出的版本。單張 16 GB 顯示卡、寬鬆的授權，以及沒有按 token 計費的帳單，與需要一個服務團隊的 52 GiB 檢查點相比，是真正不同的產品。

你可以套用的決策規則

• 每州一題，高用量 — Flash。價格優勢確實存在，而準確度損失集中在可改派到其他地方的知識型任務上。

• 每州兩題或以上 — 27B。兩題時價格打平，三題起更便宜，且在聯合模式下更準確；每增加一題，差距就擴大。

• 知識密集或評分規準密集的判斷——27B。知識上 14.3 分的落後，不是更好的提示詞就能彌補的。

• 檢索閘控與工具選擇 — Flash 站得住腳。那裡的差距是 3.6 與 7.7 個百分點，而這項工作負載正是該模型專為打造的情境。

• 裝置端或單一 GPU 部署 — Flash，在這組配對中沒有真正的替代方案。

• Vision — 兩者皆可，27B 領先 4.9 分；如果你已經用 27B 處理文字，將視覺拆分給 Flash 帶來的效益不大。

無論你最後落在拆分中的哪一邊，決策器都只是整條流程中便宜的部分。它所把關的生成才是資金流向所在，而那也正是值得最佳化的環節。OrcaRouter 將200 多個模型置於同一把金鑰之後，對供應商標價不加價，因此上游降價當天就會反映，而自動容錯移轉可涵蓋閘門將請求送往已降級模型的情況。路由 DSL 可組合我們所供應的模型；兩個 pplx-decider 檢查點都不在其中，所以 Flash 對 27B 的拆分必須存在於你自己的程式碼中。我們型錄中的託管決策器是 TypeSafe 的 Jev，即 jev-1.13 與 jev-1.14。

兩家廠商都尚未公布這項測試

上述一切是根據供應商文件所做的決定。能定案的測試既枯燥又具體：取一千個真實請求，替它們加上標籤，並在你打算採用的門檻下，分別以單一問題和三個問題的形式跑這兩個模型。記錄準確率、校準誤差與總計費 token 數。根據已公布數字的預測是，Flash 在單一問題工作負載上以成本勝出，但在三個問題的工作負載上則在成本與準確率兩方面都落敗。如果這成立，選擇取決於你的請求型態，而不是你的預算——量測它的團隊會選對，而所有只看價目表的人會選到帳面上便宜 50%、在生產環境中卻貴 50% 的模型。