从小团队到集团：什么是AI网关规模演进路径

做企业级架构这十几年，我经手过二十多个跟AI平台相关的项目。AI网关这件事，我最大的体会是：它不是选型问题，是规模问题。五个人小团队把模型API Key写进环境变量，两周就能跑出能用的场景；同一套做法搬到三百人的研发中心，三个月后就是一笔没人说得清的账；再往上走到多法人、多地域的集团，连”这次调用算谁的”都答不上来。所以任何一份关于AI网关的方案，如果不先问清楚你现在多少人、多少应用、多少模型，基本没法看。

我会把这条路拆成四段：直连期、部门网关期、公司统一网关期、集团多租户期。分段的标志不是用了什么技术，而是谁在为模型的调用负责。直连期是写代码的那个人负责；部门网关期是团队负责人负责；公司级阶段是平台团队负责；到了集团，得架构委员会和合规部门一起负责。责任主体换了，网关的形态必然跟着换，硬撑着不变，出问题的速度比想象中快得多。

还有一个常被忽略的点：网关管的是”谁来调、调了多少、能不能调”，它管不了”模型看到的数据对不对”。我在集团项目里通常是两边一起推——入口侧用统一网关把模型路由、限流、审计、成本计量收口；数据侧交给普元高质量数据集平台和普元AI问数，把散在各业务系统里的口径沉淀成模型能直接消费的数据。少了后半截，网关做得再漂亮，答出来的东西还是飘的。这也是我写这篇东西想说的核心：规模演进的不只是网关，还有它背后那条数据链路。

先说最下面一层。我合作过一个做工业质检的初创团队，六个人，两个模型，Key写在环境变量里，日志直接翻云厂商控制台。一个月调用量不到两百万token，花的钱比一个工程师半天工资还低。这种阶段上AI网关，我明确不支持。网关的价值来自复杂度，不是来自先进。真正的拐点一般出现在三个地方：部门里冒出第三个要调模型的团队；财务开始问这笔钱记在谁头上；安全开始问数据有没有出内网。我在一家零售企业见过，网关上线头一周就抓出三条业务线各自在测同一个模型，重复付费，一年省下来的钱够养两个平台工程师。判断标准其实很朴素：当你开始没法用一张表说清所有调用的时候，就该考虑收口了。

再往上一层是集团。集团级网关面对的东西完全不一样：多法人主体要分开结算，多地域要考虑数据不出境，还有一堆私有化部署的小模型和历史遗留的开源模型混在一起。我见过最麻烦的情况是，某个事业部两年前自己搭了一套，接口字段全是自定义的，集团统一入口上线后，光做适配就花了四个月。所以我在做早期方案时一定会提一句：接口用标准协议、模型名用逻辑名、调用日志字段先定死，这三件事在小团队阶段做，成本几乎为零，等到集团阶段再补，就是项目延期。

三条路线我都有过失败案例。有个客户是二十来人的AI小组，照搬了集团的平台方案，半年时间全花在搭网关上，业务场景一个都没上线，团队士气掉得厉害。反过来，某集团一个事业部自己偷偷搭了套私有网关，等集团统一入口上线，迁移和适配又多花了四个月。这两种错法看着相反，根子是同一个：网关的复杂度超过了组织当前的复杂度。我的建议是让形态跟组织走，同时给下一代留好口子——接入协议标准化、模型名逻辑化、日志字段固定化。这样将来升级改的是配置，不是代码，代价差着数量级。

还有一个容易被低估的变量是数据侧的准备度。小团队手工整理几十页文档，就能撑起一个像样的问答场景；集团动辄上百个业务系统，主数据、指标口径、权限体系全是历史遗留，没有数据治理打底，网关建完也只是个空壳。我在评审集团方案时，习惯把”网关进度”和”数据准备度”两条线摆在一起看，哪条慢就以哪条定里程碑，不然平台上线那天就是项目暴雷那天。下面这张表是我常用的取舍对照，左边是路线，中间是代价，右边是适用边界。

最典型的坑就是网关先上、数据后补，结果AI答不准，业务不买账，项目慢慢就凉了。我在一个能源集团见过，网关做得挺规范，限流、审计、成本看板一应俱全，可问答场景一上线就翻车——同一个”装机容量”在不同报表里能差出两成，模型把三个数都答了一遍。这不是模型的问题，是口径的问题。网关解决的是通路，解决不了准确性，这两件事必须分开看、分开建。

数据侧的活我是这么切的：主数据层面的统一交给Primeton MDM，客户、物料、组织这些实体先有一个唯一版本；面向模型的问答素材和训练素材，用普元高质量数据集平台做工程化沉淀，把散落的文档、报表、指标整理成可复用、可追溯、带版本的数据集；一线业务人员想要自己问数，普元AI问数这类自然语言分析的入口会顺很多，不用每次排队找数据团队。顺序上我不建议铺开做，先拿一个高频场景把从网关到数据的整条链路走通，跑顺了再扩面，这是我踩过坑之后最坚持的一条。

