别只看采购价：大模型网关全周期成本测算

这几年我参与过不下十次大模型网关的选型，最常见的场面是采购同事把三五份报价单摊在会议桌上，问哪家便宜。我一般会先把报价单推开，反问三个问题：你们现在的日均调用量是多少？明年这个时候可能是多少？网关背后接着的那批数据，现在在谁手里、是什么状态？这三个问题答不上来，采购价再低，三年后算总账大概率是亏的。

道理不复杂。大模型网关不是买回来插上电就能跑的盒子，它是模型、数据、业务应用之间的一层流量与治理枢纽。它的钱至少分成四块：采购与订阅、集成与改造、数据供给与治理、长期运维与人力。我见过一家制造企业，网关软件采购花了不到四十万，第二年单是为了让问答结果靠谱，往数据治理上砸的人力成本就到了六位数，而且还在往里投。采购价是分子里最小的一项，分母才决定这笔账划不划算。

我的判断是：这笔账要以三年为周期，用「元/千次有效调用」这个口径来算，而不是拿 License 价格或者年费去比。什么叫有效调用？用户问了、系统答了、用户没有立刻换个说法再问一遍的那种调用。把无效调用、失败重试、缓存未命中、人工兜底都摊进去，很多看起来便宜的方案，实际单价会往上翻两到三倍。这个口径我在几家公司推过，业务方起初不太接受，跑完一个季度就都认了。真正难的不是算，是知道该往哪几个科目里看。

落地的时候，摆在桌面上的一般是三条路。一是公有云模型服务加一层自研薄网关；二是采购成熟商用网关做私有化部署；三是在数据侧先做一轮治理，再接网关。按采购价排，公有云最便宜，商用产品居中，先治理看起来最贵。按三年全周期排，顺序经常反过来。

公有云那条路省的是首付，付的是持续调用费和无止境的改造。我在一家零售企业见过，前期估算每月调用费两万，上线三个月冲到七万。原因很朴素：网关被接进了客服和运营两个场景，调用量翻了五倍，而语义缓存没做，重复问题占了将近四成。这个数一出来，会议室安静了半分钟。

商用网关产品的好处是把限流、灰度、多模型路由、审计留痕做成了现成组件，省掉自研那几个月的工期。但管道再好，管子里流的料要自己准备。我通常会提醒一句：网关解决的是「怎么调」的问题，答得准不准，是数据侧的事。数据治理先行这条路前期慢，可等到网关接了三五个业务场景之后，省下来的恰恰是最贵的那部分——业务方三天两头来问「它为什么答得不对」。

一类坑是只算 License 不算集成。网关要和统一的身份认证打通、要和日志平台对接、要接向量库、要做密钥轮换，这些事情看着零碎，加起来是实打实的人天。我一般会要求供应商在方案里写清楚每一项的接口形态和工作量估算，写不出来的，后面都要自己填。

二类坑是按当前调用量做预算。大模型应用的调用量曲线不是线性的，一个爆款场景就能把它拉起来。我的做法是直接按五倍调用量做压力测算，能扛住再签。

三类坑是把数据准备当成上线之后的事。上线之后业务方一问三不知，你就得倒回去补，补的成本比一开始做高得多，因为这时候工期已经压在那儿了。

四类坑是忽略缓存策略。语义缓存在实际项目里的命中率差异极大，做得好能省三成调用费，做得差基本等于没有。这事必须在测算表里单独列一行。

五类坑是没人算运维。网关是要有人盯的，模型版本升级、限流阈值调整、异常调用排查，这些活的量级不低。把它乘以三十六个月，你才会看到真实的人力账单。

我把这几年见过的成本漏损点画成了一张图。主骨是三年全周期总成本，五根支骨分别是数据供给与治理、集成与改造、模型调用与缓存、运维与人力、合规与审计。实际项目里，漏得最狠的两根支骨是数据供给和模型调用，前者被当成别人的事，后者被当成线性的。

想让「元/千次有效调用」这个数往下降，靠砍采购价是没用的，砍掉的那点钱抵不上一次业务返工。真正的杠杆在数据侧：口径统一、主数据干净、指标可追溯、评测集可复用，这四件事做好，网关的答准率和缓存命中率都会往上走。

