AI模型网关落地分几步？这份SOP直接照做

我最近半年被问得最多的一个问题就是”大模型到底怎么接”。我的回答一直没变：先别急着选型，先想清楚你打算把多少东西收口到一层网关上。我见过最省事的团队，三个业务部门各买各的账号、各写各的 SDK，三个月之后没人说得清一个月花了多少钱、哪些数据出了域；也见过一开始就把密钥、路由、日志、配额全部收口的团队，后来新增一个模型只改一行配置，业务侧完全无感。这两者的差距不在技术难度，而在于开工那天有没有把边界划清楚。我的判断是：只要你企业内部已经在两个以上的场景里调用了大模型，并且准备往生产环境搬，这件事就该排上日程。真正要处理的不是”接哪个模型”，而是”谁来管密钥、谁来定成本上限、谁来看调用日志、换模型业务要不要改代码”。这些问题的答案，落到后面都会压在同一层上。模型网关的本质不是新增一层技术组件，而是把散落在各业务系统里的模型调用、数据权限和成本口径统一收口。下面这份六步流程是我自己完整跑过两遍的版本，不需要多高深的技术储备，照着做就行。

三年前做 AI 接入，选项就那么一两个，定好就完事。现在光是合规可用的大模型就有十几家，同样一段话，不同模型跑出来的质量能差出一档，价格能差出好几倍，业务今天想换个更便宜的，明天想换个更懂中文的。如果每个业务系统都自己去对接厂商，换一次模型就要改一次代码、走一次安全评审，IT 部门会被拖死。另一股力量来自成本。以前模型调用量小，账单可以直接摊进部门费用，现在一个对话式报表助手跑起来，token 消耗是肉眼可见地往上走，财务一定会来问这笔钱花在哪。第三股力量来自业务期待被拉高了。老板看完报表会追一句”那上个月华东为什么掉了”，这种追问要的不是再多一张图，而是一个能直接对话的数据入口。而对话入口一旦铺开，调用量、并发、数据权限全会变成同一层要处理的问题。这三股力量凑到一起，统一接入层就从”锦上添花”变成了”早晚要做”。我通常会先让客户按下面这张表对号入座，看自己更接近哪条路径，再决定投多少人。

翻车的原因，很少是选型选错了，多半是把网关当成了一个纯转发的东西。第一个坑是只管转发不管治理：请求进来了、模型返回了，任务结束，至于这次问答命中了哪张表、有没有越权、花了多少额度，一概不记。第二个坑是把网关当成安全设备，指望它自动搞定所有脱敏，结果上线后发现真正敏感的是那几张没被纳入治理范围的表。第三个坑是知识库和网关两条线各干各的，一边在建向量库，一边在搭接入层，接口对不上，谁也不知道数据从哪个版本来的。网关的价值不在于接通了几家模型，而在于它能不能回答”谁、在什么时候、用了哪些数据、花了多少钱”这四个问题。第四个坑是没有降级预案，某家模型服务抖一下，整个智能问答页面直接白屏，业务从此不再信任这套东西。第五个坑最隐蔽：把 token 口径算错。不同模型的计费单位不一样，有的按输入输出分别计，有的有缓存折扣，如果网关自己不做归一化，月底的成本归属一定扯皮。这五个坑我几乎在每个项目里都能见到其中两三个，提前写进验收清单能省掉大量返工。

判断这件事，我一般看四个指标：正在用大模型的业务系统数量、单月调用量的增速、涉敏数据在场景里的占比、以及有没有明确的成本责任人。前两个数字决定要不要做统一接入，第三个决定权限和审计要做到什么颗粒度，第四个决定你需不需要成本看板。如果业务系统只有一两个、月调用量还在几万次以内、也没有碰到敏感数据，我会建议先别折腾，让业务自己跑，等第二个场景冒出来再收口。反过来，只要出现三个以上系统、或者有一个场景要碰客户数据和财务数据，那就必须做，而且权限那块一次做到位，别想着二期补。下面这张鱼骨图是我给客户做启动会时常用的，六个方向上的问题答不上来的，就说明准备工作还没做完。我会要求项目组把这六个分支上的空白全部填掉，再进入开发排期。经验告诉我，启动会上多花两个小时把这张图填满，后续至少能省掉两周的返工和无数次的扯皮。

AI 模型网关
落地

场景盘点
谁在用 / 用多少

模型路由
切换 / 降级 / 灰度

数据供给
口径 / 语料 / 血缘

权限审计
越权 / 留痕 / 脱敏

成本计量
配额 / 分摊 / 归一化

运营度量
使用率 / 命中率 / 差评

