Perplexity 開源多模態決策模型 pplx-decider-v1.2 與 Flash 4B 完整解析：聯合請求架構、Decision Index 評測與快速推論指南

在建構 AI 代理（AI Agents）、客服路由、內容審核或檢索重排序（Reranking）系統時，工程團隊經常面臨一個效能瓶頸：如果為了判斷「是否需要人工介入」、「工單該分派給哪個部門」或「文章符合哪個評分等級」而呼叫傳統對話式大型語言模型（Chat LLM），不僅要承受自由文本生成的延遲與算力開銷，還必須在應用程式端撰寫複雜的正規表示式或 JSON 解析器來處理格式錯誤。

為了解決結構化決策場景的效率與機率校準問題，Perplexity 於 2026 年 10 月 16 日正式推出新一代開源多模態決策模型 perplexity-ai/pplx-decider-v1.2（27B 參數規模），並同步釋出體積僅約七分之一的輕量級蒸餾版本 perplexity-ai/pplx-decider-flash-v1.2（4B 參數規模）。兩款模型皆採用 Apache-2.0 授權協議，並於 OpenRouter 與 Vercel AI Gateway 同步上線。

本文依據 pplx-decider-v1.2 官方模型卡、pplx-decider-flash-v1.2 官方模型卡、Perplexity Decisions API 官方開發文件 與 OpenRouter 模型專頁，完整梳理這套決策模型的架構設計、聯合請求協議、基準評測數據、問題分組策略以及本地與雲端部署方式。

什麼是決策模型（Decision Model）？核心定位與三大問題型態

根據 Perplexity Decisions API 官方文件 的定義，決策模型是一類專為「軟體可直接使用的快速結構化決策」所打造的模型。它如同多模態語言模型一樣能同時讀懂自然語言文本、結構化 JSON 與圖片，但不生成任何自由對話文字或推理過程（輸出 Token 數為 0），而是直接針對開發者定義的一或多個具名問題（Named Questions），回傳經過校準的機率分佈與型別化答案。

在 pplx-decider-v1.2 中，每次請求都由一個待評估的狀態脈絡（state，支援字串、字典、列表與最高 160 萬畫素圖片）以及一組問題（questions）組成。系統支援三種標準問題型態：

透過這種設計，應用程式可以直接對模型回傳的機率設定門檻值（Thresholding）——例如當 noul >= 0.8 時自動放行代理執行資料庫操作，介於 0.4 至 0.8 時轉交人工審核，完全省去解析聊天文字的風險。

pplx-decider-v1.2 的兩大核心突破與家族規格對照

作為前代 perplexity-ai/pplx-decider-v1.1-27b 的直接繼任者，pplx-decider-v1.2 同樣基於阿里巴巴的 Qwen/Qwen3.8-27B 骨幹網路，但在底層請求協議與訓練資料配方上進行了兩項重大革新：

1. 聯合請求格式（Joint Request Format）與行內標記讀取

前代 pplx-decider-v1.1-27b 每次前向傳播（Forward Pass）只能回答單一問題，並從序列的最後一個 Token 讀取輸出。若要針對同一篇客服信件同時判斷「負責部門」、「是否緊急」與「客戶情緒」，就必須對同一段脈絡重複編碼三次。

pplx-decider-v1.2 改採全新的 joint-question-inline-readout-v1（協議版本 v3）聯合請求格式：

• 單一序列打包多題：模型在單一序列中依序讀入完整的 state，接著排列所有問題與選項。
• 專屬 <|fim_suffix|> 標記讀取：每個問題的選項後方都會放置一個特殊的 <|fim_suffix|> 標記 Token，模型直接從各個標記位置獨立讀取該題的分類結果，而非僅讀取序列末端。使用者輸入文本中的特殊字元會在分詞前被無害化處理，防止惡意提示詞注入偽造標記。
• 成本與資訊共享優勢：針對同一份 state 詢問多個問題的運算成本，幾乎與只問一個問題相當；同時，由於全注意力層採用非因果（Noncausal）雙向設計，各個問題之間還能互相參照彼此的語義。

2. 訓練資料重構、機率分佈蒸餾與模型湯（Model Souping）

