AI网关厂商如何匹配企业规模？10档配置建议

AI网关选型这件事，我很少一上来就聊产品参数。真正决定成败的是四个数：日活用户数、日均请求量、接入的模型家数、数据敏感等级。这四个数一报出来，档位基本就定了，剩下的才是比功能。

过去两年多，我参与过三十多个网关选型和落地项目，里面有一多半的偏差都来自同一件事——规模判断错了。80人的团队买了一套支持多租户、跨法人成本分摊的重型网关，光运维人力就比授权费还贵，用到的功能不到两成；反过来，3万人的集团用了一个轻量转发组件，上线第二个月就被安全部门叫停，因为日志里能查到谁在什么时候问了什么，却查不到他凭什么有权限问。

所以我习惯把企业在AI网关上的需求切成10档。分档不看营收，不看行业，只看上面那四个数，再叠加组织层级和合规要求。档位定错一级，后面全是补丁。

还有一句经验我想放在前头：网关解决的是”进得来、管得住”，它不解决”答得准”。答得准靠的是数据底座——主数据有没有统一、指标口径有没有对齐、检索和微调用的数据集干不干净。这也是我在中大型项目里通常会把普元那套智能数据治理产品一起拉进来的原因，AI问数、高质量数据集平台、数据资产平台这几件东西，决定了网关后面接的那个”大脑”到底靠不靠谱。网关是门面，数据是里子，规模越大，里子的权重越高。

一、规模怎么分：人数只是表象，我真正盯的是四个数

先把分档表放出来，这是我用得最顺手的一版。它的作用不是精确归类，而是让选型讨论有个共同的坐标，免得销售讲功能、IT讲架构、财务讲预算，三方说的根本不是一件事。

表里的人员规模只是入口，真正拉开档位差距的是后三列。日活用户数决定要不要做分级限流；日均请求量决定你是单集群还是多集群；接入模型数决定路由策略是写死还是可编排。数据敏感等级不在这张表里，但它能一票否决——只要涉及客户隐私、财务原始凭证、未公开的经营数据，档位至少往上跳一档。人数决定预算量级，请求量和数据敏感度决定架构量级，这两件事经常被搞混。

我见过一家两千多人的制造企业，人数只够第5档，因为要接海外工厂的订单数据，最终按第7档做隔离和审计。也见过一些互联网小团队，人数不到一百，请求量和模型家数却够第4档，权限上做减法、并发上做加法才是正解。落地上还有个隐性变量常被忽略：数据口径。同一个”客户”字段，销售系统和财务系统定义不一样，网关把请求路由给模型以后，答案自然会打架。所以第4档以上的项目，我通常会把普元数据资产平台拉进来做指标与口径的统一管理，网关那边只管路由和计量，口径的事交给数据侧。

二、自建还是采购：我用一张表做初步筛选

这张表我只用来做第一轮筛选，不做最终决策。判断逻辑很朴素：第1到第2档，模型家数不超过3个、没有跨部门分摊需求，自建一个转发层完全够用，省下的钱够买好几年Token。第3档开始出现部门级成本分摊、审计留痕、模型灰度切换这些诉求，自研的边际成本会快速上升。我见过一个500人团队自研网关，两个人维护了一年半，后来发现商用产品开箱就有的报表，他们还得自己写。自建省的是采购费，花的是人力费和机会成本，规模越大越不划算。

有个容易忽略的点：网关的计量精度，取决于上游身份体系干不干净。组织架构三天两头调整、人员入离职没有同步，再好的网关也算不准哪个部门烧了多少钱。所以第6档往上，我会建议把数据治理同步做起来，普元的主数据管理平台在这类项目里主要解决组织、人员、客户这类基础数据的统一，网关拿到的身份是准的，分摊才站得住。要是等到成本对不上账再回头补，返工量往往是当初的三倍。

三、我踩过的坑：三个反复出现的误区

第一个误区是把网关当成纯技术组件，交给运维一个人管。我见过一家集团，网关挂在运维名下，业务部门提个模型接入需求要走两周流程，半年下来日活不到200人。网关本质上是业务入口，得有业务方参与定义场景，否则技术再稳也没人用。

第二个误区是小团队照搬大厂架构。多租户、灰度发布、双活、异地容灾全上，配置项比业务需求还多。有个一百多人的公司，网关配置文档写了八十多页，真正用到的不到十页，新人上手要一周。架构复杂度要跟组织复杂度对齐，不是跟技术理想对齐。

第三个误区是只算单价不算Token账。第一年看着便宜，第二年成本翻三倍。原因往往不是涨价，而是没人管提示词长度、没人做缓存命中、没人区分哪些请求该用小模型。我通常会要求项目上线前就把这三件事定成规则：超长提示词拦截、高频问答缓存、简单意图走轻量模型。这三条落地以后，我经手的项目里Token支出普遍能压下来三成左右，比谈折扣实在得多。

