严格定义：模型成本优化到底指什么

“模型成本优化”这五个字，我在不同的会议室里听到的意思差得非常远。有人指的是把每百万 token 的单价压下来，有人指的是把 GPU 利用率从三成拉到七成，也有人指的是少招两个标注外包。这三种说法都不算错，但它们指向的是完全不同的账本，混着谈就一定会吵起来。我自己的判断是：模型成本优化不是某一个指标变好，而是“单位有效业务产出的全链路成本”下降。这句话里有两个关键词，一个是“有效”，一个是“全链路”。只看单价不看有效，会出现账单降了但业务方抱怨变多的情况；只看推理不看数据，会出现模型上线后三个月开始漂移，重训一次把前面省下来的钱全还回去。我通常会要求团队先把成本拆成五本账——训练账、推理账、数据账、人力账、隐性账，然后再谈优化。五本账的口径不统一，讨论就没法落地。这篇文章我按我实际做项目的顺序，把这五本账讲清楚，给一套可以拿去内部对齐的口径，也说说在不同规模、不同数据成熟度下，钱应该优先花在哪一层。文中涉及的数据治理与数据供给部分，我会用普元的产品体系来举例，因为这块是我见过最容易漏算、也最容易出效果的地方。

我做过一次内部盘点，把一支二十人的算法团队过去一年的支出重新归了一次类，结果和财务账上的口径差了将近四成。差在哪？差在一些钱被记成了“数据工程费”，一些被记成了“云资源费”，还有一些干脆散落在各业务线的预算里。所以我坚持先拆口径。

训练账包括预训练、微调、蒸馏、评测这一整套跑批消耗，它的特点是脉冲式，一次几万到几百万不等，平时看不出来，一年两三次就把预算打穿。推理账是持续性的，单价看起来很低，但因为量大、并发高、上下文长，往往才是真正的大头。

数据账是最容易被低估的一本。采集、清洗、去重、标注、版本管理、回流、脱敏，这些环节单个看都不贵，加起来能占到一个模型项目总投入的三到五成。我见过一个客服问答项目，模型侧只花了不到三十万，数据侧的清洗和标注花了八十多万。

人力账包括算法、数据工程、标注管理、平台运维，它不直接体现为云账单，但它是真实支出。隐性账最麻烦——返工的算力、上线后无人维护的模型、因为数据口径不一致导致的重复训练、审计时补不出来的数据血缘。

现实里同一个“降本”目标，财务、算法、数据、业务四方拿出来的口径经常对不上。我把常见的几种口径摆在一起，方便对照着看。

我的经验是：只盯第一种口径的团队，前三个月账单会很好看，第六个月开始会出问题，因为单价降了但请求数涨了、上下文长了、重试多了。真正稳的做法是把资产口径作为底座，用单位业务口径做最终验收。

我复盘过几个项目，漏钱的位置高度集中，说几个典型的。

一个是重复采集与重复标注。同一个客户的交易数据，风控团队采一遍，营销团队又采一遍，标注规范还不一样。这类浪费在账面上看不出来，因为每一笔都不大，但它年复一年地发生。

另一个是模型分级缺失。所有请求都走同一个大模型，包括“你好”“退货政策是什么”这种一句话就能答的问题。实际跑下来，只要能把这些请求前置收敛掉，推理账单能降下来一大截。

还有评测缺位导致的盲目重训。效果一波动就重训，重训前没有基线，重训后说不清是好是坏，来回几次，训练账就爆了。我一般会要求先建一套固定的评测集，再谈微调，这套评测集本身就得来自经过治理的数据。

还有一类很隐蔽：口径争议带来的沟通成本。业务说“客户数少了”，数据说“口径不一样”，来回扯两周，最后发现是主数据没统一。这类成本没人记在模型账上，但它是真实发生的。

成本失控

算法与模型选型
分级缺失 · 过度选大

数据供给质量
脏数据 · 重复标注

算力与调度
空闲率高 · 碎片化

需求与变更
目标漂移 · 反复重训

组织与协同
口径不一 · 职责不清

