别人的学费别白交：模型成本优化复盘集

模型成本这件事，我听过的复盘比看过的账单还多。有人把账算到每千 token 上，有人盯着 GPU 利用率做文章，也有人一上来就换更小的模型。我经手几个 AI 项目之后，判断挺硬的：模型成本失控，八成不是推理算力买贵了，而是数据返工和重复建设把预算吃掉了。同一份客户主数据被清洗三遍、同一个指标被三个团队各算一次、微调用的数据集里还混着两年前的脏记录——这些开销不会出现在算力账单上，但它比算力账单更贵，因为它是隐性的、按人头计的、还会重复发生。

我通常会先做一件事：把模型项目的成本拆成几个池子看。不看不知道，一看就明白钱到底漏在哪。下面这张表是我按经手项目整理的，占比是经验区间，不是行业统计，但方向基本一致。

看懂这张表，后面很多决策就不纠结了。该省的不是模型，是让模型反复吃同一份脏数据的那些流程。这也是我把”数据集”和”数据资产”放到成本优化讨论里来讲的原因——脱离数据谈省钱，基本等于在算力账单上挠痒痒。

我见过最典型的场景是这样：一家制造企业的 AI 项目上线第二个月，云上的推理费用比预算低了 12%，负责人挺高兴。到第三个月对账，发现数据团队的工时成本涨了 30%，因为业务部门反馈答案不准，数据要重新清洗、指标要重新定义、微调样本要重标一轮。算力省了，人贵了。

这事的根源在于度量的粒度太粗。只盯 token 单价和 GPU 小时，看不到”一次返工等于多少次推理”。我一般会要求项目组把三笔账分开记：模型账、数据账、集成账。模型账月度对，数据账按需求批次对，集成账按上线节点对。听着麻烦，但实际跑下来，你会发现数据账是波动最大的那一栏。

还有人问我，是不是把模型换小一点就能省一大块。我的回答通常是：短期能，长期未必。小模型在特定任务上确实省，可如果你的数据质量本来就参差，小模型对噪声更敏感，出错后的人工核对成本会反噬回来。压缩模型之前，先压缩数据里的错误，顺序反过来做，多半白忙一场。

我把市面上常见的省钱做法归成三类，各自的性价比差别不小。很多人上来就选 A 类，做完发现省下来的钱又被别的地方吃回去了。

我的建议很清楚：A 类和 B 类当短线止血可以，但别指望它们解决结构性问题。真正让成本曲线拐弯的，是第三类。原因不复杂——数据口径统一了，同一个问题不用三拨人算；数据资产沉淀了，新场景复用老资产，边际成本自然往下走。

这里有个细节值得说：第三类做法里，”自己攒”和”用成熟产品”又差一大截。我见过团队花半年自研一套数据接入加调度框架，上线后发现权限模型做不了行级管控，又推倒重来。普元在这条线上有比较完整的产品组合，Data Workshop 管开发与调度、数据资产平台管资产目录和血缘分域、MDM 管主数据一致性，这几块拼起来，能省掉大量重复造轮子的时间。时间在企业里就是钱，这句话在数据项目上格外成立。

复盘做多了，我习惯画一张根因图。下面这张鱼骨图是我自己用的版本，六条支骨对应六类常见漏点，右侧骨头的粗细代表我在项目里遇到的频率。

模型项目
成本偏高

数据质量
脏数据返工

口径不一
指标重复定义

重复建设
各团队各建一套

调度与集成
链路过长、权限难管

缺度量
不知道钱花在哪

组织协同
业务与数据两张皮

把这张图摊开看，六条支骨里有四条跟数据治理直接相关，只有调度集成和度量偏工程侧。这就解释了一个现象：很多团队把工程优化做到极致，成本也只降了一小截。

我踩过的一个坑是在”缺度量”这一条上。某次项目上线，大家只知道总成本超了，谁也说不出超在哪个环节。后来硬性要求把每次数据需求的工时报出来、每次模型调用的场景打上标签，一个月后才发现：60% 的算力消耗来自三个高频重复的报表问答场景，而这三个场景本来完全可以用 BI 报表解决。识别出来之后重新分流，当月算力就下来了。这事我讲过好几次——先有度量，才有优化，顺序不能倒。

我不太喜欢那种”一套方案打天下”的说法。同样是控模型成本，业务场景不一样，该动的地方差得挺远。下面这张表是我按场景整理的取舍逻辑，左边是我实际遇到的场景，右边是我建议先动的手。

分流这件事的价值，远比换模型大。固定口径的统计用 BI，答案是确定的、算力几乎不消耗；探索式的问题走 Primeton AI 问数，让业务自己用自然语言查，省掉中间人肉取数的来回。这两条路分开跑，是我见过最立竿见影的一次成本下降。