• 去污基準訓練集與廣泛決策語料：部分 Jev Decision Index 評測基準附帶官方訓練分割集（Training Splits）。為了在排行榜上進行公平比較，Perplexity 團隊將這些經過嚴格測試集去污（Decontaminated）的訓練分割納入訓練，同時加入大量來自 tasksource（Damien Sileo, LREC-COLING 2024） 等結構化 NLP 任務與自有決策資料。
• 模型湯（Model Souping）權重平均：最終釋出的檢查點並非單一訓練流程的產物，而是將多個訓練批次透過權重平均（Weight Averaging）融合而成，在所有內部與外部獨立基準測試中取得最佳綜合表現。
• 輕量版 Flash 4B 全機率分佈蒸餾：同步推出的 pplx-decider-flash-v1.2 以 Qwen/Qwen3.5-4B 為基座，透過知識蒸餾直接學習 27B 教師模型在訓練請求上的完整機率分佈（Full Probability Distributions）而非單一硬標籤，以約七分之一的參數規模保留了 27B 模型絕大多數的決策與視覺能力。

Perplexity Decider 模型家族規格對照表

根據 pplx-decider-v1.2 模型卡、pplx-decider-flash-v1.2 模型卡 與 OpenRouter 定價頁面，三款模型的關鍵規格對照如下：

Decision Index 0.3 與視覺決策基準測試全解析

根據 pplx-decider-v1.2 官方模型卡 與 pplx-decider-flash-v1.2 官方模型卡 公布的 Decision Index 0.3 (public) 與 Vision Decision Index 0.3 評測結果，官方分別測試了「聯合請求模式（Joint requests，同一請求的所有問題共用單一序列）」與「單題獨立請求模式（One question per request，每個問題各自與 state 送出）」兩種呼叫方式。

在全部 37 項公開基準測試中，有 28 項基準的每個請求原本就只有 1 個問題，因此兩種模式分數完全一致；差異主要體現在包含多個問題的 9 項基準測試上：

評測數據關鍵洞察

1. 27B 旗艦版全維度大幅躍進：pplx-decider-v1.2 的 Decision Index 0.3 綜合加權總分從前代的 62.30 提升至 68.09（增加 5.79 分），其中藝術人文（Arts）大漲 8.9 分、檢索（Retrieval）提升 7.2 分、語言（Language）與工具（Tools）也雙雙成長超過 5 分；在多模態 Vision Decision Index 0.3 上同樣從 73.22 躍升至 77.43。
2. Flash 4B 展現極高性價比：僅 4B 參數的 pplx-decider-flash-v1.2 在單題模式下拿下 60.05 的綜合分數，其檢索能力（65.2）與工具呼叫能力（80.9）甚至超越了前代 27B 模型（61.2 與 79.1），視覺決策得分（72.53）也與前代 27B（73.22）極為接近。
3. 機率校準（Calibration）表現優異：在包含 1,497 道題目的開發驗證集上，套用預設溫度（1.382）後的 pplx-decider-v1.2 達到 91.3% 準確率，期望校準誤差（ECE）從未縮放前的 0.033 降至 0.014，Brier Score 為 0.134（Flash 4B 套用溫度 1.554 後準確率為 88.8%，ECE 從 0.057 降至 0.021，Brier Score 為 0.163）。在完全獨立於訓練集之外的外部決策資料集上，模型的 ECE 約為 0.05，過度自信程度明顯低於前代 v1.1。

關鍵實戰技巧：何時應該將多個問題合併（Group Questions）？

在 pplx-decider-v1.2 與 pplx-decider-flash-v1.2 的混合注意力架構中，線性注意力層（Linear-attention layers）維持因果（Causal）特性，但全注意力層（Full-attention layers）在整個請求序列上是非因果（Noncausal）的。這意味著同一請求中的每個問題不僅能看到 state，也能看到其他所有問題的內容與排列順序。

官方模型卡 透過消融實驗明確揭示：當多個問題屬於「同一個決策的不同面向」時，合併詢問會顯著提升準確率；但當多個問題是「互相競爭同一判斷的獨立候選項」時，合併詢問反而會拉低表現。

1. 多問題基準測試：合併請求（Joint）對比單題請求（Single）的分數變化

2. BEIR 文件重排序（Reranking）實測：8 篇候選合併 vs 單篇獨立評分

pplx-decider-v1.2 模型卡 進一步在 13 個 BEIR 檢索資料集上比較「每次請求打包 8 篇候選文件」與「每次請求僅放 1 篇候選文件」的 nDCG@10 差異：

