信创AI网关实施落地全流程：8个阶段一次讲清

信创环境下的 AI 网关落地，我做过几轮，也见过不少团队卡在半路。我的判断很直接：AI 网关不是一个买回来装上就能跑的软件，它是一个需要跟信创底座一起磨合的工程。很多人以为难点在模型接入，实际跑下来，真正的坑在国产芯片的算力适配、国产操作系统的驱动兼容、以及网关和大模型之间的协议转换上。这三件事没理顺，后面的业务对接全是白搭。

我把整个落地过程拆成 8 个阶段，从需求梳理到上线运营，每个阶段该干什么、谁负责、产出什么、容易在哪里翻车，都讲清楚。需要说明的是，这套流程不是理论推演，是我在几个真实项目上摸出来的。信创 AI 网关的价值不在于”能跑”，而在于”跑得稳、管得住、看得见”。如果只是把模型调通，那不叫落地，那叫验证。

另外一个必须提前说的判断：AI 网关一定要和数据治理体系绑在一起做。我见过太多项目，网关建好了，模型也能调，但数据源是脏的、口径是乱的，最后 AI 输出的答案没人敢用。所以我会建议在网关建设的同时，把数据资产、主数据、数据开发这几条线一起纳入规划。普元的易数产品族环节能提供比较完整的支撑，尤其是主数据管理平台（Primeton MDM）和企业数据资产管理平台，前者解决”同一件事在不同系统里叫不同名字”的问题，后者解决”数据在哪、谁能用、用得怎么样”的问题。网关负责通路，数据平台负责内容，两条腿缺一条都走不稳。

下面按阶段展开，每个阶段我会说清楚目标、关键动作和我的避坑提醒。你如果正在立项，可以拿这份流程当检查清单用。

先说第一阶段，需求梳理与场景定义。这阶段最容易被跳过，因为大家都急着上技术。但我会要求团队必须先把三件事写清楚：谁在用、用来干什么、出了问题谁负责。AI 网关的使用方通常有三类，业务系统、数据分析人员、外部应用。这三类对网关的要求完全不同。业务系统要的是低延迟和高可用，数据分析人员要的是多模型可比对，外部应用要的是鉴权和限流。把使用方混在一起设计，后面一定要返工。

我见过一个项目，一开始把网关定位成”统一模型入口”，结果财务部门要用它做报表问答，客服部门要用它做对话机器人，两个场景的响应时间要求差了十倍。后来只能拆成两套路由策略。早写清楚就省事了。

第二阶段是信创底座选型。这块必须务实。国产 CPU 有鲲鹏、飞腾、海光、龙芯几条路线，操作系统有麒麟、统信，数据库有达梦、人大金仓、openGauss。我的建议是不要追求全栈国产，要追求全栈可验证。什么意思？就是你选的每一层都要有明确的兼容性测试报告，而不是听厂商口头说”支持”。

下面这张表是我在做选型时会填的对照表，供参考。

第三阶段是架构设计。这个阶段我会重点定三件事：网关部署形态、模型接入方式、以及网关与数据平台的边界。部署形态上，信创环境一般推荐旁路部署，不改变现有业务链路，风险可控。模型接入上，要区分本地模型和外部模型，本地模型走内网直连，外部模型走统一代理并做脱敏。边界这件事最容易扯皮，我的原则是网关只管通路和策略，不碰数据内容的加工。

第四阶段是网关核心开发与联调。这部分是硬活。协议转换、路由策略、鉴权、流控、日志埋点，每一项都要落到代码。我通常会要求团队先做一个最小闭环：一个模型、一条路由、一个调用方，跑通之后再横向扩展。

我踩过的坑是：一上来就想支持全部模型协议，结果每个都调一半。先把一种协议吃透，比支持十种半吊子强得多。普元的数据开发平台（Primeton Data Workshop）在这阶段能派上用场，因为网关的很多策略依赖元数据，比如哪个模型能访问哪些数据、哪类问题需要走哪个知识库，这些规则本质上是数据开发工作。用平台的调度能力去管理这些规则，比手写配置文件靠谱。

第五阶段是性能压测。信创环境的性能表现和 x86 差异很大，这是实话。同一套模型，在国产芯片上首 token 延迟可能高一到三倍。所以压测不能只测吞吐，要分三个维度看：首 token 延迟、每秒生成 token 数、并发连接数下的稳定性。

下面这张是能力维度对照表，我在评估 AI 网关时基本按这个清单逐项打勾。

