当前位置：

社区首页

文化娱乐

在线教育

IT互联网

OpenAI

文章详情

便宜模型总翻车？OpenAI缓存机制与分工技巧避坑指南

省Token不靠少写指令

模糊任务更容易反复返工

把范围和验收标准写清

让一次执行更接近目标

9 月初，OpenAI 发布 GPT‑6 Astra 时，强调的是能力上限：这是 GPT‑6 家族里最强的型号，适合最困难、最重要、不能轻易出错的工作。

但大多数人每天做的，并不是这种级别的任务。

我们更多是在写文章、查资料、改代码、整理文件，或者让 AI 重复执行一套固定流程。所有任务都交给最强模型，成本通常更高，也未必有必要；但如果只盯着最低单价，把复杂工作全塞给最便宜的模型，又可能因为反复出错和返工，最后花掉更多时间和 Token。

所以 9 月 22 日，OpenAI 发布了 GPT‑6 Sol 和 GPT‑6 Luna。与它们一起出现的，还有一套更完整的使用逻辑：怎样按任务选择模型和推理强度，怎样复用上下文，以及怎样判断一次 AI 调用到底便不便宜。

一、9 月 22 日，OpenAI 到底发布了什么

GPT‑6 Astra 仍然是整个家族中能力最强的模型。OpenAI 对它的建议没有改变：当你需要最好的结果，不准备在质量上妥协，就选 Astra。

Sol 和 Luna 解决的是另外一个问题——并不是每项工作都需要 Astra 的全部能力。

OpenAI 对 Sol 的定位，是在能力与成本之间取得平衡。它面向复杂编程、专业工作和智能体流程，适合需要判断力、但又要考虑运行成本的日常任务。Luna 的定位更明确：专门服务于目标清楚、数量大、重复频率高的工作。

两个新模型都使用了与 Astra 类似的训练方法，把 GPT‑6 在专业工作、事实性、编程、计算机操作和对齐方面的进步，带到更快、更便宜的型号上。相比 GPT‑5.6 对应型号的促销价格，OpenAI 将 Sol 和 Luna 的 API 价格都降低了 50%。

价格之外，还有几项容易被忽略的变化。

在 OpenAI 根据用户标记错误对话构建的内部事实性评测中，Sol 的错误量大约是上一代的一半，并以更低成本接近 Astra。Luna 也有明显改善；在较高推理强度下，官方称它能以大约百分之一的成本达到 GPT‑5.6 Sol 的事实性水平。这里说的是 OpenAI 自己的评测，不代表每一种任务都会得到相同比例的提升。

编程方面，OpenAI 报告称，Luna Max 在 DeepSWE 1.1 中得到 66.6%，接近 Claude Opus 5 和 Fable 5 的 Medium 水平；在官方给出的对比中，单任务成本分别低约 93% 和 96%。计算机操作评测中，Luna Max 超过 GPT‑5.6 Sol Medium，成本约为后者的十分之一。不同公司的推理设置和计费方式并不完全相同，所以这些数字更适合用来观察 Luna 所处的价格—能力位置，而不是拿来宣布某个模型在所有场景里获胜。

OpenAI 还专门提到 Sol 和 Luna 的沟通风格：表达更清楚、术语更少、奇怪措辞更少、无价值细节更少，回答整体略短，但不牺牲实质内容。两者的对齐表现也比对应的 GPT‑5.6 前代有所改善，其中包括更少对编程工作作出误导性陈述。官方同时提醒，这些评测刻意设置了困难情境，不能直接换算成日常使用中的失败率。

发布时，GPT‑6 Sol 和 Luna 面向 Plus、Pro、Business、Enterprise 和 Edu 用户逐步进入 ChatGPT Work 与 Codex；Free 和 Go 用户可以在桌面应用中使用 Luna。当时它们尚未进入普通 ChatGPT 对话模式。你最终能看到哪些选项，还取决于客户端、灰度进度以及工作空间管理员的设置。

二、别再背模型排行榜：按任务选就行

