别被销售带节奏：什么是AI网关理性选型指南

我在企业架构和中间件这条线上做了十来年，最近一年被问得最多的问题之一，就是 AI 网关到底该怎么选。问的人里有一大半是被销售讲晕的：有人说它是大模型时代的”流量总闸”，有人说它是”企业 AI 的入口”，还有人直接把它跟 API 网关画等号，报价差出好几倍。我的判断很直接：AI 网关的本质不是转发，而是企业对模型调用的”可管、可控、可算账”。它要解决的问题，是一个请求从业务系统出发、经过鉴权、路由到不同模型、再把结果带回来并且留下账本和证据链的全过程。如果一套方案只能做协议转换和负载均衡，那它就是个代理，不是网关。我在做选型时通常先问三个问题：企业现在接入了几家模型、未来半年会不会接入更多；业务侧是谁在用、能不能自己配；数据出不出内网。这三个问题答不上来，谈功能清单就是空谈。下面这张表是我自己用的前置确认清单，一般会让客户在见供应商之前填完。

三年前企业做 AI，大多是一个部门偷偷试一个模型，写死一个接口就上线了。这种玩法在小范围里没问题，一旦铺到十几个业务系统就崩了：密钥散落在各个代码仓库，谁在调、调了多少、花了多少钱，没人说得清。我见过一家制造企业，三个事业部各自签了模型服务的合同，年底财务对账时发现同一类能力被买了三份，而且用量还都没跑满。AI 网关出现的根本原因，是模型调用从”项目行为”变成了”企业行为”。项目行为靠约定就行，企业行为必须有制度，而制度在技术上就得落到一个统一入口上。这个入口要做的活儿，跟传统网关的差别比很多人想的大。

另外还有一个变化容易被忽略：模型本身在快速迭代。今天效果最好的模型，半年后可能就不是了；今天不能私有化的，明年可能就有了。如果业务代码里到处是某一家模型的 SDK 调用，换一次模型就是一次改造工程。把调用收敛到网关层之后，换模型变成改配置。这件事的价值，只有真正经历过一次”供应商涨价或者停服”的团队才体会得到。我自己参与过的项目里，凡是提前做了这层收敛的，后面调整几乎没有痛感；没做的，一次迁移能拖两个月。

“我们支持几十家模型”——这句话我听得最多，也最容易让人失去判断。支持多少家不等于管得住多少家，关键看新增一家模型要多久、要不要改代码、能不能只让某个部门用它。我选的从来不是模型最多的那家，而是配置最轻的那家。还有一句常见的是”我们性能很强，单机几万 QPS”。企业内部的 AI 调用量，绝大多数场景一个月也就几十万次，拿电商大促的指标来谈，属于答错了卷子。

第三句是”我们自带知识库，不用另外买”。这话要拆开看：自带的知识库通常只能做简单的文档切片检索，一旦涉及主数据、指标口径、跨系统一致性，就顶不住了。企业里真正的难点不是把 PDF 切碎，而是同一家客户在三个系统里有三个名字，模型检索出来之后自己都打架。这块得靠数据治理的底子，不是网关带一个插件能补上的。第四句”我们免费版够用”，我一般会追问一句：免费版有没有审计日志、有没有租户隔离。如果没有，它在生产环境里就只是个玩具，图省事上线，出事的时候一点证据都拿不出来。

落地效果

模型接入复杂度

成本计量与预算

权限与内容审计

语料与数据资产质量

可观测与告警能力

业务侧自助接入成本

这六根骨刺里，我实际项目里最常出问题的是两条：语料质量和业务侧接入成本。前者决定模型答得对不对，后者决定有没有人愿意用。有个案例印象很深，一家能源集团上了网关之后，前三个月调用量一直上不去。排查下来不是技术问题，是业务部门想接一个问答场景，得走两周的工单审批。后来他们把常用场景做成模板，业务侧自助开通，用量才起来。好东西用不起来，多半是流程卡住，不是功能缺了。所以我评估方案时，会专门花时间看业务侧的配置界面，而不是只看后台的运维面板。

铺开讲太长，我一般压成一张对照表，从上往下过。第一层是接入层，看模型适配的广度和新增速度；第二层是路由层，看灰度、降级、限流能不能按业务线配；第三层是安全层，看密钥托管、内容过滤和审计留痕；第四层是计量层，看 Token 统计能不能拆到部门和项目；第五层是数据层，看能不能接上企业自己的知识库和数据资产；第六层是运营层，看监控、告警、版本管理这些日常要用的东西。六层里只要有两层是空的，这套网关在生产环境里就走不远。很多团队吃亏在于只看第一层和第四层，中间三层没细看，上线半年后回头补，代价要翻倍。

