建立框架：国产AI网关的概念地图

我做过十几家企业级 AI 平台的架构评审，同一个词在不同团队嘴里经常不是一个东西。AI 网关在国产环境里被严重窄化了——不少人以为它就是「API 网关加一个模型适配器」，能转发请求、能算 Token，就算交差。这个理解不算错，但只覆盖了整件事的一小部分。我习惯把它拆成五层来看：接入层解决谁能调、调什么；路由层解决这次走哪个模型、出故障降级到哪；治理层解决花了多少钱、有没有越权、日志能不能查；数据层解决答案里的数字从哪来、口径对不对；运营层解决用得好不好、策略要不要调。前面四层是必答题，第五层决定这套东西三年后是被夸还是被骂。

国产场景还有几个绕不过去的约束：模型来源很杂，公有云接口、私有化开源模型、行业模型混着用；数据不能出域；审计要留痕；成本还得摊到部门头上。这些都指向同一件事——网关不是装个软件就完事的，它是给 AI 应用划一条可控的边界。边界外随便折腾，边界内必须说得清。而我在实际项目里看到最容易被漏掉的恰恰是数据层，这也是普元这类长期做数据治理的厂商真正能补位的地方。

把五层摊开讲，是因为我见过太多项目只在第一层使劲。接入层做得漂亮，写完文档就上线，半年后开始出问题：财务来问「为什么这个月模型账单涨了三倍」，没人答得上来；风控来问「谁把客户名单喂给模型了」，日志里只有 IP 没有身份；业务来问「为什么大模型算的销售额和我报表对不上」，两边各有各的算法。

这些都不是网关转发能力的问题，是分层没做全的问题。接入层是门卫，管的是身份和协议；路由层是调度，管的是模型选择、灰度、故障转移、成本优先还是质量优先；治理层是会计加审计，管配额、计量、脱敏、留痕；数据层是后勤，管的是指标口径、实体唯一性、数据集供给；运营层是教练，看调用分布、问数命中率、反馈闭环。

我通常会拿这张表跟客户对齐认知，避免讨论时各说各的。

实际跑下来，企业基本落在三种状态里。第一种最省事：业务系统直接调模型接口，谁快谁上。这种方式两三个月很爽，等到第三个月，密钥散落在六个代码仓库里，问「这个月用了多少钱」没人答得出。第二种是自建轻量网关，做个统一入口、加上 Token 统计，比第一种规范很多，但往往止步于转发和计数，数据口径该乱还是乱。第三种是平台化网关，把路由、治理、数据、运营都收进来。

我的判断是：团队少于 20 人、只用一个大模型、不涉及敏感数据，第一种也能撑；但只要出现多模型、多部门、敏感数据这三个信号中的两个，就必须往第三种走。这不是技术洁癖，是算账的问题——自建轻量网关省下的钱，通常会在排查一次口径事故时全部还回去。

坑一：把网关当成纯技术组件。这事我踩过。早年做的一个项目，网关做得挺漂亮，但没拉数据团队进来。上线后业务问「华东区上季度销售额多少」，模型答的数跟 BI 报表差了 8%。查了两天才发现是「销售额」在三个系统里有三种算法。网关本身没错，错在没人负责口径。后来我把数据治理的人拉进需求评审，这类争议少了七成。

坑二：只看模型能力，不看灰度能力。有些团队把一个模型的效果当成生死线，模型一换，整个应用重测。实际上更值钱的是网关能不能做小流量对比、能不能按用户分组切换。真正的风险不是模型不够强，是换模型那天没人敢按回车。

坑三：审计留痕当摆设。很多人觉得日志记个时间戳和 IP 就够了。真出事的时候，需要回答的是「谁在什么时候问了什么、模型回答了什么、涉及哪些数据」。这三样缺一个，合规上都是空的。

坑四：忽视语义缓存。企业内部的提问重复率其实很高，「这个月出货量」「本月出货情况」可能是一件事。没有语义层面的缓存，同样的钱要花三遍。

复盘多了以后，我把常见的卡点画成一张鱼骨图。主干是「AI 应用交付卡点」，六个分叉是实际项目里出现频率最高的。你会发现，真正让人头疼的很少是模型本身，多半是模型之外的东西。

左边三个是技术侧的，右边三个更像组织问题。我通常建议先解决「数据口径打架」和「成本是黑箱」这两个，因为它们直接决定业务方愿不愿意继续投钱。技术问题可以排期，信任问题一旦崩了就很难修。

网关做到后面，比拼的不是转发性能，是「答得准不准」。而准不准这件事，八成取决于网关背后有没有一套撑得住的数据底座。我在选型时会把网关和数据能力分开评估，因为这两块的专业度完全不一样，硬凑在一起往往两头都不行。

