GPT-6.1 Sol 成本怎么算：缓存、长上下文与模型路由预算

以 2026 年 9 月 30 日核验的官方页面为准，GPT-6.1 Sol 的标准短上下文价格为：每百万 Token 普通输入 2 美元、缓存输入 0.10 美元、缓存写入 2.50 美元、输出 10 美元。Batch 和 Flex 还有单独价格，快速模式、区域处理和长上下文也可能改变账单。当前模型价格

但这几个单价不能直接回答“一个任务要花多少钱”。生产系统的费用还会被输出长度、缓存命中、工具调用、失败重试、模型降级和人工修正改写。要做可靠预算，应该把账单提升为“单位合格交付成本”，按任务而不是按一次请求核算。

一、先把四种价格分开

基础账单至少包含四类 Token：

以标准价格做一个简单估算：一次请求使用 100K 普通输入 Token、20K 计费输出 Token，费用约为 0.2 + 0.2 = 0.4 美元；如果其中 80K 输入来自缓存，不能直接把全部输入乘以 0.10 美元，还要确认首次写入、命中范围和请求是否真的共享了相同前缀。这是假设算例，不是已完成的模型实测。

官方定价页是动态页面，价格和模式应在上线前重新核对：API 定价

二、长上下文会改变预算

GPT-6.1 Sol 的上下文窗口是 1,050,000 tokens，最大输出是 128,000 tokens。能装下不代表适合每次都塞满。模型页说明，超过 272K 输入 Token 时，整个请求的输入和缓存费率为短上下文的两倍，输出费率为一点五倍，不是只对超出部分加价。长上下文规则

因此，长上下文预算至少要做三档：

短上下文：小于 32K
中上下文：32K 至 272K
长上下文：超过 272K

每档分别测量输入 Token、输出 Token、缓存命中量、延迟和失败率。不要用短上下文的平均单价去外推百万 Token 级任务，也不要因为上下文窗口很大，就把历史消息、工具结果和重复文档全部原样保留。模型规格

三、Prompt 缓存不是自动打折按钮

Prompt caching 复用的是可重复的前缀。官方缓存指南说明，后续请求要匹配相同的已渲染前缀；模型、工具定义、开发者消息、对话历史、文本和文件等内容都可能影响前缀。只要前面某处发生变化，后面的内容就可能无法继续命中。Prompt caching 指南

GPT-6.1 Sol 的缓存输入价格是普通输入的 5%，缓存写入按普通输入的 1.25 倍计费。缓存写入不是附加费：同一输入 Token 应按普通输入、缓存读取或缓存写入中的适用类别计算，不要同时收两次。缓存适合复用稳定的系统说明、工具 schema、产品知识和固定规则。缓存定价口径

可以把请求结构整理成：

稳定系统说明
稳定工具定义
稳定业务规则
可复用文档片段
本次用户输入
本次工具结果

如果使用显式缓存，要记录断点位置和命中情况；如果使用隐式缓存，也要通过 usage 字段确认实际命中，而不是看到请求很像就假定发生了折扣。

四、建立任务级成本公式

建议把账单和工程成本放进同一张表：

任务成本 = 普通输入成本
         + 缓存写入成本
         + 缓存输入成本
         + 输出成本
         + 工具成本
         + 重试成本
         + 人工修正成本

其中人工修正成本不能省略。一个首轮费用很低、但经常需要开发者重写的模型，单位合格交付成本可能高于单价更高的模型。公式采用分项口径：前几项仅算首轮，重试成本补上后续尝试；如果直接汇总了所有请求费用，就不能再额外加一次重试费。

建议每条任务日志至少包含：

task_id
model
reasoning_effort
input_tokens
cached_input_tokens
cache_write_tokens
output_tokens
tool_calls
retry_count
latency_ms
human_fix_minutes
accepted

上面的字段是应用侧建议账本，不是承诺 SDK 返回同名字段。映射时要保留原始 usage，依据当前文档确认普通输入、读取和写入之间的关系，再计算互不重叠的数量。若无法辨认缓存写入，先标注数据缺口，不要把它记为零。

用整组任务的总成本除以实际验收通过的任务数，得到“每次合格交付的平均成本”。失败任务的费用也包含在分子里，而不能只统计成功请求。若没有任何任务通过，该指标应标为不可计算，不能显示零成本。对于失败任务，还要区分参数、服务、工具和质量错误。

