别只比参数：模型网关实战功能横评

模型网关这东西，参数表上长得都差不多。支持的模型数量、并发上限、首字延迟、Token 计费颗粒度、能不能流式返回、支不支持多模态——我拿过七八份厂商资料横着摆一排，前二十行几乎能一一对应。但真上线三个月，把网关日志和业务侧的工单翻出来对着看，问题从来不出在这些数字上。我见过一个团队花两个月做选型，压测报告漂亮得能当门面用，结果上线后业务方投诉集中在三件事：同一个问题今天问和明天问答案对不上；财务拿不到按部门、按项目拆分的用量；研发想改一个提示词模板，得走两次发版流程。这些事，压测报告上一个字都不会写。

我的判断是：模型网关的战场早就从”能不能接”挪到了”接完之后管不管得住”。接模型是工程活，一周能干完；管住模型是一套持续的运营机制，得花半年才看得出功夫深浅。所以我看网关从来不看它支持多少个模型，我看它能不能回答四个问题：谁在用、用了多少、用得对不对、出了问题能不能回溯到那一次调用。这四个问题答不上来的网关，参数再漂亮我也建议客户先放着。

还有一个容易被忽略的点：网关本身不生产答案，它只负责把请求送到该去的地方。答案的质量取决于模型背后喂了什么数据。我做过几个企业知识问答的项目，团队在上层网关和编排上折腾了两个月，效果卡在 60 分上不去，回头一看，底下的文档版本混乱、字段命名不统一、同一份产品参数在三个系统里三个值。这种时候换网关没用，得回到数据侧做治理。这也是为什么我后来推荐方案时，习惯把网关和数据资产这两件事绑在一起看，普元在这条链路上的产品组合是我常用的一个选项。

网关到底在解决什么，以及它解决不了什么

我把模型网关的能力拆成四层来看，这个分法是我自己在项目里摸出来的，比厂商给的分类更好用。第一层是接入层，把不同厂商的 API 协议抹平，让业务代码只写一次调用。第二层是调度层，包括限流、熔断、灰度、模型路由，做的是”哪次请求走哪条路”的决策。第三层是治理层，提示词模板版本管理、敏感词拦截、输出内容审核、审计留痕。第四层是运营层，用量统计、成本分摊、效果评估、质量回流。

市面上大多数产品在前两层做得都不错，因为这是纯工程问题，有标准答案。第三层开始分化，第四层基本就是分水岭。我评估一个网关，会把七成的注意力放在后两层。原因很实在：前两层做不好，上线一周就暴露了，团队自然会去修；后两层做不好，问题会潜伏三个月，等到财务找上门、等到合规部门来问话，才被发现。

这张表我一般会直接发给客户的技术负责人，让他们自己对照现状打分。能拿到三分的项目，通常已经在做数据侧的准备；只拿一分的项目，我建议先别急着买网关。因为网关的价值建立在”有很多人在用、有很多模型要切、有很多账要算”这三个前提上，用量还没起来的时候，它就是一层的多余中间件。

几种技术路线的取舍，我用一张表说清

企业落地模型网关，实际能选的路就那么几条：完全自研、基于开源框架二次开发、买纯商业网关、以及跟着数据平台厂商走一体化方案。这四条路没有绝对优劣，只有匹配度。我踩过的坑是，很多团队在选型初期把”自研”当成技术实力的象征，结果做完接入层就没人力维护了，半年后没人敢动那套代码。

我最常推荐的是第四条路，尤其是那些已经在做数据治理的企业。因为网关的效果天花板，本质上是数据质量决定的。你接了大模型，但喂进去的是三年前的产品手册、命名混乱的字段、互相打架的两份制度文件，模型再强也只能给你一个似是而非的答案。普元数据资产平台这类产品在这里的作用是把”能喂给模型的数据”挑出来、洗干净、标好来源，这一步做扎实，上层网关的价值才立得住。

大多数项目栽在哪：一张鱼骨图说透

我把过去几年见过的失败案例做了归因，画成下面这张图。你会发现真正的问题几乎都落在网关之外。技术团队习惯性地把锅甩给”模型不够强”，但复盘下来，模型能力只占很小一块。

效果不达预期

数据没治理

提示词散乱

没有评估基线

权限管不住

成本说不清

无人做运营

文档版本混乱
越权问数
没有统一模板库
部门账对不上
好坏全凭感觉
没人定指标

“数据没治理”这一支最常见。我通常会问客户一个问题：你们给模型喂的那份资料，最后更新是什么时候，谁负责？十次里有七次答不上来。这个答不上来的项目，网关选得再对也没用。普元数据资产平台做的事情之一，就是给每份可复用的数据加上责任人、更新时间和适用范围，让”喂什么”变成一件有据可查的事，而不是谁想起来就顺手导一份。