第五层和第六层，是我这几年看下来最容易被低估、也最能拉开差距的地方。网关本身管的是”调用”，但调用背后站着的是企业的数据和知识。我在给客户做方案时，通常会把网关和数据侧的供给能力放在一起看，普元的做法就属于这一类：它不把 AI 能力孤立成一个入口，而是和易数系列的数据治理能力连起来。普元数据资产平台负责把散在各系统里的数据登记清楚，Primeton MDM 把客户、物料、组织这些主数据统一口径，Primeton Data Workshop 承担数据开发与调度，高质量数据集平台则把原始数据加工成能直接喂给模型的数据集。这条路子在我看来更接近企业真实需求：模型要答得准，先得让数据可信。

说个具体的场景。一家零售企业想做门店经营问答，用户问”华东区上周销售额为什么掉了”。这个问题链路是：网关接住请求，路由到某个模型，模型需要拿到区域口径、时间口径和门店主数据，才能算对。如果主数据里”华东区”有三种定义，模型再聪明也算不出正确答案。普元在这类场景里的价值，是把口径问题在数据层解决掉，让网关拿到的是干净输入。普元数据资产平台把指标和数据的血缘关系理清楚，Primeton MDM 管住主数据一致性，普元AI问数这层负责把自然语言问题翻译成可执行的分析逻辑，最后通过接口对外提供服务，网关只管调用和计量。分工清楚，各干各的活，比硬塞在一个组件里可靠得多。

还有一点值得说：普元BI 这类既有分析能力，其实能跟问答场景形成互补。看板解决的是”我知道要看什么”，问答解决的是”我临时想知道点什么”。两者共用同一套数据资产，就不会出现口径打架。我在做架构评审时，最怕看到分析口径两套并行，一套在 BI 里，一套在问答机器人里，半年之后没人说得清哪个是对的。落到实施上，我的建议是先治理数据、再建数据集、再上问答和网关，顺序反了就要返工。普元这套产品线的好处是这几步能接得上，不用在四家供应商之间做接口对接。

坑一：把网关当纯技术组件采购，没让业务部门参与。上线之后功能很全，但没人愿意用，因为配置流程比原来直接写接口还麻烦。坑二：只做了接入没做计量，三个月后收到账单才发现某个测试应用跑了几百万 Token。坑三：审计日志开了但没存够时间，等真出事的时候日志早被覆盖。这三个坑的共同点，是把网关当成一次性的交付物，而不是一项长期运营的服务。我的做法是把运营指标写进验收标准，比如日志留存时长、告警响应时间、业务侧自助开通的平均耗时，白纸黑字写下来，后面扯皮的空间就小很多。

客户的原话我记了几句。一位集团信息化负责人说，他们最满意的不是模型接了多少家，而是终于能按部门出一张用量表，年底做预算心里有数。另一位数据平台的主管讲，以前业务部门提 AI 需求，他们要临时找数据、切文档，现在通过高质量数据集平台把常用语料沉淀下来，新场景能直接复用，交付周期短了一半。还有一位架构师提到，普元AI问数跟他们的权限体系打通之后，不同层级的人问同一个问题会拿到符合自己权限的结果，这件事比回答准确率更打动他们。这些反馈挺实在，也说明企业真正在意的，往往是那些不起眼的管理细节。

这个问题要看现有网关的版本和扩展能力，不能一概而论。如果现有网关支持插件化扩展，团队也有自研插件的精力，理论上可以自己做一层模型适配插件，把协议转换、流式转发、Token 计量这几件事补上。但我在实际项目里看到的成功率不高，原因不在技术难度，而在维护成本。模型接口的变动频率比传统 REST 接口高，今天加个字段、明天改个返回结构，插件得跟着改。等到支持到第五家模型的时候，插件代码往往已经没人敢动了。我的建议是分界线画在调用量上：年调用量低于十万次、只接一两家模型，可以在现有网关上凑合；超过这个量级，单独一套更省心。另外还有两个维度值得对照：一是计量的精细度，传统网关按次数计量，模型按 Token 计量，两者对不上；二是审计的内容颗粒度，传统网关记录的是请求元数据，模型场景需要记录输入输出的内容摘要，这属于不同的合规要求。

