pplx-decider 对比 Decider：Perplexity 静默的 27B 对阵 Mapika 的 Open Ladder

现在 Hugging Face 上摆着两个决策模型，它们回答问题时的方式如出一辙，除此之外几乎别无一致之处。pplx-decider 是 Perplexity 于 2026-10-01 上线的一个 27B 检查点，没有公告、没有博客文章、没有定价页面，也没有任何推理服务商托管它；随后在 2026-10-05，基于同一骨干网络的修订版 pplx-decider-v1.1 接踵而至。Decider 是 Mapika 旗下同一类模型的家族——从 decider-0.8b 到 decider-35b-a3b，是 System One 谱系中的一次公开复现，并附有完整的训练笔记一并发布。两者都接收一组带名称的问题外加一份文档，并在单次前向传播中为每个答案返回一个校准后的概率。二者都不会写出一句散文。以下便是各自真正有据可查的内容，以及记录戛然而止处的明确标记。

首先，那个句子里的“决策模型”是在起什么作用？

这两者都不是那种被要求简洁作答的聊天模型。它们根本不是通常意义上的语言模型——没有解码循环，没有采样，也没有任何逐词元进行的东西。对你的文档做一次前向传播，就会为你提供的每一个选项返回一个概率。

调用的形态，正是让这种比较值得写出来的原因。你交出一个状态（一张工单、一条 JSON 记录、一张截图、一份合同），再加上一组带名称的问题。每个问题都指明自己的答案类型：在 2 到 255 个带标签的选项之间做选择，一个是/否/未知的读数，或在 2 到 10 个有描述的等级上打分。答案会按你提问的顺序返回，形式是 0 到 1 之间的数字，而这个数字应当被当作概率来读，而不是一个规整的标签——对于“是否正在申请退款？”，0.62 就是全部输出，由调用方决定阈值。

那种设计消除了延迟和成本，因为一份包含六十个问题的文档只需处理一遍，而不是六十遍。这也意味着通常评判语言模型的方式不再适用：没有可阅读的推理轨迹，没有可争辩的思维链，也无法让它解释自己。你得到的只有概率质量，别无其他。两个项目都明确表示，这就是取舍。

已发布的内容，以及没人说出口的话

pplx-decider 仓库异常完整，对于一个背后没有发布帖的模型来说。权重采用 Apache-2.0 许可。基础模型是 Qwen/Qwen3.8-27B，卡片上已说明。有一个以 bf16 发布的读出头（readout head），形状为 [255, 5120]，这正是你在 5,120 宽隐藏状态上对应 255 个可选项时所期望的形状。卡片记录了输入预算、选项上限、三种问题类型以及端点形态——POST /v1/systemone。

缺席的是发布帖通常会有的那句话。卡片上没有发布日期，没有公告，没有来自 Perplexity 的基准测试帖，没有价格，也没有第三方平台在为其提供服务。下载量属于那种你从一个被找到而非被推广的仓库里会得到的量级。把这两者放在一起读，诚实的描述是：工件是公开的，其背后的意图则不是。下面关于 pplx-decider 的一切都来自该仓库及其卡片。以下内容均未被独立复现，实验室之外也没有人发表过自己的运行结果。

Ollama 库条目让这一差距以微小方式显露出来。其页面将该标签列为 27b、17 GB，并带有 256K 上下文窗口——这是一个量化构建，远低于 bf16 权重所占的大约 49 GiB——而仓库记录的文本与图像输入预算则小得多，并表示超限输入会被拒绝，而不是被截断。这两种说法显然并非在描述同一个限制，而公开资料中没有任何内容能调和它们。请把运行时的数字视为运行时的说法。

有趣之处在于：两个陌生人，同一个界面

Mapika 的 Decider 系列和 pplx-decider 是独立开发的，基于不同的基础，出于不同的原因，却最终收敛到了同一种线路格式。Decider 模型也采用 System One 的调用形态——具名问题、在 2 到 255 个选项中选择、不生成文本、可接受的状态最多约 32k。针对其中一个编写的客户端，几乎就是另一个的客户端。

这种趋同是这项对比中有用的事实。你选哪一个并不是重写；它只是换掉一个 base URL 和一个模型字符串。有意思的问题不再是“我该集成哪个 API”，而是“在我的文档上，我该信任哪种读取结果”——而这两个项目以非常不同的方式回答这个问题。

