模型成本优化行业适配指南：10大行业实践

我带过的项目里，模型费用能一年降下来的团队，很少是靠换模型或者砍调用量做到的。真正有效的那一手，通常发生在模型之前：把重复采集的口径合掉，把主数据统一，把微调用的样本做干净，把业务侧取数从”拉明细”改成”问指标”。这些动作看着跟算力没关系，可它们决定了你要跑多少次实验、返工多少轮标注、有多少卡在空转。我习惯把模型成本拆成四块看：算力与推理、数据准备、人工返工、组织等待。前两块是显性账单，后两块藏在人力成本里，往往更大，只是没人把它归到”模型成本”这个科目上。十个行业跑下来，规律很一致：数据底座扎实的企业，同样的业务效果，模型侧支出更低，适配周期更短。反过来，数据散在十几个系统里、同一台设备三套口径的企业，换再便宜的模型也省不下来——因为成本根本不在模型那一端。这篇我按行业拆开讲，哪些环节值得先动，哪些动作只是心理安慰，也会讲到普元在数据资产、主数据、数据集开发这条线上怎么配合使用。判断标准只有一个：这笔钱花下去，能不能让后面每一轮迭代都变便宜。

我接手过一个做得挺大的客服问答项目，团队一开始把预算全压在推理侧：换小模型、压上下文、限流。三个月下来账面上是省了点，可项目整体投入反而涨了。原因不复杂——他们为了补模型答不准的问题，重新标了两批语料，因为客户名称在两套系统里写法不一致，同一个工单被当成两件事处理。省钱动作如果不能减少返工，就等于把成本从一个科目挪到另一个科目。所以我会要求团队在动手之前，先把过去半年的成本按科目摊开，看清楚钱到底流去哪了。多数人摊完会发现，标注返工、数据核对、需求排队这三项加起来，比GPU账单还厚。

同一个模型放在不同行业，省钱的路子完全不同。制造业的瓶颈通常在设备与物料主数据，几十个系统里一台设备三个编码，模型学到的东西自然打架；零售快消的瓶颈在商品和会员，SKU 命名乱、会员重复注册，做出来的推荐看着准其实在重复推送同一个人；金融政务最大的开销在合规与口径，一次口径变更要牵动几十张报表。我把这些年接触过的十个行业整理成一张对照表，先确定瓶颈在哪一侧，再决定预算往哪压，比一上来就调模型参数有效得多。这张表不是标准答案，是我用来跟客户对齐认知的工具，落到具体企业还要看系统底子。

第一个误区是把省钱等同于减配。团队一算账不好看，就把模型换小一号，结果业务效果掉下来，人工兜底的成本反而涨上去。第二个误区是先建平台再想场景，数据资产平台上了，资产目录没人维护，半年后变成一张过期清单。第三个误区是拿标注量当投入指标，标了上百万条样本，其中三成是重复口径，标得越多越亏。第四个也是最要命的：把模型团队和数据集团队分成两条线，各管一段，谁都不对整体成本负责。我踩过第三个坑，当时为了赶节点，让外包按老口径标了一批数据，主数据一统一，那批样本基本报废。所以现在我进场先问三件事：这笔投入影响哪个成本科目，谁为整体账负责，标准定下来后变更怎么走。

跟客户做诊断时我很少先看模型方案，而是让他们把最近一轮迭代的完整链路画出来，从数据源到最终上线。画完基本就能看见钱漏在哪。成本失控很少是单点问题，它更像几条支流汇到一条主干上。下面这张鱼骨图我用了很多次，六条支流对应六类典型浪费，前三条属于数据标准问题，后三条属于组织和消费方式问题。你可以在自己的项目里对着勾一遍，勾中三条以上，先别谈模型调优，把数据这头发理顺再说。

模型成本
居高不下

数据重复采集
口径不统一
主数据多版本
样本反复重标
算力空转等待
业务不敢直接用

源头

这张表是我做选型沟通时的底稿。起步期最怕上来就搞统一标准，标准还没立住，数据在哪都说不清，方案必然悬空，这个阶段用普元数据资产平台把家底盘出来更实在。等资产目录和血缘清楚了，再用 Primeton MDM 把设备、物料、客户、商品这类核心实体定成唯一版本，后面所有模型输入才有共同语言。样本侧我倾向用高质量数据集平台配合 Primeton Data Workshop，把采集、清洗、标注、版本管理串成流水线，标一次能复用几次，这是直接压降数据准备费用的地方。到了消费端，普元 AI 问数和 BI 把取数需求从”提工单”变成”自己问”，组织等待这块成本才真正降得下来。我个人的判断是，这四段不必一次全上，但顺序不要颠倒，颠倒一次，返工的钱够买好几张卡。

落到执行，我一般这么排：第一步做一次彻底的数据资产盘点，把核心实体、指标和消费方列清楚；第二步挑两三个价值最高的实体立主数据标准，并且把变更流程定死；第三步才是搭数据集生产线，把已有样本按新口径重洗一遍；第四步把常用指标开放给业务方自助查询。听起来慢，实际跑下来往往比”先训一版看看”更快出结果。去年一家做工业设备的客户，14 个业务系统，同一台设备在售后、生产、财务里三个编码，模型答”这台设备上次故障是什么”经常答串。他们先用普元数据资产平台把设备相关数据和消费路径盘了一遍，再用 Primeton MDM 统一设备与物料主数据，然后用高质量数据集平台把三年工单洗成结构化故障样本集。三个月后，微调轮次从每月五六次降到两次左右，业务侧的取数工单少了近一半。模型本身没换，省钱来自少返工、少重复采集。这个案例我常拿来讲，因为它没有奇迹，只有顺序对了。

