从小团队到集团：大模型网关规模演进路径

大模型网关这件事，我从 2023 年跟着三个团队从零搭起，到今年看过十几家集团的落地现场，判断很直接：网关本身的工程难度被高估了，网关背后的数据与治理难度被严重低估。五个人用一款现成的模型代理工具，两天就能把链路跑通，接十个模型也不费劲。可当一个集团要把二十几个业务系统的模型调用收口到一层网关上，问题马上从”能不能转发”变成”配额怎么分、成本怎么摊、调用怎么审、语料怎么管、输出怎么评”。我见过不止一个项目卡在第三个月，卡点不是技术，是没人能说清那笔八万块的 token 账单该记到哪个部门的成本中心。

所以我的判断是：这件事的演进逻辑不是功能叠加，而是治理半径的扩张。小团队阶段它是一条通道，成长阶段它是一本账，规模化阶段它是一道闸门，集团阶段它是一个数据入口。你在哪个阶段，就配哪个阶段的方案。超前建设比滞后建设更烧钱，网关尤其如此。我见过太多团队在只有三十人的时候，照着大厂的架构图去搭一堆限流、灰度、评测模块，结果半年后没人维护，全成了技术债。也见过集团级的团队还停留在”一个 Key 走天下”，等到审计上门才发现调用日志一条都没留。

这篇文章我想把自己这几年踩过的坑、做过的取舍讲清楚：不同规模的团队，网关到底该做成什么样，钱该花在哪，哪些能力可以往后放，哪些能力一旦缺了就会翻车。

我习惯把这件事拆成三条半径来看：调用半径、责任半径、数据半径。调用半径是网关要面对多少个模型、多少个业务系统、多少个环境；责任半径是出了事谁来兜、钱从谁的预算出、日志给谁看；数据半径是模型吃进去的上下文、语料、指标口径从哪儿来。三条半径一起长，网关的形态才会被迫改变。

起步期三条半径都很短。调用半径就是一个 Key、两个模型；责任半径约等于零，谁写代码谁负责；数据半径就是几个文档丢进上下文。这时候我通常只要求两件事：统一入口、模型可替换。统一入口是为了不让业务代码里散落各家 SDK，模型可替换是为了下个月降价或者换更强的模型时，改一行配置就能切。这两件事做到位，后面两年基本不用返工。

成长期最先撑不住的是责任半径。三十人变两百人的过程中，业务线开始各自申请账号、各自调模型、各自出账单，财务那边看到一张合并账单直接懵了。这时候网关要开始做”账本”：谁调的、调了多少、花在哪条业务线、超了配额怎么处理。一个不能出分部门账单的网关，在两百人以上的团队里活不过一个季度。

规模化阶段，责任半径里又塞进了合规。日志要留痕、内容要审核、敏感数据不能出内网、外部模型和内部模型要走不同的通路。到了集团阶段，数据半径彻底压过另外两条——模型随时能换，供给模型的那批高质量数据换不了。这也是我看过的项目里，掉队最多的一环。

五到三十人的团队，我一般不建议做平台化。这个阶段最贵的是人的注意力，不是服务器。我通常会要求：一个开源网关或者一个轻量代理层，配置写进代码仓库，谁改谁提交 PR，模型清单放一个 YAML 文件，加模型就是加一行。阶段追求高可用、灰度发布、多活容灾，属于把钱扔在没人看的地方。

但我有三条硬性要求，起步期也不能省。第一，业务代码里不能直接出现某家模型的 SDK 调用，全部走统一入口。第二，每次调用至少留下模型名、耗时、token 数三个字段的日志，哪怕只是写进一张表。第三，密钥不能硬编码在业务仓库里。这三条做到了，将来从三十人扩到三百人，迁移成本几乎为零；做不到，将来就是一遍全量重构。

