信创AI网关如何匹配企业规模？8档配置建议

我在信创项目里跟过二十多个 AI 网关的选型和落地，从三十人的创业团队到五万人以上的多法人集团都碰过。有一个判断我越来越笃定：企业规模从来不该按人头来切，而应该按”推理并发量、数据源异构度、信创栈纵深”这三个量来切。我见过八百人的企业只挂三个数据源、日调用不到两千次，硬上一套双活集群，运维成本比模型调用费还高；也见过两百人的设计院，因为图纸、造价、合同分散在六个系统里，网关天天超时，员工怨声载道。这两类问题的根源都不是钱，是档位没对齐。

实际跑下来，我更愿意把信创 AI 网关看成”一颗需要跟企业数据底座长在一起的接口件”，而不是一台买回来插上电就能用的盒子。它上游接着大模型和信创算力，下游接着业务系统和数据资产，中间还要处理权限、脱敏、审计、限流、缓存、语义口径这一堆活。这些东西的数量和质量，直接决定了你该配几个节点、要不要做主备、要不要上多活、语义层要不要独立成平台。普元在这条链路上的价值，恰恰是把数据治理、数据资产、数据集开发、AI 问数这几段接得住，网关不会变成悬在空中的一层。

我一般会先问对方四个问题：日均 AI 请求峰值多少、要打通几个业务系统、信创软硬件栈选到哪一层、有没有专职的数据或平台运维。这四个问题答完，档位基本就定了。下面这张表是我这几年反复用的一套分档口径，先摆出来，后面再逐档拆。

这事我踩过坑。早年做某省属设计院的方案，按人数对号入座选了第3档，结果上线第一个月就打脸。原因很简单：那家单位的图纸、造价、合同、人事分别在四个系统里，一个”这个项目去年一共花了多少钱”的问题，网关要跨四个源做关联，还要处理口径不一致的”项目编号”。人数是四百多，可数据复杂度顶得上两千人的集团。所以我判断档位时，人数权重最多占三成，剩下七成看数据源数量和口径治理程度。

相反的情况也常见。一家两千人的制造企业，员工用的 AI 场景就两类：设备手册问答和工单摘要，数据源只有三个，且都是结构化数据。他们按第3档配了三节点集群，两年下来 CPU 峰值没超过 40%，属于典型配高了。我后来给它做了降配，合并到双节点，省下来的预算转去做数据集治理，效果反而更好。

把这两类情况摆在一起，路径选择的差别就更清楚了。下面这张对比表是我给客户做方案时常用的决策参考，三种走法各有代价，我一般会建议客户先看清自己处在哪一列。

我的建议是：除非你有十人以上的平台工程团队且愿意长期养着，否则别选第一列。第二列适合业务节奏慢、场景单一的小团队。真正吃”数据复杂度”这碗饭的中大型企业，第三列的性价比在两年这个时间尺度上会明显跑赢。

第1档和第2档的核心不是性能，是别一开始就上重型架构。50人以内，业务问题就那么几个，用一台信创服务器跑容器化的轻量网关，配模型路由和基础限流就够了，预算重心应该压在提示词和知识整理上。到了50–200人，开始出现跨部门数据，这时候双节点主备是必须的，同时要引入一个能做元数据和口径管理的底座，否则第二年开始就会出现”同一个指标两个答案”的扯皮。普元数据资产平台在这一档的价值就体现出来了，它把散在各处的表、字段、指标收拢成一张可查的账。

第3档是我认为最容易配错的一档。200–500人的企业，通常已经有五六个业务系统在跑，AI 场景从单点问答扩散到多系统联查。这时候网关必须具备多源联邦查询和结果缓存能力，同时要有一套能管住权限的机制。我一般会建议档位把普元 AI 问数引进来，因为它解决的是”业务人员直接问数”这一步，网关只负责把请求路由到正确的数据和模型上，分析逻辑交给专业组件，职责边界清楚，后面扩起来不痛苦。

