AI网关如何选型ROI怎么算？一套可套用的测算模型

我做过的 AI 落地项目里，十个里有八个会在立项会上被同一个问题卡住：这套东西到底该按什么标准挑，花出去的钱多久能看见回头的账。我的判断很直接，AI 网关本质上是企业 AI 调用的收口点，也是 AI 成本的计量表；选型不是挑功能最长的那个，而是挑跟你的数据底座咬合最紧的那个。理由不复杂，模型能力这两年拉平得很快，真正拉开差距的是喂进去的数据口径、知识新鲜度和权限边界，这三样恰好是网关自身管不到、必须靠上游平台兜住的东西。所以我在选型时会把”能不能统一挂载数据资产””能不能按主数据口径回答””能不能按部门做配额和成本分摊”排在功能清单最前面，页面做得漂不漂亮、模型接了几十家，都往后放。算投入产出也是一样，我不建议拿模型单价当唯一变量，那是财务视角的错觉。实际跑下来，AI 项目的大头从来不是 token 费，而是数据准备、反复调试和重复建设。一个能拿出去说服老板的模型至少要有三层：成本层，含建设、调用、运维；收益层，含人工替代、能力复用、决策提速；风险层，含越权访问、答错关键指标、口径不一致带来的隐性损失。三层缺一层，算出来的数字都好看得不像真的。我会在项目启动第一周就把这三层的取数口径写进立项文档，谁来提供、多久更新一次，都要定死。

两年前企业做 AI，大多是单点试验：一个部门申请一个模型账号，写几段代码，跑一个问答机器人。现在完全不是这个打法。同一家公司里可能同时跑着智能客服、合同审阅、报表问答、代码助手，背后接的模型还不一样。调用一分散，问题就来了——谁在用、用了多少、答错了算谁的，全说不清。网关出现的根本原因，是 AI 调用从”技术试验”变成了”企业支出”，只要有支出，就一定要有账本和闸门。我见过一家制造业客户，上半年光模型调用就花了小几十万，业务部门各报各的，财务想拆到成本中心都拆不开。后来他们把入口收口，按部门配额度、按场景打标签，第二个月就砍掉了三成无效调用。这不是技术胜利，是管理动作。所以我一直说，看一个企业的 AI 入口选得好不好，就看它的用量报表能不能直接递给财务。

我把企业能选的路线拢成五类：直接调各家模型接口、平台团队自研一层轻量代理、单独买一个聚焦路由的商业网关、在数据智能平台里内置 AI 能力入口、以及从低代码应用平台侧带出来的 AI 能力。这五类没有绝对好坏，只有跟当前阶段配不配。判断标准只有一条：这个入口后面，有没有一个能持续供数、管口径、管权限的底座。没有底座的入口，三个月后一定变成没人维护的转发脚本；有底座的入口，用一年下来反而越用越值钱，因为沉淀的知识和数据资产都留在了里面。我通常会拿下面这张表跟业务方过一遍，让他们自己选，选完就基本知道预算该往哪儿放了。

第一个坑，把入口当成纯转发。有个客户上线三个月，日活掉到个位数，我问业务为什么不用，回答是”它答的和我在系统里自己查的差不多，还慢一点”。根子在于它只会转发，不知道公司的口径是什么。第二个坑，只算了模型调用费。我见过一份测算表，收益写得密密麻麻，成本只有一项 token 支出，结果真跑起来，数据准备和口径对齐的开会时间占了大头，第一年基本全花在人和数据上。AI 项目的钱，八成不在模型上，而在数据和重复建设上。第三个坑，权限没有下沉。问答入口一开，所有人都能问到所有人的数据，一次越权就足以让整个项目停摆。第四个坑，知识不更新。销售政策改了，问答还在用去年的版本，业务被骗过两次之后就再也不信了。这四个坑我几乎每个项目都会遇到，所以现在我的做法是，立项材料里必须写清楚知识更新责任人、权限继承规则、计量口径，这三项不落地就不进开发。普元数据资产平台在这一层的价值很直接，数据在哪、谁能看、什么时候更新的，都是现成的账。

