OpenAI推出Decisions API，Jev上线15天就遭冲击？

Jev 才刚发布 15 天，OpenAI 就出手了。

今天的 DevDay 上，OpenAI 亮出了新的 Decisions API。这款接口跑在 GPT-6 Luna 上——这是 OpenAI 眼下体量最小、价格最低的模型。它能从一组预设答案里挑出一个，同时给出对应的置信度分数。OpenAI 报出的延迟是 150 毫秒，而如果直接拿 GPT-6 Luna 干同样的活，要花 1.6 秒。

开发者要做的，是把问题、候选答案和上下文交给 API。模型不会像 ChatGPT 那样吐出一段文字，而是直接给一个能塞进程序里用的决定：这条内容归到哪一类，这个请求该转给哪个模型，Agent 下一步该干什么。

这半个月里，Jev 最受关注的能力差不多就是这个。

消息出来几个小时后，Reddit 的 AI_Agents 版块冒出一个标题很直白的帖子：“Jev Is Dead”。

发帖人认为，OpenAI 把 Decisions API 一推，Jev 想活下去恐怕很难。它手里还能打的牌，只剩“速度极快、价格极低”。评论区还有人补了一句：“Jev 从来就没有过任何护城河。”

OpenAI 发布的，几乎就是一个 Jev

DevDay 主题演讲里，Sam Altman 提到 Decisions API 时没多说：“今天，我们要推出 Decisions API。它可以让模型在几分之一秒内作出响应，速度非常快，工作方式是向 Luna 模型提供一组预设选项。通过让模型专注于这次选择，我们可以把响应速度提高到极致。”

这段话里有两个关键点。

一是 Decisions API 把开放式生成收窄成了“从明确选项里挑一个”，这跟 Jev 的 Choice 原语在设计上走的是一条路。

二是它挑了 Luna 当底层模型——OpenAI 现有模型里最小、最便宜的那个。让最小、成本最低的模型去扛决策任务，而不是搬出 Astra 或 GPT-6.1 Sol，说明这项能力瞄准的是高频、低成本、能大规模塞进 Agent 工作流的基础组件场景。

这款新 API 眼下只提供限量预览，定价、单次请求能带几个候选答案、开发者能不能用自己的数据调优，全都没说。一位 OpenAI 发言人对海外媒体表示，公司打算在“全面推出时”再公布更多信息。这样看，OpenAI 很可能是为了赶在 DevDay 前放出消息，才匆忙推进了这次发布。

这类产品填的，是普通聊天模型和传统分类器之间的空档。以前开发者想让模型从几个答案里选一个，一般是调普通聊天模型，再用提示词逼它只返回某个选项。要是还想要置信度，可以读 token 概率，或者让模型自己生成一个数字。可聊天模型给的置信度往往只是毛估，而且为了完成一个简单判断，还可能生成一大堆 token。

另一条路是训练专用的小型分类器。这种模型又快又便宜，但得准备带标签的数据。分类标签一旦变了，通常还得重新训练。

Decisions API 卡在两者中间。开发者可以像用大语言模型那样，通过提示词给出新的问题和标签，同时拿到类似分类器的结构化结果和置信度。这套设计对 OpenAI 来说不算陌生：Moderation API 长期以来也会针对预设类别返回分数。不同在于，Moderation API 的类别是 OpenAI 定死的，Decisions API 则让开发者自己定义问题和候选答案。

这套产品逻辑，跟 Jev 重合度很高。

9月15日，TypeSafe AI 正式发布 Jev。据《金融时报》报道，Jev 上线后很快引来投资者关注，潜在投资正在按超过 100 亿美元的估值展开讨论，而这家公司之前的估值约为 2 亿美元。

Jev 背后的 Diogo Almeida 曾在 OpenAI 参与 GPT-4、ChatGPT 和 RLHF/InstructGPT。在之前的一场演讲中，他是这么介绍自己的：“我参与署名了 OpenAI 最重要的一批公开成果，包括 GPT-4、ChatGPT，以及 RLHF/InstructGPT。我所在的团队基本上创造了‘后训练’这个概念。”“但真正让我显得有些特别的是，我可能是 OpenAI 少数几个会公开批评 ChatGPT 的人之一。”

Almeida 的履历确实不一般。OpenAI 在 GPT-4 贡献者名单中把他列进“Foundational RLHF and InstructGPT work”一栏，他还是 InstructGPT 论文的第四作者。2024 年离开 OpenAI 后，他和 Erik Gafni、Sasha Sheng 一起创立了 TypeSafe AI，花两年时间秘密推进 Jev。

