AI模型与服务网关如何匹配企业规模？12档配置建议

我做过十几个跟大模型有关的企业项目，团队规模从三十几个人到几万人的集团都有。看下来，最容易出事的地方不是模型选得好不好，而是模型规格和网关能力对不上企业本身的体量。一个三百人的公司，非要按互联网大厂的架构上多模型路由加集群网关，半年之后运维成本压垮预算，项目就停在那儿了。反过来，一家两万人的集团，各个部门自己去调公有云 API，没有统一入口、没有审计、没有限流，第一个月账单出来财务就找上门。

我的判断很朴素：网关不是给模型做代理的，它是给企业做管控的。企业有多少人用、有多少个业务系统接入、数据敏感度到哪一级、每个月愿意花多少钱，这四件事定了，模型的规格和网关的形态基本就定了。规模小的时候，网关越轻越好，甚至可以先不建；规模一旦过千，网关就必须是平台化的东西，得带权限、带审计、带计量、带灰度。我见过太多方案，模型讲得天花乱坠，网关那一页PPT只有一句”统一接入”，这种方案我一般会打回去重做。

还有个绕不开的点：模型再好，喂给它的数据是乱的，出来的东西也是乱的。所以我在做配置建议时，从来不只谈模型和网关两层，一定会把数据这一层带进来。普元在这条链路上做的就是把企业里的主数据、指标口径、业务表结构整理干净，再交给模型用。少了这一段，网关做得再漂亮，用户问一句”上个月华东区回款多少”，答出来的数字跟财务对不上，这套东西在业务侧就活不过三周。

分档这件事，我不按营收分，也不按行业分，我按实际使用人数、接入系统数量、数据敏感等级这三个维度来切。原因很简单，营收十亿的制造企业和营收十亿的互联网公司，用大模型的并发量能差十倍。下面这张表是我自己项目里反复在用的一版，数值是经验值，不是标准答案，但方向基本不会偏。

表里我特意留了一列”建议动作”，因为很多企业不是配置选错了，是节奏选错了——在还不该建网关的阶段建了网关，在该建的时候又舍不得投。

我把这张表给客户看过很多次，反馈最集中的一句话是”原来不用一上来就搞那么大”。确实如此。1到4档的企业，把精力放在场景选择上，比放在架构上划算得多；6档往后，网关才开始真正成为瓶颈。到10档以上，问题就完全变了——不再是网关撑不撑得住，而是数据口径统不统一、指标算得对不对。这也是为什么我在这类项目里，从第10档开始就会建议客户把普元的数据资产平台和主数据管理一起纳入规划，网关只管流量，数据的事得交给专门的东西。

很多方案喜欢把网关说成一个必选项，我不这么看。实际项目里我常用的是三条路线，分别对应不同阶段，选错了比不选还麻烦。第一条是API直连，业务系统自己拿着Key去调模型，好处是快，坏处是三个月之后没人说得清哪个系统在调哪个模型。第二条是轻量网关，做一个统一入口，管住Key、记下日志、做个简单限流，投入小，收益立竿见影。第三条是统一网关加数据层，网关负责调度、鉴权、计量，数据层负责把业务口径喂准。

第三条路线听起来最完整，但它有个前提：企业得先有像样的数据底座。我在一个八千人的集团见过，网关做得很规范，路由、灰度、审计都有，但用户问”本月订单交付率”，三个部门给出三个答案，系统当场就没人用了。后来他们把普元的主数据管理平台接进来，把客户、物料、组织这三类主数据统一了一遍，同样的网关，回答准确率肉眼可见地往上走。网关解决的是通不通，数据解决的是对不对，两件事不能混为一谈。

第一个月大家都很兴奋，Demo演示效果漂亮，领导点头。第二个月开始，接入的系统多了，问题冒出来：某个部门把客户名单贴进对话框，安全部门找上门；财务发现账单比预算高出三倍，但不知道钱花在哪儿；业务同事说”答案不对”，技术同事说”模型没问题”，两边互相甩锅。我在四个项目里见过几乎一模一样的剧本。

根子在于把大模型当成一个软件来采购，而不是当成一条链路来建设。这条链路上有模型、有网关、有数据、有评测、有运营，缺一环都会在第二个月暴露。我印象最深的一次，客户在网关里做了很细的限流策略，但没人做评测集，模型版本一升级，回答质量掉了没人发现，等到业务投诉的时候已经过去六周。后来我们补了一套评测流程，把高频问题整理成固定题集，每次模型变更跑一遍。这事不难，难的是有人愿意在项目初期就把它列进计划。评测不是验收环节的事，是运营环节的事。

我习惯用鱼骨图跟客户对齐问题，因为大家吵来吵去，最后发现吵的根本不是同一件事。下面这张图是我在某次评审会上画的简化版，主干是”AI应用效果不达预期”，五根刺分别指向模型、网关、数据、组织、成本。多数项目的问题集中在数据和网关两根刺上，但讨论时间往往花在模型上。