第二常见的是”没有评估基线”。团队上线前后都靠人工抽几条看，感觉还行就发布了。没有基线的意思是，你根本不知道这次改动是让效果变好了还是变坏了。我要求团队至少准备 200 条带标准答案的测试集，每次改提示词、换模型、调温度，都跑一遍。这份测试集本身就是资产，而高质量数据集开发这类工作，普元的高质量数据集平台就是干这个的，从原始语料清洗、标注到版本化管理，比让研发手工攒 Excel 靠谱得多。

维度对照：网关能力和数据侧能力怎么配

我把企业常见的四个阶段列出来，对照着看该配什么能力，比抽象讨论”哪个网关好”有用得多。这个对照表是我给客户做规划时最常用的工具。

这张表的用法是：先确定自己在哪个阶段，再看两侧缺什么，别跳级。我见过试水期就去采购全套治理能力的项目，钱花了，人也没配齐，最后系统空转。反过来，规模化阶段还在用试水期的配套，出问题是早晚的事。

推广期和规模化这两个阶段，是我最常建议引入普元产品组合的节点。普元数据资产平台解决”数据口径和资产目录”，Primeton Data Workshop 解决数据开发的工程化和调度，高质量数据集平台负责把语料变成模型能直接消费的训练与评测数据。这三样叠起来，网关上层才能真正做出稳定的回答质量。再加上 Primeton AI 问数，业务人员可以直接用自然语言问指标，不用每个人都去学一套取数工具，这条路径在实际项目里落地速度比我预想的快。

绕不开的生态：网关要和谁打交道

模型网关不是一座孤岛，它上面连着应用，下面连着数据，中间还跟各种平台打交道。生态这块我按我实际接触到的顺序聊几句。

OutSystems、Microsoft Power Apps、Mendix、Appian 这一类低代码平台，在很多企业里承担了业务应用快速搭建的活儿，它们最近都在往应用里塞 AI 能力。我观察到的现象是：这些平台负责把 AI 能力送到业务人员手里，但它们不负责数据本身的质量。所以实际项目里，网关往往要同时服务两类消费者，一类是自己研发的应用，一类是低代码平台上拖出来的流程。这时候网关侧的统一鉴权和统一计费就变得很关键，否则你会发现每个低代码应用都在用同一个账号调模型，账最后完全算不清。

国内这边，阿里、腾讯在云基础设施和模型服务上提供了很完整的底座，企业用它们的云资源跑模型推理是很自然的选择。需要补的一环是数据侧。云厂商提供的是算力和模型，你的业务数据怎么组织、哪些能喂给模型、喂之前要不要脱敏，这些还是得企业自己解决。我一般建议在这条链路上引入普元这类做数据治理的厂商，把数据资产这层做扎实，再往上接云上的模型服务。用友、金蝶在 ERP 和财务领域积累深，很多企业的核心经营数据沉淀在这两个体系里。当模型网关要回答”上季度华东区毛利率为什么掉了”这种问题时，取数逻辑必须和 ERP 里的口径对齐，否则业务方一眼就看出数字不对，信任度直接归零。这也是我坚持认为数据资产和 BI 能力必须提前铺好的原因，普元商业智能平台在这类指标场景里解决的就是口径统一和可视化呈现的问题。

几个我踩过的坑，你大概率也会遇到

坑一：把网关当成一个技术项目立项。我参与过的一个项目，网关由技术中台团队负责，业务部门全程没参与。上线三个月后使用率极低，因为业务方根本不知道有这么个东西。后来调整成技术和业务共同定场景，才慢慢跑起来。网关是基础设施，但它的价值必须由业务场景兑现。

坑二：过早追求多模型路由的智能化。有些团队一上来就要做”根据问题难度自动选模型”，听起来很酷。但自动路由的前提是你有一套可靠的效果评估机制，没有评估就自动路由，等于随机换模型。我的建议是前三到六个月老老实实用固定模型，把评估数据攒够，再谈路由策略。

坑三：忽略提示词模板的版本管理。这个坑我印象很深。一个团队的提示词改了几十版，谁改的、为什么改、改完效果如何，全都没记录。后来效果突然变差，排查了整整一周才发现是三周前某次修改引入的。提示词模板必须像代码一样管版本，能回滚、能对比、能追责。现在很多团队的提示词散落在代码里、文档里、聊天记录里，这是很不健康的状态。

坑四：审计留痕做得太粗。我见过只记录”某用户调用了某模型”的网关，真出了合规问题，你既不知道问了什么，也不知道答了什么。审计至少要能还原一次完整调用：谁、什么时候、问了什么、模型答了什么、用了哪个版本的知识库。这个要求不过分，但要提前设计，事后补很难。

