GPT-5.6 发布那会儿，一口气端出三个模型，而不是像以前那样只推一个。

说实话，第一反应是有点烦的。Sol、Terra、Luna，名字听着是挺好听。

但当你盯着配置文件，准备填 model 字段的时候，会发现这些名字几乎没提供任何实质性帮助。

所以，干脆干了一件比较笨但很实在的事：把这三个模型都接进同一个应用里。

我用真实的生产流量跑了一周，仔细观察 token 消耗和账单费用，然后把结果全记了下来。

这篇文章就是最后整理出的结论，也是一套恨不得在第一天就有人能直接告诉你的模型选择方法。

30 秒快速结论

这三个模型共用一个 API，功能支持基本拉平。

真正拉开差距的是推理深度、价格和响应速度——这三点，才是选型的关键。

官方公布的价格如下（单位：每百万 token）：

档位	模型名称	价格（输入 / 输出）	一句话评价
Sol	gpt-5.6-sol	$5 / $30	旗舰模型，出错代价很高时使用
Terra	gpt-5.6-terra	$2.50 / $15	让人有点意外的默认选择
Luna	gpt-5.6-luna	$1 / $6	适合大批量任务的主力模型

注意输出 token 的价格：Sol 是 30 美元，Terra 是 15 美元，Luna 是 6 美元。

现在大模型的成本都是由输入和输出 token 组成的，而输出 token 的计费权重很大。这三个模型的输出价格，差不多都是输入价格的 5 倍。

这个比例很重要。意味着模型选型很多时候不能光看你喂了多少内容进去，还得看模型最后会吐出多少内容出来。

Terra 才是最大的意外

一开始，本来以为自己会把 Sol 用在所有地方，然后一边看账单一边抱怨太贵。

后来，把 Sol 和 Terra 放在真实的写代码助手流量里做了个 A/B 测试。

测试内容包括代码 diff、重构，以及排查“为什么这个测试偶尔会失败”之类的问题。

OpenAI 官方的说法是，Terra 的基准测试表现大约能达到 Sol 的 97%。

而在日常开发中，确实很难感受到那 3% 的差距。它们给出的修复方案基本一致，解释也差不多。

但 Terra 的价格只有 Sol 的一半。

这让思路彻底变了。问题不再是“我能不能承担 Sol 的价格”，而是：

我有没有明确的理由，要把某个请求从 Terra 升级到 Sol？

对于大多数请求来说，答案其实是否定的。

于是，Terra 成了默认模型，而 Sol 变成了一个需要有意识去选择的例外。

Sol 什么时候依然值得使用？

那些真正复杂的推理任务，而且一旦出错，带来的损失远高于 token 费用的场景：

• 架构评审
• 复杂系统迁移
• 基于大量上下文的研究总结
• ultra 模式下的 Agent 流程

复杂的 Agent 系统都是由多个并行子 Agent 协调组成的。

GPT-5.6 系列正好支持这种协调工作，这也正是深度模型更容易体现价值的地方。

如果任务本身很复杂，而且最终结果是否正确至关重要，那么 Sol 的价格通常是值得的。

Luna 不是低配版，而是另一种工作类型

很多人容易误解 Luna，把它简单理解成“缩水版 Sol”。但更愿意把它看成一个完全不同的工具。

如果任务主要是大量重复操作，而且质量上限基本不会成为瓶颈，那么 Luna 就非常合适：

• 批量分类
• 标签生成
• 信息抽取
• 大规模摘要
• 处理大量结构相似的记录

比如你要对一万条数据执行同一种小操作。

这时候每百万输入 token 是付 1 美元还是 5 美元，就不只是模型参数上的差异了，而是会实打实地直接影响项目成本。

同时，Luna 也是这三个模型里速度最快的一个。

所以对于下面这些对延迟比较敏感的场景，通常会选 Luna：

• 自动补全
• 流式聊天界面
• 实时分类
• 用户操作过程中的即时反馈

如果你经常做这类任务，可以配合 stream: true 使用。这样能让用户更快看到输出内容。

很少有人讲清楚的缓存计算

这一点真正改变了模型路由策略，也解释了为什么不能简单地默认选择最便宜的模型。

