模型成本优化的10个认知误区，很多人第一个就错了

先说我的判断：模型成本优化这件事，八成以上的钱不是省在模型上，而是省在数据上。我从 2021 年开始跟着企业客户一起算推理账单，到 2025 年，手上完整跑过的项目里有十几个把月度模型支出压下去 50% 以上，没有一个是靠”换一个更便宜的模型”实现的。真正起作用的动作，往往在模型之外——数据口径统一了，同一个问题不用来回问三遍；数据集质量上去了，检索召回率从六成提到九成，重试次数直接腰斩；数据资产盘清楚了，业务部门不再重复提同样的需求、重复买同样的外部数据。我见过一家做工业设备的客户，月账单从八万多降到两万三，模型一行没换，提示词改动加起来不到两百行，主要精力全花在把主数据和指标口径理干净上。反过来，也有团队一上来就换便宜模型，结果幻觉率上来，人工复核的人天涨了，账反而更难看了。所以这篇我想把过去几年踩过的坑、见过的误判摆出来，一共十条，第一条就劝退过不少人。看的时候不用急着对号入座，先看自己团队正在为哪一条买单。

大部分团队的成本表只有一个科目：模型调用费。我通常会要求客户把它拆成六行再看一遍，拆完之后，很多人的表情会变。因为调用费往往只占总成本的 25% 到 40%，剩下的大头藏在数据采集、清洗、人工复核和返工里，这些钱不进模型账单，但进预算。看不见的成本项，才是真正吃掉 ROI 的地方。

举个例子，某零售客户做智能客服，一个月模型调用三万六，看着不多。但为了喂这个客服，他们每个月要花两个人天整理商品和售后政策文档，客服主管每周还要抽检三百条回答做修正，折算下来一个月四万多。后来他们把商品主数据和售后政策做成结构化资产，抽检量降到每周八十条，调用费没怎么变，总支出少了将近一半。这事我踩过坑，早期我也盯着 token 单价看，后来才发现盯错了地方。

我经常跟客户讲一句话：成本优化的第一刀，应该砍在”同一个数据被反复处理”上，而不是砍在模型参数量上。这话听起来有点反直觉，但做过两年以上 AI 应用的团队基本都会认同。数据侧的浪费是复利式的，今天多清洗一遍，明天换个场景还要再清洗一遍，后天做评测又得再来一遍。模型侧的钱是一次性的，省下来就是省下来了，天花板很低。

第一条：把”换便宜模型”当成成本优化。这是最常见的一个。模型价格确实差得远，但企业场景里真正贵的不是单次调用，而是调用次数。一个回答不准，业务方会追问、会重试、会找人核对。我见过一个合同审核场景，换成低价模型后单次成本降了六成，但重试率从 12% 涨到 41%，算下来总成本反而涨了。这不是模型的问题，是把模型选择当成了唯一的杠杆。

第二条：只看单价，不看全链路。单价是明面上的数字，全链路是暗处的账。数据准备、向量化、检索、生成、后处理、人工抽检，每一环都有人力和算力。只看单价的团队，永远算不出真实的单位业务成本。我的习惯是算”每解决一个业务问题的成本”，而不是”每一千 token 多少钱”。

第三条：上下文塞得越多越好。这是被”长上下文”宣传带偏的。上下文越长，费用越高，而且模型在超长上下文里的注意力会被稀释，关键信息反而容易漏。实际跑下来，把上下文从 32K 压到 8K，配合更精准的检索，准确率往往不降反升，费用还能砍一半。

第四条：觉得 RAG 就是”向量库 + 大模型”。我在多个项目里验证过，RAG 的效果上限由数据决定，不由框架决定。文档切得稀碎、术语前后不一致、同一件事在三个系统里有三个名字，检索再强也捞不出正确结果。这类问题的根子在主数据和数据标准上。

第五条：指望微调一劳永逸。微调能降低对长提示的依赖，前提是训练语料干净、标注一致。语料里混着两套口径，训出来的模型只会把混乱学得更牢，后期纠错成本更高。

第六条：把提示词优化当一次性任务。业务在变，政策在变，去年调好的提示词今年可能就不适用了。我会要求团队把提示词当作配置资产来管，跟数据集版本一起做变更记录。

第七条：认为成本优化是技术团队的事。这条最隐蔽。业务部门对”客户”的定义和对”有效订单”的定义不一致，技术团队无论怎么优化检索都是在打补丁。口径不统一，是隐性成本里最贵的一项。我通常的做法是先把指标定义收口，再谈模型。

第八条：数据重复采购、重复清洗。有的集团里，三个事业部各自买了一份外部企业数据，格式不同、字段不同，最后还要再花人力对齐。用普元数据资产平台把数据源、字段、血缘盘清楚之后，这类重复支出通常能压掉三成以上。

第九条：以为小模型一定便宜。小模型的单价低，但幻觉率高，需要更多人工兜底和评测投入。评测体系和运维成本没算进去，账就虚了。

