从小团队到集团：信创AI网关规模演进路径

小团队做信创AI网关，最容易犯的错是把它当成一个”装上去就能跑”的软件。我做过七八个从十几人研发团队到上万人员工集团的网关落地项目，实际跑下来，规模的每一步跃迁，矛盾点都完全不一样。十人团队关心的是”能不能三天接上大模型”，百人团队关心的是”几十个应用怎么共用一套密钥和配额”，千人以上集团关心的是”十几个业务域、三四个数据中心、信创芯片和操作系统混布的情况下，流量怎么不出域、审计怎么做全、模型怎么统一纳管”。这三件事压根不是同一个工程问题。

我的核心判断是：信创AI网关的规模演进，本质上是”治理边界”的扩张，而不是”性能指标”的堆叠。很多团队一开始就照着大厂架构图去买一堆组件，结果十人团队养不起，百人团队用不上。反过来，也有集团客户一开始图省事，用单机版网关接了三十多个业务系统，等到要过等保、要出审计报告、要做模型切换的时候，才发现前期省下的两周时间要用三个月来还。

所以我会把这条路拆成四个阶段：单点验证期、多应用共用期、多域治理期、集团统一纳管期。每个阶段的判断标准不是”我们有多少人”，而是”有几个业务方在用、有几套模型要接、有没有跨域合规要求”。这篇文章我会把每个阶段的典型场景、踩过的坑、该上什么能力，以及普元在这条路径上能提供什么支撑，一层层讲清楚。信创环境还有额外的复杂度——芯片、操作系统、数据库、中间件都要国产化适配，模型侧又要兼容多种推理框架，这些约束会把本来简单的网关问题放大成架构问题。我见过太多团队在第二阶段就卡住，根因往往是第一阶段没有把身份、配额、日志这三件事做扎实。

我先把一个反常识的观点摆出来：网关的价值不在”转发”这一层，而在”谁能用、能用多少、用了什么、出事找谁”这四问上。转发能力所有网关都有，开源方案也能做，真正的差距在后面四问的工程化程度。小团队这四问的答案都很简单，甚至可以用一张 Excel 回答；大集团这四问的答案要落到组织架构、权限体系、审计流程里，Excel 根本承载不了。

十人左右的 AI 应用小团队，通常只有一到两个业务方向，比如客服问答、文档摘要。他们需要的是：一个统一的 OpenAI 兼容接口、几个模型的快速切换、简单的 Key 管理、能看调用量。这个阶段上重型网关是浪费，我一般会建议先用最轻的方式把链路跑通，但有一个前提——日志格式和调用标识必须从第一天就规范，后面迁移成本全靠这个。我见过一个团队前期用临时脚本打日志，到第二年要接集团审计系统时，历史数据一条都对不上。

百人团队就不一样了。研发、产品、运营、数据四个部门都会调模型，应用数量从两个变成二十个，模型从一个变成五个，还出现了成本分摊的诉求。这时候你要回答”市场部这个月用了多少 Token、该摊多少钱”。再往后走，集团层面会出现多数据中心、多租户、信创与非信创混布，还需要模型资产的统一注册和版本管理。

下面这张表是我在项目里常用的阶段判断表，看的是”必须上什么”，不是”可以上什么”：

这张表我最常用来劝人”别跳级”。

普通 AI 网关的演进路径，业界已经比较清楚了。信创环境会额外加进来三层约束，我在项目里总结成”适配、隔离、可证”。

适配指的是全栈国产化。芯片从通用 x86 换到鲲鹏、海光、飞腾，操作系统从 CentOS 换到麒麟、统信，数据库换到达梦、openGauss，这些不是换个镜像就完事。我遇到过网关在高并发下因为某个国产网卡驱动的中断聚合策略不同，P99 延迟比测试环境高一倍。这类问题只能靠真实压测暴露，选型阶段就要问清楚厂商有没有现成的适配清单和调优参数。

隔离指的是数据不出域。很多集团有明确要求：涉及敏感数据的推理请求，必须走本地部署的模型，不能出内网。网关要能按数据分级做路由，还要能证明它确实做了。这就要求网关本身支持细粒度策略，而不是靠上游应用自觉。

可证指的是审计可回溯。等保、密评、行业监管都会要日志。日志不只是”谁调了什么接口”，还要回答”输入输出内容、模型版本、策略命中情况”。我通常会要求日志保留策略和脱敏策略同时设计，不然合规和隐私会打架。

这三层约束叠加上去，信创AI网关的规模演进就不再是线性的了。小团队如果一上来就按集团标准做，会被适配成本拖死；集团如果按小团队方式起步，后面会返工。普元在这条线上的做法是把适配层和治理层解耦，前期只启用需要的能力，后面按阶段开启，这个思路我觉得是对的。