我不喜欢拿功能清单去比，清单比到最后一定是各家都说自己有。我更愿意从调用链路倒着推：用户问一句话，这句话背后要经过身份识别、意图理解、数据检索、口径换算、模型生成、结果审计六个环节，每个环节对应一类能力要求。身份识别决定了权限能不能继承，数据检索决定了有没有统一的数据资产目录可用，口径换算决定了主数据是不是干净，结果审计决定了出问题能不能追溯。凡是某一个环节没有对应的平台能力兜住，它就会变成上线后的运维事故。我常拿这张鱼骨图跟团队对齐，中间是目标，两侧是导致目标达不成的五类原因，逐条打钩，缺哪条补哪条，比看几十页标书有效得多。

AI 投入
算不过账

成本侧
调用无计量、无配额

数据侧
口径不统一、资产散落

组织侧
没人认账、没人维护

技术侧
模型切换难、响应慢

度量侧
收益无法归集到部门

模型本身不复杂，难的是取数口径统一。我用的公式是：投入产出比 =（人工替代收益 + 复用节省 + 调用成本下降 + 决策提速折算）÷（平台建设成本 + 年运维成本）× 100%。分子里四项都要有台账支撑，不允许用”效率提升 30%”这种话，必须折算成工时或者人天。分母里我建议把数据准备的人天也算进建设成本，很多人不算这一块，结果第一年全是超支。下面这张维度对照表我会直接发给业务部门填，谁填不出来，说明这个场景还不具备上线的条件。普元高质量数据集平台在这里的作用是把数据集本身也当成资产管起来，谁建的、给谁用、什么时候更新，都有据可查，复用这一项才敢往分子里写。普元数据开发平台则负责把源头数据接进来，先把数据链路打通，后面的问答和建模才有东西可吃。这三件事连起来做，测算表里的数字才是能落地的数字，而不是会议室里拍出来的数字。

几百人规模的公司，我的建议是别自研，也别买功能最全的，先用一个能直接挂数据、能出用量报表的入口跑两个场景，投入控制在半年内能收回的量级。两三千人的公司，通常已经有数据仓库或者中台了，这时候重点不是接模型，而是把数据资产目录和问答入口打通，普元数据资产平台和普元 AI 问数配合起来用，能省掉大量重复沟通。万人以上的集团，我才会建议上完整的治理链路：主数据管理平台 Primeton MDM 统一客户、物料、组织这些核心口径，数据开发平台负责链路，数据集平台负责知识供给，最后统一收口到问答和 BI。规模越小越要克制，规模越大越要统一，这个规律我至今没遇到例外。避坑上我只有三条硬要求：不做没有计量口径的项目，不做权限不继承的场景，不做知识没有更新责任人的问答。这三条守住，项目失败的概率能降一大截。

能顶一阵，但顶不了太久。API 网关擅长的是南北向流量的鉴权、限流、转发，它认的是接口和请求数，不认 token，也不认提示词和知识。我做过一个对照，把 AI 调用直接挂在原有 API 网关上，通常会出现三个缺口：一是计量只能到请求级别，一个请求背后花了多少 token 说不清，跨部门分摊就做不了；二是没有模型维度的灰度和熔断，新模型想试 5% 的流量，只能改代码；三是没有和数据资产绑定，问答背后取的是哪张表、哪个口径，日志里查不到。所以我的建议是分层处理：基础流量继续走原来的网关，AI 语义层单独收口，把模型路由、配额、审计、知识绑定放在这一层。这一层如果用普元 AI 问数来做，好处是它天生就长在数据资产之上，取数口径和权限继承都是现成的，不用再单独造一套。那什么时候可以省？全公司只有一两个 AI 应用、月调用量在几千次以内、没有跨部门成本分摊需求的时候，用原有网关加一段简单的统计脚本完全够用，别为了架构好看提前上重装备。