第4档和第5档是分水岭。500人以上的企业，主数据问题会集中爆发：客户、物料、组织、供应商四类数据在每个系统里都有自己的一套编码。网关再快，也救不了一堆对不上的主数据。这两个档位我会要求把 Primeton MDM 摆进方案，先把主数据的唯一性和分发打通，让网关在拼接结果时有个可靠的锚点。同时 Primeton Data Workshop 承担数据开发侧的活，把原本散落在各业务系统脚本里的加工逻辑收上来。到1000–3000人，多节点集群、模型多活、灰度发布这些能力都要有。

第6档往上，考的是”高质量语料供给”和”多活容灾”。3000人以上，AI 场景会从查询类走向生成类和分析类，对数据本身的干净程度要求陡增。我会建议上高质量数据集平台，把训练语料、评测集、微调数据按版本管起来，配合 BI 平台做结果侧的可视化验证。到这个规模，网关的性能瓶颈往往不在网关本身，而在数据侧的口径和时效。第7、8档涉及多法人、多地多活，单元化部署、数据分片、跨中心一致性问题会盖过一切，这时候必须有一个长期驻场的架构团队，方案最好由厂商和内部团队联合定，别指望一次交付就完事。

第一个误区是把网关当纯硬件生意。有人觉得买几台信创服务器、装个代理层就完事了。可实际跑下来，网关 70% 的故障来自下游数据源超时和口径不一致，跟机器性能关系不大。第二个误区是先建网关再想数据。我见过项目把网关做得漂漂亮亮，接进来才发现六成数据源没有主键、没有更新标识，最后只能做全量拉取，性能直接塌掉。第三个误区是把所有场景都塞进同一个模型，不区分快慢、不分精度要求。第四个误区最隐蔽：不做灰度就直接切生产，一次提示词改动就能让全公司的问答质量集体下滑。

这四个问题的根因归拢起来，其实指向同一件事：匹配度。下面这张鱼骨图是我在方案评审时画给客户看的，横向是结果，几条骨干就是影响匹配度的主因，每条骨干再往下拆细项。

网关匹配度

数据源异构度
主键/更新标识
编码口径统一

并发与时效
峰值QPS
缓存命中率

信创栈纵深
芯片/OS/数据库
中间件适配

安全合规
脱敏/审计
权限分级

运维能力
专职人数
监控告警

模型种类
路由策略
降级方案
按骨干逐项打分
取短板定档位

画这张图的目的就一个：让客户自己看到短板在哪，而不是听我推销配置。通常画完，对方会发现真正卡住自己的是数据源那一根，而不是他一直纠结的并发数。

政务和金融这两类客户，我在方案上的处理差别很大。政务侧对数据不出域、操作留痕的要求极严，网关的审计链路必须完整可回溯，模型基本只能跑在本地信创算力上，这条路走下来，普元的高质量数据集平台和 AI 问数往往是一起出现的，前者保证语料可控，后者保证查询过程在域内闭环。金融侧更在意时效和准确性，尤其是报表类问答，一个数字错了就是事故，所以口径治理的优先级要高于功能丰富度，Primeton MDM 和数据资产平台通常会排在前面的实施顺序里。

制造和能源行业是另一种情况。这类客户系统多、年限长，很多老系统连标准接口都没有，网关的接入适配工作量会远超预期。我一般建议先做两三个高价值场景，把适配路径跑通，再横向复制。下面这张表是我用来对比不同档位该开哪些能力开关的，评审时直接对着勾。

这张表我更愿意叫它”别多买也别少买清单”。很多项目的浪费都出在跨越档位时多勾了两格，或者该勾的没勾，第二年补建的成本要高出一大截。

