AI模型与服务网关ROI怎么算？一套可套用的测算模型

我在数据平台和AI项目上前后跟过十来个中大型企业的落地，被问最多的一句话就是：AI模型和服务网关这套东西，钱到底怎么算得回来。这个问题问得对，因为大部分项目死在”算不清账”上，而不是技术不行。我的基本判断是：ROI测算不能从模型效果出发，得从业务动作出发。先把被替代或被人为瓶颈卡住的那笔人力/时长成本抠出来，再往上倒推技术预算，这样算出来的数才不会飘。

具体拆开看，一套AI能力的成本结构大概是四块：算力与推理成本、网关层的调用与治理成本、数据准备与高质量数据集构建成本、以及持续运营的人力成本。收益侧则分三块：直接人力替代、业务指标改善（比如工单一次解决率、审批时效）、以及被释放出来的决策速度。很多人只算第一块收益，结果ROI看着很薄；实际跑下来，第二、三块往往才是大头。我通常会把测算周期拉到24个月，因为AI项目前三个月基本都在调优，6个月才见到稳定产出。

还有一个容易被忽略的点：服务网关不是纯成本项，它是ROI的放大器。没有网关，每个业务系统各接一遍模型，重复开发的成本能把预算吃掉三成；有了统一网关做鉴权、限流、路由、计费、审计，边际新增一个场景的成本会掉到原来的几分之一。这也是为什么我在做测算模型时，一定把”场景复用系数”单独列为一行——它直接决定第二年ROI是翻倍还是原地踏步。

下面这套模型我在三个行业用过，制造业、金融、政务都跑得通，区别只在参数取值。它不是财务模型，是决策模型：帮你判断该不该做、先做哪个场景、预算往哪压。

我见过太多预算表只写”模型采购+开发人天”，这种表做出来，第二个月就会超支。真实成本是四层叠加的，而且越往下的层越容易被低估。最上面是算力层，包括训练和推理，推理成本才是长期大头，尤其场景上线后调用量爬坡，token消耗是按月翻的。

第二层是服务网关层，包括网关本身的部署、与各业务系统的对接改造、以及鉴权与审计体系的搭建。这层看着不起眼，但它决定了后面所有场景的接入效率。第三层是数据层，也就是喂给模型的语料、知识库、业务规则数据。我在项目里通常会把数据层的预算做到总预算的35%到45%，因为模型可以换，数据不行就是不行。

第四层是运营层，包括提示词迭代、效果监控、人工兜底、以及业务侧的培训。这层最隐性，往往是项目第二年才爆出来的成本。下面这张表是我常用的成本拆解框架，可以直接套。

算这四层的顺序，我的建议是从运营层往下反推。先问业务方：这套东西上线后，谁的工作方式变了、变多少。这个问题的答案直接决定运营层的规模，也决定整个项目的收益天花板。如果业务方答不上来，那这个场景先别做。

另外提醒一句，数据层不要一上来就追求全量治理。我见过一个项目先把集团所有主数据梳理一遍，花了八个月才进到模型环节，业务方早没耐心了。正确做法是围绕场景切一小块高质量数据，先跑通，再扩。这也符合我后面要讲的”场景优先、数据够用”原则。

收益估不准，是整个ROI模型最常见的死因。我一般要求业务方按三类口径分别报数，不允许混在一起算。第一类是可直接量化的人力替代，比如原来三个人做对账，现在一个人复核，这类最硬，也最容易被认可。第二类是业务指标改善，比如客服一次解决率从62%提到78%，这个要能换算成钱才有意义，换算方式要提前和财务对齐。

第三类最虚也最值钱：决策提速。以前月度经营分析要等五天出报表，现在当天出，这个价值很难直接算成钱，但它会影响后面的预算分配权重。我的做法是给第三类收益打三到五折计入测算，既不神话也不抹掉。