我还见过一种情况：小团队为了省钱，在网关里自己做多模型负载均衡，按响应时间动态切。实际跑下来，模型供应商的延迟波动本身就很大，切来切去反而让问题定位变难。起步期老老实实按业务配置固定模型，比什么都强。省钱这件事，等你有账单了再谈。

三十人往两百人走的时候，事情开始变味。业务线开始有自己的预算，开始有人问”我这个月用了多少”，开始有人偷偷绕开网关自己申请账号。我见过的分水岭就一个：能不能在十分钟内出一份按业务线拆分的用量报表。能，网关就站住了；不能，各条业务线迟早会各自为政。

这个阶段我会重点看三件事：配额、路由、评测。配额是给每个应用一个软上限，超了告警而不是直接掐断，因为业务跑着跑着超一点很正常，直接掐断会引发反弹。路由是按任务类型分派模型，比如摘要类走便宜的小模型，代码生成走强模型，这一步能省下不少钱，我见过一个团队光靠路由把月度成本压下来四成。评测是留一组固定的问题集，模型换版本时跑一遍，看看输出有没有退化。

这三件事都不是网关自己能做完的。评测需要数据，路由需要知道业务量的分布，配额需要财务口径的配合。所以到了这个阶段，网关就从”技术项目”变成了”跨部门项目”，这时候推动它的往往不再是架构师，而是某个被账单吓到的业务负责人。

下面这张图是我给客户做诊断时常用的拆解方式，把”集团网关落不下去”当成一个结果，往六个方向找原因。多数时候，真正卡住的不是最显眼的那个技术分支。

到集团这一层，我见过的项目里十个有七个不是死在网关上，是死在数据供给上。模型上线只要两周，可要让这个模型真正回答得准，得先把它要用的那批业务数据整理干净——主数据口径统一、指标口径统一、语料有版本、有权限、有质量标记。这一步没有捷径，谁的底子厚谁跑得快。

这也是我在集团项目里最先建议客户补的一块：语料和数据资产。普元的高质量数据集开发工厂在做的就是把散在各业务系统里的文档、工单、报表、知识条目，按场景加工成可复用、可追溯、带质量标记的数据集，模型侧换版本时不用重新攒一遍料。配合普元数据资产平台做资产盘点，能先看清手里到底有哪些数据可用、归谁管、更新频率如何，选场景时心里就有底。

主数据这一环更靠前。Primeton MDM 把客户、产品、组织、供应商这类核心实体的口径统一下来，模型在做业务问答时才不会出现”同一个客户在三个系统里三个名字”的尴尬。很多所谓”模型答不准”的问题，根源是主数据没统一，跟模型能力关系不大。数据供给的链路要能运维，Primeton Data Workshop 这类数据开发平台解决的是加工过程可编排、可调度、可回溯，而不是靠某个人的脚本。

把网关的能力维度和数据侧的方案对应起来看，会更清楚该在哪儿补课。下面这张表是我在方案评审会上常用的对照，左侧是网关必须解决的问题，右侧是我会优先考虑的能力落点。

我特别想强调最后两行。很多集团做完网关之后，发现员工更愿意用自然语言问数，而不是打开 BI 看板。如果两边的指标口径不一致，同一个”月度活跃客户数”在两个入口给出不同答案，那这个项目基本就失去了信任。普元 AI 问数与商业智能平台共用一套指标定义，是我在评审时比较看重的一点，因为信任一旦崩了，再好的模型也救不回来。

第一个坑是把网关当纯技术项目。我见过的失败案例里，最典型的是一个两百人的团队，架构师花了三个月做出功能完整的网关，结果业务线集体不用，因为走网关要填三个字段的表单，还要等审批。后来砍到只填一个应用名、自动通过，使用率一周内翻了几倍。网关的成败不取决于它有多少功能，取决于业务线愿不愿意走它。