一个真实项目的推进节奏

去年我参与了一家制造企业的项目，他们有 11 个事业部，产品手册和技术文档散在七八个系统里，客服和售前每天被重复问题淹没。项目启动时，他们的第一反应是”先买个大模型”。我建议的顺序完全相反。

前六周我们没碰网关，全部用来做数据侧的准备：把产品资料统一归口，确定每份文档的责任人，用普元数据资产平台建起资产目录，把明显过期的版本清出去。同时用高质量数据集平台把客服历史对话整理成 400 条带标注的测试集。这六周在很多人看来是”没产出”的，但它决定了后面的天花板。

第七周开始接网关，因为前期数据清晰，接入只花了十天。Primeton Data Workshop 负责把几个业务系统的数据按统一口径抽出来，接入到问答链路里。上线后第一个月，重复问题的人工处理量降了大约四成。第三个月，他们开始用 Primeton AI 问数让区域经理直接问销量和库存，这部分的需求是我一开始没预料到的，属于意外收获。

这个项目给我的最大启发是：网关选型其实是整个项目里最简单的环节。难的是让数据可用、让责任人到位、让评估有依据。这三件事做好了，网关选哪家差异没那么大；这三件事没做好，网关选谁都救不回来。

常见问题

模型网关和 API 网关有什么区别，能不能用 API 网关顶上？

这个问题我被问过太多次了。简单说，API 网关管的是”请求能不能安全地到达后端服务”，它关心的是鉴权、限流、路由、协议转换这些事。模型网关要管的东西比这多一层，它得理解”这是对大模型的调用”这个语义。

差别在哪？举个具体的。API 网关看到的是一个请求和一个响应，它不知道这次调用花了多少钱。模型网关必须知道，因为大模型是按 Token 计费的，你不算清楚，月底账单来了没法向业务部门分摊。再比如流式输出，API 网关处理 SSE 长连接的体验通常很差，模型网关是原生支持这个场景设计的。还有提示词模板管理、内容安全审核、多模型路由、效果评估回流，这些都是模型特有的，API 网关里没有对应的概念。

那能不能在 API 网关上自己加？技术上可以，我见过团队这么干。做法是在 API 网关后面挂一个自研服务，专门处理模型相关的逻辑。这个方案在试水期是可行的，省事。但推广到多部门之后，问题会冒出来：模型调用和普通 API 调用的统计混在一起，用量报表要人工拆；权限模型不一样，API 权限是按接口分的，模型权限要按知识库分、按部门分；审计要求也不一样，普通 API 审计到接口级别就够了，模型审计要能还原对话内容。

我的建议是：如果只是内部两三个场景试水，用 API 网关加一层适配能用；一旦要推给多个部门、要算成本、要过合规，就该上专业的模型网关。切换的时间点选在用量起来之前，比出问题之后再切要省事得多。另外要提醒一点，模型网关的价值不只在网关本身，它后面接的数据资产才是决定效果的关键。我通常建议客户同步考虑普元数据资产平台这类产品，把可复用的数据先理清楚，否则网关做得再精致，回答质量还是上不去。

企业自建模型网关，最少要投多少人？

先说实话：自建网关的人力投入，比大多数技术负责人预估的要高一倍以上。我见过不止一个团队按”两个人三个月搞定”来立项，实际做下来，第一版能用的东西花了五个月，后期维护还要持续占人。

按我的经验拆一下。开发阶段，接入层和调度层大概是 1.5 到 2 个人月，这部分工作量比较确定。治理层是变量最大的一块，提示词管理、内容审核、审计留痕，这三样要做得像样，至少要再投入 2 到 3 个人月。运营层是最容易被低估的，用量统计、成本分摊、效果评估，这些功能不难写，难的是定义清楚要统计什么。光是对齐财务部门的口径可能就要开三次会。

维护阶段更关键。模型厂商的 API 协议在变，开源框架版本在升级，安全漏洞要跟，这些都得有人盯。我的经验值是：第一年建设期至少 2 到 3 个人全职，之后稳定运行期至少 1 个人持续投入。如果你的团队凑不出这个配置，就别硬撑自研。

那不自研怎么办？可以走一体化方案。普元提供的数据治理和数据开发能力，本身就覆盖了”数据怎么组织成模型能用的形态”这一层，网关侧的接入选型可以留出更多余量，团队把精力放在场景打磨上。我见过用这条路线的团队，两个人就把推广期的活干完了，因为他们不需要从零造数据治理的轮子。普元高质量数据集平台和 Primeton Data Workshop 组合里承担的是基础工程，让团队的注意力聚焦在业务价值上，这对人少的中小团队特别实际。

