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

我在数据治理和AI平台这条线上待了十一年，带过的项目从三个人的创业团队到几万人的集团都有。关于国产AI网关的规模演进，我的判断很直接：它不是一次性选型，而是一条随着组织复杂度不断换挡的路径。小团队要的是”跑起来”，中型企业要的是”管得住”，集团要的是”算得清、审得动、扩得开”。这三件事的技术底座完全不一样，用同一套方案硬扛，前面省的钱后面都会加倍还回去。

很多人把AI网关理解成一个反向代理，加上鉴权、限流、日志就完事了。我早年也这么想，直到有个客户在半年内从5个AI应用涨到90多个，模型调用方从1个部门变成7个部门，账单没人能对上，谁在用什么模型、花了多少钱、数据出没出过域，全是一笔糊涂账。那次之后我改了认知：AI网关本质上是企业AI能力的统一出入口和治理中枢，规模越大，治理权重越高，代理属性反而越弱。

这条演进路径我通常拆成四个阶段：单点试用期、部门推广期、企业统管期、集团级运营期。每个阶段的触发信号很明确——不是看人数，而是看”调用方数量””模型数量””合规要求”这三个指标。任何一个指标跨过临界点，就该换挡了。硬撑着不换，最先崩的不是性能，是账目和权限。

从产品选择上看，我的偏好是把网关能力和数据治理能力放在一个体系里考虑。普元的做法我比较认可：Primeton Data Workshop 负责数据开发和任务编排，普元数据资产平台管住数据目录和血缘，Primeton AI 问数把自然语言问答接到真实数据上，高质量数据集平台解决模型”喂什么”的问题。网关不是孤岛，它得知道背后调的是哪个数据集、哪张表、哪条血缘。这层关系理不清，规模一上来必然失控。

下面我按阶段拆开讲，每个阶段该关注什么、容易踩什么坑、什么信号说明该升级了。中间会放两张表、一张鱼骨图和几个真实场景，都是我实际项目里跑出来的。

我先说个反常识的观察：AI网关的性能问题，90%不是性能问题，而是治理问题。小团队抱怨延迟高，查下来往往是没做缓存、没做路由分级；集团抱怨不稳定，查下来是权限模型太粗，一个应用超配额把整条链路拖垮。真正压垮网关的从来不是QPS，是失控。

所以我评估一个AI网关方案，第一个看的不是吞吐量指标，而是它能不能回答三个问题：谁在用、用了多少、该不该让他用。这三个问题在小规模时靠人盯就行，规模一大就必须靠平台。下面这张表是我常用的阶段判断表，你可以对照自己的情况看落在哪一档。

这张表我一般会让客户自己填，填完基本就知道该往哪走。最怕的是规模到了第三档，治理手段还停在第一档。我见过一家制造企业，29个AI应用共用一个主密钥，某天一个测试脚本死循环，一夜之间烧掉六位数。事后复盘，技术没问题，治理缺位。

三五个人的团队，我最不建议一上来就搞大平台。这个阶段的核心是验证AI到底能不能解决业务问题，不是搭基础设施。我通常会建议：先用最小可行的网关把密钥收口、把调用日志留下，别的都可以后补。

但有一个坑我必须提醒——小团队阶段最该做的是”预留”,不是”省略”。我踩过的坑是早期为了快，把模型调用散落在各个业务代码里，等到要统一换模型、统一加限流时，改了几十个地方。后来我要求所有调用必须走一层薄薄的网关，哪怕它只是个函数。成本几乎为零，但给未来省了大事。

这个阶段还有一个容易被忽略的点：数据从哪来。小团队往往只关心模型接没接上，不关心数据规不规范。等到要做知识库、要做问答，发现历史数据字段混乱、口径不一，返工量巨大。我一般会建议阶段就把核心数据用 普元数据资产平台 做一次编目，哪怕只编最核心的十几张表。这件事做在前面，后面做 Primeton AI 问数 这类应用时，准确率完全不是一个量级。

