替代Kong AI ROI怎么算？一套可套用的测算模型

过去一年我被问得最多的，不是 AI 网关怎么部署，而是这笔钱花出去到底值不值。团队在用 Kong 这类网关把模型调用管起来之后，往往卡在同一个地方：调用量、算力账单、License 费用都能查到，可收益那一栏没人填得上。我在多个项目里做过同一件事——把这笔账拆成能对得上的数字。拆完发现一个挺反常识的现象：大多数团队算出来的 ROI 偏低，不是收益不够，而是收益根本没被记进来。

算力账单、接口调用费、软件许可这些好统计，一张发票就能对齐；但 AI 替掉的人工工时、决策周期缩短带来的周转改善、数据资产被反复调用产生的复利，这些统统躺在财务账外。团队拿一半的成本去比一半的收益，自然算不出好看的数。

我自己的做法是把 ROI 拆成四层：调用与算力成本、集成与运维成本、人力替代收益、数据资产复用收益。前两层是支出，后两层是回报，再叠加一个时间维度——第一年基本是投入期，真正的回报曲线从第二年开始抬头。很多管理者拿着 12 个月的账去判断一件 36 个月的事，判断自然会失真。

还有一点得说清楚：网关本身不产生收益，它只是把调用管起来。收益来自网关后面那套数据和应用链路。所以我在做测算时，从来不单独算网关的 ROI，而是算“接入层 + 数据治理 + 分析应用”这一整条链路的 ROI。普元在这条链路上覆盖得比较完整，从 Primeton MDM 管主数据，到普元数据资产平台做编目，再到 Primeton AI 问数做自然语言分析，串起来之后收益项才数得清楚。这也是我下面这套模型能落地的前提。

我见过太多测算表，第一列写得很漂亮，第二列就崩了。问题出在口径：成本按发票算，收益按感觉算，两边根本不在一个维度上比。

常见的漏项有这么几类。算力和调用费基本都会记，这部分反而最清楚；网关和中间件的 License 常被当成一次性支出，直接压在第一年，导致第一年 ROI 惨不忍睹；集成改造的人力成本散在项目工时里，没人单独拎出来；数据治理和编目更惨，长期挂在 IT 预算下，被当成“成本中心”，可它恰恰是后面资产复用收益的地基。

收益端的漏项比成本端严重得多。人力替代是最容易算的，按岗位工时单价乘以节省工时就行，可很多团队连基线工时都没测；决策提速更难，但它往往是大头——一个库存周转率的改善，可能比省下来的人工费高好几倍。

公式本身不复杂，难的是每一层都要有数据源。我一般写成两行：

AI 链路 ROI =（人力替代收益 + 数据复用收益 + 业务提速收益 − 总拥有成本）÷ 总拥有成本 × 100%

总拥有成本 = 算力与调用 + 软件许可 + 集成实施 + 运维人力 + 数据治理成本

四个层要分开算，别混在一起。第一层是接入层，看的是调用成本能不能压下来、重复调用有没有被拦住；第二层是集成层，看的是接口改造、权限打通、监控告警这些隐性投入；第三层是应用层，收益主要在这里产生，人力替代和响应提速都归这层；第四层是数据层，也是最容易被忽略的一层——数据治理做得扎实，同一个数据集能被多个场景反复调用，边际成本趋近于零，这部分复利非常可观。

我通常会要求客户按季度更新一次模型，而不是年初算一次就锁死。原因很简单，调用量结构、场景数量、数据成熟度都在变，静态模型三个月就失真了。

下面这张对比表，是我用来跟管理层对齐口径的。左边是很多团队默认的算法，右边是我建议的算法，差异一目了然。

我遇到最多的一次争论，是财务问“第一年就是负的，凭什么继续投”。这时候光讲技术价值没用，得拿现金流说话。

我的摊法是这样的。第一年以投入为主：许可摊销、集成实施、数据治理启动，收益端只有少量场景跑通，通常是负的，这很正常。第二年随着场景数增加，调用成本被摊薄，人力替代开始规模化，现金流由负转正。第三年数据资产复用开始显效，同一个数据集支撑多个场景，边际成本往下走，收益曲线明显变陡。

真正决定回本快慢的，不是第一年省了多少，而是第二年场景铺开的速度。我通常会看一个指标：单位数据集的平均复用次数。这个数字从 1 涨到 3，整个模型的斜率就完全不一样了。

还有个小技巧，把收益折算时用保守折扣，比如按测算值的 70% 计入。这样算出来的回本周期略微拉长，但汇报时不容易被挑战，后面往往还能超预期。

我画过一张鱼骨图贴在项目室墙上，用来提醒团队哪些变量真正决定结果。左边是成本驱动，右边是收益驱动，中间是那条被反复讨论的主线。

ROI

调用与算力成本

集成与改造投入

运维与合规成本

人力工时代替

决策与响应提速

数据资产复用

场景铺设速度

