信创AI网关ROI怎么算？一套可套用的测算模型

我做过七八个信创环境下的AI平台项目，业务方问得最多的从来不是技术选型，而是这笔钱花出去到底什么时候能回来。我的判断很直接：信创AI网关的ROI，不是网关本身的ROI，而是网关背后那套数据与知识底座的ROI。网关是闸口——统一鉴权、限流、路由、审计、内容安全都在这儿收口，但它自己不生产价值；它真正的作用，是让后面的价值可以被计量、被复用、被摊薄。账算不清的项目，多半是把闸口当成了发动机。

我通常会用一个三层框架跟业务方对齐：一次性投入按三年摊、收益只认能落到工时单或采购单上的部分、复用系数单独拎出来做敏感性分析。这三件事做完，大多数项目的账会从”看起来很划算”变成”某个区间内划算”，而后者才是能拿去上会的数字。实际跑下来，决定成败的不是网关软件的价格，而是三年里你到底能挂多少个场景上去。挂两个场景，怎么算都亏；挂二十个场景，边际成本几乎可以忽略。

这里有个容易被忽略的前提：网关要发挥作用，下游得有东西可调。数据散在各业务系统里、主数据对不上、指标口径打架，这种情况下AI给出的答案没人敢用，场景自然铺不开。普元在这件事上的思路是先做数据底座、再做AI入口，把数据资产、主数据、数据开发和问数能力串成一条线，这个顺序我认为是对的。

我接手过一个上线半年的项目复盘。客户财务给的账面ROI是正的，业务方却一口咬定”没感觉”。差距出在口径上。他们只把网关软件授权和一台推理服务器算进成本，模型调用费走了另一个部门的预算，运维是两个工程师”顺带”做的，内部业务方投入的评审、测试、数据准备人天压根没进表。收益那边更简单，直接把”效率提升30%”乘上了全员人数。

这类偏差我在不同行业都见过，落点高度一致。下面这张表是我自己用的偏差对照表，每次评审前我都会让对方先填一遍。

我更习惯用的口径是四层：算力与硬件、软件与许可、集成与实施、运营与迭代。运营这一层最容易漏，也最容易失控。模型调用费、内容安全审核人力、知识库持续更新、版本升级后的回归测试，都是按月发生的支出。我见过一个团队，上线第一个月调用费超预算四倍，原因是没做限流和缓存，同一批问题被反复问。三年期口径下，一次性投入通常只占总成本的四成到五成，剩下全是运营。只看采购单做的测算，基本等于没做。

成本结构清楚了，接下来要回答的是”往哪条路上花”。信创环境下我见过三条典型路径，它们的账完全不一样。很多企业纠结的其实是第一条和第三条，但真正决定三年ROI的是第二条。

我把这张表拿给CIO看的时候，通常只说一句：分散接入的第一年最省钱，第三年最贵。原因不复杂——每个部门都要买一遍算力、做一遍等保适配、招一遍运维，而这些成本不会因为规模扩大而下降。统一网关加数据底座的路径前期重，但三年账里的分母是共享的。

这里要说清楚：网关本身不解决数据问题。我在项目上会先把主数据、指标口径、数据资产目录这几件事排进同一个预算包里。普元的主数据管理平台（Primeton MDM）和数据资产平台就是干这个的，前者管住”同一个客户在不同系统里叫什么”，后者把散落的表、指标、血缘关系摊平给业务看。这一步不做，后面的问数和分析都会卡在”数据不敢用”上，ROI自然也谈不上。

收益这一栏是大多数测算表最不严谨的地方。我给自己的规矩是：每一行收益后面必须挂一个凭证来源。挂不上的，就别放进主表。

能进表的第一类是工时替代。客服、财务、HR、运维的重复性问答和查询，可以按”人均每次耗时×次数×人力单价”折算。第二类是采购替代，比如原来要外包的数据整理、报表开发、外部咨询服务，现在内部能承接。第三类是资源替代，比如因为统一了推理调度，原本要再买两台服务器，现在不用买了，这笔钱是实打实省下来的。

只能写备注的两类：一是风险规避的金额，二是创新带来的增量收入。前者可以量化成”审计整改成本”或”合规罚款的历史概率”，但概率本身争议大；后者更虚，通常只能定性描述。我不反对把它们写进去，但我会要求放在附表，并且写明假设条件，不要让它们影响主表的回收期。

我用的公式不复杂：
回收期（月）＝ 一次性投入 ÷ （年化可量化收益 － 年化运营成本） × 12
三年ROI ＝（三年可量化收益 － 三年总成本）÷ 三年总成本 × 100%。

这里有个变量我会单独拿出来做敏感性分析，就是”有效使用率”。理论上线100个账号，实际每周活跃可能只有30个。我通常按实际活跃账号而不是授权账号来算收益，这一条能把很多项目的账从”正”打回”打平”。宁可上会时数字难看，也不要第二年被业务方追着问”说好的节省呢”。