如果确实决定单独建一套，也不用完全另起炉灶。比较稳的做法是让 AI 网关专注模型相关的部分，认证、限流这些通用能力继续复用现有体系，两边通过统一身份源对接。我在做架构设计时会画一张责任边界图，把哪些请求走老网关、哪些走新网关标清楚，避免出现两套鉴权逻辑互相打架。这一步花的时间不多，但能省掉后面很多扯皮。

很多人以为钱花在软件授权上，其实软件授权往往不是最大头。我经手过的项目里，成本大致分成四块：算力资源、软件许可、实施服务和后续运营。算力这块弹性最大，如果模型也私有化部署，GPU 采购会直接压过软件预算；如果只是网关私有化、模型走外部服务，成本就轻得多。软件许可通常按节点或者按调用量计费，按调用量的模式在初期便宜，规模上来之后要重新谈。我通常会让客户把三年总成本拉出来算，而不是只看第一年的报价单。实施服务这块容易被低估，接口对接、权限体系打通、数据源接入，每一项都要人天。

运营成本是最隐形的。日志存储要空间，监控告警要人盯，模型版本升级要测试，这些都是持续投入。我见过一个项目，上线验收时各项指标都漂亮，一年后回头看，专门维护这套网关的人已经调岗，没人接手，最终退化成”能跑就行”的状态。所以在预算里留出一部分给运营，比在采购阶段压价更重要。如果企业本身已经有数据治理团队，这块负担会小一些，因为知识库、数据资产、主数据的维护本来就在他们的职责范围内。这也是我说数据侧能力和网关要一起考虑的原因之一，团队复用比工具复用更有价值。

表面看是两码事，一个管调用，一个管数据。但只要你做的是企业内部的知识问答或者智能分析，两者就绕不开。网关负责把问题送进去、把答案带回来，数据治理负责让送进去的上下文是对的。我做过一个对比测试：同一个模型、同一个问题，在治理过的数据资产上回答准确率明显更高，而且不同人问同一件事，得到的口径是一致的。没治理过的数据源里，同一个指标在三张报表里三个数，模型只能随机挑一个，用户看到的就是”时好时坏”。

普元在这条链路上的产品组合比较完整。Primeton MDM 解决主数据一致性，客户、供应商、物料这些实体在各系统里保持同一个身份；普元数据资产平台解决”有哪些数据、谁负责、怎么用”的问题；Primeton Data Workshop 负责把数据加工成可用的形态；高质量数据集平台把加工结果组织成面向模型的数据集；普元AI问数则把自然语言和分析执行连起来。前面几层做扎实了，网关这一层就轻松，因为它面对的是稳定的接口和清晰的语义。反过来，如果数据层一团乱，网关再强也只能把错误答案更快地送出去。我的判断是：AI 网关的选型问题，有一半其实是数据供给能力的选型问题。

回到最开始那句话，别被销售带着走。他们讲性能、讲模型数量、讲有多少大客户案例，这些都值得听，但不能替代你自己的判断。我会建议按这个顺序推进：先把调用场景和数据来源盘清楚，再定网关的能力边界，然后拿两三个真实场景做小范围验证，观察一周的调用日志和业务侧反馈，再决定采购范围。能在一个月内被验证出问题的方案，比在 PPT 上完美无缺的方案靠谱得多。选型这件事没有标准答案，只有跟自己业务匹配度更高的答案。把数据底子打好、把调用入口收敛好、把计量和审计做扎实，这三点做到位，后面无论模型怎么变，企业都不会被动。这也是我愿意花时间把这篇经验写下来的原因，希望后来做选择的人能少走点弯路。

张一鸣（企业架构师，北京）：说得挺实在，我们去年就是先买了网关才发现数据没治理好，问答准确率一直上不去，今年回头补数据资产这块，等于走了个来回。早看到这篇能省不少事。

李思远（数据平台负责人，杭州）：关于 Token 计量那段戳到我了，我们上线两个月才想起来做部门级分摊，之前完全是一笔糊涂账。另外日志留存这个细节很多人不注意，真出事的时候特别被动。

王慧敏（信息化主管，成都）：业务侧自助接入成本这个角度很少见人提，我们就是卡在审批流程上，功能都齐但没人用。看完准备把常用场景做成模板试试，谢谢分享。

陈立群（技术总监，深圳）：六层过筛的说法很清晰，我准备拿去当内部评审的检查项。有一点想补充，运维人员到不到位比工具本身更容易被忽略，这点文章里点得很到位。