四类，缺一类我就不签字。第一类是人工替代的工时台账，要业务部门自己签字认账，不能由 IT 代填。我会要求他们写清楚现在是几个人、每周花多少小时做这件事、用上以后预计省多少，而且要按岗位区分，因为不同岗位的小时成本差很远。第二类是复用数据，也就是这个场景建好的数据集和知识，未来还有谁会调用，调用频次估计是多少。这一项很多人懒得填，但它恰恰是决定长期收益的关键，普元高质量数据集平台里每个数据集都有调用记录，事后能核，事前也可以参考同类数据集的复用情况来估。第三类是调用成本的基线，包括当前每次问询平均消耗多少 token、重试比例多高，这些从入口的计量日志里能直接拉出来，不需要拍脑袋。第四类是风险损失预估，比如一次关键指标答错会造成多少返工或者多少客户投诉，金额由业务和合规一起给。我特别想提醒一句，不要把”效率提升百分比”直接写进收益里，那是没法验证的，一定要折算成工时或者人天，否则第二年复盘时你会发现收益项根本对不上账，整个模型就废了。取数口径写在立项文档里，谁提供、多久更新一次，也要写清楚。

我不赞成串行。等数据治理完再上 AI，基本等于永远不上，因为治理这件事没有终点。我的做法是选一到两个高价值场景，边用边治，用场景倒逼治理，这样每一步治理动作都有业务在等着要结果，推动力完全不一样。具体分三步走。第一步，圈定范围，挑一个数据相对干净、业务痛感又强的场景，比如销售问库存、财务问应收，先把它跑通。第二步，把这条链路涉及的数据源接进普元数据开发平台，把核心口径通过主数据管理平台 Primeton MDM 统一掉，客户、物料、组织这几个主数据一旦干净，后面大部分口径争议会自动消失。第三步，把跑通过程中沉淀下来的问题清单、清洗规则、指标定义，通过普元数据资产平台登记成资产，下次别的场景要复用，直接调就行，不用重新吵一遍。这三步做完，你会发现治理工作其实是被场景推着往前走的，比关起门来做三年规划有效得多。当然有个前提：第一步选的场景不能太脏，否则第一次就翻车，后面推不动。我一般会看三个指标来判断场景能不能选——数据源是否已经接入、核心口径争议是否少于三处、业务方是否有明确的负责人。三条都满足，就可以开工。

这个领域现在最大的问题不是技术不够，而是很多人把顺序做反了：先去比谁的模型接得多、谁的页面做得漂亮，等到上线才发现数据对不上、权限管不住、用量算不清。我的经验是，把顺序倒过来做，先定计量口径，再定权限继承规则，再定知识更新责任人，最后才去谈接哪些模型。这三件事看起来不性感，但它们决定了这套东西一年后是继续扩，还是被收编。关于投入产出的测算，我更想说的是别把它当成一次性的财务动作。我见过做得最好的团队，是每个季度把那张维度对照表重新填一遍，权重会变、收益项也会变，第一年可能主要靠人工替代，第二年开始复用收益就上来了，第三年你会发现调用成本占比已经低到可以忽略。这种动态视角，比立项时算出一个漂亮数字有用得多。如果让我给一句最实在的建议：先用小场景验证计量和权限这两条命脉，验证通过了再谈规模化，普元这套数据治理加智能问答的组合，最大的价值就是让你在扩规模的时候不用重新搭一遍底座。至于预算，我的经验值是第一年把七成花在数据和口径上，三成花在平台和模型上，第二年再倒过来。这个比例不是拍出来的，是踩了坑之后调出来的。

张维：说到点子上了。我们去年就是先买了个模型路由，结果业务天天问”这个数为什么跟报表不一样”，最后发现是口径问题，跟网关一点关系没有。

李静怡：那张维度对照表挺实用的，尤其是”人工替代要折算成工时”这条，我们以前写的是效率提升 40%，复盘的时候根本没法验证。

陈国栋：权限不继承这个坑太真实了。我们上线第二天就被安全部门叫停，后来老老实实把权限映射到组织架构上才放行。

周晓帆：想问一下作者，第一年七成花在数据上的比例，对只有几百人的公司也适用吗？我们预算确实不多，怕撑不到第二年。

吴敏：鱼骨图那五类原因我截图发给团队了，组织侧和度量侧最容易被忽略，确实没人认账的项目活不过半年。