1. 为什么我会动自己搭多模型 API 网关的念头一个月前我手上同时跑着三个项目一个客服知识库问答、一个内部代码助手、一个内容摘要工具。三个项目分别调用了不同厂商的大模型服务有的走 OpenAI 兼容接口有的走自家协议有的只提供 HTTP 原生调用。最开始的方案很粗暴——每个项目里硬编码一套请求逻辑各自维护自己的密钥和重试策略。结果就是我每天要花大量时间处理各种报错。最典型的就是429 Too Many Requests有时候是某个厂商的免费额度跑满了有时候是并发太高被限流有时候是密钥轮换没同步导致 401。更头疼的是当我想把某个项目的模型从 A 换成 B 时要改代码、改配置、重新测试一套流程下来半天就没了。于是我开始认真考虑要不要自己搭一个多模型 API 网关把所有的模型调用统一到一个入口由网关来做路由、鉴权、限流、重试、日志记录。这样业务代码只需要关心我要什么结果不需要关心这个请求发给谁、怎么发、失败了怎么办。但问题也随之而来自己搭网关到底值不值得市面上的方案那么多是直接用现成的开源网关还是自己写一个轻量级的转发层我决定用两种方案各跑一个月用真实数据来回答这个问题。这篇文章就是这一个月折腾的完整记录。我会把两种方案的架构设计、核心实现、踩过的坑、以及最终的数据对比全部摊开来讲。如果你也在纠结要不要自建网关或者正在选型阶段这篇内容应该能帮你省下不少试错时间。2. 两种方案的整体设计与选型思路2.1 方案一基于开源网关做二次开发第一种方案我选择了一个成熟的开源 API 网关作为基础在它上面做配置和少量二次开发。选它的理由很直接社区活跃、文档齐全、已经内置了限流、重试、密钥管理这些我需要的核心功能。我不需要从零造轮子只需要把各个模型厂商的接口适配进去就行。这个网关的核心工作流程是这样的业务方发来一个标准格式的请求网关根据请求中的model字段或者自定义的路由规则决定把请求转发给哪个上游服务。转发之前网关会做几件事——检查密钥是否有效、检查当前并发是否超过阈值、记录请求日志。如果上游返回了 429 或者 5xx网关会根据预设的策略进行重试或者降级到备用模型。我选择这个方案的核心考量是稳定优先。开源网关经过大量生产环境验证边界情况处理得比较完善我不需要担心一些奇怪的并发问题或者内存泄漏。而且它的插件机制让我可以很方便地接入自定义的鉴权和计费逻辑。但这个方案也有明显的代价。首先是部署复杂度高需要维护额外的服务实例、数据库、缓存。其次是灵活性受限当我想实现一些比较特殊的路由策略时发现要么改源码要么绕一大圈用插件机制实现都不太优雅。2.2 方案二自己写一个轻量级转发层第二种方案是我自己用 Python 写了一个轻量级的转发层核心代码不到 500 行。它的设计哲学和方案一完全相反——不做大而全的网关只做请求转发 失败重试 密钥轮换这三件事。具体来说这个转发层是一个 FastAPI 应用对外暴露一个统一的/v1/chat/completions接口内部维护一个模型路由表。当请求进来时它根据model字段查表找到对应的上游地址和密钥然后用 httpx 发起异步请求。如果返回 429就根据配置的重试次数和退避策略重试如果重试耗尽就切换到备用模型。这个方案最大的优势是透明。所有的逻辑都在我自己的代码里我想怎么改就怎么改。比如我想实现一个按用户等级分配不同模型的策略只需要在路由表里加一个字段然后在转发前做一次判断就行。再比如我想记录每个请求的 token 消耗用于计费直接在响应处理里加一段解析逻辑就完事了。代价当然也有。我需要自己处理很多底层细节比如连接池管理、超时控制、异常捕获。而且因为没有经过大规模生产验证一些边界情况需要我自己慢慢踩出来。2.3 两种方案的核心差异对比为了让你更直观地看到两种方案的区别我把关键维度整理成了下面这张表对比维度方案一开源网关方案二自写转发层部署复杂度高需要额外维护数据库和缓存低单个 Python 进程即可功能完整度高内置限流、鉴权、监控低只做核心转发和重试灵活性中受插件机制限制高想怎么改就怎么改稳定性高经过生产验证中需要自己踩边界情况维护成本中需要跟进社区版本低代码量小逻辑透明适用场景多团队共用、需要精细管控个人或小团队、追求轻量这张表是我跑了一个月之后总结出来的刚开始选型的时候其实没有这么清晰。接下来我会分别拆解两种方案的核心实现细节把每个环节的考量和踩过的坑都讲清楚。3. 方案一的核心细节与实操要点3.1 网关的基础部署与配置开源网关的部署我采用的是容器化方案用 Docker Compose 编排了三个服务网关本体、PostgreSQL 用于存储路由配置和密钥、Redis 用于限流计数和缓存。这样编排的原因是网关本身是无状态的可以水平扩展而配置和计数需要持久化存储。部署过程中第一个要注意的点是网络配置。网关需要同时对外提供服务和对内访问各个模型厂商的 API所以它的网络策略要允许出站 HTTPS 请求。我一开始图省事把网关放在了一个限制出站的网络环境里结果所有转发请求都超时排查了半天才发现是网络策略的问题。第二个要注意的是密钥管理。开源网关通常支持把密钥存在数据库里但明文存储肯定不行。我的做法是用环境变量注入一个主密钥然后用它加密存储各个厂商的 API Key。网关在转发时动态解密这样即使数据库被拖库密钥也不会直接泄露。配置路由的时候每个模型厂商都需要单独配置一个 upstream。这里有个细节不同厂商的接口路径不一样有的兼容 OpenAI 的/v1/chat/completions有的需要改成/api/v3/chat/completions之类的。网关的路径重写功能可以处理这个差异但配置的时候要仔细核对否则会出现 404。3.2 限流与重试策略的配置细节限流和重试是网关最核心的两个功能也是我踩坑最多的地方。先说限流。开源网关通常支持多种限流维度比如按 IP、按密钥、按路由。我最初只配置了按密钥的限流结果发现同一个密钥被多个业务方共用时一个业务方的突发流量会把其他业务方也限死。后来改成了按密钥 按业务方标识的双维度限流每个业务方有独立的配额互不影响。限流的阈值设置也很讲究。我一开始把阈值设得比较宽松结果上游厂商的 429 还是频繁出现。后来才想明白网关的限流阈值应该略低于上游厂商的实际限制留出一定的缓冲空间。比如某个厂商限制每分钟 60 次请求我在网关上就设成每分钟 50 次这样即使有少量突发也不会触发上游的限流。再说重试。重试策略的核心是什么情况重试、重试几次、间隔多久。我的配置是只对 429 和 5xx 重试4xx 中的 401 和 403 不重试因为重试也没用重试次数最多 3 次间隔采用指数退避加随机抖动。这里有个关键细节指数退避的基数不能设得太小。我一开始设的是 100 毫秒结果三次重试在 1 秒内就打完了上游的限流窗口还没过去重试必然失败。后来改成基数 1 秒三次重试分别在 1 秒、2 秒、4 秒后触发成功率明显提升。还有一个容易被忽略的点是重试的幂等性。对于聊天补全这类接口重试是安全的因为不会产生副作用。但如果网关还代理了其他有副作用的接口重试就需要谨慎最好只对明确的幂等接口开启重试。3.3 多模型路由的配置与管理多模型路由是这个网关的核心价值所在。我的配置思路是每个业务场景对应一个虚拟模型名网关根据这个虚拟模型名查到实际的上游模型和备用模型列表。举个例子我的代码助手场景用的是虚拟模型名code-assistant它对应的主模型是某个代码能力强的模型备用模型是两个其他厂商的通用模型。当主模型返回 429 或者超时时网关自动切换到备用模型业务方完全无感知。配置路由的时候有几个实操要点。第一备用模型的接口格式要尽量兼容否则网关需要做额外的格式转换。我优先选择那些兼容 OpenAI 接口格式的模型作为备用这样切换时不需要改请求体。第二路由的匹配规则要精确避免出现某个请求匹配到了错误的路由这种情况。我用的匹配规则是精确匹配虚拟模型名不做模糊匹配。第三路由配置要支持热更新不能每次改配置都重启网关。开源网关通常支持从数据库或配置中心动态加载路由这个功能一定要用上。3.4 日志与监控的落地方式日志和监控是网关的眼睛没有它们出了问题就是两眼一抹黑。我的日志方案是网关把每个请求的关键信息结构化输出到标准输出然后由日志收集组件统一采集。关键信息包括请求 ID、业务方标识、虚拟模型名、实际上游、请求耗时、响应状态码、重试次数、token 消耗。这些字段足够我排查绝大多数问题。监控方面我用了网关内置的指标暴露功能把请求量、错误率、延迟分布、限流触发次数等指标暴露给监控系统。然后配置了几个告警规则错误率超过 5% 告警、429 触发次数突增告警、某个上游的延迟超过阈值告警。这里有个实操心得告警阈值不要设得太敏感否则会被大量误报淹没。我一开始把错误率告警设成了 1%结果因为正常的重试也会产生少量错误告警天天响。后来改成 5%并且加了持续 5 分钟的条件告警才有实际参考价值。4. 方案二的核心细节与实操要点4.1 转发层的最小可用架构自写转发层的架构非常简洁一个 FastAPI 应用一个路由配置字典一个 httpx 异步客户端。整个应用启动后监听一个端口接收请求、查路由、转发、返回结果。核心的路由配置我放在一个 Python 字典里结构大概是这样的键是虚拟模型名值是一个包含上游地址、密钥、备用模型列表的配置对象。这个字典可以从环境变量或者配置文件加载改配置只需要改文件然后重启进程对于个人项目来说完全够用。httpx 客户端我配置了连接池和超时。连接池的大小根据并发量来定我设的是最大 100 个连接超时分为连接超时和读取超时分别是 5 秒和 60 秒。读取超时设得比较长是因为大模型的响应有时候确实很慢设太短会导致正常的请求被误判为超时。4.2 429 处理与退避重试的实现429 处理是自写转发层最核心的逻辑也是我花时间最多的地方。我的实现思路是这样的封装一个forward_request函数它接收请求体和路由配置返回上游的响应。函数内部用一个循环来处理重试循环次数由配置决定。每次请求失败后判断状态码是否是 429 或者 5xx如果是就计算退避时间等待后继续循环如果不是就直接返回错误。退避时间的计算我用的是指数退避 随机抖动第 n 次重试的等待时间是base * 2^n random(0, jitter)。base 设为 1 秒jitter 设为 0.5 秒。这样三次重试的等待时间大概在 1 秒、2 秒、4 秒左右加上随机抖动避免多个请求同时重试造成惊群。这里有个关键细节重试的时候要换密钥。如果同一个密钥被限流了用它重试大概率还是失败。我的做法是每个上游配置多个密钥重试时轮换使用。这个策略让我的重试成功率从 40% 左右提升到了 80% 以上。还有一个细节是重试的终止条件。除了次数限制我还加了一个总耗时限制。如果重试的总耗时超过了业务方能接受的上限比如 30 秒就直接返回错误不再继续重试。这样可以避免一个请求卡太久拖垮整个服务。4.3 多模型切换与降级的代码实现多模型切换的逻辑比想象中简单。当主模型的重试耗尽后转发层会从备用模型列表里取下一个模型用同样的逻辑再试一遍。如果所有模型都失败了才返回最终的失败响应。代码上的实现是把尝试一个模型的逻辑封装成一个函数然后在外面套一层循环遍历模型列表。每个模型有自己的重试次数和退避配置互不干扰。这里有个实操心得备用模型的顺序很重要。我把响应速度快、稳定性高的模型放在前面把能力强但偶尔限流的模型放在后面。这样大多数降级请求都能快速返回用户体验更好。另外降级的时候要记录日志。我在每次降级时都会输出一条 WARN 级别的日志包含原始模型、降级模型、降级原因。这样我可以定期分析降级频率判断是否需要调整主备模型的选择。4.4 配置热加载与密钥轮换自写转发层的一个短板是配置热加载。因为配置在内存里改配置需要重启进程。对于个人项目来说重启几秒钟可以接受但如果想做得更优雅可以用文件监听的方式实现热加载。我的做法是用一个后台线程定期检查配置文件的修改时间如果发现变化就重新加载配置。加载的时候用读写锁保护避免加载过程中有请求读到不完整的配置。这个实现不复杂大概几十行代码就能搞定。密钥轮换是另一个需要处理的点。我的做法是把密钥存在一个列表里每次请求时按顺序取下一个密钥。如果某个密钥连续失败多次就把它标记为冷却中一段时间内不再使用。这个策略可以有效避开那些临时失效的密钥。5. 两种方案跑了一个月后的真实数据对比5.1 稳定性与错误率对比跑了一个月之后我统计了两个方案的关键指标。先看稳定性指标方案一开源网关方案二自写转发层总请求数约 12 万约 11.8 万最终成功率99.2%98.7%429 触发次数约 3200 次约 3500 次重试成功率约 85%约 78%平均响应延迟1.8 秒1.6 秒服务不可用时长约 15 分钟约 40 分钟从数据上看开源网关的最终成功率略高服务不可用时长也更短。这主要得益于它更完善的重试和熔断机制。自写转发层的延迟略低因为少了一层中间处理但稳定性稍逊一筹。服务不可用时长这个指标差异比较大。开源网关的 15 分钟主要是两次配置变更导致的重启而自写转发层的 40 分钟里有 30 分钟是因为我改代码引入了一个 bug导致所有请求都失败。这个差异其实反映的是人为因素——自写代码的出错概率更高。5.2 维护成本与开发效率对比维护成本这块我记录了每天花在网关相关事务上的时间维护事项方案一耗时方案二耗时日常巡检每天约 10 分钟每天约 5 分钟配置变更每次约 20 分钟每次约 5 分钟故障排查每次约 30 分钟每次约 45 分钟版本升级每月约 2 小时无功能开发每次约 4 小时每次约 1 小时日常巡检和配置变更上自写转发层明显更省时间因为逻辑简单、改起来快。但故障排查上开源网关反而更快因为它的日志和监控更完善问题定位更直接。版本升级是开源网关的额外成本每个月都要花时间跟进社区更新。功能开发这块差异最大。我想加一个按用户等级分配模型的功能在自写转发层里改了几十行代码就搞定了而在开源网关上折腾了半天插件机制最后还是没实现得很优雅。5.3 成本核算与资源占用成本方面两个方案的实际支出都不高但结构不一样成本项方案一方案二服务器资源2 核 4G约 60 元/月1 核 2G约 30 元/月数据库/缓存约 40 元/月无开发时间投入约 20 小时约 35 小时维护时间投入约 15 小时/月约 8 小时/月如果只算现金支出自写转发层更便宜。但如果把时间成本折算进去开源网关在前期的总成本更低因为开发时间短。不过随着时间推移自写转发层的维护成本优势会逐渐体现出来。5.4 什么场景该选哪种方案基于这一个月的真实体验我总结了一个选型建议如果你是多团队共用、需要精细的权限管控和计费、对稳定性要求极高选开源网关。它的功能完整度和稳定性是自写方案很难达到的多花的那点部署和维护成本完全值得。如果你是个人开发者或小团队、需求相对简单、追求轻量和灵活选自写转发层。它的代码透明、改起来快、资源占用低只要你能接受偶尔因为自己改代码引入的小故障。如果你介于两者之间可以考虑一个折中方案用开源网关做基础但把一些个性化的逻辑通过它支持的扩展机制实现。这样既能享受开源方案的稳定性又能保留一定的灵活性。6. 实操中遇到的典型问题与排查技巧6.1 429 报错的排查思路429 是我遇到最多的错误排查思路可以总结成三步第一步确认是网关限流还是上游限流。看网关的日志如果请求根本没发出去就被拒绝了那是网关限流如果请求发出去了但上游返回 429那是上游限流。两者的处理方式完全不同。第二步如果是上游限流看是哪个维度的限制。有的厂商是按请求数限流有的是按 token 数限流有的是按并发数限流。看响应头里的Retry-After和X-RateLimit-*字段可以判断。针对不同的限制维度调整策略也不一样。第三步如果是网关限流检查限流配置是否合理。常见的问题是阈值设得太低或者限流维度选错了。我遇到过一次限流维度设成了按 IP结果所有请求都来自同一个出口 IP等于没限流。6.2 配置错误导致的 400 问题400 错误通常和配置有关我遇到过的几种典型情况一种是base_url配置错误。不同厂商的接口路径不一样有的需要带/v1有的不需要。配置的时候要仔细核对文档最好先用 curl 手动测一下。另一种是请求体格式不兼容。虽然很多厂商声称兼容 OpenAI 接口但实际实现上会有细微差异。比如有的厂商不支持stream参数有的对temperature的取值范围要求不同。遇到 400 的时候先把请求体简化到最小然后逐步加参数定位是哪个参数导致的。还有一种是模型名称错误。虚拟模型名和实际模型名的映射关系要配置正确否则网关会把请求转发到一个不存在的模型上上游返回 400。6.3 重试耗尽后的降级处理当所有重试都失败后降级处理就很重要了。我的降级策略分三层第一层是切换到备用模型。如果备用模型可用用户几乎无感知只是响应内容可能略有差异。第二层是返回缓存结果。对于一些重复性高的请求我会缓存之前的成功响应降级时直接返回缓存。这个策略适合知识库问答这类场景。第三层是返回友好的错误提示。如果前两层都不可用就返回一个结构化的错误响应告诉用户当前服务繁忙请稍后重试而不是直接抛一个 500。6.4 常见问题速查表问题现象可能原因排查方法解决方案429 频繁出现限流阈值过低或密钥共用查看网关和上游的限流日志调整阈值拆分密钥400 配置错误base_url 或模型名错误用 curl 手动测试上游接口核对文档修正配置请求超时读取超时设置过短查看超时日志和上游响应时间调大读取超时密钥失效密钥过期或被封禁检查密钥状态和余额轮换密钥启用备用密钥降级频繁主模型不稳定统计降级日志调整主备模型顺序响应格式异常上游接口不兼容对比请求和响应格式增加格式转换层7. 我个人在实际操作中的几点体会跑完这一个月我最大的体会是网关这个东西核心价值不在于功能多而在于把复杂性收敛到一个地方。不管是开源方案还是自写方案只要能把多模型调用的复杂性从业务代码里剥离出来就已经成功了。第二个体会是429 处理是网关的生命线。多模型场景下限流几乎是必然的能不能优雅地处理 429直接决定了整个系统的可用性。我的建议是不管选哪种方案都要把重试、退避、密钥轮换、降级这几件事做扎实。第三个体会是日志和监控不能省。我一开始觉得个人项目没必要搞那么复杂的监控结果出了问题全靠猜。后来补上了结构化日志和基础告警排查效率提升了好几倍。最后分享一个小技巧如果你也在纠结选型可以先花半天时间用自写方案搭一个最小可用的转发层把核心流程跑通。然后再花一天时间部署一个开源网关体验一下它的功能。两个都试过之后你自然就知道哪个更适合自己了。选型这件事别人的建议只能参考真正的答案还是要自己跑出来。