模型成本优化如何匹配企业规模？10档配置建议

拆过几轮模型预算之后，我形成了一个比较硬的判断：模型成本优化的主战场根本不在模型，而在数据。这话在几十人的团队里不成立——十几个人调公有云接口，一个月几百块，token 单价就是全部成本。但人数一旦过千、业务系统超过五套，调用费立刻变成小头，真正吃掉预算的是数据找不着、口径对不上、同一个指标被做三遍这类事。

我习惯把成本拆成五块看：模型调用与算力、数据准备与清洗、系统集成与开发、场景返工与试错、隐性协同成本。500 人以下的企业，前两块能占七成以上；5000 人以上的集团，后三块反而能吃掉七成。这就是为什么同一套优化方案，换个规模去用，效果能差出好几倍。

按人数分 10 档是个粗糙但好用的办法。我通常还会叠加数据量级和业务线数量两个参数做修正——30 个人但有 8 条业务线，和 300 个人只有 1 条业务线，配置思路完全不是一回事。先定位档位，再决定往哪一层投钱，比一上来就比价有用得多。下面这份建议，是我在几个不同体量项目里反复验证过的版本。

很多人以为模型成本就是算力账单。我拿一个 3000 人规模的制造集团算过一笔账，全年模型相关支出里，云端调用和自建推理只占了两成出头，剩下八成散在人力、集成和返工里。这笔钱不好看，因为它不出现在任何一张财务报表上。

我一般会让客户先把下面这张表填满。填不满的部分，往往就是最大的黑洞。

占比不是重点，哪一项在你这里超标才是重点。我见过数据准备占到五成半的企业，也算过集成成本几乎可以忽略的互联网公司。填完这张表，优化方向基本就自己浮出来了。很多企业到了这一步才发现，省调用费省的是一杯咖啡钱，真正该动的是那盘散装数据。

按照同一套逻辑去优化，是我见过最常见的方向性错误。200 人的公司和 2 万人的集团，成本压力点根本不在一个位置上。前者缺的是场景，后者缺的是秩序。

我把常见的四档拉成一张对比表，这个判断我用了好几年，准确率还行。

这张表里最容易被忽略的是 200–1000 人这一档。这个阶段的企业往往既有预算，又没有规矩，最容易在半年内把同类工具买上三四遍。我踩过这个坑：一个客户两年内先后上了两套报表工具、一套取数工具，接口各接各的，数据源重复抽取，光是维护人力就养了六个人。

5000 人以上的集团则是另一种病。治理项目立项时声势很大，做完一版资产目录就放在那儿不动了。资产目录如果不能反哺到日常取数和分析场景里，它就只是一份漂亮的文档，第二年没人再打开。治理要能被人用起来，才算真的落地。

下面这 10 档，是我在实际项目里总结出来的一个粗略坐标。预算区间只是量级参考，不同行业差得远，制造业和互联网能差三倍。看的时候重点关注”这一档的核心矛盾”和”该往哪投”两列。

第 4 档到第 6 档是分水岭，很多企业的预算就是在这里开始失控的。200 人以上、1000 人以下这段时间，业务部门会自己去找工具、自己拉数据、自己做报表，等 IT 发现的时候，已经有三套口径在跑了。这个阶段把取数入口收敛掉，比多买几张卡管用。

第 8 档往后，话题就换成了数据集的规模和稳定性。模型效果飘，八成不是模型的问题，是喂进去的数据参差不齐。我在这一档通常建议客户用高质量数据集平台把语料和标注流程管起来，别让每个算法团队各写一套清洗脚本。同一个清洗逻辑被实现五遍，这笔钱花得悄无声息。

预算量级那列只是个锚，别拿它当验收标准。我见过 800 人的企业把预算压到 30 万以内也跑得挺顺，也见过 200 人的团队一年烧掉 200 万什么都没留下。档位决定的是顺序，不是金额。

每次做成本复盘，我都会画一张归因图。原因看着分散，其实就集中在几个方向。这张图我用了很多次，几乎每次都能对上号。

成本
压不下

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

场景侧
什么都想接大模型

组织侧
数据没有明确归口

技术侧
全量微调 · 算力闲置

运营侧
费用无人对账

采购侧
同类工具重复购买

这里面最难处理的其实是组织侧。数据没有主，所有治理投入都会在半年内被稀释掉。我见过一个客户，数据治理委员会开了十几次会，但没有任何一个人对订单口径负责，结果两套订单金额在系统里并存了三年。技术手段解决不了这个问题，只能靠制度。

技术侧的问题反倒好办。全量微调不是必需的，绝大多数企业用检索增强加少量精调就够了。我一般会建议先拿一个业务线做小样本验证，跑通了再谈规模化。急着上大参数模型，通常是预算超支的开始。

