10 月 22 日，OpenAI 把它的 Decisions API 全面开放了。

这不是又一个聊天模型。它瞄准的是一个今年才成型的新品类：决策模型（decision model），也叫 System One 模型——给定一组选项，快速做出选择，并给出置信度。

这个品类的开创者是 TypeSafe 的 Jev，靠它 TypeSafe 成了估值 76 亿美元的公司。而 OpenAI 的做法很有意思——它没有专门训练一个决策模型，而是拿现成的 ChatGPT Luna 改了改。

结果：延迟从 1-3 秒降到 100-180 毫秒。

这篇聊聊三件事：为什么决策模型能替代 LLM、OpenAI 的"偷懒"打法为什么有效、以及现在这个赛道的真实格局。

一、决策模型在解决什么问题

先说清楚这个品类跟 LLM 的区别。

维度 LLM（对话模型） 决策模型（System One）
输入 任意 prompt 一组结构化选项
输出 自由文本 选择 + 置信度
延迟 1-3 秒 100-200 毫秒
成本 按 token 计费，较长 极低
适用 需要生成、推理、解释 需要在岔路口快速选

关键在于"岔路口"这个场景极其普遍。

一个 Agent 执行任务时，可能每一步都要做选择：调用哪个工具？走哪条路径？这个结果算成功还是失败？要不要重试？

用 LLM 做这些判断，每次 1-3 秒，一个任务 20 个决策点就是 20-60 秒纯等待。用决策模型，整条链路可能压缩到几秒。

OpenAI 的 API 产品负责人 Nikunj Handa 的原话：

Decisions API 最大的突破是速度，把 1-3 秒缩短到 100、120、180 毫秒。

二、OpenAI 的"偷懒"打法

这部分我觉得是最值得琢磨的工程决策。

Handa 说，团队看到 Jev 之后的反应是：

哇，我们有一百万个用例。

但他们的做法不是从头训练一个决策模型，而是：

我们拿 ChatGPT Luna 重新配置，加快推理速度、降低成本。

Handa 很坦白：

未来我们可能会有专门的训练，让模型在这方面更好。但现在，就是普通的老 Luna 把活干完了。

为什么这招有效

决策模型的核心诉求是快和便宜，不是"聪明"。很多决策任务的判断复杂度其实不高——给 5 个选项选一个，Luna 的能力绰绰有余，瓶颈在推理开销。

所以优化的方向不是"提升智能"，而是"降低延迟"：

  • 缩短输出（不生成推理过程，直接给答案）
  • 地理上就近部署推理资源（降低网络延迟）
  • 针对特定 API 形态优化推理路径

这跟"训练一个更好的模型"是两条完全不同的路，但对用户来说结果一样：够快、够便宜、够用。

一个反直觉的观察

这条路线暴露了一件事：很多"模型能力"问题，本质是工程配置问题。

我们习惯性地认为"要做新任务就得训新模型"，但实际上：把现有模型按特定输入输出形态重新配置，往往就能覆盖大量场景，而且上线快得多。

三、实测数据

OpenAI 公布了一些客户试用数据：

客户 场景 效果
Speak（AI 语言教学） 动作间隔 1.4 秒 → 0.13 秒
Box 替换 LLM 提吞吐 高吞吐
Datadog — 高吞吐
Ramp — 高吞吐
OpenAI 自家 Dots 语音助手响应 明显改善

Speak 的 CTO Andrew Hsu 给的数据最具体：动作间隔从 1.4 秒缩短到 0.13 秒，快了 10 倍多。

对语言教学这种强交互场景，这个差别是致命的——1.4 秒的停顿让人觉得"机器在思考"，0.13 秒就是"对话"。

四、赛道格局：Jev 还是第一吗

现在是四家混战：

厂商 模型 特点
TypeSafe Jev（最新版） 品类开创者，OpenRouter 上查询量最大
Liquid D1 Ultra 公开榜单排名靠前
Base Lab Elephant-1 公开榜单排名靠前
OpenAI Decisions API（Luna 改） 多模态优势，速度优化

公开榜单排名

两个主要榜单：AIM System One Index 和 Artificial Analysis Decision Index。

模型 AIM 排名 AA 排名
Liquid D1 Ultra 榜首 榜首
Base Lab Elephant-1 靠前 靠前
TypeSafe Jev（最新） 第 7 第 3
OpenAI Decisions 第 8 第 14

注意：OpenAI 在榜单上不占优（第 8 和第 14），但它在实际使用上可能更强——多模态是它的差异化。

Handa 说：

