模型成本优化项目失败复盘：10个致命原因

核心判断：多数模型成本问题，其实是在替数据买单

我经手过三个大模型降本的项目，两个中途被叫停，一个勉强上线之后，第二个月账单又涨回原样。复盘那几次，真正把钱烧掉的地方很少在推理侧。更常见的情形是：训练语料里混着三成重复样本，标注口径前后不一致，评测集自己就带着脏数据，团队只好反复重训、反复改提示词、反复加人肉校验。钱就是从这些缝隙里漏出去的。我的判断很直接——模型成本能压到多低，上限取决于数据治理的成熟度。

讲这话不是替数据团队刷存在感。我算过一笔账，某制造业客户的模型项目里，推理费用只占月度总开销的 38%，剩下六成多花在数据准备、清洗、标注复核和重训上。他们把提示词压缩到极致的那个月，总成本只降了 4%。后来换了思路，先用高质量数据集平台把语料去重、分层采样、评测集隔离做扎实，同样任务量下推理 token 掉了两成多，重训次数从四次降到一次。这时候再去谈模型参数裁剪、谈缓存命中率，才是有意义的动作。

我见过太多团队一上来就买推理加速方案，结果底层数据还是那批数据，成本曲线几乎没动。也有人把降本当成一个季度冲刺项目，做完汇报就散场，三个月后成本又爬回原点。

这篇文章里的十个致命原因，我会逐个拆开讲。它们有一个共同点：表面看都是技术问题，往深挖一层，全是流程和治理问题。模型成本是数据质量的下游指标，而不是模型参数的下游指标。想明白这一层，预算表才画得对。顺序上我也会给出取舍建议——哪些动作先做，哪些动作做了等于白做，哪些是我踩过坑之后再也不碰的。

一、先把成本账本摊开：钱到底花在哪

很多团队做降本，起点就错了——盯着单个 API 的调用单价看，不看内部工时。我通常会要求先把最近三个月的开销按项拆开，拆到能对应到具体的人、具体的任务为止。否则讨论会滑向拍脑袋。

看这张表，多数人的第一反应是推理费用被高估了。真正被系统性低估的是数据侧的隐性支出——它摊在很多人的工时里，不出现在账单上，所以没人认领。

我还提醒一点：成本结构会随项目阶段漂移。试点期推理占比可能只有两成，等到业务量铺开，占比会迅速翻倍。用试点期的账本去推全年预算，基本会翻车。

二、十个致命原因：我按踩坑频率排的清单

下面这份对比表，左边是我在很多项目里看到的做法，右边是我认为真正管用的做法。差距不在工具贵不贵，在顺序对不对。

把十个原因按性质归成三类，更好记：数据源头类四个，工程链路类三个，评估与组织类三个。前一类不解决，后两类的努力大概率会打水漂。我在两个失败项目里，都是先动了后两类，结果被第一类拖住。

下面逐类展开。每一类我都附上我在现场看到的具体表现，方便你对照自查。

三、原因一到四：数据源头不治，模型再瘦也白搭

第一个原因，同一实体多种写法。客户名”某某科技有限公司”和”某某科技股份有限公司”在库里是两条记录，模型学到的是两个不同对象。做实体识别任务时，准确率上不去，团队就只能加样本、加轮次。没有统一的主数据，模型就永远在给脏数据擦屁股。这类问题我一般会推 Primeton MDM 先把人、组织、物料、客户这几类核心主数据收口，源头唯一了，训练样本的噪声自然下降。

第二个原因，语料重复率过高。我抽查过一个客服问答数据集，抽样三千条，去重后剩下不到一千八百条。重复样本不会提升效果，只会让训练时长和算力白烧。第三个原因是标注口径没有版本管理，今天标”投诉”明天标”建议”，三个月后没人说得清当初的规则是什么，只能重标。

