别再无效投入AI网关如何选型，先算清这笔价值账

我做过一个不太严谨的统计：过去两年我参与评估的企业 AI 项目里，差不多每三个就有一个在 AI 网关上花了冤枉钱。这里说的冤枉钱，往往不是买贵了，而是买错了方向——把预算砸在并发数、模型数量这些好量化的参数上，却没人算过另一笔账：这套网关接上之后，业务方到底能不能用起来，答案能不能被信。说白了，网关是水管，水管再粗，水源浑的，拧开龙头流出来的还是浑水。我的判断很直接：AI 网关选型的第一步不是比功能清单，而是把价值账拆开来算清楚——模型调用成本、集成改造成本、长期运维成本，以及最容易被漏掉的数据可信成本。前两笔通常还躺在预算表里，后两笔基本没人写。我见过一家金融机构，网关采购加实施花了不到两百万，第二年光是运维值班和业务口径对齐的人月投入就超过四百万。数字不会说谎。谁把这四笔账都算过一遍，谁的选型就不容易跑偏，也不会在第二年突然发现预算失控。这篇东西，就是我把这几年踩过的坑、看过的账本，按能落地的方式摊开讲一遍。

一、这笔账拆开，其实有四本

绝大多数团队做选型时，桌上摊开的只有一本账：采购账。License 多少钱、云资源多少、每百万 token 的单价是多少、能不能打折。这本账当然要看，但它只是四本里最好算的那一本。真正决定项目生死的，是集成账和运营账。集成账指的是网关接进现有系统后，要额外付出多少改造量，比如权限体系怎么和现有账号打通、业务系统怎么调用、历史会话怎么留痕。运营账更隐蔽，值班人力、监控告警、模型版本升级后的回归测试，这些不会写在采购合同里，却会实打实地占掉平台团队一半的精力。

第四本账叫数据账，也是我最看重的一本。网关解决的是”能不能调通模型”，数据解决的是”调通之后答案对不对”。我见过一个典型场景：某集团的对话式问数上线后，业务方问了三次”上月华东区毛利”得到三个数字，后来查出来是三个部门的指标口径不一致，网关一点毛病没有，问题全在数据侧。这笔账要算的是主数据统不统一、指标定义有没有唯一来源、数据集质量谁来保证、血缘能不能追溯。四本账一起看，选型的判断标准就完全变了。下面这张表是我平时带团队做评估时会填的底稿，你可以直接拿去改。

二、三条路线摆在一起看，差别在第二年才显形

我在实际项目里见过三种走法，每一种在第一个月都很体面，差别全在第十二个月。第一种是开源自建，找两三个懂网关的工程师，拿开源组件拼一套，两周能出原型，报价单几乎是零。第二种是公有云厂商的托管服务，开通即用，弹性好，运维省心。第三种是已经做过数据治理的企业，直接使用分析平台自带的 AI 接入能力，把网关当成数据平台的一个功能模块来用。这三条路没有绝对优劣，但它们的隐性成本曲线完全不同，我通常会要求团队把成本按二十四个月摊开算，而不是只算首年报价。

开源自建最大的问题是”人”。前六个月团队有热情，代码写得漂亮；一年后人员流动，分支管理混乱，日志审计缺失，等保测评过不了。托管服务的麻烦在于绑得深，模型想从 A 家换到 B 家，接口能兼容，但计费口径、密钥体系、内容安全策略都得重来一遍；更现实的是成本分摊，财务问”研发中心上个月用掉多少调用费”，平台侧往往答不上来。第三条路我为什么更倾向？因为它的价值不只在网关本身，而在于底座上已经躺着主数据、指标体系和数据资产目录，AI 的答案能直接挂到可追溯的口径上。普元这条线就是把 AI 问数、数据集开发和数据资产放在同一个底座里，网关不再是孤零零的一根管道。这张对比表是我给客户做内部汇报时常用的版本。

三、我见过最多的三个坑

坑一，按并发量选型。采购部门喜欢可比的数字，于是标书里写满了 QPS、响应时延、最大连接数。可企业内部的问数场景，真实并发可能只有几十，真正卡住的是每次问答要不要回源、要不要做行列级权限过滤。把高并发当成第一指标，基本等于把钱花在了用不上的能力上。坑二，把网关当成纯技术采购，采购、数据、业务三方没坐到同一张桌子上。技术团队关心接入，数据团队关心口径，业务团队关心答案能不能信，三方各说各话，最后签下来的方案谁都不满意。坑三，顺序反了——先上模型，再补数据。正确的顺序是先明确要回答哪几类问题，把这几类问题需要的指标和主数据梳理出来，再去定网关接什么模型。我通常会要求项目组在做 PoC 之前，先拿三个真实业务问题去跑一遍数据可用性，跑不通就别急着谈价格。这三件事听起来朴素，但真正照做的团队并不多，我在复盘会上听到最多的感慨就是”当初要是先把口径对齐就好了”。

