pplx-decider-flash vs 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 个令牌，每小时 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。

• Vision — 在 Vision 决策指数上为 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。

• 开发集准确率 — Flash 在 1,497 个问题上的准确率为 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 tokens，但训练仅验证到约 32,000 tokens，且卡片警告称更长的输入测试较少。

自托管 Flash 是这一对比中唯一让 4B 无条件胜出的版本。单张 16 GB 显卡、宽松的许可证，以及无需按 token 付费，这些使其与一个需要专门服务团队的 52 GiB 检查点成为真正不同的产品。

你可以应用的一条决策规则

• 每个州一个问题，数量很大 — Flash。价格优势确实存在，准确率损失集中在你可以分流到其他地方处理的知识类任务上。

• 每个状态两个或更多问题—— 27B。两个问题时价格持平，从三个问题起更便宜，并且在联合模式下更准确；每增加一个问题，差距就扩大。

• 知识密集型或评分标准密集型的判断——27B。知识方面 14.3 分的差距，不是更好的提示词就能弥补的。

• 检索门控与工具选择——Flash 是站得住脚的。这些方面的差距分别为 3.6 和 7.7 个百分点，而且工作负载正是该模型的设计用途。

• 设备端或单 GPU 部署 — Flash，在这一组合中没有真正的替代方案。

• 视觉——两者均可，其中 27B 领先 4.9 分；如果你已经用 27B 处理文本，把视觉任务拆分给 Flash 收益不大。

无论你最终落在分流方案的哪一边，决策器都只是流水线中成本低廉的一环。它所把关的生成环节才是花钱的地方，也正是值得优化的那一层。OrcaRouter 将 200 多款模型置于一个密钥之后，且不对提供商的标价加价，因此上游一旦降价，当天就能生效；而自动故障转移则可应对网关把请求发送到性能降级模型的情况。路由 DSL 可组合我们所服务的模型；两个 pplx-decider 检查点都不在其中，因此 Flash 与 27B 之间的分流只能放在你自己的代码里。我们目录中的托管决策器是 TypeSafe 的 Jev，即 jev-1.13 和 jev-1.14。

两家供应商均未发布该测试。

以上所有结论都是根据厂商文档做出的决定。能定论的那个测试枯燥而具体：取一千个真实请求，给它们打上标签，然后在预期阈值下分别用两个模型运行，一次只问一个问题，一次问三个问题。记录准确率、校准误差和总计入费 token。根据已公布数字作出的预测是：Flash 在单问题工作负载上凭成本胜出，而在三问题工作负载上则在成本和准确率两方面都落败。如果这一点成立，那么选择就取决于你的请求形态，而不是你的预算——进行测量的团队会选对，而所有只看价目表的人会选中那个纸面上便宜 50%、生产中却贵 50% 的模型。