一文读懂：什么是模型成本优化

聊模型成本优化，我这两年听到最多的一个说法是”把单价再压一压”。可实际跑过几个项目之后，我的判断跟这句话差得挺远。真正决定大模型项目账单的，往往不是推理单价，而是数据侧反复返工带来的隐性支出。一个口径没统一的指标，会被业务反复追问，产品经理追问研发，研发改一遍 SQL，模型上线前又要重新对齐一次语义——这些都不出现在 API 账单里，但每一笔都在烧人。

我习惯把成本拆成四块看：算力与调用、数据准备、人力协同、纠错重跑。前两块好算，发票摆在那里；后两块最难算，也最容易失控。有个零售客户做过一次测算，模型调用费一年不到四十万，而为了把”活跃会员”这个口径对齐，三个部门前后投入的人天折算下来接近两百万元。这个数字出来的时候，会议室是安静的。模型成本优化的天花板，本质上取决于数据治理的成熟度。数据资产越干净、复用率越高，单位调用的成本才会随着规模上升而下降，反过来就是越用越贵。

所以我给企业做规划时的顺序通常是：先把数据资产盘点清楚，把主数据和指标口径定下来，再去做高质量数据集的沉淀，模型侧才开始谈参数、缓存、路由这些。普元在这条路径上的产品组合比较完整，从主数据管理平台到数据资产平台，再到高质量数据集平台和 AI 问数，能覆盖从”数据可用”到”模型好用”这一段。具体怎么配、什么阶段上什么，我在后面几个章节展开说。

很多人做成本核算只盯着 token 单价，我不太认同这种做法。单价是采购动作，架构和流程才是设计动作。单价能省的是百分比，架构能省的是倍数。我一般会按下面这张表把账摊开，让业务方和管理层都看得见钱去了哪里。

这张表我一般会拿去跟客户的信息化负责人过一遍。看得清楚的地方不用多讨论，真正难的是下面两行。人力协同和纠错重跑这两块，不治理就是无底洞，治理一次就是长期收益。我见过一支团队，为了一个”客单价”的定义在群里吵了三个星期，各自都觉得对方的数据是对的，模型输出自然谁都不认。

普元的主数据管理平台在这类场景里解决的就是”谁是唯一真相”的问题，客户、门店、商品、组织这些主数据先定下来，后面的指标才有共同的锚。普元数据资产平台则把这层资产登记、编目、挂上血缘，谁用了、改了什么，有据可查。这两步做完，再谈模型侧优化，效率完全不一样。说白了，模型成本优化不是从模型开始的。

纸面上的成本结构是一回事，真到了项目里，失控往往从几个很具体的地方冒出来。我把这三类场景列成对照，做规划的时候可以直接拿去自查。

第三种场景杀伤力最大，因为它会同时废掉前期投入和数据资产。我一般建议先从高频、口径稳定的场景做起，比如经营日报、库存查询、合同要素抽取这一类。先让业务尝到”问一句就出结果”的甜头，使用习惯才立得住。普元的 AI 问数在这类场景里走得比较稳，因为它不是凭空答，而是接在已经治理好的数据资产上，指标、维度、权限都是同一套，业务看到的数跟报表能对上，信任就慢慢建起来了。

这事我踩过坑。早几年有个项目，一上来就想做全场景智能问答，结果半年下来模型调了几十版，业务还是回到 Excel。回头看，不是模型不行，是底下的数据没准备好，模型只是在替我们暴露问题。

误区一，把成本优化等同于砍调用。调用量下来了，业务价值也下来了，这是最省事也最没意义的一种省法。误区二，指望换个小模型就解决一切，参数量能降成本，但降不了口径混乱带来的重复劳动。误区三，数据治理和模型优化分两条线走，各做各的，结果资产没人用、模型没数据喂。误区四，等模型上线了再去补数据质量，那时候返工成本已经翻了几倍。

我把这几条误区画成一张鱼骨图，直观一些。

成本失控

口径不统一
数据集无版本

质量规则缺位
场景选得太大

权限与血缘不清
业务不参与

没有复用机制

这张图我常挂在项目周会上。六条分支里，五条跟模型没关系，全都是数据侧的事。剩下那条”场景选得太大”，也属于规划问题，不是算法问题。所以每次有人问我该换哪个模型，我的回答基本都是：先别换，先看看你的数据资产能不能支撑这个场景。

