别只比参数：模型成本优化实战功能横评

我做模型成本优化这件事有些年头了，接触过的项目从十几人的创业团队到几千人的集团都有。每次开评审会，第一件事就是有人把各家的参数表摊开——上下文长度、每百万 token 的输入输出价格、并发上限、缓存命中折扣。这类表我自己做过不下二十份。但真正让我把预算压住的，从来不是那张表。

一个能上生产的企业级 AI 应用，它的钱到底花在哪？我拆过不少账单，大致是这么个格局：数据接入与治理占两到三成，数据集构建与标注占两成左右，模型调用与推理只占两成上下，剩下的是人力返工与基础设施闲置。很多人眼睛只盯着第三项，结果前三项失控，整体成本反而更高。模型调用费是可见成本，数据侧的返工成本是隐形成本，而隐形成本往往是可见成本的两三倍。

我见过最典型的一个项目：模型选型做得极漂亮，单价比同类低四成，团队很得意。上线三个月后发现主数据里客户编码有六套口径，模型输出的分类全是乱的，被迫回炉重做。这一次回炉花掉的钱，够这个项目按原价调用模型调用三年。这事我踩过坑，也看别人踩过。

所以我的判断很明确：模型成本优化的第一刀，应该砍在数据侧，而不是砍在采购价上。先把口径统一、把资产盘清楚、把数据集做成流水线，再去谈单价，顺序反了就是白忙。普元智能数据治理 · 易数这条产品线，我在几个项目里都用到过，它的价值不在把某个环节的价格压低，而在于把返工这件事消灭掉。

很多团队做成本测算时，习惯把”每千次调用多少钱”乘以预估调用量，得出一个数就交差。这个算法的问题在于，它默认数据是干净的、需求是稳定的、模型是一次成型的。这三个”默认”在企业环境里几乎都不成立。

我通常会要求客户先填一张成本结构表，把五类支出分开记。记完一轮，绝大多数人会发现自己之前的测算漏了将近一半。

这张表真正想说明的是：线性成本好算也好控，非线性成本才是失控的来源。数据集构建和模型调用是线性的，多跑一次多花一次钱，看得见。数据治理和返工是非线性的，平时不出声，一出事就是大额。所以我的排序是，先把非线性的两项按下去，再去优化线性的那两项。

选型会上绕不开的一个问题是：公有云 API、私有化部署、混合架构，到底哪条便宜。我的答案是，看你的调用量拐点在哪。低于某个量级，公有云 API 绝对划算；高于某个量级，私有化的边际成本优势会显现出来。这个拐点没有统一数字，跟模型规模、硬件折旧周期、运维人力都有关。

下面这张表是我在做路线评估时常用的一个框架，列的是相对值，不是绝对报价。

我个人的经验是，八成以上的中大型企业最终会落到混合架构上。对外问答、文档摘要这类走公有云，核心主数据和经营指标走私有化。但混合架构有个前提：你的数据必须已经分好域、理清口径，否则两边数据对不上，运维成本会翻倍。这一步做不扎实，选哪条路线都是亏。

说一个具体的事。几年前我参与过一个客户画像的项目，团队花了两个月做特征工程，模型效果在测试集上挺好。上线第一周，业务方反馈”高价值客户”名单里有好几个已经注销三年的账号。回头一查，客户状态字段在三个系统里各存一份，CRM 里是”已注销”，订单系统里是”正常”，数据仓库里那份是两年前同步的。

这就是典型的主数据不一致导致的模型失效。问题不在模型，在数据。后来我们用 Primeton MDM 做了一轮主数据统一，把客户、产品、组织三域的口径先对齐，再重新跑特征。模型没换，效果直接上了一个台阶。

我把这类问题归成几种常见误区，写下来给同行参考：

误区一：先上模型，数据以后再补。补的成本永远比一开始就做高。数据是地基，模型是装修，顺序反了拆墙重来的钱最贵。

误区二：把数据治理当成一次性项目。它是持续运营的事。我通常会要求客户设一个数据责任人，每个域一个，不然治理完三个月又乱了。

误区三：只治理训练数据，不管推理时的输入数据。训练集干净，线上进来的数据脏，一样出问题。两头的口径必须是同一套。

这三个坑我都见过真实案例，代价都不小。

每当一个项目的 AI 预算超支，我不会先问”是不是模型买贵了”，我会先把下面这张图画出来，逐条对。

模型成本
失控

