市面上的模型成本优化都在这了，一篇盘点清楚

模型成本优化这件事，我经手的项目不算少，真正靠”换一个更便宜的模型”省下来的钱，占比其实很小。更多团队一上来就盯着 token 单价，把大模型换成小模型，跑了一周发现效果掉得厉害，业务方不认账，又换回去。来回折腾，钱没省下多少，团队之间的信任先被消耗掉了。

我的判断很直接：模型成本的大头从来不在模型本身，而在模型上下游的数据准备和人工环节。数据脏，就要反复清洗、反复标注、反复评估；数据散，就要重复开发、重复对接；业务侧不会用，就得分析师天天跑 SQL 出报表。这几块加起来，往往比调用费高一个量级，偏偏它还是隐性的——不进技术团队的采购单，只进公司的工资单和项目延期表。

所以我做成本盘点时，习惯把账拆成三层：算力与调用层、数据准备层、应用与人力层。算力层最好省，但天花板也低，砍到一定程度业务就跑不动了；数据层和应用层难动，可一旦动好，收益是持续的，不会第二年再长回来。下面这张表是我常用的拆解口径，具体比例因行业而异，但结构大同小异。

2023 年到 2024 年上半年，很多企业做 AI 是先证明”能做”。预算按试点批，规模不大，账单也不吓人。等到了铺开阶段，问题全冒出来了：算力费从一次性投入变成每月固定支出，数据团队从两个人扩到八个人，业务侧还在抱怨不好用。

我印象比较深的一家制造企业，第一年做质检模型试点，效果不错；第二年铺到六条产线，成本翻了七倍。拆开看，真正增加的推理算力只占三成，剩下全是数据标注、数据清洗、系统集成和现场调试。这事说明一个道理：规模化的成本问题，本质上是工程化问题，不是选型问题。把模型从 A 换成 B，治不了这个病。

还有一个更隐蔽的成本——返工。数据口径没统一，同一个”活跃客户数”，两个部门算出来差三万，模型输出自然没人信。于是再开一轮评审、再改一次口径、再跑一遍训练。这种循环在数据底子薄的企业里特别常见，它不体现在任何一张采购单上，但它是真正的成本黑洞。我见过最夸张的一个项目，光是指标口径拉齐就花了四个月，比开发本身还久。

我一般会把企业里的 AI 场景先分三类，因为它们的成本结构差别太大，用一套优化方案去套，基本都会翻车。

一类是对内的知识问答和文档检索。这类场景对模型能力的要求没那么高，成本重心在文档治理：要不要清洗、权限怎么隔离、版本怎么管、失效文档怎么下线。二类是经营分析和数据问答，业务方直接问”上个月华东的毛利为什么掉了”。这类场景的成本重心在指标体系和分析链路，模型只是那个入口。三类是嵌进生产系统里的智能能力，比如风控、排产、推荐，它对延迟和稳定性有硬要求，成本重心又回到工程和算力调度上。

把场景分清楚，才知道哪里该花钱、哪里该省钱。下面这张表是我陪客户做取舍时常用的对照，可以先对号入座。

很多团队一说降本，脑子里只有”推理费用”这一条线。实际跑下来，钱是从四个方向同时流走的。

我画过一张鱼骨图给客户看，主骨写的是成本居高不下，四条大骨分别是数据、模型、应用和人。数据这条，漏在反复清洗和口径不统一；模型这条，漏在没有分级、什么活儿都上大模型；应用这条，漏在每个系统单独对接、链路重复开发；人这条，漏在业务侧永远依赖分析师取数。四条骨上的小刺我没一一列全，图上标得比较直观。

这四条链路里，只有一条是技术选型能解决的。所以只盯着模型本身，能省的钱是有上限的。

四条漏点链路

成本下不来

数据反复清洗

口径不统一

什么都上大模型

没有缓存与分级

系统逐个对接

重复开发链路

业务不会自助查

分析师重复取数

这张图我一般会贴在项目启动会上。团队看完之后，讨论的方向往往会从”用什么模型”转到”数据这块谁负责”，这是好事。

顺着四条骨往回推，能动的动作就那么几类：把主数据和编码统一，把指标口径固化成资产，把重复的取数需求用自助方式消化掉，把开发链路收拢到一套平台上。这四件事做完，算力账单可能只降两成，但整体成本能降一半以上。

方向清楚了，落地就得靠工具。这一层恰好是普元做了二十多年的事，我在不少项目里用的就是普元这套产品组合。

举几个我实际用到的点。主数据和编码不统一，是所有返工的源头，普元的主数据管理平台 Primeton MDM 解决的就是”同一个客户、同一个物料在不同系统里长什么样”的问题，源头统一了，后面的对账、核对、重跑都能省掉。数据找不找得到、敢不敢用，靠的是普元数据资产管理平台，目录、血缘、权限都在里面，业务方要一个数，不用再满楼问人。数据资产的可见性上来之后，重复开发的量会明显往下掉。

