九月模型发布潮：从刷榜到算账，单位任务成本成选型新标准

1. 九月这波密集发布到底在卷什么九月份这一个月我朋友圈里做模型推理和做应用落地的两拨人状态完全不一样。做推理的那帮人天天在群里发各种新模型的跑分截图做应用的那帮人则在算账——算同样的任务换一个新模型能省多少钱。这个割裂感本身就说明了一件事行业的评价标准正在从谁更强往谁更划算偏移。过去我们看一个模型发布第一反应是看榜单MMLU、GSM8K、HumanEval 刷到多少分比上一代涨了几个点。但九月份这一轮旗舰扎堆发布之后我发现身边真正在做产品的人问的问题变了。他们问的是这个模型的输入输出定价是多少缓存命中怎么算钱长上下文是不是要额外加价推理延迟在真实负载下是多少这些问题的共同点是它们都不是能力问题而是成本和工程可用性问题。这篇文章我想做的事情是把九月这一轮发布潮背后的逻辑拆开讲清楚。不是复述新闻而是从一个实际要用模型做东西的人的角度聊聊为什么旗舰扎堆、成本下探、评价标准换轨这三件事其实是同一件事的三个侧面。适合谁看如果你是把模型当 API 调、要控制预算、要选型做技术决策的人这篇应该对你有用。如果你只是看热闹也能从中理解为什么今年下半年开始便宜突然变成了一个技术指标。先说结论性的判断九月的密集发布不是巧合而是竞争进入下半场的信号。上半场比的是能不能做到下半场比的是能不能便宜地、稳定地、大规模地做到。旗舰模型依然在发但它们承担的角色变了——从唯一选择变成了能力天花板展示真正跑量的是那些价格被打下来的中端型号。2. 旗舰扎堆发布的背后逻辑2.1 为什么大家都挤在九月发如果你留意过发布节奏会发现模型发布有明显的窗口期效应。九月这个时间点很微妙暑期结束企业采购和技术选型进入下半年的决策周期同时距离年底的各种总结和预算规划还有一段时间。对厂商来说这个窗口发布既能赶上企业选型的节奏又能在年底前积累足够的实际使用数据。但更重要的原因是竞争节奏被拉快了。以前一个旗舰模型的生命周期可能有半年到一年现在可能只有三到四个月。你如果不在对手发布后的一两个月内跟上市场心智就被占了。所以九月的扎堆本质上是谁也不敢掉队的结果。我观察到的一个细节是这一轮发布里很多模型的定位非常接近能力差距在缩小这说明大家的技术路线在收敛剩下的差异主要在工程实现和成本控制上。从实际使用者的角度这种扎堆对我们是好事也是坏事。好事是选择多了价格被压下来了坏事是选型成本变高了你得花更多时间去对比和测试。我自己的做法是不再追每一个新发布而是建立一个自己的评测集用固定的任务去跑只看在我的场景下谁更划算。2.2 旗舰模型的角色转变这里要讲一个很多人没意识到的变化旗舰模型正在从生产工具变成能力标尺。什么意思以前我们做产品默认就是用最强的模型因为只有它能做对。但现在很多任务用中端模型就能做到 90% 的效果而成本只有旗舰的十分之一甚至更低。这时候旗舰模型的真正价值变成了两个一是给你一个上限参考让你知道这个任务理论上能做到多好二是处理那些真正困难的长尾 case。我举个具体的例子。做文档摘要这个任务旗舰模型能做到几乎完美的信息保留和语言流畅度但一个价格只有它五分之一的模型在 80% 的文档上表现已经足够好。剩下的 20% 难 case你可以用旗舰模型兜底。这种分层调用的策略是九月这一轮成本下探之后才真正变得划算的。所以旗舰扎堆发布表面上是能力竞赛实际上是厂商在争夺标尺的位置。谁的模型被当作 benchmark谁就掌握了话语权。但对使用者来说别被这个带偏你要关心的是你的任务需要什么级别的能力而不是谁的榜单分高。2.3 发布节奏加快带来的选型难题发布节奏加快直接后果就是选型从一次性决策变成了持续性决策。以前你选一个模型可能用一年不用换。现在可能三个月后就有更便宜、更好的选择你换不换我的经验是不要把模型选型做成硬编码。也就是说你的系统架构里模型调用应该是一个可替换的层而不是散落在各处的直接调用。这样当新模型出来、价格更优的时候你只需要改配置而不是改代码。这个原则在九月这种密集发布期尤其重要。具体怎么做至少要做到三点一是把模型调用封装成统一的接口二是把 prompt 和模型解耦不同模型对 prompt 的敏感度不一样但结构可以复用三是建立一套自动化的评测流程新模型进来能快速跑一遍你的核心任务看是否值得切换。这三点听起来简单但真正做起来很多团队是在第一次遇到想换模型但换不动的时候才后悔没早点做。3. 成本一路下探钱到底省在哪3.1 推理成本下降的几个真实来源成本下探不是厂商做慈善背后有实打实的技术原因。我梳理了一下主要有这么几个来源。第一是模型架构的效率优化。混合专家MoE架构的普及是一个关键因素。传统稠密模型每次推理都要激活全部参数而 MoE 每次只激活一部分专家计算量大幅下降。这意味着同样的硬件能服务更多请求单位成本自然就下来了。九月这一轮发布里不少模型都采用了类似的稀疏化思路。第二是推理工程和缓存的成熟。上下文缓存prompt caching这个东西对成本的影响被很多人低估了。如果你的应用有大量重复的前缀比如固定的系统提示词、few-shot 示例缓存命中之后这部分几乎不花钱。我实测过一个场景加上缓存之后同样的任务成本直接降了六成以上。这不是模型变便宜了而是你不再为重复计算付费。第三是硬件和批处理的优化。连续批处理continuous batching、投机解码speculative decoding这些技术让单卡吞吐量提升了好几倍。吞吐上去了摊到每个请求上的成本就下来了。这部分是厂商在后台做的你感知不到但它直接体现在定价上。3.2 定价结构里藏着的坑成本下探是好事但定价结构里有很多细节不注意的话你以为省了钱实际账单出来吓一跳。我把常见的几个坑列一下。计费维度常见做法容易踩的坑输入 token按量计费长上下文输入单价可能更高或超过阈值后阶梯涨价输出 token通常比输入贵输出不可控模型啰嗦一点成本就上去了缓存命中命中部分打折缓存有有效期过期后重新计费长上下文超过阈值加价很多模型 128K 以上是另一个价不是线性批量调用有折扣但延迟高不适合实时场景我踩过最典型的一个坑是输出 token 失控。有一次做结构化抽取模型偶尔会输出一大段解释性文字导致输出 token 暴涨。后来我在 prompt 里加了严格的格式约束并且设置了 max_tokens 上限成本才稳定下来。这个教训是输入成本你可控输出成本要靠约束。还有一个坑是缓存失效。缓存通常有几分钟到几小时的有效期如果你的请求间隔比较长缓存命中率会很低你以为省了钱其实没有。所以缓存策略要结合你的实际请求模式来设计不能想当然。3.3 怎么算清楚自己的真实成本很多人算成本只算 token 单价这是不够的。真实的成本应该包括模型调用费、重试和失败的成本、评测和调试的成本、以及工程维护的成本。我自己的算法是这样的先定义清楚一个标准任务单元比如处理一篇 2000 字的文档并输出 300 字摘要。然后统计这个单元的平均输入输出 token 数乘以单价得到单次成本。再乘以日均调用量得到日成本。最后加上一个 20% 到 30% 的冗余系数覆盖重试、异常和调试。这个算法看起来粗糙但比拍脑袋准得多。关键是它逼你去量化而不是凭感觉觉得这个模型便宜。我见过太多团队选型的时候只看单价上线之后发现实际成本远超预期就是因为没算清楚真实的任务单元和冗余。另外别忽略失败成本。一个模型如果稳定性差需要重试那重试的 token 也是钱。有时候一个单价稍贵但一次成功的模型总成本反而更低。这个账要算全。4. 评价标准换轨从刷榜到算账4.1 榜单为什么越来越不管用榜单的问题不是它不准而是它和真实场景脱节。榜单上的题目通常是标准化的、有明确答案的但真实业务里的任务往往是模糊的、多步骤的、需要判断的。一个模型在 MMLU 上高几分不代表它在你的客服场景里就更好用。我自己的体会是榜单能帮你做初筛但不能帮你做决策。初筛的意思是如果一个模型连基础榜单都排不上号那基本不用考虑。但进入候选名单之后决定用哪个的一定是你在自己场景下的实测结果。九月这一轮发布之后我注意到一个现象厂商越来越喜欢展示实际场景的案例而不是纯榜单分数。这说明厂商自己也意识到光刷榜已经打动不了真正的买家了。买家要的是在我的场景下能省多少钱、能提多少效。4.2 新的评价维度单位任务成本如果让我选一个最能代表换轨的指标我会选单位任务成本cost per task。这个指标把能力和价格揉在一起直接回答完成一件事要花多少钱。计算单位任务成本需要三个输入任务的成功率、单次调用的平均成本、以及重试次数。公式大概是单位任务成本 单次成本 × 平均尝试次数 / 成功率。这个公式的好处是它把便宜但经常失败和贵但一次成功放在同一个尺度上比较。我举个实际对比。假设模型 A 单次成本 0.01 元成功率 70%平均尝试 1.5 次模型 B 单次成本 0.03 元成功率 95%平均尝试 1.05 次。算下来 A 的单位任务成本是 0.01×1.5/0.7≈0.021 元B 是 0.03×1.05/0.95≈0.033 元。A 更便宜。但如果任务对准确性要求极高失败一次的代价很大那 B 可能更划算。所以这个指标要结合业务容忍度来看。4.3 延迟和稳定性被重新重视成本之外九月这一轮还有一个明显的变化延迟和稳定性重新回到了评价的核心位置。前两年大家比的是能力延迟高一点、偶尔超时都能忍。但当模型真正进入生产环境、面对真实用户的时候延迟和稳定性就成了硬指标。用户不会因为你模型聪明就容忍三秒的等待。我做过一个测试同样的任务延迟从 2 秒降到 800 毫秒用户的完成率明显提升。稳定性也是。一个模型如果高峰期经常超时或者返回错误那它的实际可用性就大打折扣。我现在选型会专门在高峰时段做压力测试看 P99 延迟和错误率。这两个指标比平均延迟更能反映真实体验。所以新的评价标准我总结成一句话在可接受的延迟和稳定性下用最低的单位任务成本达到业务要求的成功率。这句话里没有最强因为最强不是目标够用且划算才是。5. 实操怎么在这波发布潮里做选型5.1 建立自己的最小评测集选型的第一步不是看别人的评测而是建自己的评测集。这个评测集不需要很大30 到 50 个样本就够但必须覆盖你的核心场景和边界情况。怎么建从你的真实业务数据里采样。比如你做的是合同审查那就找 30 份真实合同涵盖常见的条款类型和容易出错的边界情况。每份合同标注好期望的输出。这个评测集是你的金标准所有候选模型都跑一遍看谁的表现最接近期望。我自己的评测集里会特意放一些陷阱样本比如格式不规范、信息缺失、有歧义的输入。这些样本最能区分模型的实际鲁棒性。榜单上分高的模型在这些陷阱样本上不一定表现好。评测集的维护也很重要。业务在变评测集也要更新。我一般每季度review一次把过时的样本换掉补充新的边界情况。5.2 分层调用策略的落地前面提到分层调用这里讲具体怎么落地。核心思路是用便宜的模型处理大部分简单任务用贵的模型兜底困难任务。实现上有两种方式。一种是基于规则的根据输入的长度、类型、复杂度直接路由到不同的模型。比如短文本用便宜模型长文档用贵模型。这种方式简单但规则需要调优。另一种是基于置信度的先用便宜模型处理如果它的输出置信度低比如格式不符合要求、或者自评分数低再转给贵模型重试。这种方式更智能但需要便宜模型能输出置信度信号。我实测下来基于置信度的方式效果更好但实现复杂度高一些。一个折中的做法是先用便宜模型跑用一个轻量的校验器可以是规则也可以是另一个小模型检查输出质量不合格的再升级。这样既控制了成本又保证了质量。5.3 成本监控和告警怎么做选型不是一锤子买卖上线之后要持续监控成本。我的做法是按天和按任务类型两个维度监控。按天监控是为了发现异常。如果某天成本突然翻倍肯定有问题可能是某个任务的重试率上升或者某个模型的输出变啰嗦了。按任务类型监控是为了优化。你会发现某些任务类型的成本特别高这些就是优化的重点。告警阈值怎么设我一般设两个一个是日成本的绝对值上限超过就告警另一个是单位任务成本的环比涨幅比如比上周涨了 30% 就告警。前者防突发后者防慢性恶化。监控数据要能下钻。光看总成本没用要能定位到具体是哪个任务、哪个模型、哪个环节花的钱。这个需要你在调用的时候打上足够的标签。前期多花点功夫打标签后期排查问题会轻松很多。6. 常见问题与避坑经验6.1 换模型之后效果变差的排查思路换模型之后效果变差是最常见的问题。排查的时候我一般按这个顺序来。先看prompt 兼容性。不同模型对 prompt 的敏感度不一样同一个 prompt 在 A 模型上效果好在 B 模型上可能就不行。这时候不要急着否定 B 模型先针对它调整 prompt。我遇到过好几次只是把指令的位置换了一下效果就回来了。再看输出格式。有些模型喜欢加额外的解释有些模型对 JSON 格式的遵循度不高。如果你的下游依赖固定格式这些差异会导致解析失败。解决办法是在 prompt 里加强格式约束并且在解析层做容错。最后看任务本身的难度分布。可能新模型在简单任务上更好但在你的难 case 上更差。这时候要分开统计看是整体变差还是局部变差。如果是局部可以考虑混合调用。6.2 缓存命中率低的几个原因缓存命中率低钱就省不下来。常见原因有这么几个。一是前缀不稳定。如果你的系统提示词里带了时间戳、用户 ID 这类每次都变的内容缓存永远命中不了。解决办法是把变化的部分放到后面固定的部分放前面。二是请求间隔太长。缓存有有效期如果你的请求是分散的缓存早就过期了。这种情况要么接受低命中率要么调整请求的批处理方式。三是缓存粒度不匹配。有些缓存是按完整前缀匹配的你的前缀只要有一点点不同就不命中。这时候要检查你的前缀是不是真的完全一致。我踩过的一个坑是系统提示词里有个空格不一致导致缓存一直不命中排查了半天才发现。所以缓存相关的配置一定要仔细核对。6.3 长上下文到底值不值得用长上下文是个双刃剑。好处是你可以把大量信息一次性喂给模型不用做复杂的检索。坏处是成本高、延迟大而且模型在超长上下文里的注意力会分散效果不一定好。我的经验是长上下文适合信息密集但结构清晰的任务比如分析一份完整的合同、总结一份长报告。对于信息稀疏的任务比如从一大堆文档里找几个相关片段用检索加短上下文反而更好既便宜又准。用长上下文的时候要注意把最重要的信息放在开头或结尾因为模型对中间部分的注意力相对弱。这个中间遗忘的现象在很多模型上都存在实测下来把关键信息前置效果会好不少。6.4 常见问题速查表问题现象可能原因排查方向成本突然上涨输出变长、重试增多、缓存失效看输出 token 分布、重试率、缓存命中率效果变差prompt 不兼容、格式问题、难 case 变多分任务类型统计、检查 prompt、看边界样本延迟变高上下文变长、并发增加、模型负载高看 P99 延迟、输入长度分布、高峰时段表现缓存不命中前缀不稳定、间隔太长、粒度不匹配检查前缀一致性、请求模式、缓存配置输出格式错乱模型遵循度低、prompt 约束弱加强格式指令、加解析容错、换模型测试7. 我对这波换轨的个人判断做了几年模型落地我最大的感受是行业终于从炫技阶段进入了过日子阶段。前两年大家比谁的模型更聪明现在大家比谁能让模型更便宜、更稳地干活。这个转变对做应用的人来说是好事因为我们的价值不再被模型能力卡脖子而是取决于我们怎么把模型用好、用省。九月这一轮发布表面上是旗舰扎堆实际上是竞争焦点的转移。能力还在涨但涨得没那么快了边际收益在递减。而成本还在降降得很快边际收益在递增。所以聪明的做法是把精力从追最强转移到找最划算上。我自己的策略是保持一个能力上限的模型作为兜底主力用性价比最高的中端模型同时持续监控成本和效果随时准备切换。这个策略不激进但稳。在这个快速变化的阶段稳比激进更重要。最后分享一个我一直在用的小技巧每次新模型发布不要急着全量切换先拿 10% 的流量做灰度。跑一周看成本和效果的真实数据再决定要不要扩大。这样既不会错过好模型也不会因为一次错误的切换影响业务。灰度这个习惯帮我避开了好几次坑。