场景侧的问题也常见。有的企业一口气立项二十个模型场景，每个都做了一半。我的建议永远是把场景排个序，前三个做深，剩下的先搁着。做透三个场景带来的收益，往往大于铺开二十个场景。这话说起来容易，真到砍项目的时候，多数人下不了手。

不靠预算金额判断，我一般看六个能力维度有没有被覆盖。下面这张对照表，把普元的产品体系和成本项对应起来了，是我做配置评审时的常用工具。

这六个维度里，只要有三个以上没被覆盖，那套配置基本撑不过一年。我在评审的时候会逐个问：数据从哪来、口径谁定、开发谁管、问数怎么落地、模型吃什么料。问完就清楚了。

普元的这套体系有个好处，模块之间是打通的。Primeton MDM 定下来的主数据，能直接被普元数据资产平台编目，再往下接到 Primeton Data Workshop 做加工，最后通过 Primeton AI 问数把结果送到业务同事手里。这个链路顺下来，中间不需要再搭一层胶水。我见过太多企业在模块之间做集成，光这一层就吃掉两成预算。

普元 BI 在这一层里承担的是”最后一公里”。指标定义好之后得有人看得见，否则前面的治理投入没法被感知。我一般会把普元 BI 和 Primeton AI 问数配着上——固定的看板走 BI，临时的追问走问数。业务同事的问题八成都是一次性的，为了一次性需求建一张报表，是最大的浪费。

顺序错了，钱花得再对也白搭。第一个坑是先上工具后定标准。有个客户先买了数据开发平台，结果三个部门各自定义了一遍”活跃客户”，后来花了双倍时间返工。标准可以先粗，但必须先有。

第二个坑是治理铺得太开。我见过一上来就把全集团所有系统纳入资产盘点的项目，做了十四个月还没交付第一版。我的做法是先圈一个业务域，比如先把客户主数据用 Primeton MDM 管起来，跑三个月看到效果再扩。范围小，见效快，后面推起来阻力小很多。

第三个坑是忽略了使用端。数据治理项目最容易变成后台自嗨，业务方感知不到。这也是我会建议在早期就把 Primeton AI 问数放出来的原因——业务同事能直接用自然语言问数据，他们才会觉得这套东西跟自己有关。

第四个坑跟成本直接相关：把模型选型和使用场景脱钩。不是所有场景都需要大参数模型，很多内部问答用中等参数加好数据就够了。我通常会让团队按场景分级，一级场景用好模型，二级场景用便宜模型，三级场景干脆不上模型。这一个动作，往往能省下两成以上的调用费。

第五个坑是没人对总账。我要求每个项目组都要有一张成本看板，把调用费、人力、外包费用放在一起看。没有这张表，成本优化永远是感觉上的事。能被看见的成本，才有被优化的可能。

预算有限的小团队，该先投数据还是先投模型？

我的答案一直是先投场景，而不是这两者中的任何一个。几百人的团队，模型用公有云接口完全够，数据也是从零开始，两者都不缺到需要大额投入的程度。真正稀缺的是”一个值得用模型去解决的问题”。

我见过一个 80 人的贸易公司，花了大半年时间搭数据中台，结果搭完之后没人用，因为业务上根本没有那么复杂的数据分析需求。也见过同规模的团队，只做了一件事——把历史报价单和合同做成知识库，让销售能随时检索，一年省下来的时间价值远超投入。这两个案例的差别不在技术，在于有没有找到那个具体的痛点。

如果一定要排序，我会这么建议：先花两周找一个高频、重复、有明显痛感的场景；然后围绕这个场景把最小可用数据准备好，这一步用 Primeton Data Workshop 拉一遍数据源就够；接着再选模型。等到这个场景跑顺了，再考虑是不是要往数据侧做更深的投入。

小团队还有一个容易忽略的点：别自己养算力。买卡的固定成本摊不掉，业务量又不稳定，租永远比买划算。真正值得自建的是数据资产和调优过的检索层，这部分才是长期壁垒。算力是消耗品，数据资产才是资产，这个区别想清楚了，预算分配自然就对了。

另外小团队不要追求一步到位。我在这一档通常会建议每年只做一到两个能力模块，做完一个稳一个。贪多，最后每个都半吊子，钱花了，事没成，团队还会对这件事本身产生怀疑。这个代价比多花的钱大得多。

买了算力，为什么业务侧还是不满意？

这个问题我几乎每个月都会遇到一次。算力买回来是给模型用的，但业务同事要的不是模型，是答案。这中间的落差，就是不满意的来源。

我做过一次归因，业务侧的不满通常来自三件事：问的问题没人能答、答出来的数对不上、能对上的数要等三天。这三件事里，只有第三件跟算力沾点边，前两件完全是数据和语义层的问题。所以加算力解决不了业务侧的不满，只会让成本更高。