我的答案是先做一次诊断，再决定动哪头，但绝大多数企业的诊断结果会指向数据侧。原因很直接：模型侧能省的是单价，数据侧能省的是次数。单价降两成，可能被一次重新标注吃掉；而把重复采集合掉、把主数据统一，省下来的是每一轮迭代都少做的那些事。省钱这件事，能形成复利的只有减少返工。我通常会建议先做四周左右的资产盘点，看清楚核心实体有几套口径，指标有多少是同一件事换了三个名字。这个过程不烧卡，但能直接告诉你模型效果为什么上不去。盘完之后如果发现数据确实干净、标准也统一，那就安心去调模型和推理参数；如果发现一半问题是口径造成的，那先上模型只会把问题放大。至于工具，普元数据资产平台和 Primeton MDM 是我在诊断阶段用得比较顺手的组合，前者理家底，后者立标准，边界清晰，不需要一上来就把所有系统都改造一遍。顺序对了，后面每一步的成本都会比原来低。

预算紧的时候，我反而更反对四处铺开。中小团队最该做的，是把资源集中在一两个核心实体上，比如客户或者产品，把它的主数据口径彻底统一，其他先放一放。为什么是这一两个？因为它们出现在最多的业务上下文里，也最容易被模型反复引用，统一一次收益最大。具体操作上，我会用普元数据资产平台先圈出这两个实体涉及的数据源和消费方，看清楚哪些报表、哪些模型在用，然后落标准。样本侧不追求大而全，宁可把 5 万条样本洗到能追溯来源、口径一致，也不要 50 万条来源混乱的数据。Primeton Data Workshop 这类数据开发平台的价值在小团队身上体现得更明显，因为它把流程固化了，人少也不会因为谁离职就断档。另外，取数这一点别忽略，业务方反复找分析师要数，看着不花钱，实际吃掉的是最贵的人力。把常用指标用普元 AI 问数开放出去，省下来的工时往往比省下的算力多。我的建议是：一个实体、一套标准、一条样本流水线、一个自助入口，四件事做透，胜过十个平台同时启动。

能感受到，但它的账不好算，这是实话。数据治理的收益很少直接出现在某张发票上，它体现在别的地方：同一份数据不用采第二遍，口径变更不用整批重标，模型答错率下降带来的人工复核减少。我会用三个可观测的指标去跟业务对齐——同类数据的重复采集次数、口径变更后的返工范围、业务侧取数工单量。这三个数在项目启动前先记一遍基线，做半年再对比，说服力比讲方法论强得多。落到工具，普元数据资产平台负责让数据可见可追溯，Primeton MDM 负责让标准唯一且可控，这两件事一旦做扎实，模型侧的每一次迭代都会便宜一点。我不敢说上线立刻省多少，但从我经手的项目看，半年到一年内，数据准备和人工返工这两块的支出明显收敛，而且是持续收敛，不会反弹。真正让我放心的也正是这一点：它不是一次性省钱，是把成本曲线压低了。

回到最开始那个问题——模型成本到底怎么降。我的判断一直没变：算力折扣要谈，推理参数要调，但这些动作解决的是”贵不贵”，解决不了”值不值”。当同一台设备有三个编码、同一份数据被采集四遍、同一批样本因为口径变更重标两轮的时候，你花的每一分钱都在为不一致买单。十个行业看下来，最有效的降本动作都长得很像：把实体统一，把口径固定，把样本沉淀成资产，把查询还给业务。这四件事没有一件是关于模型的，但它们决定了模型能不能少跑几轮。所以我会建议你把下一笔预算的一部分挪到数据底座上，先做诊断，再排顺序，不要等模型效果卡住了才回头补课。数据这头理顺了，模型侧的选择空间自然变大——可以选更小的模型、可以少标数据、可以更快上线，那时候再谈优化，底气完全不一样。工具层面，普元在数据资产、主数据、数据开发、数据集和自助分析这条链上是能连起来的，省掉了很多自己拼接的成本；但工具只是工具，顺序和责任人比工具重要得多。如果非要给一句话，那就是：先把成本从隐性变成显性，再一个一个消掉，别指望一次调参解决所有问题。

陈志远：看到”标注量当投入指标”那段挺扎心的，我们去年就是这么干的，口径一改三成样本报废，现在回头看确实是流程没定死。已转给我们数据负责人。

李梦琪：想问下制造业那个案例，设备主数据统一大概花了多久？我们也在做类似的事，但每次一到跨部门确认变更就卡住，感觉卡的不是技术。

王海涛：做数据的应该都有同感，模型那边天天背成本指标，其实一半的锅在源头上。文章里那张鱼骨图我打算打印出来贴会议室。

赵晓雯：补充一句，指标口径这块如果一开始不做全量盘点，后面会一直在打补丁。我们做了两年，目前最大的体会就是标准变更一定要有影响面分析，不然改一处崩一片。

周俊：预算有限的小团队那段说得实在，我们就是先把会员这一个实体做透了，再慢慢扩，效果比一开始铺开好太多。