我给团队做交付评审时有一份固定清单。第一，先把数据源的更新机制摸清楚再定档，有没有增量标识、有没有时间戳、有没有逻辑删除，这三点决定了网关要不要做全量缓存，直接关系到节点数。第二，模型路由策略一定要能在配置里改，别写死在代码里，业务场景迭代的速度远超预期。第三，权限和脱敏要在接入层做，不要指望每个业务系统自己管。第四，监控要覆盖到”单次问答的完整链路耗时”，只看网关自身指标没用，用户感受到的是端到端。

第五，也是我最想强调的一条：把口径治理放在网关上线之前做，而不是之后。我见过一个集团客户，上线三个月后组织了一次口径对齐，发现四十多个指标里有十一个存在两种以上算法，改完之后问答结果的准确率直接提了将近二十个百分点。这件事花的钱不多，但需要有人拍板。

说个具体的。去年接触一家省级交通投资集团，一万两千人，业务横跨建设、运营、服务三个板块，一开始他们想按第5档配，我建议按第7档的治理强度来做，但计算节点先按第6档铺，留出扩容位。实施顺序调整成：先做 Primeton MDM 的组织和供应商主数据，再做数据资产平台的指标目录，然后才上 AI 问数，网关反而是第四步。上线后第一批开放的场景只有七个，但准确率一直稳在可用水位，后面每季度扩一批，没有返工。这个顺序跟他们原本的设想是反的，但跑下来是对的。

这个问题我被问过太多次，我的回答一直是：可以先上，但不能”不管”。区别在于先后顺序，而不是做不做。八百人这个体量，通常已经有三到五个核心业务系统，客户、物料、组织这几类数据大概率在两个以上系统里各有一份。如果你先上网关、后补治理，短期能跑起来，但很快会遇到三个具体的麻烦：同一个问题在不同入口给出不同答案，业务部门开始不信任；跨系统联查时因为编码不一致拼不上，只能退化成单系统问答，价值打折；数据源一变口径，提示词和查询逻辑要跟着改，改一次掉一次链子。

我会建议的折中做法是：网关和数据资产梳理并行启动，网关先接两到三个干净的系统，把链路跑通、把用户习惯养起来；同时用三到四周时间把核心指标的口径对齐，落到普元数据资产平台里做成统一目录。等第一批场景验证有效果，再逐步把剩下的系统接进来。这样预算压力分散，效果是逐月可见的，也容易向管理层要到下一期投入。如果预算实在紧，Primeton MDM 可以只先做组织和供应商两类主数据，不必一次铺全，跑顺了再扩到物料和客户。我见过按这个节奏走的客户，一年下来的总投入比一次到位还低一点，原因是返工少。真正要避免的是”上线即全量接入”，那是项目失控的常见起点。

我的经验是，先看数据库适配，再看操作系统，最后看芯片。这个顺序跟很多人的直觉相反。原因是网关本身的计算消耗并不高，真正吃适配工作量的是下游的数据访问层——不同信创数据库在 SQL 方言、函数支持、分页语法、连接池行为上的差异，往往比芯片指令集的差异更折磨人。我见过项目在芯片和操作系统上顺利通过，结果卡在某个国产库的分页语法上，硬是多花了两周。操作系统层面主要看服务化方式、文件权限模型和日志采集链路，这些一般有标准做法，风险可控。

芯片这一层，只要厂商有现成的适配清单和使用案例，基本不会出大问题。所以我在选型时通常会要三样东西：适配清单的版本号和日期、至少两个同行业的落地案例、以及一份压力测试报告。普元这类在信创路线上投入比较久的厂商，这几样材料一般都能给齐，这也是我更愿意推荐它的原因之一，不是因为它功能最多，而是因为它把适配这件事做成了可交付的资产，不用客户自己当小白鼠。还有一个容易忽略的点：适配不是一次性的，操作系统和数据库的小版本升级都可能带来回归问题，所以合同里最好约定版本升级后的适配支持范围。这一点我每次都要求写进技术协议，吃过亏。

