Stop Overpaying for Intelligence | DevDay 2026

**TL;DR：优化 AI 成本的关键不是压低单 token 价格，而是盯住「单任务成本」——选对模型、再用提示词缓存、程序化工具调用、推理力度与批量处理四个杠杆持续迭代。** ## 开场：我们要聊什么 这是 OpenAI DevDay 2026 户外舞台的一场圆桌对话，由 Arty 主持，邀请了 OpenAI 应用 AI 部署工程团队的两位成员 Mandeep（驻旧金山）和 Sapto，围绕「如何优化 AI 成本」展开。讨论覆盖四个问题： - 优化成本时，真正该看的指标是什么 - 如何针对特定任务为模型选型（right-size） - 模型之外还有哪些成本杠杆 - 全程贯穿 OpenAI 真实客户案例 ## 第一个错误：指标就选错了 大多数开发者把成本等同于价目表上输入和输出 token 的标价。Mandeep 指出，这个数字遗漏了两件事： 1. 更便宜的模型可能要消耗更多 token、或者产出更多 token 才能完成任务； 2. 模型可能根本完不成任务，必须由人工介入收尾。 结论是：**开发者和企业真正应该关注的指标是「单任务成本」（cost per task），而不是「单 token 成本」（cost per token）。** ### 一个亲身案例：航空公司的改签机器人 Mandeep 上周去纽约出差订机票，在网上改签找不到符合行程的航班，只好打电话给航空公司，接他的却是一个客服聊天机器人。他非常耐心地解释——自己想改签航班、不想要红眼航班——但机器人始终听不懂，最后他只能直接说：「我要和真人通话。」人工客服介入后完成了交易，给他订了一趟经由休斯敦的航班，让他赶上了团队线下活动。 这家航空公司使用的模型在单 token 成本上可能确实更便宜，但真正完成这个任务的成本，是 token 的成本，加上必须介入的人力成本。**航空公司本该看的指标是单任务成本，其中既包括人力，也包括人工花在完成任务上的时间。** ### 客户案例：Perplexity 与 Notion - **Perplexity**：在其研究评测中报告，新模型（6 Astra）结果准确度高出 9%，而成本只有一半。6 Astra 在单 token 成本上可能更贵，但它用更少的 token 把事情做完了，因此单任务成本高效得多。 - **Notion**：非常擅长把系统迁移到最新的模型系列，例如从 5.5 迁移到 5.6 Sol，报告准确度更好，单任务成本减半。 这里还强调了 **token 效率**：OpenAI 持续投入大量精力，不仅让模型性能更强，也让它在 token 上更高效。 ## 第二步：如何针对任务为模型选型 建议的起点分两步： 1. **清晰地定义任务**——回到航空公司的例子，他们的目标可能是「80% 的咨询由聊天机器人解决」。如果当时使用了 6.0 的 GPT Live 作为委托模型，也许就能在不转交人工的情况下解决 Mandeep 的问题。 2. **定义这个任务需要达到的准确度。** 目标是找到那个能以尽可能最好的成本达成该准确度的**模型、框架（harness）和配置**。 ### 帕累托曲线（Pareto Curve） 这是把两个相互依赖的变量画在一起、必须在两者之间做取舍优化的工具。在成本优化场景中，这两个变量是**准确度**和**成本**。 思路是：尝试不同的模型、不同的设置、不同的配置、不同的框架，算出这些配置下每个任务的准确度，然后找出哪个模型配置和框架能在最好的成本下达到这个准确度门槛。 ### 从哪个模型开始试 OpenAI 有模型正处于准确度与成本的帕累托前沿上： - **6 Astra**：最前沿的模型，智能水平非常高； - **6.1 Sol**：提供非常高的智能水平，同时在单任务上非常节省成本； - **Luna**：大家也听到了「Luna maxing」的说法。 很多任务凭直觉就知道该用哪个模型：简单的分类任务、或者只是从文档中抽取几个字段，Luna 就够了。所以在这些情况下，会在流程早期先测试一个更小、更高效的模型；如果任务需要更强的智能，就从 6 Astra 开始。然后在测试不同模型的过程中把帕累托前沿画出来，找到那个分界点——哪一个模型和配置能在最好的单任务成本效率下达到性能门槛。 **总结顺序：先建立评测集（evaluation sets），找到能满足准确度门槛的模型，然后再去优化成本。** ### Luna Maxing 很多客户惊喜地发现，**Luna 在较高的、或额外高的推理力度（reasoning effort）设置下，实际上能击败许多更大的模型**，尤其是上一代模型或竞争对手的模型。因此很多客户把 Luna 作为开发者写代码的默认方式，只有在需要更高智能时才切换到其他模型。客户反馈是：**对 80%–90% 的工作流来说，Luna 都表现得非常好。**「别小看 Luna，去试试看。它能做的事情可能比你想象的更多。」 OpenAI 当天还发布了 **Decisions API**，同样面向更简单的任务，这个模型家族在不断壮大。 ## 模型之外的四个成本杠杆 Sapto 指出：同一个模型家族，成本可能差别很大，取决于处理的信息量、传递给模型的信息量，以及我们期望的输出是什么。他给出四个杠杆：**提示词缓存（prompt caching）、程序化工具调用（programmatic tool calling）、推理力度（reasoning effort）、批量或 Flex API 处理**。 ### 杠杆一：提示词缓存 切入点是看你输入提示词中**重复出现的文本**。例子：假设你有一个公司客服助手，它对每一位客户都使用相同的公司政策和文档来处理请求。提示词缓存的原理是：它可以复用这些共享信息的预处理结果，而模型仍然会处理提示词中的任何新信息，并每次生成全新的回复。 ### 杠杆二：程序化工具调用 场景：你有一个在线订货系统，其中的智能体（agent）处理大量订单，并需要查库存是否足够完成这些订单。流程可能是智能体调用多个工具、处理订单、找出缺什么、什么在途，然后把所有结果推回给 LLM（推理引擎）。 关键问题是：**你的模型真的需要自己去读取并比较所有这些结果吗？答案是不需要。** 程序化工具调用的概念是：你的模型运行一段小程序，由这段小程序负责协调工具调用、处理结果，然后把打包好的汇总报告交回模型去判断。这些结果可以先被校准、合并，再进行比较，而不必全部传回模型。 好处有两点： - 不需要把每一条中间数据都发回模型； - 尽可能多的步骤上减少工作流对模型的调用次数。 **客户案例 Clio**：这是一家 AI 驱动的法律科技公司，为律所提供云端管理软件系统。他们在多步骤文档分析中报告称，通过使用程序化工具调用，**减少了 38% 的 prompt token，而且质量没有任何损失**。仅仅是改变应用与模型交互的方式，就减少了 38% 的 prompt token。 ### 杠杆三：推理力度 主要建议：**把推理力度当作一个需要测试的设置来看**。推理力度与答案长度是两回事——即使是很短的回答，也可能需要相当多的推理力度才能生成出来。 指导原则： - 只要是任何类型的**路由任务**，始终从较低的推理力度级别开始，然后运行你的评测（evals），看质量是否仍然达标； - 对于任何困难或需要区分的任务，多花这些 token 是值得的； - 最重要的一点：**一定要迭代地运行评测，帮助你做出有依据的决策。** ### 杠杆四：批量（Batch）或 Flex API 处理 背后的问题是：**你愿意等多久？** 假设你正在处理成千上万份文档，而且可以稍微等一等。OpenAI batch API 提供 **24 小时的处理窗口，token 价格比标准同步请求低 50%**，对不需要即时获得模型响应的工作流是理想选择。 ## 一个更根本的思考框架 构建 AI 应用时，脑子里可能会有「我该用哪个模型家族？」这个问题，但还应该额外问一个：**「我要让模型做多少工作？」** 具体建议：在你的应用中完整地跟完一个任务，看看输入是什么、输出长什么样，看看是否存在重复性的工作流，看看这里有多少工具调用。然后思考什么能改善结果，**只改一个设置，然后迭代，运行评测**，让你的应用和模型随之不断演进。 最重要的一点是：**这并不在于把 token 降得越低越好，也不在于让 token 越简单越好。而在于，通过降低成本和保持可接受的延迟，最终拿到一个成功的业务结果。** ## 四个杠杆的快速回顾 1. **提示词缓存**：如果去看价目表，会看到输入和输出 token 的成本，而缓存输入的成本**最多可以低 90%**，对所付成本影响最高可达 90%。 2. **减少输入 token 量**：与其一股脑倒进大量信息，可以用程序化工具调用把一部分数据或上下文的处理卸载到代码中，让它留在模型的上下文窗口之外，直接降低成本。 3. **推理力度**：很多人熟悉 Codex 上的那个滑块，API 中同样可以调整推理力度。而且现在在 API 中，**可以调整推理力度而不破坏缓存**，意义重大（大约几周前随 Astra 一起发布）。 4. **Batch / Flex**：如果请求不紧急、可以延后处理，就能少付钱。 对话在接下来深入探讨提示词缓存最常犯的错误时结束。 Source: [Stop Overpaying for Intelligence | DevDay 2026 — OpenAI](https://www.youtube.com/watch?v=_nmlHbSB8kM)