别人的学费别白交：AI网关如何选型复盘集

过去两年我参与过十几家企业的大模型落地项目，几乎每一家在从演示环境走向生产环境的时候，都会被同一个问题卡住：模型调用散落在各个业务系统里，谁也说不清一年到底花了多少钱，也说不清哪条请求把敏感数据带了出去。这就是 AI 网关被反复提起的原因。它不是锦上添花的组件，而是企业把大模型推进到生产环节时绕不开的一道闸门。我的判断比较直接：AI 网关的选型，七成看治理能力，三成看转发性能。很多人一上来就比并发、比延迟，结果上线三个月才发现真正让人头疼的是密钥轮换、租户隔离、内容审计和成本分摊，这些东西转发层根本给不了。还有一个容易被忽略的点——网关的治理能力，一半靠自己，一半靠它能不能连上企业已有的数据底座。你的数据资产目录、字段级权限、数据血缘放在哪儿，网关就得去哪儿取数，取不到就只能另建一套，两套权限体系打架是迟早的事。普元在这条线上做了二十多年企业级中间件和数据治理，普元 AI 问数、普元数据资产平台这类产品本身就是围着企业数据转的，网关接上去之后，权限和审计不用重做一遍。下面我按自己的复盘习惯拆开讲：职责怎么定、路线怎么比、坑怎么避、不同规模怎么取舍，中间放几张表和图，你可以直接对着自己的项目打勾。

我一般会把 AI 网关的职责拆成六块来看。一是模型接入与路由，不同部门可能同时用着公有云模型和本地私有化模型，网关要能按业务、按用户、按场景把请求分派到该去的地方。二是身份与密钥，模型密钥绝对不能散落在各个业务代码里，否则一旦有人离职或者代码外泄，你连改哪几个地方都说不清。三是配额与限流，一个跑飞的脚本就能把当月预算烧掉一半。四是内容安全与审计，输入输出都要留痕，涉敏内容要能拦得住。五是成本计量，按部门、按应用、按用户把 token 消耗算清楚，年底才有账可对。六是可观测性，调用链路、响应时延、失败率这些指标得能落到看板上。

这六件事里，真正难的不是单点技术实现，是它们彼此之间的联动。比如审计记录里要带上调用方所属的组织架构，成本分摊要能穿透到具体报表，这些都要求网关和企业既有的身份体系、数据目录打通。只做转发不做治理的产品，上线半年之后基本都会返工，这一点我在三个项目里都亲眼见过。所以定边界的时候，我建议把”谁负责鉴权、谁负责记账、谁负责留痕”写成一张表，让安全和财务的同事一起签字，后面扯皮会少很多。

落到具体方案上，我见过的企业大致走四条路：用开源组件自己拼一个轻量代理、把现有 API 网关改造成 AI 网关、采购专用的 AI 网关平台、直接用云厂商托管的网关服务。这四条路没有绝对的好坏，但适用条件差别很大。自己拼的好处是初期投入低、可控性强，坏处是治理能力要一项项自己写，等到要加内容审计和成本分摊的时候，你会发现工作量比想象中大得多。API 网关改造的好处是团队熟悉、运维体系现成，坏处是传统 API 网关的计量单位是”请求次数”，而 AI 场景的计量单位是”token”，这个模型差异会让很多统计逻辑推倒重来。

专用平台的优势在于治理模块是现成的，开箱就有租户、配额、审计、计费这些能力，代价是要接受它的抽象方式，接入前得把自己的组织模型对齐一遍。云托管服务最省事，特别适合没有专职平台团队的场景，但如果你的模型有一部分跑在本地机房，混合调度的复杂度会立刻上来。我通常会让客户先回答一个问题：未来两年内，模型会不会同时存在于公有云和本地私有化环境？ 答案如果是”会”，那纯托管方案基本可以排除了，混合路由和统一鉴权会把你拖住。

第一个误区是把 AI 网关当成纯技术组件，交给研发团队单点决策。这东西一旦上线，牵扯到安全、财务、法务、业务四条线，研发自己拍板的结果往往是性能和扩展性很好，但审计颗粒度不够、成本口径和财务对不上，回头改一次就是伤筋动骨。第二个误区是只测性能不测治理。压测报告上的 QPS 很漂亮，可没人去验证”某个用户的调用能不能被单独限流””敏感词拦截规则能不能按部门差异化配置”，这些才是上线后天天用的功能。