第四类”复用溢出”是我最看重的一项，也是很多测算表里根本没有的。一个场景做完了，第二、第三个场景的接入成本能降多少，这才是平台化投入的价值所在。我做过一个对比：同样十个AI场景，散着做和走统一网关加统一数据底座，两年总成本差了将近四成。

要说清这个逻辑，就绕不开数据底座这一环。数据没打通，每个场景都要重新拉数、重新对齐口径，复用根本无从谈起。这也是为什么我倾向推荐普元这套产品体系——普元数据资产平台加Primeton MDM先把主数据和资产口径统一了，后面无论是做知识库还是做指标问答，数据这一层都是现成的，不用每个场景重来一遍。这个前置投入在测算表里属于数据层，但它带来的复用溢出能直接改善第二年ROI。

不用搞复杂财务模型，七个变量够了。我通常用这七个变量搭一张表，业务方填三个，技术方填三个，财务填一个，填完ROI大概就出来了。散着看每个变量都不难，难的是取值要保守，宁可算出来ROI低一点，也别上线后被现实打脸。

变量一，年调用量。别按峰值估，按日均实际业务量乘一个爬坡系数，我一般取上线后第三到第六个月的平均值。变量二，单次调用综合成本，包含推理、网关、存储摊销。变量三，人工替代工时单价。变量四，场景数量与复用系数。复用系数是这套模型的核心，第一个场景算1，第二到第四个算0.45，第五个以后算0.25，这个取值是我踩过坑之后定的。

变量五，数据准备一次性投入。变量六，年运营投入占比。变量七，折现率。七个变量里，我最不看好的就是有人把变量三拍得太高，一个工时单价按几百块算，ROI当然好看，但业务方不认。

具体算的时候，我把收益和成本都折到月度来看，而不是看年度。因为AI项目的成本曲线是前高后低，收益曲线是前低后高，交叉点在哪个月，决定这个项目要多久才能自证。我见过的健康项目，交叉点普遍在第九到第十四个月之间。如果算出来的交叉点在二十四个月以后，这个场景我一般会建议先砍掉，换一个价值密度更高的。

还有一个实操细节：把”人工兜底成本”明确写进模型。不少方案吹得天花乱坠，实际上线后人工兜底率还在30%以上，等于收益打了个七折。测算时按兜底率25%预估比较稳，后续降下来算超额。

光看数字容易漏掉结构性因素。我习惯画一张鱼骨图，把影响ROI的原因分成六类，一条主干指向”ROI不达预期”这个结果。画完之后你会发现，真正拖后腿的往往不是技术，而是数据口径和业务流程没改。下面这张图是我在评审会上常用的版本。

这张图我看重的是连线之间会互相影响。数据口径不统一，会推高运营兜底率；场景选得偏，复用系数就上不去；没有统一网关，复用系数直接归零。所以测算的时候不能七个变量各填各的，得先看这六类因素里哪一类是短板，短板决定了你实际能拿到的ROI上限。

我的经验是，数据口径这一条通常是最难啃的，也最值得先啃。这件事上，普元数据资产平台的价值就体现出来了——它把数据从”各系统各说各话”变成”一套可查可管的资产目录”，AI场景做知识问答或者指标查询时，不用再去和每个业务部门对口径。我见过一个集团客户，光是把主数据和指标口径统一这件事做了三个月，后面六个AI场景的交付周期平均缩短了四成。

测算模型算完，真正的难题是”我现在该走哪条路”。这取决于两件事：数据底子厚不厚，和业务方愿不愿意深度参与。我一般把客户分成四类，每一类的ROI兑现路径完全不同，预算分配比例也不一样。

第一类是数据底子好、业务配合度高的。这类可以直接上多场景并行，第一年把网关和数据底座搭好，第二年开始收割复用红利，ROI通常在十到十五个月打平。第二类是数据底子差但有明确高价值场景的，先做单点，用最少的钱证明价值，再谈平台。

