很多朋友第一次听到 AI 网关第一反应往往是“这不就是 API 网关套了个马甲吗”——这个判断对了一半。API 网关管的是接口路由、鉴权、限流这些 AI 网关都继承但 AI 网关真正要解决的是模型切换、Token 计费、流式响应、多模态格式适配这些和 AI 强绑定的问题。这篇文章我准备从一个实际场景切入拆开讲讲为什么多模型时代应用层需要这样一个“中间层”也把我在项目里踩过的坑和存下的经验一并分享出来。什么人适合读这篇文章正在做 AI 应用、纠结要不要上多模型或者已经在为多模型的接入和维护头痛的研发、架构师、技术负责人。如果你还停在单模型阶段读这篇文章的好处是能提前看清未来要面对的问题避免在架构上走回头路。1. 多模型时代的真实困境1.1 你以为是自由选择实际是被模型厂商“绑架”我参与过一个智能客服项目起步阶段只接了一家模型 API团队当时的约定是“非必要不换模型”。理由是简单代码里到处是模型 SDK换模型的工作量太大不想碰。结果半年后模型厂商调价账单翻倍产品组慌了要求立刻切换模型。我翻了一下代码SDK 的实例被散落在四十多个文件里有的直接 new 客户端有的依赖全局单例有的把模型返回的错误码写死在业务判断里。真要换模型先要梳理所有调用点再逐个适配新 SDK还要针对新模型的参数语义调整业务逻辑——保守估计一个多月期间所有 AI 功能冻结。这种困境的本质是架构问题不是“换哪家模型”能解决的。任何单一模型厂商的 API一旦和业务代码深度耦合你就失去了议价权和选择权。模型在快速迭代价格在波动能力边界在扩展而你却因为改不动代码只能被动接受。1.2 多模态把复杂度推向新高度最近多模态模型讨论度很高图像识别、语音问答、视频理解这些能力正在快速融入产品。但多模态带来的复杂度比纯文本高了一个量级。先说输入格式。同一张图片有的模型要求 base64 字符串有的要求可访问的 URL有的要求 multipart 表单还有的模型对图片尺寸、格式、压缩比例都有严格限制。音频输入更麻烦采样率、编码格式、声道数各家要求都不一样。如果你的应用同时支持文本、图片、语音问答每一种输入类型、每一家模型都要写一套适配逻辑代码会迅速膨胀到不可维护。再说输出。多模态模型的输出不只是文本还有结构化数据、内联图片、引用标注等。不同模型对这些内容的编码方式不一致上层应用想要统一解析难度不小。当模型数量从 1 变成 3、5、10差异会呈指数级放大。客户端不可能也不应该去适配每一家模型的每一个细节。所以在应用和模型之间插入一个中间层让差异在这个层次收敛同时让上层面对统一接口几乎是多模型应用的必然选择。2. AI 网关的核心能力拆解2.1 统一协议让所有模型看起来“一样”AI 网关最基础、也最值钱的能力是协议归一化。它做的事情很朴素把各家模型厂商不同的 API统一转换成你自定义的标准格式。业务代码只和标准格式打交道模型切换变成改网关配置而不是改业务代码。具体落到实现层面至少有三件事要做。统一请求格式。不同模型的请求参数差异很大model、messages、temperature、max_tokens 这些字段命名、位置、可选性都不一样。网关要做一层映射把标准请求翻译成目标模型的方言。统一响应格式。模型返回的原生结果五花八门有的把文本放在 choices[0].message.content有的放在 content[0].text有的带 usage有的不带。网关统一转成标准响应结构上层就不需要关心字段差异。统一流式协议。OpenAI 的 SSE 格式Anthropic 的事件流国产模型自己的流式协议差异很大网关要把它们收敛成一种格式再透传给客户端。这块是很多团队自己造轮子时最容易翻车的地方后面我会详细说。我在多个项目里的体会是统一协议是整个 AI 网关里性价比最高的投入。它一开始看起来像是“多一层转发多一层性能损耗”但实际带来的收益远超那点损耗——团队不再依赖任何一家模型 SDK核心业务逻辑和模型实现彻底解耦。2.2 智能路由与容灾把“该用哪个模型”决策上收统一协议解决的是“怎么换”的问题智能路由解决的是“该用哪个”的问题。路由本质上是一个决策系统它根据请求的特征决定请求走哪条模型通道。常见路由策略大体分几类。按任务类型走简单分类、信息抽取走便宜的小模型复杂推理走高性能大模型图片理解任务走多模态模型按用户维度走免费用户走低成本模型付费用户走顶级模型按实时状态走主模型超时或报错时自动切换备用模型。这些策略如果写在业务代码里很快会变成一团乱麻因为团队的策略是经常调整的。放网关里用配置驱动灵活性就高得多。容灾是路由策略里最刚需的一环。模型厂商的可用性说实话很难用 SLA 完全兜住。我遇到过模型服务连续五个小时返回 5xx 错误如果应用没有故障转移能力线上业务直接瘫痪。网关在检测到主模型异常时能自动把请求切到备用模型对调用方面完全透明。多 Key 轮转也算容灾的配套能力。模型厂商对单个 API Key 都有速率限制多个 Key 轮转能显著提高整体吞吐。网关在请求分配时按权重轮转 Key遇到 429 错误自动换下一个 Key这是接入模型时最常见的硬需求。2.3 成本治理与可观测性没有数据的网关等于没做很多团队把 AI 网关当成一个“转发器”我觉得这是对网关价值的最大浪费。网关最适合做的事是对 AI 调用做精细化成本治理。先说 Token 监控。模型计费的核心单位是 Token一个请求的输入 Token、输出 Token、缓存命中 Token直接影响成本。独立应用可以通过模型返回的 usage 字段做粗粒度统计但多应用、多团队共用模型资源时就必须在网关这一层统一采集。网关要知道每一个 API Key 消耗了多少 Token哪个应用、哪个功能在烧钱才能回答“钱花在哪了”这个问题。再说配额与限额。网关可以给每个 API Key 设置配额超过阈值的请求自动降级或拒绝。也可以设置单次请求的 Token 上限防止业务代码里出现“越权调用”——我见过一次线上事故一个低端功能因为上限设置不当把整个月的模型预算打光了。可观测性方面日志和指标要在网关层标准化。请求延迟、模型返回耗时、Token 消耗、错误码分布、缓存命中率这些指标统一采集之后才能做有效的成本分析和容量规划。没有数据支撑的网关本质上就是一个只能转发不能治理的黑盒子。2.4 多模态网关的进阶能力多模态模型普及之后网关又多了一个职责输入标准化。客户端不必关心目标模型接受什么格式只需把原始数据丢给网关网关负责预处理。以图片为例客户端传原始图片文件网关判断目标模型的输入要求自动完成 base64 编码、URL 生成、尺寸压缩、格式转换。音频同理统一转码、降采样、时长截断等操作放在网关层完成。这样客户端保持轻量模型升级带来的格式调整只影响网关配置客户端不需要跟着变化。更深入地看多模态网关还承担多模型能力协商的职责。一个请求里同时包含文本和图片不同模型的混合输入能力不一样有的支持图文联合推理有的只支持单一图片。网关根据模型能力做预处理和路由用户感知不到背后的切换。做多模态网关有一个容易忽略的细节图片和音频的体积。图片动辄几 MB音频更是几十 MB 级别网关转发时需要考虑体积优化和传输压缩。这里我试过用预签名 URL 代替直接 base64 传输实测下来能把网关转发耗时降一个量级后面避坑部分细说。3. 自建一个最小可用 AI 网关3.1 选型开源优先但别迷信现在市面上的 AI 网关方案不少我按适用场景简单分一下。第一类是通用 API 网关加 AI 插件代表有 Higress、Apache APISIX、Kong。这些项目本身是成熟的流量网关AI 插件让它具备了模型代理、协议转换、Key 管理能力。适合已经在用这些网关、不想再引入新组件的团队。第二类是专门的 AI 网关/代理项目代表是 LiteLLM。它支持上百种模型服务统一接口格式内置负载均衡、预算管理、日志记录。特别适合多模型接入需求明确的团队PyPI 上直接装配置简单社区活跃。第三类是自研。不推荐所有团队一上来就自研因为你面对的问题大概率已经被开源项目解决过了。但如果你有特殊需求比如私有化部署的协议定制、多模态输入深度预处理开源项目扩展点不一定够用自研反而更可控。我的建议是先用开源项目搭起基础能力验证业务场景再根据实际需要决定是否二次开发。不要一上来就用重型方案也不要为了炫技自研轮子。LiteLLM 的配置比较轻量我贴一个最小配置示例读者可以感受一下这类工具的上手成本。# config.yaml model_list: - model_name: gpt-4o litellm_params: model: openai/gpt-4o api_key: os.environ/openai_key - model_name: claude-3.5-sonnet litellm_params: model: anthropic/claude-3-5-sonnet api_key: os.environ/anthropic_key - model_name: vision-model litellm_params: model: openai/gpt-4o-mini api_key: os.environ/openai_key配置里定义了三个模型入口业务侧统一通过 LiteLLM 的 /openai 风格接口调用客户端只需要改 base_url不用动代码。模型切换就是改配置和重启服务真正做到了业务和模型解耦。3.2 自研一个轻量网关的代码骨架我理解有的读者希望搞清楚内部原理所以我用 Python 写过一个轻量版网关大约 400 行技术栈是 FastAPI 加 httpx。核心功能包括统一协议、多 Key 轮转、按模型名路由、流式转发。这里贴出核心代码骨架并解释每一块的设计意图。# app.py 简化版 AI 网关核心逻辑 from fastapi import FastAPI, HTTPException, Request from fastapi.responses import StreamingResponse, JSONResponse import httpx from pydantic import BaseModel app FastAPI() # 模型映射表标准模型名 - 上游服务配置 MODEL_ROUTES { chat: { url: https://api.openai.com/v1/chat/completions, api_keys: [sk-xxxx, sk-yyyy], timeout: 60, }, claude: { url: https://api.anthropic.com/v1/messages, api_keys: [ak-xxxx], timeout: 90, }, } # Key 轮转简单取模 状态记录 def get_next_key(mapping: dict) - str: if current_key_index not in mapping: mapping[current_key_index] 0 keys mapping[api_keys] key keys[mapping[current_key_index] % len(keys)] mapping[current_key_index] 1 return key def normalize_request(body: dict) - tuple: 把标准请求转换为目标模型方言这里以 OpenAI 与 Claude 为例 model_name body.get(model, chat) messages body.get(messages, []) if model_name claude: # Claude 需要 system 字段单独拆出来 system_content \n.join( m[content] for m in messages if m.get(role) system ) filtered_messages [m for m in messages if m.get(role) ! system] return { model: claude-3-5-sonnet, system: system_content, messages: filtered_messages, max_tokens: body.get(max_tokens, 1024), stream: body.get(stream, False), }, MODEL_ROUTES[claude] # 默认走 OpenAI 兼容协议 return body, MODEL_ROUTES[chat] async def forward_request(request: Request): 核心转发逻辑解析、映射、转发、响应 body await request.json() target_body, route normalize_request(body) api_key get_next_key(route) headers { Authorization: fBearer {api_key}, Content-Type: application/json, } async with httpx.AsyncClient(timeoutroute[timeout]) as client: if body.get(stream): # 流式转发把上游 SSE 数据流原样透传给客户端 req client.build_request( POST, route[url], jsontarget_body, headersheaders ) upstream_response await client.send(req, streamTrue) return StreamingResponse( upstream_response.aiter_raw(), status_codeupstream_response.status_code, media_typetext/event-stream, ) resp await client.post(route[url], jsontarget_body, headersheaders) if resp.status_code 429: raise HTTPException(status_code429, detailrate limited) return JSONResponse(contentresp.json(), status_coderesp.status_code) app.add_api_route(/v1/chat/completions, forward_request, methods[POST])这段代码有几个重要的设计决策。Key 轮转不是简单随机而是带状态的取模轮转这样能保证每个 Key 被均匀使用。生产环境建议做成独立的 KeyManager记录每个 Key 的速率限制和剩余配额否则多个 worker 进程各轮各的限流依然会出现。normalize_request 是协议转译的核心。不同模型的参数差异都是在这样一个小函数里收敛的。你需要维护一个映射表把标准请求映射到各家模型的方言。Claude 的 system 字段要单独拆出来这是常见差异点。流式转发用 httpx 的 build_request 再 send(streamTrue)直接把上游的字节流透传不做二次解析。这样可以最大化吞吐但代价是失去对流式内容的统计能力。如果你需要流式 Token 计数就得在网关层自己解析 SSE 事件成本会高一些。3.3 部署与验证怎样才算落地成功自建网关之后第一件事是本地跑通第二件事就是做回放验证。回放验证的含义是把你线上真实的请求日志拿出来对着新网关跑一遍对比结果是否和原模型一致。这一步非常重要因为网关层最怕出现“转发没问题但语义变了”的隐性 bug。回放方式很简单把这些真实请求用工具重放到网关对比返回内容。我习惯用 drift 检测来做相似度对比文本类请求用编辑距离和语义相似度的组合评估如果偏差过大就去检查 normalize_request 里的映射逻辑。部署形态上我推荐 Docker 单容器起步。FastAPI 加一个进程跑 HTTP 服务前面加个 Nginx 做 TLS 终止就够了。如果请求量上来了横向扩展网关实例注意此时 Key 轮转和限流要做在共享存储上比如 Redis否则每个实例各自维护 Key 状态会出现限流不均的问题。压测工具我推荐 locust原因是它脚本写起来简单便于模拟真实的多模态请求分布。压测时关注的指标不只是 QPS还有 P95 延迟和错误率。网关每多一跳延迟一定会有增加你要做的不是追求零损耗而是把额外延迟控制在可接受范围内。按我的经验本地到网关再到模型额外延迟控制在 20ms 以内是合理的多数情况下连 10ms 都不到。4. 常见问题与避坑实录4.1 高频问题速查表这里整理成两张表模型接入类、稳定性类。每一项背后都是线上事故攒下来的经验。常见问题根因解决思路切换模型后部分请求报 400参数映射遗漏某模型不支持某个参数检查 normalize_request 映射表对不支持参数做剔除或降级流式响应总是断连网关层超时设置过短上游 SSE 保活间隔过长把超时调大或按模型类型设置不同超时值429 限流频发Key 轮转太简单没有考虑每 Key 配额引入带配额的 KeyManager限流退避加重试Token 统计总是不准流式响应没有解析 SSE漏掉 usage 字段在网关层解析 SSE 事件从最后一个事件取 usage 数据多模态图片请求超时网关直接转发大体积 base64改用预签名 URL 或压缩图片后再转发某个用户请求总是失败但全局限流不触发没有按用户维度的配额在网关层增加按用户/API Key 的维度配额控制这个表格是经验总结展开说几个。4.2 流式响应是自研网关最容易翻车的地方流式响应翻车的主要原因是超时和断连。模型做长文本生成时SSE 的事件间隔可能很长如果网关的读超时设置得太短会在两次事件之间把连接断掉。客户端收到的流就中断了。解决方法是按模型类型配置不同的读超时长推理模型要放宽。另一个坑是流式响应的错误处理。很多模型 API 在流式过程中返回错误其实是放在 SSE 事件里的状态码却是 200。如果你的网关只判断了 HTTP 状态码就会把带错误内容的 SSE 透传给客户端客户端解析出奇怪的结果。正确做法是网关层对 SSE 事件做轻量解析既能统计 usage又能检测错误事件把错误转为合适的 HTTP 状态码返回。这需要一点额外开发但值得。4.3 多模态数据的体积处理多模态数据最现实的问题是体积。一张几 MB 的图片转成 base64 之后体积会膨胀约 33%加上 JSON 包装一个请求的 body 会非常大。网关做转发时如果直接透传上游模型接口被拖慢还容易触发网关层 body 大小限制。我试过两种优化策略。第一种是在网关层对图片做压缩和格式转换用 Pillow 把大图缩放到 512 以内JPEG 质量压到 80。实测下来图片体积可以从 3MB 骤降到 200KB 左右转发速度提升非常明显模型侧识别精度下降可以忽略。第二种是对音频做转码和时长截断只发送有效片段避免把整个音频文件丢给模型。这两种策略在多模态网关里几乎必备。还有一种思路更极端但很有效把媒体文件先上传到对象存储请求 body 里只带预签名 URL。模型服务多数支持 URL 输入这样网关转发的请求非常轻量。缺点是多一次上传流程客户端要稍微多写点代码但在大文件场景下收益远大于成本。4.4 成本治理的一些细节心得成本治理最容易犯的错误是把所有请求都路由到最强的模型。通用大模型能力最强但是贵、慢小模型便宜、快但能力上限低。如果不做路由策略默认全走大模型预算会很快失控。我的建议是在网关里预设一套“默认小模型、按需大模型”的路由规则。高价值复杂任务才走大模型简单任务一律小模型。这个策略改起来很快一个配置项就能生效但它的省钱效果非常可观。另一个细节是 Token 上限。很多模型请求失败不是因为网络而是因为输出 Token 超过上限。网关在转发前可以做一次预校验把 max_tokens 限制在合理范围防止业务代码里出现一次性输出上万 Token 的调用。还有缓存。模型调用结果在某些场景下是可缓存的——比如用户问题固定、期望答案不变。网关层可以做精确命中缓存也可以做语义缓存。精确命中缓存实现简单直接以消息哈希为 key。语义缓存成本高一些需要嵌入向量化但特定场景下收益巨大。这些能力都属于“加分项”先把前面的基础能力做扎实再考虑缓存。4.5 安全与合规网关是最后一道闸模型 API Key 的管理是安全重点。千万不要把模型 API Key 下发到客户端一定要放在网关或服务端。网关在中间层天然适合做 Key 隔离客户端只持有网关颁发的应用 Key网关背后管理真实的模型 API Key。多租户场景下应用 Key 要隔离权限某个 Key 只能调用特定模型只能消耗特定额度。网关在转发前做鉴权校验防止一个团队的 Key 越权调用高成本模型。内容安全上可以在网关层挂敏感信息过滤。请求出去之前做一次脱敏处理比如把身份证号、手机号替换为掩码响应回来之后再做一次内容合规检测。这些逻辑放网关层各个应用就不用各自实现了。值得强调的是网关层做安全过滤要格外注意性能损耗。字符串匹配和规则过滤还好如果上大模型进行内容审核延迟和成本都会显著增加。建议按风险级别分级处理普通文本用规则过滤高危场景才上模型审核。5. 多模态模型复现与应用侧的角色分工5.1 复现模型的团队先别急着写代码多模态模型是当前热词很多团队想自己复现或者微调一个多模态模型。但我要提醒一句如果你在做多模态 AI 应用先把多模态的输入处理和多模型路由想清楚再考虑代码层面的复现。因为应用侧的瓶颈往往不在模型权重而在数据流动的流畅度。我在项目里见过团队花大量精力微调模型却忽略了数据管线图片上传经常失败、音频转码格式不兼容、模型输入输出状态码混乱。这些问题用 AI 网关就能解决把精力省下来放到真正影响业务体验的地方。这里给一个判断标准如果你的多模态请求成功率低于 95%先不要怀疑模型能力先检查数据链路。图片有没有被正确压缩音频采样率是否符合模型要求每一家模型对输入格式的偏好是否被正确处理这些问题的答案大概率在网关层能找到。5.2 本地模型与云端模型的统一编排如果你确实要做多模态模型的本地化部署和复现网关也有独特价值把本地模型和云端模型编排在一个统一入口之下。数据敏感度高的请求走本地模型需要强大推理能力的请求走云端模型网关按数据属性自动路由。这样既满足了数据隐私要求又保留了调用顶级模型的能力。这本质上是将“模型路由”这一能力从按任务类型扩展到按数据流向。技术实现上与第 3 章的自研思路完全一致只是多一个本地推理服务作为上游节点。配置里加一行路由规则就能完成编排。6. 最后再分享一点个人体会我在实际项目中的体会是AI 网关不是一个锦上添花的组件而是多模型时代的架构必需品。它解决的不是某一个模型的问题而是整个应用如何与模型生态共处的问题。如果你正在设计新的 AI 应用从一开始就把网关层的边界划出来后面会省下大量重构成本。最后分享一个小技巧网关的配置文件一定要做好版本管理和评审流程。模型路由策略、Key 轮转权重、成本限额这些配置的变更直接影响线上成本和稳定性。把配置当代码一样对待走 PR 评审能避免很多“改了个配置引发线上事故”的惨剧。另外网关不是越复杂越好。很多团队一上来就追求语义缓存、A/B 测试、模型编排结果维护成本比收益还高。我的建议是分阶段推进先做协议统一和 Key 管理跑通之后再逐步加路由策略、成本治理和多模态预处理。每加一个能力都要有明确的数据来证明它值得而不是为了一些看起来很酷的架构概念提前负债。多模型时代的好消息是选择越来越多坏消息是选择的成本都堆在应用侧。一个务实的中间层能把这些成本消化在网关这一层让业务代码安心做业务这大概就是 AI 网关最有价值的地方。