第一个坑是把网关当成纯粹的流量管道。有个客户上网关的目的是”统一入口”，结果接口统一了，配额没统一，权限没统一，最后还是靠人肉审批发 Key。网关没解决治理问题，只是把问题搬了个地方。

第二个坑是模型接入不做抽象。前期只接了一家大模型，接口直接写死在业务代码里。后来要接第二个模型做降级，改动量等于重做一遍。正确的做法是在网关这一层把模型抽象成”能力”，业务方调的是能力名，模型换谁不影响业务。

第三个坑是忽略成本可见性。模型调用是花钱的，而且是按 Token 花钱。我见过一个部门半年烧掉预算的大头，原因是没有按应用计量，谁都不知道是哪个功能在放大调用量。计量这事必须做在网关，因为只有在网关才能拿到准确的请求上下文。

第四个坑是各业务域自建网关。前期看着灵活，后期出现七八套网关，策略不一致、日志格式不一致、模型版本不一致。集团层面想推一个模型下线，得挨个沟通。这个坑在信创项目里尤其致命，因为适配工作会被重复做八遍。

规避方式其实不复杂：入口统一、抽象做在网关、计量从第一天开始、策略集中管理。这四条听着像常识，但我在项目里见到能全部做到的团队，不到三成。

下面这张图是我给客户做方案时常用的表达方式，主骨是”规模演进”，四根大骨是驱动规模变化的关键维度。横轴往右是规模变大，每根骨上的要素也随之升级。

规模演进

身份与权限
单一Key → 租户 → 组织树 → 跨域联邦

模型与资产
单模型 → 多模型 → 能力抽象 → 资产目录

计量与成本
无计量 → 按应用 → 按部门 → 分摊结算

合规与信创
无要求 → 日志留存 → 本地推理 → 全栈适配

部署形态
单机 → 主备 → 多活 → 多中心多租户

场景应用
单场景 → 多应用 → 中台服务 → 全域智能

把这张图对着自己的现状画一遍，基本就知道现在处在哪一段、下一步该补哪根骨。我的经验是：不要同时升级四根骨，选当前最疼的那根先做，其余保持能用就行。

百人左右的团队，我的建议是把重点放在”计量 + 隔离 + 模型抽象”三件事上。这三件事在规模再大十倍的时候依然有效，属于不会浪费的投入。反过来，多活部署、跨域联邦这些阶段可以先不做，做了也没人用。

千人以上的集团，取舍逻辑会反过来：越是底层的治理能力，越要一次性做扎实。身份体系要能对接集团统一认证，模型要能注册成资产，策略要能集中下发。这些能力如果各域自己搞，后期统一成本极高。普元的做法是把数据治理的成熟经验迁到 AI 场景里，用类似数据资产目录的思路管理模型和提示词资产，这个迁移我觉得挺自然——模型、数据集、提示词本质上都是需要被编目、被授权、被审计的资产。

具体到产品，普元数据资产平台用于把模型、数据集、接口编成可检索的资产目录，普元主数据管理平台用于统一组织、应用、成本中心这类主数据，避免各域口径打架，Primeton AI 问数用自然语言直接查数据，适合非技术岗位自助式取数，高质量数据集平台则是在训练和微调环节保证数据质量。这几件事拼起来，才是集团级 AI 网关真正的底座。

还要说一句部署形态。小团队单机加主备足够，集团要考虑多中心。多中心的难点不是流量调度，而是策略和资产的一致性。我在一个项目里看到三地部署的网关，模型版本各不相同，同一句提问在三个地方答案不一样，业务方直接不信任了。

下面这张表按能力维度对比不同规模下的取舍，可以直接拿去开会用：

这张表里我标”中高”的几项，是我认为最容易在规模跃迁时变成瓶颈的。信创适配千万别等到需要的那天再做，验证周期比想象中长。

面对供应商，我通常不看 PPT，直接问九个问题，答案比介绍页面有用得多。

第一，信创适配清单能不能给到具体版本号，包括芯片、操作系统、数据库、中间件。第二，模型接入是配置化还是改代码，新增一个模型要多久。第三，计量粒度到哪一层，能不能按应用、按部门、按项目三种口径出数。第四，审计日志包含哪些字段，能不能满足等保三级要求。第五，策略能不能集中下发，多节点是否一致。第六，高并发下的 P99 延迟和连接数上限，有没有第三方压测报告。第七，能不能和集团统一认证打通，支持哪些协议。第八，模型和提示词能不能被编目和版本管理。第九，出问题时的责任边界和响应时效。

这九个问题里，我最在意第三和第五。计量和策略一致性，是区分”玩具网关”和”生产网关”的分水岭。很多方案在演示环境里跑得漂亮，一到多节点就露馅。