一个检查点对梯子

结构差异是最容易看出来的。Perplexity 只推出了一个尺码。Mapika 推出了多个尺码，并公布了尺码表：

• 目录 — pplx-decider：一个 27B 检查点，外加基于同一骨干网络的 v1.1 修订版。Decider：已发布七种以上规模，从 1.4 GB 的 decider-0.8b，一直到 decider-2b、decider-2b-vision、decider-4b、decider-12b，以及 decider-35b-a3b（bf16 为 65 GB，nvfp4 为 19.6 GB）。

• 基础模型——pplx-decider：Qwen/Qwen3.8-27B，同一血统。决策器：一个混合体——小尺寸用 Qwen3.5-0.8B、Qwen3.5-2B 和 Qwen3.5-4B，大尺寸用 Qwen3.5-35B-A3B，聊天变体下则用 gemma-4-12B-it 和 gemma-4-31B-it。

• 激活 — pplx-decider：密集 27B，因此每次调用都会运行全部参数。Decider：decider-35b-a3b 是混合模型 — 总计 34.7B，在 256 个路由专家中约 3B 处于激活状态，每个 token 有 8 个专家激活。

• 视觉 — pplx-decider：多模态，仓库文档中也是如此说明的；支持文本、JSON 和图像（包括截图、收据和表单），视觉 token 的开销约为 宽 × 高 / 1024。Decider：采用单独的 decider-2b-vision 检查点，而不是在主线上加一个标志，因此图像处理是一种不同的模型选择，而不是一个不同的参数。

• 许可证——双方均为 Apache-2.0，这是本次对比中唯一平淡无奇的一点。

• 训练披露 — pplx-decider：一个基于 Bespoke Labs 的 Bespoke Nimble 构建的数据管道，基准子集通过记录 ID 和校验和固定，v1.1 的收益归功于移除因果掩码以及添加包括 tasksource 在内的数据。Decider：每个版本的说明，包含条目数量、硬件和实际耗时——decider-35b-a3b 在 4× B300 上训练了 394 分钟，处理了 1,543,567 个条目——外加具名失效模式以及实际训练的参数占比，34.7B 中的 2.45B。

这两者都不构成决定性优势。单一检查点更易于推理，更便于提供服务，并且无法缩减规模。阶梯式方案则让你可以把 decider-0.8b 放在廉价的预过滤器之后，只在真正需要它的条目上使用 35B——但前提是你愿意维护决定哪个是哪个的路由逻辑。

这些数字，以及它们是由谁产生的

两组核心数字都是由厂商自行报告的，而且都没有附带独立复现。这一点在这里比通常更重要，因为目前不存在任何具有图像或语言领域那种地位的第三方决策模型排行榜。

根据 Perplexity 自己公布的数据，pplx-decider 在 11 个公开基准测试上的成绩为 85.7%，而 Jev 为 84.5%，其训练所基于的 Qwen3.8-27B 基础模型为 74.8%。所报告的各项单独结果包括 RAGTruth 88.8、FinancialPhraseBank 84.2、TabFact 90.6、JudgeBench 78.3 和 WinoGrande 83.3，更完整的集合还涵盖 Circa、Belebele、TruthfulQA binary、BBH、ContractNLI 以及 JevBench 的一个公开困难子集。v1.1 修订版报告的套件加权总分为 61.56，而 v1 为 56.4，Jev 为 57.9，其中单项类别提升最大的是语言任务。与 Jev 的对比来自厂商，是基于厂商自有套件计算得出的，且权重并未公布。

Mapika 的报告有着不一样的质感：数字总是附带会削弱它们的限定条件。decider-35b-a3b 报告任务内成绩为 0.855、留出成绩为 0.810，而零样本基线为 0.732；在 JevBench 的公开困难划分上为 0.676——低于 Jev 1.13.0 的 0.730。模型卡还说明没有强化阶段，因此采样对局表现为 86.4%，而 decider-2b v10 为 93.2%；并指出模型在最难的条目上过度自信，困难层级的期望校准误差为 0.15。decider-2b v11 报告任务内成绩为 0.802、留出成绩为 0.752，ECE 为 0.156，而声明的发布准则为 0.08——未达标，且由作者自行写明。

