GPT-6 Sol 与 Luna 发布后，选型还要确认什么？从官方参数到迁移验证

文章目录

一、从发布消息到实际选型：这次更新该怎么看

看到"GPT-6"这个名字，开发者很容易先问两件事：能力是不是又上了一个台阶，手里的应用是不是该换模型了。但对已经上线的产品来说，名字只决定了要不要关注，能否迁移还得看任务表现、接口兼容和成本账本。

先校正一个信息边界。截至 2026 年 10 月 10 日，OpenAI 的 Sol 与 Luna 发布页面已包含价格、评测与开放范围。因此，继续以"官网只给了一段预告，参数和价格都没公布"为文章前提，会误导准备做预算的读者。早期 RSS 摘要可以作为线索，正式选型应回到目前可核验的原文。

这次发布也不是 GPT-6 家族第一次出现。OpenAI 在公告中交代，Astra 此前已经推出，Sol 和 Luna 是进一步扩展这个家族。公告强调把能力带到更多日常工作，并拓宽不同预算下的选择。OpenAI 发布公告

对企业来说，这类扩展的实际价值，要放进具体业务才能看清。同一个客服产品，可能同时处理意图分类、订单信息提取、长对话总结和复杂争议分析。这些任务的难度、调用频率和错误后果差别很大，没必要仅因为它们属于同一个产品，就让它们采用完全相同的模型配置。

高频分类需要稳定地识别有限类别，复杂争议分析则可能需要核对多个时间点、处理相互冲突的证据。前者每次多花一点钱，累计后就会影响毛利；后者一次漏掉关键限制，可能带来更多人工返工。选型人员真正需要的是判断每类任务需要多少能力，以及为这种能力付出的完整代价。

因此，本文把问题拆成三个层次：官方已经给出了哪些答案，公开评测能支持什么判断，以及在自己的业务中还缺少哪些证据。前三节整理官方资料，后面给出作者提出的预算与验证方法。本文没有调用模型进行独立性能测试，示例也不代表任何企业的实际账单。

还要留意版本变化。原公告标注了 9 月 29 日的 GPT-6.1 Sol 更新，Sol 的模型文档也指向这个后续版本。本文主体讨论 GPT-6 Sol 与 GPT-6 Luna，当前重新选型时，应把 GPT-6.1 Sol 单独纳入候选，不能拿新版评测解释旧版能力。GPT-6.1 Sol 公告

二、官方已经公布了什么：参数、价格与能力边界

先把比较口径放在同一张表上

下面整理的是两个模型的 API 文档信息。价格均以美元计，单位为每百万 token，采用标准处理、短上下文的文本 token 费率。token 是模型计量文本的单位，与中文字数不能直接画等号。

项目	GPT-6 Sol	GPT-6 Luna
API 模型名	gpt-6-sol	gpt-6-luna
官方定位	复杂编码与代理工作流	聚焦、高调用量任务
上下文窗口	1,050,000 token	1,050,000 token
最大输出	128,000 token	128,000 token
未缓存输入价格	$2.00	$0.10
缓存读取价格	$0.20	$0.01
缓存写入价格	$2.50	$0.125
输出价格	$10.00	$0.50
原生输入／输出	文本输入输出、图像输入	文本输入输出、图像输入
原生音频／视频	不支持	不支持
功能	流式输出、函数调用、结构化输出	流式输出、函数调用、结构化输出
Responses API 工具示例	搜索、代码解释器、计算机使用等	搜索、代码解释器、计算机使用等

表内参数分别来自 GPT-6 Sol 模型文档和 GPT-6 Luna 模型文档。这里比较的是 API 条件，不能据此推算某个订阅套餐的额度。

同样的上下文和输出上限，不能证明两个模型处理复杂任务的能力相同。规格表只说明接口允许的范围，任务质量还需要单独比较。就像两套数据库都允许保存相同规模的数据，并不意味着它们在所有查询上都有相同表现。

大窗口解决的是容量问题，长文理解还要另测

一家企业想分析一组供应商合同，可能会先计算所有文件能否装进上下文。这个检查有必要，却只完成了容量验证。真正影响结果的是模型能否找到散落在不同附件里的限制，是否注意到补充协议覆盖了旧条款，以及能否把结论对应到具体证据。

