1. 这次更新到底改了什么：从模型分层到价格体系的全盘拆解
GPT-6 这波更新，我第一时间把手上几个跑量的项目切过去实测了。先说结论：Sol 和 Luna 两个新模型上线，Astra 的部分能力被下放，API 价格整体下调约 50%。这三件事单独看都不算小，凑在一起就是一次产品线的重新洗牌。很多朋友看到新闻第一反应是"又发新模型了"，但真正值得琢磨的是背后的分层逻辑——什么能力留在旗舰、什么能力下放、价格为什么能砍一半，这三者是有因果关系的。
先把三个名字理清楚，不然很容易看晕。Astra是这一代里能力最全的旗舰档，主打复杂推理、长上下文、多模态理解这些重活；Sol是这次新出的中坚档，定位是"日常主力"，覆盖绝大多数通用任务；Luna则是轻量档，主打快、便宜、够用。你可以把它理解成一条从重到轻的梯度：Astra 干最难的，Sol 干最多的，Luna 干最快的。这次更新的关键动作，是把原本只有 Astra 才有的几项能力（比如更强的结构化输出、更稳的长文档处理、部分多模态理解）下放到了 Sol，同时把 Luna 的性价比拉到极致。
为什么这个分层值得单独讲？因为过去一年很多人踩过的坑就是"用旗舰模型干轻活"。我见过一个团队拿 Astra 去做商品标题改写，一天几十万次调用，账单高得离谱，效果其实和轻量模型差不了多少。模型分层不是为了让你多花钱，恰恰相反，是为了让你按任务难度选档位，把预算花在刀刃上。这次价格直降 50%，本质上也是这个逻辑的延伸：当 Sol 能承接 Astra 的大部分日常任务时，单位成本自然就下来了。
那价格为什么能降这么多？这里有几个叠加因素。一是推理效率优化，新版本在同等硬件上吞吐更高，单位 token 的边际成本下降；二是能力下放带来的负载重分配，原本挤在旗舰模型上的请求被分流到 Sol 和 Luna，整体资源利用率上去了；三是竞争压力，这个不用多说，大家都懂。对开发者来说，最直接的影响就是：以前因为成本不敢上的功能，现在可以重新算一遍账了。
我拿一个真实场景算过：一个中等规模的客服问答系统，日均调用 20 万次，平均每次输入 800 token、输出 300 token。按老价格跑 Astra，一个月成本大概在四位数美元；换成 Sol 之后，同样的任务质量基本持平，成本直接砍到一半以下。这不是理论值，是我把同一批测试集跑了两遍对比出来的。所以这次更新对中小团队和个人开发者的意义，可能比对大厂还大——因为大厂本来就有议价能力，而中小团队是真的按标价付费的。
适合谁来参考这篇内容？三类人。第一类是正在选型的开发者，纠结到底该用哪个档位；第二类是已经在用但想优化成本的人，想知道怎么迁移、怎么压测；第三类是做 AI 应用的产品和运营，需要理解这次变化对功能设计的影响。不管你手上是 Python 脚本、还是接了工作流平台，下面的内容都能直接抄。
2. 三个模型怎么选：一张表讲清 Sol、Luna、Astra 的边界
选型这件事，最怕的就是"凭感觉"。我见过太多人上来就问"哪个模型最强"，然后无脑选旗舰。正确的问法是：我这个任务，最难的环节是什么？是长文档理解、是复杂推理、还是只是格式转换？把任务拆开，再对号入座，选型就清晰了。
先上一张我整理的对照表，这是基于我实测和官方文档综合出来的，参数是量级参考，具体以你接入时的实际返回为准：
| 维度 | Astra（旗舰） | Sol（中坚） | Luna（轻量） |
|---|---|---|---|
| 定位 | 复杂推理、长上下文、多模态 | 通用主力、日常任务 | 高频轻量、快速响应 |
| 上下文窗口 | 最大（百万级 token 量级） | 大（数十万 token 量级） | 中（十万 token 量级） |
| 推理深度 | 最强，适合多步推理 | 强，覆盖绝大多数场景 | 够用，适合单步任务 |
| 响应速度 | 相对慢 | 中等 | 最快 |
| 单位成本 | 最高 | 中等（本次下放后性价比突出） | 最低 |
| 典型场景 | 复杂分析、代码架构、长报告 | 客服、摘要、改写、抽取 | 分类、打标、简单问答 |
这张表怎么用？我给你一个判断口诀：任务里有没有"需要想好几步"的环节？有，就往 Astra 靠；没有，Sol 基本能扛；如果只是"看一眼就出结果"，Luna 足够。举个例子，让模型把一段用户评论分类成"好评/差评/中性"，这是单步判断，Luna 完全够用，用 Astra 就是浪费。但如果让模型读完一份 50 页的合同，找出所有风险条款并给出修改建议，这就是多步推理加长上下文，Astra 才稳。
这里有个很多人忽略的点：能力下放不等于能力等同。Sol 拿到了 Astra 的部分能力，比如更稳的结构化输出、更好的长文档处理，但在最难的推理任务上，两者还是有差距的。我实测过一个多跳推理题（需要串联三份文档的信息才能得出结论），Astra 一次答对，Sol 需要提示一次才答对，Luna 直接答偏。所以下放是"够用级"的下放，不是"顶配级"的平移。理解这一点，你就不会盲目地把所有任务都迁到 Sol。
再说 Luna 的定位。很多人觉得轻量模型"不够聪明"，其实是被旗舰模型惯坏了。Luna 的价值在于高频、低延迟、低成本。我有个做内容审核的项目，每天要过几百万条短文本，用 Luna 跑分类，延迟低到几乎无感，成本只有旗舰的零头。这种场景下，你根本不需要模型"会思考"，你只需要它"快速判断"。把 Luna 用对地方，它比 Astra 还香。
选型还有一个实操技巧：先用 Sol 打底，遇到瓶颈再升级。不要一上来就 Astra，也不要为了省钱硬用 Luna。我的做法是，新任务先用 Sol 跑一批测试集，看准确率和延迟是否达标；如果某些 case 明显不行，再单独把这些 case 路由到 Astra。这种"分级路由"的策略，能把成本压到最低，同时保证关键任务的质量。下面我会专门讲怎么实现路由。
3. 价格直降 50% 背后的账：成本怎么算、预算怎么重排
价格降了，但很多人其实不会算账。我见过有人只看"每百万 token 多少钱"，然后拍脑袋决定，结果月底账单还是超。真正的成本核算要分三层：输入成本、输出成本、以及被忽略的重试和缓存成本。这次降价对这三层的影响是不一样的。
先说输入和输出。大多数 API 的计费是输入便宜、输出贵，因为输出是模型"生成"的，算力消耗更大。这次降价，输入和输出的降幅可能不同，你需要去官方价目表确认。我实测下来，输出 token 的降幅对总成本影响最大，因为很多任务输出占比高。比如摘要任务，输入 2000 token、输出 500 token，输出虽然少，但单价高，所以输出降价带来的节省更明显。算账的时候，一定要按你实际任务的输入输出比例来算，别用平均值。
第二层是重试成本。这个最容易被忽略。模型偶尔会输出格式不对、或者答非所问，你就得重试。重试一次，成本翻倍。Astra 因为能力强，重试率低；Luna 因为能力弱，重试率可能高。所以不能只看单价，要看"有效成本"——也就是"完成一个任务的总花费"，包括重试。我做过对比：某个抽取任务，Astra 单价是 Luna 的 5 倍，但 Astra 一次成功率 98%，Luna 只有 85%，算上重试，Astra 的有效成本其实只比 Luna 高 2 倍多。这时候如果任务对准确率要求高，Astra 反而更划算。
第三层是缓存。很多 API 支持上下文缓存，重复的输入部分可以打折甚至免费。如果你的应用有大量重复的系统提示词（system prompt），缓存能省一大笔。这次降价之后，缓存的相对价值更高了，因为基础单价低了，缓存省下的绝对金额虽然少了，但占比可能更可观。我的建议是，把固定的系统提示词、few-shot 示例都放进缓存，这部分能省 30% 以上的输入成本。
给你一个我实际用的成本估算公式，直接抄：
单任务成本 = (输入token × 输入单价 + 输出token × 输出单价) × (1 / 一次成功率) × (1 - 缓存命中率 × 缓存折扣)这个公式里，一次成功率和缓存命中率是两个你需要实测的参数。别拍脑袋，跑 100 条真实数据测一下，比什么都准。我用这个公式帮一个团队重排了预算，他们原本打算全量迁到 Luna 省钱，算完发现关键任务迁过去后重试成本反而上升，最后改成"Sol 打底 + Astra 兜底 + Luna 处理简单分类"的混合方案，总成本降了 40% 多，质量还没掉。
预算重排的思路也顺带说一下。降价之后，我建议把省下来的钱分三份：一份用于升级关键任务（把原来因为贵而将就的任务换成更好的模型），一份用于增加测试覆盖（多跑压测，找到最优路由），一份留作缓冲（应对流量波动）。别一股脑全砍成本，那样容易把质量砍崩。降价的目的是让你"用同样的钱做更多事"，不是"用更少的钱做同样的事"。
4. 从 Astra 迁移到 Sol：一份可直接照做的实操流程
迁移这件事，最怕的就是"改个模型名就上线"。我踩过这个坑：早期把一个项目从旗舰切到中坚，以为只是换个 endpoint，结果输出格式变了、边界 case 处理变差了，线上直接出问题。所以迁移必须有一套流程，不能拍脑袋。下面这套是我现在固定用的，五步走，每一步都有验证。
4.1 第一步：建立基线测试集
在动任何代码之前，先建一个测试集。这个测试集要覆盖你线上真实流量的分布：高频任务、边界 case、以及历史出过问题的 case。我一般会从线上日志里抽 200 到 500 条，人工标注好期望输出。这个测试集是你后面所有对比的基准，没有它，你根本不知道迁移是变好了还是变差了。
测试集的构建有个技巧：按任务类型分层抽样。比如你的应用有摘要、抽取、分类三类任务，那就每类都抽，比例按线上流量来。别只抽简单的，边界 case 才是真正考验模型的地方。我见过有人测试集全是"标准问题"，迁移后测试全过，上线就崩，就是因为没覆盖边界。
4.2 第二步：并行跑双模型对比
有了测试集，就同时跑 Astra 和 Sol，逐条对比输出。这里不要只看"对不对"，要看四个维度：准确率、格式合规率、延迟、成本。准确率是硬指标，格式合规率决定你要不要加重试逻辑，延迟影响用户体验，成本是你的目标。我一般会做一个表格，把每条 case 的两个模型输出并排，人工过一遍。
对比的时候有个经验：重点关注"部分正确"的 case。全对的不用管，全错的也好判断，最难的是"对了一半"的——这种 case 往往暴露了模型能力的细微差距。比如一个抽取任务，Astra 抽出了 5 个字段全对，Sol 抽出了 4 个，漏了一个不明显的。这种差距在测试集上可能只占 5%，但在线上可能被放大。你要判断这个漏掉的字段重不重要，如果不重要，Sol 可以用；如果重要，就得考虑路由。
4.3 第三步：设计分级路由策略
如果 Sol 在大部分 case 上达标，只有少数不行，那就上路由。路由的逻辑很简单：先用 Sol 跑，判断结果是否可信，不可信的转 Astra。判断"可信"的方法有几种：一是看模型返回的置信度（如果 API 提供）；二是用规则校验输出格式；三是用一个轻量模型做二次判断。我用得最多的是规则校验加关键词兜底，简单可靠。
路由的代码结构大概是这样（Python 伪代码）：
def route_request(task, payload): # 简单任务直接走 Luna if task in ["classify", "tag", "simple_qa"]: return call_api("luna", payload) # 通用任务先走 Sol result = call_api("sol", payload) # 校验：格式不对或命中兜底关键词，转 Astra if not validate_format(result) or needs_escalation(result): return call_api("astra", payload) return result这个结构的好处是，大部分请求走便宜的档位，只有少数升级。我实测下来，一个抽取任务里只有 8% 的请求需要升级到 Astra，整体成本降了 45%，准确率几乎没掉。路由的阈值需要调，别一开始就设太严，否则升级率太高，省不下钱。
4.4 第四步：灰度上线与监控
路由写好了，别全量上。先灰度 5% 到 10% 的流量，观察一周。监控要看几个指标：升级率、准确率、延迟 P99、成本。升级率突然升高，说明 Sol 在某些场景下不行；准确率掉了，说明路由判断有问题；延迟 P99 升高，可能是升级请求拖慢了整体。这几个指标任何一个异常，都要回滚排查。
灰度期间我建议加一个"影子模式"：让 Sol 和 Astra 同时跑，但只用 Astra 的结果返回给用户，Sol 的结果记录下来对比。这样既不影响线上，又能收集真实流量的对比数据。跑一周下来，你就有足够的数据决定要不要全量。
4.5 第五步：全量切换与回滚预案
灰度没问题，就可以全量了。但全量不等于撒手不管，回滚预案必须提前准备好。我的做法是保留一个开关，出问题一键切回 Astra。同时保留至少一周的双写日志，方便出问题时对比。全量后第一周要盯紧，尤其是流量高峰时段，模型的表现可能和低峰不一样。
迁移这件事，慢就是快。我见过太多人图省事直接切，结果线上出问题，回滚又手忙脚乱。按这五步走，虽然多花几天，但省下的是后面无数个救火的夜晚。
5. 高频踩坑与排查：那些文档里不会写的经验
用新模型的过程中，坑是少不了的。我把这段时间踩过的、以及社群里大家反馈最多的问题整理了一下，做成速查表，遇到问题直接对号入座。
| 问题现象 | 可能原因 | 排查方向 | 解决建议 |
|---|---|---|---|
| 401 未授权，提示 API key 错误 | key 写错、环境变量没加载、key 被禁用 | 检查 key 字符串、环境变量、账户状态 | 重新生成 key，确认加载顺序 |
| 400 上下文超限 | 输入超过模型窗口 | 打印实际 token 数 | 截断、分段、或换更大窗口的档位 |
| 输出格式不稳定 | 模型档位能力差异 | 对比不同档位的格式合规率 | 加格式校验 + 重试，或升级档位 |
| 延迟突然升高 | 升级路由触发过多、并发过高 | 看升级率和并发数 | 调路由阈值，加限流 |
| 成本不降反升 | 重试率高、缓存没命中 | 统计有效成本 | 优化提示词，启用缓存 |
| 结果质量波动 | 提示词对某档位不适配 | 分档位调提示词 | 针对 Sol/Luna 单独优化 prompt |
这张表里，我重点说三个最容易踩的坑。
第一个是401 未授权。这个错误看起来低级，但实际非常高频，尤其是把 key 写进代码又提交到仓库、或者环境变量名拼错的时候。我自己的习惯是，key 一律走环境变量，绝不硬编码；加载后先打印一下前几位确认（别打印全的）。还有一点，有些平台的 key 分不同权限，你用的 key 可能没有新模型的调用权限，这时候也会报 401 或 403，要去后台确认权限范围。
第二个是400 上下文超限。这个错误的完整提示通常是"maximum context length is XXX tokens"。很多人看到这个就懵，其实很简单：你的输入加输出超过了模型窗口。解决办法有三个：截断输入（丢掉不重要的部分）、分段处理（把长文档切块分别处理再汇总）、换更大窗口的档位。我一般优先分段，因为截断会丢信息。分段的时候注意块与块之间要有重叠，否则跨块的信息会丢。
第三个是成本不降反升。这个最反直觉，但确实会发生。原因通常是重试率上去了，或者缓存没配好。我遇到过一次，切到轻量模型后，因为输出格式老是不对，重试了三次才成功，算下来比原来还贵。后来我针对这个档位重写了提示词，把格式要求写得更死，重试率降下来，成本才真正降下去。所以换档位一定要重新调提示词，不能直接复用。
再补充几个独家经验。一是别迷信"能力下放"，下放的能力是有边界的，复杂任务该用旗舰还得用旗舰。二是压测要用真实流量，别用构造的数据，真实流量的分布和边界 case 才是关键。三是留好日志，每次调用记录模型档位、token 数、延迟、是否重试，出问题时这些日志就是你的救命稻草。四是关注官方状态页，有时候问题不在你，在服务端，别自己瞎折腾。
6. 几个真实场景的落地示范
光讲方法不够，我拿三个真实场景给你演示怎么落地。这三个场景覆盖了从简单到复杂的梯度，你可以对照自己的项目找参考。
6.1 场景一：高频文本分类用 Luna
有个做社区内容审核的朋友，每天要过几百万条短文本，判断是否违规。这种任务的特点是：单条短、量大、判断标准明确。用 Astra 是杀鸡用牛刀，用 Luna 刚好。他的做法是，先用 Luna 跑一遍，把明显违规和明显正常的筛出来，剩下模棱两可的（大概占 5%）再转 Sol 或 Astra 人工复核。这样整体成本降了 70% 多，准确率还因为分级处理更稳了。
这个场景的关键是分类标准要写清楚。Luna 能力有限，你给的指令越明确，它表现越好。别给它模糊的"判断是否合适"，要给它具体的规则和例子。我帮他重写了提示词，把违规类型列成清单，每条给一个例子，准确率直接从 85% 提到 93%。
6.2 场景二：长文档摘要用 Sol 打底
另一个场景是合同摘要。输入是一份几十页的合同，输出是结构化的摘要，包括关键条款、风险点、建议。这种任务需要长上下文和一定的推理能力，Sol 是主力。他的做法是，先用 Sol 分段处理，每段生成小结，再把小结汇总成总摘要。如果某段 Sol 处理得不好（比如漏了关键条款），再单独把那段转 Astra 重处理。
这个场景的关键是分段策略。合同有天然的结构（章节、条款），按结构分段比按字数硬切好得多。我建议按标题层级切，每段带上前文的上下文，这样模型不会断章取义。汇总的时候，把各段小结按顺序拼起来，再让模型生成总摘要，效果比一次性塞进去还好。
6.3 场景三：复杂分析用 Astra 兜底
第三个场景是数据分析报告生成。输入是一堆数据表，输出是一份有洞察的分析报告。这种任务需要多步推理：先理解数据、再找规律、再得出结论、最后组织语言。这种任务 Sol 能做个七八成，但关键的洞察部分容易浅。他的做法是，用 Sol 生成初稿，再用 Astra 做一轮"深化"，专门针对洞察部分重写。这样既控制了成本，又保证了质量。
这个场景的关键是分工明确。别让 Astra 从头做，那样贵；也别让 Sol 硬扛，那样浅。让 Sol 做它擅长的（整理、组织），让 Astra 做它擅长的（推理、洞察），各司其职。我实测下来，这种"Sol 初稿 + Astra 深化"的模式，成本只有全 Astra 的 40%，质量能达到全 Astra 的 90% 以上。
这三个场景的共同点是：没有一刀切的方案，都是分级组合。这也是这次更新最核心的启示——模型多了、便宜了，但用好它们的关键，还是理解任务、合理分工。
7. 提示词适配：换档位后必须重调的那几处
换模型不调提示词，等于白换。这是我踩过最深的坑之一。不同档位的模型，对提示词的敏感度不一样：旗舰模型"聪明"，你写得糙它也能懂；轻量模型"老实"，你写得越明确它表现越好。所以迁移之后，提示词必须重新过一遍。
第一处要调的是格式要求。轻量模型对格式的遵循度通常弱一些，你要把输出格式写得更死。比如原来写"返回 JSON"，现在要写"返回 JSON，包含字段 a、b、c，a 是字符串，b 是数字，不要有任何额外文字"。我一般还会给一个完整的示例输出，让模型照着抄。这一招对 Luna 特别管用，格式合规率能从 80% 提到 95% 以上。
第二处要调的是指令的明确度。旗舰模型能处理模糊指令，轻量模型不行。原来写"总结一下"，现在要写"用三句话总结，每句不超过 30 字，第一句讲背景，第二句讲问题，第三句讲结论"。指令越具体，轻量模型表现越稳。这看起来啰嗦，但省下的是重试成本。
第三处要调的是few-shot 示例的数量。轻量模型更依赖示例。原来给 1 个示例，现在可能要给 3 个。示例要覆盖不同的情况，尤其是边界 case。我一般会从测试集里挑几个典型的，放进提示词。注意示例别太长，否则占上下文，得不偿失。
第四处要调的是系统提示词的结构。把固定的规则、角色设定、输出格式放在系统提示词里，把变量部分放在用户消息里。这样系统提示词可以缓存，省钱。而且结构清晰，模型更容易遵循。我习惯把系统提示词分成三段：角色、规则、格式，每段用标题隔开，模型理解起来更清楚。
调提示词这件事，没有捷径，就是测。改一版，跑测试集，看指标，再改。我一般会迭代三到五轮，直到指标达标。别嫌麻烦，提示词调好了，后面省下的成本和重试，远超你花的时间。
8. 我个人的几点体会
最后说点掏心窝的。这次更新之后，我最大的感受是：模型选型从"选最强"变成了"选最合适"。以前模型少、差距大，无脑选旗舰就行；现在档位多了、价格低了，反而更考验你对任务的理解。你得知道自己的任务难在哪，才能选对档位。
另一个体会是，成本优化不是一味求便宜。我见过有人为了省钱，把所有任务都塞给最便宜的模型，结果质量崩了，用户跑了，省下的钱还不够赔的。正确的做法是分级：简单的用便宜的，复杂的用贵的，关键的用最稳的。省钱的目的是把钱花在刀刃上，不是不花钱。
还有就是，别被"能力下放"冲昏头。下放是好事，但下放的能力有边界。复杂任务该用旗舰还得用旗舰，别为了省那点钱把质量搭进去。我的原则是：能用 Sol 解决的绝不用 Astra，但 Sol 解决不了的绝不硬撑。这个度，要靠测试集来把握，不能靠感觉。
如果你手上正好有项目在跑，我的建议是：先别急着全量迁移，花两天时间建个测试集，跑一轮对比，算清楚账，再决定怎么切。这两天的时间，能帮你省下后面几个月的冤枉钱。模型更新会越来越快，但"理解任务、合理分工、持续测试"这套方法，是不会过时的。
