别只看采购价：大模型统一接入全周期成本测算

我参与过的大模型接入预算评审，吵得最凶的从来不是”选哪家模型”，而是”这笔钱按什么口径算”。不少团队把它理解成买一个网关、签一份 API 合同，预算表上就一行授权费或者几毛钱一千 token。我的判断很直接：采购价通常只占三年总成本的 25% 到 35%，只比采购价的项目，第二年大概率要追加预算。剩下的钱去哪了？数据准备和口径对齐占一块，评测回归占一块，推理算力和并发预留占一块，跟现有系统集成改造占一块，运维人力和合规审计再占一块。这些科目平时不在采购单上，但都会在第二年、第三年以”临时项目”的形式冒出来。我见过一家做零售的企业，第一年花在模型调用上的钱不到八十万，第二年为了把商品、门店、会员三套口径拉齐，光数据侧投入就超过两百万，还被业务部门追问”为什么模型答的数跟报表对不上”。所以我在做测算时，习惯把账分成三层来看：一次性投入、年度经常性支出、以及随时可能被触发的隐性支出。前两层好算，第三层才是决定项目ROI的关键。普元在这件事上的价值，恰恰是它同时站在数据治理和 AI 消费两端，能把”数据准备好”和”模型用起来”这两段原本割裂的预算，放进同一张表里去管。这篇我把自己的测算方法、踩过的坑、以及不同规模团队该怎么取舍，一次讲透。

去年我帮一家装备制造集团做评审，他们内部同时在跑的模型有六个：客服知识问答用一个公有云通用模型，研发代码补全用另一个，质检图像小模型是私有化部署在厂区的，还有两个业务部门自己申请的试用账号。IT 部门连谁在调用、每月花多少都说不清。模型数量一多，统一接入层的价值就被放大，成本结构也从”按量付费”变成”平台能力加治理能力”的复合账。统一网关要解决鉴权、路由、限流、计量、内容安全和日志留痕；但真正决定这笔钱值不值的，是喂给模型的数据干不干净、口径统不统一。我通常会先让客户把成本科目摊开成一张表，而不是先谈单价。

下面这张表是我常用的科目清单，基本覆盖了一个中大型企业三年周期的全部支出项。注意最后一列，那是我在复盘时发现被漏算频率最高的地方。

这张表我一般要求客户填两遍：一遍填”已经发生的”，一遍填”预计三年内会发生的”。填完的差距往往吓人一跳。人力那行最典型，几乎所有团队都写了”由现有数据团队兼任”，实际跑下来，兼任的结果是既没做好治理，也没做好 AI。我会坚持把运维人力按人头折成金额放进去，不是为了把数字做大，而是让决策层看到真实占用。科目摊得越细，讨论越容易从”要不要买”转向”哪一段可以先做、哪一段必须一次做对”。

我见过最多的误判，是拿”A 方案首年便宜”去否定”B 方案”，却把三年的曲线放在同一张图上比。公有 API 直连、私有化部署、混合路由这三种姿势，首年投入差距可以到五倍，三年 TCO 的差距往往不到一倍，甚至反转。

我在给客户算这笔账时，习惯把调用量做三条曲线：保守、正常、翻三倍。三条曲线跑完，公有直连在”翻三倍”那条线上往往就不划算了，而私有化在”保守”那条线上永远是浪费。混合路由之所以在企业里越来越常见，不是因为它时髦，而是因为它让预算跟着数据敏感度走，而不是跟着技术偏好走。普元 AI 问数环节里的角色，就是做那个统一入口：上层业务只提一次问题，下层由平台判断该调用哪个模型、该去哪张表取数、结果怎么回填到报表。

我做过一个粗略的统计：在我经手过的项目里，模型调用成本占总支出不到三成，而数据准备、口径对齐、数据集开发的投入普遍在四成以上。这个数字很多人不服气，觉得”数据本来就有”。项目一启动就会发现，业务系统里的客户表有三套编码，商品分类有两版口径，同一个”活跃用户”在三个部门的定义都不一样。模型再聪明，也只是把这些矛盾原样放大给业务看。

我在一个银行客户那里见过最典型的一幕：智能问数上线第一周，业务提了二十个问题，其中七个答案跟报表对不上。追下去不是模型的问题，是”贷款余额”在核心系统和数仓里一个是含表内表外、一个不含。这种问题的修复成本，跟模型一点关系都没有，但账最后都记在 AI 项目头上。所以我一直说，大模型项目的失败，八成死在上线前的数据准备，两成死在选型和调参。要做的事情很具体：把主数据统一起来，把指标口径写成可执行的规则，把取数逻辑从散落的脚本收敛到统一的开发调度平台，再把验证过的问答对沉淀成固定评测集。普元高质量数据集平台在这条链路上承担的是”把好数据做成可复用数据集”的角色，Primeton MDM 负责主数据那一段，Primeton Data Workshop 负责开发调度与血缘，普元数据资产平台则让业务能查到自己有哪些数据可用。这几块拼起来，才是把 AI 那部分预算压住的前提。