可以准备两份内容相近的材料，把关键条件分别放在开头、中间和末尾，再要求模型给出相同格式的答案。如果结论随位置变化明显，就说明仅靠容量参数还无法回答业务问题。另一种测试是故意保留两份不同日期的规定，看模型是否能识别新旧关系，而不是从其中随便摘出一条。

这些是本文建议的验证方法，并非对两个模型实际表现的结论。即使输入能够提交成功，也应检查完整读取、引用准确性和输出是否被截断。最大输出上限也不能被理解为每次请求都会、或者应该生成那么长的答案。

图像输入、图像生成和工具调用要分开看

表格里的"图像输入"说明模型能够接收图像信息；"支持图像生成工具"则表示它可以参与调用相关工具的工作流。这两项不是同一种能力。一个应用能返回图片，可能依赖模型之外的工具服务，选型时要把工具可用性和调用成本一起纳入。

同样，文档列出函数调用，并不等于模型会自动获得企业内部系统的权限。开发者仍要提供函数定义、处理返回结果，并限制可以执行的操作。例如，让模型查询库存和让模型直接修改库存，是两种不同的应用设计，应分别验证。

接口兼容也值得提前查看。两个模型的文档都提示，内置工具和函数调用可通过 Responses API 使用；Chat Completions 的函数调用有推理设置限制。旧应用即使只替换模型名，也应检查自己采用的端点和参数组合，而不是把模型存在等同于旧代码完全兼容。

预算中的长上下文不能沿用短上下文单价

两个模型的文档都写明：输入超过 272K token 时，整次请求采用不同费率，输入和缓存费率为基础费率的两倍，输出为一点五倍。这是计费门槛，不是上下文容量上限。

产品经理看到百万级窗口后，可能会提议把全部资料一次性提交。工程师此时应同时回答：这些资料是否必要，跨过计费门槛后要多花多少钱，以及按主题检索是否能达到同等质量。能放进去是一回事，值得放进去是另一项需要证据的判断。

三、如何读懂官方评测，而不把分数当作生产承诺

工作流评测：先看"完成"是怎么定义的

OpenAI 的公告报告，在 AutomationBench 中，GPT-6 Sol 在 xhigh 推理强度下得到 33.2%，每任务成本为 $0.27；表中 Claude Opus 5 的比较设置是 max，成绩为 26.9%。这些数字应保留模型和设置一起阅读。官方评测说明

对于业务人员，最值得追问的是评测如何判定任务完成。一次客服操作如果查对了订单，却更新错了状态，应算失败；一份分析即使文字通顺，遗漏用户要求的附件，也不能算成功。只有定义清楚，团队才能判断测试任务与自己的工作有多少重合。

这里的不同推理强度还提醒我们，模型名并不是全部实验条件。相同名称在不同设置下，耗时和 token 用量可能变化；跨模型比较若采用不同设置，更不能理解成完全相同资源预算下的结果。

编码评测：代码能运行之后，还需要什么

公告还报告，DeepSWE v1.1 中，Sol 和 Luna 在 max 设置下分别得到 68.8% 和 66.6%。这是官方对特定软件工程评测的报告，不能转换为"企业所有代码任务的成功率"。官方编码评测

开发团队可以据此决定是否值得试用，但试用任务必须贴近自己的代码库。修改一个独立函数与跨模块调整权限逻辑，所需证据不同；新增接口与修复一个只在特定环境出现的问题，也不能使用相同的验收标准。

检查时要看模型是否遵守项目约定，是否改变不相关行为，是否只增加了让当前样例通过的测试，以及最终说明中的"已验证"是否有对应记录。一个能通过测试的补丁仍可能有维护问题，而一段看起来漂亮的解释也可能掩盖未完成的工作。

计算机使用评测：分数相近，不能省掉流程验证

公告还涉及 OSWorld 2.0 的计算机使用评测，并注明部分奖励口径。阅读这类分数时，要先辨认统计的是部分进度还是完整任务成功率，再决定它与自己的验收标准是否相符。官方计算机使用评测

