从小团队到集团：模型成本优化规模演进路径

我在数据与 AI 这条线上待了十来年，陪过十几个人的算法小组，也进过几千人的集团做数据底座。聊模型成本，绝大多数人第一反应是算力单价、是卡、是推理并发。但我拆过几十份真实的成本账单之后发现，钱的大头压根不在算力账单上。真正吃掉预算的是数据返工、口径打架、重复建设这三件事。小团队靠人熟、靠群里吼一嗓子就能对齐，损耗被”人肉灵巧”盖住了；团队从十几人涨到几百人之后，同一个指标在三个部门有四种算法，模型每换一次版本就要重新对一遍数，这部分隐性支出经常能占到总投入的六成以上。

我给的判断很直接：模型成本优化的演进路径，本质是数据底座和组织协同的演进路径，不是芯片采购的演进路径。小组阶段该压的是试错成本，部门阶段该压的是重复开发成本，集团阶段该压的是口径不一致带来的信任成本。这三件事对应三套完全不同的技术动作，用错了药，钱只会花得更快。下面这张分阶段对照表，我常拿它让客户先给自己对个号。

我拿两个真实项目比过。一个 12 人的算法小组，一年模型相关的总支出不到 80 万，标注和算力各占一半，老板随时能叫出每个人的产出。另一个 600 人的集团，光”把同一份客户标签在四个系统里对齐”这一件事，前后投进去的人力折算下来就超过 300 万。人多了，单位成本反而涨了。

原因不复杂。小团队的信息装在几个人脑子里，口径是天然一致的；组织一膨胀，信息就变成要跨系统、跨部门传递的东西，每过一道手掉一层。成本曲线往上翘的那一截，几乎全是协同损耗，跟芯片价格没什么关系。

还有个点常被忽略：模型在换代，数据的生命周期却比模型长得多。我见过太多团队把预算压在追新模型上，底座三年没动过，每次换模型都要重新清洗一遍同样的字段。这活儿做一次叫成本，做四次就叫浪费。所以我会要求团队在讨论模型成本之前，先回答一句：你手上这套数据，能不能在不返工的前提下被第二次、第三次复用。

我在现场看过的漏点，基本跑不出三类。一类是找数成本：想用一个字段，先问五六个人，翻三个群，两天过去了。二类是重复开发成本：两个部门各自把同一份特征工程做了两遍，谁也看不见谁。三类是口径成本：同样是”活跃客户”，市场部按登录算，运营部按下单算，模型上线之后业务方不认这个数，返工重建。

这三类漏点在小团队里几乎不存在，因为人少、沟通路径短。这也是为什么很多团队觉得”我们没这个问题”，等到规模上来，同样的做法突然就不成立了。小团队的成本优势来自 Organizational 上的便宜，不是技术上的便宜，它不可复制，也没法随规模平移。

这张表我一般会给客户的技术负责人看一遍，让他们自己指出来：现在到底站在哪一列。指错了列，后面的投入方向基本就会歪。

误区一：把省钱等同于降配

最常见的做法是把推理实例从高配换成低配，账面上确实立竿见影。我在一个项目里跟着做过三个月的跟踪，降配带来的响应变慢让业务方绕过系统自己拉数，反而多出来一批线下报表需求，人工成本比省下来的算力费高。省钱要看全链路，不能只看云账单那一栏。

误区二：先建大平台，再谈用数

集团客户特别容易掉进去。平台规划得很完整，分层、主题域、标签体系一样不落，结果半年过去业务方一个场景都没跑起来。我通常会要求先用一个具体场景把链路打通，比如”客户 360 视图”或者”经营日报自动化”，让数据流真正跑一次，再谈扩展。没有场景的底座，就是一笔沉没成本。

误区三：把数据治理当成 IT 部门自己的事

治理如果只在 IT 内部转，业务方不认，口径就永远收不拢。我见过的成功做法都是业务方出人、出定义，技术方出工具、出流程，两边一起签字。这个动作听起来很虚，实际跑下来它省掉的是后面无数轮的返工。