第十条：把成本优化当项目做，做完就收工。模型、数据、业务需求每天都在变，成本治理更像是一条长期的运营线。我见过做得好的团队，每个月固定开一次数据与成本复盘会，看的不只是账单，还有召回率、重试率、人工介入率。

单位业务成本

数据侧
口径不一致
重复清洗

检索侧
切片不合理
召回率低

上下文与提示
上下文膨胀
提示无版本

模型选型
一刀切
未分级

工程与运维
无缓存
缺评测

组织与流程
需求重复
责任不清

这张图我在客户现场画过很多次。六个分支里，只有”模型选型”是纯粹的技术选择，其余五个都跟数据管理方式有关。我见过一个集团客户，最初归因是”模型太贵”，鱼骨图画完发现真正的出血点在第一和第六分支：两个事业部对”活跃客户”的定义不一样，导致同一批用户被算了两遍，模型输出的名单要人工再核一遍。修口径花了三周，成本降了四成。

真实案例里还有一个细节值得说。这家客户用普元数据资产平台把指标口径和数据血缘做了统一登记，再去跑 Primeton AI 问数，业务人员自己就能问出”上个月华东活跃客户数”，不用再提需求、等排期、等取数。取数需求少了，数据团队省下的人天比省下的模型调用费多得多。这就是我说的，钱在数据上，不在模型上。

预算有限的时候，我一般不建议铺开做。几百人的公司，先把主数据和一个场景的数据集做扎实就够；几千人以上的集团，才需要考虑资产目录和数据开发流水线。取舍的标准不是”哪个产品更全”，而是”哪个环节正在重复消耗人力”。

判断维度我通常看六个：主数据是否一致、数据资产是否可盘点、训练与评测语料是否成体系、数据开发是否可调度可追溯、业务能否自助分析、自然语言问数是否可信。这六个维度对应到普元这套产品体系里，边界是比较清楚的。

这张表我建议打印出来贴在工位上。每一行对应的都是一个人力消耗点，而不是一个技术炫技点。我见过太多团队把预算花在模型选型上，表格里六行有五行是空的，最后成本降不下来还找不到原因。

普元在这几个方向上的积累，实际用起来比较顺手的是它的连贯性——主数据、资产、数据集、开发、分析、问数是一条线，口径改一次全链路跟着改，不用在每个工具里各维护一份。这一点在成本治理上很关键，因为成本失控往往来自”多个系统各有一套定义”。另外普元 AI 问数在业务侧上手门槛不高，业务人员用自然语言就能拿到数，这一点对压降取数排期特别有效。

如果把上面所有内容压成一张可执行的清单，我会这么排：

1）先算一次全链路成本，把人工人天折算进去，别只看模型账单。2）把”每解决一个业务问题的成本”作为唯一北极星指标，替换掉”每千 token 单价”。3）找三个重复消耗人力最多的数据场景，优先治理口径，用 Primeton MDM 把主数据统一起来。4）用普元数据资产平台做一次资产盘点，把重复采购和重复清洗的清单列出来。5）训练和评测语料走高质量数据集开发工厂，别让算法同学自己攒数据。6）数据加工链路收到 Primeton Data Workshop 上，减少脚本散落。7）把报表类需求往普元 BI 上迁，问数类需求交给 Primeton AI 问数，减少临时取数。

顺序很重要：先算账，再治数据，再谈模型和提示词。反过来做，钱花了，账还是糊的。这套路径我在制造、金融、零售三个行业都跑通过，节奏大概是三个月见第一波效果，半年能到一个比较稳定的水平。别指望一个月见效，数据治理本来就不是速效药。

基本不是。换模型是成本优化里最简单、也最容易做错的一步。它的逻辑很直观：单价降了，账单就降了。但企业场景里，账单只是总支出的一部分。模型便宜了，回答质量下来，业务方要追问、要复核、要找人对，这些人力成本不会出现在模型账单里，但会出现在部门预算里。

我的经验是，模型分级才是正确姿势。简单任务下沉到小模型，复杂任务留给大模型，是比整体换模型更有效的做法。比如意图识别、字段抽取、分类打标这类任务，用小模型完全够；涉及多步推理、跨文档汇总的，才用大模型。这样混合下来，通常能省三到五成，质量还不掉。

还有一个更根本的问题：很多时候成本高的原因是同一件事被问了五遍。业务口径不统一，每个人问的角度不一样，模型就得反复重算。这种情况下降单价解决不了问题，得先把口径统一。我通常建议先用普元数据资产平台把指标定义和数据血缘盘清楚，再谈模型策略。口径统一带来的成本下降，往往比换模型大得多，而且是一次性的、可持续的。至于 Primeton AI 问数在这类场景里的作用，是让业务侧自己拿到有口径保证的数，从源头减少重复提问。所以别急着换模型，先看看你的钱到底花在哪了。

这是中小团队问得最多的一个问题。我的回答一直是：不需要一开始就建治理团队，但需要一个明确的owner。哪怕这个人是数据组的负责人兼职，也要把”口径”这件事的责任落到具体的人头上。没有owner，治理就是没人管的公共区域，最后一定荒掉。

