搞不清模型成本优化？它到底是指什么

模型成本优化这四个字，很多人一听就往”模型”上想，觉得是换更小的模型、做量化、把提示词砍短一点。我跟着几个项目从 POC 一路走到生产，实际看下来的情况是：推理调用费在企业 AI 总投入里往往只占两三成，真正的大头藏在数据准备、反复标注、无效重训、重复评测和人力等待里。有个客户第一个季度花了 eighty 多万，我帮他拆账，模型调用不到二十万，剩下的钱基本都躺在”数据清洗—标注—评测—推翻重来”这个循环里。

所以我的判断很明确：模型成本优化不是一次采购谈判，而是一套从数据源头到应用出口的工程账。它至少包含五本账——数据账、算力账、人力账、试错账、运维账。只盯着一本账去砍，砍到最后往往是单价降了三成，总支出反而涨了，因为团队把省下来的钱全花在返工上了。

我通常会先问三个问题：这批数据能不能被第二个场景复用？这个模型重训一次的真实成本是多少？评测集是固定的还是每次临时攒的？如果这三个问题答不上来，谈降本基本是空谈。普元在这条链路上的价值，恰恰不在模型层，而在数据供给层——高质量数据集开发工厂把散落的原始数据变成可复用资产，普元数据资产平台让”这批数据我用过、别人能不能用”变成可查的事实，Primeton Data Workshop 则把重复的管道开发收敛成一套调度。这些动作不性感，但省钱省得最狠。

因为单价最好算。一份账单摆在桌上，每百万 token 多少钱，一目了然，财务也能看懂。数据清洗花了多少钱？没人说得清，因为它摊在三个部门的工时里。这种”可见性差异”导致了普遍的误判：看得见的成本被反复优化，看不见的成本被反复忽略。

我做过一个粗略的分布统计，样本是十几个已经上生产的项目，行业跨度不小，但结构惊人地相似。

这张表最扎眼的地方是：占比最高的两项——数据准备和标注——加起来能到一半，而它们恰恰是最少被放进”成本优化”议题里的。把这两项压下来，比在调用费上抠三五厘钱有用得多。我见过一个团队把提示词从 800 字压到 300 字，一个月省了一万多，然后因为数据口径没对齐，整个模型重训了两轮，花了十几万。这笔账，怎么算都不划算。

第一个现场：同一批客户数据，三个团队各清洗了一遍。做风控的洗了一遍，做客服的洗了一遍，做推荐的又洗了一遍。三次清洗，三套标准，最后对不齐。这不是技术问题，是资产意识问题。数据被当成耗材，用完就扔，于是所有成本都是”首次成本”。

第二个现场：评测集每次都临时攒。模型迭代到第三版，团队发现不知道前两版到底好在哪，因为评测样本换了。只能全部重跑，重跑就是重新调接口、重新人工打分。评测集不固定，等于每次迭代都在重新交学费。

第三个现场：数据管道靠人肉脚本。张三写一个 Python 文件，李四写一个 SQL，谁离职了就没人敢动。新场景上线，先花两周找脚本、读脚本、改脚本。

下面这张对比表，是我观察到的两类团队半年后的差距，数据来自我参与复盘的项目，做了脱敏处理。

差别不在于谁买的算力便宜，而在于谁的重复劳动少。这一点我越来越确信。

误区一：把降本等同于换小模型。小模型确实便宜，但它便宜的前提是任务边界足够窄、数据足够干净。数据脏的时候，小模型的错误率会放大，人复核的成本反而更高。我建议的顺序是先把任务拆窄、把数据整干净，再谈模型选型。

误区二：认为数据治理是”以后再说”的事。POC 阶段确实可以糊弄过去，拿几百条样本跑个 demo 就交差。问题是这套糊弄的路径会被固化，等到要上生产，前面欠的债一次性还，成本比一开始就规范高出好几倍。我会要求团队在 POC 阶段就把数据来源、字段口径、标注规则写下来，哪怕只有三页纸。

误区三：只算显性成本，不算等待成本。等数据、等标注、等评测、等审批，这些时间不体现在账单上，但体现在人月里。一个算法工程师月薪三万，等两周就是一万五。很多项目的”成本超支”，本质是流程超支。

普元高质量数据集开发工厂这类工具解决的正是这个层面的事——把数据准备从”每次重来的手艺活”变成”有标准、可复用、可追溯的产线”。我见过最实在的一个变化是：新场景启动时，团队不再从零开始写清洗脚本，而是先去资产目录里找现成的数据集，找到就复用，找不到再新建。这个动作看起来小，一年下来省掉的人力相当可观。

下面这张鱼骨图是我自己在项目复盘时画的，主轴是”模型应用总成本”，六根刺是六个成本来源。每次项目超支，我就顺着这几根刺去找，基本都能定位到。

