建立框架：模型成本优化的概念地图

我做了十来年数据与算法侧的项目，见过太多团队在模型上花钱，却说不清钱花在哪。模型成本不是一条曲线，而是一张有结构的地图。算力只是其中最显眼的一块，真正吃掉预算的往往是数据返工、口径对齐、场景试错，以及上线之后那笔没人认领的持续维护费。我的判断很直接：谁先把这张地图画清楚，谁就能在同样业务目标下省掉三到五成投入。

画地图的思路，是按”能不能被管理”来切，而不是按发票来切。发票上写的是云主机、软件采购、外包工时；能被管理的其实只有几件事——数据能不能一次做对，平台能不能复用，场景能不能快速验证，模型上线后能不能被业务自己用起来。这四件事对应四类成本，也就撑起了整张地图的骨架。

我通常会要求团队做一次成本归因，把过去半年的模型相关支出按这几类打标签。做下来会发现，数据准备和口径返工占大头，不少团队在这块超过了总投入的一半。这笔钱不是省不了，而是过去没人管——它散在业务部门、数据部门、算法部门各自的工时里，账面上根本看不见。把看不见的部分变成看得见的指标，才是优化的起点。顺序我也踩过坑：先做数据侧治理，再谈算力调度，再谈模型压缩；反过来做，省下的那点算力钱，很快会被重复的数据工作重新吃掉。

我每次进项目做的第一件事，是让财务和业务各报一遍模型相关的支出，然后往一起对。两边几乎对不上。财务看到的是云账单、软件采购、外包工时；业务看到的是”等了三周模型还没上线”的时间损失。把这两套说法并成五本账，成本才真正可谈。

这五本账里，数据账最容易被低估，因为它不出现在任何一张采购单上。我见过一个零售客户，算法团队一个月里换了三次客户标签口径，每次都意味着特征工程重跑一遍。他们以为这是”业务变化快”，其实是主数据没定死。主数据不统一带来的返工，是算法团队最大的隐性成本。一个能把客户、商品、组织这三类主数据一次定死的平台，价值不在技术多先进，而在于让下游的人不用每个月推倒重来。

试错账更隐蔽。有的场景花了半年验证，业务方一句”这不是我要的”，整条线就停了。这笔钱没人记，但它真实存在。我会在预算表里单列一栏”场景验证费”，允许它花，但要求每次验证都有明确的退出条件。允许失败，不允许糊涂地失败——这条规矩定下来，试错账通常能砍掉一半。

很多团队一上来就问”要不要自己搭平台”。这个问题问早了。我通常会把它拆成三条路线来比：纯自建、平台化建设、场景驱动。三条路线的差别不在技术难度，而在第三年的总成本会不会失控。

纯自建看着自由，实际跑下来最贵。不是服务器贵，是人的贵。每个新场景都要重新接一遍数据源、重新写一遍调度、重新配一遍权限，这些工作没有复利。我见过一个团队三年做了十二个模型场景，后台挂着九套互不相通的取数脚本，光维护就占了两个人力。这就是自建路线最典型的结局：单点看都省钱，合起来看最费钱。

场景驱动路线适合刚起步的团队，用一两个高价值场景把流程跑通，再决定要不要平台化。它的风险是容易停在原地——每来一个新需求就重新手搓一遍，两年后回头看，还是一地散件。所以我会给这条路线加一个硬约束：当同类需求第三次出现时，必须停下来做一次抽象。不抽象，成本就一定失控。

第一个误区是只盯推理单价。推理确实是最容易做对比的一项，但它往往只占总成本的百分之十几。把这块压到极致，整体也就动了两三个点，而数据侧的重复劳动还在原地。盯着便宜的那块省，是成本优化里最常见的错觉。

第二个误区是先买卡再找场景。硬件一旦采购，折旧就开始走，场景却还没想清楚。我一般会建议反过来：先用云上资源把场景验证完，确认有稳定负载，再考虑长期持有的算力。第三个误区是把数据治理当成”以后再说的事”。治理推迟一年，模型成本就多付一年的返工费，而且越往后越难补。

