扒一扒 OpenAI o1 系列模型 (二)：对开发者有何影响？

o1 系列模型在多项测评中锋芒毕露，它是否就是开发者的万能之选呢？今天魔法哥将从性能、局限、成本、接口协议 、提示工程 等几个方面来探讨这个问题。

性能

适用场景

上篇文章曾提到，o1 系列模型借助 训练阶段的强化学习 + 推理阶段的预思考 token 这两大奇招，显著提升了复杂推理能力------也就是说，它是一个 "逻辑高手"，业界的相关测评也验证了这一点。

不过，对于创意生成类场景来说，o1 的表现并不比上一代模型 GPT-4o 更出色。因此开发者有必要针对自己的应用场景进行性能评估，再决定是否要切换到 o1 模型。

模型版本

此外，o1 系列模型目前有 o1-preview 和 o1-mini 两个版本可用，未来还会放出 "完全体" o1，它们之间也有能力差异。

简单来说，o1-preview 和 o1 具备广泛的世界通用知识，着重于复杂推理 ；而 o1-mini 是一个更小规格的模型，其优势在于推理速度更快、成本更低，因此在编程、数学等不需要通用知识的场景下是更合适的选择。

以上图为例，在某些领域，o1-mini 以较低的推理成本获得了与 o1 接近的推理能力。因此，开发者有必要考虑到 o1-mini 的这些优势，获取更好的性价比。

推理速度

上篇文章也提到，o1 在正式输出之前，会在内部生成一定的 token 数量来进行 "预思考"。因此，它的 TTFT（生成首个 token 所用时间）肯定是比不上 GPT-4o 等上一代模型的；而且按照 TPS（每秒生成 token 数，即平均推理速度）来评估，o1 显然也具有先天的劣势。

魔法哥以某个简繁转换的文本生成任务为例，拿 OpenAI 自家 GPT-4o 模型与 o1 进行了推理速度的横向对比，数据如下：

模型	推理时间	Token 数	TPS
`gpt-4o`	6.6	564.3	86.0
`o1-preview`	28.8	579.0	20.4
`o1-mini`	11.9	578.7	49.2

由于 o1 目前 并不向 API 开发者公开预思考 token 的内容，因此上表没有把这部分 token 计入有效输出的 token 数。不出意外，o1 的表现与 4o 存在明显差距。

不过，如果我们把预思考 token 也算进去，o1 的成绩会变成如下情况，算是挽回了一些颜面：

模型	推理时间	总 Token 数	总 TPS
`o1-preview`	28.8	2392.3	82.8
`o1-mini`	11.9	1624.0	138.1

魔法哥在测试中发现，o1 的数据波动较大，应该是预思考环节的不确定性所导致的。以上数据是多轮测试后的统计结果，仅供参考。

其实 "推理速度" 这个指标在云端有很大的调度空间，o1 的这个劣势并非无法弥补。改天魔法哥单独写篇文章来展开讨论。

总之，o1 的推理速度决定了它不是一款 "万金油"。对于直接面向用户进行交互的场景，o1 并不是最佳选择。

局限

o1 模型还处在测试阶段，它与 ChatGPT 的整合还没有全部完成，比如目前还不能提供联网搜索、上传文件、识别图片等高级功能，也不能驱动 GPTs。

在 API 层面，o1 目前还有很多能力没有开放出来，下面魔法哥针对这些局限来逐一分析。

暂不支持流式输出

上面我们提到，o1 模型在生成实际输出之前有较长的 "预思考" 时间，而且这部分 token 并不会暴露给 API 调用者，这两点几乎堵死了它用于 C 端对话场景的可能性。从这个角度来看，目前 o1 不支持流式输出也就不足为奇了。

很显然，这个局限是眼下开发者在选择模型时需要关注的重点问题之一。

暂不支持系统提示词

魔法哥猜测，目前 o1 模型的 "预思考" 行为是通过大量的系统提示词来进行约束的，因此现阶段的 o1 模型为保证自身行为的稳定性，暂不向开发者开放系统提示词的能力。

对于开发者来说，如果要在自己的应用中换用 o1 模型，则只能 对原来的系统提示词进行适当调整，以用户提示词的方式来传递给模型。

暂不支持工具调用和持结构化输出

这两项能力通常在复杂的 AI 应用工作流中扮演重要角色，但 o1 模型目前还没有开放。如果你需要用到这两项能力，就只能等待 OpenAI 官方的进一步消息了。

暂未开放多模态能力

据说 o1 也是一个多模态模型，但目前还没有开放这方面的能力。如果你的应用场景需要处理图片、视频、语音等多模态数据，o1 暂时还无法胜任。