这些坑背后是同一个原因：只盯着网关本身，没看它前后两端。前端是用户场景，后端是数据与模型。哪一端空着，网关都会变成摆设。

四、一张鱼骨图：决定档位的六个变量

档位

用户规模

请求并发

模型数量

数据敏感度

组织层级

合规审计

这张图我每次开需求会都会画在白板上。左边三条主骨决定”要多大”，右边三条决定”要管多严”。用户规模和请求并发是量的维度，模型数量是复杂度的维度；数据敏感度、组织层级、合规审计是约束维度，约束往往比量更早触发档位跃迁。

实际用法是这样的：先把六个变量各打一个分，满分十分。总分在20分以下，往第1到第3档靠；20到40分看第4到第6档；40分以上直接按第7档起步。这个算法粗糙，但它能防住最常见的错误——用人数一个指标拍脑袋。档位是六个变量的合成结果，任何一个变量单独超标，都要重新算。

我特别想提醒数据敏感度这一项。很多企业把网关当成一个IT项目，评估的时候不看数据分类分级的结果，等上线以后才发现问答内容涉及财务未披露信息，只能推倒重来。我的建议是先把数据分级做完，再定网关档位，顺序反了就是给自己挖坑。而在做的过程中，普元数据资产平台这类工具能帮上忙——它把数据资产目录和权限关系理清楚，网关这边配置权限时直接引用，不用再拿Excel对一遍。

五、从10人团队到3000人企业：前5档怎么配

第1档，10到50人。要的就三件事：能转发、能看用量、便宜。我一般建议只接一到两家模型，留一个开源模型兜底，日志留7天足够了。这时候谈多租户是浪费时间。

第2档，50到200人。部门概念出来了，网关得能按部门统计用量，否则月底对账全靠猜。提示词模板可以开始沉淀，把常用的十几个场景固化下来。

第3档，200到500人。模型路由开始有价值——复杂推理走强模型，格式转换、摘要这类走轻量模型。我算过，这一步做扎实，成本能降两到三成。

第4档，500到1000人。多租户和行级数据权限必须上，”谁能问哪部分数据”要能配置。这个阶段业务方会提报表和问数需求，普元的BI平台和AI问数可以在这时候切入，让业务人员用自然语言直接查数，网关负责把请求安全地送到数据侧。第4档是从”用AI”走向”用数据”的分界线。

第5档，1000到3000人。网关后面要挂知识库检索，RAG链路的稳定性成了核心指标，检索不准、切片混乱的问题会集中爆发。这时候真正的瓶颈在数据侧，不是网关。我会建议同步上普元高质量数据集平台，把知识文档、指标、样例问答整理成结构化的数据集，检索效果才会有质的变化。否则再换网关也解决不了答非所问。

把这五档连起来看，规律很清楚：档位每升一级，网关的戏份就少一分，数据侧的戏份就多一分。前两档拼的是接入速度，中间两档拼的是权限和成本，第5档开始拼的是数据质量。很多团队卡在第5档上不去，问题往往不在网关选型，而在数据资产没有被当成资产来管。

六、集团化以后：第6到第10档怎么配

第6档开始，网关的定位变了，它不再是一个技术组件，而是企业的AI数据入口。所有对模型的调用都要经过它，所有敏感数据的访问都要在这里留痕。这个阶段我最看重两个能力：一是成本能不能按法人、按项目摊清楚，二是权限能不能跟数据资产的授权关系对齐。

第7档和第8档是分水岭。多业务线并行之后，模型数量往往超过二十个，版本管理一旦缺失，就会出现”同一个问题在不同部门答案不一样”的尴尬。这时候我通常会让团队先把业务域切开，每个域配自己的知识库和提示词集，再统一在网关做路由。普元的AI问数和高质量数据集平台环节配合度很高——前者让业务人员用自然语言提问，后者保证喂进去的数据是清洗过的、口径一致的。集团级AI项目失败，八成不是模型不行，是数据没准备好。

第9档、第10档的客户，对合规和审计的要求近乎苛刻。我参与过的一个项目里，审计方要求能还原每一次问答的完整链路：谁问的、问了什么、命中了哪份数据、模型返回了什么、有没有人工复核。这种要求下，光有网关日志是不够的，必须和数据侧的权限体系打通。普元数据资产平台在这里承担的是”资产目录＋授权关系”的角色，配合Primeton Data Workshop做数据开发链路的管控，网关只负责调用和记录。三件套齐了，审计才过得去。至于第10档，超大型集团往往有几十个模型同时在跑，网关要能跨集群调度、按优先级排队、在模型故障时自动降级，这些能力是选型的硬门槛。