• 候選文件彼此關聯、需要交叉比對時（合併更準）：在需要多跳推理的 HotpotQA 上合併提升 +2.1 分，在重複問題偵測 CQADupStack 與 Quora 上分別提升 +1.7 分 與 +0.4 分。
• 候選文件彼此獨立時（單篇略佳）：在 FiQA、NQ、MS MARCO、Climate-FEVER 上合併微幅下降 −0.2 至 −0.4 分；在 NFCorpus、SciFact、FEVER、DBpedia-Entity 上下降 −0.7 至 −1.2 分。
• 近似候選文件互相競爭同一判斷時（合併明顯退步）：在反方論點檢索 ArguAna 與疫情文獻 TREC-COVID 上，合併 8 篇分別下降 −2.8 分 與 −2.9 分（13 個資料集巨觀平均為 −0.5 分）。

3. 官方問題分組最佳實踐建議

• 27B 模型（pplx-decider-v1.2）使用準則：
  1. 強烈建議合併：針對同一個物件評估多個屬性（例如工單的部門路由 + 緊急程度 + 情緒評分）、多標籤「選出所有符合項目（Select all that apply）」、或多步驟路由決策。單一請求比拆成 $N$ 次請求便宜許多且更準確。
  2. 強烈建議拆開：對獨立候選項目進行打分排序時（例如檢索系統中的 (query, document) 配對或候選工具列表），請維持「每個請求僅放一個候選項」。如有不確定，優先選擇單一候選項一請，因為單題模式最多只比合併少約 0.4 分，但錯誤合併競爭候選項可能損失高達 3 至 4.8 分。
  3. 排序請改用 Logit Margin：在執行重排序（Reranking）時，建議呼叫 decider.logits(requests) 取得溫度縮放前的原始讀取頭 Logits，並使用 noul 問題的 true - false Logit 差值進行排序，避免轉換成機率後因趨近 1.0 而飽和同分（Saturate into ties）。
• 4B 模型（pplx-decider-flash-v1.2）使用準則：除了緊密耦合的複選題（如 SATA-Bench）或單一路由的多個步驟外，預設請一律採用「每請求一題（One question per request）」，並善用 Fast Path 自動打包機制維持低成本高吞吐。
• 注意問題順序與脈絡位置：模型看不到問題的鍵值名稱（Question IDs），但看得到問題的排列順序（問題會自動編號）。請務必將決策所需的背景資訊寫在 state 內，而不要藏在另一個問題的描述中。

底層架構與 Fast Path 極速推論引擎：單卡 GB200 吞吐量翻倍

1. 原生決策檢查點結構（Checkpoint Format）

不同於一般語言模型使用完整詞彙表的 lm_head，pplx-decider-v1.2 採用原生決策檢查點佈局：

• 由 Qwen3_5Model 骨幹網路搭配獨立的 readout.safetensors 組成（27B 版的讀取頭維度為 [255, 5120]，4B Flash 版為 [255, 2560]）。
• 每個答案代碼（A, B, … 最多 255 個選項）皆對應單一 Token，讀取頭的第 i 列直接對應 decision_config.json["token_ids"][i] 的詞彙表位置。
• 由於全注意力層為非因果設計且讀取發生在行內 <|fim_suffix|> 標記處，標準的因果推論框架（Default Causal Inference）無法直接重現此檢查點的結果，必須透過官方提供的 pplx_decider 套件或支援該協議的推論端點執行。

2. Fast Path (fast=True) 四大加速機制

為了讓高併發與大批次決策任務發揮硬體極限，官方在 pplx_decider 中內建了 Fast Path 引擎（透過 Decider.from_pretrained(..., fast=True) 啟用），結合四項底層最佳化：

