大模型火了这两年身边越来越多团队把业务逻辑接到各类大模型上但聊到最后基本都会撞上同一堵墙模型接口到底该怎么统一管理这堵墙光靠写代码是砌不完的。我自己的答案是在所有模型调用前面加一层 API 网关具体用的就是 Apache APISIX。这不是简单地把大模型当成普通后端服务而是把限流、缓存、密钥管理、审计、灰度这些基础设施级能力一次补齐。这篇文章想和你聊聊 APISIX AI 网关能做什么、怎么做以及我几次落地实操里踩过的坑、事后总结的经验。1. 把大模型当成一种特殊 API 来治理1.1 裸调模型接口的四个典型问题先说一个我亲眼见过的典型事故。某个项目把模型 API Key 直接写在前端代码里上线第一天被刷掉几千块钱。这其实不是个例很多人觉得大模型接入就是一个 HTTP 请求的事但当你真把它当成业务核心服务来看会发现它比普通 REST API 难伺候得多。第一个问题是成本不可控。模型调用跟普通接口最大区别是每次请求都按 token 计费而且同一个问题问 100 遍就收 100 遍的钱。常见业务里用户反复提交相似请求、Agent 内部循环调用、上游服务重试都会让成本成倍放大。更坑的是请求体和响应里都计费你没法只按 QPS 去估算花销。第二个问题是供应商配额和限流。云端模型服务几乎都有限流有的按每分钟请求数限有的按每分钟 token 数限。一旦业务量上来直接面对供应商接口写业务代码就会遇到高峰期请求被拒、核心链路抖动的问题而你又很难在业务代码里把“谁消耗了多少配额”说清楚。第三个问题是安全和审计。密钥散落在各个微服务里有的在配置文件、有的在环境变量、有的干脆写进代码仓库轮换的时候满世界找。谁在什么时间调用了哪个模型、消耗了多少 token基本没有完整记录。出了问题只能人肉翻日志。第四个问题是模型切换困难。今天觉得 A 模型效果好明天想换成 B 模型或者想同时接多家模型做对比、做容灾如果每个服务都是自己直接调 SDK改造成本极高。这还没算上那些已经私有化部署在机房里的大模型它们虽然是 OpenAI 兼容协议但在网络结构、负载能力上和云端服务又不太一样。1.2 网关要补的能力清单把这些痛点摆在一起你会发现真正缺的是一个统一的模型访问层。用 API 网关来补这个位置在逻辑上非常顺它本来就在所有流量的必经之路上天然能做认证、限流、灰度、日志。针对大模型场景网关需要额外补的能力大概有四块。认证与配额隔离是第一步。不同业务线、不同团队各自持有自己的凭证网关统一做身份识别再按消费方维度分配模型调用配额。这跟普通接口网关里的 consumer 概念一回事只是把“每分钟请求数”扩展成了“每分钟、每天、每月的 token 预算”。成本治理是第二步。网关能看到完整的 token 消耗可以做重复内容缓存也可以做模型降级。比如把高频低价值的请求路由到便宜模型把复杂推理请求路由到强模型这个策略在网关层做非常顺手。安全审计是第三步。所有模型请求的入参、出参、耗时、token 用量都记录在案配合访问日志和 OpenTelemetry 这类指标系统能看清每条链路的真实成本和质量。多模型路由是第四步。网关拿到请求后按规则决定发给哪家模型、哪个版本、本地还是云端失败后自动重试或降级到备用模型。业务方只知道自己访问的是一个 OpenAI 兼容的入口底层模型随便换。1.3 本地部署模型也需要网关吗很多人觉得“我们用的是本地私有化大模型不走公网不需要网关”。这个想法我一开始也有后来发现不完全对。本地部署的模型虽然省了按 token 付费的问题但 GPU 资源依然是稀缺的。vLLM、Ollama 这类推理服务起来之后企业内部会有多个团队共用同一批 GPU。没有网关时每个团队的调用都在挤占显存和并发出了问题谁也说不清是谁把卡打满了。接入 APISIX 之后可以给不同团队做并发上限、请求优先级、排队策略还能把多张 GPU 卡、多个推理实例的流量做负载均衡。另外本地模型和云端模型混用非常常见。内部系统跑本地模型省钱对外的客户服务用云端强模型保效果。这两种模型放在一条链路里统一管理出了问题互相容灾网关是性价比最高的方案。2. Apache APISIX 做 AI 网关的底气2.1 插件化架构带来的扩展自由就算明白了“需要网关”很多人还是会问为什么偏偏是 APISIX而不是自己写个中间层或者用 Spring Cloud Gateway、Kong 这些我的理由首先是插件化架构。APISIX 基于 OpenResty 和 Nginx核心数据面性能本身就够硬但真正让它适合 AI 场景的是插件机制。它的插件可以热加载配置通过 etcd 下发做到管理面和数据面分离。也就是说你修改限流规则、加一个缓存策略、换一个上游模型不需要重启网关进程这在模型频繁切换的时期非常值钱。我自己用过一段时间自研的“模型代理服务”刚开始只是转发请求、记个日志后来要加限流、要加缓存、要对接告警一版一版地往工程里堆代码。维护到后面配置逻辑、业务逻辑、模型适配代码全混在一起改一个参数都要重新发版。换到 APISIX 之后绝大多数需求变成了一条 Admin API 请求改的是配置不是代码。2.2 不只是代理还有 AI 专用插件如果只是把通用网关拿去代理模型请求那其实任何网关都行。APISIX 让我比较舒服的地方是官方在较新的版本里引入了一整套 AI 插件族专门解决大模型场景下的细节问题而不是逼着我去组合一堆通用插件硬凑。以我实际用过的几类为例代理类插件负责对接不同模型供应商统一转换成 OpenAI 兼容协议限流类插件不只是按 QPS 限还能按 token 消耗去做预算控制缓存类插件可以做语义缓存意思差不多的问题直接命中缓存不用真的再请求一次大模型提示词模板类插件把 Prompt 放在网关节点的配置里业务方只需要传参数变量。这类插件解决的事如果让你自己做通常要写不少代码。比如语义缓存你首先得把文本向量化再算相似度再管理缓存淘汰策略。网关把这些能力变成可声明的配置省事太多。我不建议你直接把别人博客里的插件参数抄过去因为 APISIX 版本迭代很快插件名和字段在不同版本里可能有调整。看官方文档里对应版本的 AI 网关章节那才是准的。2.3 多模型、多云、本地点的一体化路由真正让我确定选择的是多模型路由能力。我们的环境里既有云端模型又有公司内部机房部署的模型还有专门微调过的行业模型。要是没有网关业务代码里就得写一堆 if-else 去判断走哪条路。有了 APISIX 在中间层做路由上游变成了一个逻辑池子同一类业务请求默认走效果最好的强模型但加了按比例分流、按条件灰度、按错误率自动切换这些规则。比如先让 5% 的流量走新微调模型观察生成质量和耗时再逐步放大比例这个能力在普通网关里其实也能做但 APISIX 把路由规则和 AI 插件放在同一个配置体系里操作起来更顺手。我也试过对比几种方案的取舍核心差异大概是这样方案模型协议适配语义缓存细粒度 token 限流多模型灰度切换运维成本自研代理服务需要自己写需要自己写需要自己写需要自己写高通用 API 网关看插件生态多数不具备通常按 QPS可以做但配置复杂中APISIX AI 网关内置插件内置插件支持原生支持低3. 实操从零配置一个能跑的 AI 网关3.1 用 Docker 快速拉起 APISIX实操部分必须有。先说最基础的部署照着做一遍你就明白整个链路长什么样。APISIX 依赖 etcd 做配置存储最简单的跑法是 docker compose 把 etcd 和 APISIX 一起启动。services: etcd: image: bitnami/etcd:3.5 environment: - ETCD_UNSUPPORTED_ARCHarm64 - ETCD_LISTEN_CLIENT_URLShttp://0.0.0.0:2379 - ETCD_ADVERTISE_CLIENT_URLShttp://etcd:2379 ports: - 2379:2379 apisix: image: apache/apisix:3.12.0 depends_on: - etcd ports: - 9080:9080 - 9180:9180 volumes: - ./config.yaml:/usr/local/apisix/conf/config.yaml:ro这里 9080 是数据面端口所有业务请求都走它9180 是管理端口Admin API 用它来配置路由和插件。config.yaml 里需要把 etcd 地址指到 etcd 容器默认配置一般会监听本机 127.0.0.1容器之间要换成服务名。启动之后先访问一下管理端口确认网关活了再往里写配置。整个过程不会超过五分钟。有一件事我特别提醒默认 admin key 一定在正式环境改掉文档里给的那个默认值全网都知道。3.2 接通第一个 OpenAI 兼容模型APISIX 自身不强依赖某个模型品牌它对接的是 OpenAI 兼容协议。现在绝大多数模型服务都提供这种兼容接口云端模型有本地部署的 vLLM、Ollama 也有所以一套配置通吃。先建一个 Upstream指向真正的模型服务地址。比如企业内部某个模型服务的地址是http://model.internal:8000curl http://127.0.0.1:9180/apisix/admin/upstreams/1 \ -H X-API-KEY: your-admin-key \ -X PUT -d { name: openai-compatible-upstream, type: roundrobin, nodes: { model.internal:8000: 1 } }接着配置路由在插件里启用 AI 代理能力。业务方访问你的网关时路径依然是/v1/chat/completions网关负责把请求转发到真实模型地址同时把鉴权信息注入进去。curl http://127.0.0.1:9180/apisix/admin/routes/1 \ -H X-API-KEY: your-admin-key \ -X PUT -d { uri: /v1/chat/completions, upstream_id: 1, plugins: { ai-proxy: { provider: openai, auth: { header: { Authorization: Bearer env:OPENAI_API_KEY } }, model: gpt-4o-mini } } }这里的关键点是密钥不要直接明文写进配置。我习惯把密钥放到环境变量里配置引用环境变量名这样配置入库也不怕泄露。路由建好之后拿 curl 从 9080 端口发一个普通补全请求能收到正常响应就说明链路通了。3.3 加限流、缓存和提示词模板链路通了接下来就是往上面叠治理能力。先加 token 维度限流。普通限流按 QPS 算但大模型场景更关心的其实是“这个团队这个月还能用多少 token”。在 APISIX 里加 AI 限流插件后可以按模型维度、按消费者维度设置配额。比如规定某个内部应用每小时的 token 预算不能超过 100 万超出之后返回提示信息而不是硬闯模型接口。再加语义缓存。语义缓存跟普通缓存不一样不是要求请求文本完全一样才命中而是语义相近就命中。配置时通常会有一个相似度阈值比如 0.9意思是两个请求在向量空间里的相似度超过 90% 就直接复用上次的生成结果。这个对客服问答、政策查询这类重复度高的场景特别管用明显降低成本和延迟。还有提示词模板。把 Prompt 下沉到网关配置里业务方不用在代码里拼接复杂指令只需要传变量。这还能保证所有团队对外服务的提示词口径一致模型版本升级时只改网关配置不用业务方重新发版。这些插件的配置风格跟前面路由一致都是往 plugins 字段里追加一段 JSON。我建议第一次配置时把缓存 TTL 设短一点比如 600 到 1800 秒先观察命中率和内容质量再逐步加长。缓存命中率高不是唯一目标关键看返回内容是不是真的是用户想要的。3.4 把本地 vLLM/Ollama 接进同一网关本地部署的大模型接入方式本质上跟接云端模型一模一样因为 vLLM 和 Ollama 都原生提供 OpenAI 兼容接口。以 vLLM 为例本地起了服务之后默认监听 8000 端口接口路径就是/v1/chat/completions。配置 APISIX 时Upstream 指向127.0.0.1:8000路由 URI 不变AI 代理插件里的 provider 换成合适的本地类型或者直接用兼容模式对接。Ollama 也类似不过默认端口是 11434而且它走 OpenAI 兼容接口的路径同样是/v1/chat/completions。我实际操作中还会多做一步把云端模型和本地模型放到同一个 Upstream 池子里或者配成两条不同路由用权重控制流量比例。比如新上的微调模型先在本地跑对外表现为一个单独的模型名方便跟线上模型做对比测试。等评估指标稳定了再通过修改路由权重逐步切流量。整个过程业务方是无感的他们一直访问的是同一个网关地址。4. 实际落地中踩过的坑4.1 SSE 流式响应被网关“吃了”这是我在 AI 网关落地时遇到的最经典问题。大模型应用几乎都会用流式输出前端打字机效果背后走的是 SSE。本来直连模型服务时一切正常但流量一过网关前端就开始转圈半天不出字。问题根源通常是网关默认开启了响应缓冲。Nginx 为了性能会把上游响应的内容攒到一定量再一次性发给客户端但 SSE 是持续不断的小片段缓冲区没满就一直压着。结果就是模型那边已经生成了一大段内容客户端这边一个字都没显示体验极其糟糕。解决思路是让网关对流式接口关闭缓冲。具体字段在不同版本里略有差异但思路是一样的识别出stream: true的请求在响应路径上关闭缓冲、关闭压缩保持 chunked 传输。同时还要把读取超时时间调大大模型生成长文本的时间很容易超过普通接口的 60 秒默认值不然生成到一半网关就主动断连了。4.2 语义缓存命中率低到怀疑人生语义缓存刚上线时我一度以为插件没生效因为命中率只有个位数。后来排查发现问题出在请求文本的“个性化元素”太多。比如一个客服系统的问题模板是“我的订单 xxx 怎么样了”每个用户都有不同的订单号。语义缓存要识别出这些请求的意图相似不能因为它们表面字符串不同就认为不是同一个问题。另一类问题是请求里带了大量上下文、用户 ID、时间戳这些变量把向量表示搅乱了相似度自然算不高。后来我调整了缓存设计在入缓存之前先做归一化把明显的变量、数字、ID 用占位符替换掉再计算相似度。这样“我的订单 12345 怎么样了”和“我的订单 67890 出什么问题了”就能被识别为同一类问题命中率一下就上来了。这个经验对做语义缓存的人都适用缓存能不能打出效果一半取决于前置的文本清洗。4.3 限流配置太粗暴第一次配 AI 限流时我直接按全局维度限制了一个总配额结果没到一天某个内部工具的突发流量把整个模型的配额全吃完了核心业务反而被限流挡住。这就是典型的治理粒度没设计好。正确做法是把限流维度拆开按消费方限流每个业务线有自己的额度按模型限流便宜模型和贵模型分开控制按优先级限流核心链路配额预留充足非核心任务甚至可以直接丢到排队队列。APISIX 的插件体系支持通过 consumer 身份做区分这就是为什么我前面反复强调网关层面的认证不是可有可无它是后续所有配额管理的基础。对了限流参数也别拍脑袋。先观察一周线上真实 token 消耗曲线再按 80% 水位设配额留出一点弹性。限流太紧会误伤正常流量太松又失去意义。4.4 密钥和多团队权限怎么隔离多团队共用同一个网关时密钥管理容易乱成一锅粥。原本每个团队自己管自己的供应商密钥但放进网关后核心问题变成怎么知道某个请求是哪个团队发的以及怎么限制它只能用自己的密钥。我的做法是启用消费方认证。每个团队注册一个 consumer持有独立的 API Key路由上绑定对应的限流策略和密钥映射。业务请求到达网关时先做身份识别再按身份决定注入哪套鉴权信息、走哪个模型、受什么配额限制。这样出来的效果是团队 A 即使拿到了团队 B 的 API Key也调不动团队 B 的模型配额因为身份对不上。审计日志也一定要开。模型请求的入参、出参、真实耗时、token 用量、命中哪个上游模型全部记录下来。出了问题这是唯一的回溯依据改模型、调限额、做成本分摊都靠它。5. 几个长期值得坚持的经验5.1 先有监控再谈治理我给刚上车的团队一个反常识的建议别一上来就把限流、缓存、 Prompt 模板全都配置得满满当当。先做透明再做控制。第一周只做一件事把所有模型请求的指标接进监控系统看清每个业务线的 token 消耗趋势、调用失败率、平均耗时、生成质量。没有这些数据你做的任何限流阈值都是拍脑袋任何成本优化都是盲操作。等数据积累两三周之后你会发现真正要治理的点和最初预想的经常不一样有的业务看似调用量巨大但缓存命中率高得离谱有的业务调用量小但全是昂贵的长上下文请求。5.2 路由是从简单到复杂长出来的不要第一次就设计一个复杂的多模型路由矩阵。先用一个默认模型把所有流量都交给它跑通链路。然后再根据业务场景拆路由高价值场景走强模型内部提效场景走便宜模型测试流量走本地模型。我在做过一轮模型评估之后把原来“所有流量都打同一个模型”的模式改成了按任务类型路由。复杂推理、代码生成、长文档总结走贵模型简单分类、抽取、改写走便宜模型。成本直接降了大概四成业务效果几乎没有变化。这个优化在网关层做只需要加几条路由规则试错成本很低。5.3 把模型回归评估纳入日常接入 AI 网关以后模型供应商随时可能更新版本你自己也可能微调出新的模型。每次模型变更都不要直接全量切过去而是先走灰度路由让一部分流量用新模型观察生成质量、延迟、错误率这些指标。我在实际操作中会固定一批业务问题作为回归测试集每次切模型前先把这些问题跑一遍人工看输出质量再决定放量比例。最后分享一个我一直在用的组合默认流式请求关闭响应缓冲普通非流式请求保持原样语义缓存只对幂等、重复度高的业务开启绝不给实时创作、个性化对话类请求开缓存限流优先按消费方维度配置再叠加模型维度做第二层防线。这套配置帮我扛住了好几次流量高峰也让我在复盘时能清楚地说出每笔模型开销花在了哪里。
