GPT-5.6 三档费用对照表怎么读：credits 计价、成本估算与选型

一张费率表，引出三个对不上的数字

讨论的起点是一张 GPT-5.6 的 credits 费率对照表：模型被分成 Sol、Terra、Luna 三档，每档分别给出「输入 token」「缓存输入 token」「输出 token」三类单价，下面还并列了上一代若干模型以及图像模型的价格。表一贴出来，立刻出现三种反应：有人发现 Terra 的单价和上一代的 5.4 完全一致，觉得这是「同价升级」；有人对照官方文档，发现看到的数字是表里的两倍；还有人实测，用最高档跑了约 460 万 token 的活儿，套餐周额度只掉了 2%。

三种说法其实并不矛盾，它们分别对应三件事：档位之间的相对价格、credits 与美元两套计价口径、以及实际任务里输入输出 token 的构成比例。把这三层拆开，这张表就能读懂了。需要先说明的是，下面的数字都是从这张流传的对照表换算出的相对倍数，不是官方报价；具体费用请以官方最新文档为准。

表里能读出的三条规律

规律一：每一档内部，比例是固定的

三档模型的价格结构完全一致：缓存输入约为输入价的 1/10，输出约为输入价的 6 倍。也就是说，同一档位里，生成内容的成本是「读内容」的六倍，而命中缓存能把输入成本压到十分之一。这一点比档位之间的差异更值得记住，因为它决定了你的账单结构。

规律二：档位之间是干净的倍数关系

以最便宜的 Luna 为 1 倍基准：

可以看到，Terra 与上一代 5.4 同价、Sol 与 5.5 同价，属于「换代不涨价」的排布；而 Codex 系列的定价结构不太一样——输入比 Terra 便宜，输出却接近 Terra，这意味着代码任务如果输出很短（改几行、返回结构化结果），成本并不高；一旦让它长篇生成，单价会迅速接近高档模型。

规律三：图像模型的计费口径不同

图像模型会分出「按图片输入」和「按文本输入」两套价格，且缓存价相对输入价的比例明显高于文本模型（不是 1/10 的关系）。这类价格不要和文本模型直接横向比，先确认自己调用的入口按哪种口径结算。

为什么会出现「两份费率表，数字差一倍」

这是整场讨论里最容易误导人的地方。同一家厂商同时存在多份价格文档是常态，差异通常来自这几处：

• 单位不同：一份按套餐内的 credits（额度单位）计，一份按每百万 token 的美元计，两者不能直接比大小。
• 口径不同：有的文档列的是标准价，有的是缓存价、批量价或推理档位加价后的价格。
• 文档定位不同：一份是对外的 API 定价页，另一份是套餐额度/速率卡说明，服务的是不同人群。
• 未定价模型：表里标着「research preview」的条目本身没有正式报价，拿它做比较没有意义。

核对时按这个顺序走，基本不会错：先确认数字的单位是 credits 还是货币 → 再确认是不是每百万 token → 再确认是否已包含缓存折扣和推理档位加价 → 最后确认这份文档对应的是 API 调用还是订阅套餐额度。跨表比较前，务必先统一单位。

从 token 用量反推额度消耗

想把「这张表」变成「这个月要花多少」，可以按下面的步骤做。

第一步：把用量拆成三段

从调用日志或用量面板里取三个数：未命中缓存的输入 token、命中缓存的输入 token、输出 token。很多面板只给「总 token」，这时可以按任务类型粗估：长系统提示 + 短问答，缓存占比高；一次性贴大段代码让它改写，缓存占比低。

第二步：套公式

credits = 未缓存输入 × 输入单价
        + 缓存输入 × 缓存单价
        + 输出   × 输出单价

由于同一档位内缓存价是输入价的 1/10、输出价是输入价的 6 倍，可以先把公式简化成「等效输入量」：

等效输入 token ≈ 未缓存输入 + 0.1 × 缓存输入 + 6 × 输出

算完再乘档位倍数（Luna 1、Terra 2.5、Sol 5）。这个式子能让你在没有精确日志时也快速判断量级。

第三步：用真实消耗校准

讨论里提到的实测数据很有参考价值：用最高档位跑一个任务，消耗数百万 token，周额度只下降约 2%。这既说明高档位的单次任务确实贵，也说明套餐额度对中等强度的使用是够的。反过来推，如果周额度掉得很快，问题往往不在「档位选贵了」，而在输出 token 太多或推理档位开得太高——这两项才是账单的主要来源，而不是输入长度。

第四步：小样本试跑

换档位之前，先用一两个真实任务在新档位上跑一遍，记录 token 消耗和解决质量，再决定是否整体迁移。只看单价换档，很容易出现「单价降了一半、往返次数翻倍」的结果。

选型：贵的不一定亏，便宜的不一定省

讨论中一个具体的对比值得展开：同一类排版/图表问题，上一代中档模型反复尝试没解决，换成 5.6 的 Terra 一次就解决了。单次调用的成本确实更高，但把失败重试的消耗、人工介入的时间算进去，总成本反而更低。

由此可以给出一套比较稳妥的分层策略：

• 低档位（Luna 一类）：格式转换、批量改写、信息抽取、简单问答。这类任务对推理深度不敏感，量大，用便宜档最划算。
• 中档位（Terra 一类）：日常主力。与上一代同价，适合先做无痛迁移测试。
• 高档位（Sol 一类）：只在难题、关键决策、复杂调试时开，且尽量一次给足上下文，避免多轮拉扯。
• 代码专用档（Codex 一类）：适合改代码、跑自动化任务；注意它的输出单价偏高，控制单次生成的长度。

另一个容易被忽略的变量是推理档位（high / xhigh 之类）。同一模型开不同档位，消耗可能相差接近一倍，而收益并不总是线性增长。建议固定一个默认档位，只在对结果不满意时手动升档，而不是默认拉满。

如果任务本身是长时间挂机跑批（例如让 agent 连续处理一批仓库），把执行放在一台长期在线的远程机器上会比占用本机更稳——本地断网或休眠导致任务中断、重新跑一遍，那部分 token 是白烧的。这是控制成本的一个外部手段，与选哪个档位无关。

容易踩的坑

• 拿研究预览模型比价：标着 research preview 的条目没有正式价格，别拿它做选型依据。
• 忽略缓存前提：缓存命中要求请求前缀稳定。系统提示里塞了时间戳、随机 ID，或者每轮都换工具定义，缓存就基本失效，输入成本立刻回到 10 倍。
• 只比较输入价：输出价是输入价的 6 倍，长文档生成、长代码补全类任务的真实成本往往由输出决定。
• 跨表比数字：credits 与货币两套口径混着看，就会得出「官方价格是流传版本的两倍」这种结论。
• 默认价格不变：这类费率表调整频繁，模型命名与档位划分也可能随时变动，正式采购前请重新核对官方最新说明。

小结：一份可执行的检查清单

1. 拿到任何一张费率表，先确认单位是 credits 还是货币，是否按每百万 token 计。
2. 记住同一档位内「缓存输入 ≈ 输入 / 10，输出 ≈ 输入 × 6」，优先优化输出长度和缓存命中率。
3. 用「等效输入 token」公式粗算量级，再用真实用量校准。
4. 分层用模型：简单任务走低档，难题临时升档，代码任务用代码专用档。
5. 推理档位设默认值，别长期拉满。
6. 换档前先用真实任务小样本试跑，比较的是「解决一个任务的总消耗」，不是单价。
7. 所有具体数字以官方最新文档为准；对不上的两份表，先统一口径再比较。