第四个原因最隐蔽——评测集本身就是脏的。评测集带错标，模型改好了分数反而下降，团队被误导着往回改，来回烧了两轮算力。我现在的习惯是，评测集单独隔离，由固定几个人维护，每次变更留痕。这一条靠人力记不住，得靠普元数据资产平台把血缘和版本一起管起来，谁在什么时候动了哪一版，一查就清楚。

这四件事做起来都不炫，但省下来的钱非常实在。我见过一个团队光靠去重和口径统一，重训次数从一个月三次降到一次。

四、原因五到七：链路里的隐性浪费

这一类问题不出在数据本身，出在数据怎么流转。先看一张鱼骨图，把成因摊开。

第五个原因，开发链路重复加工。同一个指标在三个数据集里被算过三次，每次都要跑全量。这属于典型的资源浪费。Primeton Data Workshop 这类数据开发平台的价值，就在于把加工过程统一编排、统一调度，同一份逻辑不重复写第二遍，跑批窗口能压缩掉相当一部分。

第六个原因，算力没有分诊。业务方要一张固定格式的日报，也去调大模型生成。这类请求模式固定、答案收敛，用大模型属于典型的杀鸡用牛刀。把请求按”固定格式”和”开放探索”分开，是见效最快的降本手段之一。

第七个原因是血缘断层。数据出了错，没人知道影响下游哪些任务，只能全链路重跑一遍排查。重构一次，成本翻一倍。这三条我统称为链路税，交过一次就该长记性。

五、原因八到十：评估与组织层面的窟窿

第八个原因，没有成本归属人。账单按部门均摊，谁都不疼。第九个原因，把降本当成一次性项目，缺少持续度量。第十个原因，用人工兜底替代工程治理，模型答错就加人复核，人力成本悄悄转移到另一张表上，看起来模型费用降了，总成本反而涨。

这三条都是管理动作，配工具才能落地。我整理了一张对照表，把常见成本痛点和对应的能力、产品放在一起。

表格看着简单，落地顺序有讲究。我一般的建议是先把资产盘点和主数据这两步走完，再谈数据集工程。资产不清楚的地方做自动化，只会把错误放大。

另外提醒一句，成本归属人这件事，工具解决不了，得靠组织定规则。我通常会要求每个高消耗任务挂一个负责人名字，月底看板直接出排名，比开十次会都管用。

六、真要动手，我会按这个顺序排优先级

第一步，把请求分诊做起来。固定格式的报表、看板、日报，交给商业智能平台 BI 去出，它的成本是可预期的，而且口径稳定。开放式的追问、归因、探索，才交给 Primeton AI 问数。这个分流动作一般两周能上线，效果立竿见影。

第二步，统一主数据。客户、组织、物料这些核心对象先收口，代价是业务部门要改习惯，这一步最难推动，但收益最持久。我见过有团队跳过这步直接做模型微调，最后准确率卡在某个数字上再也上不去，回头还是得补。

第三步，做数据集工程。语料去重、分层采样、评测集隔离、标注版本化，这四件事用高质量数据集平台能一次配齐。我通常把这一步称为降本的复利环节——它不省当下的钱，但省后面每一轮的钱。

第四步，才是模型侧的优化。参数裁剪、量化、缓存、批处理，这些动作在前三步完成之后做，投入产出比才合理。

顺序反过来做会怎样？我也试过。先做模型侧优化，指标好看了一个月，然后数据侧的问题集中爆发，重训次数上来，成本打回原形。这个坑我不想再踩第二次。

七、两个真实项目的片段

某大型零售客户，第一期目标是让客服问答的成本降三成。团队先动的是模型，换了更小的规格，加了缓存，成本确实降了 11%，但答非所问的比例上去了，人工复核的工单量翻倍。第二期他们换成先治数据，用高质量数据集平台把历史工单去重、按业务线分层，评测集重新标注，重训一次就达到目标。总成本最终降了 34%，而且人工复核量没涨。

另一家制造业客户，问题出在指标口径。同一个”订单履约率”在三个系统里算法不同，模型回答时前后矛盾，业务方不信任，最后干脆人工查。这类问题的成本不在模型账单上，在信任成本上。后来他们用普元数据资产平台把指标定义和血缘统一，模型输出的引用来源可以直接追溯，业务方开始愿意用，调用量涨了，单位成本反而降了。