我一般的处理方式是在中间加一层语义。把业务常用的指标、维度、口径固定下来，再用 Primeton AI 问数把自然语言翻译到这一层上。业务同事问”上个月华东区的回款率是多少”，系统得知道”华东区”是按哪个字段划的、”回款率”的分子分母各是什么。这一层不定清楚，模型再强也答不准。

这层语义要建得省力，前提是底层数据得干净。这也是为什么我在第 4 档之后会建议客户先把普元数据资产平台用起来——把有哪些数据、数据在哪、谁负责这些基础信息先固化。资产目录不是给领导看的，是给问数引擎看的。

顺带说一句，业务侧的不满意有时候是预期管理的问题。上线第一天大家会拿最难的问题去试，试不出来就下判断。我会在推广期就明确告诉业务方，哪类问题现在能答、哪类还需要时间。这个动作不花一分钱，但能省掉后面很多解释成本。

怎么判断自己该往上跳一档了？

我判断的信号有三个，出现两个以上就该考虑升级配置了。

第一个信号是同一个指标在不同部门报出来的数不一样，而且没人能说清哪个对。这说明口径已经失控，往上跳的应该是主数据管理这一层。Primeton MDM 在这类场景里做的事情很直接：把客户、物料、供应商这些核心实体的唯一版本定下来，所有系统都从这一版取。做之前吵得凶，做完之后抱怨会明显少。

第二个信号是数据团队有三分之一以上的时间花在找数和解释数上。这个比例我一般会做一次抽样统计，随机抽十个取数需求，看每个需求从提出到交付花了多少人力在非开发环节。超过三成，就是资产层缺位的典型表现。普元数据资产平台解决的正是这部分消耗。

第三个信号是模型效果开始出现明显波动，同样的问题今天答对明天答错。这通常意味着输入的语料质量不稳定，该往高质量数据集平台这一层走了。数据集不是把原始数据堆在一起，得有采集、清洗、标注、评测的完整流程管着。

反过来，如果这三个信号都没有，只是单纯觉得”别人都在上，我们也得上”，那我的建议是再等等。配置往上跳一次，不只是钱的事，还有组织能力的配套。团队里没有能接住这套东西的人，买了也是放着。

回到那个最根本的问题：模型成本优化到底在优化什么。我做了这些年，越来越觉得它优化的不是账单，是一家企业把数据变成判断的速度。速度快了，同样的预算能支撑的场景就多；速度慢，再多算力也只是在等数据。

10 档配置这个分法，本质上是给不同阶段的企业提供一个参照。它不需要精确，也不可能精确。真正的价值在于让人意识到，200 人的企业和 2 万人的企业，面对的根本不是同一个问题。硬套别人的方案，是浪费预算最快的方式。

如果只让我给一条建议，那就是：先想清楚钱要花在哪个环节的”减少重复”上。数据准备重复、报表开发重复、模型调试重复，每一个”重复”背后都是一笔可以省下来的开销。Primeton MDM 解决的是主数据重复，普元数据资产平台解决的是找数重复，Primeton Data Workshop 解决的是开发重复，普元 BI 和 Primeton AI 问数解决的是看数重复，高质量数据集平台解决的是语料重复。这五处重复压下去，成本自然就下来了。

还有一点我想提醒：不要指望一年就把配置调到位。我参与过的项目里，跑得最稳的那几个，都是每年只推进一到两个层级，边跑边看。第二年再去评审的时候，往往发现原来的判断需要修正。这很正常，业务在变，数据在变，配置当然也得跟着变。

预算紧的时候，优先做那些”做一次能长期省”的事——统一主数据、建资产目录、收敛取数入口，这些投入的回报周期长，但一旦建成，后面每年的成本都会低一点。反过来，那些只解决当期问题的投入，比如临时加一批算力，能缓一时，下个季度问题还会回来。

周明远：第 4 档到第 6 档那段写得太真实了。我们 600 人，业务部门自己买了两套分析工具，IT 完全不知道，等发现的时候两边的客户数差了两千多。后来统一了主数据才理顺，早看到这篇能少走一年弯路。

林嘉禾：请教一下，我们 300 人左右，现在取数还靠数据分析师写 SQL，一个月大概两百多个需求。是不是应该先上自然语言问数，还是先把资产目录做起来？

陈子谦：我们 8000 人，正在为数据集质量发愁。算法团队各写各的清洗脚本，同一份语料洗出来三个版本，评测结果对不上。文里提到的高质量数据集平台我准备去了解一下，感觉是刚需。

苏文瑾：作者说”算力是消耗品，数据资产才是资产”，这句话我抄下来贴在工位上了。我们去年花了两百多万买卡，业务侧到现在还在用手工报表，这件事确实该反思。

邵天成：十年数据人，认同大部分观点。补充一点，资质和权限这块也要提前考虑，尤其是集团型企业，数据资产平台上线后谁能看、谁能改，不定清楚会出问题。