OpenAI 在 Codex 的官方每周更新里给出了一条很直接的建议：日常和复杂编程从 Sol Medium 开始；范围明确、可以重复执行的任务使用 Luna High。

这句话比一长串跑分更有用，因为模型名称并不是唯一变量。Luna 支持 none、low、medium、high、xhigh 和 max 六档推理强度。同一个模型，推理强度越高，通常会投入更多推理 Token，也可能增加等待时间和成本。

OpenAI 的模型选择指南把任务分得更细：Luna Low 适合细小修改、范围明确的问题和简单数据提取；Luna Medium 适合按清晰需求创建内容，或者协调修改已有材料；Luna Extra High 可以承担约束清楚的跨应用搜集、排序和问题处理。Sol Low 适合聚焦写作、编辑和事实核查，Sol Medium 面向日常编码、研究和需要完整判断的工作，Sol Extra High 则用于深度分析和仔细审查。Astra 留给高难度分析、复杂交付物和对质量要求最高的任务。

换成普通用户能执行的方法，我会这样判断：不知道该怎么拆，或者做错代价很高，就用 Astra；目标已经明确，但过程仍然需要判断，用 Sol；步骤已经写得像一份 SOP，而且要重复很多次，用 Luna。

例如，把 200 条新闻按行业和日期分类，不需要直接上 Astra 的最高推理强度；但如果要从这些新闻中判断哪些会真正改变行业格局，Luna Low 又明显不够。前者重在稳定执行，后者重在判断。

对 Codex 用户来说，也可以使用同样的思路。简单重命名、格式修改、配置调整和机械性批处理，先试 Luna。日常功能开发、错误调查、测试和代码审查，从 Sol Medium 开始。涉及支付、权限、数据迁移或核心架构，再考虑 Sol 的更高推理强度或 Astra。

如果任务规模较大，我会先让 Luna 做只读整理，例如找出所有旧接口调用、列出路径和风险；再让 Sol 完成主体修改和测试；只有变更影响很大时，才让 Astra 做最终审查。这是我根据官方模型定位整理的工作流，并不是 OpenAI 规定的固定步骤。它的目的只有一个：别让最贵的模型承担所有机械工作，也别让最便宜的模型独自处理明显超出能力范围的判断。

三、Luna 很便宜，但不要只看每百万 Token

OpenAI API 标准模式、短上下文的价格如下，单位均为每百万 Token：

Luna 的普通输入和输出价格都是 Sol 的二十分之一，也是 Astra 的百分之一。这个差距足以改变批量任务的成本结构，但上表不是任何情况下都固定不变。

输入超过 272K Token 后，整个请求的输入和缓存费率会变为两倍，输出费率变为 1.5 倍。Batch 和 Flex 是标准价格的 50%，Fast Mode 则是相应价格的两倍。

更重要的是，如果算整项工作的真实成本，就不能只看 API 单价，还要考虑工具调用、失败重试、人工检查和返工时间。

Airbnb 的官方案例提供了一个很直观的例子。在一项涉及战略文档和其他非编程工作的测试中，一名 Airbnb 用户表示，使用 Astra 只需要 3 到 4 轮就获得了满意结果，而其他模型需要 20 多轮。这是客户案例中的个人反馈，不是通用基准，但它说明：更贵的模型如果能明显减少沟通轮数，最终成本未必更高。

视频平台 invideo 的反馈也类似。其团队表示，Astra 规划复杂视频编辑时需要的推理轮次更少，因此完成任务需要的输出 Token 也更少；调色和色彩校正任务的成功率提高到此前的约 3 倍。这里同样不能把企业自述当成所有用户都能复现的保证，但它揭示了一个容易被忽略的事实：单价低不等于任务总成本低，少走弯路本身也在省 Token。

所以 Luna 最适合的，并不是“一切可以交给 AI 的工作”，而是那些标准容易说清、结果容易检查、需要反复运行的任务。比如从文章中提取标题、日期和链接，把会议记录整理成固定格式，按模板生成一批说明，或者批量检查文档是否缺少规定字段。

