Open cssmagic opened 4 weeks ago
o1 系列模型在多项测评中锋芒毕露，它是否就是开发者的万能之选呢？今天魔法哥将从 性能、局限、成本、接口协议、提示工程 等几个方面来探讨这个问题。
上篇文章 曾提到，o1 系列模型借助 训练阶段的强化学习 + 推理阶段的预思考 token 这两大奇招，显著提升了复杂推理能力——也就是说，它是一个 “逻辑高手”，业界的相关测评也验证了这一点。
不过，对于创意生成类场景来说，o1 的表现并不比上一代模型 GPT-4o 更出色。因此开发者有必要针对自己的应用场景进行性能评估，再决定是否要切换到 o1 模型。
此外，o1 系列模型目前有 o1-preview 和 o1-mini 两个版本可用，未来还会放出 “完全体” 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 进行了推理速度的横向对比，数据如下：
gpt-4o
由于 o1 目前 并不向 API 开发者公开预思考 token 的内容，因此上表没有把这部分 token 计入有效输出的 token 数。不出意外，o1 的表现与 4o 存在明显差距。
不过，如果我们把预思考 token 也算进去，o1 的成绩会变成如下情况，算是挽回了一些颜面：
魔法哥在测试中发现，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，暂时就只能忽略这些参数了。
logprobs
temperature
top_p
n
话说回来，尽管 o1 API 目前还存在以上种种不便，但相信在不久的未来，随着 o1 结束测试阶段，这些局限也会逐渐解除。让我们拭目以待吧。
这里魔法哥先列一下 o1 和兄弟模型的价格对比：（单位：美元 / 百万 token）
gpt-4o mini
可以看到，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。
max_tokens
max_completion_tokens
上面提到，o1 暂时不支持系统提示词。因此消息类型（message role）只能是 user 或 assistant，不能使用 system 类型。强行使用 system 类型会导致接口报错。
user
assistant
system
可以看出，这两点需要开发者在切换到 o1 模型时特别注意，改代码或者加兼容层基本上是不可避免的了。好在魔法哥可以用 API2D 提供的 o1 API 服务，他们已经针对这两点做了兼容处理，开发者想要切换到 o1 模型就省事多了。
往期文章也介绍过，API2D（ https://cmcm.link/p/api2d ）是一个大模型 API 聚合平台，按量计费，随充随用，相当适合个人开发者和小型团队。
Chat Completion 接口的输出结果也有一些扩展。我们会发现接口返回数据中多了一个 usage.completion_tokens_details.reasoning_tokens 字段，这里的数值就是 o1 模型在 “预思考” 阶段使用的 token 数量。
usage.completion_tokens_details.reasoning_tokens
接口返回数据也进一步证实，“预思考” token 是计入补全 token 并收费的。
最后我们来探讨一下，在为 o1 模型编写提示词时应该注意什么。
由于 o1 系列模型已经内置了思维链的推理能力，因此我们以前常用的一些提示工程技巧可能就不适用了，甚至可能会适得其反。以下是 OpenAI 官方给出的一些建议：
简单直接的提示词往往表现更佳。要相信 o1 的理解能力，复杂的指令可能反而会干扰模型的行动。
不要使用思维链类型的提示词。模型内部已经具备了这方面的能力，因此没有必要再要求模型 “一步一步思考” 或 “解释你的推理过程” 了。
使用分隔符来提升提示词的清晰度。使用代码块、XML 标签或小标题这样的分隔符，可以标记出提示词的不同部分，从而帮助模型更好地理解指令。
在 RAG 场景下不要塞入过多的上下文。很多 AI 应用都会通过外挂知识库来拓展模型的能力，但如果在上下文中塞入过多不相关的知识片断，则可能会干扰模型的推理过程或让模型迷失重点。
总的来说，针对 o1 模型的提示词应该是更加简洁和直接的，以免干扰到模型的自身的推理过程。这也值得开发者注意的一个要点。
总的来说，o1 系列模型的推理能力确实出众，但它现阶段在速度、功能和成本等方面仍有劣势，开发者需要根据具体需求谨慎选择。相信随着功能的不断完善，o1 的应用前景值得期待。
魔法哥最近一年都在做 AI 领域的研发和探索，下期分享更精彩。各位新朋友请关注公众号，下次更新不迷路：
📣 AI 魔法群开放啦！ 扫码加群，领取魔法哥整理的常用 AI 工具包：
扫码加群，领取魔法哥整理的常用 AI 工具包：
© Creative Commons BY-NC-ND 4.0 | 我要订阅 | 我要打赏
您好，邮件已查收。Anmi、
Anmilover
commented
4 weeks ago Anmilover
commented
4 weeks ago
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 进行了推理速度的横向对比，数据如下：
gpt-4oo1-previewo1-mini由于 o1 目前 并不向 API 开发者公开预思考 token 的内容，因此上表没有把这部分 token 计入有效输出的 token 数。不出意外，o1 的表现与 4o 存在明显差距。
不过，如果我们把预思考 token 也算进去，o1 的成绩会变成如下情况，算是挽回了一些颜面：
o1-previewo1-mini魔法哥在测试中发现，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-4ogpt-4o minio1-previewo1-mini可以看到，
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 模型就省事多了。
返回字段变化
Chat Completion 接口的输出结果也有一些扩展。我们会发现接口返回数据中多了一个
usage.completion_tokens_details.reasoning_tokens字段，这里的数值就是 o1 模型在 “预思考” 阶段使用的 token 数量。接口返回数据也进一步证实，“预思考” token 是计入补全 token 并收费的。
提示工程
最后我们来探讨一下，在为 o1 模型编写提示词时应该注意什么。
由于 o1 系列模型已经内置了思维链的推理能力，因此我们以前常用的一些提示工程技巧可能就不适用了，甚至可能会适得其反。以下是 OpenAI 官方给出的一些建议：
简单直接的提示词往往表现更佳。要相信 o1 的理解能力，复杂的指令可能反而会干扰模型的行动。
不要使用思维链类型的提示词。模型内部已经具备了这方面的能力，因此没有必要再要求模型 “一步一步思考” 或 “解释你的推理过程” 了。
使用分隔符来提升提示词的清晰度。使用代码块、XML 标签或小标题这样的分隔符，可以标记出提示词的不同部分，从而帮助模型更好地理解指令。
在 RAG 场景下不要塞入过多的上下文。很多 AI 应用都会通过外挂知识库来拓展模型的能力，但如果在上下文中塞入过多不相关的知识片断，则可能会干扰模型的推理过程或让模型迷失重点。
总的来说，针对 o1 模型的提示词应该是更加简洁和直接的，以免干扰到模型的自身的推理过程。这也值得开发者注意的一个要点。
小结
总的来说，o1 系列模型的推理能力确实出众，但它现阶段在速度、功能和成本等方面仍有劣势，开发者需要根据具体需求谨慎选择。相信随着功能的不断完善，o1 的应用前景值得期待。
魔法哥最近一年都在做 AI 领域的研发和探索，下期分享更精彩。各位新朋友请关注公众号，下次更新不迷路：
🔥 往期推荐
AI 应用开发指南：
ChatGPT 高级技巧：
AI 资讯与评述：
© Creative Commons BY-NC-ND 4.0 | 我要订阅 | 我要打赏