GPT-6 模型怎么选：Astra、Sol、Luna 与推理档位对比

先分清三条产品线，模型名不等于能力

同一个模型名，在 ChatGPT 订阅、Codex、API 三个入口里的可用性、工具能力和额度都不一样。官方文档也明确写了：可用性、工具、推理设置和使用上限会随产品和模型版本变化。所以选型前先确认你要在哪个入口用，再去看那个入口的模型列表。

当前主力三档：Astra、Sol、Luna

现在的主力是同一代的三个定位：Astra 最强、Sol 最均衡、Luna 最省。官方的说法是 Astra 面向“最 demanding 的工作”，Sol 用更低的成本提供接近 Astra 的复杂任务表现，Luna 面向聚焦、高并发的任务。

一个常见的省钱办法是组合使用：难的部分交给 Astra 或 Sol 做规划和拆解，执行环节（改文案、补测试、批量转换）交给 Luna。前提是你能把任务拆成“需要判断”和“照着做”两段。

上一代 GPT-5.x 和 o 系列还要不要用

模型页上仍然能查到 GPT-5.6（Terra / Sol / Luna）、GPT-5.5、GPT-5.4、GPT-5.x-Codex 系列，以及 o3、o4-mini 这些更早的推理模型。它们还在，通常意味着三种情况：兼容老代码、特定任务上更便宜、或者某些入口还没切到新模型。

• 新项目直接用当前主力，不要为了“稳定”锁在旧型号上，旧型号会先进入弃用流程。
• 老代码里写死模型名的，先把模型名抽成配置，再逐档灰度替换，别一次性全换。
• 只有在对比测试里旧型号确实更好、或者预算卡得很死时，才保留旧型号。

const MODEL_TIERS = {
  planning: "gpt-6-astra",
  build: "gpt-6.1-sol",
  bulk: "gpt-6-luna",
} as const;

type Tier = keyof typeof MODEL_TIERS;

export function modelFor(tier: Tier) {
  const key = "MODEL_" + tier.toUpperCase();
  return process.env[key] ?? MODEL_TIERS[tier];
}

推理档位：比换模型更便宜的旋钮

现在的模型大多可以用 reasoning effort 控制“想多久”。档位越高，模型在回答前投入的推理 token 越多，复杂任务更稳，但更慢也更贵。官方文档给的档位示例是 Low、Medium、Extra high 三档，但不是每个入口都暴露全部档位。

调档位的顺序建议是：先用低档跑，看失败在哪；失败原因是“漏了约束”就补提示词，是“想得不够深”再升档。反过来的顺序会让你在简单任务上多付很多钱。

{
  "model": "gpt-6.1-sol",
  "reasoning": { "effort": "medium" },
  "input": "把这次变更拆成三个可独立验证的提交，并说明每个提交的验收方式。"
}

按任务选型：先问四个问题

官方给的选型建议可以压缩成四个问题。回答完这四个问题，模型和档位基本就定了，剩下的靠同一批输入做对比实验。

1. 01

   这个流程跑多频繁

   一天跑几千次的批处理，单价权重远大于质量；一周跑两次的分析，质量权重更高。

2. 02

   多快需要结果

   有人在等结果就用低延迟模型和低档位；离线任务可以用高档位甚至 Batch 接口。

3. 03

   结果怎么用

   直接给人看的要求可读性和完整性；作为下游程序输入的要求结构稳定，这时结构化输出比模型强弱更重要。

4. 04

   质量线在哪

   先定义“能接受”的标准，比如准确率、返工率、人工修改时间，再用同一批样本测试，保留能过线的最轻配置。

常见误区与检查清单

• 误区一：默认用最强模型。简单任务上，Astra 不会比 Luna 更准，只会更慢更贵。
• 误区二：只换模型不换提示词。同一段提示词在不同代模型上的表现差异很大，换模型要重跑评测。
• 误区三：忽略推理档位。很多“模型不行”的问题，其实是档位太低或提示词塞了太多无关上下文。
• 误区四：拿聊天窗口的体验推断 API 表现。工具、系统提示词、上下文管理都不一样。

上线前的检查清单：模型名是否集中配置、是否有兜底模型、是否记录了每次调用的模型与档位、是否有固定评测集、成本是否有告警阈值。