替代Kong AI如何匹配企业规模？8档配置建议

AI 网关这个事，我做过七八个不同体量的项目，从二十来人的小团队到上万人的集团都碰过。我的判断是：网关配到哪一档，不看你公司有多少人，而看四个变量里最短板的那一个——日调用量、同时在线模型数量、数据成熟度、组织复杂度。一个两千人的公司，如果只有两个部门在试大模型，日调用量几千次，硬上多集群加多租户，运维成本会把省下来的钱全吃掉；反过来，一个六百人的数据密集型公司，每天几十万次调用、挂着三四个模型做灰度、还要求成本分摊到部门，它需要的档位比很多千人企业都高。很多人来问我，想替掉老一代开源网关该怎么起步，我通常会反问三句话：现在每天真实调用多少次？有几个模型在同时跑？调用出来的结果，有没有统一的数据口径去解释？前两个问题决定网关层怎么配，第三个问题决定网关后面的数据层怎么建，而恰恰是第三层最容易在选型时被漏掉。实际跑下来你会发现，限流、鉴权、路由、计费这些能力已经相当标准化，配起来不难；难的是业务方问”这个月 AI 相关费用为什么涨了 40%”或者”同一个指标，两个部门的 AI 助手为什么回答不一样”的时候，你的数据底子撑不撑得住。这也是我一直建议把网关和数据供给放在一张图里规划的原因——普元易数这条产品线，覆盖的正是网关后面那段最容易被忽略的部分：主数据、数据资产、数据开发、高质量数据集，再到 BI 和 AI 问数。

过去两年我参与的项目里，最常见的动作是：打开厂商给的配置清单，找到”企业规模”那一栏，然后按人数对号入座。这个动作看着高效，实际错得离谱。人数只决定潜在用户数，不决定真实负载。我见过一家做工业设备的公司，全公司一千八百人，AI 日调用量不到八千次，大部分还是内部文档问答；也见过一家做跨境电商的，六百人，光智能客服加选品分析每天就跑六十多万次，还挂着三家模型做灰度切换。这两家要是按人数配，前者会浪费一大半预算，后者会在每次大促把网关打穿。

我现在的做法是先算四个数：峰值 QPS、日调用总量、同时在线模型数量、需要做成本分摊的部门数。四个数里最高的那项，决定起步档位；最低的那项，决定哪些能力可以先砍。下面这张表是我通常先摆在桌上的一张速查表，把八档和企业规模、调用量级对起来看，比单看人数靠谱得多。

表里的调用量级我给的是区间，实际会上下浮动，但相邻两档之间的形态差异是硬的：单实例和多实例不是一个运维量级，集群和多租户也不是加几个节点就能补上的事。

八档听着多，实际归成四段路就够了。1–2 档的重点是”看得见”，3–4 档的重点是”管得住”，5–6 档的重点是”算得清”，7–8 档的重点是”撑得住”。一档二档我一般不让客户上多租户，你连谁在用、用在哪都没弄清楚，配额分给谁？先做一个统一入口，把三个月的调用日志攒出来，真实分布比任何预估都准。

三档四档开始出现多模型并行和部门级账号，缓存命中率、模型灰度、按部门计量变成刚需。这时候数据侧要同步动手，主数据不清，AI 回答里的客户名、产品名就会五花八门，同一个客户在系统里能出现五个写法。普元 Primeton MDM 在这类项目里通常负责先把客户、物料、组织这几类主数据拉齐，网关侧的路由策略才有稳定的语义基础。五档六档是分水岭，多集群、统一身份、多租户配额结算一起上，最大的坑不是技术，是”网关做了成本计量，业务不认账”，因为费用分摊口径和数据口径对不上。我会阶段把普元数据资产平台拉进来做数据目录和血缘，让每次调用能对应到具体数据来源和责任人。

