GPT-6 Sol 和 Luna 的评测文我憋了整整一周才发出来。不是没东西写而是这次的信息量实在太密同源模型拆成两个形态一个叫 Sol 主打旗舰级能力一个叫 Luna 主攻成本控制API 价格直接腰斩。圈子里讨论最凶的话题已经不是模型变聪明了多少而是——当能力开始下沉、价格开始踩踏AI 应用的商业模式是不是要重新算一遍。这次我以重度 API 开发者身份跑了几天真实负载把两个模型丢进代码生成、复杂推理、长上下文三种典型场景里反复蹂躏同时扒了扒它们背后的架构变化和定价逻辑。结论先放在这GPT-6 这次发布单点能力提升其实没有 GPT-4 到 GPT-5 那种惊艳一跃但能力下沉 价格腰斩 规模化部署这套组合拳对整个 AI 应用生态的冲击比任何一次单项技术突破都大。下面把评测过程和思考完整拆开讲。1. 别急着跑分先弄懂 Sol 和 Luna 在打什么牌1.1 两个型号不是高低配是两套部署哲学很多人第一反应是 Sol 和 Luna 的关系就像汽车里的高配和低配顶配版有的功能低配版砍一刀再卖。实际用下来完全不是这么回事。Sol 和 Luna 用的底层预训练权重同源但经过不同的后训练路线、不同的稀疏激活配置、不同的推理优化策略最终产出的是两个性格迥异的模型。Sol 的定位是重武器追求单次请求的智商天花板面对复杂推理、长链条任务、密集知识问答时几乎没有妥协。它的参数量巨大上下文窗口做到了 1M token基本可以整本《三体》三部曲直接塞进上下文再追问细节。代价是响应延迟高、单次推理消耗的算力多、价格贵。Luna 的定位是劳模同样拥有数万亿参数的总量但每次推理只激活很少一部分专家上下文窗口控制在 256K配合更激进的量化和缓存策略把单 token 成本压到了上一代旗舰的一半。它追求的不是最聪明而是在成本可控的前提下足够聪明。我打个比方Sol 是请一个全科专家团队来给你的项目做深度咨询Luna 是同一个机构里按需派两三个专家快速帮你搞定常规难题。专家库一样大但 Luna 优化了到现场的成本。这个差异决定了它们面向的场景完全不同——Sol 适合做研究、离线批处理、高价值单次任务Luna 适合做在线服务、Agent 高频调用、对延迟和成本敏感的生产环境。1.2 为什么偏要拆成两个名字而不是一个模型两档定价这是我这周想得最多的一个问题。技术上完全可以让用户通过参数切换推理精度和激活规模OpenAI 偏要拆成两个独立产品线我认为核心原因是成本透明度。如果只有一个模型开发者很难理解为什么同样的输入输出有时候快有时候慢、有时候贵有时候便宜抱怨和调试成本都会转移到厂商身上。拆成 Sol 和 Luna定价表一目了然跑 Sol 你就按旗舰价预算跑 Luna 你就按经济价规划。这对企业采购、财务核算、成本预测都友好得多。更深一层这其实是在为规模化时代铺路。当 AI 应用从尝鲜走向全量生产决策者最需要的不是这个模型能做什么而是这个模型跑一个真实业务流要花多少钱。双型号策略让技术选型变得像选云服务器规格一样清晰——按业务量级选按成本红线选按延迟要求选。我自己在规划新项目时第一件事已经不是看 benchmark而是先把 Sol 和 Luna 的单位成本换算成自己业务量级的月度预算。这种思维转变本身就是行业成熟化的信号。2. 能力下沉背后的技术含量比你想象的高2.1 MoE 稀疏激活Luna 怎么做到又大又省Luna 的能力下沉不是简单地把模型做小而是保留了完整的大模型规模靠 MoEMixture of Experts混合专家架构实现按需激活。你可以把 MoE 想象成一家巨型咨询公司公司里挂着几千名专家的名字总参数量但接到一个具体项目时只需要叫上其中二三十个对口的人激活参数剩下的专家继续待命。这次 GPT-6 的 MoE 做了两个我很在意的改进。第一是专家路由的分配粒度更细了路由网络不再只是把请求整体分配给几个专家而是按 token 级别独立路由——也就是说一句话里的和量子纠缠走的可能不是同一批专家。这样做的直接收益是处理专业内容时不会浪费专家资源在通用词汇上处理日常闲聊时也不会误触发高成本的专业知识专家。第二是负载均衡策略明显更成熟了。MoE 模型最怕路况拥堵——某个热门领域的请求量大老是命中同一批专家导致计算热点和排队。GPT-6 的路由层加了动态偏移和负载感知机制我实测高并发下的 P95 延迟比上一代 MoE 模型稳定很多没有出现某个时刻突然集体变慢的毛刺。这一点对生产环境至关重要因为它直接影响你服务端的扩容设计和用户体验的一致性。2.2 量化和 KV Cache 瘦身从高精度倔强到够用就好Luna 能实现价格腰斩另一半功劳来自推理引擎层面的极度抠门。先说量化全精度FP16/BF16的权重在推理时被压缩到 FP8 甚至 INT8每个参数占用的显存和带宽直接砍半甚至砍到四分之一。精度损失换来的速度提升非常可观而且在大多数实际任务上Luna 的输出质量没有明显劣化。然后是 KV Cache 的优化这是我这几年评测里最容易忽略但影响巨大的部分。生成式模型每吐一个 token都要把之前所有 token 的 Key 和 Value 缓存下来用于注意力计算。上下文越长缓存占用越大。Luna 用了两招一是缓存压缩用低秩近似把 KV 占用的空间压下来二是缓存复用——如果请求的前缀命中了之前的计算结果直接复用而不是重算。这两招叠加的效果我在实际压测中感受很明显同样 100K 上下文的输入Luna 的首 token 延迟比 Sol 低了接近三倍而且在高并发下显存没有出现爆炸式增长。这意味着同样的钱Luna 能在同一块 GPU 上喂给更多人用这是规模化时代最需要的特性。2.3 蒸馏与合成数据Luna 是 Sol 的学生但学生不差还有一个绕不开的技术环节Luna 的能力一定程度上是从 Sol 蒸馏过来的。具体做法是拿 Sol 在海量高质量任务上生成输出再用这些输出做训练数据去锤炼 Luna让 Luna 学 Sol 的解题思路而不是死记硬背答案。蒸馏模型通常有个通病学得到答案的形状学不到推理的骨架。遇到训练数据里出现过的题型表现接近老师遇到没见过的变体容易翻车。Luna 这次在躲开这个坑上下了功夫它通过大规模合成数据把推理过程也蒸馏了下来——不只是答案是什么还有答案怎么一步步推出来的。在实际测试里Luna 面对逻辑变体题的表现让我有点意外它并没有明显比 Sol 差。当然如果用特别刁钻的边界题去拉满难度Sol 的思维深度还是肉眼可见地胜一筹。但体感上线是Sol 能解决的日常难题里Luna 能解决 85% 以上而成本只要一半。这笔账对绝大多数业务场景来说划算得不像话。3. 价格腰斩怎么算的这账不能只看数字3.1 价格变化明细确实砍到了腰上先把这次的价格变化摊开算一笔账。上一代旗舰模型按 GPT-5 时代的高端档位算的公开 API 定价大约是输入 15 美元/百万 token、输出 60 美元/百万 token。这次 GPT-6 Luna 直接把输入价打到 7.5 美元、输出价打到 30 美元——如果你用的是高频批量场景配合新的 Batch API 折扣还能再省 50%。折算下来单位 token 成本是上一代旗舰的四分之一。Sol 的定价则是 30 美元输入、120 美元输出比上一代旗舰贵一倍。这个价格差不是拍脑袋定的它反映了真实推理成本差异Sol 激活的专家数多、上下文窗口大、KV Cache 占用高跑一次复杂推理的算力开销大约是 Luna 的 4 到 6 倍。定价倍率基本贴住了成本倍率说明这次定价不是营销导向而是真实成本结构的映射。我测算过一个真实项目一个文档问答 Agent平均每次对话消耗 6K 输入 1.5K 输出 token每天 10 万次调用。如果用 Luna 按标准价算日成本大约 90 美元如果用同一体量的上一代旗舰模型日成本约 180 美元如果走批量通道还能压到 45 美元。这个数量级的成本下降意味着原本算不过账的 AI 功能可以正大光明地全量上线。3.2 降价底气规模化不是口号是实打实的摊薄外行看降价以为厂商在搞补贴抢市场。内行看门道得琢磨它凭什么降价。GPT-6 这轮降价的底气主要来自三个规模化效应。第一是推理资源池化。模型上线越久厂商对流量峰谷的预测越准可以把空闲算力打包给低价通道跑异步任务摊薄整体单位成本。第二是缓存命中率上升。越多人用相似前缀的提示词缓存复用率越高很多重复计算直接省了。第三是硬件利用率拉满。新一代推理引擎对 GPU 的调度更精细可以把不同长度的请求混合编排减少碎片化空转。这三个效应叠加在一起单位 token 的真实成本可能比上一代降了 40% 到 50%。OpenAI 没有把这部分利润全吃掉而是通过降价让利给开发者换取更大规模的调用量再靠规模反过来进一步摊薄成本。这就是规模化时代的核心循环成本降 → 用量涨 → 规模升 → 成本再降。只要这个循环转得起来后来者几乎没法在价格维度上跟它竞争。3.3 降价对生态的连锁反应Agent 和独立开发者的春天来了价格腰斩最直接的影响面是大量被成本卡住的项目开始松动。我做 AI 应用这几年的体感是很多场景技术上早就通了就是每次调用几分钱还是几厘钱决定它能不能上生产。Luna 把单位成本砸到几厘钱量级之后至少三类项目能明显受益。第一类是高频低价值的自动化流程比如日志分类、邮件初筛、客服预接待以前跑百万级调用得精打细算现在随便跑也不心疼。第二类是 Agent 类应用一个 Agent 完成任务要来回调好几轮模型累计 token 消耗大模型降价直接让 Agent 的单次任务成本断崖式下降。第三类是独立开发者以前做 AI 产品要融资才烧得起推理费现在个人开发者的成本结构和五年前做 App 差不太多了小团队又能进场玩了。4. 实测记录把 Sol 和 Luna 扔进真实场景里过堂4.1 代码生成与调试好坏一眼见分晓我这次没有用网上那些模板化的编程题而是拿了自己项目里一个真实需求写一个带并发节流、失败重试、断点续传的文件批量处理脚本要求用 Python 3.11 asyncio 实现。Sol 的表现确实惊艳只给了一段需求描述它直接生成了一份接近生产质量的代码。不仅考虑到了信号量控制并发上限、指数退避重试、进度状态持久化还主动加了日志模块和异常分类处理。我把代码丢进运行环境里跑了两个小时的压测任务只修了一处边界条件下的类型问题整体架构完全站得住。Luna 的表现要打个折扣它生成的第一版代码功能完整但缺少两个细节一是没有做断点续传进程挂了就得从头跑二是重试逻辑里没有区分可重试异常和不可重试异常碰到参数错误也会傻傻地重试三次。发现问题后我直接把报错信息贴回去让它修Luna 很快给出了补丁但这个过程说明它的主动设计意识比 Sol 弱一档。我的判断是如果只要求把功能跑通Luna 完全够用甚至会超出预期但如果要求第一次就把生产级细节想全Sol 的价值就在那 15% 的经验差距上。前者省钱省时间后者省心。4.2 复杂推理与数学差距主要藏在想几步上推理能力的测试我用了一组逻辑谜题和一道需要多步计算的数学题。Sol 在复杂推理上的优越是结构性的它会把问题拆成清晰的分步求解链前提假设、中间推导、结论验证都摆在明面上而且每一步都会回头检查逻辑一致性。那感觉像在跟一个思路极有条理的同事讨论问题。Luna 在单步推理和两步以内的逻辑链上表现得相当利落但面对需要五步以上链条的问题时偶尔会出现中间结论正确但我选择忽略它继续往下跑的情况。典型例子一道涉及分类讨论的题它列出了三种情况分析完前两种之后第三种情况突然被它合并进了第二种的结论里导致最终答案残缺。我重新提问并强调请单独讨论第三种情况之后它又能顺利完成。这个差异决定了场景分水岭如果你做的事情是从文档里提取要点并归纳结论这类浅推理活Luna 和 Sol 的体验差不太多但如果你在做数学证明、合同条款交叉核验、复杂策略推演这类必须穷尽所有分支的工作Sol 的严谨性值回票价。4.3 长上下文Sol 的 1M 是真能打还是营销参数长上下文是 GPT-6 这次最吸引我的点之一我专门做了一个大海捞针式测试把一本 60 万字的行业报告放进 Sol 的 1M 上下文窗口随后问它第 42 页末尾提到的某个数据的上下文。Sol 在 700K token 的输入长度下不但准确找到了位置还能用报告里的前后文重新组织出完整回答这个表现比我预期的要强很多。Luna 的 256K 上下文在实际使用中也够用了但体验上有一个需要留意的点当输入长度超过 150K 之后它对深入埋在中间段落的表层事实的召回率会有轻微下降尤其是该事实只出现一次且周围没有重复强调时。好在日常业务场景很少真把 200K token 塞满常规的对话历史、知识库片段组合Luna 处理起来没有明显毛病。如果你要做的是把整库文档一次性喂进去再做全局分析目前只有 Sol 能做到让人放心的程度Luna 更适合做大窗口但不需要每寸都细究的粗筛。这里我的建议是长文档场景优先使用 Sol 完成深度分析把 Luna 用作前置过滤和分块检索后的摘要器两兄弟搭配干活成本和效果同时兼顾。5. 落地实践怎么调参、怎么选型、怎么避坑5.1 API 参数配置同一套参数两兄弟要区别对待我实际把同一套 Agent 流程分别跑在 Sol 和 Luna 上发现参数不能照搬否则体验会差很多。下面是我实测后调出来的基准配置先给个表格参数Sol 推荐值Luna 推荐值原因temperature0.4 - 0.60.2 - 0.4Sol 本身思维链稳定稍高一点的温度能带出多样化方案Luna 的上下文穷尽能力偏弱温度太高容易跑偏分支top_p0.90.8控制随机性的逻辑与 temperature 类似Luna 需要更保守的采样范围max_tokens尽量给满按任务估算 30% 余量Sol 长推理时很能想截断会严重破坏结果完整性presence_penalty0 - 0.30.5 - 0.7对 Luna 加一点新鲜度惩罚可以减少它在长回答里复读自己说过内容的毛病还有一个必须提醒的坑Luna 对 system prompt 的遵循度比 Sol 敏感我在 Agent 场景里给 Luna 写了很长的 system prompt 后它偶尔会忘掉规则里的细节。解决方法是把 system prompt 拆成多个短小节并定期把关键约束轮流 mention 进最近的对话上下文里。Sol 则基本没有这个问题长 prompt 也扛得很稳。5.2 选型决策什么场景无脑上 Sol什么场景闭眼用 Luna我整理了几天实测下来自己的选型判断不一定适合所有团队至少可以当参考代码架构设计、复杂调试思路生成选 Sol。它生成代码的结构完整度和架构洞察力明显高一截省下的返工时间远超多付的 API 费。大批量内容改写、摘要、分类、信息抽取选 Luna。这类任务对深度推理要求不高Luna 的输出质量足够成本优势拉满。多轮 Agent 对话、工具调用流程默认 Luna。Agent 的核心是高频规划和小步推理Luna 能胜任绝大多数规划步骤只有遇到特别拧巴的子任务时再临时升级 Sol 出手。长文档全局分析、万字级合同的交叉条款审查、研究报告深层推理选 Sol。1M 上下文加上严密的推理链这个场景是它唯一能打的。预算有限的个人开发者、前半夜自己测试、academic 级别研究初筛先选 Luna。把 Luna 当穷人版旗舰用大多数问题已经能顶过去了。5.3 常见问题排查实录这几天我踩过的坑我把实测中踩过的坑整理成速查表应该能帮你少绕一些弯现象大概率原因解决与排查Luna 输出中途断片忘记最初的需求上下文太长导致注意力稀释或 system prompt 细节被冲淡把关键需求周期性地写进最近的对话里分割任务不要一个对话里叠太多环节同样的请求Sol 偶尔比 Luna 慢 5 倍以上Sol 的稀疏激活范围广、缓存命中率低这是正常现象建议给 Sol 单独做超时阈值Server 端不要跟 Luna 混在同一个超时策略里Batch 通道定价没生效没有满足 Batch API 的 24 小时以内延迟要求检查是否关闭了 Stream 并启用了离线文件上传模式价位只对非实时批处理生效Luna 代码返回结果里有幻觉 API 方法蒸馏模型对代码 API 名称的记忆不如参数封存完整把目标库的文档片段直接放进 prompt必要时升级到 Sol新库或不常见库别让 Luna 空写跑长上下文任务时结果前后矛盾窗口太大、注意力稀疏模型记不全先让模型输出阶段性小结分段处理再合并全局结论不要一步到位还有一条实操经验值得单独说Luna 的响应速度对流式输出很友好首 token 延迟低但高并发下的稳定性需要自己在代码里加一层重试。我压测时遇到大约千分之二的请求超时重试一次后几乎全过。建议所有线上请求都配备指数退避重试别把上游模型当永不故障的组件。6. 规模化时代真正想问的问题是你的应用架构准备好没有6.1 从模型适配应用到应用适配模型的思维反转以前我们做 AI 应用思维方式是先定一个模型再围绕它的能力边界设计产品功能模型不够强就用提示词技巧硬凑。GPT-6 这轮 Sol/Luna 的双型号策略逼着开发者换一种思路先定义业务成本和效果要求的上下限再去挑模型档位甚至把两个型号组合进同一条产品链路里。我自己已经开始把项目架构改成路由优先的设计用户请求进来后先用一个分类器判断任务复杂度简单的走 Luna复杂的升级到 Sol最后把两边的结果 ratio 汇总到日志系统里做成本分析。这套架构在以前没有必要因为所有请求都打同一个模型成本无从优化。现在不同档位的模型存在了架构上的成本感知就变成了必修课。未来几个月我相信会看到更多类似的多模型路由设计。那些还停留在全站只接一个模型的团队在成本结构上会被采用分层路由的团队拉开明显差距。规模化时代的竞争不再只是哪个模型的智商更高而是哪个团队能把模型的智商按成本分档地编排进业务流程里。6.2 几个可以立刻落地的小技巧写一个统一封装层内部支持按 model 字段自动路由 Sol/Luna业务代码里不用写死模型名后续调价也好改。把 Luna 的离线批处理任务安排在夜间跑配合 Batch API 折扣成本能进一步压低。为两个模型分别建立独立的 token 消耗监控和错误率看板出现质量下滑时快速定位是提示词问题还是模型问题。在 prompt 里明确标注任务的复杂度等级帮助路由层做分类也比纯靠 token 数量判断靠谱得多。我在实际迁移一个老项目时体验最深的一点是换模型不是改一行 model 参数就完事你得重新评估超时策略、重试策略、上下文构造方式和成本监控粒度。GPT-6 Sol/Luna 这代产品最大的意义是把模型也分性价比档位这件事摆到了所有开发者面前。以后选模型越来越像挑云服务器你既要看性能和价格的比值也要看它在你的架构里能不能跟其他组件协同。早一点适应这种思维早一点在规模化时代里占住位置。