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，以 LoRA 适配器形式发布在 Qwen3.5 基础模型上，而不是完整检查点。

决定输出形态的部分与语言主干是分开的。Kev 带有一个指针头——在 fp32 下约 2.6M 参数，架在 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 的个人，动机并不相同。但当两个模型宣称取得同一类结果，而其中只有一个告诉你它的温度时，那个告诉你的，才是你这个月就能投入生产使用的。

语境考量，这正是二者分歧最大之处。

• 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：bf16 权重 51.3 GB，常驻约 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 是整条链路中最不可靠的一环；把回退流量路由到一个覆盖 200+ 模型的 API——按提供商标价透传、加价 0%——就能让这个实验不至于变成一次服务中断。而当 pplx-decider 这样的模型最终有了托管端点时，运行对照组的同一把密钥就能直接运行它，既不用签第二份合同，也不用改代码。

什么会改变答案

四件事，且这四件都是可核实的，而不是见仁见智的问题。

如果 pplx-decider 接入某家推理提供商，其未经核验的基准表就会变成一个价格与延迟的问题，文档缺口也就不再重要——你将为托管式读数付费，而不是自行维护一份。如果独立第三方在已发布的测试框架上复现任一模型的 JevBench 数值，那么整个比较就会收窄到单一套件，而不是两个互不兼容的套件。

如果 Kev 在 CUAD 上有记录的 ECE 弱点可以通过重新拟合而非重新训练来解决，那么反对它的校准论点就基本不成立了，因为 Kev 已经自带其温度参数，而且它的失效模式都是已知量。如果你需要在单卡而非双卡上运行一个决策模型，那么 pplx-decider 的 17 GB 量化版本就是这里唯一的选择——不是因为它更好，而是因为它能放得下，而 bf16 的 27B 放不下。

在上面任何一种情况发生之前，务实的判断并不光鲜。Kev 是那个你今天就能复现其数字、并且其校准有文档记录、值得信赖的一方；pplx-decider 则是那个声称上限更高、但书面记录更弱的一方。如果你这个月就要发布，选第一个。如果你所在的团队宁愿评估一次静默发布，也不愿等一篇发布公告，那就把第二个拉进同一个测试框架里。

将回退路由通过 以0%加价直接透传的供应商列表价格，可以在本地检查点成为链路中最不可靠的组件时，避免三方对比演变成故障。

三方对比评测也是一个合理的时机，用来追问这一类模型中已经出现过哪些失败：涉及决策模型的已记录 AI 事件与智能体故障，都汇集在 OrcaRouter AI 事件档案库中，其中每条记录都附有自己的来源、严重程度、置信度评级以及争议标记。