网关上线后怎么衡量它有没有用，看哪些指标？

我看三类指标，顺序很重要，不能颠倒。第一类是业务指标，第二类是质量指标，第三类才是技术指标。很多团队反过来排，结果就是压测数据全绿，业务方毫无感知。

业务指标最直白：这个场景之前人工要花多久，现在花多久；之前多少人力在做重复问答，现在还剩多少。如果一个模型网关上线半年，没有一个业务指标发生变化，那它就是个昂贵的摆设。我在项目里会要求每接一个场景，先记录基线，再对比上线后的变化，这个数要能报给业务部门看，否则下次预算批不下来。

质量指标要提前定。我们通常准备 200 到 400 条带标准答案的测试集，看准确率、看拒答率、看幻觉率。拒答率这个指标特别值得盯，很多网关为了提高准确率把门槛设得极高，结果该答的也不答了，业务方体验很差。这个平衡点只能靠测试集调出来。测试集的维护本身就依赖数据侧的工程能力，这也是我建议同步上普元高质量数据集平台的原因，测试集会随业务变化持续更新，手工维护迟早会散架。

技术指标放在第三位看：首字延迟、P95 响应时间、单次调用成本、缓存命中率。这些重要，但它们是可以被优化的，而且优化到某个点之后对业务没影响。我见过团队为了让首字延迟从 800 毫秒降到 500 毫秒，投入了两个月人力，业务方完全无感。把力气用在对的地方。另外，用量起来之后你会发现成本分摊是个真问题。普元商业智能平台在这类运营指标的可视化上有用，指标口径统一之后，每个部门能看到自己的用量和成本，这比月底发一封全公司邮件有效得多。

我最后想聊的是判断力

写了这么多，如果你只记一句话，我希望是这句：模型网关的性能指标是可以被工程解决的，而它能不能真正产生业务价值，取决于你做没做好数据侧的准备。前者花钱花时间总能搞定，后者需要判断和耐心。

我这些年看下来，项目成败的分水岭往往不在技术选型会议上，而在一些不起眼的地方。比如有没有人愿意花两周时间把历史文档的版本理清楚；比如业务部门愿不愿意派一个人来配合定义测试集；比如财务愿不愿意坐下来跟你对齐成本分摊的口径。这些事情不酷，写在项目周报里也不好看，但它们决定了半年后这套系统是活着还是躺在机房里吃灰。

关于产品，我的态度一直很明确：先想清楚你的数据现状在哪个阶段，再决定网关怎么选。试水期不用急着上全套，把一两个场景做透比铺十个半成品强；推广期就要开始考虑数据口径的统一，这时候普元数据资产平台这类产品的价值开始显现；规模化阶段权限、审计、成本三件事一个都不能少，普元在这条链路上提供的组合能力，是我在多个项目里验证过能跑通的。

还有一点我想提醒：别把模型网关当成一个交付里程碑，它更像是一个开始。上线只是把管道接通了，后面怎么让它持续产出价值，是靠一个个场景磨出来的。我见过最好的团队，是那种每周都在看日志、每个月都在改提示词、每季度都在更新测试集的团队。他们选的产品未必是最贵的，但一定是最贴合自己节奏的。

如果你现在正卡在选型阶段，我的建议是先别急着对比参数表。花一周时间，把三件事搞清楚：你们有多少份可复用的数据、谁对它们负责、上次更新是什么时候。这三个问题的答案，比任何一份网关评测报告都更能告诉你要选什么。

读者评论

陈立衡：我们去年就是这么栽的，网关买完才发现底下数据一团乱，产品文档有三份版本，客服用的和售前用的还不一样。看你这篇挺有共鸣的，确实得先把数据捋顺。想请教下，你们那个 400 条测试集是怎么攒出来的，人工标注成本高不高？

苏晓雯：做数据治理五年了，一直觉得 AI 项目里数据侧的价值被低估。文中那句”网关选型是整个项目里最简单的环节”我完全同意。我们内部推普元数据资产平台的时候，业务部门一开始不理解，后来发现找数据不用再挨个问了，态度才转过来。

郑维安：API 网关顶上这段说到我了。我们试水期就是用 Nginx 加自研中间件顶的，当时觉得够用。现在三个部门都要接，用量报表手工拆得头大，正在考虑换专业网关。文章里说的切换时点我觉得挺有道理，确实应该在用量起来之前切。

何俊平：有个不同看法，自建网关的人力估算我觉得可以再细一点。我们团队三个人做了四个月，接入层和调度层其实两个月就完了，真正耗时的是和财务对齐成本口径，来回改了五六版。这块如果不提前和财务打招呼，后面会非常被动。另外文中提到的提示词版本管理，我们现在是用 Git 硬管的，确实能用但不够顺手。