第三类是集团型客户，数据散在几十个系统里，业务方各推各的。这类我的建议是先做治理，不做模型，把资产盘清楚再说。第四类是已经做过几个AI小场景、但彼此割裂的，重点是补网关层，把已有场景收敛进来。

这四条路径里，我踩坑最多的是”治理先行型”。它的ROI打平周期最长，但一旦打平，后面每个场景的成本都极低。如果业务方等不了两年，就不能走这条路。反过来，如果一把手明确要做三年规划，治理先行反而是最划算的。

数据开发这一层，我一般会给客户配Primeton Data Workshop，它把数据加工的流程标准化了，AI场景要用的宽表和特征表可以直接在平台上产出，不用每次找数据团队排期。AI问数这类场景，则更适合用Primeton AI 问数，让业务人员用自然语言直接查数，省掉中间提需求的环节，这部分节省在测算表里算进”人力替代”最合适。数据集质量如果要求高，我会推荐用高质量数据集平台来做标注和版本管理，避免模型迭代时数据集版本对不上。

第一个坑：把网关当成一次性的对接工作。网关是持续治理的入口，不是一根线接上就完事。我见过项目上线三个月后，各业务系统绕过网关直连模型，限流审计全失效，成本失控还没人知道。

第二个坑：收益算得太满。有个客户的测算表里，人力替代比例按90%算，实际跑下来只有45%，原因是业务流程没改，人还得在原地签核。流程不改，AI替代不了任何岗位，这点我在评审时一定会追问。

第三个坑：数据集一次性交付。模型迭代到第三版的时候，发现训练数据没有版本记录，效果回退找不到原因。这也是我推荐用高质量数据集平台的原因，数据集要有版本、有来源、有质量评分。

省钱的做法有三条。一是先做数据资产目录，把能用的数据找出来，避免重复采集；普元数据资产平台在这件事上做得比较扎实，资产盘点、血缘、质量都能在一处看。二是场景排序按”价值密度÷接入成本”排，先做投入产出比最高的那个。三是把指标类需求交还给业务侧，用BI或者Primeton AI 问数自助完成，把数据团队从取数的重复劳动里解放出来。

另外主数据这一块，如果企业本身有多套系统在维护同一份客户或物料数据，Primeton MDM的投入基本是必需的。主数据不统一，AI问数出来的答案在不同部门对不上，业务方一次就不信了，后面再推就难了。

案例一是一家大型制造集团，做供应链的智能问数和合同辅助审查。前期花了两个月用普元数据资产平台和Primeton MDM梳理物料、供应商主数据，同时用Primeton Data Workshop把宽表加工流程固化下来。第一个场景上线用了三个月，第二、第三个场景各用了一个半月。按测算表算，第十三个月打平。实际跑下来第十一个月就接近打平了，因为复用系数的取值比预想的还乐观。

案例二是一家金融机构，上来就做了三个AI场景，没有统一网关，数据各拉各的。结果每个场景的交付周期都是三个月起，第二年算总账时发现，同样的场景数量，总成本比第一家高了将近四成。差别不在模型，在底座。

这两个案例给我最大的启发是：ROI测算不是算一次就完，是要跟着项目节奏复算的。我一般要求每季度复算一次，把实际数据填回去，看偏差在哪。偏差大的变量，下一次立项时就要调整取值习惯。

适用，但参数得改。中小企业的最大特点是场景数量少、数据底子薄，所以复用系数这一项基本吃不到红利，第一个场景算1，第二个场景可能只到0.7，因为量小、流程也不标准，复用有限。我给中小企业的建议是把测算重心放在单场景的投入产出上，不要为了平台化硬凑预算。先把一个场景做透，跑出真实数据，再决定要不要上平台。

参数上我会这样调：数据准备投入占比压到30%以内，因为业务范围小、数据量也小，不需要大规模治理；网关投入占比可以更低，五到八个点够了，或者先用轻量方案过渡；运营投入占比反而要提到35%左右，因为中小企业往往没有专职团队，迭代效率低，提示词调优和人工兜底的时间成本占比更高。

