今天和大家讲一下 GPT-5.6 模型选型的那些事。
GPT-5.6 发布的时候，一口气推出了三个模型，而不是像以前那样只推一个。说实话，我第一反应是有点烦的。Sol、Terra、Luna，名字听着是挺好听，但当我盯着配置文件，准备填 model 字段的时候，发现这些名字几乎没提供任何实质性帮助。
所以，我干了一件比较笨但很实在的事：把这三个模型都接进同一个应用里，用真实的生产流量跑了一周，仔细观察了 token 消耗和账单费用，然后把结果全记了下来。这篇文章就是我最后整理出的结论，也是一套我恨不得在第一天就有人能直接告诉我的模型选择方法。
30 秒快速结论
这三个模型用的是同一套 API，支持的功能也基本一致。真正拉开差距的地方，主要是推理深度、价格和响应速度。
官方公布的价格如下（单位：每百万 token）：
| | | |
|---|
| gpt-5.6-sol | | |
| gpt-5.6-terra | | |
| gpt-5.6-luna | | |
大家注意一下输出 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 费用的场景：
我们都知道现在复杂的 Agent 系统都是由多个并行子 Agent 协调组成的，而 GPT-5.6 系列正好支持这种协调工作，这也正是深度模型更容易体现价值的地方。如果任务本身很复杂，而且最终结果是否正确至关重要，那么 Sol 的价格通常是值得的。
Luna 不是低配版，而是另一种工作类型
很多人容易误解 Luna，把它简单理解成“缩水版 Sol”。但我更愿意把它看成一个完全不同的工具。
如果任务主要是大量重复操作，而且质量上限基本不会成为瓶颈，那么 Luna 就非常合适：
比如你要对一万条数据执行同一种小操作，这时候每百万输入 token 是付 1 美元还是 5 美元，就不只是模型参数上的差异了，而是会实打实地直接影响项目成本。
同时，Luna 也是这三个模型里速度最快的一个。
所以对于下面这些对延迟比较敏感的场景，我通常会选 Luna：
如果你经常做这类任务的话，这里配合 stream: true 使用就非常方便了，能让用户更快看到输出内容。
很少有人讲清楚的缓存计算
这一点真正改变了我的模型路由策略，也解释了为什么不能简单地默认选择最便宜的模型。
GPT-5.6 支持可预测缓存：
- 一个 prompt 前缀至少可以保持缓存 30 分钟
这个定价机制会彻底改变很多前缀内容比较固定的场景。
举个 RAG（检索增强生成）的例子。假设每次请求都要重复发送一段很长的知识库前缀。如果没有缓存，每次请求都得按照完整输入价格为这部分内容掏钱。
但如果把这段内容放在缓存断点之前，那么在 30 分钟的缓存周期内：
如果你的输入内容里，固定前缀占比较高，那么 Terra 加上缓存之后，单次请求的实际成本，可能比没有缓存的 Luna 还要低。
但同时，你得到的仍然是 Terra 级别的回答质量。
所以后来，我不再下意识地选择最便宜的模型，而是会先看固定前缀和动态内容的比例。有时候，标价更贵的模型，最后反而能搭建出成本更低的系统。
我实际使用的模型路由规则
经过这段时间的实测，我现在在生产环境里大致遵循下面这套规则：
深度推理 / 高风险任务
例如架构设计、复杂迁移、ultra 模式的 Agent 流程，使用 Sol。这类任务中，结果质量比 token 费用更重要。
日常工作
例如写代码助手、普通聊天、大多数产品功能，使用 Terra。它大约能达到 Sol 97% 的基准表现，但价格只有一半。只有当评估结果显示某类请求确实存在明显差距时，我才会将这类请求升级到 Sol。
高频 / 批量任务
例如分类、抽取、摘要，以及对响应速度要求较高的用户界面，使用 Luna。需要时配合流式输出。
总结起来就是：
默认从 Terra 开始，根据请求类型的评估结果决定是否升级到 Sol；批量任务则交给 Luna。
重点不是模型名字听起来多高级，而是要让模型和你的实际工作负载完美匹配。
使用同一个 API Key 测试三个模型
测试这三个模型并不需要投入太多精力。
我使用的是 byesu。它提供兼容 OpenAI 的 Chat Completions API，当然也支持同一个服务地址下的 Anthropic 原生 /v1/messages 接口，但是我没太用到，就暂不介绍了。
一个 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 available channel”错误。
另外，模型名称必须完全正确：
gpt-5.6-sol
gpt-5.6-terra
gpt-5.6-luna
最后总结
默认使用 Terra。
对于少数错误代价很高、需要深度推理的请求，再升级到 Sol。它的输出价格是每百万 token 30 美元，但如果能显著降低错误成本，这个价格通常是合理的。
批量任务和对延迟敏感的任务，交给 Luna。
在你认定“最小模型一定最便宜”之前，先算一遍缓存成本。可预测缓存加上 10% 的缓存读取价格，可能会完全改变模型之间的实际成本排序。
把三个模型接到同一个 API Key 下，记录每次调用的 token 使用情况，然后让真实流量来告诉你答案。
粤ICP备14082021号
免费POC，
零成本试错