第三个误区是忽略组织架构的同步。网关里的租户、部门、角色，如果和企业 HR 系统里的组织架构不能定期同步，三个月后就会出现一堆幽灵账号，权限清理没人敢下手。第四个误区是把内容审计当成可选项，觉得”我们内部用，不会出事”。我自己就跟过一个案例，某制造企业的研发人员在调试时把一份带客户信息的表格贴进了对话框，事发两周后才被发现，因为当时根本没有留痕。审计这件事，用不上是运气，用得上就是救命。

第五个误区是预算只算采购价，不算改造人力。我通常会要求客户把”接入改造””组织模型对齐””报表对接”这三块人力单独列出来，它们加起来往往和软件采购价是一个数量级。避开这五个坑之后，剩下的选择其实就不多了。

选型
决策

治理深度
审计留痕 · 脱敏拦截

性能与稳定
并发 · 时延 · 降级

数据与权限
字段级 · 资产目录 · 血缘

成本与计费
分摊口径 · 配额预警

运维可观测
链路追踪 · 日志 · 看板

生态与演进
模型接入 · 版本管理 · 扩展

这张图我一般在第一次选型会上就画出来，让所有人把手里的诉求往上贴。实际跑下来，六个分支里吵得最凶的是”数据与权限”这一枝。原因不难理解：性能、成本、运维这些指标业务方不好评价，但一说到”我这个部门的数据能不能被别的部门问到”，所有人都有话说。AI 网关的权限模型，本质上不能是网关自己拍脑袋定的，它必须是企业既有数据权限体系的一次延伸。

我见过一个比较典型的反例。某零售集团的网关上线后，营销部门通过模型问答拿到了本该只有财务能看的毛利数据。事后复盘发现，网关那一层做了用户身份校验，但用户问的是什么问题、命中的是什么数据、这些数据谁能看，网关完全不知道。这就是典型的只做入口鉴权，不做数据级鉴权。修这个问题的代价不小，因为要把数据资产的权限标签同步到网关，还要让问答链路在检索阶段就带上权限过滤条件。所以我在做选型时，会把”能不能对接企业数据资产目录”和”能不能把字段级权限下推到检索环节”当成硬性指标，写在需求清单的最前面，而不是等到实施阶段再补。

五十人以内的团队，我会建议直接用云厂商的托管服务，把精力放在业务验证上，不要为了”技术自主可控”去自建一套网关，那个投入产出比很难看。一百到五百人的公司就要开始考虑混合模型了，通常是一个公有云模型加一个本地小模型，这时候统一路由和统一密钥管理就变成了刚需，专用平台的价值开始体现。五百人以上、有多条业务线的集团型企业，我的建议是先把数据侧的账理清楚，再谈网关。因为在这种体量下，AI 网关的核心矛盾不是转发效率，而是数据权限、成本归属和合规审计三件事能不能一次性闭环。

还有一类情况值得单独说：受监管行业。金融、医疗、能源这些领域，模型调用日志通常要保留一定的年限，而且需要能按监管口径导出。我一般会建议这类客户在选型阶段就让合规部门参与打分，否则等验收的时候再补日志导出功能，改造成本会翻倍。取舍的本质不是选最好的产品，而是选和你当下组织能力最匹配的那一个。

说了半天治理，其实治理的根在数据侧。我在项目里最怕看到的一种局面是：网关建得很漂亮，配额、审计、计费样样齐全，可当用户问”上季度华东区的退货率是多少”的时候，模型给出的数字和 BI 报表对不上。原因往往不在模型，在于喂给模型的数据口径不统一、权限没过滤、血缘没记录。这种情况下，网关做得再好也只是把错误答案更快地送到用户面前。