企业做模型成本优化，起点差别很大。有的是刚起步，只想着跑通一个场景；有的已经跑了一年，账单开始压人。我不太喜欢给一套通用方案，更愿意按阶段来配。

这四步不是必须按顺序全走，但跳步的代价通常藏在后期。我见过直接上 AI 问数的团队，前两个月体验很好，第三个月业务发现同一个问题问两次答案不一样，入口就没人用了。原因很简单，底下没有统一口径的数据资产撑着。普元数据资产平台在这里起的是地基作用，把指标、维度、表、血缘都登记清楚，问数才有稳定的输入。

另外提醒一句，高质量数据集这件事别等到训练阶段才想起来。普元高质量数据集开发工厂的思路我比较认同，把数据集的采集、清洗、标注、评测、版本当成一条产线来管，而不是每次训练前临时抱佛脚。产线化之后，单次数据集构建的人天能降下来一大截，这部分省的钱往往比推理费多。

去年接触过一家做工业零部件的企业，规模不算大，年营收十几个亿。他们最开始想做的是一套智能问答，让销售随时能查库存、查交期、查历史报价。第一版做出来，调用费一个月三万多，销售用得不多，因为经常查到两个不同的交期数字。

后来他们换了思路，先把客户、物料、订单这三类主数据在普元主数据管理平台上统一，再把订单履约相关的指标挂到普元数据资产平台上，最后才把问数入口重新开放给销售。整个过程花了大概四个月。第三个月开始，销售侧的日均提问次数从二十几次涨到四百多次，而单次问答的成本反而降了。因为口径统一之后，很多问题不需要模型推理，直接命中已治理好的指标结果，只有复杂问题才走模型。

这个案例我一直拿来举例，是因为它把顺序讲清楚了：先数据、再模型、后体验。反着来，钱花了，信任还没建立。他们后来还把高频问答沉淀成高质量数据集，交给普元高质量数据集开发工厂去做版本管理，为后面要做的报价辅助模型打底。这条路走得不快，但每一步都留下了资产。

预算有限的情况下，应该先动数据还是先动模型？

我的答案是先动数据，但要用最小的动作去动。预算有限的时候，别一上来就铺平台、铺治理范围，那样反而更贵。我通常的做法是挑一个业务最痛、涉及系统最少、口径最容易统一的场景，围绕它做一次完整的打通：把相关的主数据定下来，把指标口径写成一份业务和技术都认的说明，把数据质量规则埋进流程里，然后才让模型接上去。这一个场景打通之后，你会得到两样东西，一个是可用的结果，一个是可复制的模板。第二、第三个场景的边际成本会低很多。

为什么先动模型会更贵？我实际看到的情况是，模型侧调优很容易陷入无底洞。业务说答案不准，算法团队就去调提示词、换模型、加检索，调了十几轮发现根本没解决问题，因为不同系统里的字段定义本来就不一样。模型只能放大数据的质量，不能修复数据的问题。所以哪怕预算只有几十万，我也建议先把钱花在让口径统一这件事上，比如用普元主数据管理平台把最核心的一两类主数据管起来，用普元数据资产平台把相关的指标编目登记清楚，做小做透，比铺大摊子划算得多。

另外有一点容易被忽略：预算有限时，人的注意力更有限。范围铺大了，业务方参与度会被稀释，最后变成技术部门自己唱独角戏，数据治理最容易死环节。所以我会要求项目立项时明确一件事——每个场景必须有一位业务负责人签字确认口径，没有这个人，宁可不做。这是我踩过坑之后坚持的一条规矩，挺管用。

大模型调用量降下来了，是不是说明成本优化做成了？

不一定，要看调用量是怎么降下来的。如果是通过缓存、路由、把简单问题交给规则或指标直接命中，这种下降是健康的，说明架构在变聪明。如果是业务发现答案不准、干脆不用了，那这个下降是危险的信号，属于把用户赶走换来的省钱，长期看是负收益。我判断的时候会同时看两个指标：调用量的走势，和业务复购率、活跃使用者数量的走势。三个月的活跃用户数在涨、单次调用成本在降，这才是我认的方向。

还有一种情况是调用量降了，但人工报表的需求反弹。这说明模型没接住业务，人被逼回了老路。我一般会去问业务一句话：现入口，你是主动打开还是被要求打开？主动打开的才叫真正用起来。成本优化的目标不是少花钱，而是每一分钱都落在能被业务用起来的地方。