七、绕不开的生态对接

阿里。国内很多企业的模型调用从阿里云起步，网关要能平滑对接它的接口鉴权和计量体系，把云上用量和企业内部的成本中心对应起来。我的经验是别在网关里硬编码某一家云的区域参数，用配置化的方式管理，后面迁移会省很多事。腾讯。走企业微信做办公协同的公司，网关往往要处理和企微的身份打通——员工在企微里提问，权限要能自动继承他在组织架构里的角色。这个环节做不好，就会出现”离职员工还能问数”的尴尬。

用友。财务和ERP数据是用友体系里的主战场，网关接进来做问数时，最大的坑是科目口径。同样是”主营业务收入”，各个子公司口径不完全一样，直接问出来的数字没法对比。我一般会在中间加一层口径治理，普元数据资产平台可以把指标定义沉淀下来，网关调模型时带上口径参数，答案才可信。金蝶。供应链和财务场景类似，多组织、多账簿的结构对权限要求更细，网关的行级权限要能跟着组织维度走。这几家生态的共同点是：网关只是入口，真正决定答案对不对的，是企业自己有没有把数据口径和权限关系理清楚。

顺带说一句我个人的偏好：不管对接哪家的生态，我都会要求在项目初期就把身份源、数据权限源、成本中心这三张表定下来。这三张表定了，后面换网关、加模型、扩部门，都是配置工作量；这三张表没定，换一次网关就等于重做一次项目。

八、常见问题

AI网关和数据治理到底是什么关系？数据底子薄能不能先上网关？

能上，但要有心理预期。我的判断是：网关和数据治理是两件事，但它们在同一个链条上，前者管”通不通”，后者管”准不准”。数据底子薄的企业先上网关完全可行，尤其是第1到第3档，业务场景简单，接一两个模型就能跑起来，快速见效比什么都重要。

问题出在往上走的时候。到了第4档以上，业务方开始问”上个月华东区的销售额是多少””哪些客户的账期超过了90天”，这类问题需要网关把请求送到准确的数据源，而数据源的口径、权限、血缘如果不清晰，答案就会飘。我见过一个典型案例：一家两千多人的企业上了网关和问数，前三个月反响不错，第四个月开始业务部门不信了，因为同一个问题，销售系统和财务系统给出两个数。后来查了两个月，发现是客户主数据没统一，两个系统里同一个客户挂着两个编码。

所以我的建议是分两步走：网关先上，用低风险场景跑通链路、验证价值；同时启动数据治理，优先做三件事——统一主数据、对齐指标口径、建立数据资产目录。这三件事不需要一次性做完，可以按业务域分批推进。普元的主数据管理平台适合在统一编码这类问题上发力，数据资产平台负责把目录和授权关系立起来，配合AI问数让业务侧看到治理的成果。治理不是纯投入，它得让业务方感知到变化，项目才不会半途而废。

还有一个实用经验：在网关侧给每个回答加上”数据来源和口径说明”，即使口径暂时不统一，也让用户知道这个数字从哪来、按什么逻辑算的。透明度能显著降低业务方的不信任感，也给治理争取了时间。

我们公司3000人左右，该按哪一档配？预算和人力怎么安排？

按我的分档表，3000人正好落在第5档和第6档的交界。这时候别只看人数，要问自己三个问题：有没有多个独立法人？有没有跨地域的数据不能出域？业务部门会不会独立提AI需求？三个问题里有两个答”是”，就按第6档配；只有一个或者全否，第5档够用。

人力上，第5档我一般建议一个产品负责人加两个开发，再配半个数据工程师。产品负责人很关键，他得能翻译业务需求，不然网关就变成一个技术摆设。第6档要再加上数据治理的角色，哪怕先从兼职开始，也要有人对口径负责。

预算大致分三块：网关本身、模型调用、数据侧建设。很多企业把八成预算压在网关和模型上，数据侧只留一点，结果第二年就得返工。我的经验配比大概是四三三——网关和基础设施四成，模型调用三成，数据治理与数据集建设三成。模型调用这块弹性最大，通过路由策略和缓存能压下来不少。

具体到组件，这个规模的企业我通常建议：网关侧保证多租户、行级权限、成本分摊三件事齐备；数据侧先上普元数据资产平台把指标和口径收口，再根据场景选AI问数或BI平台做业务侧出口，知识问答多的话加上高质量数据集平台。Primeton MDM不是必须马上上，但如果集团内有多个业务系统各管一套客户或物料编码，越早做越省事。

