先说明一下背景大家最近都在讨论“AI 网关”各种网关产品都在往这个方向靠。我实际把 Apache APISIX 接入大模型跑了几个月把能踩的坑基本踩了一遍。这篇东西不是产品文档的复读而是把“API 网关为什么需要变成 AI 网关”以及“在 APISIX 上做 AI 网关最朴素的落地方式”讲透。如果你正在给团队挑方案或者手里有接口要接 GPT、Claude、通义、智谱这些模型这篇文章应该能帮你省不少时间。1. 为什么 API 网关会变成 AI 网关1.1 企业接入大模型痛点在“接”不在“模”先聊一个大家可能都有感触的现象大多数团队接大模型真难的并不是模型本身选哪家而是“怎么接得优雅”。业务代码里直接怼一个openai.ChatCompletion.create()看起来很简单三个星期后就会发现问题开始冒头——团队同时接了 GPT、通义、智谱三家每个 SDK 的请求结构都不一样前端页面里只有一个对话入口后端要写一堆 if-else 去路由到底调哪个模型某个供应商的账号余额用完了整个服务直接报错每次上线升级模型版本都生怕破坏线上对话体验。这些问题的本质是什么是把模型的调用凭证、协议差异、路由策略、成本控制全都散落在业务代码里了。业务代码本不应该关心“这次对话用的是 GPT-4o 还是国内某家的开源模型”它只关心“给我一个能对话的接口”。传统 API 网关这个时候就显得有点不够用了。它擅长做 HTTP 路由、鉴权、限流、灰度但它不理解“prompt tokens”和“completion tokens”的区别也不懂什么叫流式对话SSE更没办法帮你统计“这个月团队 A 在模型上花了多少钱”。于是能看懂大模型语义、又能复用原有 API 管理能力的AI 网关就成了刚需。1.2 AI 网关到底比普通网关多管了哪些事我把 AI 网关新增的职责拆成四个层面这样方便后面和 APISIX 的能力做对应第一层是协议统一。上游模型厂商各说各话OpenAI 是一套协议Anthropic 是另一套国内厂商有的兼容 OpenAI、有的完全自定义。AI 网关要对内收敛成一套标准协议常见的做法是统一成 OpenAI 兼容格式这样业务方只需要面向一个 SDK。第二层是模型路由与灰度。同样的入口网关按策略把请求分给不同模型。比如普通用户走便宜模型、VIP 用户走贵模型新模型先放 5% 流量观察效果。这本质上是把后端服务的“灰度发布”抽象到了“模型维度”。第三层是成本治理。每次请求消耗多少 token、多少钱是 AI 应用独有的计量维度。普通网关顶多记录流量大小AI 网关要能记录 token 数并且按调用方、按业务线去统计和配额。第四层是流式语义的治理。大模型对话基本走 SSE 流式返回字节是一个一个蹦出来的。网关如果还按传统请求一样做缓冲、做超时限制、做重试就全乱了。而且客户端如果中途断开网关得知道去掐断上游的长连接不能让它白白烧 token。有了这四层认知再回头看 APISIX 的 AI 网关方案就清晰了很多。Apache APISIX 本身是开源云原生 API 网关以插件机制出名它做 AI 网关的思路不是另起炉灶而是在原有路由、鉴权、限流、可观测性之上长出大模型相关的插件能力。2. Apache APISIX 凭什么做 AI 网关2.1 插件生态是 APISIX 最大的底气我早期用 APISIX 的一个直觉是这玩意儿像乐高。它基于 OpenResty在 Nginx 的请求生命周期里塞了几十个标准化插件。你不需要理解 Nginx 的复杂配置语法只需要通过 Admin API 往路由上挂插件配置就生效了而且支持热更新。这个特性对于 AI 网关特别重要因为 AI 网关的业务需求其实是复合型的既需要普通网关的鉴权、限流、可观测又需要模型协议转换、token 计量、流式转发。如果一套专门的 AI 网关产品没有这些基础能力你等于什么都得从零造但 APISIX 的情况是key-auth、limit-count、prometheus、proxy-rewrite、open-telemetry 这些插件都是现成打磨过的AI 相关能力只需要往这个框架里“长”出来就行。另一个加分项是 APISIX 控制面和数据面分离的架构。配置统一存放在 etcd 里网关节点从 etcd 拉配置数据面只管转发。这意味着你如果需要水平扩展多部署几个 APISIX 节点即可配置不用每台机器去改。生产环境里我见过很多自研的“AI 网关”就是一个单体服务流量一大就撑不住而 APISIX 这类云原生网关的底子就是为高并发设计的接手模型流量心里有底。2.2 从 API 网关到 AI 网关的两条实现路径实际用 APISIX 接大模型我试过两条路线目前两边都有不少人在用。第一条路线叫通用 Proxy 方式也就是把 APISIX 当成一个普通反代来用。你在 upstream 里配置api.openai.com或者国内厂商的接口域名把路径/v1/chat/completions暴露出去然后通过 proxy-rewrite、自定义插件做鉴权凭证注入。这种方式的好处是简单直接APISIX 版本升级不受影响所有能力都基于成熟稳定的通用插件。坏处是很多大模型细节得自己处理比如各家请求格式不统一、token 计量得自己写插件。第二条路线是使用官方 AI 插件。APISIX 后来提供了专门的 AI 相关插件比如 ai-proxy 这类能力直接在插件配置里声明“我要接 OpenAI”“我要接 Anthropic”“我要接智谱”插件自己搞定协议适配、鉴权、响应解析你只需要把 API key 配进去。网关对下游暴露统一的 OpenAI 风格接口。这条路线的缺点是插件版本迭代快有些功能在不同版本里配置格式有差异使用前得先确认和当前 APISIX 版本的兼容性。从我个人经验来说如果你团队里有一个能写 Lua 插件的人哪怕只是半吊子我其实更推荐先走通用 Proxy 方式把链路跑通等确实需要同时接多家模型、做复杂的模型路由时再用官方 AI 插件也不迟。不要一开始就上一套很重的方案AI 网关最忌讳的就是还没搞清业务需求就先堆了一堆配置。2.3 两条路线怎么取舍对比项通用 Proxy 方式官方 AI 插件方式上手门槛低熟悉 APISIX 基本路由即可中需要理解插件配置项上游适配自己写请求转换逻辑插件内置主流厂商适配token 计量需要额外开发插件可记录日志可采集多模型路由自己写 Lua 插件或配置多个路由可通过插件配置实现版本稳定性高基础能力很少变动中新功能迭代较快适用场景只接一家模型、快速上线多模型、多厂商、治理要求高这个表格不是绝对的只是个决策参考。核心思路是先看清楚自己要管几个模型、几种协议、多少人用再决定用哪条路。我见过不少人一开始就上官方 AI 插件结果遇到配置问题查半天最后退回通用 Proxy 反而顺利跑通了。3. 从零接入把大模型跑在 APISIX 后面3.1 环境准备先让 APISIX 跑起来接入之前先把 APISIX 环境准备好。最简单的办法是用 Dockerapache/apisix 镜像可以直接起但它依赖 etcd 存配置所以需要先启动一个 etcd 容器。启动 etcddocker run -d --name etcd \ -p 2379:2379 \ -e ETCD_UNSYNCED_CLUSTERtrue \ quay.io/coreos/etcd:v3.5.7启动 APISIXdocker run -d --name apisix \ --nethost \ -e APISIX_ETCD_HOST127.0.0.1:2379 \ apache/apisix:3.9.0这里我用的是--nethost方便本地访问 9080HTTP 网关端口和 9180Admin API 端口。生产环境建议用 Docker Compose 或者直接部署到 Kubernetes但先本地跑通验证概念才是重点。启动之后验证一下curl http://127.0.0.1:9180/apisix/admin/routes \ -H X-API-KEY: edd1c9f034335f136f87ad84b625c8f1能返回一个 routes 列表就说明 APISIX 活着。默认 Admin API 的 key 就是上面这个生产环境记得换掉。3.2 方式一用通用 Proxy 转发到 OpenAI 兼容服务我先把最简单的玩法讲清楚用 APISIX 把某个 OpenAI 兼容接口暴露成公司内部统一入口。创建一个 upstream指向 GPT 服务的地址curl http://127.0.0.1:9180/apisix/admin/upstreams \ -H X-API-KEY: edd1c9f034335f136f87ad84b625c8f1 \ -X PUT -d { id: llm-openai-upstream, type: roundrobin, nodes: { api.openai.com:443: 1 }, scheme: https }创建一个 route把/openai/v1/chat/completions转发过去curl http://127.0.0.1:9180/apisix/admin/routes \ -H X-API-KEY: edd1c9f034335f136f87ad84b625c8f1 \ -X PUT -d { id: openai-chat-route, uri: /openai/v1/chat/completions, upstream_id: llm-openai-upstream, plugins: { proxy-rewrite: { path: /v1/chat/completions } } }这里有个细节值得展开proxy-rewrite 插件把外部路径/openai/v1/...改写成上游路径/v1/...这样外部调用方以为自己在访问统一网关内部实际转发到 OpenAI 官方接口。而且路径前缀里带了/openai以后你再加一个/qwen、一个/zhipu路由之间完全隔离互不影响。不过用这种方式有一点要提前想清楚API key 怎么管理直接让业务方在请求头里带Authorization: Bearer sk-xxx肯定不是好主意key 会散落在各个客户端。更稳妥的做法是网关侧把 key 管起来请求进来时网关自己往上加认证信息外部调用方只需要知道网关自己的鉴权方式。怎么实现呢一个办法是写个自定义插件在rewrite阶段把上游Authorization头覆盖成网关保存的 key。APISIX 的插件开发不复杂本质上就是实现几个方法把逻辑挂到请求生命周期的不同阶段。核心代码大概长这样local core require(apisix.core) local _M { version 0.1, name llm-auth-injector, schema { type object, properties { api_key { type string } }, required { api_key } } } function _M.rewrite(conf, ctx) core.request.set_header(ctx, Authorization, Bearer .. conf.api_key) end return _M这段代码的效果很简单每个经过这个插件的请求网关自动把配置的 key 放进 Authorization 头再转发给上游。业务方完全感知不到真实 key 的存在。插件的 schema 定义了配置项 api_key密钥可以通过 APISIX 的 Secret 管理能力引用不必明文写在路由配置里。3.3 方式二用 AI 插件声明式接入 Provider如果你要接入的模型服务商都在官方 AI 插件支持列表里直接用插件方式反而省事。以 OpenAI 兼容的 provider 为例配置逻辑大致是这样curl http://127.0.0.1:9180/apisix/admin/routes \ -H X-API-KEY: edd1c9f034335f136f87ad84b625c8f1 \ -X PUT -d { id: ai-chat-route, uri: /v1/chat/completions, plugins: { ai-proxy: { provider: openai, auth: { header: Authorization, key: sk-xxxxxxxxxxxxxxxx }, model: gpt-4o, stream: true } } }这个配置的含义外部调用/v1/chat/completionsAPISIX 的 ai-proxy 插件接管请求以sk-xxx的凭证访问 OpenAI强制使用 gpt-4o 模型并且默认开启流式返回。认证信息直接写在路由配置里不安全APISIX 支持引用 Secret 资源。你可以在 Admin API 里创建一个 Secretcurl http://127.0.0.1:9180/apisix/admin/secrets \ -H X-API-KEY: edd1c9f034335f136f87ad84b625c8f1 \ -X PUT -d { id: llm-openai-key, type: env, secret: APISIX_OPENAI_KEY }然后在插件配置里用$secret://llm-openai-key引用{ ai-proxy: { provider: openai, auth: { key: $secret://llm-openai-key } } }这种方式比直接把 key 写死在配置里安全一个量级因为至少密钥不会出现在路由导出的 JSON 里而且环境变量轮换不需要改路由。不管用哪种方式接入建议都先跑一个最小验证curl http://127.0.0.1:9080/v1/chat/completions \ -H Content-Type: application/json \ -d { model: gpt-4o, messages: [{role: user, content: 你好}], stream: false }能正常返回一段文本就说明链路通了。3.4 统一鉴权与限流AI 接口也要当普通 API 治理大模型接口暴露出去之后最大的风险是什么是被人刷。对话模型按 token 计费一次普通问答可能几毛钱但如果有人拿你的 key 跑批量任务一晚上烧掉几千块毫不夸张。所以 AI 路由一建好我做的第一件事永远是挂上 consumer 和限流插件。先创建一个 consumer代表“内部业务线 A”curl http://127.0.0.1:9180/apisix/admin/consumers \ -H X-API-KEY: edd1c9f034335f136f87ad84b625c8f1 \ -X PUT -d { username: business_a, plugins: { key-auth: { key: a-secret-key-2024 }, limit-count: { count: 200, time_window: 60, rejected_code: 429, policy: local } } }再把 key-auth 挂到 AI 路由上外部请求必须带apikey: a-secret-key-2024才能访问。同一个 consumer 下的限流配额也能直接生效一分钟最多 200 次调用超了直接 429。这里我想特意强调一句AI 接口的限流阈值和你平时做 API 限流的思路不一样。普通接口限流看 QPS 没问题但对话模型接口的消耗和 token 数强相关。两个请求一个问“你好”一个让模型生成 5000 字长文后者消耗可能是前者的几十倍。所以要真正控制好成本光限制调用次数不够还得在网关层限制单次请求的输入长度甚至在拿到响应后统计 token。单次请求输入长度的限制可以在网关里解析请求体检查 messages 内容的总字符数或预估 token 数超出范围直接拒绝。这个逻辑可以直接写进自定义插件也可以配合 APISIX 的 body-filter 阶段做。总而言之要建立“按次配额 按内容限制”的双层防线AI 网关的限流才算是真正管住了钱袋子。3.5 SSE 流式对话网关上有哪些坑对话模型默认用 SSE 流式返回接口响应头是Content-Type: text/event-stream数据一行一行地蹦出来每行都是data: {...}的格式。这就给网关带来了几个普通 REST 接口没有的问题。第一个坑是缓冲。Nginx 默认会对上游响应做缓冲如果 APISIX 把整个流式响应都缓冲完再一次性返回给客户端那用户看到的就是“转圈半天然后字一次性全出来”这体验是灾难级的。APISIX 本身对流式响应默认透传但如果你开了某些插件比如 body 改写、gzip 压缩、日志采集时把 body 存下来了就可能引入缓冲。排查思路是先确认哪些插件挂在这个路由上逐个排除。第二个坑是超时。大模型生成长文可能要几十秒如果 read 超时设的是默认的 60 秒那超过 60 秒的生成直接断掉。APISIX 在 upstream 里可以配置timeout:{ upstream_id: llm-openai-upstream, timeout: { connect: 5, send: 10, read: 120 } }read 超时我建议设到 120 秒甚至更长。这不是因为每次都要等这么久而是因为流式响应是持续给数据的如果生成途中卡住了网关需要足够的时间去判断是“正常生成中”还是“真卡住了”。第三个坑是客户端断开。用户可能在模型还没生成完就关掉了浏览器。这时候如果网关不管不顾地继续等上游把整个流吐完tokens 就白烧了。APISIX 在处理连接断开时可以通过配置确保将上游连接也关闭。这块需要你在实际日志里观察当客户端断连时APISIX 有没有把请求 abort 掉。如果没有就得用插件在log阶段判断连接状态主动关掉上游连接。4. 进阶玩法把 AI 网关用到生产级别4.1 多家模型负载均衡与故障转移网关接多家模型之后第一个自然的需求就是负载均衡和故障转移。一个简单的实战场景同一个/v1/chat/completions入口网关先调用主供应商如果主供应商返回 5xx 或者超时自动切换备用供应商。这个能力在业务代码里很难做好但在 APISIX 里只需要配两个 upstream 和一个自定义插件做选择逻辑。举个例子假设主供应商是 A备用是 B。你可以在 upstream 层面做权重轮询比如 A 配权重 9、B 配权重 1这样 10% 的请求会自然打到 B 上提前发现适配问题。如果你想要更严格的主备切换就写一个 Lua 插件在access阶段先从配置里读主 upstream如果特定时间内主 upstream 健康检查失败就把本次请求的 upstream 动态换掉。APISIX 的健康检查插件支持主动与被动两种模式。主动健康检查是网关定时去探上游的 /healthz被动健康检查是根据真实请求的响应码来判断节点是否健康。对大模型这种长耗时接口我不建议把健康检查频率设太高因为模型接口本来响应就慢频繁探活既耗 token 又容易误判。一般每 10 秒探一次就够探活可以用很短的空消息尽量别用真实对话内容。故障转移真正要解决的不只是“切换到备用供应商”还包括切换后的一致性。比如用户在多轮对话中上一轮用了 A 模型这一轮如果切到了 B 模型模型风格可能突变。如果你对这个有要求就得在网关里记录会话上下文所用的模型后续轮次回到同一个模型别做无脑切换。这一步 APISIX 本身没有标准插件直接支持需要结合自研逻辑但好在状态存在 etcd 里多个网关节点共享不至于因为负载均衡把会话打到不同节点就乱了套。4.2 Token 计量与成本可视化接入大模型的省心程度很大程度取决于你能不能回答“这个月模型费用花到哪里去了”。要回答这个问题网关必须在每次请求结束时记录消耗的 token 数。最朴素的做法是用日志插件。APISIX 的 http-log、kafka-log、rocketmq-log 插件可以把请求日志推到日志系统。但大模型请求里响应体通常是流式的而且 token 统计不一定在响应头里OpenAI 兼容接口一般在流式结束的最后一个 chunk 里带 usage。要想准确拿到 token 数网关得解析流式响应的结尾。这里提供一个实现思路写一个自定义插件在 body-filter 阶段收集 SSE 数据块当检测到流结束标志data: [DONE]或包含usage的 chunk 时把prompt_tokens和completion_tokens解析出来再拼进日志。这个逻辑听起来复杂但核心其实就两步攒数据、找 usage 字段。有了 token 数成本就能算了。假设 GPT-4o 的输入价格是 2.5 美元/百万 tokens输出价格是 10 美元/百万 tokens一次请求消耗 input1000、output500那么成本就是(1000 / 1e6 * 2.5) (500 / 1e6 * 10)。你把计费公式做成配置表网关在每个请求结束时算好金额写进访问日志或者 metrics再通过 Prometheus 拉取。到月底哪个业务线调用最多、哪个模型最烧钱一目了然。如果你的网关在 Kubernetes 上建议顺便接上 APISIX 的 OpenTelemetry 插件。把 trace 和 token 指标都采集起来排查问题时能直接看到“这次对话到底卡在模型供应商还是网关转发”。4.3 问答缓存省一半 token 钱对话类请求不适合缓存因为每次问法都不一样。但企业内部的很多场景其实是“高频相似问题”比如员工问“报销流程是什么”“年假有多少天”这类问题的答案基本固定。如果每个员工问一遍都去请求大模型浪费的是大量重复的 token。APISIX 的 proxy-cache 插件可以基于 response code 和请求体做缓存。但要小心大模型接口的请求体里往往带用户的上下文或者敏感信息直接拿请求体做 cache key容易把 A 的私有数据缓存下来给 B 看这是隐私事故。所以要做缓存Key 必须精心设计——只取 messages 里的最后一条 user 消息去掉时间戳、用户 ID 等无关字段。还有更狠的一招语义缓存。把用户问题向量化然后用向量相似度去匹配缓存。这个就要引入向量数据库了不是 APISIX 开箱即用的能力但你可以基于现有的系统搭一套。做法是网关收到请求时先去向量库搜相似问题命中相似度高于 0.95 的就直接返回缓存答案不命中再转发给大模型。对 FAQ 机器人来说这个优化能把 token 成本砍掉一半以上。但语义缓存只建议用在知识库问答这种相对固定的场景开放闲聊场景别用否则用户会觉得聊天机器人像复读机。4.4 Agent 场景下网关的新角色最近大模型领域最火的方向之一是 Agent即让模型自主决定调用哪些工具来完成一个任务。一个典型的 Agent 应用要调用的 API 可能有搜索、天气、查库存、发邮件、调内部系统。这些 API 五花八门Agent 在运行过程中会不断发起请求。这时候网关的角色就不再只是管模型的入口而是变成了Agent 的外围控制面。你可以在 APISIX 上把这些工具 API 全部注册成带鉴权和限流的路由模型生成的“调用工具”指令经过网关时每一个子请求都走独立的审计日志。这样你就能看到Agent 在一次完整任务中到底调了哪些工具、每个工具调用花了多久、有没有某个被调用的 API 响应异常导致 Agent 卡住。APISIX 在处理 Agent 这类动态调用时有一个很实用的点支持 WebSocket。很多 Agent 框架的前后端通信直接用 WebSocket 长连接做实时推送。APISIX 对 WebSocket 的支持是开箱即用的只要在 route 里开启相关配置即可不需要额外装复杂的插件。网关在 Agent 场景下还有一个隐藏价值安全护栏。大模型 Agent 经常出现“幻觉”导致生成一个实际上不存在的 API 路径。如果 Agent 在业务代码里直接裸调内部接口系统容易被带偏。而如果所有工具调用都经由网关一条“路径不存在”的 404 就能拦掉大部分异常请求而不是让 Agent 自己去尝试连接内部服务。5. 现场实录我踩过的坑与排查思路5.1 SSE 老断问题不出在网关出在超时有段时间我负责的 AI 接口老是抱怨“回答到一半断了”。从 APISIX 日志看upstream_status是 200但upstream_latency特别长而且响应时间集中在 60 秒左右断掉。一查才发现APISIX 的 read 超时默认 60 秒大模型生成特别长的回答时超过这个时间连接就被掐了。解决方式上一条已经提过把 read 超时调到 120 秒并且在客户端做好“断线重连”的逻辑。但这里我想额外说一个排查思路先区分是网关断的还是上游断的。APISIX 的 access log 里有upstream_response_time和upstream_status如果这个字段正常且接近客户端感知的断开时间基本可以锁定是网关或下游的问题如果upstream_status直接是空或 502那就是上游模型供应商的问题和你网关配置没关系。5.2 上游 Key 别写在代码和 URL 里这个坑我犯过一开始图省事把 API key 放在业务方的前端请求里让网关透传。结果有个内部系统的前端代码仓被误公开key 直接泄露被人拿去跑了几天账单多出来上千块。血的教训。正确的做法就是前面说的——网关持有 key业务方用网关自己的鉴权。业务方最多持有网关发的 appKey泄露了可以在秒级吊销而不会把模型厂商的账户整个暴露。不管你用哪种 APISIX 接入方案请务必在生产环境做一层 key 的隔离。另外所有请求路径里不要出现?api_keyxxx这样的明文参数Nginx 的 access log 会把它原样记下来等于把 key 写在文件里。5.3 各家模型“方言”不一样用网关做统一适配我接入三家模型之后才意识到OpenAI 兼容协议其实并没有想象中那么“兼容”。有的厂商在请求体里支持temperature但忽略top_p有的返回结构里content字段变成了text还有的在流式模式下注释格式也不同。如果让业务代码分别适配简直是个无底洞。网关的解法是做一个“协议方言层”对外永远暴露 OpenAI 标准协议对内根据上游厂商做请求改写和响应改写。APISIX 的 proxy-rewrite 插件可以做路径和请求头改写但请求体 JSON 的深层字段改写就得靠自定义插件了。我的建议是不要做一个大而全的适配器先整理一张表哪些字段是你们业务真正会用到的哪些是模型厂商差异巨大的。只适配业务用到的字段能省下大量开发时间。5.4 连接数被打满压测前先看 keepalive上线前压测刚开始请求量不大一切正常并发一上去网关日志里开始疯狂出现connect() failed。原因是 APISIX 与上游模型服务之间的连接没有开启 keepalive每次请求都新建 TCP 连接到国外的模型服务握手带来的延迟和连接数开销直接打满。APISIX 的 upstream 配置里可以开启 keepalive 池{ upstream_id: llm-openai-upstream, keepalive_pool: { size: 64, idle_timeout: 60, requests: 1000 } }size 表示空闲连接池大小idle_timeout 是连接最大空闲时间requests 是一个连接最多复用多少次。对大模型接口来说连接是长连接不但节省握手开销还能降低延迟。压测时先调这个参数再谈其他优化。我做 AI 网关这段时间最深刻的感受是AI 网关不是某种魔法盒子它依然是一个网关只是把“API 的管理哲学”平移到了“大模型的管理”上。路由、鉴权、限流、可观测这几板斧在普通 API 时代你玩得转搬到模型场景依然吃得开。APISIX 真正的优势在于它没有把这几个能力锁死而是让你能在大模型特有的问题上自由地写插件去扩展。如果你现在正准备把大模型接进公司的业务系统我建议你先别急着选一个“AI 网关专用产品”拿 APISIX 把模型入口管起来、把 cost 算清楚、把流式链路跑稳这套基础打好了后面无论模型怎么换、场景怎么变你都有底气。