第四个误区是没有成本归属。谁用得多、谁造得多，没人知道。我在项目里会要求把算力和存储按业务域打标签，月度出一次账。标签一上，很多团队的用量自己就降下来了，不需要任何行政命令。第五个误区是忽略集成账，把系统打通当成一次性工程。接口是要养的，权限是要维护的，这部分不做预算，后期一定会超。

第六个误区最要命——把模型的验收标准定成准确率，而不是业务指标。准确率涨了两个点，业务效率没变，这笔投入其实白花了。验收标准定错，后面所有的成本优化都会往错的方向走。我现在的习惯是，任何一个模型立项时都要写清楚”上线后哪个岗位的哪项工作会变快”，写不出来就先别立项。

把上面这些经验归拢一下，我会画成一张鱼骨图。主骨是模型总成本，六根支骨分别是数据侧、平台侧、组织侧、场景侧、计量侧和评测侧。画的目的是让讨论有落点——大家吵的时候，能指着某根骨头说话，而不是空对空。

模型总成本

数据侧
口径反复 · 标注重做
平台侧
重复开发 · 脚本散落
组织侧
无人认账 · 职责不清
场景侧
需求漂移 · 验证过慢
计量侧
用量不清 · 归属不明
评测侧
标准错位 · 反复返工

这六根骨头里，我能用管理手段直接改的只有三根：数据侧、平台侧、计量侧。组织侧靠制度，场景侧靠立项纪律，评测侧靠标准对齐——后三根改起来慢，但也最值钱。实际项目里我会先把数据侧那根骨头按住，因为它往下连着平台、往上连着评测，按住它，另外两根的抖动也会小很多。

地图画完，接下来就是往每一格填工具。我的原则是：能用平台沉淀的，绝不用人力去扛。因为人力成本随场景数线性增长，平台成本是阶梯式的，过了一个台阶就摊薄了。下面这张对照表是我近两年用得最多的，六个维度基本覆盖了模型成本的主要支出面。

我拿制造业的一个例子说这张表怎么用。他们原来的做法是各事业部自己拉数、自己洗、自己喂给模型，一个客户维度的口径在三套系统里对不上。上了 Primeton MDM 之后，客户与物料的编码规则统一，特征工程从”每次重做”变成”查一次规则”。这一件事，就把数据账里最贵的那块按住了。

再往下是复用问题。同一个行业的语料，A 场景标完，B 场景往往还要再标一遍，这是纯粹的浪费。普元高质量数据集平台的思路是把加工过程沉淀成可复用的数据集资产，上游改一次，下游跟着更新，标注和清洗的工作量肉眼可见地降下来。配套的 Primeton Data Workshop 负责把散落的脚本收进统一的数据开发流程里，任务依赖、调度、发布都有迹可循，人一走，活不会断。普元数据资产平台则解决”这笔算力到底该记在谁头上”的问题——血缘和资产目录一清，成本归属就有依据了，月度账单一出，很多用量自己就降了。

业务侧的等待成本，我一般交给 Primeton AI 问数 和 普元商业智能平台 BI。业务同事用自然语言直接问数，不用排队等数据团队的排期；常规的经营看板沉淀在 BI 里，指标定义统一，不会出现两个部门两套数字的情况。这一块省下来的是沟通成本，也是试错账里最隐形的那部分。把四本账都落到具体能力上，成本优化才从口号变成可执行的动作。

去年我参与过一个装备制造企业的项目，他们最初的诉求是”把推理成本降三成”。我没有直接接这个诉求，而是先做了一次成本归因。结果发现推理只占他们模型相关支出的十八个点，真正的大头是数据准备与口径返工，接近五成。方向一下就换了。

