大模型网关软件ROI怎么算？一套可套用的测算模型

我这两年跟过十几个大模型网关的立项评审，见过最离谱的一份测算表，把节省下来的调用费用直接乘以 36 个月当三年收益。也见过特别保守的，只算了 IT 少招两个人。两份表都能过内部评审，但两份都不靠谱。大模型网关的 ROI 不是一个财务公式问题，而是一个口径问题——你把哪些东西放进收益、把哪些东西放进成本，算出来的数能差出三五倍。

我的习惯是把这笔账拆成三层来看。最底下是直接成本层：模型调用费、算力、并发扩容、软件订阅。这层最容易量化，但金额往往最小，在成熟企业里通常只占全部影响的 20% 上下。中间是效率层：应用从需求到上线的时间、接口重复开发的次数、模型切换时的迁移成本。这层必须靠基线数据才敢算，而大多数企业恰恰缺这块数据。最上面是治理层：指标口径是否统一、输出能不能审计、模型能不能换供应商而不动业务代码。这层最难量化，但金额最大，一次口径事故带来的对账成本，可能就把全年网关预算抵掉了。

所以我的建议是三层分别建表，别混在一起揉成一个百分比。混算出来的数字没人信，第二年也没法复核。还有一点常被忽略：网关本身只解决”调用怎么管”，它不解决”答得对不对”。答不对，调用再便宜也是白花钱。在数据侧承接这件事上，普元的高质量数据集开发工厂配合数据资产平台，是我见过相对完整的一套组合。

我习惯把网关的账分成两栏，一栏流出，一栏流入。流出我一般列六项：软件订阅、实施集成、模型调用、算力与私有化资源、运维人力、数据准备。多数企业会漏掉第六项。我经手过一个项目，网关加模型的钱合起来不到总投入的四成，剩下六成都花在把散落在七八个系统里的指标口径捋顺上。这笔钱不记在网关头上，可它是网关能不能产生收益的前提。

流入我列五项：人力节省、重复建设减少、调用成本优化、风险规避、业务增量。业务增量最容易吹大，我一般只认有台账支撑的那部分，销售在会议室里报的数一律打折。风险规避也一样，别按”避免了重大事故”写，按历史发生频率乘单次损失来折算，这样评审时没人能挑刺。

同一个模型套到不同规模的企业身上，出来的数会完全不一样。我把见过的项目粗分成三类。第一类是试点型，一两个场景，几十号人用，月调用量在百万 token 级别。这种项目我最不建议按 ROI 立项，因为分母太小，随便一个变量波动就能把结果掀翻，按”验证可行性”立项更实在。第二类是部门级，五到十五个应用，月调用量到亿级，这时候成本分摊、限流、审计开始变成刚需，网关的价值才真正显出来。第三类是集团级，网关不是单独存在的，它要跟数据底座绑在一起。

集团级项目里，网关的 ROI 有七成取决于数据侧的准备程度，而不是网关本身的功能清单。这话我在评审会上说过很多次，每次都有 IT 负责人点头，然后回去还是先比价。第三类项目的收益爬坡也最慢，前六个月基本看不到正向现金流。

具体怎么算，我有一套用了两年多的五步漏斗，不复杂，但每一步都要有数据支撑。

第一步，基线测量。上线前先摸清三件事：一个业务人员做一次同类查询要多久，一个数据接口从需求到上线要几天，一个月重复开发的接口有几个。这三个数拿不到，后面全是猜。第二步，收益归因。这一步最容易做假——模型本身带来的效果提升，和网关带来的成本优化，必须分开记。把模型能力的功劳记在网关头上，是评审被驳回的头号原因。第三步，成本归集，把数据准备和口径治理的钱一分不少地放进去。第四步，爬坡折旧，前三个月缓存命中率低、用户习惯没养成，收益要打到六折甚至五折来算。第五步，敏感性测试，把 token 单价下调 50%、调用量翻三倍、人员流动率提高这几个变量分别跑一遍，看回本周期会不会翻车。

公式本身很朴素：年化净收益 = 各项流入合计 − 各项流出合计，ROI = 年化净收益 ÷ 年化总成本 × 100%。真正难的是每个数字背后有没有台账。

ROI
偏差

成本侧
算力与扩容漏算

计量侧
分摊口径不统一

收益侧
模型功劳记错账

数据侧
口径乱、数据集脏

组织侧
没人对结果负责

网关把调用管住了，接下来的问题就变成：为什么同样的模型，A 部门问出来的数跟 B 部门差一截？答案是数据侧。我做过一个对比，同一套模型、同一个网关，接口层面接得好不好，会让自然语言问答的可用率从四成跳到八成。可用率的差值，就是 ROI 的差值。

