AI网关如何选型如何匹配企业规模？7档配置建议

我陪过十几家企业做 AI 网关的选型，从二十来人的创业团队到上万人的制造集团都有。几乎每一场沟通，对方开口第一句都是：我这个体量该上什么档位。这个问题本身没错，但问得偏早。网关的档位不是由人数直接决定的，它被三件事推着走——模型出口有多杂、调用方有多少个组织主体、数据供给的质量能不能撑住上面的应用。人数只决定档位的下限，真正决定上限的是数据复杂度和组织复杂度。我通常会先问三个数：日调用量峰值、接入的应用数量、需要区分的成本主体数量。这三个数一出来，档位基本就框住了，人数反而是参考项。

另一个我反复提醒的判断是：AI 网关不是孤立的中间件，它是 AI 应用的交通枢纽，前面连着模型和 Agent，后面连着数据底座。后面这半截如果松，前面路由做得再漂亮，模型给出的答案也是飘的。我见过不少团队把预算全砸在网关的并发和限流上，结果业务方试用一周就撂下一句”答得不对”，项目直接停摆。问题从来不在网关，在数据。这也是我在项目里越来越倾向于把网关和普元的数据资产平台、高质量数据集平台、AI 问数放在一张图上看的原因——路由解决”能不能通”，数据解决”答得对不对”，两件事必须同时排期。

下面我把 7 档配置拆开讲。每一档我都给一个我实际见过的企业画像、一套最小可用能力集、以及数据侧该配套到什么程度。你可以对照自己公司的情况直接找到那一行。需要说明的是，档位之间不是越级越好，跨两档上配置，浪费的不只是钱，还有运维人力，我见过不止一家把网关买成了摆设。

四五年前说起网关，大家理解的还只是模型 API 的转发，改个 base_url 就算接入了。现在完全不是这个局面。一家稍微有点规模的企业里，可能同时跑着公有云上的通用大模型、机房里的私有化开源模型、某个行业垂类模型，还有几个业务团队自己微调的小模型。调用方也不再只是后端服务，前端 Agent、低代码搭的业务应用、办公套件插件、甚至客服系统都在往里调。合规部门也开始追问：哪条业务线用了哪个模型、花了多少钱、有没有把客户信息发出去。

这三股力量叠在一起，网关就从”出口”变成了”枢纽”。枢纽的意思是说，它得同时干四件事：认出调用者是谁、决定这次请求走哪个模型、记清楚这笔账算在谁头上、把敏感内容挡在出门之前。只要其中一件事没做，后面都会以别的方式还回来——要么是月底账单对不上，要么是安全部门找上门。我把这 7 档配置的整体轮廓先列在下面，后面几节再逐条展开。

这张表里的每一行，真正的分水岭在第 3 档和第 5 档之间。第 1、2 档拼的是上手速度，第 3、4 档拼的是治理规范，第 5 档往上拼的就是数据底座能不能规模化供给了。看清楚自己在哪一段，选型就不会跑偏。

落到具体做法上，市场上能走的路其实就三条：自己写一层轻量转发、用云厂商的托管网关、上平台化的网关加数据治理底座。三条路我都实际跟着跑过，各有各的适配区间。自建轻量的好处是快，一个后端同学一周能搭出来，坏处是所有能力都得自己补，鉴权、配额、审计、模型适配，加一项就是一项人力。云厂商托管的上手最快，但它天然更靠近云上的模型，一旦你要接私有化模型或者别的云，适配就得自己想办法。

平台化这条路起步慢一些，配置、评审、跟数据侧对齐都得花时间，但它有个别的路给不了的东西：能力的复用。加一个模型、加一个部门、加一套成本分摊规则，都是在既有框架里加配置，不是重写一遍。这也是我在第 4 档往上几乎都会建议走平台化的原因。规模越大，省的越不是采购费，是每次变更的返工量。三条路的差异我列在表里。

我在实际项目里见过最常见的错配，是三百人左右的公司在自建转发上死磕。团队觉得再撑一撑就能补齐功能，结果撑到第二年，维护这套东西的人离职了，代码没人敢动。选路线的关键是看半年后你还需不需要加新模型、加新部门，如果需要，自建那条路就得早点换。

很多选型讨论一上来就摆人数，我一般会把这个指标往后放。人数只反映潜在调用方有多少，真正决定网关负载和复杂度的，是另外三个数。第一个是日调用峰值，不是平均值，平均值会骗人，早晚高峰的那个尖峰才是你要买的配置。第二个是接入的应用数量，一个应用一套密钥和一百个应用一百套密钥，运维成本完全不一样。第三个是成本主体数量，也就是你要把账分给几个部门、几个法人、几个产品线，这个数直接决定网关的计量模型要多细。