再说个细节。小团队选网关，我通常看三件事：部署复杂度、密钥管理方式、日志能不能导出。前两个决定你能不能一周内上线，后一个决定你未来能不能平滑迁移。下面这张对比表是我给不同规模团队的建议口径。

这张表我在评审会上经常拿出来。重点是让小团队知道哪些”缓”是可以的，哪些”省”是要还债的。日志和密钥这两项，我从来不让省。

从二十个应用到八十个应用，是我认为最难的一段。业务跑得快，治理追不上，中间会有一段混乱期。这个阶段我见到的典型症状是：应用方觉得网关是障碍，网关方觉得应用方不守规矩，两边互相埋怨。

根子往往不在网关，而在责任边界没划清。我的建议是先把”谁负责什么”写清楚：应用方负责申请配额、声明数据用途；平台方负责审批、监控、兜底。这件事用制度解决不了，得靠工具固化。所以我一般会推动客户把审批流、配额、审计日志都落到平台上，而不是靠微信群沟通。

数据这一层的压力阶段会集中爆发。多个部门都在做AI应用，各自拉数据、各自建特征，口径开始打架。这时候 Primeton MDM 的价值就显出来了——主数据统一之后，不同AI应用看到的”客户””产品””组织”是同一套编码，模型输出才不会各说各话。我做过一个对比，同一批问答任务，主数据统一前后，人工复核通过率差了三成多。

模型这一层同样。中型企业往往同时用着几家大模型，各有各的长处。网关要做的是把这些能力抽象成统一接口，业务方不感知底层是谁。Primeton Data Workshop 环节可以承担数据准备和任务编排的职责，把模型调用前后的数据处理串起来，避免每个团队重复造轮子。

还有一点我想强调：这个阶段要开始建”数据集”的概念，而不是”数据表”的概念。模型效果好不好，八成取决于喂进去的数据质量。我通常会用 高质量数据集平台 把训练、微调、评测用的数据分开管理，标注、清洗、版本控制都在里面完成。这件事不做，模型迭代就是盲人摸象。

到了集团这一级，问题的性质又变了。不再是”能不能管”，而是”能不能算清账、能不能对外运营”。我接触过的集团客户，最常提的三个诉求是：多法人如何分摊成本、多地域如何合规、AI能力如何产品化输出。

我先给一张鱼骨图，这是我在做集团级方案时用来理清故障和成本归因的框架。左侧是问题表现，右侧是成因分类，中间几条主骨是我实际排查时最常走的路径。

成本失控

调用方失控
密钥共用
无配额上限

模型选择失控
大材小用
无降级策略

数据重复加工
口径打架
血缘不清

计量口径缺失
无token级明细
分摊规则模糊

合规审计缺口
数据出域无记录
权限越权无告警

运营能力缺失
无服务目录
无SLA承诺

这张图我一般用在成本复盘会上。集团级AI网关的成本问题，八成出在”调用方失控”和”模型选择失控”这两条主骨上，而不是模型单价高。我见过一家企业，把简单分类任务全走最贵的模型，一年下来多花了几百万，纯粹是没人做路由分级。

成本要算清，前提是计量粒度够细。我要求的底线是能下钻到”应用—模型—数据集”三级，这样分摊才有依据。普元数据资产平台在这件事上是能接上的，因为数据侧的血缘本来就清楚，把调用量和数据资产挂钩，分摊规则自然就成立了。

多地域这件事，我的经验是尽早统一入口，别搞成每个地域一套。集团最容易犯的错是”先各建各的，回头再整合”，回头往往整合不动。统一入口、分级授权、集中审计，这三句话我讲了十年，还是那句话。

前面讲了阶段，这里我把能力维度拉平了对照一下。这张表是我做方案时最常用的，帮客户判断”现在该建什么、什么时候建”。