五、一个含写入与读取的完整算例

下面只是标准短上下文的假设算例，不是实测账单。设每次请求包含八万 Token 稳定前缀、两万 Token 新输入，并产生两万计费输出 Token。不使用工具、不触发区域附加费，首次前缀全部写入，之后九次全部命中，价格使用上文的官方费率。缓存价格说明

首次费用为：前缀写入零点二美元，新输入零点零四美元，输出零点二美元，总计零点四四美元。之后每次缓存读取零点零零八美元，加上新输入和输出，总计零点二四八美元。十次合计二点六七二美元。

如果十次都按普通输入处理，同样的输入和输出假设下，每次零点四美元，合计四美元。两种方案的差别来自可复用前缀，而不是所有输入都打折。首次写入比普通输入贵，之后是否能够完整复用才决定收益。

真实业务中要再测前缀变动和缓存失效。例如工具定义更新、前面插入时间戳、请求改换模型，都应在账本里单独分组。不要把理想的十次完整复用外推成整个月的固定节省比例。

六、不同模式单独做账

官方页面当前说明，Fast 费率是 Standard 的两倍，Batch 和 Flex 相比 Standard 低一半；可用区域处理还可能有额外费用。这是单价规则，不代表模式可以任意叠加，也不代表订阅产品按相同方式结算。对同一任务，先核对实际选择的服务模式，再读取对应价格表。模式与区域价格

本文建议把有即时交互要求的任务和允许延后的批处理拆开。前者关注用户等待和尾部延迟，后者关注队列完成时间与单位交付成本。即使单价较低，也要把失败补跑、任务截止时间和人工处理纳入验收。

七、模型路由怎么设计

GPT-6.1 Sol 不需要承担所有请求。可以按任务难度建立三层路由：

这不是按模型名称做永久排名，而是按任务的质量、延迟和预算约束做动态选择。路由器应该看输入长度、工具数量、风险等级和历史失败率，不能只看“这次请求有多少字”。

一个简单的伪代码如下：

function chooseRoute(task) {
  if (task.risk === "high") {
    return { model: "gpt-6-astra", effort: "medium" };
  }
  if (task.toolCount > 3 || task.inputTokens > 32000) {
    return { model: "gpt-6.1-sol", effort: "medium" };
  }
  return { model: "gpt-6-luna", effort: "low" };
}

上线前要用自己的任务集校准阈值。路由规则过于复杂，会增加调试成本；规则过于简单，则可能把难任务送到低档模型，最后用重试和人工修正把预算补回来。

八、重试是最容易漏算的一项

失败重试通常会复制输入 Token，有时还会重新写缓存。应区分可安全重试的错误和不应自动重试的错误：网络超时、临时 5xx 可以使用有限次数的指数退避；参数不兼容、权限不足、上下文超限和工具 schema 错误，应该直接进入修复或降级流程。

每次重试都要保存原因。否则月底只看到“成功率还可以”，却不知道费用有多少来自重复请求。建议设置任务级上限，例如最大重试次数、最大 Token 预算和最大等待时间，达到任一条件就转人工或走备用路由。

带写入副作用的工具还要把“重试请求”和“重新执行动作”分开。网络响应丢失时，不能简单地再次扣款、发消息或修改记录。先用幂等键查询上一次状态，再决定是否补偿，是预算治理和数据安全的共同要求。

九、建立三张预算表

第一张是单次任务表，记录上面的 Token、工具、重试和人工数据。第二张是模型路由表，记录各任务类型送到哪个模型、哪个推理档位，以及升降级比例。第三张是月度账单表，把普通请求、缓存请求、Batch/Flex、区域处理和失败重试分开。

这样才能回答三个实际问题：缓存到底有没有降低成本；Sol 的质量收益是否值得它的输出价格；路由后每个合格交付的平均成本是否下降。

每张表再注明价格核验日期和服务模式。账单出现偏差时，先检查分类、次数与命中量，再检查是不是跨过长上下文阈值。预算预警应限制整个任务的累计费用，而不是只限制单次请求，否则多次重试仍可能突破预期上限。

GPT-6.1 Sol 的官方单价只是预算起点。真正上线前，至少用一周的脱敏流量或离线回放校准缓存命中、长上下文、工具失败和人工修正，再决定默认模型和升级策略。不要用一张静态价格表替代自己的任务日志。