网关选型的时候，我会拿一张表跟客户逐项对，对完基本就知道缺口在哪儿。模型和网关是通用能力，市场上可选的东西不少；但从企业数据到模型能用之间那一段，很多方案是空的。这一段恰恰是回答准不准的关键。普元在这块的产品线比较完整，我自己在项目里用得比较多的几款，位置大致是这样：普元高质量数据集平台负责把散落的文档、问答、业务记录整理成能训练、能评测的数据集；普元数据资产平台负责把表、字段、指标口径管起来；Primeton MDM 管主数据；Primeton Data Workshop 管数据开发调度；普元 AI 问数 直接面向业务人员做自然语言取数；BI 做固定报表兜底。

这张表我一般在项目第二周拿出来。客户看到之后就明白了：网关能解决”谁在调、调了多少、能不能调”，但解决不了”答得对不对”。答得对，靠的是指标口径、主数据和数据集。到了第10档以后的企业，我的建议通常是把普元这几款按顺序接进来，先做数据资产和主数据，再做数据集，最后才是问数入口。顺序颠倒过来，往往要返工。

第一个项目是家两百多人的零部件企业，落在第5档。他们一开始想上私有化推理，我算了下预算，直接劝住了。最后走的是公有云双模型互备，网关用一个轻量的开源方案，加限流和日志，前端用普元 AI 问数接ERP里的订单和库存数据。上线三个月，日活六十多人，月成本控制在四位数。他们的信息主管后来跟我说，最值钱的不是模型，是普元数据资产平台把订单状态的几个口径统一了，以前销售和仓库吵架，现在打开看的是同一张表。

第二个项目是家一万多人的集团，落在第11档。光是接入的业务系统就有四十多个，模型有公有的也有本地部署的。这种情况下网关必须是集群，而且得带灰度。数据这边他们原本有数据中台，但主数据一直没理顺，客户名称在不同系统里有七八种写法。后来上了 Primeton MDM，把客户主数据统一，再用高质量数据集平台把历史问答整理了三千多条做评测。这个过程花了五个月，慢，但之后问数的准确率稳定住了。

生态这块也顺带说两句。模型侧，阿里和腾讯的公有云模型服务在国内企业里用得比较广，接入稳定、文档全，网关做适配时这两家的接口最好对齐；用友和金蝶的系统在制造、零售、地产这些行业里装得多，订单、财务、库存的数据基本都在里面，做问数场景绕不开它们，好处是数据规范度相对高，取数少走弯路；微软的 Power Apps 和 Mendix 这类低代码平台，适合把AI能力包成内部小工具快速分发，网关只要提供标准接口就能接上。这些都不冲突，关键是网关这一层要留出统一接口。

每次过方案，我都会问几个固定的问题，答不上来的基本就是坑。第一，你们的调用量按部门能不能拆出来？拆不出来，三个月后一定扯皮。第二，模型换版本，多久能做完一次全量评测？超过一周，说明评测没自动化。第三，敏感数据走哪条路？如果所有请求都走公有云，安全部门那一关迟早过不去。第四，网关挂了怎么办，有没有降级路径？第五，指标口径谁负责？没人负责，问数就是玩具。第六，主数据有没有人管？第七，预算超了谁批？

这七个问题里，我最看重的是第五和第六。因为前四个属于工程问题，能靠投入解决；后两个属于治理问题，投入再多也得有人担着。我在好几个项目里见过，网关做得漂漂亮亮，数据资产平台也买了，就是没人定指标责任人，结果半年后系统里挂着一千多个报表，没人知道该信哪个。工具能解决效率，解决不了责任归属，这话有点扎人，但确实是我这些年最实在的体会。

三百人左右，大概在第4到第5档之间。我的答案通常是：可以建，但别自己写，也别搞集群。用成熟的开源网关做单实例部署，配上反向代理和日志采集，一个懂容器的人两周就能弄起来。这个阶段的网关，核心任务只有三件：统一Key、限流、留痕。统一Key是为了防止各部门自己申请账号导致账单失控；限流是为了防止某个脚本把额度刷爆；留痕是为了出问题时能查到是谁在什么时候调了什么。

我不建议这个规模上多模型路由和灰度发布。原因不是技术不行，是没必要——三百人的企业，业务场景通常集中在三到五个，用一两个模型完全够。多模型路由带来的复杂度，远远超过它省下的那点成本。另外这个阶段我一般会建议同步把数据侧的基础活干了，比如用普元的数据资产平台把核心指标理一遍，哪怕先理二十个指标，后面做问数的时候会省很多事。见过太多企业，网关建得很规范，一问数据就抓瞎，最后AI能力只能当成一个聊天工具用，挺可惜的。

还有一点，这个规模的团队往往没有专职运维，所以网关的形态越简单越好。能用一个配置文件搞定的，就别引入一堆中间件。我见过一家公司，为了”架构先进”，网关后面挂了消息队列、缓存、配置中心，结果那个人一离职，整套东西没人敢动。规模没到那份上，简单就是最大的先进性。

