GPT-6 Sol与Luna降价一半,模型竞争转向单位任务成本

OpenAI把GPT-6 Sol与Luna的API价格降到上一代约一半,其中Luna每百万Token输入0.1美元、输出0.5美元,已经进入低价模型的竞争区间。这次发布真正改变的,不只是价目表上的数字,而是大模型服务的比较单位:当模型能够完成编程、电脑操作和多步骤Agent任务,企业和开发者需要衡量的就不再是每百万Token多少钱,而是完成一项可验收工作到底花多少钱。

OpenAI公布的测试显示,Sol在部分专业工作和智能体基准中以更低的单任务成本取得有竞争力的结果;Luna则面向大量、重复、风险较低的任务。与此同时,提示词缓存和中途调整推理强度等机制也被纳入成本控制。新一轮模型竞争因此呈现出更清晰的分层:旗舰模型负责能力上限,中档模型承担复杂日常工作,低价模型接住高频调用,系统再通过缓存与任务路由减少浪费。

价格下降改变了比较方法

GPT-6 Sol从上一代较高价格降到每百万Token输入2美元、输出10美元;Luna进一步降到0.1美元和0.5美元。OpenAI称价格调整与推理基础设施和缓存效率改善有关。仅看Token单价,开发者容易把它理解为一次促销;但模型实际执行的任务可能消耗数千甚至数万Token,单价只是成本公式的一部分,推理时长、重试次数、上下文长度和人工返工同样会影响最后的账单。

因此,更有参考价值的数字是任务成本。OpenAI披露,在AutomationBench等专业工作流测试中,Sol以较强推理设置取得33.2%的成绩,报告的单项任务成本约为Claude Opus 5相应测试成本的9%;在Agents’ Last Exam中,Sol的成绩为56.4%,公司称单项任务成本低约六成。这些是厂商公布的基准结果,不能直接等同于每家企业的生产表现,但至少说明模型供应商已经开始把“花多少钱把活办完”放到发布主叙事里。

对采购团队来说,可以把费用拆成模型调用费、数据整理费、人工复核费和错误恢复费四项。不同供应商的Token计量方式、缓存折扣与上下文规则可能不同,测试时要统一任务输入和成功条件,并把未完成、超时和重复执行都计入成本。只有用同一把尺子比较,低价模型的真实优势才不会被宣传口径放大或掩盖。

模型分层对应不同工作

Sol和Luna并不是简单的高低配命名。按OpenAI给出的定位,Sol面向需要较强推理、编程与Agent能力的主流专业任务,Luna则针对高频、规模化且对成本敏感的调用。与面向最高能力上限的Astra相比,这种产品组合试图把昂贵的最强推理从每个请求中移开:只有任务确实需要时才调用旗舰模型,其余工作交给成本更低的版本。

这种分工需要应用层真正识别任务,而不是让用户手动猜模型。比如代码审查可以先由轻量模型归类风险,再把复杂缺陷交给Sol;客服请求可先由Luna检索并整理,涉及退款、合规或高风险承诺时再升级审核。路由错误会抵消降价收益:简单任务频繁升级会白白增加费用,复杂任务被压给弱模型则会带来错误和返工。模型价格战最后会落到任务拆分、权限控制和验收标准这些工程细节上。

电脑内部存储与供电组件近景,体现模型推理对计算资源和成本的依赖
配图依据=文章核心新闻点:新模型以更低推理成本承接编程与智能体任务,竞争焦点从Token单价延伸到单位工作成本。

还要注意,不同任务对“好结果”的定义并不相同。摘要任务可以检查事实覆盖和引用准确性,代码任务要运行测试并审查改动,客户服务则需要核对政策边界和语气。把所有场景压成一个综合分数,可能掩盖模型在关键步骤上的短板;分场景建立验收集,才能知道哪些请求适合低价模型,哪些必须交给更强模型或人工处理。

基准成绩还要经过生产检验

发布基准可以显示能力趋势,却不能代替真实业务验收。公开测试集的任务边界、工具权限、提示方式和失败处理机制,未必与企业内部系统相同。OpenAI披露Sol在真实代码库工程测试中的成绩接近部分高端模型,同时成本显著降低;这能帮助开发者筛选候选模型,但部署前仍应使用自己的代码仓库、工单和文档做盲测,统计正确率、人工接管率、延迟和总成本。

尤其是Agent任务,“完成”不能只按模型是否给出答案计算。模型有没有改动不相关文件、是否调用了不该访问的工具、失败后能否回滚、结果能不能复现,都会影响实际价值。若一次低价调用造成生产事故,修复和审核费用可能远高于节省的推理费用。评测应把成功率与风险一并记录,并对发邮件、付款、删除数据等高影响操作设置人工确认。

缓存让长流程重新算账

此次更新还强调提示词缓存。持续工作的Agent会反复读取相同的系统指令、代码库片段和任务背景,如果每轮都按完整输入重新计费,长流程成本很容易快速累积。缓存让重复前缀可以较低成本复用,开发者也能查看缓存命中情况,调整提示词结构和显式断点,让稳定内容尽可能保持一致。

缓存不是免费的捷径。频繁改写提示词前缀、把易变信息放在固定内容之前,都会降低复用效果;缓存过期、模型切换和上下文更新也需要纳入实际测算。更重要的是,缓存只减少重复计算,并不会自动缩短任务或提升答案质量。应用团队应比较缓存开启前后的单次任务总费用、响应时间与质量,避免只盯命中率而忽略额外Token和失败重试。

低价竞争考验服务生态

当前沿模型降价进入日常开发者预算,更多团队可以尝试长时间运行的编码Agent、批量文档处理和多步骤业务自动化。但低价本身不会自动带来稳定供给。速率限制、峰值延迟、区域可用性、服务条款、数据保留政策和故障时的回退策略,都会影响模型能否承担关键工作。企业选型时需要把这些条件和模型能力放在同一张表里评估。

接下来的竞争很可能同时发生在模型和系统两层:一边是更便宜、更强的模型,另一边是更会分配任务、复用上下文、限制权限并验证结果的应用架构。对开发者而言,值得跟踪的不是某个榜单名次,而是同一项真实任务在不同模型、不同缓存策略和不同审核规则下的单位交付成本。只有质量、风险与费用都可测量,降价才会转化成可持续的生产效率,而不是一张看起来漂亮的API价目表。

© 版权声明
THE END
喜欢就支持一下吧
点赞5 分享