GPT-6 Luna vs GPT-5.6 Luna：如何衡量升级价值
对 Luna 工作负载而言，有用的单位通常是“验收通过的记录”：字段正确的发票、标签正确的工单，或能通过下游校验的转换结果。能够解析成 JSON 的响应仍可能是错的；较低的 token 账单也可能掩盖更大的重试队列。
已有文档基线与待核验候选型号
| 项目 | GPT-5.6 Luna | GPT-6 Luna：9 月 20 日核查状态 |
|---|---|---|
| 官方身份 | gpt-5.6-luna | 未找到型号专属目录条目 |
| 官方定位 | 成本敏感、高调用量工作 | 尚未核验 |
| 输入 / 输出 | 文本、图像 / 文本 | 本次来源尚未公布 |
| 上下文 / 最大输出 | 1,050,000 / 128,000 token | 本次来源尚未公布 |
| 推理档位 | none、low、medium（默认）、high、xhigh、max | 尚未核验 |
| 流式输出、函数调用、结构化输出 | 上游模型文档列为支持 | 尚未核验 |
| 自己的处理结果 | 需要在自己的记录上测量 | 本指南尚未执行测量 |
这些事实确认了模型身份和起始接口约定，但不能证明未来 Luna 会保留相同的 schema 行为、价格更低，或更快处理你的队列。
建立能代表真实队列的记录集
从自己的工作负载分布出发。合理的测试集不一定是每类数量相等：如果某个客户格式占多数流量，就应有足够代表。同时，也要纳入少见但后果严重、足以阻止上线的失败类型。
保存稳定记录 ID、输入版本、预期输出、允许的空值、校验规则和升级处理决策。如果评估环境没有处理敏感数据的授权，应先移除相关内容。数据集还要附带提示词、schema、预处理和后处理版本。
把样本分为小规模开发集和独立保留的检查集。前者用来修复评估框架问题和调优候选配置，后者用来观察调优后的表现能否适用于新样本。如果对全部记录反复调优，再把同一批记录当成全新测试报告，会夸大可信度。
按负载切片报告结果。总体准确率可能看起来不错，但某种语言、文档模板或低频标签变得不可靠。总体分数应按计划流量占比加权，同时单独展示关键切片。
六类重复任务与验收规则
| 工作负载 | 应纳入的情况 | 验收规则 |
|---|---|---|
| 发票或表单提取 | 缺失值、冲突金额、多个日期、扫描页 | 必需字段符合参考答案；缺失值保持缺失；金额满足约定校验 |
| 工单分类 | 相近标签、多主题、少见紧急情况 | 标签与升级处理正确；按类别记录误报和漏报 |
| 结构化摘要 | 长讨论、后文修正、未解决问题 | 保留最终状态与未完成行动，不编造已解决结论 |
| 数据规范化 | 单位、地区格式、日期格式、模糊标识 | 正确规范化，或明确表示不确定；模糊字段不静默猜测 |
| 重复代码转换 | 有效与无效输入、已转换过的文件 | 输出通过解析/测试，保留无关内容，可安全重复处理 |
| 工具辅助记录查询 | 记录缺失、重复匹配、查询后超时 | 正确关联记录并明确不确定性，不编造工具结果或重复写入 |
把 schema 合规与语义正确分开。例如，发票响应可以使用正确键名和类型，却把供应商税号放到客户字段中。单一 JSON 合规率会掩盖这种失败。
部分任务需要人工评分。给复核人明确规则，条件允许时隐藏模型标签。记录分歧并以一致方式处理，同时说明多少记录自动评分、多少需要人工。迁移如果增加人工复核，就改变了运营成本。
提高并发之前，先检查兼容性
大规模重放前，确认候选型号的精确身份与支持端点。模型选择应可以配置，避免修改每个任务生产者。不要用搜索 slug 代替有文档的请求 ID。
检查实际使用的控制项，包括推理档位、输出限制、schema 格式、流式输出和工具响应。GPT-5.6 Luna 接受的参数，后继型号可能拒绝或作不同解释。HTTP 请求成功并不能证明某项设置真正生效。
这一步也要覆盖失败路径：
- 截断或格式错误的输出必须校验失败，并遵守有限重试策略。
- 拒答必须能与“为空但有效”的提取结果区分。
- 限流应触发受控退避，而不是无限重试风暴。
- 部分流式结果与网络超时不能计为验收通过。
- 重放任务必须保留身份，避免重复写入外部系统。
必要行为失败时，先修复接入，或把该负载留在旧路由，再尝试更高处理量。校验已经失效时取得的吞吐数字没有比较价值。
衡量有效吞吐，而不是原始响应速度
使用同一记录构成与重试策略，为两种配置运行受控的逐级并发测试。最初的小规模试跑发现基本故障，更大规模运行观察排队与限流行为。始终遵守服务商文档中的限制。
| 测量项 | 应纳入的内容 |
|---|---|
| 每分钟验收记录数 | 只计算通过完整验收规则的记录 |
| 端到端 P50 / P95 | 队列等待、请求时间、退避、重试与必要升级处理 |
| 队列积压时间 | 最久未完成任务，以及持续负载下积压是否增长 |
| 错误与重试率 | 分别记录传输、限流、schema 与语义错误 |
| 升级处理比例 | 转给其他模型或人工复核的记录 |
| 每条验收记录成本 | 所测处理链的全部计费尝试与升级调用 |
明确记录输出长度与推理配置。候选模型如果输出明显更长，延迟与支出都可能改变。提示词缓存与预热也会干扰短测，应说明缓存是否已预热，不能不加说明地混合不同条件。
条件允许时重复测试，报告样本量与持续时间。短暂突发流量不能证明持续队列容量；极小样本中的低 P95 也不是可靠的生产保证。
计算可用记录的成本
每条验收记录的 API 成本 = 处理链 API 总支出 / 验收通过记录数分子包括失败尝试与重试。如果另一个模型完成了升级处理，也要计入其 API 成本。人工纠错时间单独记录；若换算成金额，应说明时薪假设。没有任何记录通过时，应报告失败，而不是除以零。
决定哪些记录值得迁移
试跑前写下每个重要切片的门槛。总体成功分数不能抵消关键标签或字段上的不可接受回归。阈值应来自服务目标和错误代价，不应套用统一的迁移百分比。
| 结果 | 行动 |
|---|---|
| 接口约定或关键字段检查失败 | 保留现有路由，重测前记录失败原因 |
| 准确性通过，但成本或队列期限不达标 | 排查重试、输出长度、推理档位和升级处理，暂不扩大 |
| 常规切片通过，困难切片回归 | 只有分流规则可测试、额外成本已计入时，才考虑有限拆分 |
| 试跑中全部必要门槛通过 | 开始受控试点，保留停止条件与可用回退 |
| 试点错误、积压或纠错时间上升 | 停止扩大，回退受影响的切片 |
不会产生外部副作用时，影子重放很有用。真实任务应保存 job ID，超时重试前检查状态。不能因为首个响应丢失，就让回退路由重复更新数据。
重复任务应该关注 GPT-6 Luna 还是 GPT-6 Sol？
FAQ
GPT-6 Luna 比 GPT-5.6 Luna 更快或更便宜吗？
本指南没有经过核验的比较。到 2026 年 9 月 20 日所核查来源为止，新型号的价格、吞吐与行为仍待确认。
JSON 有效就能验收记录吗？
不能。除了 schema，还要校验必需字段、字段值和任务语义。格式正确的响应仍可能分类错误或编造缺失值。
应该比较每秒 token 数吗？
它能辅助诊断，但每分钟验收记录数与端到端延迟更能反映队列完成情况，并且必须纳入重试和升级处理。
成本示例是 Luna 实际费率吗？
不是。它是假设的处理链总额，用来说明每条验收记录成本。实际评估应使用当前服务商账单。
每条记录都必须迁移到新一代吗？
不必。如果分流规则可靠且完整处理链达标，可以只迁移一部分。失败或尚未测试的切片继续保留在已测路由。
什么情况下应该回退？
按上线前设定的停止条件执行：关键字段回归、积压增加、错误或重试率不可接受、人工纠错增加，或成本预算超标。
