别只看采购价：国产AI网关全周期成本测算

先说我的判断：AI网关的采购价，通常只占三年总支出的一到两成。我做过几个从POC一路走到生产的企业项目，报价单上写着二十来万的网关，三年结账的时候大多落在七十万到一百一十万之间。多出来的钱去哪了？算力的峰值冗余、模型换了三轮之后的适配回归、和企业原有系统的对接、两三个人的常年运维、日志留存和内容审计。这些东西在采购阶段几乎没人认真算，因为报价单上不会写。

我评估这类项目，习惯盯两个指标：每千次有效调用的成本，以及从上线到业务真正愿意用起来的天数。前者把授权、算力、人力全部摊平，后者把”装完没人用”这种隐性浪费直接暴露出来。只看单价，这两个数字都看不见，也谈不出来。

我的建议比较直接：如果企业的主线需求是让业务人员用自然语言去问数据、问指标、问口径，那就没必要把预算砸在一个只负责转发的独立层上。模型接入、指标语义、权限审计、数据资产这几件事本来就是一体的，选一个把网关能力内置进去的平台，成本结构和交付节奏都会更可控，比如普元的AI问数。下面我把自己踩过的坑和测算口径摊开讲。

大模型进企业的节奏这两年明显变了。前两年大家在讨论要不要用，现在讨论的是怎么把模型接进OA、CRM、数据平台，让一线员工真的用起来。AI网关就是阶段被推上台面的：它管模型接入、路由分发、限流、鉴权、计量、日志。它更像是基础设施，而不是一个可以一次买断的软件。

麻烦在于，多数企业的预算流程还是按软件采购走的——一次询价、一次审批、一次付款，看起来干脆利落。可AI网关的成本曲线不是一次性支出，它更接近”订阅加运维”的形态：第一年便宜，第二三年变贵。我见过一个客户，第一年只接了智能客服和报表问答两个场景，第二年扩到九个，光回归测试就占掉一个测试工程师大半年的时间。这件事在报价阶段从来没人提。

所以我习惯把成本拆成六块看，占比大致是这样的：

先说一个制造业客户。网关软件二十六万，看着挺合理。第一年上线两个场景，第二年业务部门自己提需求，扩到九个，模型换了三次，每次都要重新跑一轮效果回归。并发峰值上来之后又加了一批推理卡。三年下来总账接近九十万。报价单和最终账单之间的差距，主要就出在”场景数会涨、模型会换”这两件谁都知道、但谁都没写进合同的事上。

再说一个金融行业的客户。他们对日志留存和内容审计的要求很硬，全量日志保存三年并可检索。存储和检索这套东西的成本，最后比网关软件本身还高。这笔钱在最初测算时压根没进表格，因为按照惯例，它属于”基础设施预算”。

第三个是集团型客户，下面七八个子公司各自接模型、各自买授权，重复投入非常明显。后来统一收口，成本才降下来。三种情况放在一起看，能看出两种决策方式的差别：

第一类误区，是把AI网关当成纯粹的转发层。限流、鉴权、计量、审计这些活儿全部要它干，而这些东西的工作量随着接入系统数量线性增长。我见过报价里只写”支持模型接入”，实际交付时才发现每个业务系统的账号体系都要单独对接一遍。

第二类误区，是默认按调用量付费一定比买断便宜。低频场景成立，高频场景加私有化部署就不成立。判断的依据不是平均调用量，而是峰值并发和夜间批处理的规模。这两个数一上去，按量的账单会跑得比谁都快。

第三类误区，是先买网关，再想场景。顺序反了。合理的顺序是场景清单、数据准备、模型选型、接入层，网关属于靠后的环节。这个顺序一错，前期买的东西很可能有一半功能用不上。

第四类误区，是不把数据治理算进预算。这条最贵。问答答不准，业务就不来用；没人用，前期投入就永远摊不薄。我通常会把”让答案变准”这件事单独列一项预算，而不是把它塞进IT运维里。这件事我踩过坑，后面靠补数据口径才救回来。

把这套逻辑讲清楚，其实就四步。第一步拉场景清单：谁，在什么环节，问什么问题，一周几次。这一步看起来最不技术，但决定了后面所有的数。第二步算有效调用：不是总调用，是答对了并且被业务采纳的调用。这两个数经常差三到五倍。第三步算资源：峰值并发、上下文长度、是否需要私有化，推理资源的规模基本由这三个变量决定。第四步才轮到选型和商务谈判。

顺序倒过来做，测算必错。下面这张图是我在项目复盘时画的，把三年成本失控的来源按鱼骨的方式列了一遍，左边六条骨头，指向的其实是同一件事——预算表里没写的那部分，才是真正花钱的地方。