GPT-5.6 支持可预测缓存：

• 一个 prompt 前缀至少可以保持缓存 30 分钟
• 你可以手动设置缓存断点
• 缓存读取只按照输入价格的 10% 计费

这个定价机制会彻底改变很多前缀内容比较固定的场景。

举个 RAG（检索增强生成）的例子。

假设每次请求都要重复发送一段很长的知识库前缀。

如果没有缓存，每次请求都得按照完整输入价格为这部分内容掏钱。

但如果把这段内容放在缓存断点之前，那么在 30 分钟的缓存周期内：

• 第一次请求按照完整价格计费
• 后续请求只按照输入价格的 10% 计费

如果你的输入内容里，固定前缀占比较高，那么 Terra 加上缓存之后，单次请求的实际成本，可能比没有缓存的 Luna 还要低。

但同时，你得到的仍然是 Terra 级别的回答质量。

所以后来，不再下意识地选择最便宜的模型，而是会先看固定前缀和动态内容的比例。

有时候，标价更贵的模型，最后反而能搭建出成本更低的系统。

实际使用的模型路由规则

经过这段时间的实测，现在在生产环境里大致遵循下面这套规则：

• 深度推理 / 高风险任务
  例如架构设计、复杂迁移、ultra 模式的 Agent 流程，使用 Sol。这类任务中，结果质量比 token 费用更重要。
• 日常工作
  例如写代码助手、普通聊天、大多数产品功能，使用 Terra。它大约能达到 Sol 97% 的基准表现，但价格只有一半。只有当评估结果显示某类请求确实存在明显差距时，才会将这类请求升级到 Sol。
• 高频 / 批量任务
  例如分类、抽取、摘要，以及对响应速度要求较高的用户界面，使用 Luna。需要时配合流式输出。

总结起来就是：

默认从 Terra 开始，根据请求类型的评估结果决定是否升级到 Sol；批量任务则交给 Luna。

重点不是模型名字听起来多高级，而是要让模型和你的实际工作负载完美匹配。

使用同一个 API Key 测试三个模型

测试这三个模型并不需要投入太多精力。

一个 sk- 开头的 key 就可以调用 GPT-5.6 的三个档位。

模型之间的比较只需要修改一个字符串，费用按照 token 使用量按量计费，不需要订阅，也不需要单独开通 OpenAI 账号。

如果你已经有 OpenAI SDK 的代码，只需要替换 base_url：

from openai import OpenAI
client = OpenAI(
    api_key="sk-YOUR_TOKEN",
    base_url="https://byesu.com/v1",
)
prompt = "重构这个函数，并解释其中的取舍。"
for tier in ("gpt-5.6-sol", "gpt-5.6-terra", "gpt-5.6-luna"):
    r = client.chat.completions.create(
        model=tier,
        messages=[{"role": "user", "content": prompt}],
    )
    u = r.usage
    print(f"{tier:16} in={u.prompt_tokens:5}  out={u.completion_tokens:5}")
    print(r.choices[0].message.content[:200], "n")

每次调用都记得记录 usage。

输入 token 和输出 token 的比例，是整个成本计算的核心。

当你真正看到自己使用的 prompt 在不同模型上的输入、输出 token 数量之后，价格表就不会再只是一个抽象数字了。

哪个模型更适合你的工作负载，通常很快就能看出来。

注意避坑：

创建 token 时，一定要把它放在 OpenAI GPT 分组里。

如果分组选择错误，很容易出现“no a vailable channel”错误。

另外，模型名称必须完全正确：

gpt-5.6-sol
gpt-5.6-terra
gpt-5.6-luna

最后总结

默认使用 Terra。

对于少数错误代价很高、需要深度推理的请求，再升级到 Sol。

它的输出价格是每百万 token 30 美元，但如果能显著降低错误成本，这个价格通常是合理的。

批量任务和对延迟敏感的任务，交给 Luna。

在你认定“最小模型一定最便宜”之前，先算一遍缓存成本。

可预测缓存加上 10% 的缓存读取价格，可能会完全改变模型之间的实际成本排序。

把三个模型接到同一个 API Key 下，记录每次调用的 token 使用情况，然后让真实流量来告诉你答案。