OpenAI 入场 Jev 赛道:投研决策模型另一选择

9 月 29 日，OpenAI 在 DevDay 2026 上发布了一堆东西：Dots、GPT-6.1 Sol、Ultrafast 模式。但在量化开发者和 Agent 开发者圈子里，真正引发讨论的是一个相对低调的发布——Decisions API。

The New Stack 的报道标题很直白：OpenAI answers TypeSafe's Jev with a Decision API built on Luna。TNS 直接判断，这是 OpenAI 对 Jev 的仓促回应，可能赶在 DevDay 前匆忙上线。

Decisions API 基于 GPT-6 Luna，OpenAI 当前产品线里最小、最便宜的模型。它的核心能力是：你定义问题和候选答案，它返回一个答案加上置信度分数，延迟 150 毫秒。对比 GPT-6 Luna 自己的 1.6 秒，快了 10 倍。

目前是 limited preview，定价未知，候选答案上限未知，是否支持微调也未知。OpenAI 对 TNS 表示会在"广泛发布"时分享更多细节。

图注：鸭总站在岔路口，面前多条路通向不同方向

图注：OpenAI Devs 官方推文：Decisions API 基于 GPT-6 Luna，limited preview。来源：X/@OpenAIDevs

决策模型到底在解决什么问题

传统做法有两种。一种是用大语言模型加精心设计的 prompt，让它从列表里选一个，然后读 token 概率当置信度。问题是 LLM 在这件事上并不靠谱，置信度经常是粗略猜测，还烧不少 token。另一种是训练一个小分类器，速度快、成本低，但每次标签集变了都得重新训练。

决策模型卡在两者中间。它像分类器一样快，但像 LLM 一样灵活——新标签写在 prompt 里就行，不用重新训练。决策模型返回预定义答案和置信度分数，LLM 在这件事上经常靠不住。

这不是一个全新的概念。OpenAI 自己的 Moderation API 早就返回按类别打分的结果而不是文本，只不过那些类别是 OpenAI 预设的，不是开发者自定义的。Liquid AI 的文档把决策模型的三种原语讲得很清楚：Noul（是/否概率）、Choice（多选一概率分布）、Score（有序评分）。一次 API 调用可以同时问多个问题，模型一次性返回所有答案，零生成 token。

对量化场景来说，这意味着分类交易信号、路由行情请求、评估 Agent 下一步动作，都可以用一个专门的模型来完成，而不是每次都调一个完整的 LLM。

图注：决策模型的核心：从固定选项中快速返回答案和置信度

赛道开始拥挤

两周前这个赛道还只有 Jev 一家。

9 月 19 日，LangChain 发布了 Jev 和 LLM judges 的四维对比测试——准确率、可重复性、延迟、成本。那条推文拿了 3000 多个赞，算是给决策模型赛道做了一次大规模科普。9 月 24 日，Latent Space 播客放出 Jev 创始人的深度访谈，他明确拒绝"Decision Model"这个标签，坚持叫 System One 模型——强调的是快速、直觉式的决策循环，不只是分类器。

然后 9 月 29 日，一天之内两条消息同时砸下来。

Liquid AI 发布 d1 模型，声称是首个在 HuggingFace Decision Index 上超越 Jev 的模型，多语言评估胜出，抗 prompt injection 更强。Ollama 更快，OpenAI 发布次日就宣布支持 Nimble 本地决策模型，走 /v1/systemone API，本地跑，不需要云端 API。

从一家独大到四方入场，只用了 12 天。

图注：12 天内，决策模型赛道从一家独大变成四方入场

图注：Liquid AI 同日发布 d1 模型，声称首个超越 Jev 的 Decision Model。来源：X/@liquidai

技术差异

表面上看，这四个产品做的事情差不多：你给上下文和候选答案，它返回一个选择加置信度。但技术实现差别不小。

Latent Space 在 DevDay 报道中指出，OpenAI 的 Decisions API 目前是"light shim over Luna"——Luna 的一层薄封装。好处是继承了 Luna 的视觉能力，可以处理图片输入。坏处是没有 calibration 或 RLCD（Reinforcement Learning from Contrastive Decisions），也就是没有专门针对决策任务做校准训练。

Jev 的技术路线不同。TypeSafe 用 RLCD 做训练，专门优化决策场景的校准度。Liquid AI 的 d1 也做了专门训练，声称在多语言和抗注入上有优势。Ollama 的 Nimble 走开源路线，本地部署，数据不出机器。

OpenAI 的优势在生态和基础设施。如果你已经在用 OpenAI 的 API 做其他事情，加一个 Decisions API 的调用成本几乎为零。但如果你需要高度校准的置信度，或者需要在本地跑，OpenAI 目前不是最佳选择。

图注：表面相似的决策模型，技术实现差别不小

三个关键未知

TNS 在报道结尾点出了三个关键问题：Decisions API 每次调用多少钱？一个请求最多能处理多少候选答案？开发者能不能在自己的数据上微调？

这三个问题直接决定了这个产品是"标准构件"还是"小众工具"。定价如果比 Jev 贵很多，迁移动力不足。候选上限如果太低，复杂场景用不了。不支持微调的话，特定领域的精度可能不够。

定价未知是最大的信息缺口。 OpenAI 的定价策略一向复杂，Luna 本身的价格、Ultrafast 模式的 6 倍溢价、缓存输入的 95% 折扣，这些都说明定价对 OpenAI 来说是精细运营的工具。Decisions API 的定价会直接影响量化开发者的选型决策。

Liquid AI 的 d1 有免费层（d1:free），这是一个值得关注的信号。Ollama Nimble 本地跑，成本为零。如果 OpenAI 的定价不够有竞争力，开发者有充分的替代选项。

量化开发者的选型建议

现在不是做最终决定的时候，但可以开始评估。

如果你已经在用 Jev 生产环境跑着，不急着动。Jev 有先发优势、LangChain 集成、TypeSafe SDK，生态最成熟。等 OpenAI Decisions API 正式发布、定价公布后再做对比也不迟。

如果你想尝鲜，Liquid AI 的 d1 有免费层，API 兼容 TypeSafe SDK，迁移成本低。可以拿来做 A/B 测试，看看在你的场景里和 Jev 的差距。

如果你在意数据隐私或需要本地部署，Ollama Nimble 是唯一选项。本地跑，数据不出机器，延迟取决于你的硬件。

如果你已经在用 OpenAI 的全套 API，Decisions API 值得关注，但别急着全面迁移。等定价、候选上限、可调性三个参数明确后再决定。

这个赛道的壁垒不在推理技术本身，而在生态和数据。 Ollama 在 OpenAI 发布次日就支持了本地决策模型，说明技术门槛不高。真正难复制的是 TypeSafe 积累的训练数据、LangChain 的集成生态、以及围绕 Jev 建立的社区。

对量化开发者来说，好消息是第一次有了真正的选型空间。坏消息是，选型窗口可能很短——一旦某个平台的定价和生态形成锁定，迁移成本会快速上升。