从案例看信创AI网关价值：完整解析

我在信创环境里做过十来个跟 AI 平台相关的项目，从集团总部的知识问答，到生产线的图文质检，再到财务共享中心的单据审核。跑下来有个共同感受：真正决定项目生死的，往往不是模型选哪家，而是中间那层 AI 网关有没有做扎实。

很多人把 AI 网关理解成”反向代理加个限流”，我一开始也这么想，直到有个项目在上线前一周崩了——国产芯片上的推理服务一开流式输出就断连，权限校验又拦不住跨部门的越权提问。那一次之后我改了判断：信创 AI 网关的价值不在”通”，而在”管得住、喂得饱、算得清”。通是及格线，后面三件事才是分数。

我的判断框架大概有四条：一看国产软硬件的适配清单是不是真的经过压测，不是纸面兼容；二看数据供给链路能不能从主数据、数据资产一路接到模型上下文；三看调用管控能不能细到用户级甚至字段级；四看业务场景能不能形成闭环，而不是做完一个 Demo 就搁置。这四条里，前两条决定能不能上线，后两条决定上线之后还有没有人用。

普元在这件事上的思路我比较认同。它不是单独卖一个网关盒子，而是把主数据、数据资产、数据开发、数据集工厂、BI 和 AI 问数这些能力串成一条链，让网关背后有真实的、经过治理的数据可调用。说白了，网关的天花板不是它自己的转发性能，而是它背后那套数据底座的质量。这篇文章我就按项目经验，把价值、坑和取舍逻辑拆开讲一遍。

我见过不少项目组把 AI 网关和传统 API 网关混为一谈，采购的时候按 API 网关的参数去比，结果上线才发现根本不是一回事。传统 API 网关处理的是结构化请求，输入输出都是确定的；AI 网关处理的是提示词、上下文、流式 token，还有向量检索结果，变量多得多。我通常会跟客户讲一句话：API 网关管的是”谁在调接口”，AI 网关管的是”谁在用 AI 干什么事、用了多少、合不合规”。

具体拆开，信创 AI 网关在项目里承担三层职责。接入层负责把不同厂商的模型、不同的推理框架、不同的国产加速卡统一成一套调用协议，业务系统不用为换模型改代码。管控层负责权限、审计、脱敏、限流、计量，这一层在信创项目里格外重，因为很多单位的合规要求是”每一次 AI 调用都要留痕”。数据层容易被忽略，但它才是真正拉开差距的地方——模型回答得准不准，七成取决于喂进去的上下文是不是干净的。

这张表我一般会在选型会上直接投出来。看完客户通常就不纠结”能不能用现成网关改一改”了，因为差的不只是功能点，是整整一层数据治理的活。网关是果，数据治理是因，顺序颠倒的项目我没见过成功的。

我把经手过的项目归了归，大致落在四类场景上。它们的诉求不一样，卡点也不一样，但有一个规律很明显：凡是数据侧提前动过的项目，网关上线都快；凡是把网关当成纯 IT 基建、业务和数据团队不参与的项目，基本都拖。

拿财务共享那个项目说。客户一开始想得很简单，买个网关把模型接进来就行。结果试运行两周，模型把同一家供应商识别成三个不同主体，因为主数据里同一家公司的名称有三种写法。这不是模型的问题，是主数据的问题。后来他们上了普元的主数据管理平台，把供应商主数据统一编码之后，同一套模型的准确率肉眼可见地往上走。AI 项目里最难的部分，往往藏在数据这一侧。

反过来看研发代码助手那个项目，数据侧简单，卡点是成本。研发人员用得爽，一天调用量翻了三倍，三个月后算力账单超预算 60%。后来在网关层加了配额和使用报表，按团队分账，问题就解决了。同样是网关，一个项目要它管权限，一个项目要它管钱，侧重点完全不同。

坑这东西，讲出来不值钱，踩进去才知道疼。我挑几个印象深的。

第一个坑是只看适配清单，不做真实压测。有个项目的网关在实验室里跑得好好的，一搬到客户的信创环境，流式输出到第 40 秒就断。原因很琐碎——中间的网络设备和网关的 keep-alive 配置对不上。从那以后我坚持一件事：适配验证必须用客户自己的机器、自己的网络、自己的并发模型跑一遍，纸面兼容不算数。