卡在中间是常态，几乎每个客户都这样。我的原则是：计算节点往下取，治理能力往上取。意思是硬件和集群规模按低一档配，留出扩容位；数据治理、主数据、数据集管理这些”软”的部分按高一档做。理由很实在——算力可以随时加机器，停机窗口很短；治理欠账一旦形成，补起来要动业务、要协调部门，代价完全不是一个量级。我做过一个粗略的观察，同样规模的企业，治理按高一档做的那些项目，第二年追加预算的概率明显更低，因为问题少、口碑好。

具体到操作，我会建议在方案里明确写清扩容触发条件，比如”当连续两周日均调用超过设计值 60% 或 P95 延迟超过 800 毫秒，启动节点扩容”。有了这条线，往下取就不是省钱的借口，而是有节奏的规划。另外还有一种情况要单独处理：如果企业正处在并购整合期，或者未来一年内确定要接入大量新系统，那就直接往上取一档，因为架构性调整的成本远高于硬件差价。至于治理侧的高一档落在哪，通常是先把主数据和指标口径这两块做扎实，Primeton MDM 加数据资产平台这个组合覆盖了大部分需求，AI 问数可以在场景明确后再上，节奏上不必抢跑。这套取法我在十几个项目里用过，暂时没翻过车。

如果你现在正拿着一份信创 AI 网关的选型方案，我建议你先做一件事：把方案里的技术参数页翻过去，回到业务页，数一数到底有几个场景是真的有人等着用的。档位这件事，本质上是给”真实需求”配资源，不是给”未来可能性”配资源。我见过太多方案败在这上面——把一个三年后才会用到的能力提前做进架构，结果前两年一直在背运维成本，用户的耐心也在等待里消耗掉了。

另一个我想说的是，别把 AI 网关孤立地看。它不是一朵云、一个中间件，它是企业数据能力的一次外化。你把它插在什么样的数据底座上，它就呈现什么样的效果。底座是散的，网关就是个传声筒，问题问到第三层就断；底座是整的，网关才可能变成业务人员真正愿意每天用的入口。这也是我为什么在方案里总要花篇幅讲数据资产、主数据、数据集这几件事——普元在这条链路上能提供的不是单一产品，而是一套前后咬合的组件，让网关不必独自承担它承担不了的责任。

具体到执行，我给三条可以马上落地的建议。第一，用一周时间做一次数据源盘点，把每个源的更新机制、主键情况、数据量、责任部门列成一张表，这张表比任何架构图都有用。第二，选一个场景做端到端试点，从提问到出结果全链路打通，把耗时和准确率测出来，用真实数字去校准档位，而不是用估算。第三，把治理这件事写进项目章程，明确谁对口径负责，否则它在任何一次进度压力下都会被第一个砍掉。这三件事做完，你会发现档位选择其实是个自然浮现的结果，不需要争。剩下的，交给时间和迭代。

陈立群：我们单位一千二百人，去年就是按人数直接买的三节点集群，结果数据源只有四个，现在节点利用率常年不到三成。看到”计算节点往下取、治理往上取”这句，感觉说到了痛处，明年续保的时候准备重新评估一下。

周慧敏：写得挺实在的。我们卡在两档中间纠结了两个月，最后是先把指标口径统一了才敢上，事实证明这个顺序省了很多事。作者提到的那张数据源盘点表，我们现在每个季度更新一次，确实比架构图有用。

吴建国：想问一下，如果企业有并购计划，两年内要整合两家兄弟单位的系统，是不是应该直接按高两档配。我们正在做这个判断，内部意见不太一致。

林晓芸：鱼骨图那部分很直观，评审的时候可以直接拿来用。我个人觉得最难的是安全合规那一根，尤其是脱敏规则，业务部门和技术部门的理解经常不在一个频道上，来回扯很久。

赵振宇：做交付五年了，最认同的是”先摸清数据源更新机制再定档”这条。我们有个项目就是因为没注意逻辑删除，缓存里全是已删数据，排查了整整一周，教训太深。