在图像分类上，Luna 非常强大，校准表现更好。客户也希望 Decisions API 在把图像作为输出时更灵活。

最有意思的 benchmark：JevMan

我特别喜欢这个——让决策模型玩吃豆人（Pac-Man）。

这个 benchmark 叫 JevMan，由 Opper AI 构建。其增长官 Felix Wunderlich 解释了为什么吃豆人是好测试：

这个经典游戏有意思的地方，是它不间断的高频决策流。每个路口，模型都必须在几百毫秒内决定往哪走。

而最新版 Jev 在这个榜单上排第一。

这个测试其实很精准地对应了决策模型的真实价值：不是在"深度思考"上比高低，而是在"持续做出够快够好的小决策"上。

五、TypeSafe CEO 的一句话值得记住

TypeSafe 的 CEO Diogo Almeida 不信任 benchmark：

他敦促人们在自己的工作负载上试这些模型。

有意思的是——即便是 TypeSafe 自己，上周也在发布新版 Jev 的同时放出了自己的排名。

这不算虚伪，反而说明了一个现实：决策模型的"好坏"高度依赖工作负载。你在智能、成本、校准、速度之间怎么权衡，每个场景答案都不同。

公开榜单能给个方向，但真正该做的还是拿自己的数据跑一遍。

六、下一站：60 毫秒

Handa 提到下一步目标时说了句很有想象力的话：

我们能把它做到 60 毫秒左右吗？那样你可以想象，每一帧视频都调一次 API。

60 毫秒 ≈ 16 fps。如果决策做到这个延迟，能做的事情就完全不一样了——实时视频理解、逐帧决策、真正的"视觉反射"。

这也呼应了 Jev 这个名字的来历。Jevons 悖论：提高资源使用效率，反而会让总消耗增加（因为变得太便宜，用的人更多了）。

Handa 的说法是：

会有一大堆"疯狂的用例"浮现出来——它们一直就在那里，只是决策模型把它们显出来了。

七、对开发者意味着什么

如果你在做 Agent 或任何有多步决策的系统，几点实操建议：

1. 先量一下你的决策延迟占比

# 粗略估算：你的 Agent 一次任务有多少个决策点？
# 如果每个决策点用 LLM 花 1.5s，20 个点 = 30s 纯等待
decisions_per_task = 20
llm_latency = 1.5      # 秒
dm_latency = 0.15      # 决策模型

print(f"LLM 方案: {decisions_per_task * llm_latency:.1f}s")
print(f"决策模型: {decisions_per_task * dm_latency:.1f}s")
# LLM 方案: 30.0s
# 决策模型: 3.0s

如果决策延迟占了大头，这就是值得优化的点。

2. 不是所有决策都该换

需要解释理由、需要多步推理、需要生成内容的，还是用 LLM。

只需要在固定选项里选、给出置信度的，才适合决策模型。

3. 校准比准确率更重要

决策模型输出的是"选择 + 置信度"。置信度准不准（校准，calibration）往往比选对率更重要——因为下游系统要靠它决定"要不要人工介入"。

一个 80% 选对但置信度校准良好的模型，比 90% 选对但置信度乱报的模型更可用。

4. 在自己的数据上测

这是最实在的一条。榜单排名第 7 还是第 1，跟你实际场景的效果可能完全没关系。

八、一点观察

决策模型的爆发，本质上是 AI 应用从"演示"走向"生产"的一个信号。

演示阶段，大家关注"模型能不能做到"。生产阶段，关注"做这件事要多久、多少钱"。

Jev 开创的这条路线，把一个原本被 LLM 霸占的场景（做选择）拆出来，用专门的形态重做。这是一种典型的系统优化思路：把通用能力拆成专用通道。

OpenAI 的反应也很有代表性——不重新造轮子，先改配置抢市场。这在竞争激烈的赛道里往往是对的：等你训好专门的模型，用户已经用上别人的了。

至于最后谁赢，我觉得可能不是"模型最强"的那个，而是校准做得最好 + 延迟最低 + 生态最全的那个。

参考来源

  1. TechCrunch《OpenAI makes its Jev competitor widely available as decision model competition heats up》，Tim Fernholz，2026-10-22
  2. OpenAI Decisions API 官方文档（2026-09-29 开发者日发布）
  3. AIM System One Index / Artificial Analysis Decision Index 公开榜单
  4. Opper AI 的 JevMan benchmark

⚠️ 免责声明：本文基于公开报道整理，数据均来自 TechCrunch 原文与公开榜单。文中代码仅为示例，请根据实际场景调整。