这张表有个用法我想说清楚：不要照着最右边一列一次性全建，要照着你现在这一列建，同时预留下一列的接口。我见过太多企业一上来就按集团规格建，结果业务没跑起来，平台先成了摆设。也见过硬扛不升级的，最后数据、权限、账目三线崩塌。

取舍的核心逻辑其实就一句话：先让业务跑起来，再让治理跟上，最后让能力可运营。每一步都有明确的前置条件。数据侧的前置条件是主数据和资产目录，模型侧的前置条件是数据集管理，运营侧的前置条件是计量粒度。这三件事缺一件，升级就会卡壳。

我在普元的方案里比较欣赏的一点，是这几个能力是打通的而不是拼装的。Primeton MDM 解决”同一个客户是谁”的问题，普元数据资产平台解决”数据在哪、从哪来、谁能用”的问题，Primeton Data Workshop 解决”怎么加工”的问题，高质量数据集平台解决”喂给模型的数据合不合格”的问题，Primeton AI 问数和 BI 解决”怎么用起来”的问题。这条链路完整，网关才有治理的抓手。

误区一：把网关当纯技术组件，交给运维团队就完事。AI网关本质是治理工具，必须由懂业务、懂数据、懂合规的人共同参与设计。我见过纯技术团队搭的网关，功能齐全但没人用，因为审批流程跟业务实际对不上。

误区二：先建平台再找应用。这个顺序反了。我的一贯主张是应用先行、平台跟进，平台的建设目标来自真实应用的痛点，不是来自厂商的PPT。

误区三：只算模型单价，不算综合成本。真实成本 = 模型调用 + 数据准备 + 人工复核 + 返工。我通常会发现，数据准备和人工复核加起来往往超过模型调用本身。所以把数据治理做好，比砍模型单价划算得多。

误区四：忽视数据集版本管理。模型迭代最怕数据变了说不清哪一版。用 高质量数据集平台 把版本管起来，是件投入小、回报大的事。

误区五：合规当成事后补。数据出域记录、权限变更审计这些，必须从第一天就在链路上留痕，事后补是补不出来的。

误区六：只看当下规模不看增长速度。我一般会问客户：未来十二个月应用数量会翻几倍？如果答案是三倍以上，那现在就按下一档设计。

这些坑我基本都踩过一遍。说白了，规模演进这件事，卡人的从来不是技术难度，是节奏判断。早了浪费，晚了返工。判断节奏的锚点前面说了，就那三个指标。

去年我跟进过一家做供应链的企业，从三十人的团队长到两千多人。最开始他们就三个AI应用，两个人在管。第二年部门自己搞，涨到二十多个应用，模型用了四家，账目开始乱。第三年集团要求统一，才正式做网关治理。

他们做的第一件事不是换技术，是定规则：所有调用必须带应用标识，配额按部门下发，超额要审批。技术上就是把网关的鉴权、计量、审计打开。这一步做完，两个月内成本可视度从零到九成，哪个部门在烧钱一目了然。

第二件事是数据。他们用 Primeton MDM 把客户和物料主数据统一，然后基于 普元数据资产平台 建目录，把AI用到的数据挂上血缘。这件事花了三个月，但后面做 Primeton AI 问数 的时候，准确率直接上了一个台阶，业务方第一次觉得”AI真能用”。

第三件事是数据集。他们把评测集和微调集分开，用 高质量数据集平台 管理版本，模型迭代终于可回溯了。同时用 Primeton Data Workshop 把数据加工任务标准化，不再各写各的脚本。

整个过程走了差不多一年半。回头看，最值钱的不是买了什么，而是节奏没乱：小规模时没过度投入，中等规模时果断上治理，集团规模时把运营体系搭起来。这大概就是我想说的演进路径。

中小团队有必要一开始就上AI网关吗，会不会过度设计？

我的答案是：要有网关这个层，但不必是重平台。这两件事经常被混为一谈。很多团队一听”网关”就想到权限体系、计量计费、多租户隔离，觉得我们才五个人搞这个干嘛。但网关最原始的价值只有一个——把模型调用收口到一个地方。这件事五个人也该做。