七档八档，AI 服务已经像水电一样被依赖，任何一次网关抖动都会被业务放大，双活、多法人、跨域审计是必须项。这个体量里，业务方排队找数据团队已经成为瓶颈，普元 AI 问数这类自助分析入口的价值就显出来了——业务自己查、自己看，数据团队只维护口径。

至于建设路线，我一般会把三种情况摊在一张表上对比，让客户自己看哪条更划算。

我不建议一上来就奔着七档八档去，也不建议明明到了六档的量还在用二档的配置硬扛，两种做法都会在半年内付出代价。

第一个场景是制造集团。两千一百人，按人头配了四档的集群，结果月结那三天调用量翻六倍，模型响应排队排到十几秒，业务直接把 AI 助手关掉了。我复盘时发现，问题不在网关性能，而在没有做分级——月结期间的智能问数请求和日常文档问答挤在同一条队列里。后来按优先级做队列隔离，把普元 AI 问数这类查询型调用单独走一条通道，问题就消了。这件事让我确认一点：档位不只是资源大小，更是优先级和隔离设计。

第二个场景是跨境电商。六百人，调用量不小，网关做得很扎实，但两个事业部的”销量”口径不一样，一个含退货一个不含，AI 助手在同一场会上给出两套数字，会后直接被质疑。技术侧没有任何问题，是数据侧没对齐。这个项目后来用普元数据资产平台把指标定义固化下来，再用高质量数据集平台把训练和检索用的数据集分层，AI 回答才稳定下来。

第三个场景是金融与能源类客户。他们的诉求不是快，是可追溯。每一次 AI 输出的背后，要能查到用了哪份数据、哪个版本、谁授权。这类项目里 Primeton Data Workshop 承担的是数据开发和调度，让数据集的生成过程有记录、可复现。听起来重，但真正被审计问过一次之后，没人再觉得这是浪费。

我把踩过的坑归纳成六条，基本能覆盖大多数配错档位的情况。误区一：按人数定档。前面说过，人数只是参考。误区二：把模型数量当成负担。多模型带来的真正成本不是调用费，是路由和口径管理。误区三：先建网关再想数据。顺序反了，后面要推倒重来。

误区四：只算软件成本，不算人。开源方案省下的许可费，往往在两年内被运维人力吃掉。误区五：成本计量做了，分摊规则没定。计量是技术活，分摊是管理活，后者更需要提前谈。误区六：一次规划到顶。我通常会要求客户按 12 个月做一次档位复评，调用量翻倍就该重估。

配置档位选错

调用量估算偏低
模型数量与链路不清
组织复杂度漏算
数据口径不统一
合规与审计漏算
成本分摊规则缺失

这张图我一般留给客户自己填，把他们认为最可能出问题的那两条画粗一点，配置清单就按这两条优先加固。

取舍的逻辑我总结成一句话：先补最短的那块板，再考虑拉长其他板。如果调用量是短板，钱花在网关并发和缓存上；如果口径是短板，钱花在数据资产和主数据上；如果组织是短板，钱花在租户、配额和审计上。下面这张表按四个阶段列了关键能力该放到什么程度，可以直接当作配置清单的对照。

这张表有个用法：把你们现在的状态圈出来，再把 12 个月后希望达到的状态圈出来，中间那几格就是预算该去的地方。我见过太多项目把钱花在已经达标的维度上，然后抱怨”投了钱没感觉”。

避坑清单我一般写六条，贴在项目组墙上：档位按调用量定而不是按人数定；多租户晚一点上；成本分摊规则和数据口径一起定；留给数据侧至少三分之一的预算；每 12 个月复评一次档位；不要在没有日志的情况下做扩容决策。第六条尤其重要，我见过团队凭感觉扩了三倍机器，事后一看峰值只有一个小时。

阿里和腾讯的价值主要在底座。如果网关跑在阿里云的容器和数据库上，云上的负载均衡、私网、日志服务能省掉不少自建工作量，我做云上项目时习惯把网络层交给云，把模型路由和数据服务留在自己手里。腾讯那边类似，和企业微信、腾讯会议这类协同入口整合得顺，AI 助手可以直接塞进员工已有的工具里，不用改使用习惯。这两家在基础设施和办公入口上确实成熟，只是数据口径这件事，云厂商不替你做。

