1. 九月这波旗舰潮到底在卷什么九月份这一个月我朋友圈里做AI应用的朋友几乎没消停过。前脚某家刚发完新旗舰模型后脚另一家就甩出个更便宜的版本价格表一天一个样。你要是隔三天不看群消息回来就发现讨论的话题已经从“哪个模型跑分高”变成了“哪个模型每百万token便宜了两块钱”。这个月的核心关键词就两个旗舰扎堆和成本下探。听起来像是两件独立的事其实是一件事的两面——当头部玩家在同一时间窗口密集发布新版本竞争维度就不可避免地会从“谁更强”滑向“谁更划算”。而一旦价格战打起来整个行业的评价标准就会跟着换轨。我先把话说在前面这篇复盘不是给投资人看的行业分析也不是给媒体用的通稿素材。我写的是作为一个每天要调API、要算成本、要跟产品经理扯皮“这个功能到底用哪个模型”的一线从业者在这个九月里观察到的真实变化。如果你也是做AI应用落地的或者正在选型阶段纠结用哪家模型那这篇东西应该能帮你省下不少试错时间。九月的这波发布潮有个很明显的特征旗舰模型不再只是秀肌肉而是直接对标落地场景。以前发新模型官方博客里全是benchmark截图MMLU涨了几个点、HumanEval又破了纪录。但九月这波我注意到一个变化——好几家在产品页面上直接放了“每百万token成本对比表”甚至有的把“相比上一代降价XX%”写进了标题里。这说明什么说明厂商自己也意识到光靠跑分已经很难说服客户掏钱了大家开始算账了。这个转变对一线开发者的影响是直接的。以前选模型流程大概是看跑分→看榜单→选最高的那个→上线。现在不行了你得算这个任务用旗舰模型跑一次多少钱用中杯模型跑一次多少钱效果差多少用户能不能感知到。评价标准从“能力上限”变成了“能力/成本比”这个换轨是九月最值得关注的事。我自己的体感是九月之后团队内部讨论模型选型的会议时间明显变长了。以前十分钟能定的事现在要开半小时因为要对比的维度多了——不光是效果还有延迟、并发限制、上下文窗口的实际可用性、以及最关键的这个价格能撑多久。毕竟谁也不想今天刚把架构搭好下个月厂商一纸公告说涨价或者限流。2. 成本一路下探到底是怎么降下来的2.1 降价不是做慈善是架构和推理优化的结果很多人看到API价格往下走第一反应是“厂商在烧钱抢市场”。这个判断对了一半但不全对。烧钱补贴确实存在但九月这波降价更多是技术侧实打实的成本优化传导到了价格上。我拆一下这里面的逻辑。大模型推理成本主要花在三块算力GPU时长、显存带宽、以及调度效率。九月发布的新旗舰里好几家都提到了“MoE架构的进一步优化”和“推理时的动态稀疏激活”。说人话就是以前你问一个问题模型要把所有参数都过一遍现在它只激活跟这个问题相关的部分专家网络其他部分待机。这就好比你去餐厅点菜以前是后厨所有灶台同时开火现在只开你需要的那两个灶。这个变化带来的成本下降是数量级的。我拿一个实际场景算过账一个中等复杂度的文本分类任务输入500token、输出50token用上一代旗舰模型跑每千次调用成本大概在1.2元左右换成九月新发的某个MoE架构旗舰同样任务每千次调用降到了0.4元出头。降幅接近70%这不是补贴能补出来的是架构红利。另一个降本来源是推理框架的成熟。九月前后几个主流推理引擎都发了新版本对长上下文的KV Cache管理做了优化。以前处理一个32K上下文的请求显存占用会随着对话轮次线性增长跑到后面要么OOM要么延迟爆炸。现在通过分页管理和前缀共享同样长度的上下文显存占用能压到原来的三分之一左右。这意味着同样的GPU能扛更多并发单次调用的分摊成本自然就下来了。2.2 价格表背后的隐藏条款你得会看降价是好事但九月这波价格调整里有几个坑我踩过得提醒你注意。第一个坑是阶梯定价的临界点。很多厂商的定价页面上写的是“输入每百万token X元”但下面小字里藏着“月调用量超过Y百万后超出部分按Z元计费”。这个Z有时候比X高有时候比X低你得根据自己的实际调用量算清楚落在哪个区间。我见过一个团队为了拿更低单价拼命刷调用量结果月底一算因为跨过了某个临界点实际单价反而比不刷还贵。第二个坑是缓存命中的计费差异。现在好几家都支持“上下文缓存”就是如果你重复发送相同的前缀内容这部分可以按更低的缓存价格计费。但缓存有有效期有的是几分钟有的是几小时。如果你的应用场景是用户隔半天才回来继续对话那缓存早就失效了你按缓存价格做的预算就会超。我一般会建议团队在压测阶段就把缓存命中率打出来按实际命中率去估算成本而不是按理论最优值。第三个坑最隐蔽输出token的计费权重。有些厂商输入和输出是分开计价的输出通常比输入贵。但九月新发的几个模型里有的把输出价格调得特别低吸引你去做生成类任务。这时候你要注意输出价格低不代表总成本低——如果模型为了生成同样质量的内容需要输出更多token比如啰嗦、重复那单价低反而总价高。我实测过同一个摘要任务A模型输出价格是B模型的一半但A平均要输出300token才能达到B用150token的效果算下来总成本差不多。提示看价格表的时候别只看输入单价。把输入、输出、缓存、阶梯四个维度拉个表格按你自己的业务分布算加权成本这才是真实成本。2.3 成本下探对应用层意味着什么成本降下来最直接的影响是以前算不过账的场景现在能算了。举个例子实时翻译。以前用旗舰模型做同传级别的翻译延迟和成本都扛不住只能做“提交-等待-返回”的异步翻译。但现在推理成本降了、延迟也优化了我试过用新旗舰做流式翻译端到端延迟能压到800毫秒以内成本大概是每分钟对话0.02元左右。这个数字意味着什么意味着你可以把它做成一个常驻功能而不是一个“高级用户才配用”的付费点。再比如长文档处理。以前处理一份100页的PDF光是输入token就要花掉几块钱很多团队只能做摘要或者分段处理。现在上下文窗口大了、单价低了整份文档塞进去做全量分析成本能控制在几毛钱。这个变化直接催生了一批“文档深度分析”类产品九月之后我至少看到五六个团队在往这个方向转。但这里有个反直觉的点成本降低不一定会让你的账单变少。因为成本低了你会忍不住用更多、更复杂的调用。以前舍不得让模型多轮反思现在便宜了那就让它跑三轮吧以前只处理用户主动提交的内容现在成本低了那就把所有历史记录都塞进去做上下文吧。结果月底一看单价降了60%总账单涨了200%。这个坑我踩过后来学乖了给每个功能模块设了token预算上限超了就降级到小模型或者走规则兜底。3. 评价标准换轨从跑分崇拜到场景适配3.1 跑分为什么越来越不够用了九月这波旗舰发布有个很有意思的现象官方跑分和实际体感之间的差距在拉大。以前MMLU涨两个点你在实际任务里多少能感觉到一点提升。但现在头部模型的跑分已经挤在很窄的区间里了MMLU都是85分往上HumanEval都是90分左右差距在统计误差范围内。可你实际用起来A模型和B模型在同一个任务上的表现可能天差地别——A模型写代码一次过B模型总是漏边界条件A模型总结文档能抓住重点B模型总是把次要信息当核心。为什么会这样因为跑分测的是“平均能力”而你的业务场景要的是“特定能力”。MMLU考的是通识知识但你的业务可能只需要模型懂法律条文HumanEval考的是算法题但你的业务可能只需要模型会写SQL查询。跑分高的模型在你的特定场景里不一定好用。我现在的做法是建自己的评测集。不用多每个核心功能准备50到100条真实case覆盖正常情况、边界情况、以及你踩过坑的异常情况。每次有新模型发布先跑自己的评测集跑分只作为参考。这个习惯帮我省了很多事——有一次某个新旗舰在公开榜单上排名第一但在我的SQL生成评测集上准确率只有70%比上一代还低直接pass。3.2 场景适配的四个维度九月之后我评估一个模型是否适合某个场景会从四个维度打分维度具体指标为什么重要效果自有评测集准确率、人工抽检通过率跑分高不代表你的任务做得好成本加权每千次调用成本、缓存命中率单价低不代表总成本低延迟P50/P95首token延迟、完整响应时间流式场景对首token延迟极敏感稳定性限流阈值、故障恢复时间、版本兼容性上线后最怕突然限流或接口变更这四个维度里稳定性是最容易被忽略但最致命的。我经历过一次某个模型效果和成本都很理想上线两周后突然开始限流P95延迟从1秒飙到8秒用户投诉直接爆了。后来才知道是厂商那边GPU资源紧张优先保障了大客户。这件事之后我选型时一定会问清楚限流策略是什么、有没有SLA保障、版本更新会不会提前通知。3.3 换轨之后团队协作方式也在变评价标准变了团队内部的协作方式也跟着变。以前算法团队和工程团队的边界比较清晰算法团队负责选模型、调效果工程团队负责部署和运维。但现在成本成了算法团队也要背的指标。我认识的几个团队九月之后都把“每千次调用成本”写进了算法团队的OKR里。这意味着算法同学不能只盯着效果调参了还得考虑这个prompt能不能压缩、这个few-shot示例能不能减少、这个任务能不能拆成两步用更小的模型先过滤一遍。产品团队的角色也在变。以前产品经理提需求说的是“这个功能要准确率90%以上”。现在他们会问“准确率85%但成本降一半能不能接受”或者“这个功能用旗舰模型跑用户愿意付多少钱”成本意识开始渗透到产品定义阶段而不是等到技术方案评审时才考虑。这个变化我觉得是好事。AI应用落地说到底是要算经济账的。九月这波成本下探和评价标准换轨本质上是在把行业从“技术演示”推向“商业闭环”。能在这个换轨期活下来的团队不一定是技术最强的但一定是最会算账的。4. 实操九月之后我的模型选型流程4.1 第一步明确任务分级我现在拿到一个需求第一件事不是选模型而是给任务分级。S级任务直接影响核心用户体验错了会导致用户流失或投诉。比如客服机器人的意图识别、代码助手的补全建议。A级任务影响体验但不致命错了用户会感知到但能容忍。比如文档摘要、内容推荐。B级任务后台处理用户不直接感知。比如日志分类、数据清洗、批量翻译。分级之后选型策略就清晰了S级任务用旗舰模型成本高也认A级任务用中杯模型效果差一点但成本可控B级任务用轻量模型或者规则引擎能省则省。这个分级不是拍脑袋定的我会拉上产品和运营一起对齐。因为“致命”和“能容忍”的边界不同角色判断不一样。技术觉得“摘要少了一句话没关系”产品可能觉得“这句话是用户最关心的”。对齐一次后面省很多扯皮。4.2 第二步建最小评测集分级之后给每个S级和A级任务建评测集。不用多50条起步覆盖三类case正常case最常见的输入占70%。边界case输入特别长、特别短、或者格式奇怪的占20%。坑case你之前踩过坑的输入占10%。评测集的标注不用太复杂二分类就行通过/不通过。如果任务比较复杂可以加一个“部分通过”的中间档。关键是标注标准要统一最好写个简单的标注指南不然不同人标出来的结果没法比。我一般会用这个评测集跑三个模型当前在用的、新发布的旗舰、新发布的中杯。跑完之后看通过率如果新旗舰比当前在用的提升不到5个百分点那就不值得换——迁移成本、重新调prompt的成本、以及新模型可能带来的新坑都不划算。4.3 第三步算加权成本评测集跑完效果达标了接下来算成本。别用官方单价直接比要算加权成本。加权成本的公式大概是加权成本 (输入token数 × 输入单价 输出token数 × 输出单价) / 缓存命中率调整系数缓存命中率调整系数怎么来跑一周线上流量统计有多少请求命中了缓存。如果命中率是30%那实际成本大概是理论成本的70%到80%取决于缓存单价折扣。我还会加一个重试成本。模型不是100%可靠的有时候会返回格式错误、超时、或者内容不合规需要重试。重试率因任务而异我见过最高的有15%。算成本的时候把这个加上不然预算会超。4.4 第四步压测延迟和稳定性成本和效果都达标了最后一步是压测。压测不是测极限QPS是测你的业务峰值下能不能稳住。我会模拟业务峰值流量跑至少30分钟看几个指标P50首token延迟流式场景下用户感知到的“反应速度”。P95完整响应时间非流式场景下用户愿意等的上限。错误率超时、限流、格式错误的占比。限流触发次数如果压测期间就触发限流那上线后肯定不够用。压测通过之后我还会做一件事准备降级方案。万一上线后模型服务出问题能不能自动切到备用模型备用模型的效果差多少用户能不能感知到这个降级方案要提前写好别等出事了再临时找。提示压测的时候记得把缓存关掉测最坏情况。缓存命中率高的时候延迟很好看但缓存失效的时候才是真实压力。5. 九月踩过的坑和排查实录5.1 坑一新旗舰的“隐性限流”九月某家发新旗舰我第一时间申请了API key跑评测集效果很好成本也比上一代低。正准备切流量还好留了个心眼先拿10%的流量跑了一天。结果当天下午就出问题了P95延迟从1.2秒涨到6秒错误率从0.5%涨到8%。查日志发现是触发了隐性限流——官方文档里写的限流阈值是每分钟1000次请求但实际跑到600次左右就开始排队了。后来问客服才知道新模型上线初期资源紧张实际限流阈值比文档写的低而且不同账号等级的阈值还不一样。这个坑的教训是别信文档里的限流数字自己压测。压测的时候从低到高慢慢加找到实际开始排队的那个点然后按这个点的70%作为你的安全阈值。5.2 坑二上下文缓存的“假命中”另一个坑跟缓存有关。九月新发的某个模型支持上下文缓存官方说缓存命中的部分按10%的价格计费。我一看这便宜啊赶紧把长系统提示词都改成缓存模式。结果月底账单出来缓存节省的钱远低于预期。排查发现两个问题一是缓存有效期比想象中短官方说1小时但实际在高并发下可能几分钟就被挤掉了二是缓存命中要求前缀完全一致我系统提示词里有个时间戳每次请求都不一样导致缓存从来没命中过。后来我把时间戳挪到用户消息里系统提示词做成完全静态的缓存命中率才上去。这个细节官方文档里没写清楚是我自己踩坑踩出来的。5.3 坑三输出token的“通胀”第三个坑最隐蔽。九月有个新模型输出价格特别低我拿它做一个生成类任务算下来成本比原来省一半。但上线一周后发现总成本反而涨了。原因在于这个模型为了生成同样质量的内容平均输出token数比原来多了40%。比如原来模型用100token能说清楚的事它要用140token。单价是低了但量上去了乘出来总价反而高。这个坑的排查方法是别只看单价看“每完成任务成本”。定义一个标准任务比如“生成一段200字的产品描述”然后统计不同模型完成这个任务平均消耗多少token、花多少钱。这个指标才反映真实成本。5.4 常见问题速查表问题现象可能原因排查方法解决思路延迟突然飙升触发限流、GPU资源紧张看错误码、看P95延迟曲线降级到备用模型、降低并发成本超预算输出token通胀、缓存未命中统计输入输出token比、缓存命中率压缩prompt、优化缓存策略效果不稳定模型版本更新、prompt不兼容对比版本变更日志、跑评测集锁定模型版本、重新调prompt格式错误率高模型对格式指令遵循度下降抽检错误case、看错误模式加few-shot示例、加格式校验重试并发上不去账号等级限制、区域资源不足压测找实际限流点申请提额、多区域部署6. 换轨期的一些个人体会九月这波变化我最大的感受是AI应用的门槛在从“能不能做”变成“划不划算”。以前大家比的是谁先做出功能现在比的是谁能把功能做得可持续。成本下探给了更多人入场的机会但评价标准换轨也意味着光靠“接了个大模型”已经不够了。你得知道你的场景适合什么模型、你的成本结构是什么样的、你的降级方案是什么。我自己的做法是每个月花半天时间做一次“模型选型复盘”把当前在用的模型跑一遍评测集看看效果有没有波动算一下上个月的实际加权成本跟预算对比再看看有没有新发布的模型值得试。这个习惯坚持了半年帮我避开了至少三次因为模型更新导致的线上问题。最后分享一个我觉得挺实用的小技巧给每个模型调用加一个“成本标签”。在日志里记录这次调用用了哪个模型、消耗了多少token、估算成本是多少。这样月底一拉报表哪个功能最烧钱、哪个模型性价比最低一目了然。别等到账单出来才去猜钱花哪了那时候已经晚了。 
长河君 · 2026/11/3 13:41:18 · 阅读 1.2k 九月AI旗舰模型成本下探与选型换轨：一线开发者的实操复盘
1. 九月这波旗舰潮到底在卷什么九月份这一个月我朋友圈里做AI应用的朋友几乎没消停过。前脚某家刚发完新旗舰模型后脚另一家就甩出个更便宜的版本价格表一天一个样。你要是隔三天不看群消息回来就发现讨论的话题已经从“哪个模型跑分高”变成了“哪个模型每百万token便宜了两块钱”。这个月的核心关键词就两个旗舰扎堆和成本下探。听起来像是两件独立的事其实是一件事的两面——当头部玩家在同一时间窗口密集发布新版本竞争维度就不可避免地会从“谁更强”滑向“谁更划算”。而一旦价格战打起来整个行业的评价标准就会跟着换轨。我先把话说在前面这篇复盘不是给投资人看的行业分析也不是给媒体用的通稿素材。我写的是作为一个每天要调API、要算成本、要跟产品经理扯皮“这个功能到底用哪个模型”的一线从业者在这个九月里观察到的真实变化。如果你也是做AI应用落地的或者正在选型阶段纠结用哪家模型那这篇东西应该能帮你省下不少试错时间。九月的这波发布潮有个很明显的特征旗舰模型不再只是秀肌肉而是直接对标落地场景。以前发新模型官方博客里全是benchmark截图MMLU涨了几个点、HumanEval又破了纪录。但九月这波我注意到一个变化——好几家在产品页面上直接放了“每百万token成本对比表”甚至有的把“相比上一代降价XX%”写进了标题里。这说明什么说明厂商自己也意识到光靠跑分已经很难说服客户掏钱了大家开始算账了。这个转变对一线开发者的影响是直接的。以前选模型流程大概是看跑分→看榜单→选最高的那个→上线。现在不行了你得算这个任务用旗舰模型跑一次多少钱用中杯模型跑一次多少钱效果差多少用户能不能感知到。评价标准从“能力上限”变成了“能力/成本比”这个换轨是九月最值得关注的事。我自己的体感是九月之后团队内部讨论模型选型的会议时间明显变长了。以前十分钟能定的事现在要开半小时因为要对比的维度多了——不光是效果还有延迟、并发限制、上下文窗口的实际可用性、以及最关键的这个价格能撑多久。毕竟谁也不想今天刚把架构搭好下个月厂商一纸公告说涨价或者限流。2. 成本一路下探到底是怎么降下来的2.1 降价不是做慈善是架构和推理优化的结果很多人看到API价格往下走第一反应是“厂商在烧钱抢市场”。这个判断对了一半但不全对。烧钱补贴确实存在但九月这波降价更多是技术侧实打实的成本优化传导到了价格上。我拆一下这里面的逻辑。大模型推理成本主要花在三块算力GPU时长、显存带宽、以及调度效率。九月发布的新旗舰里好几家都提到了“MoE架构的进一步优化”和“推理时的动态稀疏激活”。说人话就是以前你问一个问题模型要把所有参数都过一遍现在它只激活跟这个问题相关的部分专家网络其他部分待机。这就好比你去餐厅点菜以前是后厨所有灶台同时开火现在只开你需要的那两个灶。这个变化带来的成本下降是数量级的。我拿一个实际场景算过账一个中等复杂度的文本分类任务输入500token、输出50token用上一代旗舰模型跑每千次调用成本大概在1.2元左右换成九月新发的某个MoE架构旗舰同样任务每千次调用降到了0.4元出头。降幅接近70%这不是补贴能补出来的是架构红利。另一个降本来源是推理框架的成熟。九月前后几个主流推理引擎都发了新版本对长上下文的KV Cache管理做了优化。以前处理一个32K上下文的请求显存占用会随着对话轮次线性增长跑到后面要么OOM要么延迟爆炸。现在通过分页管理和前缀共享同样长度的上下文显存占用能压到原来的三分之一左右。这意味着同样的GPU能扛更多并发单次调用的分摊成本自然就下来了。2.2 价格表背后的隐藏条款你得会看降价是好事但九月这波价格调整里有几个坑我踩过得提醒你注意。第一个坑是阶梯定价的临界点。很多厂商的定价页面上写的是“输入每百万token X元”但下面小字里藏着“月调用量超过Y百万后超出部分按Z元计费”。这个Z有时候比X高有时候比X低你得根据自己的实际调用量算清楚落在哪个区间。我见过一个团队为了拿更低单价拼命刷调用量结果月底一算因为跨过了某个临界点实际单价反而比不刷还贵。第二个坑是缓存命中的计费差异。现在好几家都支持“上下文缓存”就是如果你重复发送相同的前缀内容这部分可以按更低的缓存价格计费。但缓存有有效期有的是几分钟有的是几小时。如果你的应用场景是用户隔半天才回来继续对话那缓存早就失效了你按缓存价格做的预算就会超。我一般会建议团队在压测阶段就把缓存命中率打出来按实际命中率去估算成本而不是按理论最优值。第三个坑最隐蔽输出token的计费权重。有些厂商输入和输出是分开计价的输出通常比输入贵。但九月新发的几个模型里有的把输出价格调得特别低吸引你去做生成类任务。这时候你要注意输出价格低不代表总成本低——如果模型为了生成同样质量的内容需要输出更多token比如啰嗦、重复那单价低反而总价高。我实测过同一个摘要任务A模型输出价格是B模型的一半但A平均要输出300token才能达到B用150token的效果算下来总成本差不多。提示看价格表的时候别只看输入单价。把输入、输出、缓存、阶梯四个维度拉个表格按你自己的业务分布算加权成本这才是真实成本。2.3 成本下探对应用层意味着什么成本降下来最直接的影响是以前算不过账的场景现在能算了。举个例子实时翻译。以前用旗舰模型做同传级别的翻译延迟和成本都扛不住只能做“提交-等待-返回”的异步翻译。但现在推理成本降了、延迟也优化了我试过用新旗舰做流式翻译端到端延迟能压到800毫秒以内成本大概是每分钟对话0.02元左右。这个数字意味着什么意味着你可以把它做成一个常驻功能而不是一个“高级用户才配用”的付费点。再比如长文档处理。以前处理一份100页的PDF光是输入token就要花掉几块钱很多团队只能做摘要或者分段处理。现在上下文窗口大了、单价低了整份文档塞进去做全量分析成本能控制在几毛钱。这个变化直接催生了一批“文档深度分析”类产品九月之后我至少看到五六个团队在往这个方向转。但这里有个反直觉的点成本降低不一定会让你的账单变少。因为成本低了你会忍不住用更多、更复杂的调用。以前舍不得让模型多轮反思现在便宜了那就让它跑三轮吧以前只处理用户主动提交的内容现在成本低了那就把所有历史记录都塞进去做上下文吧。结果月底一看单价降了60%总账单涨了200%。这个坑我踩过后来学乖了给每个功能模块设了token预算上限超了就降级到小模型或者走规则兜底。3. 评价标准换轨从跑分崇拜到场景适配3.1 跑分为什么越来越不够用了九月这波旗舰发布有个很有意思的现象官方跑分和实际体感之间的差距在拉大。以前MMLU涨两个点你在实际任务里多少能感觉到一点提升。但现在头部模型的跑分已经挤在很窄的区间里了MMLU都是85分往上HumanEval都是90分左右差距在统计误差范围内。可你实际用起来A模型和B模型在同一个任务上的表现可能天差地别——A模型写代码一次过B模型总是漏边界条件A模型总结文档能抓住重点B模型总是把次要信息当核心。为什么会这样因为跑分测的是“平均能力”而你的业务场景要的是“特定能力”。MMLU考的是通识知识但你的业务可能只需要模型懂法律条文HumanEval考的是算法题但你的业务可能只需要模型会写SQL查询。跑分高的模型在你的特定场景里不一定好用。我现在的做法是建自己的评测集。不用多每个核心功能准备50到100条真实case覆盖正常情况、边界情况、以及你踩过坑的异常情况。每次有新模型发布先跑自己的评测集跑分只作为参考。这个习惯帮我省了很多事——有一次某个新旗舰在公开榜单上排名第一但在我的SQL生成评测集上准确率只有70%比上一代还低直接pass。3.2 场景适配的四个维度九月之后我评估一个模型是否适合某个场景会从四个维度打分维度具体指标为什么重要效果自有评测集准确率、人工抽检通过率跑分高不代表你的任务做得好成本加权每千次调用成本、缓存命中率单价低不代表总成本低延迟P50/P95首token延迟、完整响应时间流式场景对首token延迟极敏感稳定性限流阈值、故障恢复时间、版本兼容性上线后最怕突然限流或接口变更这四个维度里稳定性是最容易被忽略但最致命的。我经历过一次某个模型效果和成本都很理想上线两周后突然开始限流P95延迟从1秒飙到8秒用户投诉直接爆了。后来才知道是厂商那边GPU资源紧张优先保障了大客户。这件事之后我选型时一定会问清楚限流策略是什么、有没有SLA保障、版本更新会不会提前通知。3.3 换轨之后团队协作方式也在变评价标准变了团队内部的协作方式也跟着变。以前算法团队和工程团队的边界比较清晰算法团队负责选模型、调效果工程团队负责部署和运维。但现在成本成了算法团队也要背的指标。我认识的几个团队九月之后都把“每千次调用成本”写进了算法团队的OKR里。这意味着算法同学不能只盯着效果调参了还得考虑这个prompt能不能压缩、这个few-shot示例能不能减少、这个任务能不能拆成两步用更小的模型先过滤一遍。产品团队的角色也在变。以前产品经理提需求说的是“这个功能要准确率90%以上”。现在他们会问“准确率85%但成本降一半能不能接受”或者“这个功能用旗舰模型跑用户愿意付多少钱”成本意识开始渗透到产品定义阶段而不是等到技术方案评审时才考虑。这个变化我觉得是好事。AI应用落地说到底是要算经济账的。九月这波成本下探和评价标准换轨本质上是在把行业从“技术演示”推向“商业闭环”。能在这个换轨期活下来的团队不一定是技术最强的但一定是最会算账的。4. 实操九月之后我的模型选型流程4.1 第一步明确任务分级我现在拿到一个需求第一件事不是选模型而是给任务分级。S级任务直接影响核心用户体验错了会导致用户流失或投诉。比如客服机器人的意图识别、代码助手的补全建议。A级任务影响体验但不致命错了用户会感知到但能容忍。比如文档摘要、内容推荐。B级任务后台处理用户不直接感知。比如日志分类、数据清洗、批量翻译。分级之后选型策略就清晰了S级任务用旗舰模型成本高也认A级任务用中杯模型效果差一点但成本可控B级任务用轻量模型或者规则引擎能省则省。这个分级不是拍脑袋定的我会拉上产品和运营一起对齐。因为“致命”和“能容忍”的边界不同角色判断不一样。技术觉得“摘要少了一句话没关系”产品可能觉得“这句话是用户最关心的”。对齐一次后面省很多扯皮。4.2 第二步建最小评测集分级之后给每个S级和A级任务建评测集。不用多50条起步覆盖三类case正常case最常见的输入占70%。边界case输入特别长、特别短、或者格式奇怪的占20%。坑case你之前踩过坑的输入占10%。评测集的标注不用太复杂二分类就行通过/不通过。如果任务比较复杂可以加一个“部分通过”的中间档。关键是标注标准要统一最好写个简单的标注指南不然不同人标出来的结果没法比。我一般会用这个评测集跑三个模型当前在用的、新发布的旗舰、新发布的中杯。跑完之后看通过率如果新旗舰比当前在用的提升不到5个百分点那就不值得换——迁移成本、重新调prompt的成本、以及新模型可能带来的新坑都不划算。4.3 第三步算加权成本评测集跑完效果达标了接下来算成本。别用官方单价直接比要算加权成本。加权成本的公式大概是加权成本 (输入token数 × 输入单价 输出token数 × 输出单价) / 缓存命中率调整系数缓存命中率调整系数怎么来跑一周线上流量统计有多少请求命中了缓存。如果命中率是30%那实际成本大概是理论成本的70%到80%取决于缓存单价折扣。我还会加一个重试成本。模型不是100%可靠的有时候会返回格式错误、超时、或者内容不合规需要重试。重试率因任务而异我见过最高的有15%。算成本的时候把这个加上不然预算会超。4.4 第四步压测延迟和稳定性成本和效果都达标了最后一步是压测。压测不是测极限QPS是测你的业务峰值下能不能稳住。我会模拟业务峰值流量跑至少30分钟看几个指标P50首token延迟流式场景下用户感知到的“反应速度”。P95完整响应时间非流式场景下用户愿意等的上限。错误率超时、限流、格式错误的占比。限流触发次数如果压测期间就触发限流那上线后肯定不够用。压测通过之后我还会做一件事准备降级方案。万一上线后模型服务出问题能不能自动切到备用模型备用模型的效果差多少用户能不能感知到这个降级方案要提前写好别等出事了再临时找。提示压测的时候记得把缓存关掉测最坏情况。缓存命中率高的时候延迟很好看但缓存失效的时候才是真实压力。5. 九月踩过的坑和排查实录5.1 坑一新旗舰的“隐性限流”九月某家发新旗舰我第一时间申请了API key跑评测集效果很好成本也比上一代低。正准备切流量还好留了个心眼先拿10%的流量跑了一天。结果当天下午就出问题了P95延迟从1.2秒涨到6秒错误率从0.5%涨到8%。查日志发现是触发了隐性限流——官方文档里写的限流阈值是每分钟1000次请求但实际跑到600次左右就开始排队了。后来问客服才知道新模型上线初期资源紧张实际限流阈值比文档写的低而且不同账号等级的阈值还不一样。这个坑的教训是别信文档里的限流数字自己压测。压测的时候从低到高慢慢加找到实际开始排队的那个点然后按这个点的70%作为你的安全阈值。5.2 坑二上下文缓存的“假命中”另一个坑跟缓存有关。九月新发的某个模型支持上下文缓存官方说缓存命中的部分按10%的价格计费。我一看这便宜啊赶紧把长系统提示词都改成缓存模式。结果月底账单出来缓存节省的钱远低于预期。排查发现两个问题一是缓存有效期比想象中短官方说1小时但实际在高并发下可能几分钟就被挤掉了二是缓存命中要求前缀完全一致我系统提示词里有个时间戳每次请求都不一样导致缓存从来没命中过。后来我把时间戳挪到用户消息里系统提示词做成完全静态的缓存命中率才上去。这个细节官方文档里没写清楚是我自己踩坑踩出来的。5.3 坑三输出token的“通胀”第三个坑最隐蔽。九月有个新模型输出价格特别低我拿它做一个生成类任务算下来成本比原来省一半。但上线一周后发现总成本反而涨了。原因在于这个模型为了生成同样质量的内容平均输出token数比原来多了40%。比如原来模型用100token能说清楚的事它要用140token。单价是低了但量上去了乘出来总价反而高。这个坑的排查方法是别只看单价看“每完成任务成本”。定义一个标准任务比如“生成一段200字的产品描述”然后统计不同模型完成这个任务平均消耗多少token、花多少钱。这个指标才反映真实成本。5.4 常见问题速查表问题现象可能原因排查方法解决思路延迟突然飙升触发限流、GPU资源紧张看错误码、看P95延迟曲线降级到备用模型、降低并发成本超预算输出token通胀、缓存未命中统计输入输出token比、缓存命中率压缩prompt、优化缓存策略效果不稳定模型版本更新、prompt不兼容对比版本变更日志、跑评测集锁定模型版本、重新调prompt格式错误率高模型对格式指令遵循度下降抽检错误case、看错误模式加few-shot示例、加格式校验重试并发上不去账号等级限制、区域资源不足压测找实际限流点申请提额、多区域部署6. 换轨期的一些个人体会九月这波变化我最大的感受是AI应用的门槛在从“能不能做”变成“划不划算”。以前大家比的是谁先做出功能现在比的是谁能把功能做得可持续。成本下探给了更多人入场的机会但评价标准换轨也意味着光靠“接了个大模型”已经不够了。你得知道你的场景适合什么模型、你的成本结构是什么样的、你的降级方案是什么。我自己的做法是每个月花半天时间做一次“模型选型复盘”把当前在用的模型跑一遍评测集看看效果有没有波动算一下上个月的实际加权成本跟预算对比再看看有没有新发布的模型值得试。这个习惯坚持了半年帮我避开了至少三次因为模型更新导致的线上问题。最后分享一个我觉得挺实用的小技巧给每个模型调用加一个“成本标签”。在日志里记录这次调用用了哪个模型、消耗了多少token、估算成本是多少。这样月底一拉报表哪个功能最烧钱、哪个模型性价比最低一目了然。别等到账单出来才去猜钱花哪了那时候已经晚了。