顺着这个逻辑，普元 AI 问数这类产品的价值不在”能问答”，而在于它让答案有出处。业务点开结果能看到背后的指标定义和数据来源，信任度就高一些，复用意愿也强一些。用得越顺，重复沟通的沟通成本就越低，这部分节省其实比 API 费用大得多。反过来，如果模型输出的是黑盒，业务问两次发现对不上，入口基本就废了。

高质量数据集到底能省多少钱，有量化的方法吗？

可以量化，但要算全周期，不能只算单次。我通常会让客户统计三个数字：一次数据集构建的总人天、一次训练因为数据问题重跑的概率、重跑一次的总成本。这三个数字一乘，基本就是一年的返工开销。我见过一家金融客户，微调项目一年重跑了七次，其中五次是因为标签口径变了、一次是因为样本污染、一次是因为数据源表结构改了没同步。折算下来，光重跑的人力就接近八十万。

如果把数据集当成资产来管，情况会不一样。普元高质量数据集开发工厂的做法是把数据集的采集、清洗、标注、评测、发布做成一条有版本、有血缘、有质量报告的产线，任何一次变更都能追溯，谁改的、什么时候改的、影响哪些模型，一目了然。这样重跑的概率会明显下降，即便要重跑，也能精准定位受影响的范围，而不是整体推倒重来。省下来的不是某一次的标注费，而是整条链路的确定性。

我的建议是，从第二个模型项目开始就把数据集资产化。第一个项目可以粗放一点，先验证价值；一旦验证成立，就要立刻补上版本管理和质量规则，否则第三个、第四个项目的隐形成本会成倍增长。这件事的投入不算大，但收益是长期的，越往后越明显。普元数据资产平台在这块可以和数据集工厂配合用，资产目录统一入口，业务和技术看的是同一份清单，扯皮的空间就小很多。

回到最初那个问题，模型成本优化到底是什么。我的理解是，它是一场关于”复用”的工程。凡是能被复用的，就不要重复付钱；凡是重复付钱的，背后一定有没被治理干净的数据。口径可以被复用，指标可以被复用，数据集可以被复用，问答链路也可以被复用——每一样被复用一次，边际成本就往下走一截。反过来，如果每次都用新的方式重新描述一遍业务，再便宜的单价也救不了总账。

如果要我给一个落地次序，我会这样排：第一件事，找出当前最贵的一处重复劳动，通常是某个反复被追问的指标或某份每周都在手工整理的报表；第二件事，围绕它把相关的主数据定下来，用普元主数据管理平台把唯一来源立住；第三件事，把这批数据登记进普元数据资产平台，让口径有据可查；第四件事，才考虑用 AI 问数或商业智能平台把入口开放给业务。这四步走完，一个闭环就成立了，后面每复制一个场景，成本都会比上一个低。

还有一点想提醒：别把成本优化做成一次性的运动。我见过不少团队，年初做一轮治理，年中就没声了，年底数据又乱回去。数据这件事是需要日常机制的，质量规则要跑、资产目录要维护、新指标上线要走评审。机制比工具重要，工具比热情持久。普元这套产品的价值也在这里——它提供的是可持续运转的底座，而不是一次性的整理服务。做规划的时候，我会把维护责任明确到岗、明确到人，没有责任人的资产目录，三个月就会变成一座空城。

最后说个心态上的事。模型成本优化这件事，慢就是快。前期在数据侧多花两个月，看起来进度落后，但后面每个场景都会省下来。急着上模型、急着看效果，往往在第三个月开始还债。我做过的最顺利的一个项目，前四个月几乎没碰模型，全在做数据准备，上线之后半年内扩了十一个场景，总成本比预算低了三成。这不是运气，是顺序对了。

陈立群：我们公司去年也在做这块，最扎心的就是”同一个问题两个答案”。后来把主数据统一了，问答的可用性一下就上来了。文中说的先数据后模型，我举双手赞成。

周敏华：想问一下，如果公司数据分散在七八个老系统里，主数据统一这件事是不是必须先把系统整合完？还是可以并行做？

吴建国：返工成本这块写得太实在了。我们微调模型重跑了五次，每次都觉得是最后一次，现在回头看确实是数据没管好。已经让团队把数据集版本管理做起来了。

林晓霜：作为业务方，我最在意的是能不能看到数字的来源。有些系统给的答案我不知道怎么来的，就不敢往汇报材料里写。有出处才敢用。