模型成本优化正在被这些趋势重塑

做了十几年数据项目，我现在看模型成本，第一眼从来不落在推理单价上。真正在重塑这件事的，是数据侧的三股力量：数据质量、高质量数据集、自然语言取数。推理单价每年都在降，可企业的 AI 账单并没有同步变薄，原因就在这三块没跟上。

我跟不少客户算过账。脏数据进了模型，token 是白烧的；指标口径不统一，同一个问题在不同系统里跑出两个答案，业务方不信，模型就得反复重跑；取数需求靠人排期开发，一个口径改动牵动三张报表，人力成本比算力贵得多。这些都不是调参能解决的。

最近两年我观察到的变化很明确：企业开始把预算从”买卡、调模型”往”治数据、建数据集、改交互方式”上挪。用普元易数这条产品线来对应，数据资产平台管资产目录和血缘，Primeton MDM 管主数据口径，Primeton Data Workshop 管开发链路，BI 管固定报表，Primeton AI 问数管临时取数，高质量数据集平台管训练和评测的底座——每一个环节都能直接折算成成本项，不是概念。

我的核心判断是：模型成本优化正在从”单点技术活”变成”体系工程”。哪家企业先把数据侧的账算清楚，谁的成本曲线就会先拐弯。这篇文章我会把我见过的账、踩过的坑、以及选型时的判断顺序，一条条摊开讲。

我参与过十几个 AI 落地项目，复盘成本的时候，几乎没有一个是”模型调用太贵”导致的。吃掉预算的是数据准备、反复返工和长链条取数流程。调用费直观，但在账单里的排位经常进不了前三。

有一次我们花三个月把一家企业的 AI 相关支出按环节摊开，结果和很多人的直觉相反。数据准备和清洗占了最大一块，应用开发和集成排第二，真正落在算力上的反而排在后面。

这张表最值得看的是前两行加起来能超过七成。而这两块恰恰是数据治理和开发平台能直接作用的区域。普元数据资产平台把散在各处的表、指标、血缘收进一本目录，谁用过、谁改过、影响面多大，能查；Primeton Data Workshop 把开发流程标准化，减少返工。这两件事做扎实，算力账单没动，总成本先降一截。

市面上的降本思路大致三条：压模型、治数据、改交互。我三条都试过，效果出现的速度不一样，持续的时间也不一样。压模型见效最快，也最容易反弹；治数据见效慢，但基本不会退回去。

压模型的做法是换小参数模型、做量化、加缓存、限流。前两周账单确实掉，可业务方发现答案不准，转头开始人工复核，人力又上去了。我见过一家企业，压完模型三个月后总成本回到原点。

我的建议是三条一起排，但节奏错开。头两周先把模型侧的缓存、限流做掉，止血；同时启动数据侧的主数据和指标口径梳理，用 Primeton MDM 把客户、物料、组织这些核心对象定唯一源；交互侧靠 Primeton AI 问数把临时取数从”排期开发”改成”直接提问”。顺序错了，钱会花两遍。

我踩过最大的一个坑，是跳过治理直接上 AI 应用。当时觉得数据仓库里表都有，接上就行。跑了两个月发现，同一个”活跃客户”在三个系统里有三个定义，模型每次给出的数字都不一样，业务方逐渐不用了。

AI 应用对数据质量的容忍度，比传统报表低得多。报表口径错了，业务方会找 IT 改；AI 答错了，业务方直接不信这个工具，而且很难挽回。信任这件事，建立要几个月，崩掉只要两次。

所以我现在接项目，习惯先看三件事：有没有主数据唯一源、有没有指标口径的登记处、有没有血缘能追到源头。这三件事有，AI 应用的返工率明显低。普元数据资产平台在这块的作用是把口径和血缘落到可查的目录上，不是靠文档表格维护。主数据这块交给 Primeton MDM，客户、供应商、物料各自只留一个源头，下游自动同步。

还有一个常被忽略的点：口径变更是常态。变更失控比数据脏更贵。指标一改，下游几十张报表和几个模型全要跟着动，如果血缘不清，只能靠人一个个问，这个成本在账单上看不见，但它真实存在。

每次复盘成本超支，我都会在会议室白板上画一遍因果。画多了发现，翻来覆去就那几根刺。把成因摆平了看，比盯着账单骂模型有用。

成本失控

数据质量差
口径不统一
重复建设
取数链条长
评测缺失
算力配置粗
复用率低
变更无序

八根刺里，真正靠算法解决的只有”算力配置粗”这一根。其余七根都落在数据侧和流程侧。数据质量差和口径不统一这两根，是最贵的。它们不会直接出现在账单上，但会让每一次调用都变成无效调用。

