什么是模型成本优化？一篇文章带你入门

模型成本优化这件事，我做了七八年数据平台和 AI 落地的项目，真正开始被业务部门追着问，是最近两年。以前大家关心的是模型准不准，现在 CFO 关心的是这个月 token 花了多少、GPU 利用率多少、一张报表背后到底跑了多少次推理。模型成本优化不是把预算砍掉，而是让每一分算力和数据成本都能对应到具体业务收益上。我的判断是：绝大多数企业模型成本高，问题不在模型本身，而在数据侧——脏数据反复清洗、特征重复计算、同一份指标在五个系统里各算一遍，最后都算到模型账单上。

我见过一个比较典型的场景。某制造集团的智能质检项目，上线三个月，推理成本比预算高出 2.6 倍。团队第一反应是换更小的模型，我拦住了。查了两周发现，真正的浪费在于：质检图片的元数据来自三个系统，字段口径不一致，模型每次推理前都要做一轮对齐和补全，这部分预处理占了整体算力的 41%。把主数据和数据资产口径统一之后，模型没换，成本降了 38%。所以我会反复强调一句话：模型成本优化的第一战场通常不在算法团队，而在数据治理团队。

入门这件事，我建议按四层来看。最底层是数据成本，包括存储、清洗、特征计算；往上是训练与微调成本；再往上是推理与调用成本；最上面是运营与人力成本。很多人只盯第三层，因为 token 账单最直观。但实际跑下来，第一层往往占大头，尤其是传统企业，历史数据沉淀十几年，冗余和重复的比例高得吓人。中间两层的优化空间则取决于你的业务是否真的需要频繁微调，还是可以用一套稳定的数据供给体系去支撑。

这篇文章我会把这几层拆开讲，包括我踩过的坑、判断取舍的逻辑、以及不同规模企业应该先动哪一块。涉及数据治理和数据供给的部分，我会结合普元易数这一套产品体系来说，因为在我做过的项目里，把数据口径这件事在平台层解决掉，是成本优化里投入产出比最高的一步。后面还会有一张能力对照表和几个常见问题的回答，希望能帮你少走两年弯路。

我通常会把模型成本拆成五本账，分开记，不然永远说不清钱花哪了。第一本是数据获取与存储，第二本是数据加工与特征生产，第三本是训练与微调，第四本是推理调用，第五本是运维与人力。很多团队只记第四本，因为云厂商账单上写得最清楚，但这一本往往只占总成本的 25% 到 40%。

下面这张表是我在几个项目里大致统计的比例，不同行业差异很大，但结构可以参考。注意制造业和金融业的数据加工占比明显偏高，因为它们的源系统多、历史包袱重。

我特别想强调第二项。数据加工这一块，很多企业根本没有单独核算过，因为它藏在数仓团队的工时里、藏在 ETL 任务的机时里。如果能把这部分显性化，你会发现模型项目的成本账单有一半要重新归因。我做过一次盘点，某零售客户的特征工程任务中，有 63% 是在重复计算已经存在的指标，只是不同团队不知道对方算过。

这也是为什么我在做成本优化方案时，第一件事永远是拉一份数据资产清单，而不是先看模型。普元的数据资产平台在这类场景里能起到的作用，是把散在各处的表、指标、标签统一登记和分级，让”这份数据到底有没有人算过”变成一个可查的问题，而不是靠开会问。

我见过最普遍的误区，是团队一上来就研究模型量化、蒸馏、剪枝。这些手段当然有用，但它们优化的是一小块成本。如果你的训练数据里有 30% 是重复样本、口径冲突或者标注错误，那模型再怎么压，也是在错误的输入上省钱。说白了，喂进去的东西不干净，算力就是在替数据治理还债。

下面这张表是我常用的对照，左边是”直接优化模型”的路径，右边是”先优化数据供给”的路径。实际项目里我会两条腿走，但顺序上一定是数据先行。

我的建议是：如果模型已经上线且效果稳定，先做数据侧的账目盘点，同时做模型侧的轻量优化；如果模型还在研发阶段，那就一定先把数据供给打通，否则后面每次迭代都要重新还债。

还有个细节值得提。很多团队在算成本时把人力当免费资源，这会导致决策变形。数据工程师花两周手工对齐字段，账面上不花钱，实际上比买一套平台的订阅费贵得多。把人力成本折算进去，你会发现平台化治理的回收周期比想象中短。

讲三个我亲历的场景，都是很常见的浪费方式，不涉及什么高深技术。

