进入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，按流量分流。

5.2 开源真正的风险不是能力，是供应链

很多人以为用了开源模型就“自主可控”了，其实不然。开源真正的风险藏在工程链路里：上游基础库有没有被投毒、你拿到的第三方微调版本来路是否干净、开源许可证的边界是否清晰。2025年出现过不止一次“一个看似正常的开源工具包里藏了恶意代码”的事件。

所以对开源模型的使用，我有三条建议：一是锁定版本，不要追新，每次升级都要走完整的回归测试；二是对下载的模型文件和依赖库做校验，来源不明的一律不碰；三是持续关注社区的更新频率和维护状态，如果项目长期没有维护，要尽早评估替代方案。开源从来不是“零成本”，它的成本从“授权费”转移成了“维护义务”。

6. 对齐与安全，正从“口号”变成产品约束

6.1 过度对齐的反噬：把模型调成了复读机

早期为了安全可控，不少团队会把对齐调得“宁可错杀一千，不可放过一个”。结果就是模型变成了一个过度敏感的复读机：用户问一个完全正常的业务问题，模型开始长篇大论地拒绝、纠正、反问。我见过某公司的AI客服因为“过度拒绝”被用户集体吐槽，业务指标断崖式下滑。

对齐不是越严越好，而是“分场景策略”。实操中可以把用户请求分成高、中、低三个风险等级：高风险场景（医疗、法律、金融操作）走强校验，答案必须带来源和置信度提示；中风险场景做格式约束和内容过滤；低风险场景直接放行，给模型足够的自由度。规则引擎做兜底，模型判断做决策，而不是让模型自己从头到尾“想太多”。

6.2 从“事后审核”到“事前约束”

提示词注入、幻觉、隐私泄漏这些问题，不能只靠上线后审核。更有效的做法是从系统设计阶段就把安全约束嵌进去：外部知识必须带来源可溯源，输出要经过格式校验才能放给用户，模型不能直接访问超出权限范围的工具和数据。安全不是模型的一个属性，而是整个产品架构的一个属性。

这里讲一个虚拟案例。某AI医疗问答项目上线初期，模型给用户提供了一个看似权威、但剂量完全错误的建议，好在及时发现下架，没有酿成严重后果。事后复盘发现，如果当时就引入“引用来源+置信度提示+免责声明”三件套，这个错误根本走不到用户面前。这个案例给我的教训很深：安全设计的核心不是“让模型更乖”，而是“让错误没有机会造成伤害”。

7. 往后看：几个大概率会持续的方向

7.1 推理成本继续下降，应用门槛继续降低

推理优化不是一个一次性的工程，它每年都在以数量级的方式进步。这意味着应用开发者应该把模型当作“可替换组件”来对待——今天用这个模型，明天如果出现推理成本只有一半、效果差不多的方案，就可以平滑切换。不要把业务逻辑和某一家模型深度耦合，越抽象越好。

7.2 “模型越大越好”的迷信会进一步瓦解

2025年已经能明显看到，小模型加混合路由的架构，在成本和质量上都能打赢单纯的大模型方案。未来两到三年，这个趋势只会更明显：小模型负责高频、简单、延迟敏感的任务，大模型负责低频、复杂、创造性要求高的任务。选型的关键词不再是“参数多大”，而是“这个任务到底需要多强的模型”。

7.3 组织能力比模型能力更决定成败

最后说点我个人很深的体会。过去一年里，我见过不少团队拿着最强的模型，做出的产品却平平无奇；也见过一些团队用开源小模型，把垂直场景打磨得非常扎实。差距不在模型，而在组织能力——有没有一套自己的评测体系，数据管道是否稳定，流程控制是否清晰，团队里有没有人会问正确的问题。

如果只让我给同行一个建议，我会说：先搭一个验证闭环，数据、微调、评测、上线、回归，让这个闭环转起来，再谈要不要上更强的模型。闭环永远是先于模型的。模型可以一年换三代，但一个能持续产出优质数据的闭环，才是真正复利增长的东西。