别再为AI智能超额付费：OpenAI DevDay成本优化全攻略

在OpenAI DevDay的户外舞台上，来自AI部署工程团队的Mandeep和Saptal分享了一个被大量开发者忽视的话题——如何真正优化AI应用的成本。他们的核心观点很直接：大多数人从一开始就盯错了指标，从而为智能付出了不必要的高价。

最大的误区：盯着「每Token成本」，而非「每任务成本」

开发者最常犯的错误，就是打开定价页面、比较输入输出Token的单价，然后选择最便宜的那个模型。Mandeep指出，这种思路忽略了一个关键事实：在Token单价上更便宜的模型，在完成整个任务的成本上未必最便宜。

原因有两个：便宜的模型可能消耗或产出更多Token才能完成任务；又或者它根本完不成任务，最终需要人工介入。无论哪种情况，真实成本都远高于单纯的Token账单。

Mandeep用了一个颇具共鸣的亲身经历来说明：他的航班被取消，联系航空公司时遇到客服聊天机器人，耐心解释想改签却怎么也无法让AI理解诉求，最后只能说「我要和人工对话」。一个本应由AI完成的任务，最终加上了人工客服的时间成本。他总结道，航空公司真正该关注的是每任务成本（cost per task），这个数字包含了人工介入所花费的时间和成本。

他还引用了两个客户案例佐证这一逻辑。Perplexity在其研究基准测试中报告，新模型相比旧模型准确率提升9%、成本却只有一半；Notion则通过持续迁移到最新模型系列（如从5.5到5.6），实现了更高准确率和每任务成本减半。换言之，更贵的模型在「每任务」维度上反而可能更高效。

如何为任务「适配」合适的模型

选对模型是成本优化的第一大决策。Mandeep给出的方法论是：先清晰定义任务，再定义业务对这个任务期望的准确率。

回到航空公司的例子，目标可能是「让聊天机器人解决80%的咨询」。只要设定了明确的准确率阈值，接下来的工作就是寻找能以最低成本达成该阈值的模型、框架（harness）与配置组合。

这里他引入了一个重要概念——帕累托曲线（Pareto curve）。横纵轴分别是准确率和成本，两者相互制约。开发者要做的是尝试不同模型、不同设置、不同框架，测出每种配置下的每任务准确率，再找出那个在满足准确率门槛的同时成本最优的拐点。

对于能够直观判断的任务，比如简单分类或从文档中提取几个字段，Luna这类小模型往往足够胜任；需要更高智能的任务则可以从旗舰模型6 Astra起步，再逐步向下测试。OpenAI方面强调，其模型矩阵——6 Astra（前沿旗舰）、6.1 Sol（高性价比）以及Luna——都处于成本与准确率的帕累托前沿。

Luna Maxing：别低估小模型

现场提到一个有趣的术语「Luna maxing」。Mandeep表示，许多客户惊讶地发现，开启高或超高推理强度（reasoning effort）的Luna，能够击败不少上一代或竞品的更大模型。因此，一些客户把Luna作为开发者编程的默认模型，只有在确实需要更高智能时才切换到更强的模型。对80%到90%的工作流而言，Luna表现得相当出色。

帕累托曲线（Pareto curve）源自经济学中的帕累托效率概念，在这里被用来描述准确率与成本之间的权衡边界。曲线上的每一个点代表一种模型/配置组合，其含义是：在给定成本下能达到的最高准确率，或在给定准确率下能实现的最低成本。曲线上的点被称为「帕累托最优」，意味着无法在不牺牲另一指标的情况下单独改善某一指标。落在曲线内侧（非前沿）的配置则意味着存在改进空间——可以找到同等成本但更准确、或同等准确但更便宜的替代方案。实际操作中，开发者需要通过系统性评测（benchmark）来绘制这条曲线：对同一批代表性任务，用不同模型、不同推理强度、不同提示结构分别运行，记录每种配置的准确率和成本，再标注出各自所在的位置，从而直观地找到满足业务准确率门槛的最低成本拐点。

模型之外的四个成本杠杆

Saptal强调，同一个模型系列的成本可以相差极大，关键取决于你让它处理多少信息、输出多少内容。他介绍了四个具体杠杆。

1. 提示缓存（Prompt Caching）：把输入提示中重复的部分（如企业政策文档）缓存下来，模型复用这些共享信息的预处理结果，同时对每次的新信息重新处理并生成全新回复。这是影响最大的杠杆——OpenAI的价格表显示，缓存输入最高可节省90%的成本。

2. 程序化工具调用（Programmatic Tool Calling）：Saptal抛出一个问题——当agent调用多个工具处理订单、查找库存时，模型真的需要亲自读取和比较所有中间结果吗？答案往往是否定的。程序化工具调用让模型运行一段小程序来协调工具调用、整理结果，只把打包好的报告交回模型判断，从而避免把每一份中间数据都塞进上下文，也减少了模型调用次数。法律AI公司Clio报告，在多步文档分析中采用这一方式，在质量无损的前提下减少了38%的提示Token。