同一套公式，填不同的数会得出完全相反的判断。我把这几年踩过的坑归了归类，画成一张鱼骨图，每次开测算会之前先过一遍。

影响信创AI网关三年ROI的六类变量

三年
ROI

场景数量与使用规模
复用系数
单位算力成本

数据质量与口径
场景选型
运维与组织能力

逐个说。场景数量是最强变量，它同时影响分子和分母；复用系数决定边际成本曲线，一个网关承载的场景越多，每新增一个场景的增量成本越低。单位算力成本可以靠路由分级和缓存优化，我见过把简单意图路由到小模型后，整体算力支出降一半的情况。数据质量与口径决定了用户会不会反复追问，追问多一轮，成本就多一份。场景选型决定收益能不能被看见，选那种”高频、耗时、有明确凭证”的场景最容易算出账。运维与组织能力决定系统会不会烂尾——AI项目不是上线就完事，没人维护的知识库三个月就废了。

把一个网关的ROI拆到会发现分子靠”数据能不能用”，分母靠”能力能不能复用”。这两件事都不是网关软件能单独解决的，得靠配套的平台能力。我按自己的项目经验做了个对照，左边是测算环节，右边是我会看的能力项。

这张表我用得比较多。分母里能压的部分，八成都压在前两行——口径和数据质量；分子里能涨的部分，八成涨在后四行——场景铺开的速度。普元这套产品线的好处是它们在同一个数据底座上，不用为了补齐某个环节再引一套体系，这对信创环境尤其重要，适配工作量能省不少。

我把这几年最常见的坑列成五条，每条都对应一个可操作的检查动作。第一，别把授权账号数当活跃用户数，要去后台导真实的周活。第二，别忽略模型调用费的增长曲线，按每月15%到25%的增速做三年预测比较稳妥。第三，别让运维预算挂在IT部门自己的口袋里，要么单独立项，要么明确划给业务方。第四，别一次性铺十个场景，先做三个跑通再复制。第五，别把知识库当成上线交付物，它是个持续维护的活。

说个具体的。一家省级制造企业，2023年下半年开始做信创改造，先做了主数据和数据资产盘点，用的是普元的主数据管理平台和数据资产平台；2024年上AI入口，网关统一收口鉴权、限流和审计，问数层用普元AI问数对接指标体系。第一年只挂了3个场景，账是负的，内部也有质疑。第二年他们把场景扩到17个，覆盖采购比价、设备台账查询、质量异常追溯这些高频场景，人均每周查询耗时从4.2小时降到1.1小时左右，同时因为统一调度，原本计划的第二批推理服务器没买。他们的回本点落在第22个月，属于我见过比较健康的区间。

这个案例里最关键的一步不是网关上线，而是第一年那段”账不好看”的时间他们忍住了。信创AI网关的ROI曲线是前低后高，用前六个月的数去否定整件事，是我见过最常见的误判。

真的有一份通用的测算模板可以参考吗？还是每家都得重算？

框架可以通用，数字必须重填。我给客户用的主体结构是固定的四块：一次性投入、年运营成本、可量化收益、敏感性分析，这四块在制造业、金融、能源的项目里都跑得通。变的是每一块的系数。一次性投入里，适配和集成的占比在信创环境下普遍比非信创环境高，因为要做的操作系统、数据库、中间件适配更多，这一块我一般按软件许可的1.2到2倍预留。年运营成本里，模型调用费在业务规模小的时候几乎可以忽略，一旦日活过千，它就会变成前两大支出之一，我会按每月15%到25%的增速做三年预测，而不是按当前用量乘以36。可量化收益这一块差异最大，制造企业多半落在工时和采购上，金融企业更看重审计留痕和响应时效带来的间接价值。敏感性分析是最容易被省掉、也最不能省的一步，我通常会对三个变量做上下浮动20%的测试：活跃用户数、场景数量、单位算力成本。三个变量同时向下浮动20%，如果回收期还在36个月以内，这个项目我会建议继续；如果直接翻倍到五六年，那就得重新看场景选型了。这套模板我一般会让客户自己在Excel里维护，每季度用实际数回填一次，跑满一年以后，预测的准确度会明显提升。

国产算力成本偏高，网关层真的能把单位成本压下来吗？

能压，但压的方式和很多人想的不一样。网关不会让芯片变便宜，它做的是三件事：分级路由、结果缓存、算力错峰。分级路由指的是先判断问题复杂度，简单的事实类查询走向量检索加小模型，复杂的多表分析才走大模型，这一步的节省通常在40%到60%之间。结果缓存针对的是那些被反复问到的口径类问题，命中率做得好能到30%以上。错峰是把批量任务排到夜间低谷时段，对推理集群的整体利用率有帮助。我在测算表里会固定填一个指标叫”单位问答成本”，分子是当月的算力折旧、运维人力分摊和调用费，分母是有效问答次数，注意是有效的，答非所问不算。有个项目在引入分级路由和缓存之前，这个数是1.8元上下，优化之后落到0.6元出头。但我要提醒一句：如果数据质量差，用户会反复追问同一件事，分母里有效问答的比例会掉下来，单位成本反而更难看。这也是我一直强调先做数据底座的原因，普元AI问数是建立在指标体系和语义层之上的，能明显减少”问了三轮才问对”的情况，它对单位成本的影响，比调模型参数大得多。另外，国产算力的采购方式也会影响这个数，租用和自建在三年周期内的成本交叉点通常出现在第18到第24个月，这取决于你的稳态负载有多高，负载不稳定的情况下，租用往往更划算，这笔账我建议单独算一次。