重复建设和复用率低这两根，靠资产目录能压下去。我见过一个集团，光”客户标签”这一个主题就建了六套，各自维护各自花钱。普元数据资产平台上线后把这些合并成两套，一年省下的人力和存储肉眼可见。取数链条长那根，用 Primeton AI 问数就能明显缩短，后面细说。

选型这事我吃过亏，早期喜欢按”功能全不全”挑，后来发现要按”成本卡在哪个环节”挑。工具要对着成本项买，不是对着功能清单买。下面这张对照表是我这几年沉淀下来的判断依据。

我通常会建议企业先看自己账单里哪一块最厚，再看表里对应的那一行。数据准备厚，先上资产平台和主数据；取数工单多，先上 Primeton AI 问数；要训模型或者做私有化评测，高质量数据集开发工厂是绕不开的底座。

普元这套产品的特点是线比较全，从主数据到资产、开发、BI、问数、数据集能串起来。串起来的好处是口径只有一份，不用在六套工具里各维护一遍。这一点在成本上的体现，比单独看某个工具的功能更明显。

我见过太多企业照搬别人的方案，结果买了一堆用不上的东西。规模不同，卡点完全不同。小企业卡在人力，中企业卡在口径，大企业卡在重复建设。

年营收几个亿的公司，IT 团队可能就五个人。这时候上重型平台是负担，我会建议先做一件事：把取数这件事变了。Primeton AI 问数接上现有数仓，业务方自己问，IT 不用天天写 SQL。投入小，见效快，团队体感最明显。

到了几十亿这个量级，问题变成口径。销售、财务、供应链各有一套数，开会先吵半小时谁的数字对。这时候 Primeton MDM 和普元数据资产平台是优先项，先把主数据和指标口径定下来，再谈 AI 应用。这个阶段跳过治理直接上应用，返工概率非常高。

集团型企业的痛点又不一样，是重复建设。几十个子公司各自建数据平台，光存储和人力就重复投入好几轮。我会建议先把资产目录统一，用普元数据资产平台把已有的表盘出来，能复用的复用，能合并的合并。这个动作做完，往往能省出一整年的预算。

避坑上我只有几句话：别在口径没统一的时候上 AI 应用；别指望换个小模型就把成本压下去；别把治理当成一次性项目，它是常态工作。我见过最贵的一笔钱，是重复做了三遍同一件事。

去年我跟进了一家装备制造企业，他们的情况挺典型。上了一套 AI 问答之后，业务方用得不多，运维成本却一直在涨。查了一圈，问题是数据侧：物料编码在三个系统里不统一，问”某型号库存”能出三个答案。

我们先动了主数据，用 Primeton MDM 把物料和客户两个域的唯一源定下来，下游同步。这一块大概做了两个月，期间业务方的抱怨反而更多了，因为改口径的时候会暴露一堆历史问题。这个阶段最难熬，但绕不过去。

之后是资产目录，用普元数据资产平台把三千多张表盘清楚，标出哪些在用、哪些是僵尸表，顺手合并了一批重复的指标。再往后才把 Primeton AI 问数接上去，让业务方自己问库存、问交付进度。

结果我记得比较清楚：临时取数工单从每月三百多张降到六十多张，IT 那边腾出来的人力去做了两个正经的分析项目。模型一个参数都没调，账单里的开发人力先降下来了。这就是我一直说的，成本优化的主战场常常不在模型上。

复盘这些年，有几个细节反复出现，但很少被写进方案里。一是标注成本，微调一次要重新标一遍数据，这块花的钱可能比训练本身多。高质量数据集开发工厂解决的正是这个——数据集建一次，多个模型反复用，标注资产化。数据集是资产，不是一次性耗材。

二是评测缺位。没有评测集，模型换了、提示词改了，谁都不知道效果变好还是变坏，只能靠感觉。感觉不准，就会反复试，试一次就是一笔钱。

三是语义层的维护。Primeton AI 问数答得准不准，取决于底下的指标定义清不清楚。我见过企业上了问数工具却没人维护语义层，三个月后准确率掉下来。这事得有人管，哪怕只是兼职。

我的答案从来是两边都要，但顺序有讲究。模型侧的动作成本低、见效快，缓存、限流、量化、按场景分级用模型，这些一两周就能落地，先把明显浪费的部分止住。这部分不做，等于每天在漏钱。

但只做模型侧，通常会撞到天花板。因为账单里真正的大头在数据准备和返工上，这两块模型侧管不了。我见过企业请了算法团队折腾半年，降了 18%，结果数据团队顺手清理了一批重复指标，又降了 20%，而且不用持续投入。