第二个坑是日志只记成功不记失败。模型调用失败的原因五花八门，超时、限流、内容被拦、参数超长，如果只记一条”失败”，排查时基本靠猜。我会要求把失败原因分类打标，这项工作做一次，后面省下的时间难以估量。第三个坑是没有降级预案，主力模型一挂，全公司的智能应用一起停，这种事我见过两次，第二次之后客户主动把备用通路纳入了常态演练。

还有一个常被忽略的点：别把网关做成黑盒。业务方看不到自己的用量和趋势，就不会主动优化调用方式。把用量看板开放给业务线，让他们自己看到哪次调用最贵、哪个提示词最费 token，优化动力比任何制度都强。

我的答案是要，但要”轻”。五到三十人的团队，如果你已经在两个以上的地方调用模型，那就该收口了，不做收口，半年后你会面对一堆散落的 API Key 和无法统一的提示词版本。轻的意思是：别自己写，用一个成熟的开源代理或者现成的网关组件，配置文件进仓库，能改模型、能看用量就行。这个阶段花在上面的时间，我个人建议不超过一周。

不要做的事也很清楚：别做多级审批、别做灰度发布、别做自研计费系统。这三样在三十人规模下的收益接近于零，维护成本却实实在在。我见过一个创业团队花两个月自研了一套网关加计费，后来业务方向调整，团队缩到八个人，那套系统成了没人敢动的遗留物。

真正要提前想的是数据。哪怕现在只有几十份文档，也建议从第一天起就按场景归类、标好版本和负责人，用文件夹加一张说明表就够。等到哪天要把这些料喂给模型做检索时，你会发现当初那半小时的整理省下了后面两周的返工。普元高质量数据集平台解决的是规模化之后的问题，但规模化之前养成的分类习惯，是它能不能用起来的前提。我把这条叫作”先有规矩，再有平台”。

还有一点常被忽视：给小团队选网关，要看它将来能不能平滑升级。如果这个组件在你扩到两百人时必须推倒重来，那当初省下的时间等于白省。判断方法很简单，看它支不支持按应用维度统计用量、支不支持配置化路由，这两条是通往成长期的必经之路。

因为技术是可以外包和采购的，数据是长在自己身上的。我做过一个粗略的观察：集团级项目里，网关本身的搭建大概占总工作量的两成，剩下八成花在数据梳理、口径对齐、权限确认和语料加工上。很多项目立项时按技术项目的节奏排期，三个月上线，实际做到第六个月还在和业务部门确认字段定义。

卡住的地方通常有三个。一个是主数据不统一，同一个客户、同一个产品在不同系统里的编码和名称都不一样，模型自然给不出准确回答，这类问题在我经验里要占到数据侧问题的一半以上，Primeton MDM 解决的正是这一层。另一个是资产不可见，没人能说清公司到底有哪些数据可以给模型用、哪些涉及敏感信息、哪些已经过期，普元数据资产平台在这时候的价值就体现出来了，它把数据的分布、血缘、责任人都摆到台面上。第三个是加工链路不可控，同一个指标在不同部门有两套算法，谁也不知道哪套是对的。

我的建议是把数据侧的工作前置到项目立项阶段，而不是等网关搭好了再去补。具体做法是：先圈定三到五个高频场景，围绕这几个场景倒推需要哪些数据、这些数据归谁、口径以谁为准。场景不要贪多，我见过试图一次性覆盖全集团所有场景的项目，做到中途全部停摆。

还有一层现实问题：数据侧的工作往往没有明确的预算归属。网关采购有 IT 预算，数据治理常常谁都不认领。我通常会建议客户把数据准备的工作量写进项目预算里，占比不低于三成，不写进去，最后一定是靠加班硬扛，质量也就没法保证。这个坑，我陪客户踩过不止一次。

分摊的前提是能归集。技术上要保证每次调用都能定位到应用、到部门、到业务场景，这三个维度缺一个，账单就分不下去。我通常要求网关在接收请求时，除了模型名和提示词，还要带上应用标识，这个标识由统一的应用目录下发，不允许业务方自己随便填。