3. 推理强度（Reasoning Effort）：把它理解为一个可调测试的设置。注意推理强度与答案长度无关——即使是简短答案也可能需要大量推理。建议是：常规任务从低推理强度起步，跑评测看质量是否保持；困难或差异化任务再支付额外Token的代价。核心是迭代式地运行评测来做决策。

4. 批处理 / Flex API：问题的关键是「你愿意等多久」。如果要处理成千上万份文档且不急于立即拿到结果，OpenAI的批处理API提供24小时处理窗口，Token价格比标准同步请求低50%。

Saptal的忠告是：选择模型系列时，还要问一个问题——「我要让模型做多少工作？」走完应用里一个完整任务，观察输入输出、识别重复工作流和工具调用次数，然后每次只改一个设置、迭代、跑评测。重点不是单纯减少Token，而是在可接受的延迟下以更低成本获得成功的结果。

程序化工具调用（Programmatic Tool Calling）的核心思想来自于「编排层」与「推理层」的分离。传统的agent工作流中，每次工具调用的结果都会原样追加到上下文，再交由大模型读取、判断下一步行动，导致上下文随工具调用次数线性膨胀，Token消耗也随之飙升。程序化工具调用则在模型与工具之间插入一段轻量级代码逻辑：由程序负责调度工具调用顺序、聚合中间结果、过滤无关信息，最终只将精简后的摘要或结论送入模型。这与软件工程中「关注点分离」的原则一脉相承——让擅长精确执行的代码去处理确定性逻辑，让昂贵的模型推理只聚焦在真正需要语义理解的决策节点上。这一模式对多步骤数据查询、文档分析流水线等场景效果尤为突出。

深挖提示缓存：开发者的常见失误

由于提示缓存影响巨大，两位讲者专门展开讨论。现场提问显示几乎所有开发者都在用提示缓存——它本身是默认开启的，但很多客户并未用到极致。

首要原则是尽量保持提示开头一致，这样缓存就能复用共享指令的预处理，而新信息则被重新处理。客户Blitzy（AI软件开发公司）的案例颇具说服力：通过从单次结构化输出调用改为Luna的工具调用循环，他们的缓存复用率从24%提升到90%，在数千次生产调用中实现了8.5倍更少的输出Token、相比GPT 5.4 mini成本降低87%，同时处理的上下文还多出2.2倍。

当提示频繁变化时怎么办

对于早期模型系列，自动缓存默认开启、系统按Token间隔选择断点，开发者无法自定义边界。到了GPT 5.6系列，新增了显式断点（explicit breakpoints）——你可以在稳定内容之后、频繁变化的任务之前手动设缓存点，让稳定部分被复用、变化部分被重新处理。

若需要更精细的控制，还有显式仅缓存模式（explicit only mode），让你挑选具体要缓存的部分，避免缓存那些频繁变化、日后不会被复用的内容。

到了GPT 6 Astra，此前的能力全部保留，并新增一项关键能力：可以在进行中的对话里改变推理强度而不破坏缓存。此外，开发者也早已能在不破坏缓存的前提下通过allowed tools等参数改变可用工具。

OpenAI还上线了提示缓存仪表盘，可测量和追踪应用的缓存命中率；以及一个诊断API，针对两个不同查询定位缓存未命中发生的位置，帮助针对性优化。

提示缓存（Prompt Caching）的工作原理是：当模型接收到一段输入时，会对其进行分词（tokenization）和预处理，生成一组中间表示（通常称为KV Cache，即Key-Value Cache）。如果后续请求的输入前缀与之前某次请求完全一致，模型可以直接复用已计算好的KV Cache，跳过对该部分的重新计算，从而大幅降低计算量和对应费用。这也解释了为什么「保持提示开头一致」至关重要——缓存是前缀匹配的，系统提示、企业政策文档等固定内容放在最前面，变化的用户输入放在最后，才能最大化命中率。缓存未命中（cache miss）则意味着这部分Token需要按完整价格计费。提示缓存对长系统提示（如嵌入整份知识库或操作手册）的场景收益最为显著，因为这些固定内容往往占据输入Token的绝大部分。

可落地的行动清单

两位讲者给出的收尾建议清晰可执行：

• 先定义你想让模型完成的任务，确定业务期望的准确率阈值；
• 构建一组能代表实际使用场景的任务集，尝试不同模型、设置、推理强度和提示；
• 绘制帕累托前沿，找到在准确率阈值下成本最优的模型、配置与框架组合；
• 每次只测试一个改进，找到有效改进就固定下来并持续迭代，随着应用和模型演进不断重跑评测。

归根结底，这场分享传递的核心讯息始终如一：不要为智能超额付费，真正重要的指标是用更低的成本、可持续的延迟，稳定地完成任务。