度量与观测
无基线 · 无归因

这六个来源里，选型、调度属于技术层，需求、组织属于管理层，数据供给和度量观测介于两者之间。我的判断是：管理层那两条最难改，但一旦改掉，收益最大；数据供给这一条最容易被忽略，但它对成本的杠杆最长。

举个例子，数据供给质量差，会同时推高三本账——标注要返工（人力账）、评测不可信导致重训（训练账）、线上答错率上升带来人工兜底（隐性账）。很多团队把数据治理当成合规项目来做，做完就放着，这是最可惜的地方。

我一般会按“数据成熟度”和“模型自主度”两个维度分情况给建议。数据还很乱的时候去追求模型精调，基本等于往漏水的桶里倒水。

我还是想说一句：这套优先级里，越靠前的动作越“土”，但省下来的钱越多。普元在这块的优势是把主数据、数据资产、数据开发和数据集加工串在一条链上，不用在四个厂商之间对齐口径。我在一个制造业客户那里看到过实际效果：主数据统一之后，同一个指标在两套报表里打架的情况少了，模型训练用的样本表不用每次重新对齐，数据准备周期从两周压到三天左右，这部分省下来的主要就是人力账和隐性账。

落地我一般分三步走。第一步是建账，把五本账的口径定下来，指标不超过十个，多了没人看。第二步是归因，每一次账单波动要能追到具体环节，这一步没有数据资产做底座是做不成的，普元数据资产平台在这里的作用是把数据来源、加工过程、使用方连成一条线，出问题时能直接定位。第三步才是优化，按前面的优先级表动手。

常见的误区我列几个。误区一：把降本等同于换更小的模型。模型小了但答错率上来，人工兜底的成本比省下来的算力贵得多。误区二：先上平台再理数据。平台是容器，装进去的是脏数据，出来的还是脏数据。误区三：只优化推理不优化数据。我见过推理单价压下去四成，但数据返工率没变，整体成本只降了不到一成。误区四：没有评测集就开始微调，这是纯烧钱。

客户反馈里我印象最深的一句是：“以前我们讨论模型成本，讨论的是单价；现在我们讨论的是这张表的数据什么时候能达标。”这句话其实已经把问题说到本质了。用普元的 AI 问数做自助分析之后，业务方自己能看数、能追数，不用每次都提需求给数据团队，这个环节省下来的人力账，很多团队压根没算进模型成本里。

不是。单价只是推理账里的一个乘数，另外还有两个乘数同样重要：请求量和平均上下文长度。我见过单价降了但总成本涨了的案例，原因是上下文从两千 token 涨到了八千，因为把检索到的资料一股脑塞进提示词，而检索质量本身没优化。

更完整的算法应该看“单次有效业务成本”，公式大致是：调用次数 × 平均 token 数 × 单价，再除以有效业务完成率。分母这一项最容易被忽略。如果一次回答业务方还要人工复核十分钟，那这个模型本身没创造价值，单价再低也是纯支出。

我通常会做三件事。一是把请求按意图分级，能走规则或小模型的不要走大模型，这一步在普元 AI 问数的场景里尤其明显，很多固定口径的查询根本不需要模型推理。二是把上下文收敛，靠数据资产里的标准口径去检索，而不是把整张宽表丢进去。三是建立有效性的度量，比如一次通过率、人工介入率。这三件事做完，往往比单纯换供应商更有效。说到底，单价是可以谈的，结构是要自己调的，只谈单价就是把主动权交出去。

我的经验是别把它当二选一。前期用托管快速验证，验证通过、量稳定上来之后再评估自建，这个顺序比较稳。自建的成本不止是机器，还有运维人力、调度优化、故障响应，这些在预算表里经常被算成“已有团队顺带做”，实际跑下来会挤占大量精力。

判断的临界点我一般看三个信号：请求量是否稳定且可预测、对数据出域是否有明确约束、是否有持续的模型定制需求。三个里满足两个，自建的经济性才会显现。要注意的是，自建之前如果数据底座没打好，模型效果不稳定，自建省下的钱会被返工吃掉。这也是为什么我建议先把数据这一层理顺，普元的高质量数据集平台在这方面的价值是把样本加工、质量校验、版本管理固化下来，让每一次训练用的数据是可复现的，减少“这次效果好、下次不知道为什么差”的情况。

