做了两年多RAG落地项目我有个特别深的感受很多团队把注意力全放在向量检索、rerank、chunk切分上结果一上生产就发现真正让系统变慢、变贵、变难维护的往往是模型调用这层。AI网关就是专门解决这一层问题的。我们内部沉淀的一套方案叫MAI Gateway定位是面向AI应用、尤其是RAG场景的模型流量治理网关。这篇文章会把这套方案的落地思路、核心模块、配置过程和排查经验完整写出来。如果你正在做RAG知识库、Agent应用或者已经发现多个模型API混用之后调用链越来越乱可以参考这里的做法。基础读者也不用担心我会从问题讲起。1. 为什么RAG落地需要AI网关先看清问题1.1 RAG架构里最容易被忽略的“接入层”RAG的标准流程大家都很熟用户提问检索知识库拿到相关内容拼进Prompt交给大模型生成回答。看起来只有四步但真实生产环境里第四步“交给大模型”远没有想象中简单。你至少要面对这几个问题多个模型厂商的API不能混用不同知识域对模型能力要求不同线上流量有高峰模型服务商容易被限流相同或相似的问题反复请求成本飞速上涨出了问题需要排查却很难追踪是检索失败还是模型回答故障。这些问题全都不在RAG算法层而在模型接入层。我习惯把这一层叫作“模型接入层”或者“AI网关层”。可以用一个生活类比来理解如果RAG系统是一栋办公楼向量库是仓库Prompt工程是加工车间那么大模型API就好比水电煤气——每间办公室都要用但又不能每家都自己去拉管线必须有一个集中管理的总闸。MAI Gateway在这里做的事就是把这套总闸做成可配置、可观测、可灰度、可回滚。它不是帮你做检索也不是替代模型而是让“调模型”这件事变成一种基础设施能力。1.2 没有网关时的四种典型混乱场景先说第一种代码里到处硬编码模型SDK。今天业务A直接调通义千问业务B直接调DeepSeek业务C又调了别的模型。看上去每个人都有自由度实际上每个模型接口参数、鉴权方式、返回格式都可能有差异。等到模型厂商出问题或者要换更优模型时你就要一个服务一个服务去改代码、发版非常痛苦。第二种是没有缓存。用户问“报销流程是什么”上午问一遍下午又问一遍系统每次都把同样的问题、同样的知识片段发给大模型每次都秒回但每次都扣钱。我把这类流量叫做“重复生成流量”它既不产生增量价值还把成本白白推高。如果每天有一万次请求重复率30%每次生成2000 token折合下来一年可能要多烧好几万。第三种是一个模型provider抖动整个RAG应用跟着崩溃。比如某个模型服务在高峰期超时如果你没有隔离和降级所有请求都卡在那里线程池被占满最后连健康检查都挂了。这时候就算检索质量再好用户感知到的只是“系统又崩了”。第四种是审计缺失。企业内部的知识库往往涉及合规问题谁问了什么、系统给了什么回答、用了哪个模型、花了多少钱都需要有据可查。没有网关层的话日志散落在各个业务服务里出问题只能靠猜。这四种场景一旦同时出现RAG项目就很难真正生产可用。2. MAI Gateway核心设计思路与选型2.1 网关定位不是反向代理而是模型流量治理层有人可能会问Nginx、Kong这些API网关已经很成熟了为什么还要单独做一个AI网关我的回答是它们关注的东西不一样。普通API网关按URL、Service、IP来做路由和限流但它读不懂Prompt算不了Token也做不了语义缓存。AI网关更像一个专门为大模型流量设计的“语义层网关”需要在协议层理解模型调用而不是只做四层或七层转发。MAI这个缩写我们内部是这么解释的Model Access Integration Gateway即“模型访问与集成网关”。它要解决的是一组更贴近业务的问题选哪个模型、要不要命中缓存、每分钟消耗多少Token、这次的调用链路是否完整。它和传统网关不是替代关系而是配合关系。外部流量可以先经过Nginx/Kong做基础接入再由RAG编排服务调用内部的MAI Gateway去访问模型。这样普通网关负责南北向安全AI网关负责模型流量的精细化治理。2.2 关键模块拆解路由、认证、限流、缓存、审计MAI Gateway的核心由五个模块组成Router、Authenticator、RateLimiter、Semantic Cache、Auditor。每个模块都对应一个实际痛点。Router是模型路由但它不是靠请求路径来做路由的。我们要求上游RAG服务在请求头里带上类似x-rag-domain这样的标签比如legal、medical、general网关根据标签选择不同的模型。这样做的好处是模型选择与业务代码解耦路由规则变更不需要重新发布应用。Authenticator负责统一鉴权。上游业务不再直接持有模型厂商的API Key而是使用网关分配的AK/SK。模型厂商的主Key只存放在网关环境变量或密钥管理服务里。这样即使某个业务服务被攻破泄露的也只是网关子Key可以单独回收不影响全局。RateLimiter是双层限流一层限QPS一层限Token。大模型厂商的计费和容量都跟Token有关只看QPS远远不够。比如一个请求虽然只有10次每秒但每次输出可能上万Token照样能把上游容量打满。MAI Gateway会在Redis里维护滑动窗口同时统计输入和输出Token。Semantic Cache是语义缓存。RAG场景里用户问法变化很多精确哈希缓存几乎没有意义。MAI Gateway会把用户问题和检索到的知识片段做向量化用相似度判断是否命中缓存。命中之后直接返回历史生成结果可以省掉一次大模型调用。具体策略后面我单独讲。Auditor是全量审计模块。每次请求都会记录traceId、模型名称、Prompt大小、生成Token数、耗时、成本和返回码。这些日志不只在网关侧保存还会通过消息队列送到审计平台供合规和成本分析使用。2.3 为什么选择自研而不是直接套用API网关我不是说自研比开源好而是想说明边界。通用API网关确实可以挂载插件完成一部分功能但做久了你会发现解析Prompt、计算Token、识别模型流式协议、做向量化缓存这些逻辑塞进通用网关的插件体系里会很别扭。升级网关版本、调试插件、压测性能全都会被绑在一起边界很模糊。我们选择独立做MAI Gateway核心原因是希望有一条清晰的“模型治理边界”。模型厂商有变更只改网关新模型上线只加Provider配置想调整成本策略只动路由规则。业务侧统一走OpenAI兼容接口前面已经接好的代码几乎不用动。如果团队没有精力自研也可以使用现成的开源AI网关项目但架构上仍然建议把网关独立成一个服务而不是塞进业务代码里。3. RAG场景下的MAI Gateway行业落地方案3.1 串联知识库检索与大模型调用的标准路径在实际的RAG工程中调用链路通常是这样用户请求先进到RAG编排服务编排服务先做向量检索和混合检索拿到top-k知识片段再组装Prompt然后调用MAI Gateway由网关转发给真正的大模型。网关并不取代检索服务但它在两者之间承担了“模型调用总闸”的角色。这样设计的好处是检索优化和模型策略优化互不影响各司其职。我们给业务侧的SDK大概长这样from mai_gateway.client import MAIGatewayClient client MAIGatewayClient( base_urlhttp://mai-gateway:8080/v1, api_keyapp_ak_xxx ) resp client.chat.completions.create( modelroute:rag, # 网关内路由 messages[ {role: system, content: system_prompt}, {role: user, content: user_query} ], headers{ x-rag-domain: legal, x-rag-tenant: tenant_01 } )关键在于modelroute:rag业务侧不关心实际用哪个模型只告诉网关“这是RAG场景”。真正选哪个模型由网关根据请求头里的domain、scene等标签动态决定。响应里我们会额外返回一个X-MAI-Trace-Id方便后续把检索链路和生成链路串起来。3.2 路由策略按知识领域、成本、时延分发到不同模型一个常见的RAG知识库可能同时包含法律条款、产品FAQ、技术文档和闲聊类问题。让所有问题都走同一个大参数模型成本高又没必要。我们的做法是在网关里配置多条路由规则按照知识领域分发。下面是一个简化的配置示例routes: - name: legal-high-accuracy match: header: x-rag-domain value: legal provider: qwen-max priority: 10 - name: general-cheap match: header: x-rag-domain value: general provider: deepseek-chat priority: 5 providers: - name: qwen-max base_url: ${QWEN_BASE_URL} api_key_env: QWEN_API_KEY timeout_ms: 30000 max_retries: 1 - name: deepseek-chat base_url: ${DEEPSEEK_BASE_URL} api_key_env: DEEPSEEK_API_KEY timeout_ms: 15000 max_retries: 0这里有两个细节值得展开。第一为什么用请求头而不是在网关里做语义分类因为让网关再跑一次意图识别会带来额外的时延和成本而且上游RAG服务在检索时通常已经知道知识领域了把这个信息透传过来更准确。第二priority字段表示匹配优先级当同一个请求同时满足多条规则时优先走法律类高精度模型。类似的需求还有按租户分流、按对话场景分流本质上都是用元信息代替硬编码。在Agentic RAG场景里链路往往是多跳的先判断问题属于哪个子知识库再决定要不要调用工具最后再汇总生成。这类请求通常需要模型具备较强的function calling和长上下文能力。我们会在请求头里增加x-rag-scene: agent把这类流量单独路由到支持工具调用的模型上避免被通用路由误伤。3.3 缓存策略让重复检索和相似问题不再打模型语义缓存是RAG落地里被低估的模块。多数知识库产品有两类问题特别适合缓存一是高频重复问题比如“密码重置流程”“如何提请假”二是语义相同但表达不同的变体问题比如“报销流程是什么”和“我想知道怎么报销”。精确缓存对后者无效但语义缓存可以。MAI Gateway实现语义缓存时会把请求中的用户问题做向量化和缓存库里的历史问题比对当相似度超过阈值时直接返回缓存内容。我们内部通常把cosine阈值设置为0.92命中后响应头会带上X-MAI-Cache: HIT。缓存里不只有生成结果还会带上知识来源引用这样用户看到答案时仍然能知道出自哪个文档。配置项大致如下cache: semantic: enabled: true threshold: 0.92 ttl_seconds: 600 include_search_refs: true需要注意两个坑。第一如果知识库本身更新频繁必须把知识版本号或者批次ID纳入缓存判断否则用户会拿到旧答案。第二涉及用户隐私或强动态数据的请求不要开启缓存比如“我的订单到哪里了”这类请求天然不该缓存。在我们的FAQ类知识库里语义缓存命中率保持在25%到35%之间整体响应时间能从3秒降到0.5秒以内成本下降非常明显。3.4 可观测性从“检索命中率”到“端到端链路”RAG社区常聊Hit Rate、MRR这类检索评估指标但生产环境里光看这些是不够的。检索质量好不代表系统快、便宜、稳定。我们更需要一套能回答“模型调用慢在哪、钱花在哪、哪个Provider在抖动”的观测体系。MAI Gateway在这块会输出一组核心指标再和RAG检索指标合并看。指标名来源说明RAG Hit RateRAG检索服务知识片段是否被正确召回LLM调用耗时MAI Gateway模型生成环节耗时网关缓存命中率MAI Gateway语义缓存拦截掉的重复请求比例Provider错误率MAI Gateway上游模型服务稳定性单次请求成本MAI GatewayToken消耗与单价折算端到端满意度应用层最终用户任务完成率实现上我们用OpenTelemetry为每条请求生成统一的traceId网关响应头里返回这个id。RAG编排服务如果做了埋点那么一次完整的“问题进来-检索-生成-返回”过程就能在链路追踪系统里看到每一段的耗时。当用户投诉回答错误时我先看trace再查审计日志很快就能定位问题到底出在检索环节还是模型选择环节而不是凭感觉排查。4. 实操过程从0到1部署MAI Gateway4.1 环境准备与基础配置这里给出一套最小可运行的部署方式不依赖K8sDocker Compose就能跑起来。需要的东西包括一台Linux服务器或者本地Docker环境、Redis用于语义缓存和限流、一个数据库用于存审计日志流量不大时PostgreSQL就够了、以及模型厂商的API Key。如果你已经通过vLLM或Ollama本地部署了模型也可以把它当作一个OpenAI兼容服务配置进网关。启动配置大致如下services: mai-gateway: image: mai-gateway:1.0.0 ports: - 8080:8080 environment: REDIS_ADDR: redis:6379 AUDIT_DSN: postgres://user:passaudit-db:5432/mai_gateway volumes: - ./config:/etc/mai-gateway depends_on: - redis - audit-db redis: image: redis:7 ports: - 6379:6379 audit-db: image: postgres:15 environment: POSTGRES_USER: user POSTGRES_PASSWORD: pass POSTGRES_DB: mai_gateway之所以把Redis和审计数据库单独拆出来是因为网关本身要保持无状态这样才能在流量增加时水平扩容。Redis一挂缓存和限流会受影响但网关仍然可以转发请求只是成本控制和缓存能力会降级。审计数据库也不应该跟网关同一套存储否则排查问题的时候会互相干扰。4.2 配置一个RAG专用的透明接入层下面是一份更完整的网关配置它把一个RAG场景拆分成了两条路由通用问答走便宜模型Agent场景走支持工具调用的模型。你可以直接抄这份配置改一改server: listen: :8080 providers: - name: qwen-turbo type: openai_compatible base_url: ${QWEN_BASE_URL} api_key_env: QWEN_API_KEY timeout_ms: 15000 max_retries: 1 - name: deepseek-chat type: openai_compatible base_url: ${DEEPSEEK_BASE_URL} api_key_env: DEEPSEEK_API_KEY timeout_ms: 20000 max_retries: 0 routes: - name: rag-general match: header: x-rag-domain value: general provider: qwen-turbo - name: rag-agent match: header: x-rag-scene value: agent provider: deepseek-chat cache: semantic: enabled: true threshold: 0.92 ttl_seconds: 600 limit: qps: 100 tokens_per_minute: 100000 audit: enabled: true driver: postgres这份配置读起来很直白定义了两个Provider定义了两条路由开启了语义缓存、限流和审计。上游RAG服务只需要把domain或scene标签放到请求头里网关就能自动选择合适的模型。后面如果需要接入新模型比如本地私有大模型只需在providers里增加一项再在routes里把某个domain指过去业务代码完全不用动。4.3 灰度与回滚方案RAG项目有三个极其容易打架的变量知识库内容、检索参数、模型版本。如果同时改出问题时很难归因。我们习惯用网关先隔离模型变量具体方法是权重灰度。比如新模型上线时先让10%的流量走新模型90%继续走老模型观察答案质量和耗时。配置示例routes: - name: rag-general match: header: x-rag-domain value: general providers: - name: qwen-turbo weight: 90 - name: qwen-plus weight: 10如果新模型表现不好把它的weight改成0流量立刻全部回老模型。如果新模型只是某些知识域表现不好也可以按路由规则只让特定domain走新模型实现更精细的灰度。另一个实用操作是给Provider增加status: drain。当某个Provider进入drain状态时网关不会给它分配新流量但已建立的流式请求会继续跑完。这比直接拔Key优雅得多适合在模型服务升级或运维窗口期使用。从我们的实操经验来看把灰度逻辑放在网关层比放在业务代码里要省事很多因为业务方不需要跟着发版。5. 常见问题与排查实录5.1 问题速查表以下是我们在生产环境里遇到过的高频问题整理成一张速查表方便先定位再动手。症状可能原因排查路径所有请求变慢或大量超时Provider容量不足或者模型服务超时配置太短看upstream_latency和provider_error_rate把异常Provider临时置为drain语义缓存命中率极低相似度阈值太高或embedding模型不一致查缓存命中样本统一向量模型与维度把阈值降到0.88做对照成本没有下降网关只缓存了最终回答但检索阶段仍然在重复执行启用“检索引用生成结果”组合缓存再看审计日志里的prompt重复度回答质量突然下降灰度权重切到了参数更小的模型查看审计日志里的model字段对比路由权重快速回滚某些用户被限流误杀Token预估不准或全局限流共享按租户拆分限流配额换用模型厂商官方Tokenizer这张表看起来简单但每一条背后都有实际案例。比如限流误杀在一次大促场景里某个租户的调用量突然上涨把全局Token配额打满结果其它租户全被误伤。后来我们把limit改成按x-rag-tenant维度配置问题才彻底解决。所以部署网关时建议一开始就规划好租户维度而不是等到出事故再改。5.2 避坑经验超时、重试、上下文截断先说超时。大模型生成时间本来就不稳定简单FAQ可能1秒返回复杂推理可能20秒甚至更久。RAG场景里还要叠加检索耗时如果网关默认超时设成5秒你会发现大量正常请求被误杀。我们的经验是按路由设置超时通用问答15秒Agent多跳场景30到40秒本地私有模型因为算力有限超时要放得更宽。流式场景还要区分“首字延迟”和“总完成时间”不要用总超时去卡流式连接否则用户刚看到第一个字就被断连。再说重试。面对Provider抖动很多人会不假思索地加重试实际上这是最危险的操作。一个Provider故障时如果每个请求都重试2次网关透出的流量会变成原来的3倍反而把故障扩大。我们只对幂等请求做一次重试而且必须等待至少1秒的退避时间。生成类请求本身就很难保证幂等所以重试策略一定要保守。最后是上下文截断。RAG系统经常把多个知识片段塞进Prompt再加上对话历史很容易超出模型上下文窗口。如果网关不去干预模型可能会把排在后面的关键资料直接忽略导致“一本正经胡说八道”。我们在网关层做了一道保护转发前估算Prompt的Token数如果超过模型max_tokens的一定比例直接返回告警给RAG编排服务让上游压缩历史或裁剪知识片段而不是把截断风险丢给模型。这样才能保证用户看到的答案是基于完整资料生成的。5.3 别把RAG瓶颈全归到检索上最近社区里聊RAG瓶颈聊得很多知识割裂、GraphRAG、Ontology RAG、Agentic RAG这些概念都很热。它们解决的是“怎么让模型在更复杂的知识结构里找到信息”这确实是检索侧的重要升级。但我们也观察到一旦上了GraphRAG或Agentic RAG模型调用次数会明显增加。比如一次多跳检索可能要连续调用模型做判断再汇总生成调用量是普通RAG的好几倍。这时真正的瓶颈很可能从“检索质量”转移到了“模型调用治理”。没有统一的网关多跳调用的耗时、成本、错误处理都会变成新一轮混乱。所以我认为把知识割裂问题交给检索层去解决把模型流量治理问题交给AI网关层去解决是一个比较清晰的分工。这并不冲突而是递进关系。MAI Gateway就是我们在这一递进关系里补上的重要一环。最后说一点个人体会。我见过不少团队一上来就调embedding模型、换GraphRAG、上rerank把检索指标刷得很漂亮但上线后用户体感还是差。后来排查发现大部分超时和费用问题都出在模型调用层。RAG项目越往后做越会意识到“模型流量不可控”才是最大的隐性瓶颈。MAI Gateway这套方案不一定非得自研你可以先用一个轻量的网关把语义缓存和路由做起来再逐步加审计和灰度。顺序很重要先让模型调用可管再做检索优化效果才会被真正放大。希望这篇文章对正在做RAG落地的朋友有参考价值。