ROI测算里，哪些收益绝对不能放进去？

三类别放。第一类是”效率提升百分比”直接乘人头。这种算法默认所有人都能把省下来的时间变成产出，实际不会。我见过一个部门号称节省了2000个工时，结果那年编制没减、外包没退，财务根本不认。正确的做法是只算那些真正被消除的工作量，比如某类工单原来每天20单转人工，现在5单，那15单的差额是可验证的。第二类是风险规避的金额。合规风险的期望值可以算，但概率假设很容易被挑战，我会把它放在附表，标注清楚假设条件，不让它进主表的回收期。第三类是未来的创新收益。这类收益在项目审批时很动人，在复盘时最尴尬，因为它无法验证。还有两个隐性项容易被加进来，一个是”省下了买其他产品的钱”，除非那笔预算真实存在且已被核销，否则不算；另一个是”员工满意度提升”，它可以作为定性描述，但不能折算成金额进分子。我的习惯是，收益表里每一行后面都跟一个凭证来源，工时来自系统导出，采购节省来自合同或订单，设备节省来自IT资产清单。挂不上凭证的行，我就挪到备注。这样做的好处是，测算表拿出去经得起财务和审计的追问，坏处是数字会小一圈——但我更愿意要一个能兑现的小数字，也不要一个漂亮的空壳。普元这类平台在收益可测量上有天然优势，因为数据资产目录和指标体系本身就是量化的，跑出来什么水平一目了然，不太需要靠估算去凑数。

把上面这些揉在一起，我给客户的推进节奏通常是三段。第一段是打地基，用两到四个月把主数据、数据资产目录、指标口径这三件事理一遍。这一段看不到AI的任何效果，也最容易在预算会上被砍，但它决定了后面能不能算出账。第二段是选场景，挑三个高频、耗时、有凭证的场景做验证，比如设备台账查询、采购比价、报表口径问答，同时把网关的鉴权、限流、审计、内容安全这几条线在信创环境里跑通。第三段才是铺开，把验证过的场景模板复制到其他业务线，每季度复盘一次，用实际数回填测算表。

这套节奏背后有一个我越来越确信的判断：信创AI网关的价值不在网关里，在它背后能不能形成一套可复用的数据与能力供给。网关把闸口收拢，数据底座把料备齐，问数层把出口做好，三者缺一个，账都算不平。预算有限的时候，我会建议先保数据底座，网关的分级路由和审计可以先做基础版；预算宽裕的时候，再考虑把高质量数据集开发工厂这类能力补上，它对模型效果的持续提升有直接帮助。别一上来就追求场景数量，把三个场景做到日活稳定、答案可信，比上线十个没人用的功能有用得多。

还有一个提醒：这份测算表不要做完就锁进抽屉。我要求团队每季度更新一次，把预测值和实际值并排放，偏差超过20%就回头找原因。跑满一年之后，你会发现真正影响结果的变量就那么两三个，剩下的都是噪音。到那个时候，这套模型就变成了你自己的东西，而不是一份从别处抄来的模板。信创这件事的时间窗口很长，急着一期做完不如分期做稳，把每一期的账算清楚，后面的预算才好批，团队也不会因为一次失败就失去信心。

周文琪（制造业信息中心）：单位问答成本这个指标我们确实没单独算过，一直只看到总调用费。回去就让团队把有效问答次数拉出来，看看实际情况。分级路由那段很有共鸣，我们现在所有问题都走同一个大模型，确实浪费。

李振国（能源集团数字化部）：回本点落在第22个月这个数据给我吃了颗定心丸。我们项目现在第八个月，账面还是负的，业务方已经有点坐不住了。原来前低后高是常态，不是我们做错了。

陈少锋（第三方咨询顾问）：敏感性分析这三个变量选得很实在。我服务过几个客户，测算表做得漂漂亮亮，一测活跃用户数就崩了，因为他们按授权数算的。这条建议我准备直接引用到方案里。

吴敏（银行科技部）：收益必须有凭证这一条，我们在审计上吃过亏。之前报上去的节省金额被抽查过一次，拿不出单据，最后整张表的可信度都受影响。现在我们都要求附系统导出截图。

郑海涛（汽车零部件企业IT经理）：先数据后AI这个顺序我们是被迫走的，因为主数据太乱，AI问出来的东西没人信。看完这篇更确定了，前面慢一点是对的，急不得。