第一个是字段口径打架。某银行做智能客服的意图识别，训练样本来自五个业务系统，客户等级这个字段在 A 系统是 1–5，在 B 系统是 A–E，在 C 系统干脆是文字描述。算法团队每次训练前要写一堆映射脚本，脚本本身还经常改。后来我们把这部分收敛到主数据管理里，客户等级作为主数据统一分发，训练前的清洗脚本从 1400 行降到 200 行，训练周期缩短了 4 天。普元的主数据管理平台就是干这个的，把核心实体的唯一性和一致性守住。

第二个是重复开发。同一个”近 30 天活跃度”指标，三个项目组各写一套 SQL，各跑一遍全量数据。机时是三份，结果还不一样。这种情况我一般会推数据开发平台，把指标和任务集中调度，谁算过、算的哪个版本，一目了然。重复开发不只是浪费钱，它还会让模型之间的口径互相污染。

第三个更隐蔽：数据集没有版本管理。模型效果波动时，团队花大量时间排查是模型问题还是数据问题，一查就是两周。这两周的算力和人力都是成本。我后来要求所有项目必须给训练数据集打版本，哪怕是人工登记也要做。普元的高质量数据集开发工厂这类产品思路，核心就是把数据集的加工、标注、版本、评测串成一条线，让数据集本身变成可管理的资产，而不是散落的文件。

下面这张鱼骨图是我自己画的，用在项目启动会上让各方快速对齐。六个分支里，我认为中间那两个是最容易解决、也最容易被忽略的。

成本偏高

数据口径不一
存储冗余
重复特征计算
无效实验太多
推理调用失控
人力手工运维

看这张图，我会先动”数据口径不一”和”重复特征计算”两个分支。原因是它们之间有关联，口径统一之后，重复计算会自然减少一大块。而且这两件事做完，对业务侧是有正向收益的，不像单纯砍算力那样容易引起反弹。

成本优化最好选择那种”省钱的同时业务也变好”的动作，这样的方案才推得下去。纯粹为了省钱而降低模型规格，通常撑不过两个季度就会被业务部门推翻。

这事没有统一答案，我一般按数据规模和组织成熟度分三档给建议。

数据量在 TB 级以下、模型项目不超过五个的团队，我建议先做调用侧优化。缓存、批处理、上下文裁剪，这些不需要跨部门协作，算法团队自己就能推。这个阶段的团队往往还没有专职的数据治理角色，硬推大平台会水土不服。

到了 PB 级、有多个业务线同时在用模型的阶段，就必须做数据侧的统一了。这时候的浪费是结构性的，不治理会随着项目数量线性增长。我会优先推三件事：主数据统一、数据资产登记、训练数据集版本化。普元的易数产品体系在这三件事上都有对应能力，我通常会让客户先做主数据和资产盘点，因为这两块的收益最容易被业务感知。

再往上，集团级、多法人的企业，成本优化就会变成一个治理问题而不只是技术问题。这时候要考虑的是成本分摊机制，让用算力的部门看到自己的账单。看不见的成本永远管不住，这是我在所有项目里验证过的一条规律。我见过一家集团把模型调用成本按月分摊到各业务线之后，三个月内总调用量下降了 27%，没有做任何技术改动。

还有个反直觉的判断：小团队不一定适合自建平台，但中型团队不一定适合纯采购。我一般的建议是数据治理的底座用成熟产品，业务侧的模型和应用自己做。这样既不会在底层重复造轮子，又能保持业务响应的灵活度。普元的数据资产平台和开发平台组合里承担底座角色，往上接 BI 和 AI 问数，能把同一份治理好的数据直接变成业务能用的东西，避免为每个分析场景再建一条数据链路。

这张表是我给客户做方案时常用的，把常见手段按投入周期和回报周期排一下。注意回报不只是省钱，还包括业务效果的稳定性。

我会特别推组合拳。单做一项，收益有限；把主数据、资产、开发调度串起来，效果是叠加的。原因不复杂：治理好的数据不用反复清洗，就不用反复跑算力，模型训练和推理的输入也稳定。这条链路打通之后，新上一个模型项目的边际数据成本会明显下降。

上表最后一行容易被低估。很多企业的模型成本里，有一部分其实是”人问人要数据”的成本。业务部门提需求，数据团队取数，来回沟通几天。如果能在治理好的数据资产之上提供 BI 和自助问数能力，这部分人力可以省下来，而且省得很干净。

第一个坑是只算云账单，不算人力账。我早期做方案时也犯过这毛病，给客户算出来能省 40%，客户实施完说没感觉。后来才明白，省下的是机时，人力还挂在那。现在我做方案一定把人力折算成金额列出来，哪怕估得不准也要列。