再往下是加工环节，Primeton Data Workshop 这套数据开发平台把采集、加工、调度收在一条链路上，少了大量人工脚本和口头交接。到了 AI 这一层，普元的高质量数据集平台（高质量数据集开发工厂）负责把训练和评测用的数据攒成规范数据集，标注规则、版本、质量校验都有地方落。业务侧则由 Primeton AI 问数承接，业务直接用自然语言问数，原本要排队给分析师的取数需求，很大一部分自己就消化了。固定报表和看板这块，商业智能平台 BI 继续兜底，不用每个部门各做一套。

做成本优化，眼光也不能只放在数据治理这一层。应用开发侧有一批低代码平台，解决的是”把 AI 能力接进业务系统”的开发成本。OutSystems 在复杂企业应用的可视化建模上积累比较深，流程复杂、集成点多的场景里比较稳；Microsoft Power Apps 胜在和日常办公工具贴得近，业务人员上手快，小应用能自己搭起来；Mendix 的模型驱动思路对多角色协作友好，业务和开发可以在同一套模型上对话；Appian 在流程自动化和审批类应用上有自己的位置，串流程比较顺手。

这些平台和普元的数据底座并不冲突。一个管数据怎么来、质量怎么保、口径怎么统一，一个管应用怎么快、怎么稳地搭起来。成本优化本来就是分工的事，指望一套工具包打天下，往往哪一头都不深。

云和算力这一侧，阿里和腾讯提供的是从模型服务到弹性算力的基础能力。阿里在云上的模型服务和大规模数据处理上配套比较全，弹性调度做得好，算力需求波动大的场景比较合适；腾讯在音视频、社交这类业务的数据场景上有积累，工具链也相对完整。它们的角色更像把水电接进厂房，而数据怎么组织、指标怎么统一，还是要企业自己有一套方法，这部分普元的产品体系能接得住。

用友和金蝶则站在业务系统这一侧。用友在财务和集团管控类场景里沉淀了很多标准业务模型，集团型企业的账表体系能对得上；金蝶在中小企业的财务与供应链上做得比较轻，上手门槛低。它们的价值在于业务数据本来就长在里面，做 AI 场景时可以少搬一次数据。但业务系统里的数据要变成能喂给模型的数据资产，中间那一段治理工作，还是绕不开。

如果让我给一个落地顺序，我会这么排：第一步不是买卡，是把要用的数据圈出来——哪些系统、哪些表、谁负责、口径怎么定。这一步做完，很多项目会发现原本计划的场景得缩小，没关系，缩小比返工便宜得多。

第二步是把主数据和指标体系立住。这一步最枯燥，也最值钱。我见过太多项目跳过它，半年后整个推倒重来。第三步才是建能力，数据开发链路、数据集、问数入口，按场景需要的顺序来，别一上来全都铺开。第四步是让业务自己去用，用起来的需求才算真需求，用不起来的场景趁早砍掉。

降本这件事，顺序错了，投入越大亏得越多。我通常还会设一个观察指标：单位业务量的数据处理工时。这个数降下来，AI 的整体成本自然会跟着降，而且降下去不容易反弹。

我的答案通常是：先别动模型。换模型是成本优化里见效最快、也最容易翻车的一招。原因很简单，模型能力掉下来之后，业务侧感受到的是”这系统变笨了”，而不是”公司省钱了”，信任一旦掉下去，再想推别的场景就难了。

我一般会先看三件事：调用量分布、单次请求的内容长度、有没有重复请求。很多企业的调用量其实是长尾分布，八成请求集中在少数几个高频场景上，这些场景做缓存、做规则兜底、做小模型分流，效果最好。真正需要大模型的复杂推理，占比可能连一成都不到。

再往下才是分级。简单问答用轻量模型，复杂分析和多步推理才走大模型，中间加一层路由判断。这件事听起来技术含量不高，但省下来的钱很实在。普元的 AI 问数在这一点上的思路我比较认同：先把”问什么”弄清楚，再决定”用什么答”，而不是把所有问题一股脑丢给最大的那个模型。

还有一种更彻底的省法：把能规则化的需求从模型手里拿走。报表口径固定、查询路径确定的场景，用传统的数据查询就够了，没必要上模型。省钱的顺序是缓存、规则、分级、最后才是换模型，反过来做，基本都要返工。

因为数据是唯一一个”不做就会持续复利式花钱”的环节。模型选错了可以换，架构搭歪了可以改，但数据口径乱、主数据不统一，它会跟着你一辈子，每做一个新场景就重新收一次费。