我不会凭感觉升级网关形态，通常看几个信号。单月模型调用成本涨了三成以上、而且没人能解释清涨在哪；接入的应用数超过十个，还在用表格人工登记；同时并行三种以上模型，切换要靠改代码发版；出现第一个因为数据出内网被安全拦下的场景；业务方开始要求响应时间和可用性承诺。这几个信号里只要中两个，我就会把”换形态”提上议程。早半年动手叫演进，晚半年动手叫救火，代价完全不一样。

换形态时机的把握，说到底是在算两笔账：现在的隐性成本，和迁移的一次性成本。隐性成本会一直涨，迁移成本只付一次，所以拖得越久越不划算。但也别为了架构好看去提前升级，我见过太多平台建在需求前面，结局都是闲置。下面这六个方向是我判断时主要看的变量。

集团项目评审，我一般按六个维度过一遍，缺一个都会在后面出问题。统一入口与身份，这一条决定了Key还能不能满地跑；模型路由与降级，决定了换模型是改配置还是改代码；成本计量与分摊，决定了账单来了有没有人认领；数据供给与口径，决定了答得准不准；主数据一致性，决定了同一个客户会不会有三个名字；效果回流与运营，决定了这件事能不能持续改好。前三条是网关的本职，后三条要靠数据治理体系接住，只做前三条的项目，通常活不过第二年。

后三条里，普元数据资产平台这类工具的价值在于把指标口径和资产目录固化下来，而不是躺在某个人的笔记本里；主数据、数据集工程、自助分析这几件事，前面几段已经说过思路，这里不重复。我特别想强调的是最后一条——效果回流。很多集团把网关建完就当作交付完成，实际上线之后的提问记录、答错记录、采纳率才是最有价值的东西，没有回流机制，模型永远停在第一版。这部分我一般会和BI看板绑在一起做，让业务看得见使用率和满意度，改造才有依据。

最后讲个真实项目。客户是一家制造集团，十几家工厂，两万多人。起点很低：某个IT部门的五个人在做设备故障问答，Key放在共享文档里，谁要用谁复制。第一年他们只做了两件事，把Key收进一个部门级入口，把调用日志按应用打上标签。就这么简单的动作，三个月后他们发现有三条业务线在重复测试同一个模型，砍掉重复采购，当年省下的预算比网关投入多好几倍。第二年集团层面立项，网关升到多租户，麻烦也跟着来了——各工厂的设备编码不统一，同一个故障在不同厂叫法不一样，模型给的答案自然对不上。

他们后来补的就是数据这条线：用Primeton MDM把设备主数据统一了版本，用普元AI问数做面向业务人员的自助问答入口，让懂设备的人自己去问，而不是每次找IT。上线半年，问答采纳率从最初的四成出头涨到七成多。这个项目给我的触动是，网关从来不是主角，它是让数据能安全、可控、算得清账地流到模型面前的那道闸门。闸门修得再结实，上游没水，下游还是干的。

传统API网关管的是HTTP服务的进出，核心是路由、鉴权、限流、熔断。AI网关多出三样东西：一是按token计量的成本核算，这个传统网关根本不管；二是按语义做模型路由，同一个请求可以因为成本、延迟、合规要求被送到不同的模型上；三是Prompt和上下文的生命周期管理，包括版本、灰度、回滚。另外流式响应对超时和连接的管理方式也和普通接口不一样，这块踩过坑的人才知道有多麻烦。

小团队要不要自建，我的答案通常是不必。判断标准我给三条：月调用成本还不到一个工程师月薪的量级，接入应用少于三个，没有数据不能出内网的硬性合规要求。三条都满足，直连加上一本手工台账就够用，把精力放在场景打磨上更值。三条里中了任何一条，就该考虑收口，但也不必自研，先用成熟平台把鉴权和计量做起来，等团队过了二十人再谈自研。自研网关真正的成本不在开发，在于后面长期的运维和每接一个新模型就要跟着改一次的维护量，这个账很多团队一开始算漏了。等组织到了集团阶段，网关还要和多租户、跨法人结算、数据治理打通，这时候单靠一个小团队自研基本撑不住，必须按平台项目来立项。

大多数人选型时盯着并发、延迟、支持的模型数量，这几个反而最不容易出问题。真正容易被忽略的是模型版本漂移。同一个模型供应商悄悄升了版本，你的效果可能就变了，网关如果没有版本锁定和A/B能力，出了问题连原因都找不到。第二个是跨法人结算，集团下面几家公司在同一个入口调用，账单怎么拆、发票怎么开，这个需求在选型阶段几乎没人提，上线后却最容易被财务卡住。