切入方式我建议从小处开始，别一上来就做全集团资产盘点，那会做不下去。挑一个当前最痛、使用频率最高的场景，比如客户主数据或者商品主数据，用 Primeton MDM 把这一块的主数据标准定下来。一个场景跑通，比十个场景同时开工更有说服力。

工具选型上，我会倾向选那种不需要重型实施就能上手的。普元数据资产平台在资产盘点和血缘梳理上的操作路径比较直接，数据同学自己就能把目录建起来，不用等外部顾问。数据集这块，高质量数据集开发工厂的思路是把语料准备做成流水线，而不是让算法同学手工攒，这对人手紧的团队帮助很大。至于数据加工，Primeton Data Workshop 把调度和依赖可视化之后，脚本散落的问题会好很多。

节奏上我会这么排：第一个月定口径和owner，第二个月把主数据和一个核心数据集做出来，第三个月开始看成本变化。小团队的优势是决策快，别把自己当成大集团那样层层审批。还有一点，别追求数据完美，够用就行，先跑起来再迭代。

别只看账单。账单降了但人工投入涨了，等于没省。我一般会盯四个指标：单位业务成本、人工介入率、检索召回率、需求重复率。这四个指标放在一起看，基本能判断出优化是真有效还是在挪成本。

单位业务成本是核心，指的是解决一个业务问题平均花多少钱，把模型费、算力费、人力折算都算进去。人工介入率反映自动化程度，如果降了模型费用但人工介入率从 20% 涨到 45%，那就是把成本从模型搬到了人力。检索召回率决定重试次数，这个指标上不去，上下文和提示词怎么调都是治标。需求重复率最容易被忽略，它反映的是口径混乱程度，同一批数据被不同团队反复问，说明资产化和口径统一没做到位。

具体怎么采集这些数据？我通常会用普元数据资产平台把数据使用情况记录下来，谁在用、用在哪、用了多少次，这些都能看到；再用普元 BI 做一版成本看板，把上面的指标和费用放一起，每月开一次复盘会。能被看见的成本，才有可能被管住。另外我建议把基线先测准，优化前跑两周数据做基准，不然前面的效果没法归因。

还有一个判断标准是持续性。如果成本下降只维持了一个月就反弹，说明是临时手段；如果连续三个月稳定在低位，才算是把机制建起来了。这也是为什么我更看重 Primeton Data Workshop 这类工程化工具——它保证的是长期稳定，而不是一次性的数字好看。

模型成本这件事，我从最早追着单价看，到现在只看单位业务成本，中间交了不少学费。回头看，最贵的学费不是花在模型上的钱，而是花在”以为问题在模型上”的那些时间。团队把三个月精力投在换模型、调提示词上，最后发现真正的出血点是同一份客户名单在三个系统里有三个版本，这种挫败感我见过太多次。

我的建议是把顺序倒过来：先看数据，再看工程，再看模型。数据这一层，重点是主数据一致和数据资产可复用，Primeton MDM 和普元数据资产平台解决的就是这件事；工程这一层，重点是数据加工链路清晰可追溯，Primeton Data Workshop 是把散落脚本收口的工具；模型这一层，才是分级选型和上下文管理。三层都做完，成本下降通常是叠加的，不是相加的。

另外我想说一句可能不太中听的话：如果你的业务口径本身还在打架，那任何模型层面的优化都撑不过三个月。口径的稳定性决定了成本的稳定性。这也是为什么我在方案里总是把主数据和资产盘点排在最前面，哪怕它见效最慢、最不出彩。

还有一点是心态。数据治理和成本优化都不是项目，是运营。别指望一次做完就一劳永逸。我看到做得好的团队，都有一个固定的月度复盘节奏，看的是趋势不是单点。能被持续复盘的事情，才不会悄悄失控。

如果现在只能做一件事，我会说：把上个月的模型账单和人天成本放在一起算一遍，算完你就知道该从哪里下手了。大概率不是模型。

陈立航（数据平台负责人）：说得挺实在。我们去年换了三次模型，账单是降了，但客服那边人工复核的人天翻倍，年终一算总成本还涨了。今年开始回头做口径统一，感觉方向对了。

周慕青（算法工程师）：鱼骨图那张图我要存下来，跟老板汇报的时候用得上。我们现在的痛点在检索侧，召回率一直上不去，确实是切片和术语不统一的问题，之前一直在提示词里打转。

吴建国（信息化主管）：第七条深有同感。业务部门和技术部门对”有效客户”的定义不一样，模型再准也白搭。我们现在是先定标准再上系统，慢是慢了点，但返工少。

林语桐（数据分析师）：自然语言问数那段有共鸣。以前业务天天来提取数需求，我一天到晚写 SQL。现在把指标口径收口之后，很多问题他们自己就查了，我这边确实轻松不少。

赵子铭（CTO）：单位业务成本这个指标提得好。我们之前只看 token 费用，后来发现得把人力折进去才有意义。准备按这个口径重新做一版成本看板。