四、怎么省 Token：API 用户和 Codex 用户要分开看

9 月 22 日发布 Sol 和 Luna 的同时，OpenAI 还单独介绍了 GPT‑6 的提示词缓存更新。官方所说的“缓存输入最高便宜 90%”，指的是 API 里的缓存输入 Token，不是打开一个开关，就能让 ChatGPT 或 Codex 套餐额度自动增加十倍。

缓存的原理并不复杂。连续几次 API 请求如果拥有相同的开头——例如相同的系统指令、工具定义、项目规则和参考资料——OpenAI 可以复用此前已经计算过的部分。GPT‑6 的缓存输入价格是普通输入的 10%，因此读取命中缓存的 Token 最多可以便宜 90%。

可以把它想成印一套培训手册。第一次需要制作整套版面，相当于缓存写入；以后每位员工拿到的手册，前面 100 页都一样，只有最后一页任务不同，就不必每次重新制版。前提是这段前缀达到最低缓存长度，并且进入缓存。

GPT‑5.6 及之后模型的可缓存前缀，至少需要 1,024 个可见输入 Token。缓存写入价格是普通输入的 1.25 倍，读取则是 0.1 倍。默认有效期至少为最近一次写入或复用之后 30 分钟，后续复用会刷新时间。

这意味着缓存不是无条件省钱。一段前缀如果写入后再也不用，1.25 倍的写入成本反而高于普通输入。官方文档给出的计算更直观：同一前缀写入一次、完整读取一次，总成本相当于普通输入的 1.35 倍；如果不用缓存处理两次，则是 2 倍。若总共请求十次，一次写入加九次读取约为 2.15 倍，而每次从头处理则是 10 倍。

按这套机制，缓存尤其适合客服知识库、代码 Agent、批量文档处理和长期复用同一套规则的工作流。

想提高命中率，最重要的做法不是研究玄学参数，而是保持前缀稳定：把系统规则、工具定义、固定背景和长期参考资料放在前面，每次变化的问题和客户资料放在后面。频繁改写前面的规则，哪怕意思差不多，也可能从变化位置开始破坏复用。

工具列表同样属于上下文。

OpenAI 建议保持工具名称、结构和顺序稳定。某一轮暂时不用工具，可以用 allowed_tools 限制本轮范围，或者设置 tool_choice: none，而不是删除整套工具定义。

对使用 Responses API 的开发者，GPT‑6 还允许通过 configuration_update 改变推理强度，同时保留此前前缀用于缓存复用。比如先用 Sol High 设计方案，方案确定后，把后续机械修改降到 Low 或 Medium，避免简单步骤继续使用较高推理强度。

如果在调用 API，结构相似的任务集中运行也更容易复用缓存。需要批量翻译、处理商品资料或生成周期报告时，与其今天做一条、明天做一条，不如在缓存窗口内集中处理。

普通 Codex 用户不必直接操作这些 API 参数，但仍然可以借用背后的思路：长期要求写成稳定的项目说明或 AGENTS.md；不要每轮重复粘贴已经存在的规则；日志只保留第一个关键错误和附近内容；先检索相关文件，再让模型读取，而不是一开始就把整个仓库塞进去。如果旧对话已经积累大量无关日志，再考虑开启新对话。

Luna 虽然拥有 1,050,000 Token 上下文窗口、922,000 最大输入和 128,000 最大输出，但“能放进去”不等于“应该全部放进去”。超过 272K 输入之后价格会上升，无关材料还会增加检索难度。上下文管理不是故意少给信息，而是只给完成当前任务真正需要的信息。

最后再强调一次账单区别：使用自己的 API Key，按照输入、缓存、输出和工具调用计费；通过 ChatGPT 套餐登录 Codex 或 ChatGPT Work，消耗的是套餐内的 Work/Codex 使用额度。后者受模型、任务规模、推理强度和工作量影响，不能拿 API 的“缓存便宜 90%”直接换算成还能发送多少条消息。