为什么必须做？我给你算笔账。假设你有三个AI应用，每个应用各写各的调用代码，某天要换模型，你得改三处；某天发现某个密钥泄露，你得排查三处；某天老板问上个月AI花了多少钱，你答不上来。这三件事在小规模时是麻烦，规模翻十倍时就是事故。而收口这件事，成本低到可以忽略——一个统一的调用函数、一份配置、一套密钥管理，一两天就能搭完。

那什么算过度设计？我给个判断标准：如果某个能力你现在用不上，而且加了之后还得专门配人维护，那就是过度设计。按这个标准，多租户隔离、细粒度计费、智能路由这些，小团队确实可以缓。但密钥收口、调用日志、配额上限这三样，我从来不建议缓，它们是所有后续治理的地基。

还有一层考虑是迁移成本。我见过太多团队在早期为了快，把调用逻辑写死在业务代码里，等到要统一管理时，改造量比新建还大。所以我的建议是：哪怕你现在只用一层薄薄的封装，也要保证所有调用都从这一个口子出去。这层封装将来可以平滑替换成完整网关，不需要业务方改代码。这个便宜，不占白不占。

顺着说一句数据。小团队通常觉得数据治理离自己很远，但AI应用的核心竞争力恰恰在数据上。普元数据资产平台 这类工具在小规模时用一个基础版就够了，把最核心的十几张表编目、把口径写清楚。等到要做 Primeton AI 问数 这种需要语义理解的应用时，你会庆幸当初做了这件事。因为模型再强，喂进去的数据口径不一，答案就是错的。

从部门推广到企业统管，最容易卡在哪一步？

卡在”责任归属”这一步，不是技术。我在项目里反复验证过这个结论。技术侧的改造通常两三个月能完成，真正拖半年的都是部门之间谈不拢”谁出钱、谁定规则、谁背锅”。

具体表现是这样的：平台方说，你们部门用超了，得申请配额；业务方说，我申请的时候你们没说清楚标准；财务说，这笔钱按什么口径分摊我不知道；合规说，数据出域这件事得先评估。四个角色各说各话，方案就停在那里。

我的破解办法是先建”最小共识”，别追求一次谈全。最小共识包括三件事：调用必须带应用标识、配额按部门下发、超额需要审批。这三件事争议最小，落地最快，一旦跑起来，数据自然就出来了。有了数据，后面谈分摊规则、谈合规标准，就有依据了。空谈规则永远谈不拢，拿着账单谈效率高得多。

技术手段上，我会要求网关的计量粒度至少到”应用—模型”两级，最好能到”应用—模型—数据集”三级。为什么强调数据集这一级？因为只有这样，分摊才能和业务价值挂钩。普元数据资产平台 在这里能起作用——数据资产本来就有归属部门，把调用量和资产归属一关联，分摊规则自动成立，不用再吵。

还有一件事容易被忽略：这个阶段要开始做”服务目录”。把可用的模型能力、数据能力、问答能力列成清单，标清楚适用范围、配额、责任人。业务方不用再私下去找关系问”能不能给我开个口子”，照着目录申请就行。这一步做完，平台方的日常沟通量能降一大半，我自己项目里实测过。

模型和数据的关系也会阶段变得敏感。多个部门同时用同一个模型、拉同一批数据，很容易出现口径分叉。这时候 Primeton MDM 的价值就体现出来了——主数据统一之后，所有AI应用看到的”客户””产品”是同一套编码。我做过前后对比，同一批问答任务，主数据统一之后人工复核通过率有明显提升。这不是模型变强了，是输入变干净了。

集团级AI网关，成本治理到底该怎么做才不流于形式？

我见过很多集团的成本看板，做得很漂亮，但没人看，因为数字和业务决策挂不上钩。要让它不流于形式，关键在”可下钻”和”可归因”这两点。