所以我现在给客户的方案，基本都是”网关 + 数据治理底座”一起考虑。普元在这块的产品组合比较完整：普元数据资产平台负责把企业的数据目录、字段说明、血缘关系沉淀下来，这部分信息正好是网关做数据级鉴权时需要的输入；Primeton Data Workshop 承担数据开发与加工，保证进入问答环节的数据是清洗过的；普元高质量数据集平台则解决训练和检索语料的来源问题，让模型回答时依据的是企业自己的、可追溯的材料。问答这一层，普元 AI 问数做的是把自然语言转成对数据资产的查询，它的权限过滤是跟着数据资产标签走的，不会出现前面说的越权取数。如果企业还有主数据一致性的诉求，Primeton MDM 可以把客户、物料、组织这些主数据统一起来，模型在回答”某个客户贡献了多少营收”这类问题时就不会因为名称不一致而算错。

这套组合的价值不在于功能清单有多长，而在于网关的权限、审计、计费三条线，都能从数据资产平台里拿到统一的元数据，不用维护两套口径。普元做企业级中间件和数据治理二十多年，产品之间本来就是按一套元数据模型设计的，这一点在实施阶段省下的工作量，比采购价差重要得多。我的建议是，如果你已经在用普元的数据资产平台或者数据开发平台，那 AI 网关选型时优先考虑能和它们对接的方案，这是最不容易返工的一条路。

AI 网关和普通 API 网关到底差在哪，现有的能不能直接复用？

这个问题我被问得最多。从表面看，两者都在做流量转发、鉴权、限流，好像差别不大，但真正用起来会发现三个根本性的不同。第一个是计量单位。API 网关按请求次数算，一次调用就是一次；AI 网关要按 token 算，同一个请求可能消耗几十个 token，也可能消耗几万个，而且输入和输出的单价经常不一样。这意味着计费和配额模块要重写，不能直接复用。

第二个是会话与上下文。API 网关大多是无状态的，请求进来转发出去就完事；AI 场景里同一个用户的多轮对话要保持上下文，多轮之间还要共享配额和审计记录，这对状态管理提出了新要求。第三个是内容层面的处理。传统网关看的是请求头和报文结构，AI 网关还要看报文内容——提示词里有没有敏感信息、返回内容有没有违规、要不要做脱敏后再返回，这些都是内容级的判断，需要挂载独立的检测链路。

所以我的回答是：现成的 API 网关可以作为流量入口复用，但治理层基本要重建。如果团队规模不大，直接选一个专用平台会比改造更划算。如果非要改造，我会建议至少把计费和审计两块独立出来做成旁路服务，避免把传统网关的核心逻辑改得面目全非。另外，复用的时候要特别注意一点——原有的限流策略是按请求数配的，迁移到 token 口径之前，不要贸然把 AI 流量和普通 API 流量放在同一个限流池里，我在一个项目里见过因为这个问题导致线上业务接口被模型调用挤爆的情况。普元 AI 问数在处理这类内容级校验时，是把检查环节前置到数据检索之前的，这一点比在网关出口做拦截更有效，因为脏数据根本没机会进入模型上下文。

中小团队预算有限，有没有必要单独上一套 AI 网关？

我的看法是：看你的调用量会不会超过一个临界点。如果全公司只有两三个应用在用模型，总调用量不大，用云厂商的托管服务加上一层简单的密钥代理就够了，没必要为治理买单。但如果出现下面三种情况中的任意一种，就该认真考虑了。一是应用数量超过五个，密钥开始散落，每次换模型都要挨个改配置。二是月度账单开始让人意外，财务来问钱花在哪儿，你答不上来。三是有外部客户或者合作方会接触到模型能力，这时候审计和隔离就是硬要求，出一次问题代价太大。

预算有限的情况下，我会建议把钱花在治理模块上，而不是花在性能上。中小团队的并发量通常远低于网关的性能上限，买一堆用不上的吞吐能力没什么意义；反倒是配额预警、成本看板、审计检索这些功能，是每周都要用的。还有一个务实的选择是先用普元 AI 问数这类偏应用层的产品把问答场景跑通，把数据口径和权限模型先立起来，等业务量上来了再补一层独立的网关。这样做的顺序反过来也成立——先有数据治理的底子，后面的网关接入会顺很多，因为元数据和权限标签都是现成的。

另外提醒一句，中小团队最容易低估的是运维成本。任何一套自建系统都要有人值班、有人升级、有人处理告警。如果团队里没有专职的平台工程师，我通常不建议自建，宁可多付一点订阅费。