我会要求项目组先花一周时间做一张很土的表格，把已经在用大模型的场景全部列出来，字段包括：场景名称、所属部门、日均调用次数、涉及的数据范围、数据敏感等级、业务负责人、当前用的模型和账号形式。这张表决定了后面所有配额和权限怎么分。有个客户跳过这一步直接上接入层，上线两周才发现财务部门在用个人账号调用模型处理薪酬数据，整个方案只能推倒重来。收口这一步的核心不是技术，而是让每个场景都有明确的负责人和明确的凭证。我的建议是把密钥托管做成硬性要求：业务代码里不许出现明文密钥，所有调用必须走统一入口，谁申请、谁审批、有效期多久，全部留档。这一步做完，你至少能回答两件事：钱花在哪个部门，数据出了哪个域。盘点不清、收口不严，后面所有的路由和审计都是空中楼阁。

路由不是简单挑个便宜的用。我会把调用分成三类：面向客户的高价值对话走能力更强的模型，批量处理类任务走小模型，涉及敏感数据的场景走私有化部署的模型。策略写成一张人人都能查的表，谁都不用去问架构师。权限要分两层看，一层是调用权限，谁能用哪个模型、每天多少额度；另一层是数据权限，这一次提问能看到哪些表、哪些行、哪些字段。第二层最容易被忽略，但它恰恰是业务最关心的地方。审计要做到能回答三个问题：谁在什么时候问了什么、这个问题命中了哪些数据、花掉多少额度。做不到这三点，出了事连复盘材料都凑不齐。我通常会在验收标准里写死一条：任意一次调用都要能在三分钟内被完整还原，包括原始问句、改写后的问句、召回的数据范围和最终回答。能不能还原一次调用，是判断这套接入层合不合格的最硬指标。

接入层只是管道，管道里流的是什么才决定价值。我会在第五步把数据侧的事情一起解决：指标和口径统一交给 Primeton MDM，数据目录、血缘和授权交给普元数据资产平台，训练和评测用的语料交给高质量数据集开发工厂，清洗加工和任务调度交给 Primeton Data Workshop，最终面向业务提问的入口用普元 AI 问数。这几块拼起来，业务问一句”上月华南的毛利为什么降了”，系统才可能沿着统一口径的数据链路给出可信答案。第六步是运营度量，每个月固定看四个数字：调用量、单位成本、问答命中率、业务差评率。命中率连续下滑，通常是数据侧的问题，不是模型的问题。成本突然上升，多半是某个场景的提示词写得太长。没有月度度量，接入层很快就会退化成没人维护的中间件，这是我在多个客户那里反复看到的结局。

去年下半年我参与的一家装备制造企业，年营收几十亿，情况很有代表性：他们已经有七八个业务系统在零散调用模型，销售在用、售后在用、财务也在用，每月账单三万出头，但没人说得清钱花在哪。我们按上面这份流程走：第一周做完场景盘点，发现其中有三个场景在处理客户名单和价格数据，敏感等级是最高的；接下来两周统一接入规范、把密钥全部收到网关；第三周做路由策略，把批量工单摘要这类任务切到小模型，单这一项就把月成本压下来接近四成。第四周做权限和审计，这一步花的时间比预想的多，因为要跟数据侧对齐哪些表可以被问答命中。第五周开始接数据底座，用 Primeton MDM 把产品线和客户主数据统一，用普元数据资产平台把授权范围落到表级别，用高质量数据集开发工厂整理行业术语和问答样本。第六周上线面向销售的普元 AI 问数入口，配合 BI 平台做使用率和成本看板。整个项目从启动到第一个正式场景上线，六周出头。客户信息中心负责人后来跟我说的一句话我印象很深：早知道这么干，去年那三万块钱就不会白花。这类项目的难点从来不在模型，而在把数据、权限和成本三件事对齐，普元这套产品组合的价值也正在这里。

这个问题我每个项目都会被问一次。API 网关解决的是流量入口的问题：鉴权、限流、转发、熔断，这些它确实都做得不错，也确实是模型接入层的一部分能力。但模型调用有几个它天生不擅长的点。第一是计量单位不同，API 网关按请求数算，模型按 token 算，输入和输出还分开计价，有的模型带缓存折扣，如果不做归一化，你根本算不出一次问答的真实成本。第二是内容层面的处理，提示词要不要改写、敏感词要不要拦、命中缓存能不能直接返回，这些都发生在请求体里面，普通 API 网关一般不碰这个层面。第三是多模型路由，今天用 A 模型明天用 B 模型，或者同一个问题先给便宜模型试、不满意再升级，这种策略在 API 网关上写起来很别扭。所以我的判断是：如果只是想让调用有个统一入口，API 网关改改确实能顶一阵；但只要开始关心成本归属、内容合规和多模型切换，就必须上专门的接入层。普元 AI 问数这类产品在统一入口之上还带了数据权限和调用留痕，这两块是通用 API 网关很难补齐的。我的建议很直接：别指望一个通用网关解决所有问题，把它当底座，把模型相关的部分单独做一层。