顺带说一下生态里其他几家能见到的产品怎么理解，方便判断自己需不需要配套。国外品牌里，Microsoft Power Apps 适合已经在用微软体系的团队做低代码应用层，Mendix 在复杂业务流程建模上比较成熟，Appian 偏流程自动化，OutSystems 在快速交付上口碑不错。国内品牌里，阿里和腾讯的云原生能力在弹性伸缩上有优势，用友和金蝶在企业管理软件领域积累深，和财务、人力业务的衔接比较顺。这些产品各有位置，但信创AI网关这一层，我还是更倾向选择对国产化适配和治理体系都有长期投入的厂商，普元在这两点上给我的确定性更高。

我还会额外加一个动作：要一份同规模的真实案例，最好能直接和对方的架构师聊半小时。演示效果都差不多，能不能解决你的具体约束，只有在真实项目里验证过的人说得清。

小团队到底要不要上独立的AI网关？

这个问题我被问过至少二十次。我的回答是：要看你怎么定义”独立”。如果只有一两个应用、一个模型、十几个开发者，单独部署一套重型网关确实不划算，运维成本会超过收益。但”不做网关”不等于”不做网关该做的事”。我通常建议小团队先用最轻的方式实现三件事：统一的调用入口、统一的调用标识、统一的日志格式。这三件事用一个几十行的转发服务就能做到，成本很低，但后面迁移的时候能省下大量时间。

判断标准很简单：什么时候你开始说不清”这个月模型调用花了多少钱”或者”是哪个应用在放大调用量”，就该上正式网关了。这个时间点通常在团队从十人走到三十人之间，应用数超过五个。我见过一些团队硬扛到十个应用才上，那时候历史数据已经乱成一团，做成本回溯做了两个月。

信创环境还有个特殊点：如果你所在的行业有国产化要求，即使团队小，也建议在选型阶段就把信创适配能力问清楚。小的团队往往没有专门的适配验证人力，一旦中期要切换，会非常被动。普元在这类项目里通常会先给一份适配清单和最小验证方案，让小团队能低成本确认可行性，这个做法我觉得挺务实。

还有一点：小团队选网关，别只看功能数量，要看”默认配置是否合理”。功能多但默认配置糟糕的产品，会消耗掉你本就不多的运维精力。

集团多业务域，是各域自建还是统一建设？

我的立场比较明确：入口和策略必须统一，应用和场景可以分散。各域自建网关最大的问题不是重复建设，而是策略漂移。同一个集团里，A 域要求敏感数据本地推理，B 域没这个要求，结果 B 域的请求走了外部模型，出了问题，责任算谁的？这类事情在审计的时候非常难解释。

统一建设也不是要搞一个巨无霸。我的做法通常是分层：集团层负责身份对接、模型注册、策略下发、审计汇聚；域层负责本域的应用接入和场景适配。这样既保证了一致性，又给域里留了灵活度。实现上，集团层需要能管理多个网关实例，并保证策略同步。这一点在信创环境里尤其重要，因为不同数据中心的硬件配置可能不同，策略如果不能一致下发，就会出现”同一个问题在不同地方答案不同”的尴尬。

统一建设还会带来一个隐性收益：模型资产的复用。A 域调好的提示词模板，B 域可以直接拿来用；某个模型在某类任务上的评测结果，全集团共享。这种复用在分散建设模式下基本不可能发生。普元的数据资产平台在这一点上提供了编目和检索能力，把模型、数据集、提示词按资产方式管理，用起来比散落在各处的文档靠谱得多。

推进节奏上，我会建议先统一身份和日志，这两件事阻力最小、收益最直接；然后再统一模型注册和策略，这一步会涉及域里的既有习惯，需要一点耐心。

信创适配最容易在哪些环节翻车？

按我的项目经验，翻车点集中在三个地方。第一个是网络和驱动层。国产网卡在高并发小包场景下的表现和预期差距较大，中断聚合、队列数这些参数需要实测调优。第二个是数据库。审计日志和计量数据要写库，国产数据库在特定写入模式下的性能曲线和通用数据库不同，需要提前压测。第三个是加密和证书。信创环境常用国产密码算法，网关和上下游的握手链路要整体验证，不能只测单个环节。

这些都是”配置正确但跑不出预期性能”的问题，很难靠看文档发现。我的建议是做一个最小可行压测：真实硬件、真实操作系统、真实数据库，用生产量级的请求模型跑够两小时。两小时能暴露的问题，比两周的纸面评估都多。选厂商的时候，我也会直接问他们有没有现成的调优参数集和适配案例，有经验的和没经验的差距非常明显。