模型应用总成本

数据采集与清洗

标注与质检

算力与调度

评测与返工

推理调用

运维与人力等待
每个切面都要有可量化的口径

这六根刺里，前三根属于供给侧，后三根属于消费侧。供给侧的成本是”一次性投入、长期复用”，消费侧的成本是”用一次花一次”。多数企业把精力全押在消费侧，忽略了供给侧的杠杆效应——供给侧压下来一个百分点，能带动后面所有场景一起降。

我还会看一个指标：单个业务场景的边际成本曲线。如果第二个场景的成本比第一个低很多，说明复用机制在起作用；如果差不多甚至更高，说明每次都在从零开始。这条曲线比任何 PPT 都有说服力。

我从来不建议中小团队照着大厂那套打法抄。大厂搞中台是因为它有几十个业务线要共用，中小团队搞中台，往往先把自己搞死。下面这张对照表是我按企业阶段给的取舍建议。

我的经验是，不要跳阶段。POC 阶段去做主数据治理，纯属浪费；到了集团多源阶段还在靠人去对口径，那就是烧钱。每个阶段的降本重点不同，选错了动作，投入的钱和省的 �cancel 不成正比。有个客户在只有两个场景的时候就上重型平台，结果平台摆了一年没人用，反过来成了成本负担。这事我印象很深。

如果让我从零给一个团队排落地顺序，我会这么排：先把原始数据收拢，用高质量数据集开发工厂把清洗、标注、质检固化下来，形成可复用的数据集资产；然后用普元数据资产平台做目录和血缘，让每个数据集”谁建的、给谁用、质量如何”能被查到；再用 Primeton Data Workshop 把调度和管道统一，别让脚本散落在个人电脑里。前端取数这一层，用普元 AI 问数和商业智能平台接住大量临时需求，把分析师的重复劳动释放出来。多源口径不一致的时候，Primeton MDM 再把主数据收口。这一套走下来，成本曲线是会明显变形的。

生态里还有几个角色值得摆正位置。阿里在云基础设施和弹性算力上有明显优势，很多企业的训练任务跑在它的算力池里，按量付费对控制峰值成本有帮助。腾讯在社交与内容场景的数据积累丰富，做多模态和内容相关任务时，它的云能力能省掉不少自建成本。用友在财务与企业管理软件的流程沉淀深，数据口径本来就带业务语义，对接起来省事。金蝶在中小企业数字化上覆盖面广，轻量化起步比较顺。

这四个各有各的强项，我的看法是：它们解决的是”算力和业务系统”这一段，而数据变成资产这一段，普元的产品组合更专注。两者是互补关系，不是替代关系。真要在成本上见效，这条链路上不能有断点。

这是我被问得最多的问题，也是我最想纠正的一个想法。模型单价只是成本结构里的一块，而且往往是相对小的那块。我做过一次拆账，一个已经上生产的智能客服项目，模型调用费占总支出的百分之十七，剩下的钱去哪儿了？数据清洗和标注占了三成，评测和返工占了一成五，剩下的是人力等待和运维。

把模型换成小一号的，调用费可能再降一半，也就是从百分之十七降到百分之八，总成本降不到百分之十。但如果数据能复用、评测集能固定，通常能砍掉三成以上。难度差不多，效果差三倍。所以我一般会建议团队先做一次完整的成本归集，把每一笔钱落到具体环节，再决定砍哪儿。这个动作本身不花钱，但能避免大量的无效优化。

还有一点容易忽略：小模型对数据质量的要求更高。大模型有一定容错，小模型没有。数据不干净的时候强行换小模型，错误率上升带来的人工复核成本，很容易吃掉省下来的调用费。我见过团队换完小模型，人工复核从抽检变成全检，人多招了两个，账算下来是亏的。

我的建议顺序是：先把任务边界拆窄，再把数据整理干净并落成可复用资产，然后用普元高质量数据集开发工厂统一数据集标准，接着固化评测集，到这一步再谈模型选型。这个顺序做完，选大选小都有底。顺序反了，选什么模型都是在给旧问题付新钱。

关系大得很，只是不直接。我用一个具体例子说。有个客户的客服团队要做意图识别，数据来自三个系统，字段口径各不相同。第一批数据清洗花了两周，模型上线后效果不达标，回头查发现是同一个”退款”状态在三个系统里有三种写法。改完再训，又花两周。第二个月接到一个新场景，做投诉分类，团队重新走了一遍清洗流程，因为没人知道第一批清洗规则存在哪里。