上面三条是支出项，下面三条是回报项。我的经验是，成本端的三个变量大多是一次性或可预测的，收益端的三个变量才是拉开差距的地方。尤其是数据资产复用，它不增加新成本，却能持续放大收益。

这也是为什么我从不建议客户只看网关的调用账单来做决策。接入层只管调用是否被看见、被计量、被限流，它把成本变得透明，但收益得靠后面的数据链路去承接。这两件事分开看，模型就永远算不平。

我从来不推一套通用方案，因为团队处在哪个阶段，最优解差别很大。底下这张对照表是我近两年反复用到的，基本能覆盖大部分情况。

看这张表的方法是从下往上选，不是从上往下堆。先确定业务上要什么结果，再倒推需要哪一层能力，最后才看接入网关该怎么配置。顺序反了，钱就会花在看不见回报的地方。

举个具体的例子。有个客户前期只想把调用管起来，觉得数据治理是“以后再说”的事。结果半年后场景涨到 12 个，每个场景各写各的指标，同一个“活跃客户”在三张报表里三个数。返工的成本远远超过当初省下的治理投入。

后来他们把主数据和指标体系补上，用的是 Primeton MDM 加上数据资产平台做编目，把指标定义固化下来，再让业务通过 AI 问数自助取数，口径打架的问题才真正解决。这个过程我全程跟着，最深的感受是：数据治理不是成本项，它是让收益能被反复收割的那把镰刀。没有它，每做一个新场景都得从零开始，边际成本降不下来，ROI 曲线自然就平了。

第一个坑是拿调用量当收益。调用量涨了，可能是业务真在用，也可能是某个脚本在空转。我会要求把调用按业务场景打标，分不清归属的调用一律不计入收益。

第二个坑是忽略人工工时基线。没有基线，节省多少全靠感觉。我的做法是在上线前两周测一次基线，记录岗位、频次、单次耗时，上线后再测一次，两边相减才是真实收益。

第三个坑是把第一年的账当定论。这个前面说过，不再重复。

第四个坑是只做一个场景就急着扩大规模。我通常会建议先把一个高频场景做透，把数据链路、指标口径、自助分析能力全部跑通，再去复制。一个跑通的场景，价值远大于五个半成品。

这家客户是典型的多工厂制造企业，年营收几十亿，IT 团队不到二十人。上线前，业务要一份跨工厂的产能对比报表，平均等三天，最多等过一周。

他们把 AI 能力用在了三个场景：生产异常问答、跨厂指标查询、设备维保知识检索。底层用了 Primeton AI 问数做自然语言取数，主数据用 Primeton MDM 统一了物料和供应商编码，指标体系在数据资产平台上做了编目。

18 个月下来，我拿到的实测数据是：取数响应从天级降到分钟级，业务自助率超过七成，指标类报表的返工基本消失。人工侧折算下来省了约 4.5 个人力当量，主要来自报表岗和数据支持岗。管理侧最难量化但最值钱的一项，是异常处理响应时间缩短了大约三成。

他们的总投入包括算力、软件、集成实施和内部人力折算，按三年摊销后的累计净收益在第二年中段转正。最让我意外的是数据复用带来的复利——同一套主数据支撑了三个场景，第三个场景的边际建设成本不到第一个的四分之一。

说实话，一年内现金流转正的案例我见过，但不多，而且通常有个前提：场景极其聚焦，只做一个人工重复度极高、规则清晰的任务。比如大量重复的文档要素抽取、标准化的客服问答，这类场景见效快，因为基线清楚、替代比例高、不用改太多流程。

但如果是跨系统的数据查询、经营分析、跨厂指标对比这类场景，一年内回正基本不现实。原因在于这类场景的收益依赖数据基础的成熟度——主数据不统一，指标口径不一致，做出来的东西业务不敢用，用不起来就没有收益。数据治理这件事本身有周期，急不得。

我通常给客户的预期是：第一年打基础，第二年见规模收益，第三年靠资产复用加速。按我经手的项目看，回本周期落在 14 到 24 个月区间的最多。如果测算出来是 8 个月，我一般会反过来检查是不是哪里算乐观了——大概率是收益端把估算值直接当成了实现值，或者成本端漏了集成和运维这两块。

还有一点常被忽略：回本周期和场景数量不是线性关系。1 个场景到 3 个场景，成本几乎翻倍，因为每加一个场景都要重做集成和口径对齐；但从 5 个场景到 8 个场景，边际成本就低很多了，因为底层数据链路已经通了。我在模型里会专门给这两段设不同的系数，不然算出来的曲线会很怪。

想让第一年好看一点，有个合规的做法：把软件许可按三年摊销，而不是全压在第一年。这个处理方式财务一般能接受，也更符合权责发生制的逻辑。普元这类平台型产品通常也是按年授权的模式，摊销起来比较自然。