五、把官方文档变成可以照着做的操作

前面解释了原理，下面只讲操作。需要先分清两个入口：如果你在 Codex 或 ChatGPT Work 的界面里使用模型，只需要选择模型和推理强度；如果你自己调用 OpenAI API，才会接触 reasoning.effort、缓存断点、工具列表和诊断参数。

普通 Codex 用户：先从两个默认选择开始

OpenAI 在 Codex 更新里给出的起点非常明确：

日常和复杂编程：先选 Sol Medium。
范围明确、需要重复执行：先选 Luna High。

不要一开始就把所有任务调到最高推理强度。先用官方建议的起点跑一次，再看结果：如果只是分类、提取、格式修改和机械性改动，降低推理强度；如果需要跨文件判断、调查复杂错误或检查重要变更，再提高强度或改用 Astra。

为了让 Luna 更容易把任务做对，指令中至少写清四件事：处理范围、不能改什么、输出格式、完成标准。例如，不要只写“检查这个项目”，而要写成：

只读检查 src/auth，找出仍在调用旧登录接口的文件。输出路径、调用位置和迁移风险，不修改代码，不扫描其他目录。

这段提示词不是 OpenAI 官方原版模板，但使用方式与官方对 Luna 的定位一致：范围越清楚，重复执行的价值越高。

API 用户：先用 Responses API 调用 Luna

OpenAI 建议 GPT‑6 使用 Responses API。最基本的请求可以写成：

python

from openai import OpenAI client = OpenAI() response = client.responses.create( model="gpt-6-luna", reasoning={"effort": "high"}, input="从下面的客户反馈中提取问题类型、严重程度和产品模块。" ) print(response.output_text)

模型 ID 分别是 gpt-6-astra、gpt-6-sol 和 gpt-6-luna。在 Responses API 中使用 reasoning.effort；如果仍在使用 Chat Completions，对应参数名是 reasoning_effort。

这里有一个重要限制：GPT‑6 Sol 和 Luna 在 Chat Completions 中，只有把 reasoning_effort 设为 none 时才支持函数调用。需要“推理＋工具”时，应该使用 Responses API。Astra 不支持 none，最低从 low 开始；Sol 和 Luna 支持 none。

如果推理强度不是 none，官方迁移指南要求删除 temperature、top_p 和 top_logprobs；使用 Chat Completions 时还要删除 logprobs，使用 Responses 时则不要在 include 中请求 message.output_text.logprobs。这些旧参数不是继续调优的入口，而是需要移除的不兼容项。

需要重复使用固定规则：设置显式缓存断点

缓存默认已经启用，但显式模式可以让你决定哪一段值得写入缓存。下面的结构把长期规则放在前面，把每次变化的任务放在后面：

json

{ "model": "gpt-6-luna", "reasoning": { "effort": "high" }, "prompt_cache_options": { "mode": "explicit", "ttl": "30m" }, "input": [ { "role": "developer", "content": [ { "type": "input_text", "text": "这里放长期不变的规则、字段说明和参考资料……", "prompt_cache_breakpoint": { "mode": "explicit" } } ] }, { "role": "user", "content": "这里放本次变化的数据和具体任务……" } ] }

几个细节不能漏：

显式模式需要 prompt_cache_options.mode: "explicit"。
在稳定内容末尾添加 prompt_cache_breakpoint。
顶层 instructions 不能放显式断点；需要缓存开发者指令时，应像上面一样把它写进 developer 消息的 input_text。
如果开启显式模式却没有添加任何断点，这次请求不会使用提示词缓存，也不会创建缓存写入。
每次请求最多创建四次缓存写入。
断点之后频繁变化的内容按普通输入计费，不必为明显不会复用的数据支付缓存写入费。

如果不想手动放置断点，可以使用隐式模式。GPT‑5.6 及之后的模型会在最新的合格消息末尾自动选择断点；显式断点也可以与隐式模式一起使用。