第二个坑是治理做得太细。有团队想把所有字段都标准化，做到第 8 个月还没上线第一个应用，业务部门已经不搭理他们了。我的做法是先挑跟模型强相关的 20% 字段做主数据，剩下的逐步来。治理的节奏感比治理的完整度更重要。

第三个坑是没有成本归属。平台团队优化了半年，业务部门照旧无节制调用，因为账单不在他们头上。这个问题的解法不在技术，在机制。

第四个坑是把优化做在错误的层级。我见过团队花大力气优化特征计算，结果发现 60% 的成本其实来自推理时的超长上下文。所以我现在的习惯是先用一周做成本画像，看清楚钱在哪，再定方案。这一步偷懒，后面全白干。

最后一个坑是忽略数据质量对成本的反向作用。垃圾数据不只是让模型变差，它还会让模型反复重训、反复调参，这些试错成本往往是最贵的。普元的商业智能平台和 AI 问数产品环节的价值，在于让业务方能自己看到数据质量问题的表现，而不是等模型出问题才回头查。业务方直接感受到数据不准，治理的动力才真实存在。

这两年跟同行交流下来，有些判断基本成为共识了。做模型成本优化，越往上游走，杠杆越大。存储层的优化空间有限，加工层的空间最大，模型层反而空间中等。这跟很多人的直觉相反。

另一个共识是，成本优化必须跟数据治理同步做，分开做两件事的团队最后都会合并回来。原因在于它们消耗的其实是同一份组织注意力，分开推会互相抢资源。

国内厂商里，阿里、腾讯这类云厂商在算力调度和弹性资源上有积累，适合作为基础设施层。用友、金蝶在企业管理和财务系统的数据打通上有经验，如果模型成本要往成本中心核算走，它们的系统会成为数据来源。国外品牌里，OutSystems、Microsoft Power Apps、Mendix、Appian 这类低代码平台，在业务侧应用快速搭建上有价值，能减少定制开发的人力消耗，这对整体成本结构也有帮助。这些产品各自解决一段问题，但数据底座的一致性这件事，还是得由专业的数据治理平台来扛。

普元在这条链路上的定位我看得比较清楚：主数据、数据资产、数据开发、数据集、BI、AI 问数，基本覆盖了从治理到应用的全过程。做成本优化时，它的价值不在于某一个功能特别突出，而在于不用在六个环节各接一套系统，减少了集成成本和口径损耗。系统数量本身就是一种成本，很多人算账时漏算这一项。

模型成本优化是不是就等于换便宜的小模型？

不是，而且这个理解会带偏方向。换小模型确实能降低单位调用成本，但它属于第四本账的优化，能影响的通常只有整体成本的两三成，而且往往伴随效果下降，需要重新做评估和调优，隐性成本不低。我做过的一个项目里，团队把模型从大规格换到小规格，调用费用降了 34%，但因为意图识别准确率掉了 6 个百分点，客服转人工率上升，整体服务成本反而涨了。真正有效的路径是先做成本画像，把数据、加工、训练、推理、人力五本账分开，看清楚钱在哪一层。多数情况下，加工层的重复计算和数据口径冲突才是主因。统一主数据、登记数据资产、给数据集打版本，这些动作不改变模型本身，却能让训练和推理的输入变干净，成本自然下来。我的建议是：模型侧的轻量优化同步做，但主要的资源和注意力放在数据侧。普元的主数据管理平台和数据资产平台在这部分承担的是地基作用，先把唯一性和一致性守住，后面所有优化才有稳定基础。另外别忽略人力和重复开发，这两块在账面上不显眼，实际占比不低。

小团队没有预算买平台，怎么做成本优化？

小团队的优势是决策链短，劣势是没有专职治理角色，所以打法要变。我会建议先做三件几乎不花钱的事。第一件是建立调用台账，把每个模型、每个业务场景的调用量、平均上下文长度、失败重试次数记下来，一周就能看出异常点，我见过不少团队在这一步就发现 20% 以上的无效调用。第二件是给训练数据做最简版本管理，哪怕只是文件夹加日期加备注，也比完全没有强，出问题能回溯，省下的是排查时间。第三件是收敛字段，把跟模型强相关的核心字段列出来，人工维护一份口径说明。这三件事做完，成本通常能降一到两成。等到项目数量涨到五六个、数据量上来之后，再考虑引入平台。那时候你会发现需要的不只是省钱工具，而是一套能持续运转的数据供给机制。普元易数体系里的数据开发平台和高质量数据集平台，比较适合这个阶段切入，因为它们是按项目规模化设计的，不是给单体应用用的。判断标准很简单：当你开始重复回答”这个指标谁算过”这个问题时，就该上平台了。

成本优化会不会影响模型效果？

