1. 为什么我会在自己的RAG项目前面硬塞一层网关先聊聊痛点项目忙了半年多RAG系统总算是从demo阶段磕磕绊绊走到了能给多条业务线提供检索服务。但问题也随之来了业务线多了各自的Prompt模板、模型偏好、召回参数都不一样全都堆在一个服务里改一次配置要发一次版外部调用方一多有人写了个死循环在那边疯狂请求直接把LLM服务的配额给打爆了更别提偶尔出现“某个输出是不是合规”这种需要事后追溯的问题连日志都散在三个地方查起来非常折磨。我一开始也觉得RAG的核心在检索、在embedding、在rerank上网关这种东西“又不产生检索结果何必加一层”。但后来一次次在凌晨被告警叫醒之后我承认当时的想法太天真了。RAG本身并不是一个“模型服务”而是一个复合系统。检索链路长、外部依赖多、调用方杂在这种场景下缺的不是更多的检索技巧而是一层能统一控制进出、承载治理规则的“边界”。这也是我最终被MAI Gateway吸引的核心原因——它解决的问题恰好是RAG系统做大之后最常被忽略的那部分。这篇文章我不想讲什么泛泛的AI架构趋势就聊实际落地过程为什么选它、改了哪些配置、踩了哪些坑、接入前后的数据变化以及哪些场景我明确不建议上网关。如果你也正在维护一套RAG服务正被多租户、限流、审计这类非检索问题搞得头大那这篇文章应该能给你一些可复用的参考。1.1 RAG链路中那些不性感的公共组件我们都喜欢聊召回率、Hit Rate、Rerank模型怎么调因为这些指标直接关系到RAG“聪明不聪明”。但一个RAG服务真正上线后日常最花精力的根本不是这些。我随手列几个真实存在、但特别容易被低估的问题每个业务线调用RAG时的鉴权和配额都不一样有人用API Key有人用IAM角色有人干脆先裸调出了事再补同一个知识库背后可能要切换不同的底座模型今天是这个开源模型跑得稳明天那个商用模型便宜切换要方便检索回调了向量库、Doc解析服务、Rerank服务、LLM服务一条请求链路四五个hop任何一个环节超时调用方只报“你不知道吗你的接口好慢”Prompt里可能带着敏感业务信息既要能追溯谁在什么时间调了什么库又不能把全量日志摊得满屏幕都是。这些东西在架构图里一个都看不到就像厨房里的水管和燃气管道不装不行装的时候又觉得不涨KPI。我当时的判断是如果继续把这些治理逻辑散在业务代码里早晚有一天会变成“人人可改、无人负责”的混沌状态。RAG项目真正需要的是一个独立的、可观测的、集中控制的入口层。1.2 多业务线接入后的失控现场说一个真实场景。我们当时同时服务着三个业务方一个是内部智能助手调用频次高、单次请求短一个是离线批量分析任务一次请求会连续调用数十次检索还有一个是外部客户demo时不时并发飙一下。三条线的特点完全不同但最初都走同一个RAG服务接口。混乱从那天下午开始离线批量任务调度系统抖动重试机制失效导致在二十秒内打出了接近十万次请求由于没有任何限流这些请求直接穿透到向量数据库和LLM服务商LLM服务商的账户余量被迅速消耗触发风控把主账号直接冻结所有业务方的线上请求全部失败包括内部智能助手。事后复盘时我发现光是排查“这些请求来自哪里”就花了不少时间。服务日志里有请求来源IP但没有租户维度标记向量库的慢查询日志时间对不上LLM服务商后台能看到消耗激增但没法跟具体业务绑定。整条链路到处都是信息孤岛。那一刻我特别确定网关不是可有可无的锦上添花而是直接避免同类事故的必需品。1.3 问题本质缺的不是功能而是“门口保安”做了不少功课对比后我在MAI Gateway上找到了几个能直击痛点的能力路由可以把多个模型源统一纳管在RAG链路里既能代理LLM令牌也能代理向量库/重排服务的敏感接口限流可以按租户、按API Key、按目标上游粒度分别配置审计日志自带租户维度的元信息还有多级熔断和容错策略。它的定位正好补充了RAG服务与底层模型/检索设施之间的空档。借用我同事的一句话RAG好比一栋大楼检索模型是房间里的家具向量库是储物柜Prompt是装修风格但TCP/IP、租户、密钥、流量配额、审计记录这些是整个大楼的安保系统。MAI Gateway就是那个站在门口的保安——每次有人进出都盘问清楚才不至于什么人都能上楼。有了这个认知落地决策就顺理成章了。2. MAI Gateway落地前的选型与边界它不是另一个AI中台决定引入MAI Gateway之前我先把团队内部关于“网关”的几种理解对齐了一遍否则很容易买椟还珠。有人觉得“这不就是另一个Ingress吗K8s里加个路由不就行了”有人觉得“凡是中间加层都是性能损耗能不加就不加”也有人说“是不是以后所有鉴权、计费逻辑都得写在这层了”。这些都是对网关定位的典型误解。2.1 为什么它叫“AI网关”而不是SDK或中台传统SDK是把一些功能封装成库嵌入到每个服务内部适合“所有调用者都愿意改代码”的理想情况。中台则是把很多业务能力重构成一个平台成本和周期都很大。而AI网关是一个独立的进程/服务它在网络层面代理请求调用者以正常HTTP访问不需要改动调用方的核心代码统一由网关这层做协议转换、密钥注入、策略匹配。这在RAG场景里尤其关键。RAG服务的调用方可能五花八门——有Java后端、Python脚本、低代码平台的HTTP节点、甚至Excel里的VBA请求如果要求他们都接入SDK推行成本极高。但通过网关他们只需要改一个base_url剩下什么都不用动。2.2 与传统Ingress/API网关的分工差异我在最开始的部分对比过K8s Ingress与传统API网关它们擅长的是“服务路由、负载均衡、TLS终结”对HTTP路径和域名比较熟但对AI/RAG场景里更深层的语义基本无感。比如传统API网关不知道“modeldeepseek-r1”和“modelazure-gpt4o”是两种不同成本、不同速度的目标它不知道“这个调用方的天配额还剩多少额度”它不理解Prompt消费的Token数与计费的关系更不会帮你把Rerank、向量检索这些内部上游的调用也做统一监控和限流。MAI Gateway落在我这个场景里的正确分工是外层依然保留K8s Ingress负责南北向流量接入和TLS卸载MAI Gateway则专门处理AI语义层面的策略——模型路由选择、租户级别配额、Token计量与审计、多上游容错。这样一来各司其职不会互相抢节拍也让运维不需要在Ingress的控制器上写一堆奇怪的AI插件。2.3 什么情况下我会明确不建议上网关把这么一层加在前面确实不是所有RAG项目都合适。我在评估过程中给自己列了一个“劝退清单”如果RAG服务只有单一业务线、单一模型、调用量很低那直接写好鉴权中间件就够了再加网关只是增加链路耗时如果团队对网络基础、安全策略没有运维能力网关本身也要投入配套措施反而是包袱如果RAG还在快速实验阶段Prompt和参数一天改三次那先在代码里保留灵活扩展点别过早引入重量级组件。客观来说引入AI网关的收益曲线更偏向“多租户、多模型、治理要求高、故障影响面大”的系统。我之所以在这个阶段落地是因为我们正处于这几个条件的交叉点。3. 从0到1的落地过程路由、鉴权、限流、监控四件事选型和边界对齐之后落地其实就是围绕四件事展开的路由配置、鉴权与租户识别、限流策略、观测与审计。每个环节都有不少值得说的细节。3.1 路由与模型配置让上层调用方对“模型源”无感我先说路由。RAG场景里一个典型的检索请求往往不只访问一个模型。比如一个用户问“某产品线的线上故障怎么处理”完整流程是用Embedding模型把问题向量化到向量库召回候选片段再用Rerank模型对候选重新排序最后把TopN内容交给生成模型。这中间不同环节会用到不同模型源。MAI Gateway的做法是把这些模型源统一配置成“目标上游”然后通过路由规则将请求分发到正确的地方。实际配置层面大致这样的思路以下是简化版示例# route-example.yaml routes: - name: rag-embedding match: path_prefix: /v1/embeddings upstream: primary: internal-embedding-service:8008 fallback: cloud-embedding-api - name: rag-rerank match: path_prefix: /v1/rerank upstream: primary: internal-rerank-service:8010 fallback: cloud-rerank-api - name: rag-llm match: path_prefix: /v1/chat/completions upstream: primary: azure-openai-endpoint fallback: local-vllm-endpoint:8030这种路由设计带来的直接好处是上层调用方永远只跟网关约定路径和请求格式不需要关心今天模型部署在哪、主要上游是否降级、是用云上还是本地。模型部门夜里做轮换也不需要提前通知所有对接方改SDK或base_url。第二个好处是天然支持“新旧模型灰度”。我们曾经想从某个开源模型切到商用模型又在担心中间那里效果回退。传统做法是在RAG服务里加开关然后推进度百分比。有了网关后直接按调用方维度进行路由权重分配先让某个内部测试账号走新模型观察结果稳定几天后再逐步提高权重最后切到新上游。整个过程不需要改一行业务代码。3.2 鉴权与租户识别把“谁是调用者”彻底固定下来多业务线并存时网关必须很清晰地知道“这个请求属于哪个租户、什么角色、用哪个API Key”。MAI Gateway的鉴权模块支持把API Key、JWT、Basic Auth等绑定到租户鉴权通过后会把租户信息注入到请求头里上游服务可以通过特定请求头拿到租户标识。我们当时的落地方式是每个业务线分配独立API Key按环境区分生产、预发、测试内部服务使用服务账号走JWT方式互认网关在发给上游的请求里注入统一的租户Header让RAG服务的日志也能天然带租户维度信息对于特定敏感知识库在网关注入了“读到结果但脱敏回传”的替换逻辑而不是让业务方自己去处理敏感字段。有一个小环节让我印象特别深接入网关前我们一直无法回答“某天某个知识库的检索量是哪条业务线贡献的”这个问题。接入后的第二天安全同事来要数据我直接在网关后台按租户、按时间范围筛选一份审计表导出就搞定了。租户信息的规范化价值在不到四十八小时内就得到了验证。多租户的配额管理还能在网关层面实现成本拆分。每天凌晨网关会自动汇总每个租户在模型调用上的Token消耗按照配置的价格表换算成费用再同步到内部结算系统。相比以前靠自研脚本去各平台拉账单然后手工匹配现在的数据要干净得多。3.3 限流与配额从“一刀切”进化为“按租户精细化”限流部分我前后调整过好几轮。最初是比较粗的一条全局QPS限制后来发现这种“一刀切”策略对多租户极不公平内部智能助手偶尔的瞬时峰值会把外部客户demo的调用全部挤掉。这会让客户觉得我们的服务不稳定特别是正在演示的阶段挂掉非常尴尬。最终我参考MAI Gateway的策略配置按维度分层限制# rate-limit-example.yaml rate_limits: global: qps: 200 tenant_rules: internal-assistant: qps: 120 burst: 80 batch-analysis: qps: 30 burst: 20 external-demo: qps: 20 burst: 10 model_specific: llm-high-cost: token_per_minute: 80000这里有几个值得关注的点QPS限制是平峰期的“稳定器”burst字段允许短时突发但不至于打垮上游模型维度限制Token/分钟比单纯限制请求次数更贴近真实成本因为一个多轮检索请求可能消耗几千Token不能用“请求次数”一概而论限流触发时的响应策略是可以配置的我选了返回429 标准Retry-After Header这比直接断开连接友好得多至少调用方知道“我稍后再试就行不是链路崩了”。我实测过一个小型压测把某个租户的QPS调到1然后用脚本狂发10个并发网关能准确执行限流返回预期状态码和响应头。这为后来“书面承诺某某租户QPS上限”提供了底气因为一切有据可查。3.4 监控与审计不能只有指标还得有故事线监控这块我很少看到有文章具体写。MAI Gateway提供的基础监控指标包括每条路由的请求量、P50/P95/P99延迟、错误码分布、Token消耗量、按租户维度的调用量。这些指标可以通过Prometheus标准格式暴露出来直接接入我们已有的Grafana面板。我个人的建议是不要只看“平均延迟”要拆开看每个环节。RAG链路中Embedding、向量检索、Rerank、LLM生成每个环节的延迟特征差异非常大。尤其向量检索的P99容易在数据量增长后突然恶化如果只盯着整体接口延迟很难定位是哪一环变慢了。我们当时的做法是在网关的访问日志中做链路标注把一次检索请求的内部调用按阶段打上时间戳然后用日志分析工具提取各阶段耗时曲线。这个“故事线”式观测比单纯看指标面板有用得多。另外是审计日志。我们是按内容合规要求把“哪条Prompt、哪个租户、调用过哪些知识库、召回结果是什么”全部记录下来并做加密存储定期归档到冷存储。这里的粒度需要平衡全量存Prompt文本会非常占空间只存元信息又无法回溯问题。我最后的方案是默认开启元信息审计对敏感知识库才开启全文审计。这个取舍我认为在实际生产环境中很有参考价值。4. 真实效果与定量对比没有数据就没有说服力接入MAI Gateway跑了大约三个月后我做了一次系统性的对比数据来自监控系统和网关报表下面这张表是核心结果对比维度接入前约一个月接入后约一个月备注因上游配额耗尽导致的故障次数2次大故障波及所有调用方0次网关限流熔断把故障限制在小范围平均故障定位时间40分钟以上约8分钟全链路日志统一到了网关新业务线接入平均周期2-3天联调鉴权改造半天只需要注册Key和路由策略模型切换上线耗时需要在服务里改代码发布分钟级完成灰度切换路由权重实时生效租户成本数据准确性模糊估算精确到API Key粒度网关自带计数和计价换算调用方误用导致的资源损耗多次出现无法追溯基本消失配额透明超限即429有了这些数据我后续在很多场合都能直接把话说明白AI网关不是性能的敌人而是稳定性的护城河。当然网关自身引入的毫秒级代理延迟确实存在但在RAG链路动辄2-5秒的整体耗时里这几乎可以忽略不计。4.1 两个感知最深的改善第一个是故障域隔离。以前任何一条业务线的一次异常洪峰都可能把共享的模型配额打空进而拖垮所有人。接入网关后即使某个租户突发异常网关也能在配额层将其拦截其他租户完全不受影响。第二个是可灰度、可回滚。我们后来几乎每个模型版本上线都要先通过网关切一小部分流量灰度。某次新模型上线后在灰度阶段就发现引用格式有严重问题我们直接从网关上把流量切回旧模型全流程耗时不到五分钟。放在以前这种事故意味着要从代码仓库回滚、重新构建镜像、滚动发布一小时都未必能恢复。4.2 网关自身成为RAG服务的新瓶颈时怎么办有人可能担心网关自己挂了怎么办我的答案是“永远不要让网关成为单点”。MAI Gateway支持多实例部署且路由配置存储在外部配置中心可以随时启动新实例水平扩容。我们在生产环境部署了两个可用区各双副本前面用K8s Service负载均衡。平时大部分请求都能正常打满有一次特意做了主动摘除一个实例的演练另一个实例完全无感接管没有出现请求中断。要说明的是这种高可用部署并不能掩盖“多一跳延迟”的事实但它可以通过合理的容量规划和监控来消化。网关的CPU和内存占用其实不高因为它主要的计算都在策略匹配和请求转发上不像RAG服务要做向量相似度计算和模型推理压力不在同一个量级。5. 实战中的坑与最终建议这些细节可能救你一命落地MAI Gateway并不是一路顺畅。我在这个过程中踩过不少坑这些问题在官方文档里未必会写得很直接但对后来者来说可能特别有价值。5.1 流式响应引发的超时谜案第一次调试带流式输出SSE的LLM请求时我发现网关频繁报超时。曲线很反常普通非流式请求一切正常一旦调用方使用流式输出网关到上游的连接在约三十秒后就会中断。查了很久才找到原因MAI Gateway的默认读超时是三十秒而上游模型首token响应时间偶尔会超过这个阈值特别是冷启动或调度排队时三十秒内没等到第一个token网关就主动断连了。后续我们做了两项调整一是把针对LLM路由的读超时时间加大到九十秒并开启“流式空闲超时”独立参数二是在网关和模型之间使用心跳keep-alive隔一段时间发一个空行或占位注释避免前端和网关都误判连接已经死掉。如果你也遇到“流式响应偶尔中途断掉”或“首字迟迟不来”的情况可以先往这个方向排查。5.2 不要把业务策略全塞进网关起初我确实“贪方便”把一些业务判断逻辑也搬进网关比如“某些知识的检索必须强制走某个知识库”“某些租户不能访问某标签内容”。虽然网关支持请求改写和策略插件但这样做会带来灾难性后果网关的策略代码一旦出错影响的不只是某一个服务而是所有经过网关的调用方爆炸半径太大了。后来我重新划分了职责。网关只做“通用接入治理”路由、鉴权、限流、审计、灰度。而跟业务语义强相关的内容过滤、知识库选择、Prompt构造仍然保留在RAG服务内部不混在网关这一层。这个边界后来被证明极其重要因为RAG服务里的业务逻辑迭代频率非常高如果放在网关我们可能每周都要发一次网关版本不仅效率低还容易引发更大的故障。5.3 路由规则一定记得版本化管理这算是我最想吐槽的教训。网关的路由和限流策略本质上都是“可执行的配置”但最初团队直接用后台页面编辑改完保存即生效没有经过任何代码评审。某次有人手滑把一个路由的权重全部切到了无tail的上游线上检索直接失败了一大片而且当时根本看不出来谁改的。踩过这次坑后我立刻把网关配置全部纳入了Git仓库管理并接入了CI检查# 伪代码示意配置校验后推送到配置中心 mai-gwctl validate config/routes.yaml mai-gwctl apply config/routes.yaml --envprod这个流程上线后后续所有配置变更有记录、有负责人、可快速回滚。整个过程中最核心的心得就是“能用代码和Git管理的就不要依赖手工人肉操作。”这个原则放到AI网关这种关键基础设施上尤其重要。5.4 最后的几条实操建议如果你也准备在自己的RAG项目里落地AI网关我这几个建议应该能帮你少走不少弯路先定义好租户模型再动手。没有清晰的租户划分后续的所有限流与审计都会变成一团乱麻别一上来就切全量。先把某个低风险业务线切到网关走一段时间确认稳定后再逐渐扩量Prometheus监控面板一定要提前建好。没有可视化数据支撑后续跟业务方解释“为什么请求被限流”会非常吃力定期审查网关自身的配置复杂度。如果发现规则越来越多、越来越绕及时做梳理和清理防止网关变成一个无人能维护的“毛线团”。说到底MAI Gateway对我而言不是某个具体组件的胜利而是“RAG系统治理”理念的一次落地。搜索再好、模型再强如果调用边界混乱、租户不可区分、流量没有保护系统迟早会在某个深夜给你上一课。希望这篇真实案例能给正准备构建RAG服务的朋友一点参考。