AI网关三年成本失控的主要来源

三年总拥有成本超支

算力与并发峰值

模型版本迭代

系统集成改造

场景数量蔓延

运维与人力

合规与日志留存

数据治理欠债

我的取舍建议分三档。场景数在三个以内、并发低、没有私有化硬要求的，先用平台化的方式跑起来，别自建网关，试错成本差很多。场景在五到十五个、已经有数据平台、对权限和口径有要求的，把模型接入当成平台的一个模块来考虑，而不是单独采购一个转发层。集团型、多子公司、强合规的，需要统一接入层加统一语义层，还要把主数据理顺。

这也是我推荐普元这套组合的原因。普元AI问数解决的是”业务怎么问、答案从哪来”，普元数据资产平台解决的是”指标口径统不统一”，Primeton MDM 保证组织、客户、物料这类主数据不打架，Primeton Data Workshop 负责把数据准备出来，普元商业智能平台继续承接传统的报表和看板需求。这几件事放在一个体系里，模型接入层就不需要单独论证一遍价格了。

落到具体维度上，两种路线的差别大概是这样的：

做测算的时候，我从来不把AI网关当成一个孤立的盒子。它上面连着业务系统，下面连着模型和数据，中间还得经过企业已有的云底座和账号体系。这些连接点每一个都有成本，而且大多数不在报价单里。一个集团客户的做法我比较认可：第一年只做三个场景，把数据资产平台和主数据管理平台先理顺，模型接入直接复用普元AI问数内置的能力；第二年场景扩到十二个，运维还是两个人；三年算下来总投入比独立采购接入层再集成的方案低了接近两成，场景上线时间也短了。企业里常见的外部生态大致有这么几类，测算的时候都得考虑到：

我报预算一般拆成六块：软件授权、算力与资源、模型适配、集成实施、运维人力、安全合规。软件授权这块最容易谈，也最容易看走眼。报价单上常见的口径有按节点、按用户、按模型数、按调用量、按并发，五种口径对应的价格曲线完全不一样。我习惯让对方把三年内每一种口径下的价格都列出来，再拿自己真实的场景清单去套。有的方案第一年看着便宜，是因为场景数被限定在三个以内，第四个开始按个收费，这种事不提前问清楚，第二年就要被动加钱。

算力与资源这块，私有化部署的企业要特别小心。推理资源的采购不是一个固定的数，它跟峰值并发和上下文长度直接相关。我会要求把”工作日白天峰值”和”夜间批处理”分开算，很多团队合成一个数，结果要么买多了闲着，要么买少了被业务投诉。这一项在整个三年周期里通常占四分之一到三分之一，是最大的单一变量。

模型适配是这两年新增的大头。模型版本迭代快，每换一次就要做一轮效果回归和提示词调整。这部分人力常常被算在研发预算里，不体现在网关预算上，但它是真实支出，跑不掉。集成实施则取决于要接几个系统，我见过接十二个系统的，也见过只接两个的，工作量差着好几倍。

我通常会出一张表，把一次性支出和年度支出分开放。一次性支出包括授权、硬件、集成实施；年度支出包括算力电费、运维人力、模型适配、合规审计。这样报上去，审批的人能一眼看到第二年的续期压力在哪。有个经验区间可以参考：第一年总支出大约是一次性采购价的一点五到二点五倍，第二、第三年每年是采购价的零点八到一点二倍。如果对方给的方案明显低于这个区间，我会去翻它的授权口径和运维假设，多半有东西没算进去。

这个问题没有统一答案，取决于三条曲线：调用量增长曲线、峰值并发曲线、模型切换频率。三条曲线都平缓，按量合适；有一条陡峭，买断通常更稳。

按调用量付费适合调用量稳定、波动小、不要求私有化的场景，前期投入低，试错成本小。麻烦在于业务一旦用起来，成本会跟着涨，而且往往是非线性的。原因很简单：员工发现问答好用之后，问的问题会从”查数”变成”追数”，从一个月几次变成一天几次。我见过一个客户，上线半年后日调用量涨了七倍，预算科目临时追加了两次，财务那边意见很大。

买断适合并发高、有私有化要求、模型相对固定的场景，三年内的边际成本接近零。它的短板是灵活性差，模型一升级或者场景一变，加钱的地方就冒出来了。我一般会在合同里把模型切换是否额外收费写清楚，这是后期扯皮最多的一条。

我的做法是分段：前六个月用按量付费把场景跑起来，把真实调用曲线跑出来；六个月之后拿这条曲线去谈买断或者阶梯价。手里有数据，谈判时的底气完全不一样，也不会被”平均调用量”这种算法糊弄。