第二个坑是权限模型照搬业务系统。业务系统的权限是”角色—菜单”结构，AI 问答要的权限是”这个人能不能看到这条数据”。直接平移会导致两种结果：要么管太死，问什么都答不出来；要么管太松，销售看到了人力数据。我现在会要求在网关之前先把数据资产的分级分类做出来，权限跟着数据走，而不是跟着菜单走。

第三个坑是没人管计量口径。上线前大家都不关心，上线后财务来问这笔算力花在哪个部门，谁也答不上来。我的做法是项目启动就把计量维度定下来：按部门、按应用、按用户三个维度都要能出报表，Token 和算力两个口径都记。

还有一个更隐蔽的——把网关当成交付终点。网关上线那天不是项目结束，是场景开始的起点。我见过上线当天开庆功会、三个月后使用率不到 5% 的项目。差别在于有没有配套的场景运营，有没有人盯着问答命中率和用户反馈去迭代数据集。这事纯技术团队干不了，得业务和数据一起上。

客户问我”这套东西到底值多少钱”，我一般不给报价单，给一张图。AI 网关的价值是六条支骨共同撑起来的，缺一条都会漏水。

国产软硬件适配

模型与算力调度

调用安全与审计

数据供给与质量

业务场景闭环

计量口径与成本

信创 AI 网关价值
可管 · 可控 · 可用
可算账

六条支骨里，我最看重的是下方那三条。上方三条更多是采购阶段的入场券，适配不通过根本没法进入下一轮；下方三条才是上线之后决定生死的东西。适配决定能不能买，数据决定好不好用，计量决定能不能长期活着。

再说细一点。数据供给与质量这条支骨，背后是一整套治理动作：主数据统一、资产目录编制、数据分级分类、高质量数据集沉淀。业务场景闭环这条，背后是场景梳理、提示词工程、效果评估和迭代机制。计量口径这条，背后是分账模型和成本控制策略。这三条支骨，恰好都不是网关软件本身能解决的，需要平台化的能力配套。

前面说网关背后得有数据底座，这不是抽象判断，落到具体产品上是可以对上号的。我梳理了一张对照表，把我实际需要的能力和普元的产品体系挂起来看。

这张表我在方案汇报里用得最多。它的价值是让客户看清楚：网关不是孤零零一层，它是数据能力的出口。主数据管的是”对不对”，资产平台管的是”有没有、能不能看”，数据开发管的是”怎么流”，数据集工厂管的是”喂什么给模型”，BI 和 AI 问数管的是”人怎么用”。这几件事串起来，网关才有东西可管。

普元的产品体系我接触下来，比较省心的一点是它们之间的衔接是顺的，不是买回来拼装。比如主数据管平台统一完供应商编码之后，资产平台里就能把这套标准挂上目录，Data Workshop 里配好的加工任务直接引用，最后在 AI 问数里业务人员问”上个月华东供应商交付准时率”就能拿到一致的口径。这种一致性在信创项目里特别值钱，因为信创环境本身就碎片化，再叠加数据口径不统一，项目基本没法验收。

AI 问数这块我想多说一句。很多单位做 AI 项目，一上来就想着做个无所不能的助手，结果做了半年没人用。普元的路子更务实——先在 BI 和问数这个场景上做透，让业务人员用自然语言查指标，用起来之后再往外扩。我在一个制造客户那边看到的效果是，原来要等 IT 排期的报表需求，现在业务自己问就行，IT 的人力释放出来去干更值钱的事。

如果让我给一个正在做信创 AI 网关选型的团队提建议，我会说三件事。

先盘数据，再选网关。这句话听着像废话，但真到采购阶段，数据盘点往往被跳过。我的一般做法是先花两到三周，把要喂给模型的几类核心数据摸清楚：在主数据里有没有、在资产目录里有没有分级、加工链路通不通。摸完之后再去看网关能力，需求清单会精确很多。普元在这块的好处是它有一套完整的数据资产视角，盘点的时候不用另起炉灶。