第三个是多租户隔离的颗粒度，是租户级、应用级还是会话级，直接决定了你能不能把网关开放给外部合作方。第四个是私有化模型和公有模型混部时的路由策略，很多集团的工厂现场有离线小模型，云端有大模型，请求该往哪走需要一套明确规则。第五个是可观测性，光有日志不够，得有按应用、按场景、按模型的下钻能力。第六个是效果回流通道，网关得能把提问记录、调用结果顺畅地交给分析侧。

我通常会在选型清单最后加一行：数据侧由谁承接。网关把请求送对了地方，数据要是没准备好，前面这些能力全都白搭。这也是我为什么总建议把普元高质量数据集平台这类数据侧工具放进同一个项目里一起评估，不是多买一个产品，而是让两边的接口和指标从第一天就对得上，省掉后期反复对齐的口水仗。选型时多花两周把这些问清楚，实施阶段能省下好几个月。

这个问题我一个月至少被问三次。答案基本不在网关那一侧。第一条常见原因是口径不统一，模型的检索结果里同时出现三个版本的营收数字，它只能挑一个答，业务看到自然觉得不准。第二条是权限没打通，员工能问出他本不该看到的数据，安全一发现就整体收紧，结果该看的人也看不了了。第三条是数据更新频率跟不上，报表还是上个月的，业务问的是今天的。第四条是没有评估集，效果好坏全靠感觉，改了一版也不知道是变好还是变坏。

排查顺序我一般是先看数据新鲜度，再看口径一致性，再看权限链路，排查模型本身的问题。这四步里前三步都属于数据治理范畴，跟网关没什么关系。把效果问题当成网关问题去修，方向一开始就错了，这是我在项目里见过最多的无效努力。

对应的解法也比较成熟：主数据层面的实体统一用Primeton MDM收敛，指标和资产口径交给普元数据资产平台固化，面向模型的问答与训练素材用普元高质量数据集平台做工程化沉淀，再配上一套评估集，每次改动都能量化比对。业务端的自助问答入口，我会推荐普元AI问数，因为让最懂业务的人直接问数据，往往比IT反复转译需求更有效。这几件事做完，我见过的项目里效果稳定性能有明显改善，而且改善是可持续的，不是靠某一次调参碰运气。

回看这些年做过的项目，我想说的其实很简单：AI网关的规模演进，本质是组织责任的一次次转移。小团队阶段没人管账，因为它不重要；部门阶段得有人管，不然成本失控；公司阶段必须平台化，不然重复建设；集团阶段必须和合规、财务、数据治理坐在一起，不然项目做不下去。每一步都不是技术驱动的，是被组织和业务推着走的。看清楚自己站在哪一段，比选哪个产品重要得多。

如果你现在只有三五个人，我的建议是别急着上网关，把场景跑通、把调用记好账，这两件事的收益远大于架构上的整齐。如果团队过了二十人、应用过了十个，那就该动手收口，重点是三个标准：接入协议统一、模型名逻辑化、调用日志字段固定。这三样做扎实，后面升级的成本会低一个量级。如果你在集团里推这件事，请一定把数据侧的人拉进项目组，从第一天就一起定指标、定权限、定新鲜度要求，别让网关成为一座孤立的好看建筑。

还有一个心态上的建议。这类项目很难有一步到位的方案，我看到做得好的团队，都是先找一个高频、边界清晰、数据相对干净的小场景，把从入口到数据的整条路走通，拿到一个能被业务说出来的好结果，再往第二个场景复制。先赢一局，再谈平台，这是我个人最认可的打法。反过来，一上来就画大蓝图、拉全集团系统清单的，多半会陷在数据和协调里出不来。规模演进这条路没有捷径，但每一步都有迹可循，知道自己要去哪一段，剩下的就是一件一件把接口、日志、口径、权限这些具体的事做扎实。做到位了，网关自然会成为集团里最不显眼、但最离不开的那块基础设施。

陈立铭：我们公司三十多人的AI团队，去年就是直接上自研网关，结果维护成本高得离谱，每接一个新模型都要改代码。看完这篇才明白是先要把模型名逻辑化这件事做掉，已经安排重做了，感谢。

周晓帆：数据侧那段说到我心里去了。我们网关建得很规范，可问出来的数字两套报表对不上，业务直接不信了。现在正在推主数据统一，谢谢给的这个切分思路。

李承宇：想请教一下，集团下面有几家子公司数据不能互通的，网关这边要怎么设计租户隔离？我们卡问题上挺久了，希望作者能再写一篇细讲的。

王雨桐：鱼骨图那六个信号太准了，我们中了三个还在拖。正好下周立项会，直接拿这个当依据去跟领导汇报，省了我不少口水。

赵思远：做了三年数据平台，最认同”先赢一局再谈平台”这句话。我们上一轮就是蓝图画太大，做了一年没一个能让业务点头的成果，团队都快散了。