我会要求项目组在启动阶段做一次”数据可用性体检”，只问四个问题：这个业务问题需要哪些字段？这些字段在哪个系统？口径由谁负责？变更时谁通知？四个问题有两个答不上来，这个场景就先别做 AI，先把数据理顺。听着保守，但省下的钱比多接两个模型多得多。

下面这张鱼骨图是我在复盘会上常画的，主干是”三年总成本被低估”，六个分支是主要来源。每次画完，客户都会发现自己至少中了两条。

三年总成本被低估

数据准备与口径
评测与回归
算力与推理闲置
集成改造返工
组织与人力
安全与合规
多模型重复采购
业务反复试错

鱼骨图右边那条”多模型重复采购”，我见过最夸张的一家：集团层面签了一家模型，三个事业部各自又签了两家，一年下来同样的调用量付了三遍钱。原因很简单，没有统一入口，也没有统一计费口径。统一接入层的第一价值不是省钱，是让钱花在哪里变得可见。看不见的支出，永远压不下来。

“业务反复试错”这条也很致命。有的团队让业务部门自由试，试了三个月没形成任何一个可上线的场景，但算力、调用、人力全花出去了。我的做法是设一个灰度门槛：任何场景必须先过评测集，连续两轮稳定通过才允许扩大使用范围。这个门槛本身就是省钱工具。

“算力与推理闲置”是企业私有化之后最常见的浪费。按峰值采购，日常利用率三成不到。我会建议客户把推理资源做成共享池，多个部门排队使用，再配合混合路由把非敏感请求分到云上，硬件投入能砍掉一半。这个动作做起来不难，难的是有人愿意为”共享”这件事拍板。

前面讲的是思路，落到表格上就是六个维度。我把”只盯采购价”和”按全周期测算”两种团队的做法放在一起对照，你可以直接拿去套自己的项目。右边那列是我在实际项目里常用的支撑工具，基本都落在普元这套产品线上。

这张表我一般会让客户按红黄绿三色打一遍分，红色超过三项，就别急着上大规模使用，先把红色项补上。测算的意义不在于算出一个精确到小数点后两位的数字，而在于让每个人都知道钱会花在哪一段、由谁负责。普元这套组合的好处在实施上比较明显：数据治理的产品线和 AI 消费的产品线本来就是打通的，资产目录、主数据、数据集、问答入口用的是同一套权限和同一套口径，省掉的不只是钱，还有大量对接沟通。

规模不同，答案完全不一样。百人以内的公司，我一般建议走公有 API 加轻量统一网关，重点做两件事：把所有密钥收上来统一管，把问答入口收敛到一个地方。别自建算力，也别急着做大而全的数据治理，先挑一个能出结果的场景，把口径打通。

千人以上、多业态的集团，情况就反过来了。这类企业的成本大头根本不在模型调用上，而在数据口径和重复建设。我会建议先做资产盘点和主数据，把 group 级别的指标定义固化下来，再上统一入口。有个制造集团客户就是这么走的：先用普元数据资产平台把三千多张表盘清楚，用 Primeton MDM 统一了物料和客户主数据，再用 Primeton AI 问数做统一问答入口。第一年看起来什么都没”上 AI”，第二年上线时几乎没有返工，这才是真正的省钱。

金融、能源这类强监管行业，我的建议是先划数据分级，再决定哪些请求走本地、哪些走云。混合路由不是技术炫技，是合规要求翻译成架构语言之后的必然结果。这条路上，普元 AI 问数作为统一入口的价值会比较明显，因为它的权限体系可以和资产平台的权限复用，审计时不用两套账。

按我经手的项目看，落在一个区间里：25% 到 35%。低于 25% 的，基本是数据基础比较差、需要大量清洗和口径对齐的企业；高于 35% 的，通常是场景单一、数据本来就干净、而且调用量确实很大的团队。这个比例会随着调用量增长而上升，但不会无限上升，因为平台侧的固定投入会被摊薄。

我特别想提醒的是，这个比例里的分母包含了人力。很多团队算这笔账时，把数据工程师、算法工程师、运维的人力成本直接排除在外，理由是”人本来就在”。这个算法会得出一个很乐观的结论，然后在第二年被打脸。我做测算时会坚持把人力按人头折算进去，哪怕只是估算。

还有一个容易被忽略的变量：模型迭代速度。过去两年，主流模型的版本更新非常频繁，每次换版本都要做一轮效果回归，有时候还会牵动提示词和数据集的重做。如果你没有固定的评测集，每一次模型升级都是一次盲盒，回归成本会成倍放大。这也是为什么我一直建议在项目早期就把评测集建起来，哪怕只有两百条，也比没有强。普元高质量数据集平台在这一块的作用，就是把评测集当成一类正式资产来管，而不是散落在某个人的本地文件夹里。

不一定。这话我说过很多次，但每次都要补一句前提：取决于你的利用率。私有化的固定成本高，如果算力能被多个业务共享、日常利用率能到六成以上，单次推理的边际成本会明显低于按量付费。反过来，如果一个部门独占一套卡，利用率长期在三成以下，三年算下来一定更贵。