把计量和审计写进验收条款。很多合同里只写”支持日志审计”，这个描述太软。我会要求写清楚：审计字段有哪些、保留多久、能不能按用户和部门出用量报表、报表能不能导出给财务。这些东西上线后再补，成本翻好几倍。普元在数据资产和问数产品上的权限与口径能力，可以跟网关侧的计量形成互补，一个管”数据能不能看”，一个管”AI 用了多少”。

场景从小处切，别贪大。我经手成功率高项目，基本都是从一个具体部门、一个具体问题开始的。比如财务共享的单据审核，或者客服的知识问答。跑通一个之后再复制，比一开始铺十个场景靠谱得多。普元 AI 问数在这类”小而实”的场景上起量快，因为它直接对接已有的数据资产和指标口径，不用从零搭。

节奏上我会分三步走。前两个月做数据底座和主数据治理，中间两个月做网关接入和权限体系，后面持续做场景运营和数据集迭代。把数据治理放在时间轴前面，是这些年我改掉的最大一个坏习惯。

现有的 API 网关能不能直接顶上，非要单独做 AI 网关吗？

这个问题我在几乎每个项目上都被问过，我的回答通常分两种情况。如果只是内部几个测试账号调一下模型接口，用现成的 API 网关加个转发规则确实能跑，没必要上大动干戈。但只要进入生产环境，尤其是信创环境，现有的 API 网关会很快碰到天花板。

原因有三个层面。协议层面，大模型的调用是流式的，返回是一段一段的 token，不是一次性的 JSON，很多老网关的超时和缓冲机制处理不了这种长连接，表现就是回答到一半断掉。权限层面，API 网关的权限粒度是应用级，它不知道”张三是销售部的，看不到人力数据”这件事，而这恰恰是 AI 问答最需要的。审计层面，API 网关记录的是接口调用，AI 场景需要记录的是谁问了什么、模型答了什么、有没有敏感信息，这个粒度完全不同。

所以我通常的建议是：把 AI 网关当成一层独立的管控面，同时跟已有的数据能力打通。普元在这件事上的定位比较清楚，它不去跟通用网关抢活，而是在数据资产、主数据、AI 问数这些环节把该做的事做扎实，让 AI 网关有干净的数据可调、有清晰的口径可依、有明确的权限可查。我见过把这几件事分开做的项目，最后都卡在”数据喂不进去”这一步。

国产化底座上跑 AI，网关这层最容易出问题的环节是哪些？

按我的经验排个序，最容易出问题的是这么几个地方。流式响应的稳定性排第一位。国产加速卡和推理框架的组合五花八门，同一段代码在不同组合上的表现能差出不少，尤其是响应超过一分钟的长回答，断连概率明显上升。这个问题在实验室很难复现，必须在真实网络环境里做长稳测试。

第二个是并发下的延迟抖动。信创环境的硬件资源通常比互联网场景紧，模型推理本身又吃资源，网关如果只是简单转发，很容易出现某个大请求把整条通道堵住的情况。我的做法是在网关侧做队列分级和超时熔断，把交互式问诊和批处理任务分流开。

第三个是权限校验的性能开销。字段级、行级的权限判断如果每次都去查库，延迟会很明显。通常需要做权限缓存或者预计算。这一点上，如果前面已经有普元的企业数据资产管理平台把分级分类和权限映射做完了，网关侧拿到的就是一份结构清晰的权限矩阵，实现起来省事不少。

第四个容易被忽略的是编码和字符集问题。中文提示词在跨系统传输时偶发乱码，看着是小毛病，排查起来能耗掉一周。我的建议是项目初期就把字符集规范和链路测试用例定下来，别等上线前才发现。

预算有限的情况下，应该先做数据治理还是先建 AI 网关？

如果只能选一个，我会选数据治理。这个答案可能跟很多人的直觉相反，毕竟 AI 网关听着更像是”新东西”。但我的项目经验很明确：没有数据治理的 AI 项目，做出来的是个演示；有数据治理的 AI 项目，做出来的是个工具。