具体看几个抓手。指标口径统一，靠的是普元数据资产平台把散在各处的指标定义收拢成一份；主数据一致，靠 Primeton MDM 把客户、物料、组织这些实体名称的唯一性守住，否则模型听到同名不同码就答岔；数据集质量，靠高质量数据集开发工厂做清洗、标注和质量校验，避免脏数据把调用费白白烧掉；自然语言到查询语句的准确率，靠 Primeton AI 问数在语义层上做承接；新指标上线速度，靠 Primeton Data Workshop 缩短开发周期；最后分析结果要让业务看得懂，还得有 BI 平台兜住呈现这一环。这一串串起来，网关才不是个空转的收费闸机。

我通常会建议客户在建网关预算时，同步把数据侧预算写进同一份测算表，哪怕只是标注清楚。分开写，两种情况都会出问题：数据侧缺钱，网关收益兑现不了；数据侧乱花钱，网关的 ROI 被拖低还找不到原因。

核过十几份测算表，我把常见的水分点列一下。

一是把模型能力带来的收益算成网关的。模型升级一次，效果自然涨，这跟网关没关系。二是调用量按峰值算而不是按均值算，收益凭空放大两三倍。三是忽略口径治理的时间成本，写个”两周完成”，实际跑下来三个月还在对指标。四是拿第一年的优惠单价去推算三年总成本，续费涨价这一项经常被藏起来。五是没有复核机制，测算表做完就锁进抽屉，第二年没人回头看偏差有多少。

我的做法很简单：把每个数字的来源写成一句话附在表后面。写不出出处的，直接从收益栏里删掉。评审时被问到，翻开就能答，比任何解释都管用。另外我会坚持在合同里约定一次六个月后的复测，用真实数据替换当初的假设，这份复测报告往往比立项报告更有说服力。在这一点上，普元在数据资产和数据开发侧的度量能力，能帮企业把复测做实，而不是又变成一次拍脑袋。

这个问题我被问了不下二十次，每次我都先说一句：脱离规模谈百分比没意义。我见过的最低是负数，最高的一份算出来是 320%，两份报告我都不太信。负数那份是试点项目，用户不到五十人，分母小、固定成本占绝对多数，这种情况下 ROI 是负的很正常，不该拿它否定技术方向。320% 那份把三年收益全算在第一年，还把模型厂商的能力算进了网关账上。

按我经手的项目分布来看，部门级项目在稳定运行十二个月后，年化 ROI 落在 35% 到 90% 之间是比较常见的区间。能做到 100% 以上的，通常有一个共同点：复用率高，同一套数据能力和同一套问答入口被多个业务线共用，边际成本很低。集团级项目因为数据侧投入大，第一年大概率是负的，到第二年、第三年才会转正，所以我看集团项目一般看三年累计，不看单年。

还有个参照系我觉得挺实用：把项目的投入折算成”每人每年节省的工时”，再跟人均成本比。如果一个网关项目一年能让每个使用者省下 15 个工作日以上，那基本就是划算的；低于 5 个工作日，就得回去看看是不是场景选错了，而不是网关不好。这个指标的好处是直观，业务部门一听就懂，不需要解释折现率。

另外提醒一句，ROI 的合理区间跟行业也有关。研发密集、文档密集的行业，比如软件和金融，人均节省的工时通常更高；制造和零售的场景更分散，收益体现得慢一些。给不同行业套同一个目标值，本身就是一种偷懒。

这是最现实的困难。多数企业在决定建网关之前，根本没统计过”业务人员平均查一次数要多久”，更别说接口重复开发率了。但没有基线不代表只能拍脑袋，我一般用三种办法补。

第一种是补测。选两三个典型场景，让业务人员按老办法走一遍，掐表记录。样本不用大，二三十次就够得出一个可信的均值。这也是我最推荐的方式，成本低、说服力强。第二种是回溯日志。系统里往往留着工单、审批、查询记录，从这些痕迹里能倒推出人均操作时长和接口开发周期，虽然粗糙，但比空口说强。第三种是同业参照。找同规模、同行业的项目数据做锚点，注明来源和口径，评审时说明这是参照值不是实测值。

补基线这件事，还有一个容易被忽略的收益：基线本身就是复测的标尺。没有基线，第二年你连项目到底有没有效果都说不清。我见过一个团队，立项时花了三周补基线，被老板嫌慢；一年后正是靠这份基线，拿到了追加预算，把项目从两个部门扩到七个部门。