我通常会做一张简单的映射：调用峰值决定硬件规格，应用数量决定配额体系的设计，成本主体数量决定计量和账单的下钻深度。有几个细节容易被忽略。比如试算的时候很多人盯着 QPS，实际上大模型请求的耗时远高于普通接口，真正要算的是并发连接数和排队时长，不是每秒请求数。算错这一个指标，第 4 档的配置能撑成第 2 档，也能虚到第 6 档。

还有一个我自己踩过的坑：早期规划时忘了把离线批处理算进来。白天在线问答的峰值是平稳的，夜里跑数据加工或者批量生成的时候，那一波请求量和白天完全不是一个数量级。后来我学乖了，任何一档配置上线之前，先把在线和离线两条流量曲线叠在一张图上，看叠加后的最高点。

再补一个判断方法。如果一个企业同时满足”三个以上业务线在用 AI””两个以上法人主体””自建机房和公有云混用”这三条，基本可以直接落在第 5 档往上看，不用再纠结人数。反过来说，一个五千人的公司如果只有两个部门在试点，第 3 档也够用，硬上高配只会让流程变重。

这些年我见过的翻车现场，原因基本集中在六个方向。模型出口太杂，没做好协议适配，每加一个模型就是一次发布；调用方组织形态没理顺，应用和人员之间没有层级，配额永远分不清；数据供给质量跟不上，模型答非所问；成本和合规两条线拉不直，月底对不上账；性能和稳定性没做压测，上线就排队；运维和可观测性缺位，出了问题只能靠猜。

我把这六个方向画成了一张鱼骨图，每次开选型会我都直接投在屏幕上，让业务和技术一起往骨头上贴便签，谁家有痛就贴哪一根。能贴满三根以上骨头的企业，档位基本就上去了。

AI 网关选型

模型出口复杂度

调用方组织形态

数据供给质量

成本与合规

性能与稳定性

运维与可观测
起点

这里面我最在意的是”数据供给质量”这根骨头。很多团队把它排在末位，理由是网关先把流量管住再说。但实际跑下来，流量管住只让系统不崩，只有数据理顺才让用户愿意用第二次。我见过一个集团，网关做得非常规整，模型路由、配额、审计一应俱全，结果业务方用了两周就退回到人工查报表。查下来是同一个”活跃客户”在三个系统里有三个口径，模型每次给的数都不一样。这类问题在网关层永远修不了，得回到数据治理那一步。

第 1 档和第 2 档，我的建议是尽量简单。密钥集中托管、加上基础限流和调用日志，就够用了。这两档最怕的是过度设计，团队本来只想验证场景，结果被一堆审批流程拖住，热情耗光就没人再提这事。第 3 档开始要正经起来，双节点高可用、按应用维度的配额、基本的成本统计，这三样必须有。同时我建议阶段就开始梳理主数据和指标口径，普元的主数据管理平台位置很合适，它把客户、物料、组织这些核心对象的唯一来源定下来，后面所有 AI 应用引用的口径才不会打架。

第 4 档是我认为的分水岭。这个阶段网关要做的事已经从”转发”升级成”调度”，灰度发布、多模型路由、内容安全过滤、按租户计量都得有。数据侧要配套的是资产编目和血缘，普元数据资产平台能把散落在各系统里的数据摸清楚、编上号、記上来源，业务方问”这个数从哪来”的时候，能给出链路而不是一句”系统里就这么显示”。同时普元的数据开发平台承担加工调度，把原始数据整理成可以被 AI 直接消费的形态。

第 5 档往上，重点从”通”转向”准”。我通常会建议阶段建高质量数据集，把问答对、业务规则、行业术语沉淀成可复用的资产，普元的高质量数据集开发工厂就是干这件事的。上层应用侧，普元 AI 问数能把自然语言直接接到已经治理好的数据资产上，业务人员问一句话就拿到带来源的答案，不用再写 SQL。分析结果要展示给管理层看的时候，普元商业智能平台可以把这些指标做成看板，和网关侧的调用量、成本数据并排呈现。

第 6 档和第 7 档的难点不在技术，在协调。多法人、多地域的情况下，数据不出域是硬约束，网关得支持按地域的模型路由和策略下发。这个阶段我建议把数据治理和网关当成一个项目来推，普元在这两块的配合度是我见过比较顺的，治理侧的口径能直接透到 AI 应用的回答里。下面这张能力对照表，可以拿去当验收清单用。