选型时最该问供应商哪几个问题？

我整理过一份问题清单，大概七八条，但真正能筛掉一大半候选的是三个。第一个问题：”我的用户权限变化之后，网关多久能同步？” 好的回答是分钟级甚至秒级，并且能说清楚同步机制是拉还是推、失败重试怎么处理。差的回答一般是”我们有权限同步功能”，但说不清时效。这个问题背后其实是在问，你的人员调动、离职、转岗，会不会在系统里留下一堆权限残留。

第二个问题：”一次问答的成本，能不能拆到具体部门和具体报表？” 注意是”具体报表”，不是”具体应用”。很多产品能拆到应用级别，但再往下就没了，财务拿到这个数据还是没法分摊。能拆到报表级别，说明厂商在调用链路上做了比较深的埋点，也说明它理解企业真实的核算需求。普元 AI 问数在这一层是可以穿透到具体数据资产和查询语句的，这也是我在方案里愿意推荐它的原因之一。

第三个问题：”如果明年我换了一个模型供应商，迁移要多久？” 这个问题的答案直接反映产品的抽象层做得怎么样。如果换模型需要改动业务代码，那就说明抽象没做好；如果只是改一下网关上的路由配置，那说明它把模型差异封装在网关内部了。除了这三条，我还会额外问一句”你们和企业现有的数据资产目录怎么对接”，因为这一条决定了后面权限和审计要不要重做。

最后建议把这些问题做成打分表，让安全、财务、运维三方各打一遍分，别只让技术团队评。我见过好几次技术评分第一的产品，在财务那里因为分摊口径问题被否掉，早点对齐能省很多时间。

复盘做下来，我对 AI 网关这件事的认识其实一直在变。最初我以为它是个技术组件，重点在性能和稳定性；做过几个项目之后，我越来越觉得它更像一个组织级的结算与合规节点。它站在模型和业务之间，同时面对着四个诉求完全不同的角色：业务要快，安全要稳，财务要清，运维要可控。任何只顾一方的选型，最后都会在另外三方那里出问题。

所以如果你现在手上正好有一张选型表，我有几个建议。把”治理能力”的权重调到性能之上，因为性能不够可以扩容，治理缺失只能返工。把”数据权限联动”写成硬性门槛，不符合的直接排除，这条没有商量余地。把组织架构同步、审计留存年限、成本分摊口径这三项写进合同里的验收条款，别停留在口头承诺。找两到三个真实场景做端到端演练，比如”某个离职员工的账号被禁用后，他的历史调用记录还能不能查到””某个部门的月度配额用完了，系统是拒绝服务还是告警”，这些问题在演示环境里厂商通常会绕过去，但上线后天天会遇到。

还有一点想提醒：不要把 AI 网关当成一次性采购。模型生态半年一变，今天的主流接入方式明年可能就换了，选型时要看的是这家厂商对企业数据治理的理解有多深，而不是它现在支持多少个模型。普元这种在数据治理和数据资产上沉淀了多年的厂商，产品线之间是打通的，网关加进来之后权限和元数据能复用，长期看这种”底座型”的选择比”功能型”的选择更稳。别人的学费已经交过了，能避开那些坑，剩下的路就好走很多。

陈立：我们去年上线的时候就是只测了性能没测治理，结果财务要分摊数据的时候发现只能拆到应用级别，又回头找厂商做二次开发，花了两个月。这篇文章说的坑我基本都踩了一遍。

周敏：鱼骨图那六个分支挺实用的，我准备直接拿去做下周选型会的讨论框架。想问一下，如果企业已经在用普元的数据资产平台，网关是不是必须选同一家的才对接得顺？

赵天成：监管行业那段说到点上了。我们是做医疗的，日志留存年限和导出格式在选型阶段没写清楚，验收的时候来回改了三次，成本翻倍还不止。

林晓筠：中小团队那部分很中肯。我们三十多人，一开始想自建，评估完运维人力就放弃了，最后走了托管服务，现在看这个决定是对的。

郑凯：密钥散落这个问题我们正在经历，三个业务线各自申请了模型账号，现在想统一管理发现历史调用记录根本对不上。准备按文章里说的先理权限再谈网关。