有两种有据可查的失效模式，值得你在进行任何评测时都牢记在心。通过记录在长 JSON 数组中的位置来选取该记录，被描述为该系列所处理的最不准确的输入形态；而在独立标志关闭的情况下，把若干个独立问题打包进一次调用，最多会让 12% 的答案发生翻转。这两者都属于规格表会藏着不说、而说明卡只会顺带提一次的那类事。

运行其中任何一个的成本是多少

• 最小可用 Decider —— decider-0.8b 为 1.4 GB。pplx-decider 没有小型变体，因此其下限就是完整的 27B。

• 最大的 Decider — decider-35b-a3b 为 65 GB bf16 或 19.6 GB nvfp4，每个 token 仅约 3B 参数处于激活状态。

• 延迟，决策端 —— decider-2b 在 B300 上使用 CUDA graphs 时每个请求运行 4 ms，低于 eager 模式的 18.9 ms，并且在 batch 32 下每秒约完成 2,700 次决策。35B 则是另一个世界：对于带有三个问题的 92-token 工单，约需 47 ms；对于 64 个工单，则需 368 ms。

• 延迟，pplx-decider 方面——未发布任何数据。这些卡片完全没有给出吞吐量或延迟数字，这对于一个尚未上线的代码仓库来说是正常的。

• 每次决策的成本——这正是该设计在两方面都能带来回报的地方。对同一份文档提出六十个问题，无论哪种方式都只需一次前向传播，因此当你对同一份文档提出更多问题时，每次决策的成本便会大幅下降。

以下是诚实的路由情况。OrcaRouter 不提供 pplx-decider，也不提供 Mapika 的 Decider 系列——两者都不在目录中，本文中的任何内容都不应被解读为相反的宣称。如今目录中这类目下确实有的是 typesafe/jev-1.13，一个同样属于 System One 形态的决策模型，拥有 65,536 token 的窗口，通过相同的 POST /v1/systemone 端点提供，价格为每百万输入 token $0.042，这对于衡量一个经路由的决策模型成本而言是个有用的参照。如果你正在评估像 pplx-decider 这样尚未公布的检查点，要在不把生产路径押在它上面的前提下进行评估，方法就是自己运行它，同时把一个经路由的模型放在 一个 API 覆盖 200+ 模型 之后——提供商标价原样传递，0% 加价，因此当这些项目真正接入推理提供商时，标价就是这里的价格，且当天生效。在那之前，把自托管的 pplx-decider 与经路由的 typesafe/jev-1.13 放在一起比较，才是真正能告诉你一些东西的对比。

该选哪一个

如果你今天就需要一个决策模型，运行在你自己的硬件上，规模由你选择，带有可审计的训练说明，以及一个对你毫无要求的许可证，那么答案就是 Decider checkpoint，而唯一真正的问题是选哪一档。从 decider-2b 开始；v11 的数据显示，该系列在恰恰是你会关心的那个困难划分上，相比自身的 v10 有所提升，而文档中记录的 ECE 差距告诉你，在生产环境中信任这些概率之前，需要先重新拟合温度参数。

如果你想要相同的接口、但背后是更大的稠密模型；如果图像输入很重要，而你又不想再跑第二个检查点；或者如果你是那种宁愿自己评估前沿实验室的读出头、也不愿等待一篇可能永远不会出现的发布帖子的团队，那就选择 pplx-decider。它的优势真实存在，但尚未得到验证：更大的主干网络、一张对它格外有利的基准测试表，以及一条文档详细到记录级校验和的训练流水线。

真正值得关注的不是某个基准测试，而是 pplx-decider 究竟能否接入某个推理服务提供商。一个只发布了权重、却没有任何公告的代码仓库只是一个信号，而不是产品；一旦它出现在某个托管端点上，Decider 的卡片早已能回答的价格与延迟之争，才会从一种愿景变成真正的比较。

在路由决策模型旁边运行自托管的 pplx-decider，其背后依托的是以 0% 加价率直接透传的提供商标价，因此当任一项目接入推理提供商时，标价就是当天这里的价格。

对照已发布的阶梯来衡量的新检查点，也是核查过往记录的好地方：这一类模型的已记录 AI 事件与智能体故障，都汇集在the OrcaRouter AI Incident Archive，其中每条记录都带有各自的来源、严重程度、置信度评级和争议标记。