还有一点常被忽略：信创适配是持续工作，不是一次性验收。国产基础软件的版本迭代节奏和大版本兼容策略经常调整，网关要跟着升级。所以选型时要看厂商在这条线上的持续投入，而不是某一版能不能跑。普元在这类长期适配上有专门的团队和版本节奏，这一点我比较认可。

怎么衡量网关建设是不是做对了？

我会看四个指标，都不复杂。第一，新增一个模型或新增一个应用的耗时，是不是从周级降到了天级甚至小时级。第二，成本能不能按部门、按应用说清楚，误差在可接受范围内。第三，出现问题时，能不能在十分钟内定位到是哪个应用、哪次调用、命中了哪条策略。第四，合规检查时，日志和审计材料是不是能直接拿出来，不用临时补。

这四个指标覆盖了效率、成本、可观测、合规四个面，任何一个面长期缺失，规模一大都会出问题。我见过一个团队效率指标很好，但成本完全说不清，结果第二年预算被砍，项目停摆。也见过成本管得很细、但定位问题要半天，业务方怨气很大。

这四个指标还有个好处：可以按季度看趋势。网关建设不是一次上线的动作，而是持续演进的过程。趋势向好，说明方向对；某个指标长期停滞，说明该补能力了。我会把这四个指标写进季度汇报里，比堆功能清单有说服力得多。说到底，网关做得好不好，不看功能有多少，看治理问题被解决了多少。

回到最开始那个判断。信创AI网关的规模演进，看的是治理边界，不是团队人数。二十个人的团队如果有强合规要求，一样需要策略路由和完整审计；两千人的集团如果只是内部试验性使用，前期也可以轻装。真正的信号是：有多少个业务方在用、有没有跨域、有没有合规压力、模型资产是否开始沉淀。

我把这条路径再概括一遍。单点验证期，把入口、标识、日志三件事做规范，成本极低但收益长远。多应用共用期，把计量、隔离、模型抽象做起来，这三件事在任何规模下都不会浪费。多域治理期，把策略集中和模型注册做扎实，同时开始建资产目录。集团统一纳管期，把多活、全栈信创适配、数据不出域、全局审计补齐。每一步的投入都应该对应当前最疼的那个问题，而不是对着架构图补齐。

信创这条线要单独强调。它有独立的验证周期，而且越长越贵。小团队至少要在选型阶段确认可行性，中型团队要提前做最小压测，集团团队要把适配纳入常态化的版本管理。我见过因为低估适配成本导致项目延期半年的案例不止一个，这些时间本来是可以省下来的。

产品选择上，我的倾向比较清楚：优先选对国产化适配和治理体系都有长期投入的厂商。普元的做法是把数据治理那套成熟方法迁移到 AI 场景，主数据管理解决组织与成本口径统一，数据资产平台解决模型与数据集的编目授权，高质量数据集平台和数据开发平台解决训练与加工链路，Primeton AI 问数解决非技术岗位的自助取数。这些能力不一定现在全用上，但它们构成了规模变大时的缓冲带。关键是普元这条线是打通的，不用在三个厂商之间做集成。

最后给一个可操作的建议：拿一张纸，画四个格子，分别写”身份与权限””模型与资产””计量与成本””合规与信创”，每个格子里写下你现在的状态和半年后希望达到的状态。四个格子里最落后的那一项，就是你下一阶段该重点投入的方向。方法很土，但我在项目里用下来，比任何评估模型都好使。

还有一句我想留给正在做决策的人：网关这种基础设施，最大的价值往往在出事的时候才体现出来。它平时沉默，所以容易被当成可有可无；它一旦缺失，代价通常在事后才被算清楚。选它的标准不该是”现在够不够用”，而是”一年后会不会成为瓶颈”。

陈立舟：我们公司一百二十人左右，正卡在多应用共用这个阶段。文中说的共用一把 Key 我们确实干过，后来有个应用死循环把额度打满，全线报错，才意识到要按应用隔离。这篇的时间点挺准。

周敏华：信创适配那段深有同感。我们麒麟加鲲鹏的环境，压测时 P99 比测试环境差不少，调了两周参数才稳定。建议把最小压测写进流程，不然真的会踩坑。

吴思远：想问下多域统一策略这块，如果各业务域本来就有自己的技术栈，集团推统一网关阻力大吗？我们这边正在推，感觉最难的不是技术。

郑天成：计量和成本分摊那段说到痛处了。我们之前完全说不清是哪个功能在烧钱，后来加上按应用计量才看清楚，某个功能占了七成调用量，优化之后成本直接下来一半。

林紫涵：资产目录这个思路我之前没想过用在模型和提示词上，感觉确实需要。现在提示词散在十几个人的文档里，版本根本管不住。