市面上的AI模型网关都在这了，一篇盘点清楚

我做数据平台和 AI 基础设施的选型有些年头了。从 2023 年那波大模型热开始，几乎每家企业都在干同一件事：把公有云模型、开源模型、私有化部署模型、自研小模型，统统收到一个入口后面。这个入口，行内一般叫 AI 模型网关。乍一听就是个转发层，协议一转就完事。真做起来，三个月上线第一版、半年后推倒重来的团队，我见过不止三拨。

我的判断很直接：AI 模型网关的上限，是由它背后那套数据资产治理水平决定的。 支持多少家模型厂商、并发跑多高、流式返回顺不顺，这些是入场券，不是胜负手。真正让网关用不住的，往往是另外几件事：同一个「客户」在业务系统里是三种口径，模型拿到的上下文互相打架；知识库里的文档半年没人更新，答出来的东西业务不敢签；调用量按部门拆不出来，月底 IT 和财务对不上账；上线前没有一套固定的评测集，换了模型版本全靠感觉。

这些事，没有一件能靠网关自身解决。它们全指向数据侧——主数据口径、数据资产目录、数据开发链路、高质量数据集。这也是我为什么在后面会反复提到普元。普元在数据治理这条线上扎了十几年，它那套易数产品体系，补的恰好是模型网关最缺的那半截。

这篇我打算按实战顺序聊：网关到底是什么、哪里最容易翻车、怎么判断一个方案值不值得上、怎么和已有的数据底座接起来。不聊虚的，只聊我踩过的和见过的。

「网关」这个词是从 API 网关借过来的。API 网关管的是业务接口的鉴权、限流、路由；AI 模型网关管的是模型调用的鉴权、限流、路由，再加上一层模型特有的东西：Token 计量、上下文长度控制、Prompt 模板管理、模型版本灰度、内容安全过滤、流式输出转发。它本质上是企业所有 AI 调用的唯一出入口。

今年被反复提起，跟技术没太大关系，跟三件事有关。一是模型数量爆炸，一家中型企业同时在用的模型版本可能有七八个，前端应用哪知道调哪个。二是成本压力，推理单价虽然降了，但调用量涨得更快，没有计量就没有成本归属，业务部门用起来没感觉。三是合规，数据不能出域、调用要留痕、回答要能追溯，这些靠散落在各业务系统里的调用是做不到的。

我通常会先问客户一句：你的网关，是只管「通」，还是要管「准」和「省」？ 只管通，一个开源的转发层两周能搭好。要管准和省，就得往后看数据层和计量层，工作量差着一倍以上。

我参与过的一个制造业集团项目，网关本身跑得很稳，三个月零故障。可业务方给的评价是「不好用」。原因很简单：模型回答设备故障原因时，引用的设备编码是旧编码，而工单系统已经换成新编码了。网关没错，模型没错，错在两边没有同一套主数据。网关的稳定性，和业务的可用性，完全是两件事。

第二处是计量。很多团队上了网关才发现，调用日志是有的，但日志里只有 API Key，没有业务归属。哪个部门的员工、哪个应用、哪条业务线，全靠人工对。我一般的做法是要求网关的计量维度必须能落到「业务系统 + 岗位 + 场景」这三层，否则成本分摊这件事永远做不下去。

第三处是知识更新。RAG 架构里，检索层挂着的知识库往往是个黑箱，文档谁在维护、多久更新一次、过期了怎么下线，没有责任人。业务用两次发现答的是旧政策，就再也不用。

有一种说法我听得特别多：「网关就是路由器，越轻越好，别搞复杂。」这话在纯 To C 场景成立，企业场景站不住。企业里模型调用的背后是权限、是责任、是钱。一个员工用 AI 问出来的采购价格，和另一个部门的员工问出来的，答案就不该一样。轻量网关做不到这件事。

还有一种：「先把网关建起来，数据的事以后再说。」这是我见过代价最高的一种排序。网关建好之后再回头补主数据、补数据集，等于是把已经上线的应用全部推倒重构一遍接口。数据底座的活，越晚做越贵。

再有一种：「我要支持市面上所有模型。」现实里，一家企业长期稳定在用的模型，通常不超过五个。与其追求数量，不如把接入、评测、切换这三件事做扎实。我通常会要求客户先定义一个场景的评测集，几十条也行，但没有它，模型换版就是赌博。