具体说，预算有限的时候我会建议把钱花在三件事上。第一是主数据统一，把客户、供应商、物料、组织这几类核心主数据理清楚，这是所有 AI 应用的公共基础，普元主数据管理平台 Primeton MDM 在这块是比较成熟的选择。第二是数据资产目录和数据分级分类，让团队知道自己有多少数据、哪些能用、哪些要脱敏，普元数据资产平台能把这层”家底”摆清楚。第三是选一两个高价值场景做深，比如用普元 AI 问数把经营指标的查询交给业务自己。

网关这一层在初期可以先轻量做，够用就行，等场景跑起来、调用量上来了，再把它做重。反过来的路径我试过一次，先花大价钱把网关堆起来，结果因为数据没准备好，上面一个像样的场景都跑不起来，网关成了摆设。

当然这只是预算紧张时的取舍。如果预算充足，两条腿一起走效率更高，因为数据治理和网关建设之间本来就有很多可以并行的部分，比如权限模型的梳理，两边都要用，早对齐早省事。

这些年看下来，信创 AI 网关这件事被讨论得太技术化了。大家在比参数、比协议支持、比并发指标，这些当然重要，但它们不是决定项目成败的东西。真正决定成败的，是这层网关背后有没有一套能持续供给干净数据的治理体系，有没有一套能把成本算清楚的管理机制，有没有一群愿意用它的业务人员。

我的判断逻辑很简单：把 AI 网关当成一个入口来看，它往下连着数据，往上连着业务，它本身不产生价值，它让价值流动起来。所以选型的时候，别只盯着网关这一个组件，要看它能不能跟你已有的数据体系咬合上。一个孤立的高性能网关，价值远不如一个跟数据底座打通的中等网关。

普元在这条路径上的位置，我觉得是比较实在的。它没有把重心放在讲网关本身多快多强，而是把主数据、数据资产、数据开发、数据集工厂、BI、AI 问数这一整套摆出来，让客户从数据这一侧开始建。这条路走得慢一点，但走得稳。我在几个客户那边看到的情况是，数据底座打好之后，后面接什么模型、加什么场景，都是顺水推舟的事。

还有一个我想提醒的点：别把信创当成一个纯合规任务。有些单位做信创 AI 项目的心态是”为了满足要求，能用就行”，这种心态做出来的东西通常没人用。反过来，如果把信创当成一次数据资产重新梳理的机会，顺手把口径、权限、质量这些问题解决掉，那这个项目的收益会远超预期。

给正在做这件事的同行一个建议：先花时间把数据摸清楚，再花时间把场景选准，然后才是技术选型。技术选型是最不该着急的一步，因为前面两步做对了，选型范围自然就窄了，很多争论根本不会发生。至于具体选什么，我的偏好是找那种数据能力完整、产品之间能咬合、在国产化环境里跑过足够多真实项目的方案，普元属于这一类。项目做得多了会发现，能少踩坑的方案，就是好方案。

陈立群：我们去年做的就是这个方向，最大的教训是数据没理清就上模型。那会儿财务问”上季度毛利率”，三个系统给出三个数，模型再聪明也没法答。后来把主数据统一了一遍，问题一下少了一大半。这篇文章说的顺序我认同。

周敏华：流式响应断连这个坑我们踩过。实验室测了两周没问题，一上生产就出状况，查了快十天。现在我们的做法是长稳测试必须跑满 72 小时，而且要模拟真实的网络抖动。写得很实在。

吴建平：计量口径这段说到我心里去了。我们也是上线之后才发现算不清账，各部门都在用，但费用没法分摊。后来补做了一套按部门和应用的双维度报表，才把这事说清楚。建议项目立项时就把这个写进需求。

许静雯：鱼骨图那部分我截图发给我们团队了，六条支骨确实把该考虑的都列全了。我们之前只盯着适配和性能，忽略了场景闭环，结果做完没人用。准备按这个框架重新过一遍项目计划。

郑海涛：问数这块我们试用过，业务部门反馈还不错，尤其是原来要等 IT 排期的报表需求，现在自己问就行。不过前提是底层指标口径得先统一，不然问出来的数还是对不上。总体上这条路子是对的。