最近在带一个小团队做AI应用人不多也就十人上下但每个人都在调大模型接口。两个月下来我发现一个很尴尬的事实团队里光是API Key就注册了七八个有人用OpenAI的有人用通义的有人用国产开源模型还有人偷偷用自己的个人账号在调。月底对账的时候产品经理拿着一堆零零散散的账单问我“我们到底花了多少钱”我竟然答不上来。这就是我为什么要写这篇的原因。我去GitHub找了一圈开源项目最后部署了一个37K Star的AI网关。这个项目的核心功能很直接把各个大模型的API统一收口到一个网关服务里对外只暴露一个兼容OpenAI格式的接口对内做Key统一管理、负载均衡、成本统计和权限控制。更关键的是它允许10人以内的小团队免费使用。这篇文章把从选型、部署到踩坑的完整过程都写出来希望能帮到同样被大模型API管理折磨的人。1. 先说清楚AI网关到底解决了什么破事1.1 大模型接入的混乱现场很多人觉得接大模型API很简单——拿个Key调个接口完事。但当一个团队同时使用多个模型、多个供应商时事情就变味了。我随便列几个真实发生过的场景开发环境里有人把生产环境的Key直接写死在代码里一提交就泄露到Git仓库测试同学想模拟GPT-4的响应结果每次调用的都是不同的模型版本导致测试结果不稳定运维想限制某个服务每天的调用量结果发现同一个Key被三个服务共用根本没法隔离。这些都是网关能解决的问题但当时我们没有任何管控手段。网关的价值不在于“多一个转发层”而在于把散落在每个开发者本地的配置、Key和逻辑统一收口到一处。所有调用都经过同一个入口权限、配额、日志、计费才能有据可查。1.2 网关该管的几件事一个合格的AI网关至少要管住这几件事统一接口不管底层是OpenAI、Claude、通义还是本地模型对外都暴露一套OpenAI兼容的HTTP接口客户端SDK不用改代码。Key管理团队共享一个主Key网关下发虚拟Key给不同成员或不同服务每个虚拟Key可以独立设置额度、速率和过期时间。模型路由同一个请求可以按规则转发到不同上游模型比如普通聊天走便宜模型、复杂推理走顶级模型。成本控制每次调用都记录token消耗和费用能按项目、按成员、按模型维度聚合出账单。可观测性所有请求的延迟、成功率、错误码都有日志和监控出问题时能快速定位。这些能力如果自己写至少需要一两个月。用现成的开源项目一个晚上就能部署完。差距就在这里。2. 37K Star的含金量这个开源项目到底能干什么2.1 它支持哪些上游模型我没有点名具体项目因为我实际部署的是目前GitHub上37K Star左右的那个AI网关项目LiteLLM。市面上同类项目不少但这个项目的生态和文档成熟度明显更高。上游支持范围大概是这样的模型类型支持情况OpenAI系列包括GPT-4o、GPT-4系列、o1系列以及所有兼容OpenAI接口的服务Anthropic ClaudeClaude 3.5/3.7全系列Google GeminiGemini 1.5/2.0系列国内厂商通义千问、文心一言、智谱GLM、DeepSeek等开源本地模型通过Ollama、vLLM、HuggingFace TGI等方式接入本地部署的开源模型Azure OpenAI支持Azure的部署形态私有化场景很实用有一点很关键它支持“OpenAI兼容接口”接入所以任何声称兼容OpenAI格式的服务商都能直接挂上去。现在国内不少第三方服务商都提供OpenAI兼容的端点接起来非常简单。2.2 核心特性拆解这个项目值得37K Star绝不只是因为“转发HTTP请求”。我把它最实用的几个能力拆开讲讲。第一是智能路由和fallback。你可以配置一组模型网关先尝试主模型如果超时或返回错误自动切换到备用模型。我们的生产环境里主模型偶尔会限流fallback配置能保证服务不中断。第二是负载均衡。同一个模型可以配置多个上游Key网关轮询分配请求。比如你有两个OpenAI账号各自有配额网关自动分担避免单个账号触发速率限制。第三是细粒度权限控制。每个虚拟Key可以绑定特定模型、设定每分钟请求数上限、设定日费用上限。这个能力对团队管理来说太重要了我后面会有详细使用案例。第四是完整的审计日志。每个请求的模型、token数、延迟、费用、调用方都能查。出现费用异常时我可以几分钟内定位到具体是哪个项目、哪个Key在烧钱。第五是预算控制。设置一个总预算达到阈值后网关自动拒掉新的请求。这个功能比人工盯账单靠谱得多。2.3 为什么它有资格叫“网关”而不是“SDK封装”很多人问我自己写一个工具类把OpenAI和Claude的SDK包一层不也能统一接口吗为什么要单独部署一个服务区别在于“代理”和“网关”的定位差异。SDK封装是运行在业务进程内的代码库它只能管住“用了这个SDK的实例”管不住其他服务、其他语言、其他团队的调用。网关则是一个独立的服务所有调用都强制经过它不管上游是Python写的还是Node.js写的不管调用方用不用你提供的SDK只要HTTP请求到达网关就能被管控。还有一点网关天然支持多租户。团队里前端团队、后端团队、算法团队各自拿自己的虚拟Key网关在中间做隔离和审计。SDK封装做得到吗也许能做但要做成这样完整且稳定成本极高。这一层“服务化”的差异就是网关的本质价值。3. 10人团队免费的真实规则3.1 开源协议和免费边界先说清楚这个项目本身是开源的遵循MIT协议也就是说你把它部署在自己的服务器上随便用不限制人数不管你是10人还是100人都不需要付一分钱。这对于有技术能力、愿意自己运维的团队来说已经是完全免费的方案。那标题里的“10人团队免费用”是什么意思我理解它指的是云托管版本的免费额度。这个项目背后有商业化公司在运营提供托管的SaaS服务你不用自己部署和维护注册账号在线就能用。托管服务按团队成员数收费10人及以下免费超过10人按人头计费。两种方式怎么选如果你只是想快速验证、不想折腾服务器直接用云托管版就好如果你对数据安全有要求模型请求不想经过第三方服务或者你有定制化需求自己部署才是正确的选择。我们就是自己部署的原因很简单我们需要把网关接入内部统一的监控系统云托管版做不到。3.2 云服务版的免费额度如果你选择云托管版需要了解它的免费额度边界。10人以内的团队基础功能比如统一接口、虚拟Key管理、基础日志查询都是免费的。但一些进阶特性——比如自定义模型路由策略、高级审计报表、SSO单点登录——可能需要付费解锁。这里有个很实在的建议先确认你的团队真实需求再决定是否升级。我们团队一开始也想用云托管版图省事但算了算后续要用的高级功能再加上数据安全方面的考虑最后还是走了自部署路线。目前跑下来稳定性和可控性都比托管版更符合预期。3.3 什么情况下你才需要掏钱虽然开源版不要钱但你要为运维成本买单。网关服务挂了谁来重启版本更新谁来跟数据备份怎么做这些都是隐形成本。如果你的团队连一台Linux服务器都没人维护那还是老老实实买云托管服务一个月几十块的费用比起自己折腾一天来说太划算了。如果团队超过10人而且不想管运维那就只能付钱了。按人头算下来其实也比每个成员单独注册各家大模型API的管理成本低很多。更值钱的是它帮你省下的对账时间——不是用钱能直接衡量的。4. 本地部署一条命令跑起来4.1 部署前准备我们实际用Docker部署这是最快的方式。先列一下环境要求一台能联网的Linux服务器或本地机器2核4G以上即可我们用的机器是2核4G跑得很稳Docker和Docker Compose各家大模型厂商的API Key。部署前先想清楚三件事你的上游模型是哪些是否所有调用都走网关哪些项目需要分配独立的虚拟Key想清楚后再动手后续能省很多返工的麻烦。4.2 Docker部署步骤在服务器上创建一个目录比如ai-gateway写一个docker-compose.ymlversion: 3.9 services: litellm: image: ghcr.io/berriai/litellm:main-latest ports: - 4000:4000 volumes: - ./litellm_config.yaml:/app/config.yaml environment: - LITELLM_MASTER_KEYsk-your-master-key - DATABASE_URLpostgresql://postgres:postgresdb:5432/litellm depends_on: - db db: image: postgres:16 environment: - POSTGRES_DBlitellm - POSTGRES_USERpostgres - POSTGRES_PASSWORDpostgres volumes: - pgdata:/var/lib/postgresql/data volumes: pgdata:然后启动docker compose up -d第一次启动要拉镜像国内网络环境下可能比较慢。如果拉不动可以换用其他镜像源或直接下载release包具体方法就是常规处理国内拉取GitHub镜像的策略这里不展开。启动后访问http://服务器IP:4000用LITELLM_MASTER_KEY登录管理后台。管理界面可以配置模型、创建虚拟Key、查看日志整体上手成本很低。4.3 路由规则和模型组配置这是配置网关时最核心的一步。你需要告诉网关哪些模型可用上游Key是什么以及路由到这些模型时按什么策略。配置文件的格式大致如下model_list: - model_name: gpt-4o litellm_params: model: openai/gpt-4o api_key: sk-openai-xxx - model_name: claude-3-5-sonnet litellm_params: model: anthropic/claude-3-5-sonnet api_key: sk-anthropic-xxx - model_name: deepseek-chat litellm_params: model: openai/deepseek-chat api_key: sk-deepseek-xxx api_base: https://api.deepseek.com/v1 router_settings: routing_strategy: usage-based-routing-v2 fallbacks: - {gpt-4o: [deepseek-chat]}这里解释几个关键点model_name是对外暴露的名称客户端调的就是这个名字国内模型通过 OpenAI 兼容格式接入设置api_base指向厂商的端点即可routing_strategy是负载均衡策略usage-based-routing-v2会优先选择当前配额和延迟更优的上游Keyfallbacks是最重要的容灾配置当gpt-4o请求失败时自动转到deepseek-chat。这个配置文件改完后需要重启网关服务才生效docker compose restart litellm4.4 客户端接入换一个base_url就完事作为调用方接入几乎没有成本——因为网关暴露的是OpenAI兼容接口所以任何语言里用OpenAI SDK都能直接改base_url接入。Python示例from openai import OpenAI client OpenAI( api_keysk-your-virtual-key, # 网关下发的虚拟Key base_urlhttp://your-server:4000/v1 ) response client.chat.completions.create( modelgpt-4o, messages[{role: user, content: 你好}] ) print(response.choices[0].message.content)Node.js里也类似只需要改baseURL。我们的几个后端服务大概花了半小时就全部切到网关通道代码几乎没改。5. 从接入到稳定运行我踩过的坑和排查链路5.1 问题一fallback路由不生效第一次配置fallback后我故意把OpenAI的Key改错想验证一下能不能自动切到备用模型。结果请求直接报错压根没走fallback。我当时的第一反应是“这个功能是不是假的”。排查思路是这样的先看配置文件里fallback的层级。网关的fallback配置有两种一种是全局的router_settings.fallbacks另一种是模型级别的litellm_params.fallbacks。全局的配置只对model_list里已经注册的模型组合生效而且如果有HTTP错误或上游没有返回标准格式的信息fallback逻辑不会触发。我逐条打印了网关日志才找到根因——我的测试请求temperature参数传了一个OpenAI不支持的数值上游返回400错误而fallback默认只在特定的错误码下才触发。后来我在模型级别加了fallbacks配置并打开了allowed_fails参数问题才解决。这里分享一个教训不要在生产环境第一次用fallback。先在测试环境故意制造故障确认failover链路是通的再上线。我见过太多团队fallback配了半年一次都没生效过等到真出故障那天才发现根本切不过去。5.2 问题二流式输出偶尔断流切到网关之后前端反馈聊天流式输出偶尔会在中间断掉重试一次就好。这个问题的隐蔽性很高——它不是必现的而是零星出现。排查链路大概是这样的先看网关日志发现断流的时候网关已经收到了上游完整响应但转发给客户端时TCP连接被重置。再查客户端代码发现前端设置的超时时间只有30秒而某个模型的首token延迟在高峰期偶尔会超过30秒客户端就直接断开了。那为什么断流后重试能成功因为重试时网关刚好把同一个请求路由到了另一个上游Key延迟低一些就在超时时间内返回了。这个问题的本质不是网关的问题而是超时设置和我们的路由策略不匹配。最后把客户端超时从30秒调整到60秒同时在网关层给这个模型设置了更保守的cooldown时间问题解决。5.3 问题三日志把磁盘塞满了运行两周后我们收到服务器磁盘告警查下来是网关的访问日志把磁盘写满了。默认配置下网关会记录每一次请求的完整请求体和响应体一个带图片的请求体可能就有几MB日志量非常可观。解决办法是在网关配置里调整日志级别和采样策略记录请求元数据模型、时间、延迟、token数、费用不记录请求体内容对于错误请求才保留完整信息用于排查日志轮转周期缩短到一天。这样改了之后磁盘占用降到了原来的八分之一出错排查时仍然能定位到问题。5.4 排错方法论小结网关服务出问题时我的排查顺序固定为先看客户端请求是否到达网关客户端日志、再看网关是否成功请求上游网关日志、接着看上流返回了什么上游响应体、最后确认转发链路是否正常。绝大多数问题都出在这四层之间按顺序查能最快缩小范围。另外强烈建议把网关日志接入统一日志平台。我们后面用Loki Promtail收集日志然后用Grafana做可视化排查效率提高了很多。如果是小团队至少要在Docker的日志驱动里把日志保存到宿主机文件否则容器一重建日志就全没了。6. 到底哪些团队适合上这个网关6.1 建议用的场景如果你的团队至少有两个人同时调用大模型API而且存在以下任一情况就可以考虑部署多家模型混用比如同时用OpenAI和国内模型想统一管理接口和账单一个Key多人共享现在还在微信群里传API Key的强烈建议赶紧收口成本敏感需要知道每个项目每个月花多少token、多少费用服务稳定性要求高需要跨模型容灾避免单一厂商故障导致服务不可用。另外如果你在做面向客户的产品网关几乎成了标配。因为你需要按客户或按项目隔离调用量总不能在代码里硬编码Key吧。6.2 不建议用的场景也有不适合用网关的场景。比如只是一个人本地跑个小demo那直接调官方API反而更简单。再比如你的业务对接口兼容性要求极高调用某些厂商独有接口比如多模态识别、特殊参数时网关的统一接口未必能完整透传所有参数这时候直接用厂商SDK更合适。自部署还有一个隐性成本你需要有人维护这个服务。如果团队里没人懂Docker、不会看日志那还是用托管版本的AI网关更省心。费心运维一件工具却挤占了做业务的精力得不偿失。6.3 和其他网关类项目的简单对比GitHub上同类开源项目其实不少我也简单对比过几个主流的项目特点适合场景LiteLLM功能全面上游支持最广生态活跃多数团队首选One API国内社区熟悉支持渠道管理和令牌计费面向国内模型和自部署Kong/KrakenD通用API网关非AI专用需要自己写插件已有统一API网关基础的团队Higress阿里云开源云原生场景集成好对Kubernetes生态有依赖的团队选择建议如果只做AI网关这一件事优先选专门的AI网关如果团队已经有成熟API网关可以考虑在网关里加AI插件不引入额外组件。核心看你们的技术底座和运维能力没有绝对好坏。我在实际部署这个37K Star的AI网关项目之后最大的感受是对于10人以下的小团队来说它几乎是“零成本”解决大模型管理问题的标准答案。从部署到全团队接入用了不到半天之后再也没有出现过“这个Key是谁的”“这个月花了多少钱”这类争论。如果你正被同样的问题困扰找一个周末把网关搭起来会是最值得花的时间。