今天早上看到这条消息的时候我正坐在工位上冲咖啡。价格暴降90%多项测试超Luna-6屏幕上的字读了两遍第一反应不是兴奋而是强迫自己冷静便宜90%的模型到底是厂商真的把成本打下来了还是把某个阉割版拿出来收割场景把这条消息从头到尾拆完之后我决定把其中的账、坑和选型思路完整写一遍。这篇文章不是发布会复述而是从一个做AI应用落地的人的角度聊聊这个最便宜模型到底应该怎么评估、怎么用。1. 先说结论这则消息最值得关注的不是又便宜了1.1 卖点拆解三个关键词里哪个才是真正的新信息标题里藏着三个关键词价格暴降90%、多项测试超Luna-6、最便宜模型。如果光看前两个这其实是AI大模型行业过去一年里反复上演的戏码新版本发布、价格下调、跑分上涨。真正值得琢磨的是第三个——最便宜这三个字背后说明这家实验室开始改变自己的产品策略了。过去这类厂商的定价逻辑一直是一分性能一分货旗舰模型贵得理直气壮便宜模型要么能力拉胯要么只是老模型的换皮。而这次最便宜模型能在多项测试里超过一款此前公认的旗舰模型Luna-6虽然多项这个词很有弹性但多少说明低价模型的能力下限已经被抬高了。这不是一次简单的降价促销而是产品线战略层面的信号。1.2 为什么厂商选择在这个时间节点发廉价版从行业背景来看大模型API的价格战早就打了好几轮每百万token的单价从几十美元一路压到几美元甚至更低。但在这种背景下依然敢喊出暴降90%说明这家实验室不是被动跟价而是主动把低价模型推到台前。它想抢的正是那些对成本极度敏感、手里捏着大量真实流量的开发者。这类开发者的特点很鲜明他们不是在做Demo而是在跑真实业务比如客服机器人、内容审核、信息抽取、知识库问答。这类场景对单次请求的质量要求没那么苛刻但对每月账单别爆掉的要求极高。厂商在这个时间点推出最便宜模型本质上是要在开发者的成本预算里硬生生切出一块份额——先把调用量占住生态就赢了。1.3 一个容易被忽略的细节廉价版和旗舰版的关系很多人看到最便宜模型就容易脑补成旗舰模型打了个骨折价实际上两者在产品线上通常是并行的关系。廉价版大概率是单独训练的、参数量更小的模型或者是从大模型蒸馏出来的压缩版本。它跟旗舰模型的关系更像经济型轿车和豪华SUV的差别不是同一辆车降价而是两条不同的产品线。这个判断在API的模型列表上通常一眼就能看出来廉价款和旗舰款的结构、上下文窗口、速率限制往往不一样。如果你带着旗舰模型的预期去接廉价版上线之后大概率会撞到各种隐性差异这部分我后面详细展开。2. 价格暴降90%的账这样算从token单价到月度账单2.1 单价对比把降90%还原成具体数字暴降90%在新闻标题里只是一个形容词落到API账单上得先换算成每百万token的单价。这里我按这家实验室的惯例做一个估算如果此前旗舰级的输入单价是每百万token 30美元、输出单价是90美元那么暴降90%之后的廉价款大致就是输入3美元、输出9美元上下。计费项旗舰级别虚构参考价最便宜模型虚构参考价降幅每百万输入token约30美元约3美元-90%每百万输出token约90美元约9美元-90%上下文窗口通常更大通常更小看具体配置降90%这个数字本身没有太多花头关键看分母是什么。对比基准是自家旗舰模型还是上一代廉价模型还是市面上别的同类产品结论完全不同。所以看到夸张的百分比先问一句跟谁比再决定要不要兴奋。2.2 同样的应用月度成本差多少一个模拟算例空谈单价没有体感我拿一个具体的虚构应用来算账。假设你做一个知识库问答机器人平均每天5万次请求每次请求的输入约3000 token输出约800 token。这个体量不算大但也已经远超人肉测试的阶段是可以用来估成本的中等偏上量级。先算每天的token消耗输入是5万乘以3000等于1.5亿token输出是5万乘以800等于4000万token。一个月按30天算输入就是45亿token也就是4500百万token输出是12亿token也就是1200百万token。用旗舰级别单价算月成本是4500乘30再加上1200乘90等于13.5万美元加10.8万美元合计24.3万美元。同样用量切到最便宜模型月成本变成4500乘3加上1200乘9合计2.43万美元。一个月的差额接近22万美元一年下来就是两百多万美元的差距。二十多万美元的月费对小团队来说是天文数字但对一个已经有大客户的中型AI应用来说就是能不能盈利的分界线。价格暴降90%在这个算例里非常直观不是省出一顿饭钱是直接把一个做不起的项目变成可以认真考虑的项目。2.3 定价之外的计价细节上下文、缓存与批量折扣只看单价还不够API账单里真正的坑通常藏在计价细节里。三个最容易被忽略的项是上下文长度、缓存命中和批量请求。上下文长度决定了单次请求最多能塞多少内容。廉价款模型如果上下文窗口比旗舰款小一半那些需要塞长文档、多轮聊天记录的应用就得自己截断。截断了回答质量就可能下降不截断请求报错或者被静默丢弃。这部分的隐性成本很难在单价里直接看到但会在上线后的报错率里暴露。缓存命中和批量折扣则是实实在在的省钱项。很多API对重复的输入片段比如系统提示词、固定的背景资料提供输入缓存缓存命中的价格可能是正常输入价的一折到两折。批量API则适合那些不追求实时响应的离线任务比如夜间批处理、定时生成报告单价能再便宜一半。这些折扣叠在暴降90%的标价之上实际账单可能比标价还低。2.4 我的看法90%降价的合理来源这90%到底怎么省出来的我倾向于认为有三个来源共同作用。第一是模型变小了。参数规模小单次推理的算力消耗自然低这是最硬的成本下降来源。第二是架构和推理优化包括量化、蒸馏、批处理调度这些工程手段把单位token的算力成本进一步压缩。第三是服务层级的差异廉价版可能对应更低的SLA保障、更低的速率上限说白了就是把包月套餐换成了按量付费把闲置算力打包销售。前两条是真实的技术进步第三条则是商业定价的权衡。理解了这三个来源你对价格暴降90%的预期管理就能到位——你真的买到的是一个能力够用、资源消耗更小的模型而不是一个价格减半的旗舰体验。3. 多项测试超越Luna-6的含金量要拆开每一项看3.1 榜单上的超越是哪些测试典型的自然语言理解类多项测试超过Luna-6这句话在宣传里很提气但作为技术决策者必须追问一句是哪几项根据这类发布稿的惯例最容易刷榜的是综合语言理解、常识问答、多轮对话、文本分类、写作润色这几类。这些测试的共同点是答案相对确定、评分标准清晰、模型只要学到大量语料模式就能拿到高分。在这些项目上超越上一代旗舰模型不奇怪。近一年来各家的廉价模型在纯语言任务上的表现突飞猛进因为这类任务本就吃数据和参数量而数据采集和蒸馏技术已经非常成熟。一个训练充分的小模型在这些项目上打赢一个两年前的旗舰大模型属于正常的技术迭代甚至可以说是必然。3.2 那些不在榜单里的项目强推理、代码、数学但多项测试超越和全面超越之间的差距往往就藏在没上榜的项目里。最典型的三类短板是复杂多步推理、代码生成与调试、数学证明级的长链路逻辑。这类任务要求模型不只是接下一句最合理的文字而是要在内部维护一个状态、沿着一条路径推理多步、最后得出可验证的结论。我用一个例子说明。给Luna-6这个级别的模型一个任务某个订单已经发货但用户说要改地址系统里同时存在旧地址和新地址请判断应该通知物流公司更新哪个地址并说明如果不更新会有什么后果。旗舰模型一般能拆解出已发货改地址系统记录三个事实之间的关系给出合理建议。而廉价款模型很可能只看到新地址三个字直接输出应该更新为新地址完全忽略物流状态这个关键变量。类似的差异在代码任务上更明显写一个独立的小函数廉价模型通常没问题但要修改一个跨了五个文件的调用链、理解多个函数之间共享的副作用廉价模型就容易漏改或者改出编译错误。这类差距不会出现在发布会PPT上但恰恰是真实开发里最让人头疼的部分。3.3 测试分数与生产环境的距离Benchmark分数和生产环境表现之间的距离比很多人以为的要大得多。原因有三个。第一是数据污染。公开测试集如果常年挂在网上模型在预训练阶段可能已经见过题目分数自然虚高。第二是题目风格固定。测试集里的提问方式很规整真实用户的提问却充满口语、错别字、上下文缺失和反讽廉价款模型在规整题目上拿高分不代表它在混乱输入上同样稳。第三是评估指标单一。自动评测通常只看答案是否匹配真实业务却还要看格式是否符合要求、是否拒绝回答不该答的问题、是否在长时间对话中保持角色一致。所以我的建议是任何benchmark分数都只能当作出初步筛选的参考真正的验收一定要用自己的业务数据来跑一遍。具体怎么做放在第三小节里说。3.4 一个值得做的实验带上自己的prompt去测往自己的场景里测不用等厂商的完整评测报告完全可以自己搭一个轻量评估。我在模拟项目X里用的方法是挑5类核心任务分类、抽取、问答、重写、工具调用每类准备10个代表性输入然后人工给模型的输出打分。评分维度不需要太复杂就三条任务达成度有没有正确完成任务给的指令、格式合规度输出能不能直接被下游解析、以及稳定性同一个问题问两次答案方向是否一致。如果你自己的测试集上新模型的表现和旗舰模型差距在可接受范围内那就可以进入灰度测试阶段如果差距明显哪怕宣传稿里说超越Luna-6你也应该把这张榜单当作无效信息。这个测试的成本不高但能省下后面几周踩坑的时间。我始终认为不要拿别人的名校来给自己的业务背书模型好不好用只有放到自己的数据流里才知道。4. 便宜模型在生产环境里的真实价值我的选型经验4.1 最适合它的场景高重复、模板化、低风险结合我自己最近几个月在几个不同项目里的实测判断最便宜模型真正适合的是那些高重复、模板化、低风险的任务。这类任务的特征是输入结构相对稳定、输出格式高度统一、单次错误不会造成严重后果。典型的例子包括客服工单自动分类、邮件内容摘要、用户意图识别、评论情感正负判断、以及有检索材料兜底的RAG问答。尤其是最后一种系统把相关的知识片段检索出来塞进prompt模型要做的事情其实是从给定的材料里找答案而不是自己凭空生成事实。这种场景里廉价款和旗舰款的差距会被明显缩小因为最难的部分事实正确性已经由检索环节兜住了模型只需要做阅读理解和改写。在这些场景里用廉价模型省下来的钱是真金白银的利润而且用户感知不到体验下降。4.2 不太适合它的场景复杂推理、多轮长对话、代码生成反过来有几种场景我会建议你坚持用旗舰模型不要被低价打动。第一种是复杂推理。比如金融风控规则解释、法律条款对比这类任务要求模型在多个条件之间做逻辑推断一步出错全盘皆输。廉价款模型在这种任务上的表现通常不稳定你很难通过加prompt来修补根本性的推理能力短板。第二种是超长多轮对话。假设客服机器人需要记住用户前面二十轮里提到的所有约束条件廉价款模型在长上下文里的注意力分配容易失衡经常出现忘记早前细节的问题。这种场景不是靠变便宜就能解决的你得接受降级体验。第三种是深度代码生成与重构。不是指写个排序函数而是理解整个工程里多个模块之间的依赖关系并修改某段逻辑。这种任务牵扯到长距离依赖小模型的能力边界很明显。我见过一个团队为了省钱把代码辅助全部切成廉价模型结果一周后开发效率肉眼可见下降最后又改回来了。4.3 更聪明的用法模型路由而不是二选一所以你会发现廉价模型和旗舰模型根本不是二选一的替代关系而是可以搭配使用的两条管线。最实际的方案是做一个模型路由层根据请求的特征决定这一次调谁。我在模拟项目X里就是这样实现的。大致的路由规则是先判断任务类型如果是分类、抽取、摘要这类模板化任务直接走廉价模型如果检测到请求里包含复杂推理、代码生成或长上下文再升级到旗舰模型。规则可以用很简单的逻辑实现甚至一段伪代码就够了def route_request(task_type, input_length, needs_reasoning): if task_type in [classification, extraction, summarization]: return cheap_model if needs_reasoning or input_length 8000: return flagship_model return cheap_model这套策略的核心思路是把预算花在最需要性能的地方让廉价模型去承接那80%的简单请求。实测下来整体账单能压掉一半以上而用户能感知到的质量几乎没有变化。路由规则可以做得很粗只要分类边界清晰收益就能立竿见影。4.4 数据合规与条款低价常常绑定更多限制接任何一家API之前条款是我必看的东西用廉价模型尤其要看。低价往往绑定更多限制最常见的约束有三类。一类是数据留存期限。廉价款服务可能要求你的输入输出数据留存更长时间用于模型改进或者安全审查。如果你的业务涉及用户隐私这个点必须提前跟法务确认。第二类是训练条款有些低价服务明确规定你的数据可能被用作训练语料对很多公司来说这直接触碰红线。第三类是SLA等级廉价款通常不承诺可用性或者承诺的恢复时间更长。线下线上业务最怕的就是API挂掉如果你对可用性有硬性要求这部分条款要逐字看清楚。5. 上线前必须排查的隐性成本限流、蒸馏与长尾输出5.1 限流与并发便宜模型经常伴随更低速率上限价格暴降90%的同时服务等级大概率也会降。最直接的表现就是速率限制Rate Limit。我去翻了这类发布常见的技术文档如果旗舰模型支持每分钟调用数千次廉价款可能只有它的几分之一甚至更低。对刚上线的小项目来说这无所谓但一旦流量冲上来你会发现请求开始排队、超时、被限流而你自己根本不知道是从哪一刻起触碰了上限。所以接廉价款之前压测是必须的。不用多复杂用脚本模拟你预期的峰值流量持续跑十分钟观察响应时间和错误率曲线。如果错误率在预期流量的一半就开始抬头你就要么做请求队列和重试要么做好流量增长后升级套餐的预算。5.2 模型迭代与稳定性蒸馏模型的水土不服廉价模型如果是从大模型蒸馏出来的通常会在一个很尴尬的地方暴露问题——对本地化、小众化的表达水土不服。我举一个虚构的例子某开发者A在自己的业务里接入廉价款模型做合同条款抽取发现它在大路货的合同条款上表现没问题但只要遇到自己业务特有的术语组合比如对赌回购触发条件的宽限期计算方式模型就开始犯迷糊要么漏掉关键条款要么抽取出完全不存在的字段。换旗舰模型同样的prompt基本不会出错。这种问题不是偶发质量波动而是蒸馏模型的通病它在蒸馏过程中学到的是母模型的大路货知识那些母模型只在小众语料里见过的边界情形被蒸馏时丢失了。这让廉价款模型在通用场景里很能打在垂直领域里可能翻车。5.3 长尾输出的风险看似便宜实际需要反复重试还有一个容易被忽视的成本重试成本。如果廉价款模型的输出不合格率是5%而旗舰款是1%表面上单价便宜90%实际算上重试和人工检查成本总成本可能并没有省多少。我习惯用有效完成率来做决策指标而不是看单价。具体算法是拿一批真实业务请求分别用两个模型跑统计不需要人工干预直接可用的输出比例。假设廉价模型输出单价是$3但只有80%的输出可直接使用那么实际可用输出的单次成本是$3除以0.8等于$3.75旗舰模型单价是$30但95%可用实际成本是$30除以0.95等于$31.58。差依然很大但如果你的业务对输出准确率要求接近100%边际的20%不合格输出带来的返工成本会迅速吃掉低价红利。这个时候你要判断的就不是单价贵不贵而是返工流程贵不贵。5.4 建立一个简单的质量看板基于上面这些考量我把自己的做法分享出来不管接哪家的廉价模型上线前一定建立一个最小的质量看板。指标不用多四五个足够请求成功率、P95响应时间、输出长度分布、人工干预率、以及按小时粒度的token消耗。前三个指标接一个监控面板就能自动跑后两个可能需要你在业务代码里埋点。这组数据跑满一周你就能看清楚这个模型在你的业务里到底划不划算。比任何宣传稿都准。6. 关于这个最便宜模型我最后的几条建议把前面这些拆完我最后想说的其实就四句话每一条都是我自己踩过坑之后形成的习惯。第一先明确自己的任务类型再谈价格。如果你做的是高重复、模板化、低风险的业务这个最便宜模型值得马上申请试用如果你的核心业务依赖复杂推理和长链路规划省钱这件事要往后放。第二不要用benchmark替代验收。厂商说多项测试超越Luna-6也好说接近旗舰水平也好我只信自己业务数据池里的测试结果。准备20个真实输入跑一遍比读十篇评测文章都有用。第三模型路由是当前性价比最高的降本方案。不必纠结于全换还是不换折中方案往往才是最优解。把简单流量切给廉价款保留旗舰款作为兜底成本和质量都能兼顾。第四条款比价格更需要较真。数据留存、训练使用权、SLA、限流每一项都在决定这个模型能不能长期稳定地待在你的技术栈里。被便宜价格冲昏头脑、忽略了服务条款的团队我见过不止一个。最后再分享一个实操小技巧接新模型的第一周不要让100%流量都走新模型控制在10%到20%的灰度比例。灰度期间把输出存下来跟老模型的输出做并排对比。这么做的好处是你可以在真实流量里发现那些测试集里发现不了的问题——某个特定用户群体的话术习惯、某种极端输入格式、某个时间段的并发峰值。一周之后你会比任何benchmark都更清楚这个大模型到底适不适合你的业务。这次价格暴降90%的消息我的总体判断是偏正面的。价格战打到这个深度吃亏的绝对不是开发者。真正需要留意的是怎么在省钱的诱惑下不交出质量的口子——这件事得你自己来守。