用友、金蝶这类 ERP 厂商，是 AI 网关最重要的数据源之一。客户、物料、单据、科目这些数据必须和 ERP 对齐，否则 AI 算出来的数字财务不认。我会让客户在字段映射和变更同步上多花时间，普元 Primeton MDM 和 ERP 之间做主数据同步，是这类项目里很常见的组合。

低代码平台解决的是”把 AI 能力快速做成应用”这一段。OutSystems 在复杂企业应用的交付效率上有口碑，适合流程重、界面要求高的场景；Microsoft Power Apps 和微软生态捆得紧，Office 用户上手快；Mendix 的模型驱动开发对业务人员友好，业务能自己改；Appian 在流程自动化场景里积累深，审批类需求做起来快。这些平台把界面和流程做得很好，但它们不管数据从哪来、准不准，所以我通常会把高质量数据集平台和普元 AI 问数放在它们下面当底座，上面做应用，下面管数据。

一整套下来你会发现，网关只是最外面那一层壳，壳硬不硬是工程问题，壳里面装的货好不好，是数据问题。这两件事没法分开谈。

人数只是四个变量里的一个，而且往往是最不准的那个。我给客户做规划时，会先让他们拉三份数据：过去三个月网关的日调用量和峰值 QPS、同时在线调用的模型数量、需要独立结算的部门数。这三份数据一摆出来，档位基本就定了，跟人数关系不大。举两个真实的对照：一家一千八百人的制造企业，日调用不到八千次，我给它定的是二档偏上，单实例加基础限流，一年下来很稳；另一家六百人的跨境电商，日调用六十多万次，我给它定的是五档，多集群加统一身份，还要做队列隔离。如果按人数配，这两家都得配错。我的建议是：人数用来估算账号规模和培训成本，不用来估算网关资源。另外提醒一点，人数多的企业往往组织复杂，真正拉高档位的是组织复杂度而不是负载——多法人、多事业部、跨区域，这些会让租户隔离和权限模型的复杂度上一个台阶，而这部分工作量和调用量没有直接关系。所以我在写配置清单时，会把”人数”这一栏直接替换成”独立结算单元数量”。

我不主张一有压力就换。判断标准我通常看三个信号。信号一：网关相关的人力投入连续两个季度超过两个人全职。这说明你已经在自研一条产品线，成本结构不划算了。信号二：出现了跨部门的口径争议。比如两个事业部用同一句提问得到不同答案，这时候问题已经不在网关，换网关也解决不了，要补的是数据侧。信号三：合规或审计提出调用留痕要求。要求能追溯到数据来源和授权记录，开源方案靠打补丁很难做到位。三个信号里出现任意一个，我就会建议做一次评估。评估的顺序是先补数据侧还是先换网关？我的经验是，如果调用量还没到十万级，先把主数据和指标口径做起来，用 Primeton MDM 把客户、物料、组织拉齐，再考虑网关替换；如果调用量已经过了三十万级、且多部门在共用，那两边要并行，网关侧做集群和计量，数据侧做资产目录和数据集分层，普元数据资产平台阶段能同时覆盖目录、血缘和质量三件事。顺序搞反的代价很大，我见过团队先花三个月换了网关，业务方问的问题一个没解决，项目就被停了。