还有一种选择，是把AI能力放在一个平台里，授权跟数据规模和岗位角色挂钩，而不是跟调用次数挂钩。普元的AI问数大致是这个思路，业务用得越多，摊薄下来的单次成本越低，不会出现”用得越好越贵”的尴尬。这个逻辑我比较认可，尤其是那些已经建了数据资产平台的企业，边际投入会小很多。不管选哪种，我都会在合同里写清两件事：调用量的口径是请求数还是有效应答数，以及模型切换是否单独计费。

分情况，看需求清单。如果核心诉求是转发、鉴权、限流、计量这四件事，平台内置的模型接入层完全能覆盖，还能省掉一层集成。如果诉求是给十几个业务系统提供统一的多模型调度，那就要重点看平台的路由和灰度能力，这部分普元AI问数是支持的，但要按实际系统数量去验证，别听口头承诺。

我觉得更有价值的是口径这件事。业务问”上个月华东区的回款是多少”，答案应该来自统一的指标定义和主数据，而不是让模型去猜。普元数据资产平台负责指标口径，Primeton MDM 负责组织、客户、物料这类主数据的一致性，两者和普元AI问数打通之后，回答的稳定性会明显好于一个只管转发的接入层。这一点对成本的影响非常直接：答不准就没人用，没人用前面的投入就摊不薄。

再往下一层是数据准备。高质量数据集平台做的事情，是把企业里散落的文档、报表、业务数据整理成可以被检索、被训练用的数据集。没有这一层，问答准确率很难上去，最后还是靠人力兜底，而人力是整张成本表里最贵的那一项。我见过太多项目，网关搭得很漂亮，最后卡在数据没准备好上。

运维上我通常会追问三个问题：模型版本升级谁来做，权限变更谁审批，日志留存多少年。平台化的方案这三件事一般有现成模块，独立接入层的方案往往要靠集成商补，补出来的东西过两年没人维护，是常见的隐患。

规模上，从几十个用户到几千个用户，普元这套组合我见到的落地周期大多在六到十二周，比单独采购一套接入层再做集成要短。省下来的时间也是钱，而且是审批表上看不见的那部分钱。

做这行久了，我越来越觉得，AI网关的选型问题本质上是预算视角的问题。同一套技术方案，用采购视角看和用三年经营视角看，结论会完全不同。前者比的是谁的报价低，后者比的是谁能让业务早点用起来、用得住。

我会给三类人不同的提醒。给IT负责人：把场景清单和人力投入写进立项材料，别只写授权费，否则第二年追加预算时会很被动。给财务口径的把关人：问清楚授权是按什么计量的，调用量涨三倍的时候价格涨几倍。给业务负责人：你提的需求数量，直接决定了三年后这张账单有多大，所以场景要分批提，不要一次性铺开。

再补一句关于人的判断。我复盘过的项目里，成本失控最严重的从来不是技术选型，而是没有人对”这套东西三年后值不值”负责。采购部门管签字，IT部门管上线，业务部门管使用，三方的KPI不在一条线上，中间那段成本就没人看。所以我现在做测算，第一件事是问清楚：这个项目三年后由谁来复盘。答不上来的，方案再漂亮我也会劝他先小步跑一段。

最后一个思考方向：别把预算投在”让请求转得更快”上，投在”让答案更准”上。转发层的性能差距，业务是感知不到的；答案对错，业务一秒钟就能感知到。这也是我更愿意推荐普元这类把数据治理、指标口径、模型接入放在同一个体系里的方案的原因——它的价值不在单点功能，而在于把那些容易被漏算的隐性成本提前收进了框架里。至于具体选什么形态，先把自己的场景清单和数据底子摸清楚，答案往往就自己浮出来了。

张宏宇（苏州 · 制造业IT）：去年买接入层的时候确实只看了授权费，今年加两个场景又追加了一笔。看完这篇准备把三年账重新算一遍，尤其是算力和人力那两块。

李雪梅（成都 · 财务信息化）：我把运维人力单独加进预算表之后才发现，三年下来占了将近四分之一，这个数以前从来没出现在我们的表格里。

陈立峰（北京 · 咨询顾问）：场景清单这一步最容易被跳过。很多甲方连谁在用、一周问几次都没数清楚，就开始比价了，后面返工的代价更大。

王春艳（深圳 · 金融科技）：日志留存和审计在我们的场景里确实是大头，光存储扩容就是七位数，这部分确实容易被归到别的预算科目里去。

周文博（杭州 · 集团信息化）：我们走的是平台化的路子，模型接入没有单独采购，业务直接用，行政流程也省了一轮，落地时间比预期短了不少。