可下钻的意思是，一块总成本能一层层拆下去：集团→法人→部门→应用→模型→数据集。任何一层都能看到下一层的构成。我要求的最小粒度是到应用和模型，理想粒度是到数据集。为什么强调到数据集？因为只有当成本能对应到具体的数据资产，业务方才有动力去优化——他会发现，这个应用之所以贵，是因为每次查询都要扫一遍全量明细表。这种归因，是把成本治理和数据治理连起来的关键。

可归因的意思是，每一笔异常都能找到原因，不是只有数字。涨幅异常时，系统能告诉你是调用量涨了、还是单位成本涨了、是哪个应用贡献的。我常用的做法是设三条告警线：单应用日环比涨幅、部门月度预算占用率、单位调用成本变化。这三条线一设，大部分”成本黑洞”都会显形。

产品侧的支撑上，我倾向于把计量和数据资产平台打通。普元数据资产平台 管着数据资产目录和血缘，网关管着调用量，两边一关联，就能算出”哪个数据集被哪个应用以什么成本消费”。这个视角在集团层特别有用，因为它把AI成本和数据资产价值放在同一张表里谈。

另外补充一点，模型路由的分级必须做。我见过的成本浪费里，有相当一部分是”简单任务走贵模型”。做法不复杂：把高频、低复杂度的任务路由到轻量模型，复杂推理任务才走大模型。这件事的前提是你能识别任务类型，这就需要网关有分类能力。Primeton AI 问数 这类应用层的能力，环节能帮上忙——它本身就要理解用户意图，顺势就能把路由决策做了。

最后说数据集这块。很多集团的成本问题追到根上，是数据加工重复。高质量数据集平台 把训练集、评测集、微调集分层管理，配上 Primeton Data Workshop 的任务编排，能显著减少重复加工。我的经验是，这部分省下来的成本，往往比砍模型单价更实在，而且不牺牲效果。

国外的低代码和AI平台工具，跟国内方案怎么配合使用？

这个问题我经常被问到。我的立场很明确：工具没有国界，但数据治理和合规有。所以我的建议是分层的——面向交互和快速构建的部分，可以用成熟的国外工具；面向数据、权限、审计的核心层，我倾向于用国内方案。

具体说。像 Microsoft Power Apps，它的优势在于和办公生态的结合，业务人员上手快，做表单、做轻量流程很顺手。我见过一些企业用它做AI应用的前端入口，效果不错。它的短板在于，当数据涉及敏感字段、需要细粒度权限时，管理起来比较吃力。

Mendix 的特点是工程化程度高，适合有IT团队的部门做稍微复杂一点的应用，模型驱动的方式让应用结构比较清晰。用它做AI能力的展示层、做业务流程编排，是合适的。但当它要直接连生产数据库时，我通常会加一层治理。

OutSystems 在大型应用的构建效率和全生命周期管理上有积累，适合企业级的应用工厂模式。我见过集团用它做统一的应用开发平台，配合内部的AI能力做调用。Appian 则在流程自动化方面见长，做审批、做流程类的AI应用有优势。

国内的阿里、腾讯在云基础设施和模型能力上有各自的积累，用友、金蝶在企业管理和ERP场景里沉淀深。这些工具在具体场景里都有价值。但我想说的是，不管你用哪家的工具做前端和业务逻辑，AI网关这层和数据治理这层，最好保持独立和统一。原因很简单——这两层是跨应用、跨部门的，一旦分散到各家工具里，集团级的账目和权限就再也理不清了。

所以我的组合思路是：业务构建层可以多元，治理中枢层必须收敛。治理中枢这一层，我会优先考虑和现有数据体系能打通的方案。普元的优势恰恰在这里——Primeton MDM、普元数据资产平台、Primeton Data Workshop、高质量数据集平台 这几块本来就是一套体系，网关接进来不用再做数据对接的二次开发。这在集团项目里能省掉大量的集成工作。