实际软件流程还可能遇到弹窗、页面变化、重复点击、加载超时和权限不足。测试应观察任务是否最终完成，操作顺序是否正确，遇到异常后是否能停在可恢复的位置，而不是只看模型能否识别按钮。

公告说明，评测环境可能与生产产品不同，竞品结果来自公开报告。上述数字更适合作为安排测试优先级的依据。企业自己的通过率、响应速度和人工复核需求，仍应来自自己的实验。

四、价格更低之后，API 预算应该怎么算

场景一：每天大量分类与信息提取

以下是预算演示，不是实测账单。假设一个系统每天处理十万条工单，每条请求计入两千个未缓存输入 token 和两百个计费输出 token，均未触发长上下文费率。为单独比较基础价格，假设不读取缓存，也不产生缓存写入或工具费用；输出数量已经包含按输出费率结算的推理 token。

一天的输入总量是两亿 token，输出总量是两千万 token。采用上表价格，得到：

模型	输入费用	输出费用	每日基础费用
GPT-6 Sol	200 × $2 =$ 400	20 × $10 =$ 200	$600
GPT-6 Luna	200 × $0.10 =$ 20	20 × $0.50 =$ 10	$30

这里两个模型按完全相同的 token 数量计算，基础费用相差二十倍。这个比例由本文设定的条件和公开费率共同得出，不能说明 Luna 在真实业务中的完成任务成本必然只有 Sol 的二十分之一。

假设某模型处理这些工单时，有十分之一的请求需要额外重试一次，并且重试的输入输出数量相同，调用费用就增加十分之一。更现实的情况是，重试可能带上错误说明和更长的历史记录，实际增量还得看用量记录。

人工成本也不能藏在模型单价后面。假设十万条工单中有百分之二需要人工复核，每条花三十秒，一天就是两千条、约十六点七小时的复核工作。这里没有给人工时间定价，但足以提醒团队：如果模型之间的质量差异让复核量发生变化，预算不能只比较 API 账单。

因此，高频任务的比较表应同时记录类别识别正确率、关键字段漏提率、重试比例和复核比例。一种错误被悄悄写入后续系统时，即便回答很快、输出很短，也不应把这条请求计为成功。

场景二：复杂文档与多步代理任务

再假设每天有一千个文档分析任务，每个任务经过十次模型请求。每次平均计入五万个未缓存输入 token，以及四千个计费输出 token；仍采用标准短上下文费率，并沿用不产生缓存读写、工具费用的简化条件。

每日共有一万次请求，累计输入五亿 token、输出四千万 token。Sol 的基础费用是 500 × $2 + 40 \times$ 10，即 $1,400；Luna 是 500 \times$ 0.10 + 40 × $0.50，即$ 70。对应每个完整任务的基础费用分别为 $1.40 和$ 0.07。

这里的五亿输入，是整天所有请求的累计量，不是单次上下文长度。多步任务会反复提交历史信息，所以一份不算特别长的原始材料，也可能在多轮交互中累计产生较大的用量。预算应累计每一步的实际输入和输出，而不是只统计用户上传文档的长度。

还应单独关注推理用量。官方文档说明，推理 token 不直接展示为最终答案，但占用上下文并按输出 token 计费。因此，用户看见一千字的报告，并不意味着计费输出只包含这份报告。上述示例中的四千个输出 token 是计费总量假设，不能在它之外再重复加一次推理费用。推理模型计费说明

缓存和长上下文，会改变哪一部分账单

缓存要区分首次写入与后续读取。官方提示缓存文档说明，符合条件的前缀可以先写入，再在后续请求复用；Sol、Luna 的缓存写入费率高于普通输入，读取费率则更低。只有实际复用后，才有对应的节省。提示缓存文档

预算时应把未缓存输入、缓存写入和缓存读取拆开，按照各自费率结算。不能把缓存写入价格理解成普通输入价格之外再叠加一次全额收费，也不能假设所有历史内容都会命中缓存。复用失败或频繁改变前缀，都可能让纸面预测与账单不同。