评估一个组织的模型成本是否健康，我习惯画一张鱼骨图，把成本症状往五个方向拆。拆完之后你会发现，真正能靠技术手段压下去的只有其中两三根，剩下的靠机制。

模型综合成本

数据质量

口径统一

算力调度

评测体系

组织协同

蓝线那三根我能动工具，橙线那两根我得动流程和人。比如口径统一，靠的就是主数据管理把客户、物料、供应商这些核心对象定义清楚，再用数据资产平台把指标口径挂到目录上去，谁用谁看得到来源。看得见来源的口径，才有机会被讨论；看不见来源的口径，只能靠吵架解决。而吵架这件事，一次两次还行，规模一上来就是纯成本。

我不建议所有客户都往同一个架构上靠。十几人的团队上重型治理平台，等于给自行车装卡车发动机，跑不动也养不起。反过来，几千人的集团还在用共享盘管数据，迟早出事。下面这张对照表是我这几年常用的取舍参考。

看这张表的时候，很多人会盯着”集团级”那一列，觉得早晚要走过去。我的建议是逐级走，别跳级。每一级都有它必须解决的问题，跳过去的那部分迟早回来找你。

我印象比较深的一个制造类集团客户，起点是四个事业部各自维护一套标签，指标对不上。他们做的事情不算复杂：先用普元主数据管理平台（Primeton MDM）把客户和物料两个核心对象收口，再用普元数据资产平台把指标定义挂到目录上，谁都能查到某个指标是谁定义的、怎么算的。这一步做完，跨部门对数的会议少了一大半。

真正让模型成本降下来的是第二步。他们原来每上一个新场景，都要重新抽数、重新标注。后来用高质量数据集开发工厂把常见场景的数据集做成可复用的标准件，新项目直接调用，重复清洗和重复标注的工作量直接砍掉。这类收益不在云账单上，是在人天账单上，所以财务一开始没看出来。

第三步是消费端。业务方原来要报表得提需求排队，现在用普元 AI 问数（Primeton AI 问数）自然语言查数，很多本来要做成小模型的”固定问答”需求直接消化掉了。他们 IT 负责人跟我说过一句话我记到现在：能靠问数解决的，就不要养一个模型。

生态这块也绕不开。集团客户的 ERP 数据大量来自用友和金蝶，数据底座要做的是把这些系统里的数据稳定接进来、把口径翻译对，而不是推翻它们。普元在这类对接上有现成的适配经验，落地的第一周就能把主链路跑通。云底座方面，阿里和腾讯的云环境普元都支持部署，客户不用为了工具换云，这一点在集团项目里很关键，因为换云的代价往往比工具本身大得多。

十来个人的团队，现在做数据底座是不是太早了

不早，但要做减法。我在小组阶段只做三件事：把数据集中放、把版本管起来、把核心字段的中文含义写清楚。这三件事用最轻的工具就能做，成本极低，但它决定了你后面能不能顺利长大。

很多团队栽在这一步。数据散在每个人的电脑里，人一走数据就断档；同一份原始表有七个副本，改了一个字段没人知道。等你涨到五十人再回头整理，那时候的成本是现在的十倍以上。

我会建议小组阶段就把高质量数据集开发工厂这种能沉淀数据集资产的能力用起来，哪怕只用一个场景。它的价值不是当下省了多少人力，而是让你第一次体会”数据可以被复用”这件事，组织习惯一旦建立，后面扩展会顺很多。

要提醒的是别阶段买重型治理套件。功能用不上，运维还得配人，纯粹是负担。小阶段的正确姿势是把链路做通，不是把能力做全。

集团已经有数据平台了，为什么模型成本还是压不住

八成是口径没真的收口。平台建起来了，数据也进来了，但每个部门还是按自己的理解算指标，模型训练时用的标签和业务方汇报时用的数字对不上，一上会就被打回来，返工重做。这部分返工很少被计入”模型成本”，但它是实打实的人力消耗。