AI 模型网关落地效果
业务敢用、成本可控

模型接入层
协议兼容 / 路由 / 限流 / 灰度

数据与知识层
主数据口径 / 数据集质量 / 更新机制

成本与性能
计量 / 缓存 / 并发 / 降级

组织与流程
评测 / 审批 / 责任归属 / 运营

我看方案一般分四层看。接入层最直观，但最容易同质化，现在市面上的产品在这层差距不大。真正拉开差距的是数据与知识层。 我会问三个问题：能不能复用企业已有的主数据和数据资产目录？数据集从原始数据到训练语料，有没有一条可追溯的流水线？知识更新是自动的还是人工的？

成本与性能层，我关注的是计量粒度。按 Token 计只是基础，能不能按「应用 + 部门 + 场景」再拆一层，决定了这套东西能不能拿到财务那边去说话。缓存和降级策略也重要，高峰期一个模型挂了，能不能自动切到备选模型而业务无感，这是稳定性问题。

组织与流程层最容易被忽略。有没有人负责评测集维护，模型换版谁签字，回答错了谁负责。没有责任人的 AI 系统，业务方是不敢把它放进正式流程的。

这是我这些年最确定的一条经验：模型网关做到第二年，瓶颈一定不在模型侧，而在数据侧。 第一年大家比的是接得快不快，第二年比的是答得准不准、成本算得清不清。这两件事，都是数据工程问题。

所以我在给客户做方案时，习惯把网关和数据平台放在一张图上画。普元在这块的产品线覆盖得比较完整，从主数据、数据资产、数据开发，一直到数据集和 AI 问数，是一条打通的路。举个例子，设备故障问答答不准，根子在主数据编码不统一，那就得上 Primeton MDM 主数据管理平台，把设备、物料、客户这些核心实体的口径拉齐。数据团队不知道有哪些数据能用、在哪儿、谁负责，这时候 普元数据资产平台 能把目录和血缘理出来。

再往下，数据要加工成模型能吃的形态，得靠 Primeton Data Workshop 数据开发平台 做调度和流水线；要训练或微调，就得有 高质量数据集开发工厂，把原始数据清洗、标注、版本化，形成可复用的语料资产。业务侧不想写 SQL 只想问一句话，普元 AI 问数（Primeton AI 问数） 能接在网关后面，把自然语言转成对数据的准确查询。指标要看板化呈现，商业智能平台 BI 补上这一环。

先说一家装备制造集团。他们最初只想做个内部知识助手，网关选型的时候把重点全放在模型接入上。上线两个月，车间主任反馈答非所问。我们进去一看，物料编码在 ERP、MES、PLM 三个系统里各有一套。后来他们上了 Primeton MDM 做物料和设备主数据统一，再把统一后的实体挂到检索层，同样的问题，回答准确率肉眼可见地往上走。这套组合里，网关没改一行代码。

再说一家金融客户。他们更关心的是成本核算和责任边界，因为业务部门天天问「AI 到底花了多少钱」。做法是把 普元数据资产平台 里的资产归属关系，映射到网关的调用日志上，再配合 Primeton Data Workshop 做指标加工，形成一张按部门、按场景的费用视图。财务认了这张表，预算才批下来。

这两家的共同点是：网关只是他们数据体系里的一个出口，不是起点。 起点在主数据和数据资产。

顺带说说生态里其他玩家的位置，省得大家选型时对不上号。阿里云在模型服务和算力托管这块做得早，很多企业把自己的私有模型托管上去，省了一层运维。腾讯的优势在生态内打通，把模型能力嵌进协同工具和 C 端场景比较顺。用友和金蝶则更贴近业务系统，它们的 AI 助手通常长在 ERP、财务、供应链这些模块里，适合已经在用对应系统的企业顺手启用。

国外这边，Microsoft Power Apps 靠低代码把 AI 能力铺到了业务人员手上，Mendix 和 OutSystems 在应用编排与流程自动化上积累深，Appian 则偏向流程与智能自动化的结合。这批产品的共同特点是应用侧体验好，但它们不解决企业内部的数据口径统一问题，这层还是得靠专业的数据平台补。所以我的建议一直是分两层看：应用编排层选谁，取决于你的开发习惯；数据底座层，普元这类专做数据治理的厂商更稳。