长上下文则有另一组规则。例如，一次请求包含三十万个未缓存输入 token 和五千个计费输出 token，输入已超过 272K 门槛。按文档倍率，Sol 应算 0.3 × $4 + 0.005 \times$ 15，合计 $1.275；Luna 应算 0.3 \times$ 0.20 + 0.005 × $0.75，合计$ 0.06375。此例仍不包含缓存写入、工具及区域附加费用。Sol 计费条件、Luna 计费条件

基础费用之外，还应把工具费用、重试、基础设施、人工复核和返工放进任务成本。对照任务完成记录后，再计算"每个通过验收的任务花了多少钱"。如果某种配置便宜但经常失败，它可能适合处理初筛，却未必适合承担最终交付。

按任务分层可以试，但要验证升级链路

本文建议的一种试验方案，是让 Luna 先处理规则明确、容易校验的分类与提取，让 Sol 或另一个经过验证的候选处理复杂分析。出现字段缺失、证据冲突或校验失败时，再升级处理。这个方案需要测试，不能作为既定的最佳架构。

升级也有代价：首轮调用已经花钱，第二轮还要接收材料和失败信息。若大量任务最终都要升级，直接使用另一配置可能更合算。路由条件还应尽量依靠可检查的证据，不要只凭模型自称"有把握"就跳过复核。

五、从试用到迁移：开发者和企业需要补齐的验证

先写验收标准，再准备任务样本

迁移实验最好从一张简单的验收表开始。分类任务要求类别正确；信息提取要求字段与原文一致；文档分析要求结论有证据；代码任务要求补丁满足需求并通过相关验证。不同任务应该有各自的检查项，不能只用"回答是否令人满意"覆盖全部业务。

再从真实任务中准备样本。可以先选两百个经过脱敏的案例，覆盖常见输入、长输入、信息缺失、条件冲突和历史失败样例。这是启动实验的建议规模，不能因为两百个样本全部通过，就宣称所有长尾问题都已解决。

样本还要有可检查的预期结果。提取任务可以附标准字段，复杂分析可以列出必须发现的事实和允许的不确定性。对于本来没有唯一答案的任务，应由业务人员写清评分规则，避免评审根据个人文风偏好随意打分。

调试用样本与最终验收样本应分开。否则，团队可能反复调整提示词，直到模型记住这批输入的套路，却无法判断对新的任务是否仍然有效。发生争议时，应回到证据和规则讨论，而不是凭印象选一个"看起来更聪明"的回答。

对比时，要让配置和用量能被追溯

现有模型必须进入同一轮对比。比较的目标是判断新配置相对当前系统是否有改善，不是让两个新模型彼此竞争后直接挑一个。对已经投入生产的应用来说，当前错误率和维护成本就是重要基线。

建议分两轮进行。第一轮尽量保留当前提示词、工具和任务条件，检查直接替换会发生什么；第二轮允许针对各候选作合理优化，但记录改动和调试投入。这样既能看到迁移兼容性，也能看到模型在适配后的能力。

每条结果至少记录模型名、调用时间、推理设置、提示版本、工具配置、输入输出用量、缓存情况和验收结论。失败样例保存足够的复现信息，同时避免把敏感内容不必要地写入日志。只有配置可以追溯，下一次版本更新才有可靠的比较对象。

模型本身的随机性也不能忽略。关键样例应安排重复运行，检查同一问题是否时好时坏。一个偶尔给出优秀答案的配置，未必适合无人值守的流程；实际选择可能更重视结果稳定，而不是某次测试的最高质量。

看分组表现，不让平均分掩盖重要错误

速度至少要区分首次返回与完整任务完成时间。交互式产品可能在意用户多久看见第一段内容，后台批处理则更在意整批任务多久完成。多步代理还要加入工具等待时间，否则模型生成很快也未必让业务变快。

质量也应分组看。假设模型在常见分类上表现很好，却经常把稀有退款原因归入普通咨询，总体正确率可能仍然漂亮，但错误集中在需要重点处理的业务。团队应单独报告关键类别、长文档和历史失败集的结果。

结构化输出则要经过程序验证。字段齐全不代表内容正确，格式合法也不能证明日期、金额或编号与来源一致。应用应区分格式失败、事实失败和工具失败，为不同问题准备不同处理路径，避免遇到任何异常都重新请求一次。