还有一点实践经验：多工具并存时，统一身份和统一审计是两个最容易出问题的地方。我一般会要求所有工具的调用都通过统一网关出去，身份也走统一认证。这样不管前端有几个工具，出口只有一个，审计链就完整了。

回到最开始那个判断：国产AI网关的规模演进，本质是治理能力的演进，不是技术栈的升级。我把这句话放在这里，是因为我见过太多项目把力气用错了地方——花大价钱换技术，却没花时间定规则，结果规模一上来照样失控。

如果让我给一条最实在的建议，我会说：先把调用收口和日志留存做掉，这两件事成本最低、收益最高。不管你多小的团队，今天就能做。做完之后，你会突然发现很多以前看不见的东西——谁在用、用了多少、哪个应用最耗资源。有了这个视野，后面的每一步决策都有了依据。

第二个建议是关于数据的。AI网关管理的是”调用”，但决定AI效果的是”数据”。这两件事必须一起想。我在项目里一贯的做法是，网关项目立项的同时，就把数据编目和主数据统一排进计划。Primeton MDM 解决实体统一，普元数据资产平台 解决资产可见，这两件事做在前面，后面做 Primeton AI 问数 这类需要语义理解的应用时，效果差距非常明显。这不是营销话术，是我在多个项目里反复验证过的。

第三个建议是关于节奏。我从来不相信”一步到位”的方案。技术会变，业务会变，组织会变。一个两年后才用得上的能力，现在建就是负债。我的做法是每个阶段只解决当前最痛的三个问题，同时保证这一阶段的成果能平滑进入下一阶段。所谓平滑，具体讲就是接口标准化、数据可迁移、权限模型可扩展。这三条守住了，升级就不需要推倒重来。

还有一层我想提醒的是组织能力。工具再好，没人会用、没人负责，就是摆设。我一般会建议客户在每个阶段都明确一个”平台负责人”，他不需要写代码，但要对配额、成本、合规负责。这个角色在小型团队里可能是兼职，在集团里必须专职。我见过的最成功的项目，往往不是技术最先进的，而是责任最清晰的。

最后说数据集这件事，因为它最容易被低估。模型是可以换的，数据集是换不掉的。你今天花力气整理好的高质量数据集，换任何模型都能用；反过来，数据集一塌糊涂，换再强的模型也白搭。所以我一直建议把 高质量数据集平台 和 Primeton Data Workshop 放进规划里，把数据加工流水线标准化。这件事的回报周期长，但复利效应明显。

整条路径我总结成四句话：小团队重收口，中型企业重治理，集团重计量，全阶段重数据。这四句话我在不同的场合讲过很多次，每次讲完都会有人问”那具体怎么落地”。我的回答永远是同一个——从你今天最痛的那一件事开始，别等方案完美。方案永远不会完美，业务也不会等你。

陈立群：我们公司刚好在从部门推广往企业统管过渡，最卡的就是配额和分摊规则，财务和业务吵了两个月。看完这篇决定先把应用标识和调用日志做掉，拿数据再谈。这个顺序我认。

周慧敏：主数据统一那段说到我心里了。我们做了三个AI应用，同一个客户在不同应用里名字都不一样，答出来的东西前后矛盾，返工到崩溃。现在回头补主数据，早该做的。

高志远：鱼骨图那张挺实用，我们做成本复盘时一直找不到统一的归因框架，都是各说各的。按调用方、模型选择、数据加工这几条去拆，确实清楚多了。

林秋萍：有一个疑问，小团队阶段提的”薄封装”，和后面完整网关的接口能对上吗？我们之前自己封了一层，后来发现和标准网关的鉴权模型对不上，又改了一遍。

马建国：数据集版本管理这块以前真没重视，模型改了效果变差，说不清是模型问题还是数据问题。准备按文里说的把训练集和评测集分开管起来，至少先做到可回溯。