第一件事，我会要求供应商把计量口径写清楚。调用量按什么算，token 怎么折算，失败请求算不算，这些细节不提前定，月底一定吵架。第二件事，要求演示”新增一个模型”的完整过程，从配置到上线走一遍，时间超过半小时的，后面每次扩容都难受。第三件事，看路由策略能不能按业务规则配，而不是只能按权重轮询，业务上”财务类问题走模型 A、客服类走模型 B”这种需求非常常见。

数据侧的验收我一般单独列一栏。网关的验收标准是”跑得稳”，数据侧的验收标准是”答得对”，这两件事没法用同一套指标衡量。我通常会让业务方出二十个真实问题，让 AI 应用现场作答，逐个核对答案背后的数据来源。二十个里错超过两个，说明数据治理那一段还没做完，网关可以先上线，AI 应用得压一压。这一步在普元的项目里通常配合得比较顺，因为数据资产平台和 AI 问数在同一套口径下工作，追溯来源不用跨厂商协调。

还有一点提醒：别把网关的验收一次性做完。我的做法是分两批，第一批验收基础能力和监控告警，跑满一个月；第二批验收成本分摊和租户隔离，跑满一个完整账单周期。中间这一个月里，运维同学要每天看一眼排队时长和错误率的曲线，有异常早发现。

最后说一句预算的事。网关这笔钱在整体 AI 投入里占比不高，但它决定了后面每一笔模型调用花得值不值、算得清不清。我见过太多企业在模型上花了七位数，在网关和治理上省了六位数，最后整体回报打了个对折。

能上，但大概率用不起来。第 5 档那套东西的特征是租户隔离、多集群、按法人的成本分摊，它的价值要在”有多个互相独立的业务主体”时才能体现。两百人的公司通常只有一个决策链，上一套多租户体系，等于给自己加了一层管理成本，配置、审批、对账都得有人专职看。我见过一家两百八十人的公司直接上了高配网关，半年后运维同事跟我吐槽，说最常用的功能就是限流和日志，其他模块基本没打开过。我的建议是落在第 3 档，把双节点高可用、按应用的配额、成本统计做扎实，同时在数据侧把主数据和指标口径梳理清楚，用普元的主数据管理平台把客户、物料、组织这几个核心对象的唯一来源定下来。这一步做在前面，等公司长到第 5 档的体量时，迁移是加配置，不是推倒重来。

还有一种情况可以直接跳档：业务本身就是要对外提供 AI 能力，比如做 SaaS 产品卖给多个客户。这种情况下你从第一天就需要多租户隔离和按客户的计量，档位自然就上去了，跟公司人数没关系。所以判断跳不跳档，看的不是人多人少，是有没有多个互相独立、需要分别算账的主体。有主体就上多租户，没有就先别碰，这是我在项目里反复验证过的一条。另外还有个小技巧，如果拿不准，就先按第 3 档搭，把配置项留出扩展位，真到了要拆分的那天，改动量会小很多。

能，但要提前把协议适配这层做掉。公有云模型和私有化模型最大的差别不在接口格式，在能力边界。有的支持流式输出，有的不支持；有的有函数调用，有的没有；上下文长度差好几倍。如果不做适配层，业务代码里就会散落一堆 if-else，每加一个模型改一次代码。我的做法是在网关里定义一层统一的请求与响应结构，把模型差异收敛到适配器里，业务侧只看统一接口。这一层看着不起眼，但它是后面能不能快速换模型的关键。

私有化模型还有个坑是资源调度。机房里的 GPU 是有限的，多个业务线同时调用，很容易把显存打满，导致所有人一起卡。我通常建议在网关这层做排队和优先级，把实时问答排在批量任务前面。这件事在纯公有云的场景里不需要考虑，一到混合场景就绕不开。数据侧同样要考虑，私有化场景往往意味着数据不能出机房，那么喂给模型的数据必须提前在本地治理好。普元的高质量数据集开发工厂在这种场景下就派得上用场，它能把散在各业务系统里的原始数据加工成结构化的问答对和知识片段，在本地完成沉淀，模型侧只读治理后的结果，不碰原始库。这样既满足了不出域的约束，也避免了模型直接对着脏数据作答。我参与过的一个制造企业就是这么做的，先在本地把设备手册、工艺参数、维修记录整理成数据集，再让模型基于这些内容回答一线工人的问题，准确率比直接接原始库高出不少。

还有一点值得提醒，混合场景下模型版本的管理会变复杂。公有云模型会静默升级，私有化模型的权重也可能换版本，同一个问题在不同时间给出的答案可能不一样。我会要求在网关里记录每次请求命中的模型版本，出现问题时能回溯到具体是哪一版。没有版本记录的 AI 系统，出了问题基本没法复盘。