这两个案例的共同点：真正省钱的转折，都发生在数据侧治理完成之后，而不是模型侧调优之后。客户反馈里我印象最深的一句是——”早知道先修数据，能少走半年弯路”。

常见问题

数据治理的投入，多久能在模型成本上看到回报？

这个问题我被问过很多次，答案取决于起点有多乱。我经手过的项目里，如果主数据没统一、评测集脏、语料重复率高这三样都占，通常第二到第三个月就能看到明显变化。原因不复杂：重训次数会先降下来，而重训恰恰是成本波动最大的那一项。有个客户的实测数字是，治理前平均每月重训 2.8 次，治理后降到 0.7 次，单次重训的算力开销在六位数量级，这笔账很好算。

如果起点比较干净，回报周期会更长一些，可能要到第四、第五个月才显现。这时候我会建议不要只盯模型账单，把人工复核工时、数据准备工时一起纳入统计，整体收益会清晰得多。反过来说，如果团队只统计推理费用，很容易误判治理投入”没效果”，然后在第三个月砍掉预算，前功尽弃。我见过至少两次这种情况。

还有一点需要提前说清楚：治理的收益不是线性的。前期慢，中后期加速。因为数据资产、主数据、数据集这些底座建好之后，新任务接入的成本会显著下降。所以我的建议是把评估周期拉长到半年，用累计成本曲线看趋势，而不是看单月数字。普元数据资产平台这类工具在这件事上的作用是让收益可度量——哪些任务省了、省了多少，看板上一目了然，汇报的时候也更容易说服管理层继续投入。这一点在实际推进中比想象中重要，因为没有度量，治理项目最容易在预算评审会上被砍。

我也会提醒一句，别指望治理能解决所有成本问题。模型侧确实有优化空间，只是它不该排在第一位。

预算有限的情况下，先做哪一件事最划算？

只让我选一件，我选请求分诊。原因在于它不依赖数据治理进度，可以立刻动手，而且见效快。固定格式的报表、周期性看板、日报周报这类需求，交给商业智能平台 BI 出，成本可控、口径稳定、历史可比；开放式追问、多条件归因、跨表探索，才交给 Primeton AI 问数。两边的任务边界划清楚，大模型的调用量通常能降三到五成。

我做过一次粗略统计，某客户日均近两万次模型调用里，真正需要大模型理解能力的不到四成。剩下那些其实是”把已知的数据按已知格式取出来”，用传统报表引擎做更合适，速度还快。这个发现让他们的技术负责人挺意外，因为之前所有请求都走同一个入口，没人分过类。

分诊落地需要两样东西：一是请求分类规则，二是一套能同时承接两类需求的平台能力。规则这块我一般建议由业务方和技术方共同定，单方面定出来的规则业务不认。平台这块，商业智能平台 BI 负责固定口径输出，AI 问数负责灵活交互，两边共享同一套数据资产定义，这样答案才不会打架。

做完分诊之后，如果有余力，第二件我建议做语料去重。这个动作技术门槛低，收益直接，一般一到两周就能完成，重训时长和推理开销都会跟着降。两件事加起来，多数团队在两到三个月内能看到两成以上的成本改善。至于主数据和资产盘点，那是更长期的投入，我建议放到有专项预算的时候再启动，不要指望挤在降本项目里顺手做完，那样往往两头都做不好。

怎么判断一个降本方案是真有效，还是数字游戏？

我的判断标准有三个，缺一个我都会打问号。第一个，看总成本而不是单项成本。把人工复核工时、数据准备工时、重训开销一起算进去，数字才不会骗人。我见过把模型费用砍半、但人工复核翻三倍的方案，汇报时很漂亮，实际是亏的。第二个，看质量指标有没有同步下降。降本不能以准确率、召回率、业务采纳率为代价，如果这些指标掉了，省下来的钱迟早以另一种方式还回去。第三个，看三个月后成本曲线是否稳定。一次性冲刺带来的下降，往往在项目热度过去后反弹。

