GPT-6这次上来就是双模型Sol和Luna。不少朋友的第一反应是——GPT-5我已经用得很熟了折腾GPT-6到底图什么如果只看各家榜单上的数字确实看不出太大差别但真把手头项目跑一遍你会发现产品逻辑已经换了。Sol负责深度推理这类重型任务Luna负责高频轻量任务两者共用一套API但成本和用法完全不一样。我花了两周把现有项目从GPT-5迁到GPT-6又翻了大量开发者社区的实测反馈这篇就围绕比GPT-5强在哪展开把两个模型的分工、能力差异、迁移时踩过的坑一次性说清楚。1. 为什么GPT-6要拆成Sol和Luna产品逻辑的变化1.1 算力成本倒逼的双轨路线在GPT-5时代模型发布还是单一大通吃。你要么用最强的模型硬扛所有请求要么自己去找缩水的轻量版本但两者本质上是同一个模型只是做了裁剪或量化能力边界基本一致。GPT-6拆成Sol和Luna不是临时起意而是算力账单倒逼出来的。先算一笔账。一个复杂Agent任务可能要反复调用模型十几次甚至几十次如果每次都走满血的旗舰模型横向扩展一个几百人团队的量月度API账单就是天文数字。但反过来那些高频任务——代码补全、日志解析、SQL生成、格式转换——并不需要多深的推理链它们需要的是低延迟和稳定输出。单一模型没法同时满足两个方向把能力做深成本和延迟上去了把体积做小复杂任务又扛不住。Sol和Luna就是从训练阶段开始分家的两个模型。Sol的目标是把推理做深训练预算大量投向多步规划、超长上下文、复杂工具调用让它能处理过去GPT-5需要人工拆解的活。Luna则从Sol蒸馏出底座再用各垂直领域数据做定向强化目标是把成本和延迟压下来。这套路和过去那种大模型剪出小模型完全不同——Luna不是一个缩小版Sol而是一个偏科偏得很明确的专业模型。1.2 Astra被多数人忽略的第三块拼图讨论GPT-6的人大多盯着Sol和Luna但实际上这次还有一个很容易被忽略的组件Astra。从社区讨论热度来看最出圈的一个场景是GPT-6 Astra画电路图——Astra定位在多模态的工程创作层负责把事情从用文字描述变成看得见摸得着的图纸。怎么理解Astra和Sol/Luna之间的关系我用一句话概括Sol和Luna解决话怎么说Astra解决图怎么画。当你让Astra画一张电源管理电路图时Luna先把你的需求解析成结构化要点——输入电压范围、输出电流、保护逻辑、元器件选型约束——然后Astra基于这些要点生成原理图草稿你在画布上继续调。整个过程不是一句画个电路图就完事而是文本理解和视觉生成两条链路各司其职。对硬件工程师、PCB Layout、前端架构图这些群体来说Astra才是GPT-6真正有感知的升级点。后面第3章我会专门用一节讲这个场景的实际工作流。1.3 对普通开发者意味着什么先说结论如果你只是拿API做一次性问答GPT-6的升级感知不明显但如果你的业务涉及复杂任务编排、批量处理、或者有自己的产品要接入LLM这次的拆分方式直接影响你的架构选型。过去接GPT-5只需要在能力和预算之间做一次折中。现在你要多考虑一层——任务形态。任务偏推理重、链路长、上下文大选Sol任务偏高频、碎片化、格式要求严选Luna涉及图纸、图表、可视化呈现要配合Astra。这不是挑模型的小事选错了直接表现为响应慢、成本高、或者输出结果不符合预期。这章的结论先放在这后面的内容全部围绕这个判断展开。2. Sol相对GPT-5的核心升级不是更聪明而是想得更深2.1 多步推理从直觉回答到先规划后执行GPT-5已经展示了链式思考Chain of Thought的能力但它的思路是逐步展开的——拿到问题想一想回答一步再想下一步。这种方式的短板在于缺少全局计划步骤多一点、依赖关系复杂一点模型很容易在中途走偏而且走偏之后还不容易自己发现。Sol在多步推理上的变化用一句话说是先出计划再动手。它在内部会先对任务做一个整体拆解要完成这个目标需要哪几个子任务每个子任务的输入输出是什么最后怎么汇总验证。执行过程中还会做自查发现某一步的结果和前面的假设矛盾会主动回溯修正而不是硬着头皮继续生成。我自己的实测感受很直接。拿一个典型的代码库分析任务——给定一个中等规模项目定位内存泄漏的可能位置。GPT-5的做法通常是先看几处可疑代码然后直接给出猜测最后补一段建议。Sol的做法是先梳理这个项目的数据流和生命周期列出一个检查计划然后按计划逐文件排查每查完一个模块会在推理过程中更新候选原因列表最后输出的是完整推理链路。最终结论未必总是对的但很少出现看着好像有道理、实际没法往下查的模糊答案。2.2 长上下文不再是堆窗口而是能找到重点这次Sol的上下文窗口大幅扩展但我认为真正的升级不在数字本身而在于它能在超长文本里找到重点。GPT-5的长上下文有两个典型问题一是中间信息遗忘开头和结尾记得清楚中间内容会漂移二是无差别读取塞进去100页资料它会均匀分配注意力关键信息和无关内容混在一起。Sol的进步在于动态聚焦——它在处理长文档时会先做一次全局扫描标出与当前任务相关的高价值区段后续生成集中在这些区段上。直观感受是我在一个40万token的连续代码库里做检索式问答结果比之前GPT-5在10万token范围内还要准而且不会出现前面刚说完后面就忘了的现象。这里要提醒一句上下文窗口大不代表你可以把一切都堆进prompt。实际测试中超长上下文的成本增量是非线性的越是长文档调用单次价格涨得越快。所以哪怕Sol支持512K窗口合理的做法仍然是先做信息提取和切片把真正需要的部分带进上下文而不是把整个日志库原样丢给它。2.3 实测对比我在内部测试集上看到的变化我把自己日常维护的一个评测集跑了一遍覆盖代码修复、SQL生成、多文档摘要、工具调用、格式转换五类任务。下面是粗略对比只代表我个人观察不涉及任何官方数据。维度GPT-5GPT-6 SolGPT-6 Luna上下文窗口32K / 128K 两档更大实测长文档聚焦更好中长窗口够用多步工具调用稳定但中途容易走偏规划自检偏离后能回溯简单Agent可跑复杂链路建议交给Sol代码/结构化输出好最强接近GPT-5但延迟明显低相对成本倍率1x明显高于GPT-5明显低于GPT-5适用场景通用问答深度研究、复杂Agent、长文档高频查询、代码补全、格式转换这张表最关键的一行其实是最后一行Sol和Luna不是替代关系是互补关系。如果你拿Sol干Luna的活大概率会觉得费钱又啰嗦拿Luna干Sol的活又会觉得不够聪明。这和当初在GPT-5上一个模型调参数的体验完全不同。3. Luna的定向强化轻量模型怎么做到人尽其才3.1 蒸馏和定向强化小模型为什么可以专起来过去轻量模型给我们的普遍印象是什么都行一点什么都不精。那是因为它们通常只是大模型参数量的裁剪版或者用了简单蒸馏能力被整体稀释。Luna的训练路线不太一样。第一步从Sol蒸馏出一个通用底座保证语言能力和基础推理不掉线第二步用大量特定领域数据做定向强化这些领域不是随机选的而是生产环境里调用量最大、最需要稳定性的场景——代码理解与生成、SQL与数据处理、结构化文档输出、工具调用参数生成、知识库问答。定向强化的效果是Luna在这些垂直任务上可以做到接近Sol的水平同时在延迟和成本上甩开Sol一大截。用一句话比喻Sol是能处理疑难杂症的全科医生Luna是扎在几个科室里的主治医生。你去看常见病主治医生足够还快真遇到跨科室的复杂问题再转诊到全科那里。硬要一个主治医生去应对所有疑难杂症那就用错人了。3.2 代码和结构化输出Luna最值得用的两个场景实测下来Luna最让我放心的是两个场景。第一是代码补全和代码解释。日常开发中的CRUD逻辑、单元测试编写、函数重构Luna的输出质量与Sol差距很小但延迟低了一半不止。在IDE插件里做实时补全体感差距非常明显。第二是严格的结构化输出。我这里说的不只是返回JSON而是返回符合你定义Schema的JSON。Luna对格式约束的遵循很稳定很少出现字段名被改写、数组结构被简化、枚举值超出范围这类问题。如果你要拿它作为数据清洗管道的一环比如从大量非结构化文本里抽取实体、生成规范化记录Luna比GPT-5更让我省心——不需要在prompt里反复强调格式也不需要总做后置校验。反过来Luna不擅长的是开放式的创意写作、辩论、头脑风暴。这些任务需要发散性和深层语义理解Luna的输出会显得偏稳定但缺少灵光。遇到这类需求让它写第一版、再用Sol润色是一个不错的搭配。3.3 Astra联动电路图这类视觉工程任务的干活方式Astra这个组件在画电路图上被讨论最多我实际体验后觉得它的工作方式可以抽象成一个三段式流程对其他工程绘图场景也有参考价值。第一段需求理解。你在画布上摆一个需求描述比如设计一个基于ESP32的锂电池供电电路输入电压3.7V需要过压保护、过流保护和充电指示Luna负责把这句自然语言拆成规格列表主控型号、电池接口、保护芯片选型约束、LED指示电路、PCB布线注意事项。这一步输出的结构化规格是整个流程的锚点后面Astra生成图纸时都围绕这个规格走。第二段图纸生成。Astra基于Luna给的规格生成原理图草稿包含器件符号、网络连接关系、关键引脚标注。不同于单纯的图像生成模型把电路图画得像张漂亮的插画Astra在生成时会更注重电气连接是否自洽——至少不会把电源线和地线接在一起。第三段交互调优。你在画布上圈出某一部分用自然语言指令修改——把这里的PMOS换成NMOS并添加一个10K下拉电阻——Astra直接在原图上更新而不是重新生成一张新图。这种文本理解模型视觉生成模型的配合本质上是把一个人从需求到图纸的完整工作流拆给了不同组件各做自己最擅长的事。对于只把GPT-6理解成更强聊天模型的人来说这一块是认知盲区但我觉得它才是GPT-6这次真正扩展边界的地方。4. 从GPT-5迁移到GPT-6的实测三个意外和对应调整4.1 意外一Sol对简单问题的过度思考迁移后第一个让我不习惯的变化是Sol回答一个简单问题时经常给出一大段分析过程甚至会主动补充这里我考虑了两种可能。原因是Sol的推理机制默认倾向想得更深。你拿它做复杂任务这是优点你只是问一句北京今天的天气适合穿什么它也会在内部过一遍穷举——这就没必要了。调整方案有两个。第一为不同任务设置不同的推理强度参数短问题把推理调到最低档复杂任务再拉高。第二也是更推荐的方案简单问题不要走Sol直接交给Luna。Luna没有Sol那样的深度推理包袱回答轻量、直接、快。这既是成本优化也是体验优化。我的经验是把问题先做一次分类需要规划、验证、多步骤处理的才进Sol其余默认进Luna。4.2 意外二System Prompt的影响力比我预想的大在GPT-5上System Prompt的作用更多是风格引导——你告诉它你是资深工程师它会调整语气和详略但改变不了太多实质输出。到GPT-6这套新架构下System Prompt的作用明显增强了尤其在Luna身上。原因是Luna的定向强化依赖清晰的上下文限定。你在System Prompt里写清楚任务类型、输出格式约束、负面禁止项它会快速进入对应领域的高效模式反过来如果你沿用GPT-5时代那种非常短的System PromptLuna可能表现得跟一个通用小模型差不多白白浪费了它的定向强化优势。我现在的System Prompt模板比GPT-5时代长了不少包含四块角色定义、任务边界、输出格式直接给JSON Schema、禁止行为。开一次项目级System Prompt后续每个请求中都带完整上下文效果稳定很多。这条经验在官方文档里不太会写但实测影响很大。4.3 意外三工具调用接口的兼容性没有想象中好GPT-5的Function Calling用习惯之后切到GPT-6我以为只是改个模型名的事。实际测试发现工具调用的触发逻辑和参数校验变得不一样了——有些以前能稳定触发的工具名现在会拿不到参数有些工具返回结构的嵌套层级和字段命名也变了。最直接的影响是原来写好的Agent轮询代码放到GPT-6上出现了一部分请求不走工具而是直接生成文本的情况。排查下来不是模型变笨了而是新模型的工具调用机制更严格它对参数Schema里的类型和必填项校验更认真。旧代码里很多差不多能用的Schema定义在新机制下会被直接判定为非法参数。调整方案是升级到新的SDK版本把工具调用的Schema定义重新梳理跑一轮完整的回归测试。别以为换个model字段就能覆盖兼容这在GPT-6这套双模型架构里行不通。4.4 迁移检查清单我把这次迁移的经验整理成一份可复用的清单团队接入时可以直接拿去做对照先建一个小规模的评测集覆盖你们线上最高频的20种任务类型在Sol和Luna各跑一遍确认底线能力。重写System Prompt尽量结构化尤其是Luna的任务至少要包含输出格式约束。把工具调用的Schema全部重新定义跑回归测试别复用旧字段。用灰度策略上线先10%流量切到Luna稳定后再逐步放开Sol的复杂任务。成本监控要细到任务维度别只看总量。我见过最典型的坑总量降了但某个重任务从GPT-5换成Sol后成本翻了好几倍没有任务级监控根本发现不了。保留降级开关。上线初期备好一条失败重试到GPT-5的后路收益稳定后再摘掉。5. Sol/Luna/Astra怎么搭一个更省钱的工作流5.1 先给任务分个形状接GPT-6之前先把任务按形状分三类比纠结哪个模型更强有意义的得多。第一类是重推理任务多步骤代码库分析、复杂SQL调优、需要长文档阅读与综合判断的研究类问题、Agent链路中的核心决策节点。这类任务对推理深度和准确性要求高用Sol。第二类是高频轻量任务代码补全、单元测试生成、接口文档编写、数据清洗、格式化输出、内部知识库的常见问答。这类任务量大、模式相对固定、对延迟敏感用Luna。第三类是视觉呈现任务原理图、架构图、流程图、演示文稿配图需要走Astra这条链路通常配合Luna做前置需求解析。判断标准就一条这个任务如果做错一次代价有多大代价高走Sol代价低但量大走Luna。很简单的成本收益逻辑。5.2 级联路由Luna打底、Sol兜底我目前最推荐的做法不是让用户在两个模型里手动挑而是在中间加一层路由逻辑。默认请求先进Luna如果Luna对任务的置信度不足或者用户对结果不满意并触发深入分析按钮再升级到Sol。下面是一个简单的示例逻辑真实接入时还要加上缓存、限流、日志def route_and_answer(prompt, task_type): if task_type in (code_completion, sql_gen, format_transform): return luna.complete(prompt, temperature0.2) if task_type deep_reasoning: return sol.complete(prompt, reasoninghigh) # 默认先试Luna低置信度再升级Sol result luna.complete(prompt, temperature0.2) if result.confidence 0.7: result sol.complete(prompt, reasoninghigh) return result这套策略的受益非常直观。业务量相同的条件下Luna承接了大约七成请求账单项级成本大幅下降剩下三成真正需要深度的任务用Sol最终的用户满意度反而比之前全量用GPT-5更高。原因很简单过去GPT-5在简单任务上勉强够用在复杂任务上有点勉强现在简单任务用Luna又准又快复杂任务用Sol真正能拿下来两端体验都更好了。5.3 一些可以进一步做调优的点最后说几个我还在持续调优的方向供你参考。第一是缓存策略。Luna处理高频任务时如果结果有很强的确定性可以做语义缓存——相同意图的问题直接命中缓存连Luna都不用调。实测在知识库问答这类场景中缓存命中率可以达到四成以上。第二是上下文预算管理。不要因为支持长上下文就在prompt里堆料。进入Sol的资料需要做切片、压缩、抽取重点把价值密度最高的内容放进去。这既是保质量也是控成本。第三是日志驱动的模型调参。每一轮请求都记录路由选择、模型返回的置信度、用户是否点了再次生成、最终采纳率。用这些数据反推路由阈值——如果用户对Luna结果反复点击重新生成说明这类任务应该升级到Sol如果Sol的复杂任务大量被直接采纳说明当前的重任务判定太保守。我在实际操作中最大的体会是GPT-6这套东西价值不在某一个模型冲上了榜单第一而在于它把聪明的智商和便宜的快手拆开卖。Sol负责镇场子Luna负责撑场子Astra负责把事情从文本落到画面。你不用再为一个全能但成本高的模型支付所有场景的溢价也不用来回切换多个供应商。迁移本身有一点摩擦主要是接口和System Prompt要重做一轮但做完之后我手头的业务是真正意义上该便宜的地方便宜该强的地方强。