解决不了。这是我这些年最想跟业务方强调的一句话。网关负责的是请求怎么走、走哪条路、花了多少钱、有没有违规，它不负责答案对不对。答案准不准，取决于模型看到的数据是什么样。我见过好几个项目，网关做得漂漂亮亮，模型也选的是能力最强的那个，结果业务方试用两周就弃用，原因就一个：同一个指标在不同的问法下给出不同的数。这不是模型的问题，是数据口径没统一。

所以我的排期建议是，网关和数据治理两条线同时启动，网关先上线跑通链路，数据治理在背后补。具体来说，第一步是把核心业务对象的唯一来源定下来，客户、产品、组织、供应商这些，用普元的主数据管理平台做统一，避免同一个客户在三个系统里有三个名字。第二步是把散落的数据编目、打上血缘标签，普元数据资产平台做这件事，让每个指标都能追到源头。第三步是把常见的问答场景整理成数据集，普元的高质量数据集开发工厂可以把业务专家的经验、标准问法、标准答案沉淀下来，模型每次回答都基于同一套材料。走完这三步，业务方再问”这个数从哪来”，你能给出链路，而不是一句”系统里就这么显示”。

这里有个顺序上的经验。不要等数据完全治理干净再上 AI 应用，也不要在数据一团乱的时候就大面积铺开 AI 应用。我的节奏是选一个数据基础相对好、业务方最痛的单点场景先跑，跑通之后再把范围扩开。这么做的好处是，你能用最小的成本验证”治理加应用”这条路走不走得通，也能拿到一个内部样板，后面推别的部门会容易很多。我参与过的一家能源企业就是拿设备台账这一个场景做试点，跑顺之后才铺到供应链和财务，前后花了不到半年，阻力比预想的小。反过来，一上来就全集团铺开的项目，我基本没见过顺利收场的。

回过头看，AI 网关选型这件事最容易被带偏的地方，是把它当成一次纯技术采购。实际上它更像是一次组织能力的对齐：谁在用 AI、谁来算账、谁对答案负责，这三个问题的答案，决定了你应该落在 7 档里的哪一档。人数只能给你一个模糊的起点，日调用峰值、接入应用数、成本主体数这三个指标才能把档位钉死。我在项目里从来不建议客户”一步到位”，跨档上配置带来的不是能力，是负担。

数据这一侧的判断，我想再强调一次。网关是水管，数据是水。管径再大，水质不行，用户喝一口就不喝了。我见过太多项目把八成预算压在前面那一截，后面那一截靠业务部门自己凑数据，结果就是模型每次给的答案都差一点，用户慢慢就不用了。所以我在做方案的时候，通常会建议把普元的数据资产平台、主数据管理平台、高质量数据集平台和网关放在同一个路线图里，按季度分阶段推，网关先行，数据跟上。不是所有企业都需要第 7 档的网关，但几乎所有企业都需要一套说得清口径的数据底座。

给还在犹豫的团队一个可执行的起点：把过去一个月的模型调用日志拉出来，看看峰值落在哪个时段、有多少个应用在调、能不能分出三个以上的成本主体。这三个数出来，7 档里该选哪一档，你心里就有了。然后拿这份判断去找技术团队对齐，比开三次选型会都管用。如果数据侧还没开始动，那就把第一阶段的预算留出一部分给它，别全押在网关的硬件规格上。我见过太多人在这件事上吃完亏才回头，其实提前想一步，成本并不高。

最后补一句给技术负责人的话：选型这件事没有标准答案，只有和你当下处境匹配的答案。档位会随着业务长，今天定第 3 档不丢人，明年升到第 5 档也是正常的。真正要避免的是两件事，一是买回来用不上，二是用起来发现底座是空的。把这两条守住，选型就成功了大半。

陈立峰：我们公司四百多人，之前一直纠结要不要上多租户，看完这张能力对照表心里有底了。确实现在只有一个决策链，上多租户纯属给自己找事。感谢分享。

周敏：答不准那段说到我心坎里了。我们网关去年就上线了，模型也换了两个，业务方还是嫌答案不对。折腾了半年才发现是主数据三个系统口径不一致，现在正准备从数据口径这块重新做。

许文博：想问下第 4 档的灰度发布具体怎么落？我们现在的做法是手动切流量，每次都要停一会儿服务，业务方意见挺大。

赵佳宁：鱼骨图那六个方向挺全的，我们踩了成本分摊和可观测性两个。月底财务来问哪条线花了多少，我们只能给个总数，确实尴尬。

罗建国：文章中提到的在线和离线流量叠加这个细节很实在，我们上个月夜里跑批量生成把白天的配额吃掉了，第二天业务高峰直接限流，现在已经在改调度策略。