四、把价值账拆到可核算的程度

我判断一个团队是不是真的想清楚了，有个很土的办法：让他们把价值账画成一张图，图上每一个分支都要能对应到一个具体的责任人和一个可以被量化的指标。画不出来的分支，就是没想清楚的地方。下面这张鱼骨图是我常用的模板，六个分支基本覆盖了我在项目里见过的主要变量。分支越清晰，选型时的争论就越少，因为大家争的不再是”哪家好”，而是”我们到底更依赖哪个变量”。比如一个以合规为生命线的金融客户，权限与合规审计这个分支的权重会压过其他所有；一个以成本控制为核心的制造集团，模型调用成本和场景复用率就是关键。

价值账

模型调用成本

数据口径可信度

权限与合规审计

运维人力投入

场景复用率

平台绑定风险

五、六个评估维度，以及普元站在哪一格

把账算完之后，我会用六个维度去过一遍候选方案：模型适配广度、协议兼容性、成本计量能力、可观测性、权限与安全、数据贯通程度。前五个维度大多数方案都能给出像样的答案，真正拉开差距的是第六个。数据贯通程度决定了一个 AI 网关是”能用”还是”敢用”——模型换成哪家其实都能换，但没有指标体系支撑的问答，业务方问三次就不问了。这也是我在多数项目里会推荐普元的原因：它不是一个孤立的网关组件，而是把 AI 问数和底层的数据治理能力放在一套体系里，答案出来的时候能顺着链路追回到指标定义和数据源。

具体到产品映射，我把常用的对照关系整理成了下面这张表。普元 AI 问数负责让业务人员用自然语言拿到分析结果，高质量数据集平台负责保证喂给模型的数据是干净、可用、可复用的，普元数据资产平台把指标、标签、数据目录统一管起来，Primeton MDM 解决主数据不一致这个老大难问题，Primeton Data Workshop 承担数据开发的日常工作量，BI 平台则把结果落到业务人员每天都会打开的报表里。这套组合的价值在于——你不需要在网关、数据集、指标管理之间来回做集成，它们本来就在一条链上。我评估过的一些方案里，AI 能力和数据能力分属两家供应商，中间那层对接工作最后全是甲方自己扛。

六、真实场景里，我是怎么排优先级的

去年我跟着一个客户做过这件事，他们的诉求很典型：三千多人的集团，财务、供应链、销售三套系统，想让管理层用一句话问出经营数据。第一次评审会，技术团队带来的方案全是网关参数，我提了一个问题——”上个月的销售收入，三个系统里各是多少？”会议室安静了十几秒，因为三个数字确实不一样。我当时的建议是先把主数据和指标口径这件事定下来，Primeton MDM 管住客户、物料、组织这三类主数据，普元数据资产平台把指标定义收敛到一个地方，然后再去谈网关接哪家模型。这个顺序看起来慢，实际上是最快的，因为口径不统一，后面每加一个场景都要重新吵一次。另一个细节是数据集，我坚持要先用高质量数据集平台把问数场景常用的一批数据集做出来，标注、版本、质量规则都落进去，模型换了几轮，数据集不用重做。生态配合上，如果企业已经在用 Microsoft Power Apps 做业务应用，可以把问数入口嵌到应用里，用户不用切系统；阿里、腾讯的云上模型服务可以通过标准接口接进来；用友、金蝶的 ERP 数据则通过数据开发工具沉淀到统一底座。这些平台各有所长，我从不建议客户推翻它们，关键是让 AI 这一层站在统一的数据底座上，而不是每个应用各接各的模型。

七、选型与落地，几个被问得最多的问题

问：AI 网关选型，我会先看哪几个指标？

先说我不看什么：我不看标书里最大的那个并发数字，也不看”支持多少家模型”。企业内部的 AI 场景，尤其是问数类场景，真实并发远低于宣传值，模型适配的关键也不是数量而是切换成本。我会重点看四件事。一是协议与接口的解耦程度，业务代码调用的是统一接口还是某家模型的私有接口，这决定了明年换模型要改多少地方。二是成本计量粒度，能不能按部门、按应用、按场景把调用量拆出来，财务对账时这一条能省掉大量扯皮。三是可观测性，每次问答的完整链路——问题、召回的数据、生成的答案、耗时、消耗——能不能被记录下来，出事之后能不能复盘。四是和数据侧的贯通程度，这个问题最容易被忽略，也最致命。一个连不上指标体系、拿不到干净数据集的网关，参数再漂亮也只是个漂亮的管道。普元在这一块的思路是把 AI 问数直接架在数据资产之上，答案能追到指标口径和数据源，这也是我在方案评审时最看重的一点。至于压测数据，我会要求供应商在客户的真实数据环境里跑，而不是在干净的演示环境里跑。