应用启动时预热缓存

如果应用一启动就知道稍后一定会用到一大段固定规则、工具定义或参考资料，可以先预热缓存，降低用户正式提问后的首 Token 等待时间：

json

{ "model": "gpt-6-luna", "input": [ { "role": "developer", "content": "应用共享的固定指令、工具定义和参考资料……" } ], "prompt_cache_options": { "prewarm": true } }

预热请求只准备缓存，不生成回答。它完成后，再发送带有相同前缀的正式请求，并省略 prewarm 或将其设为 false。预热写入的 Token 仍按正常缓存写入价格收费，因此只应该预热确定会复用的内容。

在同一段对话中调整推理强度

有些任务前面很简单，后面突然变难；也有些任务先完成复杂规划，后续只剩机械执行。GPT‑6 可以在标准、单 Agent 的 Responses API 对话中追加 configuration_update：

json

{ "type": "configuration_update", "reasoning": { "effort": "high" } }

把它放在下一条用户消息之前，就能让后续响应改用 High。需要保留缓存前缀时，顶层的 reasoning.effort 应保持原值，不要跟着改；真正的变化由 configuration_update 完成。这个更新会一直生效，直到出现下一次更新。

官方还列出了几个限制：不要把两个 configuration_update 紧挨着放，否则 API 会拒绝；不要把它与自动压缩或自动截断混用。如果显式压缩了历史，需要在下一条用户消息前重新添加所需的 configuration_update。

工具暂时不用，不要从列表中删除

如果请求之间需要的工具不同，官方建议保留完整、稳定的工具定义、顺序和 Schema，只改变本轮允许调用哪些工具。

本轮完全不使用工具：

json

{ "tool_choice": "none" }

本轮只允许两个工具：

json

{ "tool_choice": { "type": "allowed_tools", "mode": "auto", "tools": [ { "type": "function", "name": "get_weather" }, { "type": "function", "name": "search_docs" } ] } }

这样做的目的不是权限设计本身，而是避免添加、删除或重排工具破坏缓存前缀。如果工具很多，还可以使用 Tool Search，并为暂时不需要的工具设置 defer_loading: true，减少前几轮为工具定义支付的输入 Token。后续加载的新工具会追加到上下文末尾，不改动之前已经可以复用的内容。

使用推理模型处理函数调用时，OpenAI 还建议把上一次函数调用返回的 reasoning items、函数调用项和函数结果一并带到下一次请求中。最简单的方法是使用 previous_response_id；这样模型能延续此前推理，也更节省 Token。

缓存没有命中：不要猜，直接查原因

OpenAI 提供了两个入口：

在
Prompt Caching Dashboard
platform.openai.com
查看整体缓存命中率。
在 Responses API 中使用缓存诊断，对比当前请求与一条较早的响应。

诊断时，把基准响应 ID 放进：

json

{ "prompt_cache_options": { "comparison_response_id": "resp_上一条响应ID" } }

然后读取当前响应里的 prompt_cache_diagnostics。如果类型是 cache_miss，结果会给出原因和大约错失复用的 Token 数量。常见原因包括：

model_changed：模型换了；
service_tier_changed：处理等级变了；
tools_changed：工具被添加、删除、重排或修改；
reasoning_effort_changed：顶层推理强度改变；
verbosity_changed：回答详细程度改变；
text_format_changed：输出格式或 Schema 改变；
input_changed：前面的输入被编辑、重排或混入时间戳、请求 ID等动态内容；
context_compacted：对话压缩替换了早期内容。

真正判断省了多少，不能只看诊断结果，还要检查 usage.input_tokens_details.cached_tokens 和 cache_write_tokens，再结合模型的每百万 Token 价格计算。cache_hit 只表示没有发现阻止前缀复用的差异，并不代表本次所有输入 Token 都来自缓存。

从旧模型迁移到 GPT‑6，照着检查这一遍

如果应用原来使用 GPT‑5.5 或更早版本，官方迁移建议包括：