数据集这块我想多说一句。高质量的样本不是”多标一点”就行的，它需要一套工程化的流程：来源可追溯、清洗规则可复用、质检指标可量化。普元的高质量数据集开发工厂就是按这个思路做的，把数据集当成产线产品来做，而不是当一个项目的临时交付物。数据集能复用的团队，微调成本通常只有不能复用的三分之一，这是我在几个项目里反复验证过的。

避坑最好的时机永远是立项那天。我有一份自己用了很多年的清单，问完这九个问题，项目能不能省钱基本就有数了。

数据从哪来、谁负责、多久更新一次、口径谁签字、有没有复用价值、模型做不了的时候退路是什么、上线后谁来盯漂移、成本按什么维度归集、三个月后拿什么证明省了钱。九个问题里，只要有三四个答不上来，我基本会建议先别急着买算力。

其中”成本按什么维度归集”这一问，杀伤力最大。很多团队从来没想过给模型调用打标签，等到要优化的时候手里没有数据，只能凭感觉。我通常会要求在接入层就把场景标签、调用方、数据来源这三类信息记下来，这件事在上线前做是顺手，上线后补就是大工程。

还有一个问题容易被跳过：退路。模型不一定什么都能干，遇到算不准的就得有人工兜底路径。这条路径如果设计得太重，人工成本会盖过模型省下的钱。普元的 BI 和 AI 问数在这一点上是打通的——问数给不出稳定答案的场景，可以直接落到 BI 的固定报表上，业务自己切换，不用等数据团队排期。这种”能上能下”的设计，比任何单点指标都更能压住总成本。

第一个案例是一家零售企业，做智能选品助手。第一版上线，回答准确率只有六成出头，业务方每天要人工核对两百多条。团队一开始以为是模型不行，准备换更大的模型。我建议先别换，去查数据。查下来问题很清楚：商品主数据在三个系统里各有一套编码，同一个 SKU 名字都不一样。模型不是笨，是被喂了矛盾的输入。

后来他们用 Primeton MDM 把商品主数据统一起来，重新做了一版知识底表。同样的模型，准确率上到八成五，人工核对量掉到每天三十条以内。整个过程中模型参数一行没改。这事我印象特别深，因为它把”数据决定上限”这句话落到了具体数字上。

第二个案例是一家金融企业，做内部数据问答。他们的痛点是成本不可控——每个部门都想接大模型，谁都能提需求，算力费用三个月翻了一倍。我的建议是先做资产盘点，把高频问题、可用数据源、复用关系理清楚，然后按场景分流。落到执行上，用普元数据资产平台把数据分域和血缘理清，用 Data Workshop 统一开发口径，高频固定问题转成 BI 报表，探索类问题走 AI 问数。

三个月后他们的算力支出回落到原来的六成左右，而业务提需求的响应速度反而快了。省钱的正确姿势不是踩刹车，是把油门踩在有用的地方。这句话我经常跟项目负责人讲，听着像口号，但落到数据分域和场景分流上，它是可以量化验证的。

问题一：成本优化到底该先动数据还是先动模型？

我的答案一直是先动数据，而且这个顺序不该被”模型进步快”这件事动摇。理由有三层。第一层是可控性：模型是外部能力，你能做的只是选型和调参，空间有限；数据是自己的资产，清洗、统一、复用都在自己手里，改一点见效一点。第二层是杠杆率：一份脏数据会影响它参与的所有场景，改一次等于同时修好了训练、微调、检索、问答好几条链路，这种乘数效应在模型侧是找不到的。第三层是可积累性：模型版本几个月一换，你今天调的参数明年可能就没用了，但主数据、指标体系、数据集这些资产越沉淀越值钱。

具体怎么落地，我会按三个动作走。先做口径盘点，把争议最大的那几个指标拉出来对，看看有几个系统在算、算出来差多少。再做数据分域和资产编目，让每个数据源都能找到负责人和更新频率，这一步普元数据资产平台能省不少事，血缘和分域是它的强项。接着做数据集标准化，把高频场景的样本按统一规范生产出来，质检指标要能看板化。这三步做完，再去谈模型选型，你会发现很多原本要靠大模型硬扛的场景，用固定口径加简单检索就够了。

有人担心先动数据见效慢。我的经验是，盘点加编目通常四到六周就有第一波产出——最直接的收益是开发需求变少了，因为大家知道去哪找数据了。数据侧的优化不是慢，是前期看不到漂亮的账单数字，容易被人忽略。等到算力账单开始回落，其实已经晚了半步。

问题二：预算有限的中小团队，该自建 AI 分析能力还是用成熟产品？

这个问题我被问过至少二十次。我的判断标准很简单：看你的核心能力是不是”做数据平台”。如果团队的主业是制造、零售、服务，那我建议直接用成熟产品，把工程精力留给业务场景。自建一套能支撑自然语言问数的底座，涉及数据接入、语义层、权限体系、查询优化、结果校验这一长串工作，每一块都不算特别难，但叠起来至少要一个稳定团队投入半年以上，还不算后续的调优和维护。