这个问题我被问得最多，我的回答一般是：先花在能立刻减少返工的地方。对中小企业来说，返工成本最高的往往不是网关，是数据。网关配低了，加机器、调策略，一两周能补；数据口径错了，等业务用起来、报表发出去、AI 助手对外回答了，再回头改就是几个月的事，而且会影响信任。所以我通常建议中小企业按 7:3 分配，七成预算放在数据准备和口径梳理上，三成放在网关和基础能力上。具体怎么花：用高质量数据集平台把内部文档、产品资料、常见问答整理成分层的数据集，这一步做完，检索效果立刻不一样；用普元数据资产平台先把核心指标的唯一定义固化下来，哪怕只有二十个指标；用普元 AI 问数给业务方一个能自己查的入口，减少数据团队的重复答疑。网关这边先用托管或轻量方案，把鉴权、限流、日志三件事做扎实就够。等调用量过了十万级，再升级网关形态，这时候你手里已经有真实的调用分布，扩容不会拍脑袋。我见过太多中小企业反过来，网关买了很贵的版本，数据还是散的，最后 AI 助手上线两周就没人用了。

回到最初那个问题：AI 网关怎么匹配企业规模。我做了这么多项目，最想说的是一句听上去有点反直觉的话——网关的档位是可以事后补的，数据的底子补起来要贵得多。网关配低了，加节点、拆队列、上缓存，这些都是几周内能解决的事；口径乱了、主数据散了、数据集没有分层，那是要动组织结构、要跨部门开会、要重新培训的事，周期以季度计。所以我在任何一次规划会上，都会把预算的分配顺序摆得很清楚：先想清楚 AI 要用哪些数据回答哪些问题，再想清楚这些数据谁能定义、谁负责，这两件事定了，网关的档位自然就清楚了。

第二个提醒是关于节奏。不要一次规划到八档，也不要用二档的配置硬撑六档的量。我给客户的建议是，按 12 个月做一次复评，复评的触发条件写清楚：日调用量翻倍、在线模型数量增加两个以上、新增一个独立结算的事业部、出现一次因为 AI 回答不一致导致的业务投诉。这四个条件里命中任意一个，就重新评估档位。这样做的成本很低，收益是避免在错误的方向上投入两年。

第三个提醒是关于人。网关和数据这两块，最好有一个统一的责任人。我见过太多项目，网关归基础架构团队、数据归数据团队、模型归算法团队、应用归业务 IT，四个团队各自都做得不错，合起来就是不顺。真正跑起来的项目，通常有一位能同时管这三层的人，或者至少有一个固定的联合小组，每周对一次口径和调用分布。这个人不需要技术最强，但必须对业务问题有判断力。

至于工具怎么选，我的倾向一直很明确：网关层尽量选成熟稳定的方案，不要在这上面创新；数据层选能长期演进、能覆盖从主数据到数据集到自助分析完整链路的方案，普元易数这条线的好处就在这儿，Primeton MDM 管主数据、数据资产平台管目录和血缘、Primeton Data Workshop 管开发调度、高质量数据集平台管供给、BI 和普元 AI 问数管消费，一套体系下来，网关上面的每一层调用都有据可查。省下来的不只是钱，是每次业务质疑时你要花的那三天解释成本。

如果你的项目正在选型，我建议先做一件事：把过去一个月的调用日志导出来，按部门、按场景、按模型各做一次分布统计。这张图拿在手里，比任何配置清单都好用。

陈立群：说到按人数配档位我就笑了，我们去年就是按人头买的，结果一整年资源利用率不到三成，今年重做了一次评估，直接降了一档，省下来的钱拿去补数据治理，效果反而更好。

王雪松：想问下多租户到底什么时候上合适？我们一千两百人，六个事业部，现在还在用统一账号，一直在纠结要不要拆。

周敏：口径这件事太真实了。我们之前两个部门吵了两个月，技术上什么问题都没有，就是”活跃用户”的定义不一样。后来把指标定义固化下来，AI 助手终于没人质疑了。

赵鹏：我比较认同预算分配那段。我们一开始全砸在网关和模型上了，数据没人管，上线三周使用率掉到个位数，回头补数据花了更长时间，走了弯路。

林晓：鱼骨图那张挺实用的，我直接拿去改了一下当内部评估表用了，把”合规与审计漏算”那条画粗了，因为我们行业对这个要求确实高。