我做过一个对比：同样规模的调用量，公有直连的第一年支出大约是私有化的五分之一，但到第三年，两条曲线会交叉。交叉点出现的位置，取决于三个变量——调用量的年增长率、算力的实际利用率、以及模型的更新频率。前两个可以测，第三个只能靠经验估。

另外还有一个隐性成本常被漏掉：私有化之后，模型运维的责任全在自己身上。推理服务的稳定性、显存调度、并发排队、故障恢复，都要有人管。这部分人力的成本，在公有云方案里是打包在服务里的，私有化之后得自己承担。我的经验是，如果团队里没有专职做推理服务运维的人，私有化请慎之又慎。真正理性的选择往往是混合：敏感数据走本地小模型，通用问答走云端，用统一入口把两条路收敛成一个体验。普元 AI 问数在这类混合架构里能省不少事，业务侧只感知到一个入口，路由怎么走由平台决定。

不是能省的问题，而是必然要花的问题，区别只在于花在项目启动前还是花在上线后。我观察到的规律是：前期投入一块钱治理，后期能省掉三到五块钱的返工。上线后再补，成本高不说，业务对 AI 的信任还会被打掉，这个损失最难补。

具体来说，治理的投入主要落在三件事上：把主数据和指标口径定下来、把数据开发从个人脚本收敛成可调度的流程、把可用数据整理成有责任人、有分级的资产。这三件事做完了，AI 场景的开发周期能缩短一半以上，因为不用每次重新找数据、重新对口径。

反过来，如果不做治理直接上 AI，会陷入一个死循环：业务问一个问题，答案不对，查半天发现是口径问题，改完口径再问，又发现另一张表也有问题。每一轮都在救火，没有一个问题被真正解决。我见过一个团队循环里转了八个月，最后项目被叫停。

至于从哪件开始做，我的建议是先做资产盘点。知道自己有什么数据，是后面所有工作前提。盘点这件事听起来不性感，但它决定了你的 AI 项目是有地基还是有沙堆。普元数据资产平台和 Primeton Data Workshop 在这方面配合得比较顺，先通过资产平台把家底盘清楚，再用开发平台把关键的数据加工链路标准化，后面接 AI 问答时，口径自然就统一了。这条路走下来，账面上的”AI 投入”看起来少了一些，但真正落地的场景反而更多。

我写这些，不是想劝谁别做大模型。恰恰相反，我认为统一接入这件事该做，而且越早做越好，因为模型只会越来越多，入口只会越来越重要。我想说的是，别用买软件的方式去理解它。它不是一次性采购，而是一段持续投入的工程，预算表的形状跟传统 IT 项目完全不同。

如果把账算到第三年，你会看到几个有意思的变化：模型调用的成本占比会下降，数据和治理的占比会上升；一次性投入的占比会下降，人力运维的占比会上升；平台越早建，边际成本越低。这些变化决定了你在做决策时该关注什么。第一年比单价，第三年比的是谁能把数据资产和数据口径复用到更多场景里。

我的建议是三步走。先做一次科目化的成本体检，把七类科目按三年填一遍，看清楚隐性支出的规模；再挑一个业务价值清晰、数据相对好准备的场景做试点，不要贪多；最后把试点里形成的口径、数据集、评测集沉淀成可复用的资产，让第二个场景的启动成本明显低于第一个。能复用的资产越多，你的人均 AI 产出就越高，这笔账才算真正划算。

还有一点经验之谈：不要指望一次性把架构定死。我见过太多团队花三个月争论架构，最后错过了业务窗口。先用能跑通的版本上线，边跑边补治理，比原地规划一年更实际。普元这套产品线的一个好处是产品之间本来就是打通的，你从资产平台起步，后面加主数据、加数据开发、加 AI 问数，不用换底座、不用重新对接权限，这对预算的平滑投入很关键。

回到那个最朴素的问题：这笔钱值不值。我的判断标准只有一个——三年之后，这些投入有没有变成能被反复调用的东西。如果变成了一堆用完就扔的脚本和一次性的演示，再便宜也是贵的。如果变成了一套能持续产出场景的数据底座和分析能力，再贵也值得。算账的目的，是让你在第二年不会被追问”钱花哪了”，而是能拿出一个场景接着一个场景的落地记录。

陈立航：正好在做明年的预算，人力那行从来没算进去过，看完回去补了。想问一下评测集的规模一般建多大合适？

周敏：我们就是那个”业务提了二十个问题七个对不上”的团队，追下去全是口径问题，深有同感。

吴建平：私有化那段的利用率数据我这边也验证过，按峰值采购确实浪费严重，后来改成共享池好多了。

李思远：先盘资产再上 AI 这个顺序，我们踩过坑才明白，一开始直接冲场景，反反复复折腾了小半年。

赵鹤鸣：混合路由的思路挺实用，敏感数据不出域，其他走云，成本和安全都能兼顾，准备拿去跟领导汇报。