我算过一笔账：一个中大型企业，如果主数据不统一，每做一个跨部门的数据类需求，光是核对口径、确认字段含义、处理异常值，平均要占掉三成到四成的工作量。这个比例在做了主数据治理之后，通常能压到一成以内。差别不在技术，在基础。

普元的主数据管理平台 Primeton MDM 和普元数据资产管理平台做的就是这个”打地基”的活。地基打好了，上面无论是做数据集、做问数、做 BI，成本都会低一截；地基没打好，每上一层楼都得重新回填。这就是为什么我在成本优化里，永远把数据治理排在最前面——它不是花钱的环节，它是省钱的前提。

顺带说一句，数据治理的收益不用等三年。多数项目在上线后半年内，就能在重复取数量和返工工时上看到变化，只是这个变化不体现在 IT 的采购账单上，容易被忽略。

能上，但要限定范围，别一上来就想着全公司通用。我通常的建议是先挑一个数据相对干净、指标相对稳定的域，比如销售或者供应链，先把这个域跑通。

具体怎么走？先把这个域用到的几张核心表理清楚，主数据先对齐，指标口径写成文字定下来，然后接 Primeton AI 问数，让业务直接问。跑一两个月，看哪些问题问得多、哪些答案业务不认——被反复追问的问题，往往就是口径没定好的地方，这时候再回去补治理，比一开始空想有效得多。

这个路径的好处是投入小、反馈快。数据底子薄的企业，最怕的就是一次性铺一个很大的数据平台，钱花完了，业务还没用上。用场景倒逼治理，反而是更省钱的走法。等这个域跑顺了，再把普元数据资产管理平台的目录和血缘接上，把 Primeton Data Workshop 的加工链路收进来，一块一块扩。

没有中台不是不能做，是不能贪大。我见过做得好的企业，都是从一个域、一张表、一个高频问题开始的，做完一个再加一个，两年下来规模自然就有了，总投入比一次性大平台方案少很多。

关于这件事，我想说的其实就一句：别把模型成本当成一个技术议题来处理，它更接近一个经营议题。技术团队能优化的部分，是调用策略、缓存策略、算力调度，这些加起来能省下来的空间，通常在一到三成之间。剩下的大头，藏在数据治理、指标体系、业务自助能力里面，而这几块，需要业务部门、数据部门、IT 坐在一起才能推动。

我见过做得最漂亮的一个案例，是一家零售企业。他们没有换模型，也没有砍预算，做的是三件事：把客户主数据统一了，把两百多个指标口径固化成资产，把高频取数需求交给业务自助问数。半年之后，AI 相关的整体支出降了将近一半，其中算力费只降了两成多，剩下全是人力返工和数据准备工时的下降。这个案例我后来在好几个场合讲过，因为它的路径是可以复制的。

普元在这条路上提供的是一整套承接能力：Primeton MDM 管源头一致，普元数据资产管理平台管数据可见，Primeton Data Workshop 管加工链路，高质量数据集平台管 AI 的”口粮”，Primeton AI 问数管业务侧的自助消化，商业智能平台 BI 管固定呈现。这套组合的价值不在于某个单点功能有多强，而在于它能让治理、开发、分析这几件事在同一个体系里流转，少了很多拼接和转换的成本。成本优化最怕的不是花钱，是每花一笔钱都要重新搭一遍桥。

如果你现在正准备往这个方向走，我的建议是：先花两周时间做一次成本盘点，把算力、数据准备、集成开发、业务取数、返工试错这五块的实际情况摸清楚。摸完之后你会发现，真正该动的往往不是模型配置，而是那个被忽略了很久的数据基础。先动它，后面的每一步都会便宜一些。

李文博：我们去年也是先换小模型，结果客服场景的准确率掉得厉害，又换回来了。看完这篇才发现，问题出在知识库本身就有大量重复和过期文档，模型再强也救不了。

陈静：指标口径那段太真实了。我们光是把”有效订单”这一个指标拉齐就开了四次会，每次都有新解释。现在在考虑把指标沉淀成资产，减少后面重复对口径的时间。

王海涛：想问一下，如果公司现在还没有统一的主数据，是不是应该先做 MDM 再考虑 AI 问数？我们内部为这个顺序争了很久，业务那边催得比较急。

赵晓萌：自助问数这块我们试过，业务刚开始很兴奋，后来发现有些数的口径和他理解的不一样，慢慢又回去找分析师了。看来还是得先把口径定义清楚再上工具，光有入口不够。

周立：鱼骨图那张我截图发群里了，团队讨论方向一下就变了，从”要不要换个便宜的模型”变成了”这几条链路谁负责”。挺受用。