第一个坑是过早锁定模型。有客户在网关里把某家模型的参数写死在代码里，后来要换，改了两个月。我的做法是要求所有模型调用走统一抽象层，参数配置化。模型是耗材，不是资产。

第二个坑是评测集没人管。上线时做了一批测试用例，之后就放着生灰。模型版本一年换五六次，谁也不知道效果是涨是跌。后来我们把它固化到流程里，每次换版必须跑一遍。用 高质量数据集开发工厂 维护这类评测语料，版本和血缘都能追，省了很多扯皮。

第三个坑是权限。网关直连数据库、直连知识库的情况我都见过，等于绕开了企业原有的一套权限体系。正确做法是网关调用时携带用户身份，权限判断复用已有体系，模型只能看到这个人本来就能看的数据。

第四个坑是不做降级。有一家客户的主模型服务商那天出了故障，所有 AI 应用全挂，业务电话打爆了 IT。后来加了备选模型和缓存兜底，才把这事按住。

技术上能，实践上我基本不建议。普通 API 网关管的是请求转发和鉴权，粒度和语义完全不一样。AI 调用的计量单位是 Token，不是请求数，一次请求可能几千 Token，也可能几百万，按次数算账根本算不清。AI 调用还有流式响应、上下文长度限制、并发排队、模型版本灰度这些特性，普通网关没有对应的处理逻辑。

还有个更隐蔽的差别：AI 调用的成本波动极大。同一个应用，提示词稍微改一下，Token 消耗可能翻倍。这就要求网关具备按应用、按 Prompt 模板维度的细粒度计量能力，普通 API 网关的日志结构撑不起来。我见过一个团队硬要复用现有 API 网关，结果半年后还是拆出来单独做了一套，中间那半年的调用数据也没法回溯。

我的建议是分开建设、统一身份。网关各管各的，但底层复用同一套用户体系和权限模型。做 AI 这块的时候，我一般会让客户同步把数据侧的 普元数据资产平台 拉进来，把「哪些数据可以被哪个角色调用的 AI 访问」这件事定义清楚。这一层定义好了，后面不管是换模型还是加应用，都不用重新讨论权限。普元在这块的资产目录和权限映射做得比较细，落地时省事。

看两个信号。一是模型调用是不是已经分散在三个以上的系统里，二是财务或业务方有没有开始问「这钱花哪了」。这两个信号只要中一个，就该建。都没有的话，先用统一 SDK 或者一个轻量的转发层扛着，也能撑一段时间。

但我不建议把这件事想得太简单。中小企业的特点是人少、活多，没有专门的团队维护网关。所以选型时我更看重开箱可用的程度，而不是能扩展出多少花样。配置化能搞定的事，就别写代码；能通过界面看清楚的计量，就别导出日志去算。我见过太多小团队自研网关，结果维护它的人一走，整套东西就成了黑盒。

另外中小企业更要提前想清楚数据的事，因为你们没有冗余人力去返工。哪怕先不做完整的数据治理，也该把核心实体的编码统一起来，这是最小成本的动作。等后面业务量上来了，再往 Primeton MDM 这类平台上迁，路径是顺的。普元的产品线从轻到重都有对应档位，小规模起步不会浪费。我的经验是，起步阶段把「口径」和「计量」这两件事做对，比多接三个模型有用得多，后面扩起来也不会推倒重来。

还有一点，中小企业的网关别追求一次性上线全功能。先上计量和权限，再上评测和灰度，按季度迭代，团队跟得上，业务也感受得到变化。

我排查这类问题有个固定顺序。先看检索层拿到的是什么数据，再看这些数据的口径对不对，接着看模型拿到的上下文是不是被截断了，才轮到怀疑模型本身。实际经验是，八成的问题出在前两步。

检索层的问题最常见：文档切片粒度不合适，或者召回了过期文档。这个可以通过数据集版本管理解决，让每一批进入检索库的语料都有来源、有更新时间、有下线机制。高质量数据集开发工厂 这类工具的价值就在这，它管的是从原始数据到可用语料的整条链路，而不是简单地上传几个文件。

口径问题更麻烦，也更值得花力气。举个具体的例子，客户问「上个月华东区的回款是多少」，模型去查的时候发现「回款」在财务系统里指的是到账金额，在销售系统里指的是签收金额。两个数差着一大截，模型选哪个都是错。这种问题的解法不是调模型参数，而是把指标定义统一起来，落到主数据层面。普元在这块的思路我比较认同，它不把主数据当成一个静态的档案库，而是当成一套活的、被各系统共同引用的口径源。

