Ollama 引入 pplx-decider：27B 决策模型的本地用法

Ollama v0.40.7 把 Perplexity 的 pplx-decider 带进了本地模型列表。这可能是很多人第一次在本地接触"决策模型"这个品类——它和聊天模型是两回事，用法也完全不一样。这篇讲清它是什么、和普通模型差在哪、本地怎么跑、值不值得引入。

它不生成文本

判断写进第一句：pplx-decider 是一个只打分、不生成的模型，你给它状态和一组问题，它在一次前向里返回每个选项的校准概率。

它是 Perplexity 从 Qwen3.8-27B fine-tune 出来的 27B 决策模型，支持文本、JSON 和图片（截图、收据、表单）输入，256K 上下文，体积 17GB，Apache 2.0。用法的核心是一对概念：state 是你要判断的内容，questions 是你要它回答的一组带类型的问题。它把每个问题、每个选项一起打分，中间不产生任何输出 token。

官方给的一组定位很直观：路由一个请求，返回该去哪个目的地、每个目的地的概率；检查一个条件，返回真或假加各自概率；给答案打分，返回加权后的等级；给 agent 步骤做门控，返回 go 还是 no-go 加概率。

和普通模型怎么比

先看清差异，再决定要不要用。下面这张表对着"做决策"这个场景，把它和两种常见替代放一起比。

对比通用聊天模型的差别在两点：一是输出是结构化概率而非自然语言，下游不用写"提取是/否"的解析；二是所有选项一次算完，不需要为每个选项各发一次请求。Perplexity 官方评测里，它在 11 个公开基准上拿到 85.7%，高于 Jev 的 84.5% 和 Qwen3.8-27B 基座的 74.8%——基座只有 74.8% 这个对比，说明专门的决策微调确实拉高了判断准确度。

本地怎么跑

先拉模型，再用 --ask 加 --choice / --level 的 CLI 形式，或走 /v1/systemone 端点。

ollama pull pplx-decider

# 判断一张工单是不是在申请退款
ollama run pplx-decider --ask "Is a refund being requested?" < ticket.txt

# 路由：这单该给哪个团队
ollama run pplx-decider --ask "Which team should handle this?"   --choice billing="Payments and refunds"   --choice technical="Outages and errors" < ticket.txt

# 分级：紧急程度
ollama run pplx-decider --ask "How urgent is this?"   --level "Routine" --level "Soon" --level "Immediate" < ticket.txt

state 可以跟在模型名后面，也可以从 stdin 进。API 侧走 /v1/systemone，把要判断的文本放 state、问题放 questions，Ollama 会帮你拼好 prompt。注意别照抄某些页面里的 JSON 示例字段——那里可能出现抓取乱码，以 CLI 的 --ask / --choice / --level 为准。

值不值得用

适合它的场景有三个。一是 agent 的流程门控：把"这一步能不能继续"交给一个专门判断模型，比让通用模型一边生成一边自评可靠。二是需要稳定结构化判断的分类、路由、分级任务，省掉输出解析的脆弱。三是多模态判断，比如读一张截图判断是不是报错页、读一张收据提取判断结论。

不适合的场景也明确。它不生成文本，所以任何要写总结、写代码、对话的任务都别用它；27B 在本地要 17GB 显存，纯 CPU 跑会很慢，资源紧张的话先用 4B 的 flash 版，请求格式和图片支持一样、精度接近、体积约七分之一。还有一点，概率是"校准过"的，但具体到你的业务阈值仍要自己拿真实数据标定，别直接套别人给的数字。

本次 v0.40.7 里，除了新模型，还有几处值得顺带升级的理由：Responses 对话在带/不带 thinking 的模型间切换不再失败；streaming 下客户端工具调用先于推理项输出的乱序问题被修掉；ollama show 新增 renderer、parser、template_source 字段，能看清模型用了哪个渲染器和 chat 模板来源；远程模型在客户端断开时会被取消而不是继续烧钱。综合看，如果你已经在用 Ollama 跑本地 agent，这次升级值得跟，顺手把决策模型这个品类试起来。