接口参数限制

像 logprobs, temperature, top_p, n 等参数，要么不能用，要么已经固定为默认值。开发者如果打算尝试 o1，暂时就只能忽略这些参数了。

话说回来，尽管 o1 API 目前还存在以上种种不便，但相信在不久的未来，随着 o1 结束测试阶段，这些局限也会逐渐解除。让我们拭目以待吧。

成本

这里魔法哥先列一下 o1 和兄弟模型的价格对比：（单位：美元 / 百万 token）

模型	输入定价	输出定价
`gpt-4o`	$2.50	$10.00
`gpt-4o mini`	$0.15	$0.60
`o1-preview`	$15.00	$60.00
`o1-mini`	$3.00	$12.00

可以看到，o1-mini 的定价确实比 o1-preview 要低不少；但是相比 GPT-4o 系列，o1 系列模型的整体价格还是偏高的。

除此以外，还有一个好消息和一个坏消息：

好消息是，o1 系列模型也都支持提示词缓存，这在不少场景下可以显著节省成本。（这个 "提示词缓存" 是什么？魔法哥有机会也给大家单独讲讲。）
坏消息是，o1 的 "预思考" token 也是算在输出 token 中进行计费的！不让你看，还让你付钱，你说冤不冤？（开个玩笑，没有这些 "预思考" token，o1 的推理表现也不会这么好。）

总之，目前 o1 的 API 调用成本确实还比较高，开发者在选择模型时也需要掂量一下自己的钱袋子呀。

接口协议

OpenAI 经典的 Chat Completion 接口已经推出快两年了，从 GPT-3.5 到现在的 o1，接口协议基本没有破坏性的变化。能做到这一点确实不容易，也让开发者在接入新模型时省去了不少麻烦。

不过值得注意的是，这次 o1 模型在接口层面引入了一些小变化，这里需要提供一下各位开发者注意。

输入参数变化

首先需要留意 o1 模型 Chat Completion 接口的输入参数变化：

原先我们在限制模型输出长度时，会用到 max_tokens 参数；但在调用 o1 API 时，需要把这个参数名改为 max_completion_tokens。
上面提到，o1 暂时不支持系统提示词。因此消息类型（message role）只能是 user 或 assistant，不能使用 system 类型。强行使用 system 类型会导致接口报错。

可以看出，这两点需要开发者在切换到 o1 模型时特别注意，改代码或者加兼容层基本上是不可避免的了。好在魔法哥可以用 API2D 提供的 o1 API 服务，他们已经针对这两点做了兼容处理，开发者想要切换到 o1 模型就省事多了。

往期文章也介绍过，API2D（ cmcm.link/p/api2d ）是一个大模型 API 聚合平台，按量计费，随充随用，相当适合个人开发者和小型团队。

返回字段变化

Chat Completion 接口的输出结果也有一些扩展。我们会发现接口返回数据中多了一个 usage.completion_tokens_details.reasoning_tokens 字段，这里的数值就是 o1 模型在 "预思考" 阶段使用的 token 数量。

接口返回数据也进一步证实，"预思考" token 是计入补全 token 并收费的。

提示工程

最后我们来探讨一下，在为 o1 模型编写提示词时应该注意什么。

由于 o1 系列模型已经内置了思维链的推理能力，因此我们以前常用的一些提示工程技巧可能就不适用了，甚至可能会适得其反。以下是 OpenAI 官方给出的一些建议：

简单直接的提示词往往表现更佳。要相信 o1 的理解能力，复杂的指令可能反而会干扰模型的行动。
不要使用思维链类型的提示词。模型内部已经具备了这方面的能力，因此没有必要再要求模型 "一步一步思考" 或 "解释你的推理过程" 了。
使用分隔符来提升提示词的清晰度。使用代码块、XML 标签或小标题这样的分隔符，可以标记出提示词的不同部分，从而帮助模型更好地理解指令。
在 RAG 场景下不要塞入过多的上下文。很多 AI 应用都会通过外挂知识库来拓展模型的能力，但如果在上下文中塞入过多不相关的知识片断，则可能会干扰模型的推理过程或让模型迷失重点。

总的来说，针对 o1 模型的提示词应该是更加简洁和直接的，以免干扰到模型的自身的推理过程。这也值得开发者注意的一个要点。

小结

总的来说，o1 系列模型的推理能力确实出众，但它现阶段在速度、功能和成本等方面仍有劣势，开发者需要根据具体需求谨慎选择。相信随着功能的不断完善，o1 的应用前景值得期待。

魔法哥最近一年都在做 AI 领域的研发和探索，下期分享更精彩。各位新朋友请关注公众号，下次更新不迷路。