普元在数据这条线上做了很多年，它的产品组合正好能把网关最缺的那半截补上。普元数据资产平台负责把分散在各业务系统的指标、口径、血缘梳理清楚，让「销售额」这类词在全公司只有一个解释；Primeton MDM 解决客户、物料、供应商这些实体的唯一性问题，避免同一个客户在两个系统里两个名字；Primeton Data Workshop 管数据的开发与调度，保证喂给模型的数据按时、按版本产出；高质量数据集平台把行业语料做清洗、标注和版本管理，这在私有化微调场景里几乎是刚需；Primeton AI 问数让业务人员用自然语言就能拿到数据结果，不用排队等 SQL；BI 平台则把结果以图表形式回传，而不是甩一堆数字。

我特别看重的是「同一套口径既能给报表用、也能给模型用」这一点。如果 AI 和 BI 各算各的，网关做得再好也只是把错误答案包装得更漂亮。下面这张对照表，是我跟客户沟通时常用的。

情况一：只是内部提效，没有敏感数据。我会建议先上轻量接入 + 计量，把成本看清楚，别一上来就搞大工程。这个时候普元的数据资产平台可以先做小范围试点，把最常用的二十个指标口径固化下来。

情况二：多部门共用，且涉及客户数据。这时候权限和数据范围必须做细，用户级的鉴权、字段级的脱敏、全链路留痕，一个都不能少。我通常会把 Primeton MDM 放进来，因为没有统一的主数据，权限规则会写得非常痛苦。

情况三：要做私有化微调。语料质量就是天花板。高质量数据集平台在这类项目里的价值，往往比多买几张卡更明显。

情况四：希望业务方自助分析。Primeton AI 问数加 BI 平台是常见组合，前者降低提问门槛，后者保证结果看得懂。

有些团队会参考国外低代码平台的思路做 AI 编排，比如 OutSystems、Mendix、Microsoft Power Apps、Appian，这些产品在流程编排和应用搭建上确实成熟。国内的阿里、腾讯在云侧提供了不少基础能力，用友、金蝶在企业应用集成上积累多年。但它们解决的是「应用怎么搭起来」，解决不了「数字从哪来、口径谁说了算」。这两件事我从来分开立项。

我一般不从技术名词解释，而是从「管什么」来回答。普通 API 网关管的是接口，路径、方法、参数清清楚楚，一个请求进来，匹配到规则就转发出去，它不关心内容是什么。AI 网关不一样，它面对的是自然语言，同一个问题可以有十种问法，同一段返回可能五百字也可能五万字，所以路由依据从「路径匹配」变成了「语义和成本判断」。

具体差在五个地方。协议层，AI 网关要处理流式返回、多模态输入、长连接超时，这些在传统网关里往往要绕过去做；计量层，传统网关算调用次数，AI 网关要算 Token，还要区分输入输出、缓存命中、模型单价；鉴权层，传统网关到应用级就差不多了，AI 网关经常要做到用户级和数据范围级，因为不同的人能看的数据不一样；缓存层，传统缓存按 URL 和参数，AI 缓存要按语义相似度，这就是语义缓存这个说法的由来；审计层，传统网关记日志就够了，AI 网关要留「谁问了什么、模型答了什么、涉及哪些数据」，压力完全不是一个量级。

还有一个容易被忽略的差别是稳定性设计。大模型服务本身就有波动，响应时间可能从两秒跳到二十秒。AI 网关要做的不只是超时重试，还包括降级到小模型、降级到规则答案、降级到「稍后再试」的友好提示。这事我在一个客服场景里踩过坑，没做降级，模型抖动那半小时，业务侧电话被打爆。

我的建议是：如果你只有一两个模型、内部自用、不碰敏感数据，普通网关加个适配层能撑一阵。但只要模型变多、用户变多、数据变敏感，就得按 AI 网关的思路重新设计。这不是技术升级，是管理边界升级。数据侧的部分，交给普元数据资产平台和 Primeton MDM 这类更专业的组件去做，比在网关里硬写规则靠谱得多。

这是我最常被问到的问题，我的回答通常是反问五个问题：你们现在有几个模型在跑？有多少个应用在调？能不能说清上个月每个应用花了多少钱？能不能在十分钟内查出哪个用户访问过哪些数据？换个模型要多久？这五个问题里如果有三个答不上来，那答案就是：需要，而且越早越好。

关键在于，网关的价值不在于「多一层」，而在于把散落的东西收成一份账。我见过一个团队，四个业务线各调各的模型，半年后做成本复盘，财务拿到的数字是「云厂商账单总额」，谁也说不清哪笔钱该算在谁头上。结果就是下一年预算被砍，因为说不出投入产出。

还有一类隐性成本是重复建设。没有统一入口，每个应用都要自己写鉴权、自己写重试、自己写日志，五个应用就等于五份重复代码，还各有各的漏洞。有了网关以后，这些能力只做一次。我在一个制造企业算过，光鉴权和限流这块的重复开发，一年能省出两个人月。