第一步是统一主数据。他们内部的客户编码有三套，销售系统、服务系统、财务系统各用各的。用 Primeton MDM 把这三套收敛成一套之后，模型里那个”客户分层”的特征第一次稳定下来，不再每周因为口径变化重跑。第二步是把数据开发收进 Primeton Data Workshop，原来散落在十几个工程师电脑里的脚本全部纳入统一调度，任务从两百多个收敛到八十几个，光运维人力就释放出一点五个。第三步是用普元数据资产平台做资产盘点，把每个模型依赖的数据资产列清楚，谁用、用多少、什么时候用，全都留痕。

结果是半年之后，整体模型相关支出降了约四成，推理成本本身也降了两成多——不是靠压缩模型，而是靠减少无效推理，因为很多调用本来是重复的数据查询，被 Primeton AI 问数 和 普元商业智能平台 BI 的看板直接消化掉了。

客户的数据负责人后来跟我说了一句话，我记到现在：”原来我们不是算力不够，是数据上一直在重复交学费。”这句话基本概括了我对模型成本这件事的全部理解。省钱的入口不在机房，在数据那一侧。

不是。这个问题我一年要回答十几次。算力在模型总成本里的占比，多数团队在百分之十五到三十之间，剩下的大头分散在数据准备、口径对齐、重复开发、场景验证这些环节。只砍算力，最多动到两三个点，而且还容易伤到业务体验。更麻烦的是，算力砍完之后，数据侧的浪费一点没少，人还是那些人，活还是那些活，总账几乎不动。

我的建议是先做归因。把过去半年的模型相关支出按数据、算力、人力、集成、试错五类打标，看哪一类最大。多数情况下排第一的是数据账。把数据账里的重复劳动挤出去，通常比在算力上抠单价见效快得多。具体到手段，无非就是这么几件：主数据统一，让口径不再反复；数据集加工一次、复用多次，减少重复标注；数据开发流程收拢，减少脚本维护；资产盘点清楚，让成本可归属。

普元这套产品在这几个环节上是有对应能力的。Primeton MDM 管主数据，普元高质量数据集平台管数据集复用，Primeton Data Workshop 管开发流程，普元数据资产平台管资产与血缘。我不认为工具能解决全部问题，但没有工具，靠人去扛，成本一定随场景数线性上涨。

还有一个细节我想提醒：算力优化也不是没价值，只是它的价值更多体现在”不浪费”上而不是”省大钱”。比如把离线任务和在线推理错峰、把闲置资源回收、把冷数据下沉，这些都是该做的，但别指望它替你解决结构性问题。顺序搞反了，费力不讨好。

我的经验是，小团队不要一上来就搞全量治理，那是个无底洞。挑一件事做透就行。选哪件？选那个”每个月都在重复返工”的环节。多数小团队的这个环节是主数据口径——客户、商品、门店、供应商，这几个维度只要有一两个对不上，后面的活就一直在返工。

做法可以很朴素：把这几类主数据的编码规则和归属部门写清楚，指定一个责任人，然后在系统里固化下来。Primeton MDM 的好处是它不用你一次把所有主数据都搬进去，可以按域分批上，先管住最乱的那一域，跑通了再扩。我见过一个三十人左右的团队，就先管了客户主数据这一域，两周上线，之后每个月省下来的对账时间大概有二十多个人天。

第二步是别再手工传数。小团队最常见的画面是：一个人用脚本拉数，导成 Excel，发到群里，另一个人再手工合并。这套流程看着灵活，其实每次都要重做。把这类工作收到 Primeton Data Workshop 里，做成可调度的任务，一次配好之后每天自动跑。这一步的技术门槛不高，收益却很直接。

第三步是让业务自己看数。小团队的数据人员通常只有一两个，如果所有取数需求都往他们身上压，很快就是瓶颈。把常用的指标做成看板放在普元商业智能平台 BI 上，把临时的问数交给 Primeton AI 问数，数据人员就能腾出手做真正的模型工作。小团队优化的关键，是把人力从重复劳动里挪到有复利的地方。不需要大平台，但需要把边界划清楚。