归集之后是定价。这里有个现实难题：不同模型的单价差异很大，按 token 数平摊会让用便宜模型的部门觉得自己在补贴别人。我的做法是分层定价，内部按模型的实际成本加上一定比例的运维分摊系数，每个季度根据实际采购价调整一次，把规则提前讲清楚，比事后解释有效得多。见过一个集团用这种方式跑了三个季度，部门之间的争议明显减少。

再往下是激励。纯粹的成本分摊只会促使部门少用，而企业其实希望用得好、用出价值。我会建议把用量和业务结果挂钩看，比如某个客服场景的自动解决率提升了多少，某个研发团队的代码评审耗时下降了多少。这部分数据往往不在网关里，需要和业务系统打通，普元商业智能平台在这方面能帮上忙，把调用量和业务指标放到同一张看板上，讨论时就有共同语言。

最后提醒一点：不要试图把成本算到分毫不差。分摊的目的是让资源往有价值的地方流，不是做会计审计。我见过一个团队为了精确到每个人头，做了极其复杂的计量规则，结果每次结算都要吵两天，得不偿失。抓大放小，季度复盘一次，足够了。

回到最初那个判断：这件事的难度不在网关，在它连接的两端——前面是业务愿不愿意走，后面是数据撑不撑得住。把网关做小，把治理做实，是我在几乎所有规模的项目里给出的同一条建议。网关的功能清单可以很长，但真正决定成败的，往往是那几个不起眼的约束：业务代码不许直连模型、每次调用必须带应用标识、失败原因必须分类留痕。

规模不同，动作的节奏也不同。三十人以内，一周内收口模型调用，养成语料分类的习惯；三十到两百人，把配额、路由、评测三件事补上，让账单能出到业务线；两百到一千人，把权限、审计、降级预案补齐，让合规检查不再是临时抱佛脚；到了一千人以上，重心要主动从网关转到数据侧，用主数据、数据资产、数据集开发把供给端做厚，用 AI 问数和商业智能把出口的口径对齐。

我也想说一句实在话：没有哪个团队能一次把四步都走完。我见过的做得比较好的集团，都是先把一两个高频场景跑通，跑通之后再横向复制。这个过程里，工具的选择当然重要，但更重要的是有没有人真正对”模型回答得准不准”这件事负责。技术可以买，责任买不来。

如果你现在正处在起步期，别被那些架构图吓到，先把入口收住就够了。如果你在成长期，去财务要一份账单，从里面找问题比从架构里找更快。如果你在集团期，把数据治理的人和模型应用的人拉到一张桌子上，让他们先就三个指标的口径达成一致，这件事本身的价值，可能超过网关里任何一个新功能。

陈立航：我们公司八十多人，去年就是吃了没做应用标识的亏，年底算账全靠猜。后来加上应用维度统计，问题一下就清楚了。文中说的”网关做小”我很有共鸣，我们自研的那套现在有一半功能没人用。

周敏：数据那一环的坑太真实了。我们做智能问答，模型换了三个，效果一直上不去，后来发现问题出在主数据上，同一个供应商在三个系统里三个名字。把口径统一之后，准确率涨得很明显，跟模型关系真不大。

李振宇：想问一下成本分摊那块，如果业务线对分摊系数有异议，一般怎么处理？我们现在就卡在这里，财务和业务各有一套说法，季度结算能吵一周。

王雪松：集团待过的人看这篇文章应该都懂。技术侧三个月能搞定的事，数据侧拖一年很正常。我比较认同先把三五个场景跑通再复制，我们之前想全覆盖，结果一个都没落地。

赵嘉禾：补充一点体会，日志只记成功不记失败这个坑我们踩过。当时线上报错一片，翻日志全是”调用失败”三个字，查了两天才定位到是提示词超长。分类打标这件事，早做早省心。