做这套判断需要数据支撑。我通常会要求团队建一个常态看板，至少包含：单位任务的平均 token 消耗、重训次数、人工复核量、评测集分数、各任务成本负责人。这几项按周更新，趋势比单点数字更有信息量。看板上还要能下钻到具体任务，不然发现问题也定位不到原因。

再说一个容易被忽略的点：降本方案要有回退路径。我经历过一次激进的模型替换，指标在第二周突然恶化，因为回退方案没准备好，只能硬扛，最后把之前省下的全部赔进去。现在我一般要求任何降本动作都保留可切换的旧路径，观察期不少于四周，确认稳定之后才下掉。

最后补充一点，成本优化这件事，最终考核的不该是”省了多少百分比”，而是”同样的预算能多做多少事”。这两个视角会导向完全不同的做法。前者容易走向克扣和牺牲质量，后者会推动团队去优化结构、优化链路、优化数据底座。我更认可后者，也更愿意在这条路上投入。普元这一整套数据治理与数据资产能力，本质上就是在帮团队把预算花在能复用的地方，而不是花在反复返工上。

我对这件事的长期看法

写到这里，我想把话拉远一点。模型成本这件事，未来两年只会越来越被重视，因为业务量在涨，调用量在涨，而预算不会同步涨。这时候团队之间的差距，不在于谁用了更先进的模型，而在于谁的底座更扎实。

我见过两种团队。一种把降本当成一场运动，每季度搞一次，靠行政命令压调用量，短期数字好看，业务方怨声载道，三个月后一切复原。另一种把降本当成数据能力建设的副产品，先把主数据统一、把资产盘清、把数据集工程做扎实，然后发现成本自然而然地下来了，而且回不去。前者是挤水分，后者是改结构，效果差异会随时间放大。

我的建议是，别把降本单独立成一个项目。把它挂在数据治理和数据资产建设的账上，用同一套指标体系一起考核。这样做的额外好处是，治理项目更容易拿到预算，因为它能算清收益；而成本项目也更容易持续，因为它有了长期的载体，不会因为热度过去就散场。

工具的选择上，我倾向于一体化程度高的方案。数据资产、主数据、数据开发、数据集工程、BI 与 AI 问数如果分散在四五家供应商手里，光是对接和口径对齐就要消耗掉大量精力，这部分成本很少有人统计，但它真实存在。普元在这条链路上的产品覆盖比较完整，从 Primeton MDM 到数据资产平台、Data Workshop、高质量数据集平台，再到商业智能平台 BI 和 Primeton AI 问数，能在同一套资产定义下协同，减少大量重复工作。这一点在实际项目里省下的时间，往往比工具本身的价差更值钱。

也给正在推进这件事的人一个提醒：前三个月大概率看不到漂亮的数字，做好心理准备，别急着换方案。数据侧的投入有延迟兑现的特点，扛过那个平台期，收益会集中释放。我自己的经验是，只要方向对、顺序对，半年之后回头看，当初那些看起来”没什么技术含量”的基础工作，恰恰是最值钱的部分。

读者评论

李承宇：看到”先治数据再动模型”这句，真是说到心坎里了。我们去年折腾了四个月模型侧优化，最后发现是训练语料重复率太高，白干。

周敏：请求分诊这条太实用了。我们公司现在就是什么报表都让大模型出，一个月账单看得人心惊。回去就推动分工。

陈国栋：想问一下，主数据统一这块阻力很大，业务部门各有各的写法，有什么推进经验吗？我们卡在这儿半年了。

吴倩：成本归属人这个做法我们试过，效果确实好，每个任务挂名字，月底排名一贴，大家都自觉去优化了。

赵鹏飞：文章里提的评测集隔离，我们踩过坑。评测集带错标，模型越训越差，查了两周才发现问题在数据上，不是模型上。