把模型名改成 gpt-6-astra、gpt-6-sol 或 gpt-6-luna。
原来使用 minimal 推理强度的，从 low 开始测试。
将旧的 prompt_cache_retention 替换成 prompt_cache_options.ttl: "30m"。
确认固定前缀至少达到 1,024 个可见输入 Token。
如果默认断点把动态内容也写进缓存，在稳定内容末尾加入显式断点。
同一组请求保持模型、Service Tier、工具定义、输出格式和顶层推理强度稳定。
迁移前后比较 cached_tokens、cache_write_tokens、响应延迟和总成本，而不是只确认接口能返回结果。

GPT‑6 还支持异步工具调用和任务执行中的追加指令。将函数或自定义工具设置为 async: true 后，模型可以在应用执行工具期间继续推理、调用其他工具或处理互不依赖的内容；应用仍然负责真正执行工具，并使用原来的 call_id 返回结果。通过 WebSocket 使用 Mid-turn Steering，还可以在模型运行中追加纠正或新要求，而不必从头开始整个任务。这些能力更适合长时间运行的 Agent，不是每个普通请求都必须开启。

六、官方案例里，最值得普通人抄的不是数字

Harvey 是法律 AI 平台。它使用 Astra 处理法院信息、律所文件、判例研究和其他法律资料，再生成结构化文档。官方案例中一个很实用的设计，是把律师的长期偏好直接放进工作流：是否使用编号列表、优先采用哪类来源、问题应该怎样标色。

这比“AI 会写法律文件”更值得普通用户借鉴。很多人使用 AI 时，每一轮都在补充同一批要求：语气不对、格式不对、来源顺序不对。把这些稳定偏好写进项目说明、模板或固定指令，模型从第一轮就能按照同一标准工作，也更有利于 API 的前缀复用。

Proaction 的案例则展示了另一种用法。它是一家车队管理软件公司，让非技术销售人员使用 Codex，把客户通话记录、邮件和表格转化成定制 HTML 产品演示。

过去，创始人主要依靠沟通和幻灯片向客户解释产品能做什么。现在，销售人员可以让 Codex 根据客户自己的车辆、设备和业务流程生成可操作演示。客户指出需要调整的地方，演示继续迭代；成交后，这份演示还能作为工程团队的需求参考。

Proaction 在 OpenAI 案例中自估，每月节省 40—60 小时工程时间，创始人每月节省约 25—33 小时，从初次接触进入方案开发的客户比例提高约 50%—60%。这些数字不是独立审计结果，不应该被写成任何公司使用 Codex 后都会得到的保证。

但方法本身很清楚：把散落在通话、邮件和表格里的上下文，变成客户可以看到、团队可以继续修改的交付物。Proaction 这个案例展示了一种比问答更有价值的 Agent 用法。

Harvey 和 Proaction 也说明，提示词好不好，并不只取决于措辞多漂亮。真正影响结果的，往往是资料是否齐全、偏好是否稳定、输出标准是否明确，以及模型有没有权限使用正确的工具。

七、一份可以直接复制的任务模板

很多 Token 浪费并不是模型选错，而是任务没有说清楚。“帮我优化一下”看起来很省字，却把目标、范围和判断标准全部留给模型猜。更完整的任务说明通常反而能减少搜索和返工。

text

目标：说明这次唯一需要完成的结果。输入资料：列出必须使用的文件、链接、数据或前文结论。范围：明确只检查或修改什么，不处理什么。输出格式：规定结构、长度、字段、语言和是否需要引用来源。验收标准：说明满足哪些条件才算完成。执行要求：先使用已有资料；不要重复搜索已经确认的信息；信息不足时指出具体缺口；完成后说明实际检查了什么。

这不是 OpenAI 官方提供的固定模板，而是根据它的模型选择、缓存机制和几个客户案例整理出来的通用写法。对 Luna，清晰边界能让它发挥低成本批量执行的优势；对 Sol 和 Astra，明确验收标准也能减少无意义的探索。