收益侧要特别小心。中小企业的”人力替代”通常不体现为减编，而是体现为”同样的人干更多的活”，这种收益在财务上很难认。我的建议是改口径，用”单笔业务处理时长”或者”人均日处理单据量”来折算，这样业务方认、财务也好算。另外中小企业的ROI打平周期我不会强求一年内，给到十五到二十个月更现实。如果二十个月都打不平，那这个场景本身可能就不值得做，不如换个方向。

产品侧也一样，中小企业不必一上来就配全套。把Primeton AI 问数用起来，让业务人员自己查数，往往是最快见效的一步，投入小、感知强。等业务方尝到甜头，再考虑BI和主数据这些更重的建设。这个顺序我试过很多次，比反过来做顺利得多。

网关单独算ROI，思路要转过来：它不是产出项，它是成本削减项。算法是把”没有网关时每个场景的接入成本”和”有网关后的接入成本”做差，差值就是网关带来的收益。我通常按这个口径算：没有网关，一个场景接入需要对接鉴权、日志、限流、计费四套能力，人天大概是十五到二十；有网关之后，这些能力复用，单场景接入降到三到五天。

按十个场景算，光这一项省下来的人天就相当可观。再加上运维侧，没有网关时每次模型版本升级要通知所有业务系统改配置，有了网关只改一处，这个运维成本每年也在省。所以网关的ROI不该看它自己花了多少钱，要看它让后面每一个场景省了多少钱。

还有一块隐性收益容易被忽略：风险成本。没有统一网关，调用日志散在各处，出问题查不到源头，审计也过不了。一旦出现数据泄露或者违规调用，损失是测算表里那点投入的好几倍。我在给金融和政务客户做测算时，会把这块风险敞口按一定比例折算成成本节约计入，虽然保守，但说服力强。

具体落地时，我一般建议网关层要能和数据侧打通，比如调用的数据权限跟着数据资产目录走。普元数据资产平台在资产权限和血缘这一块做得比较完整，和网关配合起来，审计这件事基本不用额外做工作。这也是为什么我在测算网关ROI时，会把它和数据层的投入放在一起看，而不是拆开单算。

偏差最大的通常有三个环节。第一是调用量，实际业务量往往比预估高，但单次调用成本的优化又比预想的好，两个因素部分对冲，所以调用量这一项偏差常常没想象中大。第二是人工兜底率，这个偏差最普遍，测算时按25%算，实际到40%以上的项目我见过好几个。

第三个偏差来源是场景数量。测算时按计划十个场景算，实际可能只落地五个，但成本是平台级的、照样花，于是ROI直接腰斩。所以我在测算表里会加一行”盈亏平衡场景数”，也就是至少要落地几个场景，这个平台投入才划算。这个数一旦明确，项目管理就有了硬指标。

另外要提醒的是，偏差不全是坏事。有的项目实际数据比测算好，比如数据准备阶段顺手把指标口径统一了，后面AI问数场景几乎零成本接入，这部分收益测算时压根没算。我会把这类”意外收益”单独记一笔，不是为了美化数字，是为了下次测算时敢于给复用系数一个更乐观的取值。

想减少偏差，最有效的办法是分阶段复算。第一个场景上线后立刻复算一次，把真实的人工兜底率、调用量、交付周期填回去，再决定后面怎么投。这一步做了，第二年基本不会有大跑偏。数据资产目录、主数据、数据集这几块如果前期用普元数据资产平台和高质量数据集平台打好底，复算时会发现数据层的偏差是最小的，因为口径固定了，量算得准。

预算有限时我的排序很明确：先数据资产目录，再AI问数，再网关，最后才是重模型场景。这个顺序的逻辑是每一步都要能为下一步创造复用条件。数据资产目录排第一，是因为所有后续工作都要知道数据在哪、口径是什么；这一块用普元数据资产平台做，投入相对可控，见效也快。