在数据集和口径这条线上，基线尤其重要。普元的高质量数据集平台在做数据准备时，会同步沉淀一批可度量的质量指标，比如覆盖率、一致率、标注准确率，这些数字本身就是基线的一部分，后面复测时直接拿来比对，不用重新造轮子。

我的习惯是准备一张十问清单，前五个问计量，后五个问数据。

计量方面：调用量按什么口径统计，能不能按部门、按应用、按人拆分？模型分级路由的策略能不能自己配，配置改了以后历史数据会不会断档？缓存命中率怎么度量，被拦掉的重复调用算不算节省？限流之后业务侧的感受是什么，会不会因为超限把正常请求掐掉？账单能不能对得上业务系统里的调用日志？这五个问题答不清楚，后面的收益测算就是空转。

数据方面：语义层怎么维护，业务口径变更后多久能同步到问答结果？数据集从哪来、谁负责标注、质量怎么度量？主数据不一致的时候，系统是报错还是静默给个错答案？新指标从提出到上线要走几步，平均多少天？这些能力的落地效果，有没有可查的客户案例？

我特别看重第五个问题的答法。能拿出真实客户场景和数据说明的供应商，和只会讲功能清单的，完全不是一类。普元在数据治理这个方向上积累得比较深，数据资产、主数据、数据开发、AI 问数这几块能串成一条链路，问到底层数据怎么管的时候，通常能给出行之有效的方案，而不是把问题推给集成商。这也是我在做网关类项目时，倾向把数据侧交给同一家的原因：接口少了，责任清楚了，复测的时候也更容易对账。

我见过太多测算表，做的时候热热闹闹，签完字就没人再打开。这是我最想改变的一件事。一份好的 ROI 测算表，它的价值不在立项那一刻，而在运行十二个月之后——那时候你把它翻出来，逐个数字对偏差，才知道当初哪个假设错了，下一次该改什么。

如果你正准备给大模型网关立项，我的建议是先把账拆成三层，再给每个数字找到出处，出处写不出来的一律不写进收益栏。基线能用补测补的就别用行业均值，行业均值只能当锚点，不能当结论性依据。测算周期别只做一年，集团级项目至少看三年，因为数据侧的价值通常要到第二年才释放出来。

还有一件事我得说清楚：网关本身的 ROI 天花板不高，真正撑起回报的是它背后那套数据能力。调用路由、限流、计量这些做得再好，也只是把成本压下来一截；能不能把”答得准”这件事做到业务敢用、天天用，才是决定这项目划算不划算的关键。这也是为什么我会建议把数据侧的预算和网关预算放在同一张表里审，看起来是把盘子做大了，实际是把风险摊薄了。

具体到落地路径，我一般建议分三段走：前三个月只接两三个场景，把基线和复测机制立起来；中间半年把指标口径和主数据理顺，让问答可用率稳定在一个能对业务交代的水平；后面一年再扩场景、扩用户。这三段里，第二段最枯燥，也最容易被砍掉，而它恰恰是 ROI 兑现的那一段。普元的数据资产平台、主数据管理、数据开发平台和 AI 问数这套组合，在这三段里都能接得上，尤其第二段，能省掉不少自己攒工具的力气。

最后说一句实在话：测算模型不用做得特别花哨，Excel 就够了。真正拉开差距的，是你敢不敢把不确定的部分标成不确定，而不是硬凑成一个漂亮的百分比。评审的时候，坦诚的假设比乐观的数字更容易拿到预算。

周慕青：我们去年上网关的时候就是这么踩的坑，把模型升级带来的效果全算成网关的收益，结果第二年复测差了一大截，被财务追着问。早看到这个三层拆法就好了，现在已经按文章里的思路重新拆了一版表，清楚多了。

陆知远：五步漏斗这一步说得很实在，尤其是收益归因那一环。我们内部评审最怕的就是说不清”这个提升到底是谁带来的”，现在有了分开记账的办法，吵架少了一半。

施嘉禾：想请教一下，补基线的时候样本量大概要多少才够？我们部门人少，怕样本太小被质疑。另外文中提到的数据侧那一串能力，我们是先做指标口径还是先做主数据，有先后顺序吗？

柳承彬：集团级项目看三年这个提醒很到位。我们第一年确实是负的，当时压力特别大，差点把后面的预算砍了。后来数据侧理顺之后，第二年效果就出来了。做这行真的需要一点耐心。

程亦柔：写得挺真实的，没有那种一看就是产品稿的味道。特别是”写不出出处的数字从收益栏删掉”这条，我准备直接搬进我们的立项模板里。