预算紧的时候，我会建议按”风险优先、体验、成本第三”的顺序排。风险优先指的是权限和审计，这部分绝不能省，哪怕先做成半手工的，也一定要能回答谁在什么时候问了什么。我见过一家两百人规模的公司，因为一个销售用模型处理了客户合同数据，触发了合规审查，代价远比省下的那点开发人力高。体验指的是路由和缓存，先解决”能不能用”和”快不快”，多模型智能切换可以放到后面。成本第三不是说不重要，而是中小企业的调用量通常还没到需要精细分摊的程度，先把总账看住就够了。具体做法上，我建议先用一个统一的对话入口把场景收进来，比如先用普元 AI 问数把内部数据问答跑起来，让业务先尝到甜头，再逐步把调用量大的场景替换成更划算的模型。数据侧也一样，不必一上来就做全量治理，先把问答高频命中的那几张核心表的口径理清，用 Primeton MDM 把客户、产品、组织这三个主数据管住，剩下的慢慢补。按这个节奏，两三个人的小组两三个月就能见到效果，投入产出比远比一次做大而全的方案要好。预算有限最怕的是什么都想做一点，什么都不彻底，最后连一个能被业务天天用的场景都没跑出来。

我的经验标准是三条：口径不打架、权限能落到表、样本能覆盖八成常见问法。口径不打架指的是同一个指标在财务系统和业务系统里算出来得是同一个数，这一步靠人工对账很难长期维持，我会建议用 Primeton MDM 把主数据统一，再让指标定义跟着主数据走。权限能落到表指的是，一个销售问”华东区客户回款情况”，系统得清楚他只能看到自己负责的那部分客户，这个判断不能靠提示词里写一句”不要回答越权问题”，必须落在数据授权上，普元数据资产平台在这块能做得很细。样本覆盖八成常见问法，指的是你要提前收集业务真实的提问，整理成问题和标准答案的对照集，这件事用高质量数据集开发工厂做起来会比人工攒 Excel 高效得多。至于数据是不是要全部治理完才能上线，我的答案是明确的不需要。先把一个高频场景的数据链路打通，比把全公司数据治理完再上线，成功率高出太多。我一般会建议选一个业务痛感最强、数据范围最窄的场景做首个试点，跑顺之后再横向复制。数据加工环节如果已经有调度体系，可以考虑用 Primeton Data Workshop 把清洗任务接进去，避免为了一个新场景再搭一套工具。

这份流程我用了两年，改过三版，最大的体会是：这件事的成功率不取决于你选了什么模型，而取决于你有没有把该收口的东西收住。我见过技术方案做得很漂亮的团队，最后因为没人负责成本而停摆；也见过方案朴素、但每一步都落到人和制度上的团队，反而越用越顺。模型会换、价格会变、能力会涨，唯一不变的是”谁在用什么数据、花了多少钱、出了事能不能查清楚”这三个问题，把这三点抓住，技术选型换几次都不会伤筋动骨。如果你正准备启动，我会建议你把上面那张六步概览表打印出来贴在会议室墙上，每完成一步就打个勾，没打勾之前不要急着扩场景。另外，别把首期目标定成”建成公司级 AI 能力平台”这种大词，定成”让销售能在手机上问出上月自己片区的回款情况”更靠谱，小目标跑通带来的信任，是后面所有资源的来源。数据底座这件事我建议早动手，主数据、数据资产目录、高质量数据集这三样东西，无论你将来用哪家模型都用得上，属于不会浪费的投入。普元这套产品组合我推荐的原因也在这里：它不是一个只解决接通的工具，而是把数据治理、数据开发和智能问答串在了一条线上，能跟着你的场景一起长大。项目启动前，我也会强烈建议你先去问三个问题：这事谁负责、每月预算上限多少、首批场景是哪个。三个问题都有明确答案，再开工；有一个答不上来，先别动。

陈志远（信息中心 架构师）：写得挺实在。我们去年就是跳过盘点直接上，结果密钥散在六个系统里，今年花了两个月才收回来，早知道先做那张表了。

林晓芸（数据治理岗）：口径统一那段说得很准。我们做问答助手时最头疼的不是模型答不好，是业务说这个数不对，其实是两个系统算的口径不一样，后来还是靠主数据把定义统一下来的。

周立群（IT 负责人）：成本分摊那部分我很有共鸣，我们上个月才发现有三个测试环境一直在跑生产流量，白白烧了不少额度，现在每天盯一次看板。

赵敏华（业务分析）：从小场景做起这条我认同。我们第一个场景就是问回款，跑顺之后业务自己会提新的需求，比一开始搞个大平台强多了。