小范围试用，要有明确的扩大和停止条件

离线验证通过之后，可以先在不影响实际业务操作的环境中运行，或者让新配置只生成待人工确认的结果。对于会写入外部系统的任务，先验证读取、建议与执行之间的边界，再逐步扩大范围。

一套示例验收条件可以是：关键类别召回率不低于现有配置，普通任务通过率下降不超过一个百分点，完成时间满足原有服务目标，总任务成本至少降低两成，试用期间不出现未经授权的写入。这里的阈值是作者提供的示例，团队应在实验前结合自身目标固定下来。

如果成本下降来自大量拒绝处理，或者节省的调用费用被人工复核抵消，就不应据此扩大试用。反过来，即使新配置单次请求更贵，只要返工明显减少、交付更可靠，也可能值得保留。最终验收看的是业务目标，不是追求一个孤立的价格比例。

回退方案应在试用之前准备好，包括恢复哪个模型、哪些参数要同时恢复，以及已执行到一半的任务如何处理。尤其涉及订单、库存等写操作时，要检查重复执行风险；不能认为切回旧模型就自动撤销了此前产生的结果。

旧模型退役，已经有具体事项需要跟进

截至本次核验，官方退役文档记录：gpt-5.3-codex、gpt-5.1 和 gpt-5.4-nano 已于 2026 年 10 月 1 日宣布弃用，计划在 2027 年 4 月 1 日从 API 移除；对应建议替代模型分别是 gpt-6-sol、gpt-6-sol 和 gpt-6-luna。官方退役时间表

这意味着仍使用上述模型的团队，需要把迁移验证排进工作计划。官方推荐替代项给出了起点，但不会替企业验证提示词、工具行为和业务结果。上述日期也只适用于列出的模型，不能扩展成整个 GPT-5 家族统一退出的时间。

六、把文章变成可更新的选型参考

模型发布后，参考文章的维护重点可以分成两类：官方资料发生变化，以及业务验证得到新结果。前者要求重新核对参数和计费规则，后者要求调整任务分配与上线条件，两类更新都应记录来源和日期。

下面的清单截至 2026 年 10 月 10 日。表内"已公开"表示官方资料可以查询，不代表该项已通过本文的业务实测。

项目	官方状态	业务待验证项	来源	核验日期
上下文窗口	两模型参数已公开	长材料引用、跨段推理、输入位置影响	模型文档	2026-10-10
模态与工具	原生模态及工具能力已列出	图片质量、工具组合、端点兼容	Luna 文档	2026-10-10
定价	基础、缓存及长上下文条件已公开	实际用量、缓存命中、重试与复核成本	Sol 文档	2026-10-10
评测	官方公布多项报告	自有样本通过率、延迟和长尾错误	发布公告	2026-10-10
旧模型退役	部分旧模型已有关闭日期	本项目调用清单、迁移排期、回退条件	退役文档	2026-10-10
后续版本	GPT-6.1 Sol 已公布	单独对比新版配置，避免沿用旧评测结论	后续公告	2026-10-10

维护时，不必每出现一条新消息就重写全文。价格变化优先重算预算，接口变化优先检查兼容，模型更新优先回归关键样例，关闭日期变化优先调整排期。每次修改都写明改变了哪条事实，以及它影响哪项判断。

来源发生冲突时，也不要自行拼出一组看似完整的参数。例如，把 GPT-6.1 Sol 的缓存价格放进 GPT-6 Sol 表格，再沿用旧模型评测，会得到一个现实中不存在的配置。应该先核对模型名、服务层级与计费条件；仍无法解释的差异就保留为待确认项。

官方开放范围也具有时间性。发布当天的产品说明适合记录历史，不应自动作为今天所有账号、地区和产品入口的承诺。真正准备接入时，应检查自己的 API 权限、配额以及相关工具是否可用，把账号条件与模型能力分别记录。

如果今天开始评估，可以先导出当前系统的模型调用清单，挑出一类容易核验的高频任务，再用同一组样本运行现有配置与两个候选。记录正确结果、失败原因、完整耗时和总费用。等这份对照表能够解释收益与代价，再决定下一步迁移范围。