进入2026年2月我重新翻了一遍过去一年参与和旁观的几十个AI项目记录。一年前大家聊的还是哪家的模型参数又大了、榜单又刷到第一了现在圈子里真正被反复讨论的已经变成了每百万token的推理成本、真实业务流里一次失败的Agent链路、评测集是否被“背过答案”。大模型行业正在从一个“比谁嗓门大”的阶段进入一个“比谁算得细”的阶段。这篇不是行业报告也不是工具教程就是一份个人思考笔记——写给还在跟进大模型发展的同行无论你在一线做工程还是在做产品决策希望这些观察能帮你少走几步弯路。1. 算力军备的尽头是成本绞肉机1.1 预训练规模的边际红利正在变薄2025年之前的逻辑很清晰模型能力约等于参数规模加上训练算力谁堆得多谁就领先。但从2025年下半年开始很多团队发现同一套数据、同样的预算继续扩大预训练规模带来的公开基准提升变得非常有限。行业里讨论得越来越多的不是“能力还能涨多少”而是“涨的这些还值不值”。这不是说大模型能力见顶了而是说投资回报率变了。过去砸10倍算力能换2倍能力现在砸10倍算力可能只能换10%的能力提升而且这10%普通用户根本感知不到。于是整个产业的竞争重心开始转移与其赌一张更大规模的预训练不如把推理效率做上去。这直接导致“小模型大模型混合路由”成为很多团队的默认架构——高频简单请求交给小模型低频复杂请求才动用大模型。1.2 三个被反复验证的成本杀手过去一年里我观察到推理成本下降主要来自三个方向而且这三个方向都不是什么黑科技都是工程上的硬功夫。第一个是量化。量化不再是简单地从FP16砍到INT8现在很多团队用“感知量化”按层分配位宽——对敏感层保留更高精度对不敏感层激进压缩。我见过一个内部推理服务做了一次按层量化之后模型体积缩小接近一半吞吐提升明显业务指标几乎没掉。但这里有个经验不是所有层都适合激进量化尤其是注意力层的某些关键投影强行压缩会导致长文本场景下输出质量明显下降。第二个是蒸馏。把大模型的长处浓缩进小模型这个思路本身不新鲜但很多人做蒸馏时只拿大模型的答案当训练数据忽略了中间推理过程。实操中更有效的做法是让大模型同时输出“答案推理步骤对错误的解释”小模型学的不只是结果而是整个思考路径。某团队用这种方式蒸馏出来的7B模型在垂直领域问答上追平了原来用的70B模型推理成本直接降到原来的十分之一上下。第三个是投机采样。核心思路是用一个小模型先快速“猜”出几个token再由大模型批量校验对的直接采纳错的重来。这个方案对批量请求足够大的在线服务效果非常明显不少中型团队光是上了投机采样加动态批处理感知延迟就下降了一半以上。它依赖一个前提小模型和大模型的分布要足够接近否则校验失败率太高反而拖慢速度。1.3 一个反面的真实教训我见过一个团队踩过很典型的坑选型时只看公开基准跑分选了一个“分数高一点但推理贵一倍”的模型上线后每天推理成本吃掉了毛利的一大块最后只能重构把大部分流量迁到更小的模型上才缓过来。这个案例在圈子里其实很普遍。在新的竞争阶段“分数”和“成本”必须放在同一张表里看脱离成本谈模型选型就是给自己埋雷。2. 数据枯竭年代合成数据要用“钳制”而不是“信任”2.1 互联网的免费午餐正在消失大模型的数据来源正在肉眼可见地收紧。越来越多的内容平台限制爬取公开数据集里重复样本的比例越来越高高质量人类文本的增量已经趋缓。圈子里有个判断我基本认同下一阶段大模型能力的竞争重心正在从“谁的算力多”转向“谁的数据流更独特”。那些拥有真实业务日志、真实用户交互记录的公司在垂直场景上的优势会越来越难被公开数据追赶者动摇。但对大多数团队来说真实数据永远不够合成数据就成了最现实的补强手段。这也是2025年以来讨论度极高的话题合成数据到底能不能用我的答案是能但前提是你把它当成“需要钳制的原料”而不是“可以直接信任的答案”。2.2 合成数据的正确姿势与翻车现场先看一个翻车案例。某智能客服团队想快速扩充意图识别样本让大模型批量生成了十万条相似问法模型训练后离线指标非常漂亮结果一上线真实用户进来就崩——因为真实用户根本不会用那么“标准”的句式说话生成数据里还带着一股明显的“AI腔”。复盘时发现生成数据的词汇分布和真实用户差距很大模型学了一堆模板化的表达方式遇到口语化的真实输入反而不认识了。解法其实不复杂拿真实工单日志做锚点先生成“围绕锚点的变体”也就是在真实句子的基础上做同义改写、语气调整、槽位替换而不是让模型凭空想象用户会怎么说生成之后再做一轮分布过滤剔除那些和真实分布偏离太远的样本最后人工抽检百分之一到二。这个团队调整之后准确率回升了十多个百分点。关键不是“用了合成数据”而是“合成数据以真实数据为锚”。2.3 数据治理的工程化版本、血缘、权限还有一件事很多人忽视但后期会付出巨大代价数据不只是样本集也是产品资产。如果每次微调的数据没有版本记录没有标注来源没有记录合成脚本的参数那两个月后模型出了问题你根本不知道是哪个批次的数据引入的偏差。我的建议很朴素每一次训练数据的构建都应当像一次代码发布——有版本号、有变更说明、有回滚方案。数据血缘至少要记录三件事真实数据的来源批次、合成数据的生成脚本和模型版本、过滤规则的具体参数。听起来繁琐但遇到线上事故要定位根因时这套记录就是救命绳。3. 多模态与Agent已经从“能演示”变成“能生产”3.1 多模态的“看得见”不等于“看得懂”多模态模型如今“能看”的东西已经很多图片、图表、视频流。但在工程上“看得见”和“看懂了”是两码事。最典型的例子是让模型读取一张数据大屏截图生成摘要——模型经常会把不同图表的数字搞混因为它看的是像素不是真实的数据表。它可能在视觉上“认出了”一个柱状图但柱子的具体数值是它猜的不是读出来的。所以工程上有一条很实用的原则能喂结构化数据的地方就优先喂结构化数据截图只做辅助。让模型读JSON、读数据库查询结果、读API返回值而不是去“看”一张渲染好的图片。这个原则能直接消掉一大类多模态幻觉。另外视觉模态的幻觉比文本更隐蔽——文本幻觉你至少读得出来图像误读不对照原图很难发现。引入置信度过滤机制让模型对拿不准的识别结果直接说“不确定”是底线级别的设置。3.2 Agent生产的真正瓶颈不是模型是流程控制Agent从“能演示”到“能干活”中间隔着的不是模型能力而是流程控制。我看了太多团队在Agent上栽跟头原因高度一致任务拆解不稳定、工具返回异常没处理、状态管理混乱、权限边界模糊。举一个实际的例子。某团队做了一个自动化报表Agent模型负责写SQL、跑查询、生成结论。上线之后发现SQL经常“语法正确但字段用错”——比如把“当日活跃用户数”和“新增用户数”混在一起。排查了很久才发现问题不在模型的SQL能力而在于它根本不知道每张表的字段语义它只是在猜。后来团队做了一件事给Agent提供一张表语义元数据把字段别名、常用口径、示例值全部列清楚模型在写SQL之前先查这个元数据字段错误率立刻降了下来。这个案例给了一个很清晰的启示Agent不能只有一个“自由发挥”的模型接口必须把工具边界、校验规则、错误恢复机制做成显式流程。用一个生活化的类比——让一个非常聪明的实习生做事你也得给他明确的工作手册、检查清单和紧急联系人而不是只丢一句话“你去搞定”。3.3 别急着全自动先做“半步自动化”我见过很多团队一上来就想搞全自动Agent结果一旦出错用户再也不信任这个产品了。更稳健的路径是“半步自动化”让Agent先把草稿做出来在关键checkpoint由人来确认先把最枯燥、最不容易出错的环节自动化。等积累了足够多的真实反馈跑稳定了再逐步放开。这不仅仅是稳妥也是一种数据策略。每一步人工确认都在产生真实标注数据这些数据比任何合成数据都值钱。用这些反馈去微调模型、优化提示词和工具定义Agent才会越用越顺。跳过这个过程直接追求全自动等于在没有训练集的情况下强行部署失败几乎是必然的。4. 评测基准正在失效建立自己的“业务回归集”4.1 榜单分数的“通货膨胀”和“背题”现象现在公开榜单的参考价值正在肉眼可见地缩水。一方面头部模型之间的分数差距已经小到几乎没有统计意义榜首和第五名可能就差零点几分你根本分不清谁真的更好另一方面数据泄漏问题越来越严重——有些模型疑似在训练阶段就把测试题吃进去了导致分数高得离谱。更微妙的是评测集本身也卷出了“应试教育”。一些模型在特定基准上刷得很漂亮一拿到真实业务输入就露馅。对于应用开发者来说盯着这类分数做选型等于看高考模拟题成绩挑选员工参考价值极其有限。行业里已经开始流行“动态题库”“从未公开的实时评测”但动态不等于真实——真正能帮你做决策的还是从你自己的业务里长出来的评测。4.2 我建议的评估三步法第一用真实业务数据构建一个一到几百条的回归集。从用户日志里随机抽取输入人工标注期望输出不要从公开数据集里拷贝更不要只挑简单的样本——长尾的、口语化的、带错别字的都往里放。第二看分布不要只看平均。重点翻最差的那10%是什么样。十个请求里九个答对了一个答得非常离谱平均分可能很好看但那个离谱的案例可能就发生在你的核心客户身上。很多时候一个模型的“下限”比“上限”更决定产品口碑。第三上线前做小流量灰度。用真实流量A/B拿业务指标——用户留存、问题解决率、投诉率——做最终判断。跑分只能用来筛候选不能用来下结论。我见过一个很典型的案例某团队按公开基准选了A模型上线后用户投诉明显变多查下来发现A模型在口语化短文本场景下喜欢长篇大论答得“正确但烦人”。B模型平均分略低但在关键场景更稳最后团队换了B投诉率才降回去。如果那个团队提前建了业务回归集这个问题在测试阶段就能发现。4.3 “大模型当裁判”也有自己的偏见LLM-as-Judge现在很普遍让大模型给大模型的输出打分省人力但裁判本身有偏好——它通常更喜欢更长、更结构化、用了更多连接词的答案哪怕内容平平。这会导致“高分冗长”的答案挤压“低分精炼”的答案。实操建议用多模型投票降低单一裁判的偏差同时定期拿人工评过的样本去校准裁判模型。高风险场景的输出比如医疗建议、法律信息、金融判断必须保留人工审核环节不能把最终裁决权完全交给另一个模型。5. 开源与闭源的攻防战生态位正在分化5.1 开源不再是“差一截的替代品”过去很长一段时间开源模型的角色是“闭源模型的穷人版”。但到了2026年这个判断已经过时了。开源模型和闭源模型之间的差距已经缩小到“半步”而且在某些维度开源反而有不可替代的优势。企业到底选开源还是闭源核心不是“谁更强”而是“我需要什么”。我整理了一个比较实用的决策框架维度开源模型闭源模型数据隐私可完全私有化部署数据不出域依赖API调用数据在外能力上限接近顶部但复杂推理仍有差距综合能力上限更高多模态整合更好定制空间可微调、可裁剪、可解释只能通过提示词和上下文控制长期成本算力自持边际成本可控API费用随用量线性增长工程生态周边工具成熟但供应链风险要自担配套服务完善运维省心安全审计可自行审计可控性强依赖服务商的透明度和承诺如果业务涉及敏感数据、需要深度定制、或者长期调用量巨大开源路线通常更划算如果团队规模小、不想建推理基础设施、需要快速上线闭源API还是更省心。两种路线不是互斥的——不少团队的做法是核心私有场景用开源模型泛化能力要求的公开场景用闭源API按流量分流。5.2 开源真正的风险不是能力是供应链很多人以为用了开源模型就“自主可控”了其实不然。开源真正的风险藏在工程链路里上游基础库有没有被投毒、你拿到的第三方微调版本来路是否干净、开源许可证的边界是否清晰。2025年出现过不止一次“一个看似正常的开源工具包里藏了恶意代码”的事件。所以对开源模型的使用我有三条建议一是锁定版本不要追新每次升级都要走完整的回归测试二是对下载的模型文件和依赖库做校验来源不明的一律不碰三是持续关注社区的更新频率和维护状态如果项目长期没有维护要尽早评估替代方案。开源从来不是“零成本”它的成本从“授权费”转移成了“维护义务”。6. 对齐与安全正从“口号”变成产品约束6.1 过度对齐的反噬把模型调成了复读机早期为了安全可控不少团队会把对齐调得“宁可错杀一千不可放过一个”。结果就是模型变成了一个过度敏感的复读机用户问一个完全正常的业务问题模型开始长篇大论地拒绝、纠正、反问。我见过某公司的AI客服因为“过度拒绝”被用户集体吐槽业务指标断崖式下滑。对齐不是越严越好而是“分场景策略”。实操中可以把用户请求分成高、中、低三个风险等级高风险场景医疗、法律、金融操作走强校验答案必须带来源和置信度提示中风险场景做格式约束和内容过滤低风险场景直接放行给模型足够的自由度。规则引擎做兜底模型判断做决策而不是让模型自己从头到尾“想太多”。6.2 从“事后审核”到“事前约束”提示词注入、幻觉、隐私泄漏这些问题不能只靠上线后审核。更有效的做法是从系统设计阶段就把安全约束嵌进去外部知识必须带来源可溯源输出要经过格式校验才能放给用户模型不能直接访问超出权限范围的工具和数据。安全不是模型的一个属性而是整个产品架构的一个属性。这里讲一个虚拟案例。某AI医疗问答项目上线初期模型给用户提供了一个看似权威、但剂量完全错误的建议好在及时发现下架没有酿成严重后果。事后复盘发现如果当时就引入“引用来源置信度提示免责声明”三件套这个错误根本走不到用户面前。这个案例给我的教训很深安全设计的核心不是“让模型更乖”而是“让错误没有机会造成伤害”。7. 往后看几个大概率会持续的方向7.1 推理成本继续下降应用门槛继续降低推理优化不是一个一次性的工程它每年都在以数量级的方式进步。这意味着应用开发者应该把模型当作“可替换组件”来对待——今天用这个模型明天如果出现推理成本只有一半、效果差不多的方案就可以平滑切换。不要把业务逻辑和某一家模型深度耦合越抽象越好。7.2 “模型越大越好”的迷信会进一步瓦解2025年已经能明显看到小模型加混合路由的架构在成本和质量上都能打赢单纯的大模型方案。未来两到三年这个趋势只会更明显小模型负责高频、简单、延迟敏感的任务大模型负责低频、复杂、创造性要求高的任务。选型的关键词不再是“参数多大”而是“这个任务到底需要多强的模型”。7.3 组织能力比模型能力更决定成败最后说点我个人很深的体会。过去一年里我见过不少团队拿着最强的模型做出的产品却平平无奇也见过一些团队用开源小模型把垂直场景打磨得非常扎实。差距不在模型而在组织能力——有没有一套自己的评测体系数据管道是否稳定流程控制是否清晰团队里有没有人会问正确的问题。如果只让我给同行一个建议我会说先搭一个验证闭环数据、微调、评测、上线、回归让这个闭环转起来再谈要不要上更强的模型。闭环永远是先于模型的。模型可以一年换三代但一个能持续产出优质数据的闭环才是真正复利增长的东西。