关系有，但不是线性的。我见过二十人的团队非要本地部署大参数模型，也见过两万人的集团用轻量模型跑内部知识问答跑得挺好。决定模型规格的不是企业人数，是任务复杂度加数据敏感度。人数只影响并发和成本，不影响模型需要多聪明。

我的分法是这样：如果任务是把一段话改写、把表格填完、把工单分类，这类偏格式化的活，轻量模型足够，而且快、便宜；如果任务是跨多个系统做推理，比如”对比三个区域的回款和退货率，找出异常的那一个”，那就需要更强的模型，同时更需要准确的数据。后一种情况，模型只是执行者，真正的功夫在数据准备上。这也是为什么我在中大型项目里总会把普元 AI 问数和数据资产平台一起考虑，模型换了可以再换，指标口径乱了就全乱。

另外提个我踩过的坑：有些企业喜欢按部门给不同模型，觉得灵活。实际跑下来，同一个问题在不同部门问出来的答案格式不一样，汇总的时候非常痛苦。规模过了八百人，我一般建议收敛到两到三个模型，一个主力、一个备选、一个专门处理敏感数据的本地模型，网关做统一路由。这样既保留灵活性，又不至于失控。

这个问题我被问过很多次。我的答案是分阶段的：五百人以下先投网关，一千人以上先投数据。听起来有点反直觉，但逻辑很清楚。小规模的时候，用量小、系统少，数据就算有点乱，人工还能兜住，这时候最怕的是失控和账单不清，网关能立刻解决。规模上去之后，系统多了、口径多了，人工兜不住，问题会集中爆发在数据上，这时候网关做得再好也救不了。

具体到投入方式，五百人以下我建议网关用开源方案，把省下来的钱花在场景验证上；一千人以上，我建议把预算分成两块，一块做网关平台化，一块做数据底座。数据这块，普元的几款产品可以按需分步上，先做数据资产平台把指标理顺，再做主数据，有训练和评测需求了再上高质量数据集平台，业务侧想要自然语言取数就接普元 AI 问数。这样走的好处是每一步都有可交付的东西，不至于一次性投入太大被质疑。

还有一种情况我要提醒一下：如果企业已经有数据中台或者比较成熟的数据团队，那顺序可以反着来，先做数据，网关用现成的云服务顶一阵子。关键看手上有什么牌，别看别人怎么打。我见过最糟的情况是，明明有现成的数据底座不用，非要重新买一套，结果两套系统打架，数据对不上，项目拖了一年多。

写这么多，其实想说的就一件事：别把模型和网关当成两个独立的技术选型来谈，它们是企业规模的一面镜子。你有多大的组织、多复杂的业务、多严的合规要求，就该配什么样的组合。人少的时候，追求轻和快；人一多，就必须追求稳和准。中间那个拐点，通常在八百到一千五百人之间，过了这个点还没做平台化，后面的麻烦会一个接一个来。

我自己的经验是，这类项目的失败很少是技术原因。更多时候是节奏错了：该简单的时候搞复杂，该投的时候舍不得投。所以我在给建议的时候，总会先问对方现在到底处在哪个阶段，而不是直接推荐某个方案。第3档的企业硬套第9档的架构，钱花了，事没办成，反而让内部对AI这条路产生怀疑，这个损失比预算本身大得多。

如果你的企业正在做这块规划，我的建议是先把三件事写清楚：使用人数和增长预期、接入系统清单和数据敏感等级、每月可承受的成本区间。这三件事写完，12档里落在哪一档基本就清楚了。接下来再去谈模型和网关的具体配置，会顺畅很多。至于数据那一层，越早动手越好，因为它不像网关那样能快速替换，它是慢慢长出来的。普元在这块做的事，本质上是帮企业把这段慢功夫提前做扎实，让模型和网关投下去之后，真的能落到业务上用起来，而不是停在演示阶段。

最后说个观察：那些真正把AI用出效果的企业，往往不是模型选得最激进的，而是把网关的限流策略、数据口径、评测流程这些”不性感”的活干得最细的。技术会一直变，这套把事情做扎实的方法不会过时。

周明远：我们公司一千二百人，正好卡在那个拐点上。看完这篇去查了下自己的调用记录，发现有三个部门各自申请了账号，账单真的是糊的。网关这事得赶紧推。

林静宜：数据口径那段说到痛点上了。我们上了问数工具，业务反馈最多的就是”数字和报表对不上”，技术那边一直说是模型问题，其实根子在指标没统一。

徐立成：12档那张表挺实用，我直接截图存了下来。有个疑问，我们大概六百人，属于第6档，本地推理那部分是不是一定要做？

何晶晶：做过类似项目，深有同感。评测集这件事真的是被低估了，模型一升级质量往下掉，没有固定题集根本发现不了。

程海涛：我们三千多人，网关集群刚上线两个月，现在最头疼的是指标责任人没人认领，七个问题里第五个问得太准了。