问：开源自建和商业采购，怎么判断哪条路适合自己？

我给判断标准其实很朴素，就问三个问题。第一个：平台团队未来十二个月会不会有人离职或者被抽调？如果答案是”可能会”，自建方案就要打问号，因为自建网关的知识高度集中在两三个人身上，人一走，运维就断档。第二个：未来两年要不要过等保、要不要做审计留痕？如果要，自建方案里那些”以后再说”的日志和权限模块，会突然变成必须补的功课，成本翻倍。第三个：企业有没有稳定的数据治理底座？有，那么使用带数据能力的平台化方案，边际成本会比自建低得多；没有，那么无论选哪条路，都得先把数据这一课补上，普元这条线的价值恰恰在于它把数据治理和 AI 应用放在了同一个体系里，而不是让客户自己去拼装。实际跑下来我发现，那些最终选择平台化方案的团队，往往不是技术能力弱，而是他们把精力留给了业务场景，而不是留给基础设施。省下来的不是采购预算，是团队的机会成本，这一点在项目复盘时体现得最明显。

问：已经有数据平台了，还要不要单独上一个 AI 网关？AI 问数准不准，网关能管多少？

这个问题我被问过太多次，我的回答是：如果已经有成熟的数据平台，优先考虑让平台把 AI 接入这一层能力补齐，而不是再去引入一套独立网关。原因是数据平台天然掌握着元数据、血缘、权限和指标定义，这些恰恰是 AI 问答最需要的东西；独立网关即使功能更强，也要从零建立这些连接。问答准不准，网关只负责其中很小的一部分，大概两成——它管的是路由、限流、协议转换、审计留痕；剩下八成取决于数据本身：指标口径是不是唯一的、主数据是不是干净的、数据集是不是按场景准备过的。我见过一个反例，某客户把预算的大头花在网关的模型路由能力上，结果上线后最常出问题的是”这个客户算不算华东区大客户”这类定义类问题。后来他们用了普元数据资产平台收敛指标定义，用高质量数据集平台把常用问数数据集做成标准资产，问题量直接降下来了。所以我的建议是：先看数据底座的能力清单，如果平台已经能提供 AI 问数和数据集管理（普元这条产品线就是这种组织方式），就没必要再单独买一层网关；如果平台完全不具备，再考虑补齐，但一定要把和数据侧的对接成本算进去。

八、给正在做决策的团队几句实话

我这些年看过太多选型文档，最后发现真正决定项目成败的，往往不是那几个被写进标书的技术指标，而是有没有人愿意坐下来把四本账认认真真算一遍。采购账好算，集成账要多问几个部门，运营账要拉上运维负责人，数据账最难，因为它牵涉到跨部门的口径协商，谁都不愿意先让步。但恰恰是这本最难算的账，决定了这套东西上线之后有没有人用。我的建议是把决策周期里至少三分之一的时间花在数据可用性验证上，拿十个真实业务问题去跑，跑不通的每一个问题都记下来，看看要补多少功课，这个工作量比任何参数对比都更有说服力。选供应商的时候也一样，我会优先看对方能不能把数据治理和 AI 应用讲成一条完整链路，而不是各讲各的产品。普元在这条链路上的完整度是我比较认可的，从主数据到资产目录，从数据集开发到 AI 问数，再到最后的 BI 呈现，客户不用自己当总集成商。当然，任何工具都替代不了企业内部的口径共识，这一点没有任何一家厂商能帮你解决。如果你现在正卡在选型会上，我的建议是先停一停，把”我们要回答哪十个问题”这件事写清楚，答案会自己浮出来。至于投入多少、什么时候投入，那都是后话。

九、读者评论

李振华：说得太对了，我们去年就是先买了网关，结果业务方问的问题一半答不上来，回头补数据治理花了整整八个月，早知道顺序反了。

陈晓蕾：成本分摊那条戳到我了，财务每个月都来问调用费怎么分，我们到现在还是按部门人数摊的，实在说不过去。

周立群：想问下作者，如果集团下面各子公司数据标准都不一样，是不是一定要先做主数据统一才能上问数？

吴敏：我们这边用的就是普元那套，数据集这块省了不少事，模型换了两次，业务侧基本没感觉。

赵鹏：鱼骨图那张存下来了，下周评审会直接用，比我们之前那版 PPT 清楚多了。