GPT-6 Luna Decisions 成本怎么算：输入分级、判定分流与预算模型

以 2026 年 10 月 14 日核验的官方定价为准，gpt-6-luna 的标准价是每百万输入 0.10 美元、每百万输出 0.50 美元、缓存输入 0.01 美元、缓存写入 0.125 美元。输入超过 272K tokens 时，整个请求按输入 2 倍、输出 1.5 倍计费；Batch 与 Flex 按标准价的一半计费，Fast 模式按 2 倍计费，区域处理加收 10%。

在接入方式上，开发者可以直接对接 OpenAI 官方接口，也可以根据团队需要，将大模型 API 通过 4SAPI 中转站等统一接入平台调用。对于需要同时测试多个模型或统一管理密钥与调用记录的团队，这类方式可以减少重复适配工作；具体支持的模型、计费口径和线路情况，应以平台实际页面为准。官方直连通常更适合重视原厂能力和完整功能支持的项目，两种路径的适用场景并不完全重合。

Decisions 接口的特殊之处在于：它返回的是类型化答案，输出占比很低。因此，它的成本几乎完全由“输入长度 × 判定条数”决定，而不像生成式任务那样被输出主导。

本文只回答一个问题：怎么给一批判定任务做成本预算，并决定哪些交给自动、哪些转人工。

一、把官方计费规则先摆出来

官方对 Luna 的计费规则有明确说明，逐条列出来：

这几条里，长上下文那条最容易踩坑：它不是只对超出部分加价，而是对整个请求加价。

二、建立成本公式

单个判定任务的成本近似为：

单条成本 ≈ 输入 tokens ÷ 1,000,000 × 单价档位

其中输入 tokens 包含指令、排除条件、参考样例和待判定内容。很多人只算待判定文本，忘了指令和样例，预算会差出一大截。

估算示例（假设算例，非实测）：

第三行说明了分档的威力：只有 100 条，但因为单条越过 272K，单价翻倍，成本并不因条数少而变小。

三、指令膨胀是最大的隐性成本

Decisions 接口不需要长格式说明，这一点比“让通用模型输出 JSON”省。但如果把大量业务规则、词典、标注样例塞进每次都发的指令里，成本会随指令长度线性增长。

控制办法：

1. 规则外置：能用确定性规则判的，先规则过滤。
2. 样例精简：只保留最能区分类别的少量样例。
3. 排除条件写精不写多：把关键的排除项写清楚，比堆一长串规则更有效。
4. 多问题共享输入：一次请求问多个问题，只付一份输入。

四、按输入长度分档做预算

不要长短混算，分三档：

短档：≤ 32K tokens
中档：32K – 272K tokens
长档：> 272K tokens

每档单独记录：

task_id
model
input_tokens
tier            # short | mid | long
question_type   # predicate | choice | score
answer
probability
route           # auto | human
cost_estimate
latency_ms

有了 tier，就能看出成本被哪一档拉高。多数情况下长档条数少却是账单主力。

五、把“单位合格交付成本”作为指标

自动化判定的目标不是“让模型多判”，而是让正确的判定自动处理，把不确定的交给人工。所以真正的指标是：

单位合格交付成本 =
  判定成本
+ 人工复核成本（按转人工比例折算）
+ 返工成本（判错后重新处理）

阈值调松，转人工比例上升，人工成本吃掉节省；阈值调太严，自动通道变成摆设。可行的做法是以“单位合格交付成本”为目标函数扫描阈值组合，找到总成本最低的切点。

六、和同家族模型对照

把 Luna 放进 OpenAI 当前主力阵容里看：

差距有多大：Luna 的输出价是 Sol 的二十分之一，输入价也是二十分之一。定价页

这解释了为什么 Decisions 只挂在 Luna 上——判定任务的答案空间有限，用不着旗舰模型的推理深度，用旗舰反而是成本浪费。

当团队需要在这些档位之间做对照测试或逐步迁移时，统一接入方式可以简化多模型管理。除了分别对接各家官方接口，也可以借助 4SAPI 等中转平台集中维护调用入口，减少密钥和协议适配的重复工作；但实际延迟、稳定性和费用仍需结合模型、线路、并发量与地区网络进行测试，具体计费规则以平台实际页面为准。

七、和“用通用模型做判定”比成本

用生成式模型做判定，成本里至少包含：