1. 無填充序列打包（Padding-Free Sequence Packing）：將多個獨立請求直接串接成單一無填充序列，在單次前向傳播中處理多個請求與多個讀取標記。各請求之間保持嚴格隔離——全注意力層使用 PyTorch 2.10 原生提供的變長 FlashAttention（torch.nn.attention.varlen，無須額外編譯 flash-attn），線性注意力狀態與短卷積（Short Convolution）會在每個請求邊界重置，位置編碼與圖片的 M-RoPE 座標也會在每個請求起點歸零。
2. 全解碼層編譯與靜態分桶 CUDA Graphs：預設的 FastOptions() 會使用 torch.compile 編譯整個解碼器層，並將打包後的序列填充至靜態大小分桶（2k、4k、8k、16k 或 32k Tokens）以重播 CUDA Graphs。
3. 末層修剪（Last-Layer Pruning）：模型的最後一層解碼器僅在 <|fim_suffix|> 標記位置進行運算，完全跳過佔據絕大多數長度的 state 與題幹 Token，大幅節省計算量。
4. 選配行級 FP8 矩陣乘法（fp8=True）：將解碼器矩陣乘法量化為 Rowwise-scaled Float8（預設關閉，開啟後會就地修改載入的模型）。

3. 單卡 NVIDIA GB200 吞吐量與數值精確度實測

根據 pplx-decider-v1.2 官方模型卡 在單張 NVIDIA GB200 GPU（BF16 精度） 上的實測，Fast Path 與參考路徑（Reference Path，左填充並依長度排序批次）的輸出幾乎完全一致：在 300 個 Decision Index 請求（共 2,324 題）上，最高機率選項一致率（Argmax Agreement）達 99.8%，平均機率絕對誤差 $\vert\Delta p\vert$ 僅 0.002；在 BEIR 重排序任務上的 Spearman 等級相關係數高達 0.9988，與不同批次大小造成的 BF16 浮點數誤差處於相同量級。

以下為單卡 NVIDIA GB200 在三類工作負載下的每秒處理請求數（requests/s）對照：

(註：預設的 fast=True 採用 2k 至 32k 動態分桶，在保有靜態 32k 模式約 93% 吞吐量的同時，將單一小型請求的中位數延遲從 131 ms 降至 96 ms；若固定使用單一 32k 靜態分桶，單筆小請求需等待約 1.2 秒，因此 buckets=(32768,) 僅建議用於離線大批次處理。)

快速上手與程式碼實作指南

1. 本地端 GPU 部署（使用官方 pplx_decider 套件）

本地運行需配備 Python 3.12+ 與支援 CUDA 的 GPU（27B 模型需預留約 52 GiB 顯存空間存放 BF16 權重與工作記憶體；4B Flash 模型僅需約 9 GiB）。若要啟用 fast=True，需額外安裝 requirements-fast.txt（包含 flash-linear-attention 與 torch >= 2.10）。

import sys
from pathlib import Path
from huggingface_hub import snapshot_download

# 1. 下載檢查點（若為輕量版可改為 "perplexity-ai/pplx-decider-flash-v1.2"）
checkpoint = Path(snapshot_download("perplexity-ai/pplx-decider-v1.2"))
sys.path.insert(0, str(checkpoint / "source" / "src"))

from pplx_decider import Decider, FastOptions

# 2. 載入模型（標準參考路徑；若需高速推論可加上 fast=True 並呼叫 decider.warmup()）
decider = Decider.from_pretrained(checkpoint, device="cuda")

# 3. 單次請求同時執行分類路由（choice）、是非判斷（noul）與情緒量表評分（score）
response = decider.decide({
    "state": "My integration keeps failing with a 401 since we rotated our API key. Please help.",
    "questions": {
        "team": {
            "type": "choice",
            "instructions": "Which team should handle this request?",
            "criteria": {
                "billing": "Charges and refunds",
                "support": "Technical integration errors",
                "sales": "Questions about buying a product",
            },
        },
        "urgent": {
            "type": "noul",
            "instructions": "Is the customer blocked right now?",
        },
        "frustration": {
            "type": "score",
            "criteria": ["calm", "mildly annoyed", "frustrated", "angry"],
        },
    },
})

print("負責團隊:", response["answers"]["team"]["choice"])
print("客戶受阻機率:", response["answers"]["urgent"]["noul"])
print("情緒期望評分:", response["answers"]["frustration"]["score"])

若要在生產環境中啟用 Fast Path 進行高併發推論，建議在啟動服務時先執行 warmup() 預編譯所有分桶（約需 1 分鐘）：

from pplx_decider import Decider, FastOptions

# 線上低延遲 + 高吞吐預設模式（2k ~ 32k 動態分桶 + 末層修剪）
decider = Decider.from_pretrained(checkpoint, fast=True)
decider.warmup()

# 傳入請求列表時，背景執行緒會自動完成分詞與無填充序列打包
responses = decider.decide(requests_list)