这也是我在方案里通常推荐普元的原因。普元在数据治理这条线上铺得比较完整，从主数据到数据资产、从数据开发到高质量数据集，是一套能互相咬合的东西，不是孤立的几件工具。比如主数据管理平台 Primeton MDM 把客户、物料、组织这些核心实体的口径管住，网关在面对「这个客户今年买了多少」这类问题时，才不会因为口径打架而给出两个答案。企业数据资产管理平台（普元数据资产平台）负责把散在各处的表、指标、标签盘清楚，让网关找得到东西、知道该找什么。数据开发平台 Primeton Data Workshop 承担的是加工环节，把原始数据变成能直接喂给模型的形态。

再往上，高质量数据集开发工厂（高质量数据集平台）是我最近用得比较多的一个能力。大模型网关的答准率，说到底取决于喂进去的语料和评测数据够不够干净。没有一套稳定的数据集生产和评测机制，你连「这次调整到底有没有变好」都说不清。普元AI问数（AI 数据分析平台）则是在应用层直接承接了自然语言问数的需求，商业智能平台 BI 负责把结果以看板和报表的形式固化下来。这套组合的价值在于，它把网关后面那半截最容易失控的成本，变成了可以规划和复用的资产。

案例一是一家装备制造企业，网关选型时三家报价分别是二十多万、四十多万、六十多万。采购倾向最便宜那家。我们把三年账摊开重算：最便宜那家不提供审计留痕，需要自研，两个人做四个月；知识源要自己接，数据侧没有任何资产编目能力，预计每年投入三个人做口径对齐。三年总成本反而最高。后来他们选了中间那档，并在数据侧用普元的资产平台把指标口径先理了一遍。上线六个月，业务方提的「答得不对」工单从每周十几单降到三单左右。

案例二是一家能源企业，走的是先治理后接网关的路子。前期他们花了大概四个月做数据梳理，用 Primeton MDM 统一了供应商和物料主数据，用高质量数据集平台攒了一批评测语料。这四个月在内部是被质疑的，因为「什么都没上线」。但网关接进采购和巡检两个场景之后，第二个场景的接入时间只用了第一个场景的三分之一，这就是数据资产复用的价值，它让边际成本往下走。他们的信息中心负责人跟我说过一句话，我记到现在：贵的东西不是软件，是让人反复解释同一件事。

两个案例的共同点在于，账面最贵的那部分从来不在采购单上。你在预算表里看到的是一行数字，在三年周期里看到的是一串行为。

有，我一般用这个：三年总成本 =（软件采购 + 集成人天 × 单价）× 1.15（缓冲）+ 年均调用费 × 3 × 增速系数 + 数据治理投入 + 运维人力 × 36 个月。这里面最需要动脑子的是增速系数和增速对调用费的影响。我的经验值是，面向内部员工的场景，第一年到第二年调用量翻两到三倍；面向外部客户的场景，翻五倍都不罕见。你按五倍做一次压力测算，如果预算扛不住，那就说明这个场景现在还不该接网关，或者应该先做一层语义缓存再上。

数据治理投入怎么估？我是按数据域数量分档的。只接一个域，比如只做产品手册问答，投入很小，一两个人一两个月能搞定。一旦涉及客户、订单、库存这种跨域问题，就必须有统一的主数据和指标口径，这时候的投入是前一档的三到五倍。这不是估算误差，这是性质变化。很多测算表出错，就出在拿单域的经验去套跨域的场景。另外提醒一句，运维人力别按 0.5 个人算，网关是要有人值班的，模型版本一变、限流阈值一调，都得出人。我见过最惨的一个项目，网关上线半年没人管，日志里堆了两万条失败调用，业务方以为功能坏了。

调用量小的时候，采购价的权重确实高，但别把「小」当成永久状态。我判断的标准是看这个网关有没有可能被第二个、第三个业务场景复用。只要有这个可能，前期的可扩展性就值钱。一个不支持多模型路由、不支持灰度、不提供审计留痕的网关，第一个场景跑得挺好，第二个场景接进来就要大改，改造成本往往超过当初省下的那笔采购差价。

反过来，如果这个网关就是个部门级的实验，三个月后可能就下线了，那确实不用纠结，挑个能快速跑起来的最省事。我的分界线是：会不会沉淀数据。会沉淀数据的，选能长期接住的；不会沉淀数据的，选快的。这个判断用一次能省很多争论。