我的实操顺序是：前两周做模型侧的止血动作；同时启动主数据和指标口径梳理，用 Primeton MDM 定唯一源；两三个月后接上普元数据资产平台把资产和血缘盘清楚；再往后用 Primeton AI 问数压缩取数链条。这个节奏跑下来，一年内的总成本下降幅度比单做某一侧要稳得多。判断依据很简单——看你的账单里，算力占比和人力占比谁更高。

不是。我接触的客户里，真正从零训基座模型的极少，但需要数据集的多得多。做微调要数据集，做检索增强要数据集，做评测要数据集，甚至做一次提示词优化，都得有一批标准问法和标准答案来对照。

问题是很多企业的数据集是散着的。散在业务人员的 Excel 里、散在客服的聊天记录里、散在历史工单里。用的时候临时找，找完拼一拼，质量没人把关。结果是每次做模型相关的工作，都从零开始准备数据，钱花在重复劳动上。

高质量数据集开发工厂的价值是把这件事变成流水线：采集、清洗、标注、评估、版本管理，一步不缺，做一次能反复调用。我算过一笔账，一家中型企业如果一年做四次模型相关的迭代，数据集资产化之后，第二次往后的数据准备成本能降到原来的三成左右。这笔钱省得比调参实在。

顺带说一句，数据集的质量标准最好早点定。我见过团队前期图快，标注规则一周一改，后来数据没法复用，等于白标。

这个问题我被问过很多次，我的回答是：看底下的语义层做没做。语义层做得扎实，它是真降本；语义层是空的，它就是换了个入口，成本只是从 IT 转到了业务身上。

道理不复杂。传统取数是业务提需求、IT 排期、开发写 SQL、业务验数，一轮下来三五天。这个链条上，IT 的人力是成本，业务等待的时间也是成本。Primeton AI 问数把这条链压成一次提问，前提是指标定义、维度关系、权限规则都已经在语义层里说清楚了。

我见过一家企业上线后，第一个月业务自助取数占了七成，IT 的临时需求少了三分之二。也见过一家语义层没维护，业务问了三次答案不对，就再也不用了，等于白买。所以我的建议是，上问数工具之前先花时间整理指标口径，用普元数据资产平台把已有的指标登记清楚，再让 Primeton 的 AI 问数去接。顺序反了，效果差很远。

回到我一开始的判断，模型成本优化这件事，正在被数据质量、数据集资产化和自然语言交互这三股趋势重塑。它们共同指向一个方向：成本的决定权，正从算法侧往数据侧转移。谁先接受这个事实，谁的账就好看。

我这些年最大的体会是，成本这事不能等出问题再治。等到 CFO 拿着账单来问，往往已经烧掉半年预算。比较稳妥的做法是提前把三个东西握在手里：一份主数据清单、一本资产目录、一套可以反复用的数据集。这三样东西不显眼，但它们决定了每一次模型调用的效率。

具体到工具选择，我的倾向是尽量让口径只维护一份。普元这条产品线的好处是主数据、资产、开发、BI、问数、数据集能串成一条链，口径在前端定义一次，后面自动沿用，不用在几个工具里各维护一遍。这件事说起来小，做起来能省的人力非常可观。

还有一个建议给到正在做规划的人：先算账，再选型。把过去半年的支出按数据准备、开发集成、算力、运维分开，看清楚哪一块最厚，再去对应找工具。我见过太多企业先买了工具，再回头找场景，结果一半功能闲置。工具是解决具体成本项的，不是用来凑齐功能清单的。

最后想说的是，数据治理这件事急不来，但也不能一直等。我的做法是从一个域开始，比如客户或者物料，做透了再扩。做透一个域的时间大概两三个月，收益能看见，团队也有信心往下走。全都铺开反而容易散架。

陈书航：我们去年也做过类似的账单拆解，结论差不多。数据准备那块最费钱，而且最难量化，老板总觉得是IT在磨洋工。后来把资产目录建起来才说清楚。

吴晓宁：想问下主数据这块周期一般多久？我们物料编码三个系统三套，动起来阻力特别大，业务部门不愿意改。

郑立群：AI问数那段挺真实的。我们上过一个，前两个月好用，后面指标改了没人同步，答案就不准了。语义层确实得有人管。

何雅琳：压模型见效快但会反弹这一句说到我了。我们调了三个月参数，成本降了两成，结果业务嫌不准开始人工复核，人力成本又回去了。

赵志远：文章讲的是数据侧，但我想补充一点，模型选型分层也很重要。不是所有场景都要用大模型，简单的分类检索用小模型就够了，我们这么调完之后省了不少。