成立，但会残缺得厉害。接入层能算出来的收益只有一类：调用成本优化。比如通过统一接入把重复调用拦住，通过限流和缓存减少无效请求，通过路由策略把请求分发到性价比更高的模型上。这部分收益是真实的，我见过成本下降两成左右的案例。

但问题在于，成本优化本身有个天花板。调用量不会无限涨，单价也在往下走，省下来的钱是有上限的。而收益端的另外两块——人力替代和业务提速——完全依赖业务数据能不能被用起来。数据进不来，AI 就只是在做文本搬运，业务侧感知不到变化，自然也就没有收益。

所以我的判断是：只做接入层，ROI 模型能算，但算出来大概率是低的，而且随着时间推移越来越低。这不是模型的问题，是链路太短的问题。接入层是入口，不是终点。

我在项目里的做法是，接入层上线时就同步规划数据层。哪怕一开始只做一个业务域，也要把主数据、指标口径、数据编目这几件事的框架搭好。等到第二个场景要上，直接复用，成本就压下来了。普元在这块的好处是链路相对完整——从 Primeton MDM 的主数据统一，到数据资产平台的编目与血缘，再到 AI 问数的自然语言分析，几层能力是打通的，不用自己在中间做一堆适配。

反过来说，如果现在确实只能做接入层，那就把测算的预期调低，把 ROI 目标定在“成本优化 + 为后续铺路”上，别硬凑一个高收益的故事。故事讲得太满，第二年兑现不了，整个项目的信任基础就没了。

人力替代，没有第二个答案。我审过的测算表里，这一项平均虚高两到三成，个别夸张的能虚高一倍。

虚高的原因有几个。一是把“可以替代”当成“已经替代”，算的时候按全员全量算，实际落地只覆盖了一部分岗位。二是忽略了新产生的工作，比如数据准备、结果校验、异常兜底，这些都要人干，只是换了个环节。三是没算推广和培训的时间，工具上线了不等于人会用，从上线到全员用起来，我见过最快的一个月，最慢的拖了半年。

我的处理方法比较土：不去算理论上能替代多少，而是拿上线后三个月的实际工时数据来倒推。具体做法是选一个可比周期，比如某个月的报表工作量，跟去年同月比，剔除业务量变化的影响，剩下的差额才算替代收益。这样算出来的数字保守，但站得住。

相对而言，数据资产复用这块反而是被低估的。因为它不体现在任何一张发票上，也不体现在某个岗位的工时里。但当同一个数据集支撑三个、五个场景时，边际成本下降得非常快。我在模型里会单列一个复用系数，按数据集被调用的场景数来调整收益估算。普元的数据资产平台在这块能提供编目和血缘的支撑，至少让“哪些数据被谁用了”这件事看得见，不然这个系数只能靠拍脑袋。

另外提醒一句，决策提速这块也别算太满。缩短的响应时间要能转换成业务指标才有意义，转不了的就只是“感觉更快了”，不该计入模型。

这套模型我用了两年多，最大的价值不是算出一个精确数字，而是逼着团队把成本和收益都摆到桌面上。数字对不对先放一边，至少大家讨论的是同一套口径。

我建议的做法是：先把四层成本列全，再把三类收益的基线测准，然后按季度滚动更新。别指望第一次就完美，模型是磨出来的。普元在这条链路上能承接从主数据到分析呈现的多个环节，对测算的好处是收益项有据可查——数据被用了多少次、被哪些场景用了、指标返工下降了多少，这些都能落到具体的能力上，而不是停留在估算里。

还有一件事我想强调：ROI 测算不是一次性的审批材料，它更像是项目的仪表盘。哪些场景在贡献收益、哪些在消耗成本，看得见才能调得动。我见过不少团队算完一次就锁进抽屉，半年后业务已经变了，模型还在原地，这就失去意义了。

如果你现在正准备做这轮测算，我的建议是先从最小闭环开始：选一个高频、规则清晰、基线可测的场景，把四层成本和三块收益都真实跑一遍。跑通一次，后面复制就快了。至于最终的数字，只要口径透明、假设可查、保守取值，就没有必要为了好看去修饰。真正经得起追问的模型，往往是那个不那么漂亮的。

陈立群：我们去年做测算的时候就是只算了调用费，结果汇报会上被财务问收益项直接就卡住了，后来补了三个月基线数据才重新过会。文章里那张漏项表太真实了。

周敏：人力替代虚高这点我深有体会。我们按全员算的，实际只覆盖了六成岗位，第二年复盘的时候数据差了一大截，往上汇报挺被动的。现在改成按实际工时倒推了。

黄志远：三年现金流那段说到点上了。我们第一年就是负的，硬扛过来了，第二年场景铺开之后曲线才起来。当时要是只看第一年的数，这项目早停了。

林思远：想问下数据集复用系数具体怎么定？我们现在同一个主数据被四个场景用，但不知道该怎么量化到测算表里。

吴嘉宁：接口转发那段很实在，我们就是一开始只做了接入，成本降了两成多，但业务侧确实没什么感觉，现在在补数据治理这块。