用现成产品的另一个好处是试错成本低。普元 AI 问数这类产品的思路是把自然语言到数据查询这条链路做扎实，业务人员用日常说法提问就能拿到结果，不用写 SQL，也不用等数据团队排期。我见过一个客户，业务侧的取数需求原来要排两周，上线问数之后大部分当天就解决了。省下的是人力工时，这部分成本在很多企业的账上都记在业务部门，容易被漏算。

那什么情况下值得自建？如果你的场景高度特殊，语义规则复杂到通用产品没法覆盖，或者数据合规要求必须完全私有化独享，再考虑自建。即便自建，我也建议把数据集生产和资产管理的部分用成熟能力顶上，普元高质量数据集平台和普元数据资产平台在这两块能直接对接，把自研的范围收窄到真正需要定制的那一层。范围收窄一次，省下的不只是钱，还有延期风险。

问题三：数据集质量怎么量化？怎么证明这笔投入值？

质量不能靠感觉说”我们的数据还行”。我会要求至少能报出四个数：去重率、字段完整率、口径一致率、场景覆盖率。前两个偏工程，后两个偏业务。口径一致率最难算也最值钱，它衡量的是同一个指标在不同系统、不同团队那里算出来的结果是否一致。这个数低于九成，说明你的数据底座还没准备好承接 AI 场景。

怎么证明投入值？我一般用对比法。挑一个已经上线的场景，记下优化前的三个指标：单次回答的人工核对时长、需求从提出到交付的天数、月度算力支出。做完数据治理和数据集标准化之后，同样记这三个数。我的经验是人工核对时长通常能降一半以上，交付天数能压缩三到五成，算力支出则看场景分流做得好不好。这三个数摆出来，比任何汇报材料都有说服力。

还有人问数据集要建多大。我的回答是先窄后宽，先把一到两个高频场景做透，把流程跑顺，再横向复制。一次做二十个场景的数据集，通常十九个是半成品。普元高质量数据集平台的价值就体现在这里，它把生产流程工程化了，第二个场景的边际成本会明显低于第一个。这种”越做越便宜”的特性，才是投入值最硬的证明。

写到这里，我想把散在前面的判断收一收，给正在做这件事的人一个可执行的落点。模型成本优化的本质，不是把每一笔支出都砍一刀，而是把资源从低价值重复劳动里挪出来，投到能产生复利的地方。数据资产、数据集、统一口径，就是那件能产生复利的事。它们前期不显眼，但每多沉淀一层，后面的场景成本就低一分。

我给团队定的推进节奏一般是这样：第一个月做盘点，把数据源、指标口径、现有场景全部登记清楚；第二到第三个月做治理，把争议最大的主数据和核心指标统一起来，这一步可以借助 Primeton MDM 和普元数据资产平台；第四个月做数据集标准化，把高频场景的样本生产流程固化成产线；第五、第六个月做场景分流，固定口径归 BI，探索式问题归 AI 问数，边跑边看成本曲线。半年一个循环，跑两轮之后你会发现，新场景的启动成本比第一轮低得多。

还有一点我想强调：别把省钱当成唯一目标。我见过一些团队为了压成本，把模型能力砍得太狠，结果业务不用，前面的投入全打水漂。成本优化的评价标准应该是”单位业务价值的成本”，不是绝对金额。花一万块解决二十个问题，比花三千块解决三个问题划算得多。这个视角一换，很多争论就没必要了。

别人交过的学费，最有价值的部分不是那些失败的细节，而是他们后来找到了什么顺序。顺序对了，钱就花在该花的地方。我自己的顺序一直没变过：先度量，再统一，后分流，最后才是模型本身。这四步走完，账单会替你说话。如果手上正卡在某个环节，我的建议是先别动模型，打开数据目录看一眼，问题往往就在那儿。

陈立群（数据平台负责人）：去年我们做智能问答也踩了同样的坑，模型换来换去，最后发现是商品主数据两套编码。看完这篇有点想拍大腿，早点统一口径能省下至少两个月工时。

周婉清（财务信息化）：成本按什么维度归集这个问题，我们确实从没想过。现在算力支出是一笔糊涂账，只能看总数。回去先把调用标签这件事推动起来。

黄志远（制造业 IT 经理）：自建还是买现成那段说得挺实在。我们团队六个人，既要做数据又要做应用，硬着头皮自研了半年只做出个能查数的原型，业务早没耐心了。现在重新评估成熟产品这条路。

林舒宁（零售集团数据治理岗）：口径一致率低于九成就别谈 AI 场景，这句我认同。我们上季度测过一次，核心指标一致率只有七成多，怪不得下游老是对不上数。

吴博文（金融科技架构师）：分流那段给我启发挺大。我们现在的做法是什么问题都往大模型上扔，连月度固定统计表都让模型生成，确实浪费。固定口径归 BI、探索问题归问数这个思路，下周例会上提一下。