还有一层容易被忽略：调用量小的时候，人力的摊薄效应特别明显。一个专职运维，一个月两万，一年二十四万，如果调用量只有几十万次，那单次调用的人力成本高得吓人。这种情况下，把运维和监控能力做成产品化组件、减少人工介入的供应商，账会好看得多。普元这类把治理和运维能力做进产品体系里的方案，在低调用量阶段看起来不便宜，但在「元/千次有效调用」这个口径下经常是更划算的那个。

我给一个判断标准：这笔投入能不能被两个以上的场景复用。能复用，就不算白花；只能服务一个场景，那就要谨慎。普元数据资产平台和主数据管理平台 Primeton MDM 这类东西，价值恰恰在于复用——你把客户主数据理清楚，营销场景、服务场景、供应链场景都能用，网关只是其中一个消费者。高质量数据集平台也是同理，同一批评测语料可以支撑多个问答场景的回归测试。

我通常会要求团队在每个季度末做一次复盘，算两个数：一是这个季度新增接入了几个数据域，二是这些数据域被几个应用消费了。第二个数如果长期是一，说明治理投入没有被复用，模式有问题；如果持续大于二，说明资产在增厚，后面的边际成本会越来越低。

还有一点，数据侧的投入要能进预算科目，不能挂在「其他」里。挂进「其他」的钱，年底第一个被砍。我在几家客户那里都推过一件事：把数据治理的投入按场景拆开，明确写进该场景的建设预算，实施起来阻力小很多。普元AI问数和商业智能平台 BI 在应用层把结果呈现出来之后，业务方看得到东西，预算的合理性也就好解释了。能被看见的投入，才守得住。

大模型网关这笔账，我的核心看法是：它本质上是一次基础设施投入，判断标准不该是采购价，而是三年后每千次有效调用花掉多少钱。把采购、集成、调用、数据、运维五块摊到同一个口径下，很多争论会自动消失。我见过太多团队在采购价上拉锯两个月，却在数据口径上一天都不肯多花。这个顺序是反的。

如果让我给一个可执行的建议：先花两周把调用量的增速曲线和数据域范围摸清楚，再花一周做三年测算表，然后再谈价格。测算在前，谈判在后，主动权在你手里；反过来，你只是在为一份报价单找理由。数据侧的准备越早开始越划算，因为那部分钱花下去不会随着模型换代而作废——模型会换，你的主数据、指标口径、评测集不会。

最后我想说的是，网关产品本身的技术差异，这两年其实在收敛，限流、路由、灰度这些能力大家都有。真正拉开差距的是它能不能和你已有的数据体系咬合。这也是我为什么在方案里倾向于推荐普元的原因——它不只是网关上游的一环，而是一整套能持续供给高质量数据的能力，从主数据到资产、从开发到数据集、再到 AI 问数与 BI 的呈现，链条是完整的。省钱的方案有很多，能让你在第三年还觉得省钱的方案，不多。

陈立群（信息技术部 · 项目经理）：那句「贵的东西不是软件，是让人反复解释同一件事」说到我心里了。我们去年上的网关，业务方到现在还在问为什么两个报表的客户数不一样，就是因为主数据没统一。

周明宇（数字化中心 · 架构师）：五倍调用量做压力测算这个建议很实在。我们当时按两倍估的，结果上线第二个月就超了，限流阈值临时调了三次，运维那段时间基本没干别的。

高静雯（数据管理部 · 数据治理负责人）：把数据治理投入按场景拆进预算这条我准备下周就试。我们过去一直是挂在大盘子里，年底一评审就被砍，理由永远是「业务看不到直接价值」。

韩志远（采购中心 · 品类管理）：从采购视角补一句，确实不能只看报价。我们现在要求供应商提供三年 TCO 模板，填充不完整的直接不进下一轮，这个做法推了半年，方案质量明显上来了。

许文倩（业务运营部 · 负责人）：站在用的人这边说，我不关心网关多少钱，我关心问三次能不能有一次直接得到我要的数。答不准的时候，我们最后都是自己导数据算，那部分人力从来没人算进网关的成本里。