按 TypeSafe 官方的说法，Jev 是一个“System One Model”，对应心理学里那种快速、直觉式的判断。它不做聊天，也不生成自由文本，而是接收程序状态和问题，通过三种原语返回结构化结果：Choice 从最多 255 个预设选项里选一个并返回概率分布；Score 在指定数值范围内给出评分和置信度；Noul 返回经过校准的二元概率。

TypeSafe 声称，在同类结构化任务上，Jev 比前沿大语言模型快 20 至 200 倍，成本只有其 1/40 至 1/400；每百万输入 token 的价格为 0.042 美元，输出 token 免费。

目前能直接比的只有产品形态和响应速度，价格、校准方式与真实准确率都还是未知数。但两家公司给出的方向已经高度重合：开发者定义问题和候选答案，模型快速返回选择和置信度，再把结果直接嵌进分类、路由和 Agent 决策流程。

护城河在哪里？

Jev 的架构本身很可能不构成护城河。

关于 Jev 究竟怎么实现的，TypeSafe 并未公开完整架构和具体细节。不过从几个早期克隆版本能看出些端倪——它们大多搭在现成的大语言模型上。Bespoke Nimble 走的是 LoRA 微调 Qwen3.5-9B 这条路，训练数据是合成对比数据，返回概率的办法是读取候选答案对应 token 的 logits。体量更小的 Kev-0.5B 则在 Qwen2.5-0.5B 上加了 LoRA 适配器和一个小型 pointer head，一台 MacBook Pro 就能跑起来。

这些复现虽然实现方式各有差异，但思路基本一致：让模型对一组给定的候选答案打分，而不是把整段文本生成出来。一种可能的做法是，拿到一个 state 和一组 questions，模型只算所有可能成为下一个 token 的选项及其概率分布，再把候选 token 的 logprobs 转成结构化结果。拿 Noul 来说，模型只需盯住代表 true 和 false 的两个 token，其余全部忽略，把两者概率归一化，就得到“是”或“否”的概率。Choice 同理：开发者抛出四个候选答案，模型比较四个对应 token 的相对概率，拼出完整概率分布，再返回概率最高的那个。

Arcturus Labs 创始人 John Berryman 由此推断，Jev 用的模型可能和传统大语言模型差不太多。大语言模型本来就在给下一个 token 的每种可能取值分配概率，Jev 大概率是把这种能力收窄到一组明确选项上，再把模型内部的 token 概率变成开发者能直接用的决策结果。

要是架构算不上护城河，那真正能筑起壁垒的大概就是训练数据和训练流程了。原始数据本身不缺，难的是把已经产生明确结果的真实案例，改造成适合训练决策模型的材料，再靠强化学习让模型输出的概率和实际正确率对得上。这一点和 Almeida 谈到数据、架构时的说法也吻合。案例可以来自完全不搭界的领域，客服工单和它实际流转到的部门、简历和候选人最终有没有被录用、商品评价和它的星级、内容审核队列和最终裁定、预测市场和它的最终结果，都行。它们共用一个训练目标：给定具体情境和有限选项，让模型去还原已经发生的结果。怎么把跨领域的案例统一成训练材料，再训出能泛化、概率校准也过关的模型，这才是 TypeSafe 更不容易被抄走的部分。

Reddit 上一些网友都认同“Jev 从来就没有护城河”这个说法。有位 Reddit 用户还晒了自己的内部测试：拿 GPT-6 Luna 跑一个 800 条记录的数据集，每批输入 20 条。按他的说法，GPT-6 Luna 速度是 Jev 的 1.6 倍，成本是 Jev 的 1.2 倍，准确率差不多。

另外，OpenAI 手里还有一张 TypeSafe 短期内很难复制的牌：它已经攒下了庞大的开发者平台，以及 Dots、Space、Codex 云端和计算机操作 API 这些产品。Decisions API 跟这些产品有没有完成整合，OpenAI 还没宣布。可只要它的准确率到了能用的水平，借着现成平台触达开发者是很快的事。对不少团队而言，它未必需要在每项指标上都压过 Jev，够准、价格接近，再加上省掉接入新供应商的成本，吸引力就已经不小了。

那如果这条护城河本来就浅，OpenAI 又把它做了出来，TypeSafe 的机会窗口会不会很快就关上？

有意思的是，Almeida 本人看起来并不着急。他在接受 Latent Space 采访时说：“如果模型质量真的很重要，那么我们将在很长一段时间里处于非常有利的位置。”

这话站不站得住，要看那个最难验证的变量：Jev 给出的概率到底有多准。倘若 TypeSafe 的训练数据和强化学习流程确实难以复制，Jev 就还有自己的位置；反过来，如果 OpenAI 能很快逼近它的准确率，再靠价格、平台和开发者生态把规模铺开，TypeSafe 的机会窗口就会迅速收窄。

参考链接：