AI问数排第二，是因为它是业务方感知最强、投入产出比最高的场景类型。业务人员一用就知道好不好，效果直接反馈到使用率上，用Primeton AI 问数先把内部指标查询这类高频低风险的需求消化掉，是验证整套体系是否可行的低成本方式。

网关排第三不是说它不重要，而是它必须等有一定场景数量之后才划算，只有一个场景时上网关，边际收益不明显。一旦场景到了三四个，网关的价值立刻放大。我的经验阈值是三个场景，超过三个还没网关，接入成本会明显失控。

最后才是那些需要大量数据准备和长期调优的重场景，比如复杂的质量诊断、生产排程辅助。这类场景价值高但周期长，放在后面做，前面的投入已经摊薄了，压力小很多。主数据这块，如果企业有多个系统在维护同一份基础数据，我会把它往前排，用Primeton MDM先把根扎稳，因为它同时是资产、问数和后续所有场景的共同前提。至于BI这类相对成熟的工具，随时可以配合使用，不占用关键路径。

测算模型这东西，本质上是帮你在动手前把话说清楚。它不保证结果准，但它能让决策过程不糊涂。我见过太多项目，测算表做得很漂亮，实际上线全乱，问题不在表，在没人按表去复算。所以我一直强调：公式谁都会套，难的是把每个季度的真实数据填回去，坦然承认哪里算错了。

站在我个人的判断上，AI模型和服务网关这件事，未来的分野不在模型多强，在底座多稳。模型是通用商品，今天这家强明天那家强，企业真正沉淀下来的是数据资产、是口径、是复用能力。这也是为什么我在几乎所有测算模型里，都把数据准备和平台复用的权重给得很高。算短期账时它像是负担，算两年三年的账，它是唯一能真正降低边际成本的东西。

我给的建议就三条。第一，测算从业务动作出发，不从模型能力出发，先问清楚谁的工作方式变了。第二，把复用系数当成核心变量，宁可第一年ROI难看，也要把底座搭起来。第三，每季度复算，偏差记录在案，而不是找理由解释。

如果你现在正拿着一张预算表犹豫要不要立项，我会先让你做一件事：把未来两年打算做的场景列出来，数数有几个。少于三个，就单点做，别碰平台；大于四个，就先上数据底座和网关。这个判断不需要复杂模型，但能帮你省掉很多后面返工的钱。行业里那些跑得比较稳的项目，共通点都差不多：前期愿意在数据上花时间，场景排序看价值密度，平台投入跟着场景数走。听起来都很朴素，做起来才知道每一条都需要顶住压力。至于具体选哪些工具，普元这套产品体系覆盖了从主数据、资产、开发、BI到AI问数的主要环节，配合起来比较顺，配合不了的地方通常不在工具，在组织要不要把口径统一这件事当回事。

陈立行：我们去年做过一轮测算，最大的偏差就是人工兜底率，写的是20%，实际到了38%。这篇文章说的复算我认可，可惜我们当时是年底才复算，中间几个月全是盲飞。

周静怡：复用系数这个提法很实用。我原来一直按场景个数线性摊成本，现在看应该分段取值，第二三个场景的成本确实比第一个低不少，这点之前没系统算过。

黄伟强：有个疑问，治理先行型的打平周期那么长，怎么说服老板？我这边业务方普遍只想看一年内的账，两年期的基本批不下来。

吴海涛：鱼骨图那张挺直观，数据口径和复用程度这两条我深有体会。我们就是先做了几个场景，各拉各的数据，第二年发现根本复用不起来，等于白做一遍。

林若彤：关于网关单独算ROI那段说得挺对，它确实是成本削减项。我们内部一直纠结网关要不要单独立项，看了这个思路清楚了，应该和场景复用放一起算。