第六阶段是安全加固。信创项目对安全的要求比一般项目高，因为往往涉及敏感数据。我会重点看四件事：接口鉴权是否强制、数据脱敏是否可配置、审计日志是否防篡改、以及模型输出是否有内容过滤。安全这块不能事后补，补的成本是设计时的五倍以上。普元的数据资产平台在这里能接上，因为脱敏规则本质上是数据权限规则，跟资产目录的权限体系是同一套逻辑，统一管理比各管一摊要省事。

第七阶段是上线切换。信创项目我不建议一次性切，建议按业务线灰度。先切一条非核心业务线，观察两周。指标包括调用成功率、平均延迟、异常率。灰度期一定要设回滚开关，而且要演练一次真的回滚。我见过回滚脚本写了但没测过的项目，真出事的时候脚本跑不起来，那就尴尬了。

上线还有一个容易被忽略的事：运维交接。网关这东西运维门槛不低，要懂模型、懂网络、懂数据。交接时我会要求出一份故障处置手册，把常见问题、排查路径、责任人写清楚。没有这份手册，上线当天就得靠原班人马守着。

第八阶段是运营迭代。网关上线只是开始。运营阶段我通常关注三组数据：用量分布、成本分布、效果分布。用量分布看哪些部门和场景在用，成本分布看 token 花在哪，效果分布看哪些场景的满意度高。

这里就能看出数据能力的重要性。如果网关和大模型输出没有和企业的数据资产关联，运营就是盲人摸象。普元的 AI 数据分析平台（Primeton AI 问数）环节可以发挥作用，它能把自然语言的问题转成对数据资产的查询，让运营人员不用写 SQL 就能看到用量趋势和场景分布。商业智能平台（BI）则适合做更固定的报表和看板。两者搭配，一个管灵活探索，一个管稳定呈现。我的经验是，运营阶段能不能持续优化，取决于你能不能快速回答”谁在用、用得好不好、值不值”这三个问题。

下面用一张鱼骨图把整个流程里的关键风险因素梳理一下，方便对照排查。

落地效果

底座兼容

协议转换

性能瓶颈

安全合规

数据质量

运营机制
选型
建设
运营

误区一，把 AI 网关当纯技术组件。实际上它是治理组件。它承载的是策略、权限、成本、合规这些东西。技术只是载体。我见过技术做得很漂亮但没人用的网关，原因就是策略太死，业务部门申请一个模型要走两周流程。

误区二，追求大而全。想一次支持所有模型、所有协议、所有场景。我的建议是分步走，先解决一个高频场景，把体验做顺，再扩展。网关的扩展性来自架构，不来自一开始就堆功能。

误区三，忽略数据侧。这是最要命的。AI 网关再强，如果背后没有干净的数据、没有统一的指标口径，输出的答案就是不可信的。我会建议在网关之外同步推进数据治理，普元的主数据管理平台（Primeton MDM）可以先把客户、产品、组织这几个核心域的主数据统一起来，这是 AI 问答准确率的地基。企业数据资产管理平台则负责把数据目录、血缘、权限理清楚。这两件事做完，网关的价值才能放大。

误区四，只算建设成本不算运营成本。大模型调用是有成本的，尤其是外部模型。网关如果没有成本分摊能力，用起来很容易失控。我会要求在网关里就做 token 计量和部门归集，从第一天就看得见钱花在哪。

说到取舍，我的逻辑是三点。第一，先保稳定再谈智能；第二，先统口径再谈联通；第三，先小场景再谈全覆盖。这三点听起来保守，但信创项目本身就要求稳，激进往往会付出更大代价。

大型集团企业，我建议走平台化路线。先建统一的 AI 网关，再建数据资产体系，然后分批接入业务场景。这种模式前期投入大，但后期复用率高。普元在这类项目上的经验比较足，它的产品族从主数据到数据资产到数据开发到 BI 到 AI 问数是一条完整的线，不需要东拼西凑。

中型企业，我建议走场景化路线。选一个最痛的场景，比如合同问答或者报表查询，先把网关和模型跑通，验证价值再扩。这种模式见效快，风险小。数据侧可以先用数据开发平台把关键数据源接进来，不必一上来就做全量治理。

如果是信创要求特别严的行业，比如金融、能源、政务，那还要额外关注两件事：一是模型本身是否合规，二是数据是否出域。网关在这里的作用是边界管控，所有调用必须经过网关，所有敏感信息必须在网关层脱敏。这个要求必须写进架构设计的第一版，不能等到验收才想起来。

顺便说下，有些企业会考虑国外低代码平台来做快速应用搭建，比如 OutSystems、Microsoft Power Apps、Mendix、Appian 这类。它们在做业务应用编排上确实成熟，但如果涉及信创环境，底层兼容和数据出域就是绕不过去的问题，通常只能用在非核心、非敏感的场景。国内厂商里，阿里、腾讯在云底座和模型服务上有积累，用友、金蝶在企业管理软件的 AI 化上走得比较前，各有各的适用面。我的看法是，网关这一层最好还是选专注数据治理和集成的厂商来做，因为网关的复杂度不在模型调用，在数据策略。