• 指令里的格式说明与示例（每次都计费）。
• 输出的一段 JSON（按输出计费）。
• 解析失败后的重试。
• 为稳定输出而提高的推理档位。

Decisions 把这些前移到接口层，理论上能降低单位判定成本。但是否真的更低取决于输入分布：如果指令很短、判定很简单，差距可能不大；只有在大批量、长输入、需要概率分流的场景里，结构优势才明显。

因此比较时不要只看“每百万多少钱”，而要看完成同样数量合格判定需要多少钱。

八、分流策略怎么设计

推荐的默认结构是三段式：

第一段：确定性规则（零模型成本，先过滤明显样本）
第二段：Decisions 接口（低成本，输出概率）
第三段：生成式模型 + 人工（只处理低置信度）

让概率真正参与决策：

• 概率高于上界 → 自动通过。
• 概率低于下界 → 直接转人工，不再重试。
• 介于两者 → 交给生成式模型做带解释的复核，仍不确定再转人工。

这样模型调用集中在“值得调”的样本上。

九、批量与折扣渠道

官方说明 Batch 与 Flex 按标准价的一半计费。判定类任务大多不要求实时，正好适合批处理：

• 夜间批量跑分类、打标、初筛。
• 白天只处理实时性要求高的判定。

一个提醒：Batch 有延迟，不适合需要即时返回的场景。把它用在“今天处理昨天攒下的数据”这类任务上更合适。

十、验证与限制

验证成本模型时，至少要做三件事：

1. 用真实样本统计输入 token 分布，而不是凭感觉估。
2. 记录每档条数与转人工比例。
3. 连续观察若干天，确认单价口径与用量稳定。

需要明确的限制：

• 本文价格来自 2026 年 10 月 14 日的官方定价页，属于可变事实。
• 上表成本数字是假设算例，不是实测。
• 接口处于公开测试阶段，计费口径可能调整。
• 人工成本折算系数需按自身团队工时确定。

十一、常见误解

• “输出不计费所以可以随便写指令”：输入才是账单大头。
• “超过 272K 只对超出部分加价”：官方是对整个请求加价。
• “Batch 更便宜就用 Batch”：它不满足实时性要求。
• “换便宜模型就一定省钱”：要算单位合格交付成本，不是单价。

十二、一个可复用的成本对照表

做预算时，把下面这张表填出来，基本就能看清成本结构：

填表的两个要点：

1. 单价按档位取，长档用 0.20 而不是 0.10。
2. 人工成本不能留空，否则会得出“越自动越便宜”的片面结论。

十三、什么时候不该用 Decisions 接口

从成本角度看，下列情况用 Decisions 反而不划算：

• 判定逻辑简单到能用规则写完：引入模型只增加成本与不确定性。
• 每个样本都需要人工确认：自动判定省不下人工，只多了模型费用。
• 输入本身极长：越过 272K 后整请求加价，不如先做规则或检索过滤。
• 需要输出解释：Decisions 不给论证，还得再调一次生成式模型，成本翻倍。

判断标准是：自动化能省下的成本，是否大于模型调用与阈值设计带来的成本。 省不下，就不该上。

十四、把成本信号接进运营

成本不是算一次就完的。建议周度关注：

• 平均输入长度与输入长度 P95。
• 各档位条数占比。
• 转人工比例。
• 单位合格交付成本。

当平均输入长度上升或转人工比例上升时，通常意味着指令变长或任务分布变化，需要回到工程侧排查。

限制与结论

Decisions 接口的成本由输入主导：短输入便宜，越过 272K 后整请求加价，输出几乎不占成本。这决定了优化方向是控制输入长度和用概率做分流，而不是压缩输出。

落地时建议按输入长度分档统计，以“单位合格交付成本”为目标函数扫描阈值，用三段式结构把成本集中在真正需要模型判断的样本上，并把不要求实时的批量任务放进 Batch 或 Flex。价格与计费规则请在上线前回到官方定价页重新核对。

总体来看，直接调用官方 API 和通过统一中转平台接入并不是相互排斥的两种方式。对原生功能、数据链路和官方支持要求较高的项目，可以优先评估官方接口；需要同时测试多个模型、减少重复适配或希望统一管理调用记录的团队，也可以将 4SAPI 中转站作为备选接入路径。正式投入生产前，仍应结合实际模型、并发量、响应速度、费用和数据安全要求进行小规模测试，并重点评估服务协议、数据处理方式和日志策略。