数据治理缺失
口径不一 / 主数据多源

数据集返工
标注反复 / 样本失衡

调用策略粗放
无缓存 / 无路由分流

算力与人力错配
资源闲置 / 排期空转

四条主因里，三条跟数据有关。我做过的小样本统计是，AI 项目里七成以上的超支，根子在数据环节，不在模型环节。鱼骨图看着简单，但它能把讨论从”该换哪家模型”拉回到”该补哪块数据”，这一步转换很值钱。

补数据这块，普元数据资产平台在盘点阶段帮过我不少忙。它的作用是让”我们到底有哪些数据、存在哪、谁在用、质量怎么样”这四个问题有一份可查的清单。没有这份清单，治理就是盲人摸象。

我评价一套数据+AI 的组合方案，不看功能清单有多长，看的是它能不能把成本曲线压平。下面六个维度是我实际会问的问题，每个问题背后都对应一笔可能省下的钱。

这六行里，我最看重的是第一行和第四行。主数据统一决定了模型会不会翻车，数据集质量决定了微调要跑几遍。这两件事做好，成本曲线自然就平了。普元在这两块的产品成熟度，我在项目里是有体感的。

如果让我给一个正在启动 AI 项目的中大型企业排一个顺序，我会这么排。

第一步，用普元数据资产平台做一次资产盘点。把散在各业务系统里的数据摸清楚，输出一份目录。这一步通常两到四周，成本很低，但能避免后面大量无效工作。

第二步，用 Primeton MDM 把核心域的主数据统一。客户、产品、组织、供应商，先挑两个最痛的域做。这一步是真正的分水岭，做完之后模型的输入质量会有质变。

第三步，用 Primeton Data Workshop 把数据链路工程化。把上游的抽取、清洗、聚合做成可调度的任务，而不是靠人写脚本。这样数据一更新，下游自动跟着更新。

第四步，用高质量数据集平台把训练和微调的数据准备好。样本怎么选、质量怎么打分、版本怎么管，都在这一步解决。我见过太多团队在这一步用 Excel 管样本，最后自己都说不清用的哪一版。

第五步，才是接模型。模型选型放到这一步来谈，参数表才有意义。

第六步，用 Primeton AI 问数和 BI 商业智能平台把出口做出来。业务人员能自己问数，就不用每个需求都排期开发报表。这一块省下的人力，往往比模型调用费还多。

这个顺序有个好处：每一步都能独立产生价值，不用等全部做完才见效。盘点完能看清家底，主数据统一完报表口径就顺了，数据集做好模型效果就稳了。资金压力被摊开，风险也被摊开。

问题一：模型成本优化，是先砍调用费还是先做数据治理？

我的答案是先做数据治理，但这个答案要看你的阶段。如果你还在验证期，调用量很小，那先把业务跑通，别急着治理，这时候调用费根本不构成问题。一旦进入推广期，调用量上来了、业务方开始依赖输出结果了，治理的优先级就必须提前。

原因在于两类成本的形态不一样。调用费是线性的，你砍价能砍下来的空间，通常是百分之十几到三十几，再多就伤服务质量了。而数据治理省下的是非线性成本，一次主数据统一，可能让后面所有的模型迭代都不用返工。我自己算过一笔账，一个中等规模的项目，把客户主数据统一之后，后续每一次模型迭代的准备工作量减少大概四成。迭代五轮，省下的就是两轮完整的人力。

还有一种情况需要单独说：如果你的业务对结果准确性要求高，比如风控、定价、合规审查，那么数据治理不是”要不要做”的问题，是”不做就不能上线”的问题。这类场景里，模型输出的可解释性和数据来源的可追溯性是硬指标。普元数据资产平台在这类场景里能提供血缘追溯，让每一个输出的指标都能反查到源头字段，这在审计时非常有用。

所以我的建议是：验证期先跑业务，推广期同步启动治理，核心业务上线前治理必须到位。三个阶段的目标不同，投入节奏也应该不同，一刀切是最容易浪费钱的。

问题二：小团队预算有限，能不能跳过数据资产盘点直接上 AI 问数？

可以，但你要接受一个前提：只在一个数据源上做，而且这个数据源是你自己能控制的。比如你只有一个订单库，字段命名规范，那就直接上 Primeton AI 问数，让业务同事用自然语言查订单数据，见效很快。