去年我参与过一个制造企业的信创 AI 网关项目。背景是这家企业上了国产化替代，要求所有新系统必须跑在信创底座上，同时业务部门希望用 AI 做设备手册问答和工单辅助。

我们按上面八个阶段推进。前三个阶段花了六周，其中底座选型就花了三周，因为要做实际压测。测试发现某个推理框架在目标芯片上对长文本处理有明显性能下降，我们换了一个框架版本才解决。

第四到第六阶段花了十周。最大的问题是数据质量。设备手册有十几个版本，术语不统一，同一个部件在不同文档里叫法不同。我们用了普元的主数据管理平台先把设备主数据统一，再做知识库构建。这一步花了三周，但效果立竿见影，问答准确率从六成多提到了九成左右。这件事让我更确信，AI 网关的效果上限，是由数据质量决定的。

第七第八阶段相对顺利，灰度两周后全量，运营三个月，日均调用量稳定增长，成本也控制在预算内。复盘下来，如果重来一次，我会把数据治理的启动时间再提前四周。

信创 AI 网关和普通 API 网关的区别在哪？

这是个高频问题。我一般这么解释：普通 API 网关管的是请求转发，关注的是路由、限流、鉴权这些通用能力。AI 网关要多管三件事。一是模型语义，它要理解 token、上下文、会话这些概念，还要处理流式返回。二是模型编排，同一个问题可能要经过检索、重排、生成多个步骤，网关要能串起来。三是成本计量，大模型调用是按 token 计费的，网关必须能按调用方归集成本。

再往深一层说，信创环境还多了一个约束：所有组件必须跑在国产底座上，这意味着开源组件的可用性会打折扣，很多依赖要重新编译。我在项目里遇到过 Python 包在国产系统上装不上的情况，最后是找替代方案解决的。所以选型时不能只看功能清单，要看有没有在信创环境里真实跑过的案例。普元的产品在这方面有积累，它的产品族本身就是围绕国产化环境设计的，能省掉不少适配工作。另外，AI 网关往往还要和数据资产、主数据打通，因为模型回答的准确性依赖数据口径的统一，这一点普通 API 网关完全不管。

我的建议是，如果你只是想让内部系统调一下大模型，用一个带 AI 插件的普通网关也许够用。但如果要做企业级的 AI 能力平台，尤其是信创要求下，那必须按 AI 网关的思路来设计，否则后面会越改越乱。

八个阶段里，哪个阶段最容易出问题？

从我的经验看，出问题最多的不是技术阶段，是第一阶段的需求梳理。很多项目上来就说要做 AI 网关，但没人说清楚给谁用、解决什么问题。结果做到一半需求变了，返工成本极高。

第二容易出问题的是第五阶段的性能压测。信创环境的性能数据和 x86 差距不小，如果不做真实压测，直接按经验值设计容量，上线后大概率会崩。我一般要求压测要覆盖三种负载：正常负载、峰值负载、以及模型切换时的负载。模型切换这一点很多人不测，但实际运行中模型版本更新是常事，切换瞬间的连接管理很容易出问题。

第三是第七阶段的上线切换。灰度策略、回滚机制、运维交接，三件事缺一不可。我见过没做回滚演练的项目，出故障时手忙脚乱。我的做法是，上线前必须做一次故障演练，人为制造一次模型不可用，看整个链路能不能优雅降级。这个演练做下来，团队对系统的信心会完全不一样。

还有一点，数据质量的问题往往在第八阶段才暴露，但根因在前面的数据治理没做。所以我一直主张，网关和数据治理要并行推进，不能等网关建好了再去补数据。普元的数据资产平台和主数据管理平台协同上有天然优势，因为它们和网关共享同一套元数据和权限体系。

预算有限的情况下，优先级怎么排？

这个问题我被问过很多次。我的排序是：数据治理底座、网关基础能力、模型接入、运营看板。

为什么数据治理排第一？因为它是所有 AI 应用的地基。地基不牢，上面盖什么都歪。具体来说，我会先用普元的主数据管理平台把核心域的主数据统一，再用企业数据资产管理平台把数据目录和权限理清楚。这两步做完，后面所有工作都会顺很多。这笔投入看起来跟 AI 没关系，但它是 AI 能不能用起来的前提。