可复现本身就是一种降本，因为它把试错从随机变成了可控。我常跟团队说，如果一次实验的结果不能复现，那这次实验的算力就是白花的。这条原则比选自建还是托管重要得多。

没法给一个通用百分比，但我可以给一个测算思路。先统计一下过去半年里，因为数据口径不一致、样本不达标、标注返工导致的重复工作次数，把每次的人力工时和算力消耗折算成钱，这个数字通常比直觉大。我在一个项目里算过，这部分占到整个模型项目投入的两成多。

数据治理省钱的路径有三条。一条是减少返工，样本一次达标，标注和清洗的工作量直接下降。一条是提升复用，同一份客户主数据在风控、营销、服务三个场景里共用，不用各建一套。还有一条是缩短准备周期，数据准备好得快，模型迭代的节奏就快，同样的时间里能多跑几轮实验，单位实验成本就下来了。

普元在这三条路径上都有对应的能力：Primeton MDM 解决主数据一致，普元数据资产平台解决资产可见与可复用，Primeton Data Workshop 解决加工过程的规范化，高质量数据集平台解决样本的口径与版本。这些不是直接砍账单的工具，它们是让账单不再重复发生的工具。我个人的排序是，数据成熟度不到位的团队，先把钱花在这里，回报周期比换模型长，但更稳。

写在后面：先定义清楚，再谈优化

回到最开始那个问题，很多人问我模型成本优化该怎么起步，我的回答一直是同一句：先把定义写下来，写成一页纸，让财务、算法、数据、业务四方签字认可。这一页纸上要有五本账的口径、不超过十个观测指标、以及一个最终验收口径——单位有效业务产出的全链路成本。没有这一页纸，后面所有的优化动作都会变成部门之间的拉扯。

我见过最有效的做法，是把成本讨论从“谁的预算超了”改成“哪个环节的转化率低了”。这两个问法看着接近，实际差别很大。前者会催生互相甩锅，后者会自然导向流程改进。举个例子，当团队开始问“为什么这批请求的意图识别没收敛住”，讨论就会落到检索策略和缓存设计上；当团队开始问“为什么这批样本标注要返工”，讨论就会落到主数据口径和标注规范上。这两类问题，恰好是成本结构里最有优化空间的地方。

如果你所在的团队正在规模化用模型，我建议给自己排一个顺序：花两周建账，花一个月归因，之后每个季度做一次结构复盘。结构复盘的重点是看三件事——请求分级比例有没有变化、数据返工率有没有下降、有效业务完成率有没有提升。这三个数字同向变好，成本自然下来；只盯账单数字，很可能会出现“省了算力、多了人工”的假降本。

还有一点我特别想强调，别把这件事做成一次性的项目。模型在跑，业务在变，数据在长，成本结构每隔一段时间就会变形。真正做得好的团队，是把成本观测做成日常的一部分，像看线上监控一样看它。普元这套数据治理与数据资产的能力，价值也在这里——它让这套观测有据可依，而不是靠人拍脑袋估。把定义立住、把底座打牢，剩下的优化才有意义。

周文彬：五本账这个拆法很实用，我们之前就是把隐性账全漏了，重训三次才发现问题出在评测集本身不可信。

林思远：同意“先理数据再调模型”这个顺序。我们去年急着做精调，样本表每次对不齐，白跑了两轮实验，后来把主数据统一才顺过来。

许晴岚：想问一下请求分级这块怎么落地，业务方总觉得自己的问题很重要，不愿意走规则通道，这块沟通成本挺高的。

高铭：单位有效业务成本这个口径我们财务认了，比看单价合理多了，推账的时候争议少了一大半。

郑一鸣：数据资产这块讲得中肯，复用率这个指标确实很少有人认真算，我们在口径统一之后，同一份客户数据三个场景共用了，省下来的不只是钱还有时间。