{{1}}pplx-decider{{/1}} 登陆 Ollama：Perplexity 悄然发布的 27B 决策模型现已可运行

Perplexity 发布了 pplx-decider-v1.1-27b 的权重，发布日期为 2026-10-05，以及它取代的第一个检查点，pplx-decider（仓库名 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），它们都解析到同一个清单摘要。单一产物，而非尺寸阶梯。

• 格式 — 由 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 模型做了扩展。如今它还新增了命令行前端：v0.40.4（发布于 2026-10-12）为 ollama run 加入了决策模型，因此可以直接在终端中用 --ask、--choice 和 --level 提出是非题、标签选择或评分标准打分。那个版本才发布三天；而它使之变得便捷的那个模型，已经面世两周了。

仓库实际上记录了什么

该检查点并非带有简洁提示词的聊天模型。它的卡片描述了一种原生决策布局：以已发布类别名称表示的 Qwen3.8-27B 主干，外加一个单独的 readout.safetensors，其中存放着 bf16 [255, 5120] 决策头——即针对各选项槽位的 255 路读出，而非全词表语言头。这里没有解码循环。每个问题的每个选项都在一次前向传播中完成打分，这正是响应报告输出 token 数为零的原因。

卡里的三个细节比基准测试表更重要，因为它们正是让简单集成失败的原因：

• 注意力模式。全注意力层使用的是保存下来的非因果模式，而模型卡直言：默认的因果推理无法复现所评估的那套配置。用现成的因果加载器启动该检查点，得到的数值就不是已公布的那些。

• 校准温度。提供的 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 模型”。这两份文档中有一份已经过时。在你自己运行过之前，应将这条路径上的多模态输入视为未经验证——底层检查点显然能接收图像，清单也显然随附了投影器，但运行时文档记载的准入条件比模型卡所暗示的更窄。

供应商编号，以及一个不同的编号

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。同一份数据还揭示出两件厂商没有展示的事情：

• 它的强项所在。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中，其中每一条目都带有自己的来源、严重程度、置信度等级以及争议标记。