# 若為離線超大批次處理，可指定單一 32k 靜態分桶以略過多桶編譯
decider_offline = Decider.from_pretrained(checkpoint, fast=FastOptions(buckets=(32768,)))

2. 透過雲端 Decisions API 呼叫（Perplexity 原生端點與 OpenRouter）

如果不希望自行維護 GPU 伺服器，可直接透過 Perplexity Decisions API（端點 POST /v1/decisions）或 OpenRouter Decisions API（端點 POST /api/alpha/decisions）呼叫。兩者的計費方式皆為 27B 模型每百萬輸入 Tokens $0.02 美元、4B Flash 模型每百萬輸入 Tokens $0.01 美元，且輸出 Tokens 完全免費 ($0)。

以下為使用 Python httpx 呼叫原生 API 的範例：

import os
import httpx

response = httpx.post(
    "https://api.perplexity.ai/v1/decisions",
    headers={"Authorization": f"Bearer {os.environ['PERPLEXITY_API_KEY']}"},
    json={
        "model": "pplx-decider-v1.2",
        "state": {
            "title": "Battery died after two weeks",
            "review": "The headphones sound great, but the battery stopped charging after two weeks.",
        },
        "questions": {
            "defect": {
                "type": "noul",
                "instructions": "Does the review report a product defect?",
            },
            "sentiment": {
                "type": "choice",
                "instructions": "What is the overall sentiment of the review?",
                "criteria": {
                    "positive": "Mostly satisfied",
                    "mixed": "Praise and complaints in one review",
                    "negative": "Mostly dissatisfied",
                },
            },
            "severity": {
                "type": "score",
                "instructions": "How severe is the reported problem?",
                "criteria": ["Cosmetic", "Inconvenient", "Product unusable"],
            },
        },
    },
    timeout=30.0,
)
response.raise_for_status()
answers = response.json()["answers"]
print(answers["defect"]["noul"])        # 輸出範例: 0.9424... (94.2% 機率為產品瑕疵)
print(answers["sentiment"]["choice"])   # 輸出範例: "mixed"
print(answers["severity"]["score"])     # 輸出範例: 1.7838... (介於 1 與 2 之間，偏向無法使用)

此外，若使用 Vercel AI SDK，也可直接透過 ai 套件的 experimental_decide 函數呼叫 perplexity/pplx-decider-v1.2 或 perplexity/pplx-decider-flash-v1.2。

系統限制與常見疑難排解（Troubleshooting）

根據 官方模型卡 與 API 開發文件，在實務整合時需留意以下邊界條件：

• 超長脈絡與自動遞迴切分：模型架構上限 max_length 預設為 262,144 Tokens。雖然訓練序列主要在 32K Tokens 以內，但官方實測在長達 243K Tokens 的長日誌大海撈針（Needle-in-a-Haystack）測試中，各深度正確率 $P(\text{correct})$ 皆超過 0.999（單卡 GB200 Fast Path 耗時約 2 分鐘、峰值顯存 107 GiB；4B Flash 版僅需 20 秒、峰值顯存 54 GiB）。當一個多問題請求超過 max_length 時，SDK 絕不會截斷輸入內容，而是自動將問題列表遞迴對半切分（每個分塊皆保留完整的 state 與圖片），並在 usage.sequences 回報切分數量；若單一問題加上 state 即超過上限，則會直接拋出 pplx_decider.LengthError。
• 圖片輸入尺寸規範：本地 SDK 會自動保持長寬比，將大於 1.6 MP（1,638,400 畫素）的圖片縮放至上限（每張 1.6 MP 圖片約佔用 1,600 個序列位置）。若透過雲端 Perplexity Decisions API 傳送 Base64 圖片（支援 PNG、JPEG、WebP，不支援直接傳入 http/https 網址），請確保每張圖片不超過 2,048 個 32 × 32 圖塊（例如 1440 × 1440 或 2048 × 1024），否則會觸發 504 逾時錯誤。
• 切勿混用 v1.1 提示詞模板：pplx-decider-v1.2 專為 pplx_decider 建構的聯合請求格式訓練，請勿將前代 v1.1 的單題提示詞直接餵給 v1.2，否則會導致輸出異常。

相關連結

• 官方模型主頁：https://huggingface.co/perplexity-ai/pplx-decider-v1.2