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 的"能力下沉"不是简单地把模型做小，而是保留了完整的大模型规模，靠 MoE（Mixture 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 上，发现参数不能照搬，否则体验会差很多。下面是我实测后调出来的基准配置，先给个表格：

还有一个必须提醒的坑：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 的响应速度对流式输出很友好，首 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 这代产品最大的意义，是把"模型也分性价比档位"这件事摆到了所有开发者面前。以后选模型越来越像挑云服务器，你既要看性能和价格的比值，也要看它在你的架构里能不能跟其他组件协同。早一点适应这种思维，早一点在规模化时代里占住位置。