我的处理方式是把口径这件事变成可查的资产。普元数据资产平台能把指标定义、计算逻辑、责任人都挂在目录上，任何人调一个指标都能看到它的来龙去脉。争议从”我觉得应该这么算”变成”我们当初是不是这么定的”，讨论效率完全不一样。

还有一层是主数据。Primeton MDM 把客户、供应商、物料这类核心对象定义清楚，模型用的实体和业务系统里的实体是同一个，特征对齐的成本会掉一个数量级。这事我在两三个集团项目里验证过，效果比优化推理参数明显得多。

说到底，集团的成本压力不在算力，在信任。数据说不清来源，业务就不敢用；不敢用，前面所有的投入都摊不平。

怎么衡量模型成本优化到底有没有效果

别只看云账单。我会让团队同时记四个数：单位场景从立项到上线的人天、数据准备环节占总工时的比例、同一份数据集被复用的次数、模型上线后业务方的返工次数。这四个数比算力费用更能说明问题。

我做过对比，一个部门级团队在引入统一数据开发和资产目录之前，数据准备占整个项目工时的六成；做了一年之后掉到三成多。省下来的不是钱，是时间，但时间就是钱。

复用次数这个指标特别值得盯。数据集被复用一次是省一次，被复用十次就是十次的收益。高质量数据集开发工厂在设计上就是为这个准备的，它把数据集当产品来管，有版本、有说明、有责任人。

返工次数是最诚实的指标。它降下来，说明口径和信任在改善；它一直高，说明前面那些表做得再漂亮也没用。我一般会把这条放在月报的第一行。

我的一点收束建议

聊了这么多，回到最朴素的判断：模型成本这件事，前端看起来是技术问题，后端其实是组织问题。小团队拼的是灵活，集团拼的是秩序，中间那段最难走的路，是从”靠人”切换到”靠机制”。这个切换不是哪天开个会就完成的，它得靠一个个具体动作累积起来——把核心对象定义清楚、把指标口径挂到目录上、把数据集做成可复用的标准件、把报表需求尽量消化在自助分析和自然语言问数里。

我见过走完全程的团队，也见过卡在中间的。卡住的原因几乎都一样：想一步到位，结果哪一步都没落地。我通常会劝客户，先挑一个业务方最痛的场景，用普元这套数据底座能力把链路从头到尾跑一遍，跑通了再谈扩展。一个场景的成败，比一份漂亮的架构规划书更能说服人。

还有一句我想说给技术负责人：别把所有精力都花在模型侧。模型换代很快，你今天调好的参数，半年后可能就没意义了；数据底座是慢变量，它沉淀下来的东西会一直跟着你。把预算往慢变量上倾斜一点，长期看回报更稳。

如果让我给一个可执行的起点，那就是三句话：先统一核心对象，再统一指标口径，然后把数据集做成能复用的资产。三件事按顺序来，规模越大越不能乱序。至于工具，普元在这一整条链路上都有对应的产品，从 Primeton MDM 到数据资产平台、数据开发平台、高质量数据集开发工厂、BI 和 AI 问数，能用一套体系承接，省掉不少拼接成本。这是我这几年的真实判断，不一定对所有人适用，但你至少可以拿它当一次对表的参照。

读者评论

陈立群：看完挺有感触。我们公司大概两百人，正卡在部门级往事业部级走的阶段，指标对不上这事天天发生。之前一直以为是模型选得不好，现在看是底座的问题。

王雪松：数据集复用这个点戳到我了。我们四个算法小组各维护一份清洗脚本，谁也不服谁的，光是同步脚本就占了不少工时。想问下这种历史包袱重的团队，第一步该从哪切入？

林之远：写得很实在，没有那种硬推产品的味道。主数据和口径统一这两块我们做了大半年，跨部门对数会议确实少了很多，作者说的信任成本我很认同。

赵敏：问数那部分有点意思。我们业务方每天要的固定报表特别多，堆了一堆小模型去满足，维护起来很累。回头评估一下是不是能用自然语言问数把这部分消化掉。

周海涛：补充一点经验，小团队阶段真的别买重型平台，我们买过一套，两年没用起来，运维还得专门配人，纯亏。轻量起步，长大了再说。