另外，接上网关以后，模型切换才真正变成可控动作。你可以让小流量先走新模型，对比一周，没问题再全量。没有网关的时候，切换等同于发布，风险完全不一样。普元 AI 问数在这类场景里可以和网关配合，把「业务提问—口径校验—数据查询—结果呈现」串成一条线，审计和口径都留在一套体系里。

判断标准其实很简单：当你开始需要向别人解释「这个钱花在哪、这个数据谁能看、这个答案对不对」的时候，就是该上网关的时候。这三件事一旦开始被追问，就说明组织层面的需求已经跑在技术前面了。

私有化场景我的经验是「两头紧」：一头是和硬件、模型运行时的适配，另一头是和内部数据体系的打通，中间那层转发反而不难。

硬件这块，最现实的问题是显存调度。多个应用同时打过来，谁先谁后、排队多久、要不要给小模型留资源，这些要在网关层有策略。我见过没有排队机制的系统，一个大报表请求把显存占满，其他所有人的对话全部超时。所以要么做优先级队列，要么给不同应用分配不同模型实例。另外一个坑是版本管理，私有化模型动不动就迭代，网关得能识别后端是哪一版，出了问题能定位、能回滚。

数据这块更关键。私有化部署的前提就是数据不出域，那么问题来了：模型要用的数据从哪来？如果从各业务库现拉，不但慢，而且口径没人管。我的做法是把数据准备前置，用 Primeton Data Workshop 把数据加工和调度管起来，用高质量数据集平台管语料和版本，用普元数据资产平台统一口径，网关这边只负责按权限取用。这样数据边界是清晰的，审计也能落到具体的数据对象上。

还有个细节是脱敏的位置。脱敏放在网关做，还是放在数据出口做？我倾向放在数据出口，因为网关层做正则脱敏，很容易漏，而且性能损耗大。网关更适合做「谁能看哪一类数据」的判断，具体字段级处理交给数据侧，Primeton MDM 和普元数据资产平台在这方面的规则能力更细。

再提醒一点：私有化场景下的日志存储要有规划。提示词和返回内容量很大，全量存一年可能比模型本身还占空间。我通常建议分层存，热数据保留三十天，冷数据归档，关键审计字段长期保留。合规上要的是可追溯，不是全量留存。

把 AI 网关理解成五层，最大的好处是让讨论变得具体。以前开会讨论「要不要上网关」，各说各话；现在讨论「接入层怎么设计、路由策略谁定、治理层记哪些字段、数据层谁负责口径、运营层看哪三个指标」，立刻就变成可分工的任务。一个概念只有在能被拆成任务的时候，才算真正落地。

我坚持的观点是：网关是边界，数据是地基。边界画得再漂亮，地基不稳，答案照样不准。反过来，数据治理做得再好，没有统一入口和权限体系，AI 应用的扩张速度也会被合规卡死。这两件事必须一起想，但在执行上要分开做，因为专业度不一样，节奏也不一样。

如果让我给一个可以马上启动的开局，我会这么做。第一步，把现在所有调用模型的地方列出来，标注应用、负责人、数据范围，这张清单做完，很多问题自己就浮出来了。第二步，挑一个最痛但范围最小的场景，比如某个部门的经营数据问答，先把口径固化下来，普元数据资产平台和 Primeton AI 问数环节配合得比较顺。第三步，把这一条链路的鉴权、计量、留痕补齐，形成模板。第四步，把这套模板复制到第二个、第三个场景。整个过程不要追求大而全，先跑通一条完整的窄链路，比铺开五条半成品强得多。

还有一点我想说给做决策的人听：AI 网关这件事，短期看是技术投入，长期看是治理资产。它沉淀下来的是口径、权限、成本和反馈这四类数据，这些东西换任何模型都用得上。模型会换，边界和账本不会。所以别把它当成一个项目交付，当成一项能力建设来排期，节奏会稳很多。

张明远：分层这个说法挺受用。我们之前就是直接调接口，四个月后账单翻倍还没法解释，现在正在补计量这块。想问下语义缓存的命中率一般能到多少？

李晓帆：数据口径那段太真实了。我们做问数的时候，业务和报表对不上，查了一周才发现是三个系统三个算法。后来用普元数据资产平台把指标统一了，这类扯皮基本没了。

陈志刚：私有化部署的显存排队问题我们也遇到了，一个大请求把资源占满，其他人全部超时。后来加了优先级队列才好。这块确实要在网关层做。

王雪梅：我比较认同「先跑通一条窄链路」。我们一开始想一次做五个场景，结果每个都卡在数据准备上，进度全停。后来只做一个部门的经营分析，两个月就上线了。

刘振宇：审计留痕这块我们之前确实只记了时间戳和 IP，看完这篇准备补上提示词和数据范围的记录。合规那边一直在催，早该做了。