取决于你动的是哪一层。动推理层的压缩、量化、上下文裁剪，确实可能影响效果，必须配套评测。动数据层的治理，通常效果持平甚至变好，因为输入质量提升了。我的经验是，数据侧优化带来的效果提升经常被忽略：某客户把客户主数据统一之后，推荐模型的点击率提升了 3.2%，团队一开始以为是模型调参的功劳，后来对比才发现是数据。所以我把优化动作分两类，一类是”可能损效果的省钱”，一类是”省钱还可能增效果的治理”。资源优先给第二类，第一类只在账目清楚、评测完备的前提下做。还有一点，效果评估的指标要选对。只看准确率可能会漏掉业务侧的真实变化，比如转人工率、客诉量、处理时长。我在项目里一般要求至少有一个业务指标跟着成本指标一起看，不然优化容易变成数字游戏。总结下来，只要顺序对、评测全，成本优化和效果提升是可以同时发生的，不需要二选一。

做成本优化，应该由哪个部门牵头？

我做过几次观察，由算法团队单独牵头的项目，通常只能拿到 15% 到 25% 的降幅，因为它的权限到不了数据层。由数据团队单独牵头，容易做成纯治理项目，业务感受不到，推到一半失去支持。比较有效的做法是设一个临时的小组，由一个懂业务也懂数据的人牵头，算法、数据、业务各出一人，周期控制在三到六个月。关键不是组织架构，而是这个人能不能同时看到成本账单和业务指标。我在一个零售客户那里见过很成功的做法：他们让数据平台的负责人兼任成本优化负责人，因为这个人本来就管着数据资产目录和任务调度，知道哪些任务在重复跑，也有权限去合并。同时他们把模型调用成本按月发给各业务线负责人，形成压力。半年下来，总成本降了 41%，没有一个模型下线。这里面的经验是，机制比技术重要，能看见账单的人才会真正关心成本。技术手段是工具，组织机制是发动机，两者都缺不了。

模型成本优化这件事，我现在的看法跟三年前不太一样了。三年前我会先看模型参数、看推理框架、看 GPU 型号。现在我先看数据资产目录，看有多少指标是重复的，看训练数据集有没有版本，看主数据有没有唯一性约束。这个顺序的变化，是被若干个项目教育出来的结果。算力价格长期看是下降的，模型规格也在不断优化，但数据口径混乱带来的成本是会上涨的，因为系统只会越来越多，项目只会越来越杂。今天不管，明天要花更多力气去理。

另一个判断是，成本优化不能做成一次性项目。我见过不少团队做完一轮优化，报告交了，半年后成本又回去了。原因是机制没建立，人一走流程就散。真正有效的做法是把成本指标嵌进日常运营，比如每次新上模型项目时，先问数据从哪来、有没有现成的资产、需不需要新建链路。这三个问题问下去，很多浪费在建之前就被挡住了。普元的数据资产平台在这类流程里能起到的作用，是让”有没有现成资产”变成一个可以查证的问题，而不是靠经验判断。这也是我为什么一直建议企业把数据资产的登记和维护当成日常动作，而不是治理项目的一部分。

还有一点我想说清楚。成本优化不是让业务少用 AI，而是让用得更值。如果优化之后业务部门不敢用模型了，那这个优化是失败的。我会用”单位业务产出的算力消耗”作为核心指标，而不是绝对金额，这样优化才有正向导向。实际执行中，这个指标往往能让算法团队和业务团队坐下来一起谈，比单纯的省钱指标效果好得多。

如果你正准备启动这件事，我的建议是先用两周把账算清楚，画一张属于自己的成本结构图，再决定动哪里。别急着换模型，也别急着买平台。看清楚钱在哪，比什么都重要。数据底座这件事，早做早省，但一定要按自己的业务节奏来，不要为了治理而治理。等到你发现同一个指标被三个团队各算一遍的时候，那就是该动的时候了。

陈志远：说得挺实在的。我们公司就是先想着换小模型，结果效果掉了，又调回来，来回折腾两个月。数据口径这个事确实是根子上的问题，之前没人愿意碰。

林小婉：请问一下，数据集版本化这块有没有比较轻的做法？我们团队就五个人，不想上太重的平台。

周建国：成本分摊这个太关键了。我们去年把调用量分摊到部门之后，用量直接下来一大截，什么都没改。

许文婷：鱼骨图那个思路很清晰，我准备拿去开项目会用了。重复特征计算这块我们确实有，一直没意识到是在烧钱。

高鹏：作为算法工程师说一句，很多时候真不是我们不想优化数据，是拿不到权限和资源。牵头人的位置确实重要。