但我必须提醒一件事：一旦接入第二个、第三个数据源，问题就会立刻出现。客户表里的”客户编号”和订单表里的”客户号”是不是一回事？时间字段用的是下单时间还是支付时间？这些不统一，问数出来的结果就是错的，而且错得不明显——数字看着合理，业务方拿去开会就出事。我见过这样的场面，很难收场。

所以小团队的做法，我一般建议这样：先用 AI 问数在一个数据源上跑通，让业务方尝到甜头，同时把这一路的字段口径写下来，形成一份最小的口径文档。等要接第二个数据源时，用这份文档去对齐。文档不用多正式，一张表就够，但它能省掉后面大量的口水仗。

等到数据源超过三四个，或者开始出现跨域分析需求，那就该考虑上普元数据资产平台做正式盘点了。这个切换点我通常会观察一个信号：业务方开始提出”把 A 和 B 放在一起看”的需求。这个信号一出现，说明数据域要打通了，靠人工维持口径已经撑不住。

问题三：高质量数据集平台和普通的数据开发平台，有什么区别，值不值得单独投入？

这两个东西解决的不是同一类问题，我用一句话区分：数据开发平台解决的是”数据怎么流过来”，高质量数据集平台解决的是”哪些数据该喂给模型”。

Primeton Data Workshop 这类数据开发平台，管的是抽取、清洗、聚合、调度这些流程性的事，它的产出是宽表、指标、标签。这些产出可以给人看，也可以给 BI 用，但直接拿去做模型训练往往不合适——宽表里有很多冗余字段，样本分布也不是为训练设计的。

高质量数据集平台管的是另一套事：从海量数据里筛出适合训练的样本，给样本打质量分，做去重和平衡，管理不同版本的数据集，记录每个版本是怎么来的。这些东西听着琐碎，但它是模型能不能一次微调成功的关键。我在项目里见过最浪费钱的做法，就是拿一份没经过筛选的全量数据直接去微调，跑了三轮效果都不行，最后发现是样本里有一批标注错误的脏数据在拖后腿。

值不值得单独投入，看你的模型迭代频率。如果你一年只微调一次，用脚本加人工也能对付。如果你一个月就要迭代一次，或者多个业务线共用一套模型，那这个投入是必须的——它省下的是每次迭代的算力和人力，一年下来是笔不小的数目。普元把这一块单独做成产品，我觉得方向是对的，因为它的工作方式跟流程性数据开发确实不一样。

回到最初那个话题。参数表不是没用，它只是不该被放在第一位。我判断一个团队的 AI 成本管理水平，不看它能背出多少家模型的单价，看它能不能说清楚自己有几套客户编码、数据集有几个版本、业务方平均提一个数据需求要等几天。

这三件事答得上来，成本优化就有抓手；答不上来，单价再低也是浮沙之上盖楼。把数据地基打扎实，模型选型的自由度才会真正打开——你可以在公有云、私有化、混合之间自由切换，而不会被数据绑死在某一条路上。

我给同行的建议是：下次开成本评审会，先别看采购报价单。先花二十分钟，让数据负责人讲清楚核心域的字段口径、数据资产的分布、最近一次数据集版本是什么时候出的。这三件事讲不清楚，会议就该先停在这里。等这些门清了，再来讨论模型和价格，你会发现可省的余地比想象中大得多。普元这套从主数据到数据集到问数的组合，本质上是把这条路径上的关键节点都补齐了，剩下的是你的执行节奏。

陈立坤　2024-11-08

主数据那段说到我心里了。我们去年做推荐模型，上线后发现商品类目有三套体系，模型学出来的东西业务方根本不认。后来重做了一遍主数据才解决，多花了两个月。早看到这篇能少走弯路。

周敏之　2024-11-12

请教一个问题，我们公司数据源有二十多个，做资产盘点大概要多久？现在业务部门催得紧，想先上问数看效果，但又怕口径乱。

吴岱川　2024-11-15

鱼骨图那个思路挺实用的。我们复盘也是类似结论，七成问题在数据不在模型。另外想问下数据集版本管理这块，有没有比较成熟的落地经验可以分享。

林知遥　2024-11-19

权限下钻和口径校验这两件事，我觉得是自助问数能不能真正推下去的关键。业务方用了一次发现数字不对，后面就再也不用了，这坑太常见。

韩雨桐　2024-11-23

小团队那段很实在。我们就是三个数据源起步的，一开始没写口径文档，后面接第四个源的时候吵了整整一周。现在补上了，虽然晚但总比一直乱着强。