AI From U AI FROM U.COM

博客 / 指南

在 astra、sol、terra 和 luna 之间怎么选

四个模型、一个端点、一份预算,要定的不是哪个最强,而是每一类请求该走哪一个。日常产品活先用 terra,推理深度确实值回票价时把那一类提到 sol,答错代价高过 token 的活才动用 astra,后台的分类打标摘要交给 luna。长上下文不加价,混用只是请求里的一个字段,每一笔都能在控制台逐条核对。

在 astra、sol、terra 和 luna 之间怎么选

四个模型、一个端点、一份预算。一个新账号真正要问的,不是它们里哪个最强,而是手上每一部分活该走哪一个——而这个答案从来不会是单独一个名字。它是一个路由决定:每一类请求做一次,然后拿你自己控制台里逐条的用量去对。下面就是这个决定,按该做的顺序排好。

先从 terra 开始

terra 是默认项,不是将就的折中。它公布的定位是日常助理类工作 — RAG、agent、工具调用和编程 — 而这已经覆盖了一个产品实际发出去的大部分请求:普通对话、按既定结构做抽取,以及那种敲字多过思考的编码辅助。在输入上它是 sol 的一半,0.5 对 sol 的 1,输出权重是 3 对 sol 的 5。

所以新的一类请求先放在那里跑,然后对结果诚实一点。如果 terra 给出的答案就是你本来会发布的那个,你已经找到了对的模型,并且只付了账单的下半截。往上换是要有能指出来的证据才做的决定——一次你能拿给别人看的失败——而不是为了保险先换上去。

什么时候把一类请求提到 sol

sol 是整张费率表的锚:一个 sol 输入 token 就是一个积分,本页其他每一个数字都是相对它的比例。sol 公布的定位是深度推理、高难度编程、Codex 类任务和研究——这句话本身也就是换过去的判据。当推理深度明显值回票价时,就把那一类请求提到 sol:terra 一直绕不出来的难 bug;中间步骤必须对、结论才可能对的多步分析;必须把整个文件同时装在脑子里才能改的那种改动。

这一步的代价是 terra 输入的两倍、输出多出三分之二:1 和 5 对 0.5 和 3。对一类原本做不成、现在做得成的请求,这个价钱很便宜;对一类本来就没问题的请求,这个价钱很不划算。要换的是那一类,不是整个应用——这四个模型没有哪一个是全局开关,而本页上最便宜的东西,是你根本没有往上换的那些请求。

astra 是留给什么活的

astra 是在 1M token 的上下文窗口上做前沿级推理,专为最难的那一类活准备,而它的定价就是要你有意识地花:输入 2.5、输出 12.5,对 sol 的 1 和 5。请把这当成一条用法说明,而不是一句警告。astra 是留给发布前的最后一遍复核、留给会有人照着行动的那份分析、留给没人会再读第二遍的一次性任务——也就是答错的代价高过所花 token 的那些活。

有一件事不在这个决定里:长度。这里没有任何模型对长上下文另外加价。每个模型的长上下文费率跟它自己的短上下文费率一行一行完全相同,所以一份长文档并不会改变它该发给哪个模型。按活有多难来选,输入有多大就让它是多大。

luna 扛后台的量

不是产品发出去的每一条都值得动用推理模型。分类、打标、短摘要、判断一条记录该进哪个队列——那些在每一条记录上都跑一遍、又没有人会单独去读的处理——是 luna 的活,它公布的定位是快速草稿、分类、摘要和大批量对话。输入 0.05,比 sol 便宜二十倍,输出权重是 0.3。

不过要把它的提示词保持精简,否则省下来的会原样还回去。一个后台任务并不需要你的全部上下文:让你的主力助手表现好的那段长 system prompt,放进一个分类器里通常只是死重量;而单价上便宜二十倍这件事,会被你多发二十倍的 token 一笔抹平。把要处理的那条、要用的标签发过去,别的什么都不要发。

四个混着用,然后核对账单

每个 token 多少积分,按模型和按类别列出,直接取自本站给其他一切定价所用的那份 catalogue——上面几段里的比例,说的就是这四行:

模型输入缓存读取缓存写入输出 + REASONING
astra2.50.252.512.5
sol10.115
terra0.50.050.53
luna0.050.0050.050.3

以上这些都不是选一次就固定下来的设置。四个模型共用一个端点、一个 key,而模型只是你本来就在发的那个 body 里的一个字段——该便宜的请求上改一个词,必须做对的请求上改一个词。

POST /v1/chat/completions

{
  "model": "terra",
  "messages": [
    {"role": "user", "content": "用一句话概括这个工单。"}
  ]
}

如果你的代码里写的是 OpenAI 风格的模型名,它会被读成所属的那一档,所以在你还没想好要改成什么之前,现成的配置照样能跑。正是这一点让混着用的试验很便宜:你不需要迁移任何东西,就能让一类请求先换个地方跑一个星期。

跑循环的 agent 还有两件事要做对。第一,每一轮开头保持一段稳定的前缀——system prompt、工具定义、轮与轮之间不变的那些指令——因为从缓存前缀里读回来的 token,只按它自己模型输入费率的十分之一计费;而每一轮都重新拼提示词的循环,等于每一圈都为同样的字付全价。第二,分层路由要有意为之,而不是照着习惯来:决定下一步做什么的 planner 通常值得用 sol 或 astra,执行它每一步的 worker 是 terra,事后把结果归置整理的那一遍是 luna。一个 agent,三个模型,是故意这么排的。

然后去核对。每一个请求都会按上表的费率在你的控制台里逐条列出来——哪个模型、哪一类 token、多少积分——所以你以为自己在跑的那套搭配,是可以核实的东西,而不是靠猜的。这一点才把上面所有内容从一种看法变成一套流程:把这页上的路由拿去用,让你自己一个星期的真实流量走一遍,然后回头读那份明细。

每一个请求都会按上表的费率在你的控制台里逐条列出来——哪个模型、哪一类 token、多少积分——所以你以为自己在跑的那套搭配,是可以核实的东西,而不是靠猜的。

本文为机器翻译,母语审校待完成。以英文版为准。