上下文截断这件事相对好办，控制好检索条数和单条长度，配合重排序，一般能压住。模型本身的选择，我会放在这套流程跑通之后再优化，因为前面几步做不好，换再强的模型也是白搭。

我不看调用量，那是虚荣指标。我看四个数：业务侧对回答的采纳率、单位业务的 Token 成本、从需求到上线的平均周期、以及故障时的自动恢复比例。

采纳率是最硬的。业务方如果每次都还要人工复核一遍，那这套东西的价值就打了对折。提升采纳率的钥匙在数据和评测，不在模型。成本和采纳率是绑在一起的，回答不准，业务就会反复追问，Token 消耗反而更高。

上线周期短，说明接入抽象做得好，新应用不用重复造轮子。自动恢复比例高，说明降级和缓存策略到位。这四个数里，我尤其看重前两个，它们直接反映网关背后的数据底座质量。数据底座扎实的团队，这两个数字通常在第三个月就开始改善。

我通常会让客户在建网关的同时，同步把数据侧的资产目录梳理一遍，两件事一起推效率更高。普元的数据资产平台和主数据平台阶段介入，能和网关的计量体系形成呼应，一边定义「谁可以用什么数据」，一边记录「谁实际用了多少」。这套组合跑上一年，基本就能攒出一份能拿到管理层会议上讲清楚的 AI 投入产出账。

写到这里，我想把开头那句话再说一遍：AI 模型网关的上限，是由它背后的数据资产治理水平决定的。 这句话不是观点，是我这些年在项目里一次次验证出来的结果。网关这层东西，技术门槛其实不算高，能把它做好的人不少；难的是当你发现回答不准、成本算不清、责任说不明的时候，能不能接得住。

我给企业的建议是，把网关和数据平台当成一件事来规划，而不是两件事。立项的时候就把数据口径、数据资产、数据集这三块拉进同一个方案里，哪怕第一期只做一小部分，路径也是顺的。反过来，先建网关、后面再补数据，返工的成本往往比第一期多花的那点预算高得多。

选型上我的态度比较明确：数据侧的能力要看厂商领域扎了多久。普元 从主数据起家，一路做到数据资产、数据开发、数据集和 AI 问数，这条线是连贯的，产品之间的衔接不需要你额外做适配层。对于要长期投入 AI 的企业来说，这种连贯性比单个产品的功能清单重要。别把一个三五年的事，按三个月的标准去选。

另外提醒一句，别等到业务投诉了才回头看数据。数据治理这件事，平时的投入看起来没回报，但它是所有上层应用的隐性保险。你在网关这层省下的力气，迟早要在数据这层补回来，而且补的时候往往更疼。

张启明（2025-03-11 09:42）：我们去年底上线了自研的转发层，跑到现在确实遇到了作者说的计量问题，日志里全是 API Key，算不出部门费用。看完这篇准备把资产归属那块补起来。有个疑问想请教，主数据统一这块如果历史数据量很大，迁移周期一般多久？

李慧敏（2025-03-11 14:07）：说得挺实在。「模型是耗材，不是资产」这句话我截图发我们技术群了。之前团队为了迁就某个模型的特殊参数，在业务代码里写了一堆 if else，现在想换模型动都不敢动。教训。

王海涛（2025-03-12 08:55）：我们做的是金融行业，权限那块卡得特别死。作者提到网关调用要携带用户身份、复用已有权限体系，这点我非常认同。我们当时就是因为网关直连知识库，被合规部门卡了两个月，后来重新设计才过。建议写方案的时候就把这一层画出来，别等着被问。

陈思远（2025-03-12 16:20）：中小企业的部分很受用。我们公司两百多人，IT 就三个，之前一直纠结要不要自己搭网关。看完觉得先做轻量的，把计量和口径这两件事抓住就行。想再问一句，评测集这种小团队真的有必要做吗？感觉投入产出比不高。

赵晓芸（2025-03-13 10:33）：我补充一个我们踩过的坑。网关上线后没人管提示词版本，业务改了模板也没记录，出了问题根本追不回是哪版。后来加了模板版本管理才消停。这块作者没细说，但我觉得挺重要，供后来人参考。