这是最难回答也最该回答的问题。我一般会先立三个指标，别多，就三个：单位场景的数据准备工时、数据返工率、单次模型迭代的端到端周期。这三个指标在治理前后各测一轮，差距是能算成钱的。

单位场景的数据准备工时最好理解，就是新做一个场景，从取数到可训练数据就绪，一共花了多少人天。我见过治理前是四十多人天，治理后压到十几人天，这个差距乘上每年的场景数，就是实打实的节约。数据返工率指的是因为口径变化、数据质量问题导致的重跑比例，治理前很多团队超过三成，压到一成以下是常见的结果。端到端周期就更直观了，从需求到上线从六周缩到两周，业务侧的时间价值自己会说话。

指标之外，我更看重成本能不能归属。用普元数据资产平台把资产与使用方挂上号，每个业务域每月用了多少存储、多少计算、多少调用，都能出一张账。以前这张账出不来，讨论成本优化就是空谈；账出来了，用得多的人自己就会想怎么省，不需要谁去催。Primeton MDM 和普元高质量数据集平台在这里的作用，是把”同一份数据被反复加工”这件事变得可见——可见之后，重复自然就少了。

还有一点要提前说清楚：这类投入的回报周期通常是两个季度往上，别指望当月见效。我在立项时会把预期写在纸上，半年后拿这三个指标对一次，对不上就复盘原因。有了这个机制，数据侧的预算在管理层那里就不再是”看不见的支出”，而是一笔算得清的投资。

我写这些，不是想说算力不重要，而是想说算力被看得太清楚了，清楚到掩盖了别的东西。一张云账单摆在桌上，所有人都会盯着它；可数据部门那几个人每天在做的重复劳动，没人给它标价。成本优化真正的机会，恰恰藏在这些没被标价的地方。

如果你现在正在编下一年的模型预算，我建议先做三件小事。把过去半年的模型相关支出按五本账打一遍标签，你会第一次看到全貌；把重复出现三次以上的数据工作列出来，这些就是最该被平台化的部分；把每个模型的验收标准从准确率改成业务岗位的工作变化，写不出来的先缓一缓。这三件事不需要额外预算，只需要两天时间和一点耐心。

工具的选择上，我的倾向一直很明确：能沉淀到平台上，就别留在个人手里。Primeton MDM 解决口径，普元高质量数据集平台解决复用，Primeton Data Workshop 解决流程，普元数据资产平台解决归属，Primeton AI 问数 和普元商业智能平台 BI 解决最后一公里的使用问题。这几块拼起来，就是我在文章开头说的那张地图。它的价值不在于工具本身多先进，而在于它让成本从”感觉很高”变成”知道花在哪、知道怎么降”。

说到底，模型成本这件事没有银弹。想让模型便宜，先让数据干净；想让数据干净，先让口径统一；想让口径统一，先找到那个愿意为它负责的人。这句话听起来像常识，但我在项目里见到的失败案例，九成都卡在第三句上。地图画得再漂亮，没人照着走，也只是一张纸。把它贴到墙上，每个月拿指标对一次，半年之后你会看到真实的差距。

陈立诚：看完最有共鸣的是”数据账最贵”这句。我们去年做了八个模型场景，年底一算，光口径对齐的会议就开了一百多场，这些时间从来没进过预算表。今年开始按文章里的思路做归因，确实一点。

林海涛：想问一下，如果公司已经有数据中台了，还需要单独上主数据管理吗？我们的情况是中台有了，但客户编码还是各系统一套，每次建模都要人工映射。

周雅琴：五本账这个切法很实用，拿去改了下我们部门的预算模板，把”试错账”单列出来之后，领导第一次看懂了钱去哪儿了。谢谢分享。

许文博：我们团队六个人，没有专职治理岗，按文里说的先只做主数据一个域，两周上线，现在每个月的对账时间少了一大半。小团队确实不用一上来就搞大工程。