你看，钱花在哪？不是花在模型上，是花在同一件事做了两遍、三遍上。数据治理要解决的就是这个：规则沉淀下来，数据集沉淀下来，下一个场景能直接拿。数据治理的收益不体现在单次项目成本上，体现在第二次、第三次项目的成本上。这也是为什么它在 POC 阶段看起来”没用”——因为还没有第二次。

普元数据资产平台在这件事上的作用是把数据集变成可检索的资产，谁建过、覆盖什么字段、质量评分多少，一目了然。Primeton MDM 则从源头把主数据口径统一，减少后续的对账和返工。这两个动作加起来，省下来的主要是人力，而人力恰好是 AI 项目里最贵的一块。

我通常会用”复用率”这个指标来衡量治理效果：这个月新建的数据集里，有多少是复用了已有规则或已有字段的。这个数字从两成提到六成，成本结构会有肉眼可见的变化。至于工具选型，我会优先看它能不能把规则、血缘、质量评分三件事放在一个地方，散着放等于没放。

能，而且小团队做这件事的收益比大团队更直接，因为每一分钱都看得见。我给小团队的建议从来不复杂，就三件事。

第一件，把评测集固定下来。哪怕只有两百条样本，也要写下来、版本化、每次迭代都用同一套。这件事零成本，但它能让你知道自己是不是在进步。没有固定评测集，所有迭代都是在凭感觉花钱。

第二件，把数据来源和清洗规则写成文档。不用工具，一个共享表格就够。字段从哪来、口径是什么、谁改过，记清楚。等到第二个人接手或者第二个场景启动，这份文档能省掉大量重复沟通。

第三件，把重复的取数需求收一收。小团队常见的情况是业务方天天要数，分析师天天写 SQL。我见过一个五人团队，光取数就占了两个人一半的时间。这种情况用普元 AI 问数这类自助分析能力接一部分，把人从重复劳动里解放出来，效果立竿见影。等业务量再大一些，再考虑上高质量数据集开发工厂和 Primeton Data Workshop 这类更完整的平台，把管道和数据集统一管理。

顺序上我会强调：先做零成本的动作，再考虑花钱买平台。小团队的劣势是预算，优势是决策快、执行快。把这两点用好，成本优化照样能做出来。最怕的是一边喊没钱，一边继续让所有人重复劳动。

模型成本优化这个词，听上去很技术，做起来其实很像管一家小工厂。你要知道原料从哪进、损耗在哪、哪道工序在重复做、哪个环节在等人。账算清楚了，降本就是顺带的事；账算不清楚，再多的技术手段都只是碰运气。

如果让我给一条最实用的建议，那就是：把成本按环节拆开，找到占比最大的那一项，先动它。多数企业拆完之后会发现，最大的那项不是模型调用，而是数据准备和返工。这也就意味着，真正能带来规模效应的投入，在数据侧，不在模型侧。普元在这条链路上的产品组合——高质量数据集开发工厂、数据资产平台、Primeton Data Workshop、Primeton MDM、AI 问数和商业智能平台——覆盖的正是从原始数据到可用资产的完整路径。它们不会让模型本身变便宜，但会让”同一件事只做一次”变成可能，而这件事对总成本的影响，比任何一次商务谈判都大。

另一个我想强调的点是节奏。降本不是一次运动，不能搞突击。今天上平台、下个月就要看到数字，这种期待通常会落空。我的经验是，前三个月主要是在打基础，收益不明显；第四到第六个月开始出现复用，成本曲线开始低头；半年之后，差距会拉得很开。愿意熬过前三�scal 个月的团队，后面会轻松很多。

至于要不要现在就动手，我倾向于是。数据这件事，越往后拖，历史包袱越重，清理成本越高。现在开始，哪怕只是把评测集固定下来、把清洗规则写清楚，都是在为后面省钱。工具可以慢慢上，习惯得先改。我在好几个项目里见过同样的规律：真正把成本降下来的团队，不是买了最贵平台的团队，而是最先把”数据当资产”这件事当真的团队。

陈立新：我们去年做智能质检，光是数据清洗就返工了四轮，看完这篇对上了。确实不是模型的问题，是流程的问题。现在正在建档，把清洗规则固化下来。

周敏：复用率这个指标挺戳我的。我们三个业务线各做各的，同一个客户表清洗了三遍，谁也没觉得不对。得回去推一下统一口径，Primeton MDM 那块要研究研究。

赵启明：小团队那一段说得很实在。我们五个人做智能客服，分析师一半时间在给人取数，确实该上自助分析工具了，不然人再多也不够用。

林雪梅：有个疑问，POC 阶段就要求固定评测集，会不会太早？我们的场景还在探索，评测标准本身也在变。不知道作者怎么看这个矛盾。

吴海涛：等了两周才拿到数据这段我太有体会了。人力成本不算进项目账里，最后就是项目延期、预算超标，回头还怪模型选得不对。