★ FEATURED ARTICLE 文章目录一、两天四家发布选型窗口为什么变短了二、价格表里“便宜一半”需要拆开理解三、三种账单模拟把你的请求分布代进去输入较多文档提取和批量分类输出较多草稿、解释与报告生成高缓存命中共享上下文的连续任务四、价格下降之后迁移还要算哪些成本把缓存写入补回费用公式从一次调用追到一个成功任务毛利与回本应该用金额计算五、多模型路由收益边界在哪里预先分流每个任务只调用一个模型先尝试再升级失败任务支付两次调用有效的检查要能发现业务失败六、用一周做出可复核的迁移决定参考资料注事件与主价格表采用 2026 年 9 月 22 日的发布快照资料复核于 2026 年 10 月 10 日。文中账单均为明确设定条件的模拟不是生产实测也不是当前采购报价。如果你的应用还按上个月的模型价格做预算这一轮发布值得重新算一次账。同样一批请求换用新模型后输入和输出的单价都可能明显下降。但一张降价表还回答不了团队最关心的问题月底到底少付多少钱是否值得投入工程师时间迁移以及省下的钱会不会被重试和人工修改吃掉。2026 年 9 月 22 日Claude Opus 5.5 与 GPT-6 Sol、GPT-6 Luna 在同一天发布。对普通用户这是一次产品更新对依赖 API 交付服务的团队它直接改变了若干工作负载的预算起点。尤其是 Luna 这一档降价后的单价足够低重新检查原先因成本被搁置的功能已经有了具体的理由。本文先还原事件和价格再用三组可复算的 token 分布讨论迁移收益最后把重试、缓存、路由与评测接回账单。你可以把示例里的数量替换成自家日志但应当保留其中的计费分类和假设条件。一、两天四家发布选型窗口为什么变短了根据 Simon Willison 的当日记录9 月 21 日先有 x.ai 的 Grok 4.7 和小米 MiMo v2.6 Flash/Pro次日 Anthropic 发布 Opus 5.5约一小时后 OpenAI 发布 Sol 与 Luna。“约一小时”是 Simon 对发布顺序的记录并不证明两家公司存在临时跟价安排。日期也不能写得含混。这组材料直接支持的是两天内四家集中发布而不是四家在同一周里都完成了连续降价。发布模型和调整价格是不同事实缺少旧价对照时不应把每次上新都算作一次降价。对于已经有稳定业务的团队集中发布容易打断原来的评测节奏。上午刚把一个候选模型接进测试环境下午又出现了新的价格和能力组合采购讨论如果持续几周最初那张比较表可能已经需要更新。这里的变化主要来自候选方案增加并不要求团队当天就作出最终决定。团队可以把工作分成两个节奏价格变化当天更新预算能力判断等代表性任务跑完后再更新。前者只需要核对报价和用量后者需要正确答案、业务规则和足够样本。把两项工作混在一起往往会因为一张低价表提前承诺质量也可能因为评测尚未结束迟迟没有发现已经确定的预算机会。Simon 对 GPT-5.6 Luna 的喜爱来自他自己的应用开发体验不能直接变成所有团队的选型结论。他同时保留了一个重要判断理解这些新模型仍然需要时间。本文也按这个边界展开不依据发布热度给出跨模型能力排名。我的判断是这种密集发布会让“多久能完成一次可信评测”更有商业价值。一个团队若已经能按任务类型回放请求、统计费用和保存失败样本就能较快识别适合自己的候选模型如果每次换模型都要临时整理数据、手动改多处代码低价优势可能在迁移前就被工作量消耗掉。这并不意味着小团队必须建立复杂的评测平台。一份有答案的任务集、一处集中管理的模型配置以及按业务任务汇总的用量日志就能先解决大部分问题。选型窗口变短时有准备的团队可以先测试最可能受益的那部分流量。二、价格表里“便宜一半”需要拆开理解下表使用美元百万 token也就是美元1M token。缓存输入列指缓存读取不包含缓存写入这些是发布时比较用的基础费率不是覆盖所有上下文长度、处理档位和附加服务的完整价目表。OpenAI 对照使用标准处理的短上下文费率Grok 使用基础上下文档位月度累计输入量不能用来判断单次请求是否进入长上下文价格档。模型普通输入缓存读取计费输出GPT-6 Luna$0.10$0.01$0.50GPT-5.6 Luna$0.20$0.02$1.20Grok 4.7$2.00$0.50$6.00GPT-6 Sol$2.00$0.20$10.00GPT-5.6 Sol$4.00$0.40$20.00Claude Opus 5.5$4.00$0.20$20.00Claude Opus 5$5.00$0.50$25.00新 Sol 和 Luna 的三项基础费率可对照 OpenAI 9 月 22 日 API 更新记录。旧款 OpenAI 价格取自 Simon 的历史价格表Opus 新旧价格见 Anthropic 发布公告。Grok 的输入、输出价见 发布公告缓存读取价由 官方模型文档交叉核对。从 GPT-5.6 Luna 到 GPT-6 Luna普通输入从 0.20 降至 0.10缓存读取从 0.02 降至 0.01两项都下降 50%。输出从 1.20 降至 0.50降幅则是约 58.3%。只写“便宜一半”会漏掉输出量较大业务的额外收益。Sol 的三项基础费率恰好都是旧款的一半因此在这三种计费 token 数量完全相同、没有其他收费变化时模型费用会下降 50%。但如果新模型生成了更长的答案、执行了更多步骤实际支出仍然可能偏离这个比例。Opus 5.5 的普通输入和输出单价各比 Opus 5 低 20%缓存读取单价低 60%。Anthropic 宣称默认设置下典型工作负载成本可低 40%这是厂商对其测试任务的结果描述包含 token 使用效率的变化不能写成“所有 API 单价都降了 40%”。还需要注意跨模型比较的含义。Sol 与 Grok 在普通输入上的基础单价相同但缓存读取和输出价格不同Opus 与 Sol 的任务能力、行为和所需步骤也不能由价格推导。价格表可以筛选预算候选项不能证明某个模型能以同等质量完成另一模型的任务。同样百万 token 的单价不能当作百万字的价格。输入的编码方式、上下文内容以及生成的工具参数都会影响用量。如果采购人员只有“每月处理多少篇文章”的统计就应先抽取一批任务取得计费 token避免把业务数量直接乘上模型单价。三、三种账单模拟把你的请求分布代进去下面三组案例只比较普通输入、缓存读取和计费输出假设缓存写入数量为零不含工具、区域处理、长上下文或其他费用也不模拟模型能力差异。这里的“月度”只是一个便于预算的统计周期不对应任何公司的实际业务。令 U 为普通输入数量R 为缓存读取数量O 为计费输出数量基础费用为基础费用 (U × 输入单价 R × 缓存读取单价 O × 输出单价) / 1,000,000 节省比例 (旧费用 - 新费用) / 旧费用如果日志里的输入总量已经包含缓存读取应当先扣除这部分再得到 U。公式里的 O 是计费输出总量不只是屏幕上可见的答案文字。按任务记录模型调用能避免一个业务请求触发多次调用时少算费用。输入较多文档提取和批量分类设一个月普通输入为 8000 万 token没有缓存读取计费输出为 500 万 token。它可以用来模拟读取较多材料、返回较短结果的任务具体数量仅为演示设定。旧 Luna 的费用是 80 × 0.20 5 × 1.20即 16 6共 22 美元。新 Luna 为 80 × 0.10 5 × 0.50即 8 2.50共 10.50 美元。节省 11.50 美元降幅约 52.3%。在固定 token 分布下这个比例高于 50%因为输出部分的降幅更大。不过一个月节省十几美元通常不足以支付专门迁移的工程投入。对已有统一模型接口、只需改配置并回归测试的应用收益可能值得取得若要重写工作流单凭这笔账还不充分。这个例子也说明了为什么要同时给出比例与金额。一个比例很漂亮的成本优化可能只节省很少的钱。对低用量应用模型是否稳定返回可用结果、是否减少维护工作可能比基础推理费更值得先评估。输出较多草稿、解释与报告生成第二组设定为普通输入 1000 万 token计费输出 4000 万 token同样没有缓存读取。旧 Luna 费用为 10 × 0.20 40 × 1.20即 2 48共 50 美元。新 Luna 为 10 × 0.10 40 × 0.50即 1 20共 21 美元。费用下降 29 美元降幅 58%。输出越占主要支出固定用量下的下降比例就越接近输出单价的降幅。但更长的答案不自动代表更高价值一份报告需要三页生成八页之后再人工压缩会增加计费输出和编辑工作。这里可以做一个敏感性检查。若新模型输出量增加到原来的两倍输入不变新账单变为 1 80 × 0.50即 41 美元。它仍低于旧费用但降幅只剩 18%距离最初的 58% 已经很远。因此评测应记录交付标准下的输出量比如是否回答完必需的问题、是否包含冗余段落、是否需要补充证据。先规定结果应当完成什么再比较完成同一任务的费用才不会把“模型写得更多”误当成“业务得到更多”。高缓存命中共享上下文的连续任务第三组设定为普通输入 1000 万 token、缓存读取 9000 万 token、计费输出 500 万 token。输入总量是 1 亿其中缓存读取占 90%。这里的 90% 是按输入 token 计算不能写成 90% 的请求命中了缓存。旧费用为 10 × 0.20 90 × 0.02 5 × 1.20即 2 1.80 6共 9.80 美元。新费用为 10 × 0.10 90 × 0.01 5 × 0.50即 1 0.90 2.50共 4.40 美元下降约 55.1%。高缓存命中率很适合观察长期复用上下文的效果但读便宜不代表首次建立缓存免费。实际记录中存在缓存写入时必须增加这一类别本文随后会展示如何修正不能直接拿 4.40 美元当作所有长期对话的完整报价。还要测试迁移后的缓存分布。假设新模型缓存读取从 9000 万降到 5000 万 token其余 4000 万改按普通输入计费在同样不含写入费用的条件下新账单为 50 × 0.10 50 × 0.01 5 × 0.50即 8 美元。它比旧费用低约 18.4%但已经不是 55.1%。这三组结果可以放在一起看模拟场景普通输入缓存读取输出单位百万 token旧 Luna 费用新 Luna 费用降幅输入较多8005$22.00$10.5052.3%输出较多10040$50.00$21.0058.0%高缓存命中10905$9.80$4.4055.1%这些数字来自同一组 token 数量乘以不同单价。用它们做预算第一轮筛选很方便真正决定是否迁移还需要用新模型跑相同任务取得它自己的用量和成功结果。四、价格下降之后迁移还要算哪些成本把缓存写入补回费用公式为复算完整输入费用最好把输入拆成三个互不重叠的类别普通输入 U、缓存读取 R、缓存写入 W。总输入等于 U R W输出仍使用计费总量 O。于是完整模型费用是模型费用 (U × 普通输入价 R × 缓存读取价 W × 缓存写入价 O × 输出价) / 1,000,000这是对基础示例的补充不是把同一批 token 再收一次普通输入费。按 2026 年 10 月 10 日复核的 OpenAI 缓存文档缓存写入费率替代该部分输入的普通费率不能把两项完整费用相加。这里说明的是复核时的规则不将动态文档中的全部细节倒推为发布当天记录。例如对第三组新 Luna 账单若原先按普通输入计入的 1000 万 token 中有 500 万实际属于缓存写入采用复核时标准基础写入价 0.125 美元百万 token那么 U 应改为 500 万W 为 500 万。费用变成 5 × 0.10 90 × 0.01 5 × 0.125 5 × 0.50即 4.525 美元而不是给原来的 4.40 美元再加 0.625 美元。写入价格来源这个差异在低价模型的小样本里不大放到大量重复建立上下文的应用中就值得单独看。没有写入数量的日志只能做部分费用估计。预算表应把“缺少计费类别”写出来避免一个看似精确的小数掩盖不完整的数据。从一次调用追到一个成功任务一次业务任务可能经历提取信息、调用工具、生成答案和校验也可能在失败后再次请求。比较模型时需要把这些步骤归到同一个业务任务编号下。否则新模型的一次调用便宜整个任务却调用更多次汇总后仍可能更贵。计费输出也不能只数用户看到的字。OpenAI 的 用量文档说明推理 token 包含在输出用量中并按输出计价缓存读取包含在输入总量中。如果已经采用输出总量就不能再把其中的推理子项完整加一次。其他服务的用量字段则需要按各自文档映射。可用的业务指标是同一统计周期内全部任务尝试的交付成本除以最终成功的业务任务数。分子保留失败、重试和回退支出分母按照业务验收计算不能只统计“接口返回成功”的请求。工具费用和人工复核也要采用固定口径。做一个独立模拟方案甲每次尝试花 0.01 美元100 次尝试中有 90 次达到标准方案乙每次只花 0.006 美元却只有 50 次合格。两者每个合格任务的模型费分别约为 0.0111 和 0.012 美元。乙的调用单价更低在这个样本里交付一个可用结果反而更贵。这里没有模拟继续重试只是说明成功率已经足以改变结论。人工修改也有类似效果。模型账单省了几分钱却多用一分钟编辑时间收益可能就消失了。团队可以给抽样任务记录修改分钟数再按内部固定的核算标准折算不需要假装每个行业都有相同的人力单价。毛利与回本应该用金额计算假设一个产品月收入 1 万美元模型费用 2000 美元其他交付成本 3000 美元。为演示暂把这两类都归入同一简化毛利口径原毛利为 5000 美元毛利率 50%。模型费降到 1000 美元、其他条件不变后毛利为 6000 美元毛利率 60%。结果是毛利率增加 10 个百分点毛利金额增长 20%并没有翻倍。若随后给用户扩大用量、增加模型调用支出还会重新上升。降价释放了预算空间最终留在账上的收益取决于产品如何使用这个空间。迁移投入应包含适配、回归测试、提示词修改与短期维护。设一次性投入 1200 美元每月模型费用少付 400 美元但新增监控和复核成本 100 美元则月度净节省是 300 美元静态回本约为四个月。净节省小于或等于零时这个算法不存在正的回本期。四个月也不是一个无条件承诺。流量可能改变旧模型报价可能变化适配工作可能超出预期。预算可以保留保守、基准和高用量三种情形但每种都应使用可解释的用量假设。对调用费已经很低的项目优先修掉重复请求、失控循环或明显的人工返工往往比追逐小额单价差更值得尝试。五、多模型路由收益边界在哪里路由的基本思路是按任务需要选择模型。字段抽取、已知类别分类和格式改写可以成为低价候选任务需要综合多份材料、判断复杂约束或修复代码的任务可以保留更强模型。这里描述的是待评测的分工方式不是断言 Luna 必然胜任某个业务。先从可解释的规则做起比如输入长度、任务类型、工具数量和是否需要修改代码。用另一个模型负责分流也可以但这次判断本身会花钱还会发生误判。记录它分错了哪些任务比只记录它把多少流量送到低价模型更有用。下面继续使用不含缓存写入的第三组分布缩小到每个任务普通输入 1000、缓存读取 9000、计费输出 500 token。假设两模型用量相同那么 Luna 单次成本 L 为 0.00044 美元Sol 单次成本 H 为 0.0088 美元。这是一组便于计算的设定不代表模型完成真实任务时用量相同。预先分流每个任务只调用一个模型设有 10 万个任务90% 直接交给 Luna10% 直接交给 Sol。忽略分流成本时费用为 90000 × L 10000 × H即 39.60 88共 127.60 美元。全量直接使用 Sol 的费用是 880 美元预先分流在这组设定中降低约 85.5%。这个比例来自多数任务转向低价模型不能当作全行业可实现的节省也不说明合格率已经保持不变。若分流发生错误团队要明确处理方式。把复杂任务送到 Luna 可能导致结果不合格把简单任务送到 Sol 则主要增加费用。两类错误的代价不同因此路由阈值需要按业务验收调整不能只追求最低平均支出。先尝试再升级失败任务支付两次调用另一种策略是每个任务先调用 Luna检测到不合格时再调用 Sol。若升级比例 q 为 10%费用是 100000 × L 10000 × H即 44 88共 132 美元降幅 85%。它比预先分流多出 4.40 美元因为需要升级的那一万次任务也先支付了一次 Luna。一般公式为“任务数 ×L qH”不能写成“任务数 ×1 − qL qH”后一个公式对应的是预先分流。再假设每个任务的质量检查成本 V 为 0.0003 美元10 万个任务增加 30 美元总费用便是 162 美元降幅约 81.6%。如果升级时会重复发送完整材料、追加失败答案或执行额外工具还需要将 H 换成实测的升级调用成本。在这些简化条件下先尝试再升级要比全量 Sol 便宜须满足 L qH V H。当 V 为零时这组单价对应 q 95%加入上述检查成本后边界降到约 91.6%。这是费用相等的理论边界不是建议把九成任务都先交给 Luna。接近这个边界时延迟和维护投入尚未计入策略很可能已经缺乏实际意义。有效的检查要能发现业务失败对于结构化提取检查应当包括 JSON 解析、必需字段、字段类型以及金额、日期等业务约束。合法 JSON 只能证明结构可读取无法证明内容正确。生成代码则需要相应的执行和测试结果不能依据模型说“已经完成”就关闭任务。错误也未必适合重试同一种策略。材料缺失时应补充数据或交由人工处理工具超时时可以按已有规则有限重试复杂推理不合格时才考虑升级模型。给每个业务任务设置调用次数、累计成本和总耗时上限能避免降级与回退反复循环。路由还会改变缓存。跨模型切换不应默认继承原有命中率提示词和上下文组织发生变化后也需要重新统计。对于用户必须等待的任务先调用再升级会叠加等待时间后台批量任务可能更能接受这种流程。省多少钱和等多久需要一起报告。六、用一周做出可复核的迁移决定这里给出一个示例工作安排。“一周”是团队可以采用的实施节奏不是新模型已在一周内被充分评估的事实。低流量业务或复杂工作流需要更长观察日期应服从样本覆盖和业务验收。第一天先整理最近一个完整业务周期的用量。把任务编号与每次模型调用关联起来分开记录普通输入、缓存读取、缓存写入、计费输出、重试、工具费和最终结果。价格也要保存模型版本、处理档位与日期。仅有账户总账通常无法知道哪个业务最值得迁移。可以按下面的清单整理数据字段是业务记录建议不是某家 API 的响应结构业务任务编号、调用序号、任务类型、模型及版本、价格日期 普通输入 token、缓存读取 token、缓存写入 token、计费输出 token 模型费用、工具及其他费用、总耗时、失败原因 是否最终合格、人工修改分钟数、是否发生升级或回退第二到三天准备离线任务集。可先抽取约 300 个正常、困难与历史失败任务按主要业务类别分别保存有明确答案的任务优先保留答案没有唯一答案的任务写出验收标准。这个数量只是起步建议不能据此宣称覆盖罕见错误。生产材料应按组织的数据授权和脱敏要求使用。回放时固定输入材料、业务验收和工具环境。先按新旧模型都支持的相近设置比较再单独调整提示词或推理设置否则一次变动太多很难判断收益来自哪一项。需要重复运行的随机性任务应保留多次结果不能拿最好的一次充当整体表现。第四天整理结果按任务类型分别比较合格率、每个成功任务成本、结构化输出错误、工具调用失败和人工修改时间。延迟同时看中位数与较慢一端比如 P95避免平均值隐藏少数长时间等待的任务。一个总体平均值也可能掩盖小类业务明显退步。在汇报节省时还可以把结果拆成三项单价变化、每个任务用量变化和业务量变化。先固定旧任务的数量与分布重算新价得到纯价格因素再代入新模型完成同类任务的实际用量观察行为差异最后才代入新周期的业务规模。这样能区分价格带来的收益与流量缩减造成的账单下降也能发现业务增长掩盖了单任务成本改善。采购表应保留生效日期和费用边界。合同折扣、最低消费、区域档位和上下文分档会让公开价与实际结算不同不能把不同条件的数字放在同一列后直接排名。对于有承诺用量的客户更换模型后是否仍需支付原定最低金额也应依据自己的合同核对。本文用公开基础费率解释计算方法实际迁移预算则应回到团队可以获得的结算条件。第五到七天可以让候选模型承接少量符合条件的真实流量例如先选 5%。这个比例只是演示起点需要结合业务影响决定。保留原路径避免同一个外部操作因回放而执行两次真实流量的费用、缓存与失败分布应与离线预测对照。上线标准最好在试运行前写好。比如低风险文案业务可以要求各主要任务类别合格率达到已有标准每个成功任务成本低于旧路径较慢请求耗时没有超过允许范围人工修改时间没有明显增加。阈值应由原系统表现与业务要求确定本文不替团队设定统一分数线。回滚触发条件也应具体。某类关键字段频繁错误、用户等待超过约定时限、升级率突然升高或累计费用超预算都可以触发恢复原模型配置。恢复之后保存失败任务、版本和调用记录先查原因再重新试运行而不是简单认定“新模型不稳定”。这轮发布最值得开发者带走的是重新测算的理由。价格下降已经可以用表格核算能力是否适配仍要通过任务验证。能够交付合格结果、减少人工返工并保持可控费用的方案才值得进入正式流量。现在可以先做一件具体的事导出一个完整周期的计费记录选出费用最高或最容易迁移的业务按本文四类 token 公式重算一次。若净节省足以覆盖适配投入再用代表性任务验证若节省很小也就有了继续使用现有方案的明确依据。参考资料Simon WillisonClaude Opus 5.5, GPT-6 Sol, GPT-6 Luna, and a new price war发布顺序、历史价格与个人体验。OpenAIIntroducing GPT-6 Sol and Luna及 API Changelog发布说明与 9 月 22 日基础费率。AnthropicIntroducing Claude Opus 5.5Opus 新旧价格与厂商成本评估。x.aiIntroducing Grok 4.7及 模型文档发布日期与基础价格。OpenAIPrompt caching、Pricing、Observability and usage复核时的计费规则与用量口径。以上来源于 2026 年 10 月 10 日访问动态文档可能后续更新历史分析与实际采购请分别使用对应日期和档位的报价。
阅读完成 · 觉得有帮助？