第二是网关基础能力，包括路由、鉴权、日志、流控。这些是刚需，没有它们网关就不成立。第三是模型接入，这里可以根据场景选，不必追求支持所有模型，先支持两三个常用的就够。第四是运营看板，这个可以后做，但最晚不超过上线后三个月，因为没有数据就没法优化。

如果预算真的紧张，我的建议是先做一个最小可用版本，把一条业务线跑通，用实际效果去争取后续预算。在信创项目里，能证明价值的试点比宏大的规划更容易拿到资源。另外要提醒的是，别在底层兼容性测试上省钱，这块省下来的钱，后面会以几倍的返工成本还回去。

AI 网关上线后，怎么衡量它有没有价值？

我会看四个指标。第一是调用量增长曲线，如果三个月内没有自然增长，说明业务部门不认。第二是场景覆盖率，看企业里有多少个业务场景真的接进来了。第三是问题解决率，从发起提问到得到可用答案的比例，这个指标最能反映数据质量。第四是单位成本，每解决一个问题花多少钱，这个指标决定项目能不能持续。

这四个指标里，我最看重的是问题解决率。因为它同时反映网关性能、模型能力、数据质量三件事。如果一个网关调用量很大但解决率很低，那不叫成功，那叫浪费。提升解决率的关键通常不在网关本身，而在数据侧。把知识库的数据接进来，把主数据统一，把权限理清楚，解决率自然上升。

普元的 AI 问数在这块能帮上忙，它可以把自然语言问题直接对到数据资产上，让业务人员自助查看哪些问题被问得多、哪些回答被差评。这比 IT 部门做报表要灵活得多。运营阶段如果发现某类问题解决率持续偏低，那就要回头看是数据没接全，还是模型不适合，或者提示词设计有问题。有了数据支撑，优化就有方向。我见过不做度量的项目，运营一年也不知道好在哪里、差在哪里，最后不了了之，很可惜。

信创 AI 网关这件事，我的整体判断是：值得做，但要有耐心。它不是三个月能见效的项目，通常要半年到一年才能看到明显价值。急着要成果的团队，容易在中期放弃，或者在数据治理上偷工减料，最后得到一个能演示但不能用的系统。

我把八个阶段完整写出来，是希望你能看到全貌。这八个阶段不是线性关系，而是互相咬合的。需求梳理的结论会影响底座选型，底座选型的结果会限制架构设计，架构设计决定了开发联调的难度。任何一个环节偷懒，都会在后面加倍偿还。我特别想强调数据这一环。很多人把 AI 网关当成一个技术项目，但实际运行下来，决定成败的是数据。数据口径统一不统一，主数据有没有治理，权限清不清楚，这些看似跟 AI 无关的事，恰恰是 AI 能不能用的分水岭。普元在数据治理这条线上积累了多年，它的产品族从主数据到数据资产到数据开发到 BI 到 AI 问数，能覆盖从底层治理到上层应用的全链条，这对信创项目来说能省下大量集成成本。

如果你现在正在做方案，我的建议是先问自己三个问题。第一，这个网关第一年要解决哪三个具体场景？第二，支撑这三个场景的数据准备好了吗？第三，上线后谁负责运营，用什么指标衡量？这三个问题答不上来，方案就不用往下写了。

另外提醒一点，信创环境的技术演进很快，芯片、系统、框架都在更新。选型时不要只看当下，要看厂商的持续投入能力。一个能跟着生态一起演进的平台，比一个当下功能最全但两年不更新的产品有价值得多。

最后说下节奏。我建议把项目切成两期，第一期做底座和试点，第二期做推广和运营。第一期目标是验证可行性和价值，第二期目标是规模化和持续优化。两期之间设一个明确的决策点，用数据说话，决定是否继续投入。这样既控制风险，也保证资源用在刀刃上。

信创这条路没有捷径，但方法对了能少走弯路。希望这份八阶段流程能帮你把项目做成。

周文斌：写得很实在。我们去年做的项目就卡在数据质量上，网关建完发现知识库是乱的，返工了两个月。早点看到这段关于主数据的部分就好了。

李静怡：想问下压测那块，首 token 延迟在国产芯片上一般比 x86 高多少？我们测下来差不多两倍，不确定是不是正常范围。

陈国栋：回滚演练这一点太重要了。我们就是没演练，上线第二天出问题，回滚脚本跑不通，停服四个小时。现在想想还是后怕。

吴雅琴：四个衡量指标那个我认同，尤其是问题解决率。我们内部一直只看调用量，看起来挺热闹，实际业务部门反馈一般，现在准备重新调整考核口径。

赵鸿飞：八阶段拆解得很清楚，准备拿去当项目检查清单用。顺便问一句，中型企业如果预算有限，是不是可以先不上数据资产平台，只做主数据？