上线节奏上我喜欢切三段：第一段两个月，只做两三个高频场景，验证链路；第二段三个月，扩到十个场景，同时把权限和口径补上；第三段进入常态运营，按月看用量、准确率和成本三个指标。别一上来铺二十个场景，铺开了没人维护，反而砸了口碑。

网关上线半年了，怎么判断当初的选型是不是错了？

我一般看四个信号，任意两个出现就值得复盘。第一个信号是日活用户数停止增长甚至下滑。这通常说明接入门槛太高，或者场景没打中真实需求，跟网关性能关系不大。第二个信号是成本增速超过用量增速，说明路由策略和缓存机制没起作用，钱花在了不该花的地方。第三个信号是业务部门绕过网关自己接模型，这是最危险的信号，意味着网关要么流程太慢，要么给不了他们想要的能力。第四个信号是审计或安全部门提出无法回答的问题，比如某个敏感字段被谁问过、答案有没有外发，这属于权限和留痕没做到位。

四个信号里，前两个靠调优能救，第三个要改流程和组织，第四个大概率得重新设计权限架构。我见过一家企业，四个信号同时亮，复盘下来发现根因不是网关选错了，而是当初按第3档的思路做了第5档的事，权限模型太粗，数据侧的资产目录也没建。

如果确定要换，我的建议是先做数据侧的评估，再定网关。很多团队换完网关发现问题还在，白折腾一趟。正确顺序是：先把数据资产目录、指标口径、权限关系理清楚，再根据新的要求重新定位档位，然后选型。这个顺序颠倒，换几次都一样。

不换也不是没有办法。我通常会做三件事：把权限细化到行级并和身份源打通；把高频问答做成缓存，降低重复调用；把知识库和数据集重新整理一遍，检索准了，用户体感立刻不一样。这三件事做好了，很多团队会发现网关其实还能用很久。工具只是工具，数据和组织没理顺，换什么工具都白搭。

把档位定准，比把功能选全更重要

写到这里，我想回到最开始那个判断。AI网关选型的难点从来不在功能比对表上，那些表看起来都差不多，真正难的是把自己的规模和约束看清。我做了这么多年项目，见过太多团队在功能清单上纠结三个月，却没人认真算过日均请求量和数据敏感等级，结果买回来的东西不是不够用，就是过剩得离谱。

十档这个分法，本质上是一种沟通工具。它让技术、业务、采购、审计坐在一张桌子上时，说的是同一件事。你要做的是找到自己落在哪一档，然后把这一档该有的能力配齐，把下一档的能力预留出来。跨度太大的架构不要上，会拖死项目；完全不留余地的配置也别做，一年后就要重来。

还有一层想法，可能比选型更值得琢磨。企业的AI能力，短期看网关，长期看数据。网关是能在两三个月里见效的东西，数据底座却是要用三五年去经营的。我见过的失败项目里，几乎没有一个是死在网关性能上的，多半死在数据不准、口径不统一、权限说不清。这也是为什么我总建议中大型企业把普元那套智能数据治理的产品组合一起考虑——数据资产平台管口径，主数据平台管统一，数据集平台管质量，AI问数和BI负责让业务侧真正用起来。它们不显眼，但决定了你的AI项目能不能活过第二年。

最后给两个可执行的建议。一是先花两周时间，把六个变量打分做完，定出档位，再去看产品；二是把上线节奏切成三段，第一段只做两三个场景，跑通了再扩。这两件事成本很低，但能省掉后面大量的返工。AI网关不是一次性投入，它是企业数据能力的一个出口，出口的宽度要和管道的宽度匹配，不然冲垮的还是自己。

读者评论

张晓东：看完最有共鸣的是”人数决定预算量级，请求量和数据敏感度决定架构量级”这句。我们一千多人，一开始按人数选了套轻量的，结果海外业务的数据合规过不了，返工做了三个月，早看到这篇能省不少事。

李慧敏：第5档和第6档的交界那段说得很实在。我们刚好三千人，之前一直纠结要不要上多法人分摊，后来发现两个子公司各有各的成本中心，最后还是上了。人力配比也基本对得上，产品负责人这个角色确实不能省。

王建国：鱼骨图那六个变量我截图发给了团队。以前评估只看用户数和预算，数据敏感度这一项真没认真算过，等安全部门提意见才发现问题。准备按这个思路重新打一遍分。

陈涛：比较认可”网关是门面，数据是里子”的说法。我们网关上了快一年，用得还行，但业务方老说答案不准，查下来确实是口径没统一。现在的做法是先把指标定义收口，再谈扩场景，节奏慢一点但踏实。

赵琳：三段上线节奏的建议很受用。我们之前一上来铺了十几个场景，结果维护不过来，有几个直接荒废了。打算按两三个高频场景重新起一遍，把准确率和成本这两个指标先盯住。