2026年一开年我手里同时维护的AI应用已经接到第14个大模型API了——这还没算上本地用vLLM、Ollama拉起来的开源模型。密钥散落在各个环境变量里账单要对着好几家控制台手动核对前端说要换模型我得去改代码运维说限流策略没法统一做。这日子确实没法过了。于是我把能搜到的大模型API聚合网关都拉出来试了一圈最后在WoolGate、LiteLLM、One API、New API这四款里认真做了对比也把部署过程完整跑了一遍。这篇东西就是这次选型和落地的完整记录。先说结论没有任何一款是万能的选型完全取决于你的团队结构、应用规模和运维能力。下面我把每款的定位、特性、部署方式、踩坑点都摊开来写文末附上可直接抄的部署配置。1. 为什么要折腾API聚合网关先搞清楚你面对的是什么问题很多朋友第一次接触API聚合网关是在“key管理不过来”的时候。但等到真正上手才发现它的价值远不止“集中管key”这一点。我在接入十多个模型后对这个问题有了非常具体的体会。1.1 从“接两个API”到“接二十个API”的失控时刻早期项目只接GPT和通义每个模型写个独立封装环境变量放两个key出问题直接看各自控制台完全能忍。但AI应用一旦做起来情况就完全不一样了模型来源五花八门OpenAI、Claude、Gemini、国产各家大模型、微调后的私有模型、本地用vLLM或Ollama跑的开源模型鉴权方式、计费方式、限流策略全都不一样。上游接口格式不统一有纯OpenAI兼容格式的有只提供自家SDK的还有流式和非流式返回结构完全不同的。模型迭代太快今天qwen2.5-7b微调版本上线明天换更强的主模型应用侧不希望为了换个模型重新发版。多模态、知识抽取、Agent这类新场景要求动态路由不同请求要能打到不同模型上而不是写死。这些需求叠加在一起光靠业务代码里做适配层是撑不住的。你需要一层独立的“中间人”把上游所有差异都消化掉给下游应用一个稳定的OpenAI兼容接口。1.2 聚合网关究竟帮你干了哪几件事按我落地后的理解一个合格的聚合网关至少要解决六件事统一API格式无论上游是OpenAI、Azure、Bedrock、国内厂商还是本地推理服务网关统一暴露成OpenAI兼容的接口业务侧只需要维护一个客户端。密钥与令牌管理上游密钥集中保存在服务端下游只发放单独生成的令牌token可以随时吊销、限流、分组不用把各家平台key暴露给前端。模型路由与故障转移同一个逻辑模型可以配置多个上游渠道按权重、优先级分发某个渠道挂了或限流自动切换备用渠道。配额与计费统计记录每个令牌、每个用户、每个项目的请求次数和token数按渠道单价换算成费用方便内部结算和成本分摊。日志与可观测性记录请求耗时、状态码、错误信息出问题时能快速定位是网关、上游还是网络的问题。流式响应透传大模型回答的实时渲染依赖SSE流式输出网关必须正确透传流式数据并且客户端abort时能同步切断上游请求避免资源泄漏。想清楚这六件事你再看市面上各种网关就会明白它们其实是在不同维度上做取舍。有的偏开发者体验有的偏管控能力有的偏生产稳定性。我接下来拆解的这四款正是三个不同方向的典型代表。2. 四款主流网关逐个拆解每个人的技术栈和团队构成不同对“好用”的定义完全不同。我按实际体验把四款网关从定位、核心能力到适用人群拆开讲。2.1 WoolGate可视化控制台优先的“轻量新玩家”WoolGate 是这四款里名气最小的一个但我把它放进对比是因为它的定位非常清晰面向中小团队主打“开箱即用”和“好看的后台”。第一次打开它的管理界面确实比另外几款现代不少。渠道配置、令牌管理、模型分组、调用统计都在网页上完成几乎没有学习成本。它同样支持OpenAI兼容格式的输出接入上游模型后给下游分配一个令牌业务侧直接用OpenAI SDK改个base_url就能跑通。它最打动我的一点是“模型分组”的设计。比如你可以把“qwen-max”“gpt-4o”“claude-sonnet”分到一个叫“主力模型”的组里下游请求统一用这个组名后续调整组内实际模型时应用侧完全不用改代码。这个思路生产环境非常实用。但它的问题也很明显上游渠道适配数量少很多偏门模型需要自己提issue等支持插件和生态刚开始起步复杂场景下的扩展能力有限计费报表做得比较简单如果要做精细到项目维度的成本分摊会有点吃力。适合团队规模不大、模型数量不多、追求快速落地的场景。2.2 LiteLLMPython生态里的“瑞士军刀”LiteLLM 在开发者圈子里口碑很好它最初是一个Python SDK用统一的函数调用格式接入了100多家模型服务后来在此基础上加了Proxy能力变成一个轻量级网关。它的核心优势在于“代码优先”。你可以用pip install litellm[proxy]装好写一个config.yaml描述上游渠道和模型映射一条命令启动服务就能得到一个兼容OpenAI格式的代理。它还提供了debug模式请求失败时日志非常详细对排查问题极其友好。在多模型场景下LiteLLM的“fallback”机制挺好用。比如主请求发给claude-sonnet如果超时或报错自动fallback到gpt-4o这个在配置里几行就能搞定不需要自己写重试逻辑。而且它对本地模型很友好Ollama、vLLM这类本地推理服务都能直接配成上游渠道。不过它也有门槛整套东西的灵活性来自Python配置和代码对不熟悉Python的运维同学不太友好管理界面比较朴素专注功能但谈不上好看令牌管理、多租户能力比One API弱一些。如果你想在业务代码里直接调用多种模型同时又要一个统一代理LiteLLM是首选。2.3 One API老牌开源功能最全的“水桶机”One API 我身边不少团队用了很久它的定位是“全功能网关”从渠道管理、令牌管理、额度控制、兑换码到用户体系无论你要不要用它都有。它的核心是“渠道”和“令牌”两层模型。上游模型通过渠道接入渠道可以配置多个支持权重、优先级和自动禁用下游应用通过令牌访问令牌可以限制额度、设置过期时间、限定可用模型。对要给团队里不同人开通账号、设置不同额度的场景One API非常顺手。One API 内置了一套用户/管理后台数据持久化支持SQLite和MySQL。部署起来也简单拉个Docker镜像映射端口设置一下session密钥就能跑。OpenAI兼容接口是默认能力业务侧几乎零改造就能切过来。比较“劝退”的点有两个一是功能太多初级用户容易不知道从哪里下手配置项之间的逻辑关系需要理解一会儿二是它的界面风格偏“传统工具”没WoolGate那么现代但胜在稳定和成熟。如果你需要精细的权限管控、额度分发、多用户运营One API基本是这个赛道里的标准答案。2.4 New API站在One API肩膀上的优化分支New API 是 One API 的分支项目名字起得很直白就是“新”。它保留了One API大部分功能针对新模型形态和并发场景做了不少优化。从界面和操作逻辑看New API 和 One API 非常接近用过One API的人几乎可以直接上手。差异主要集中在几个方面一是支持了更多新模型渠道特别是绘图类和多模态渠道接入配置更顺滑二是在并发处理上做了优化我在同样的机器上压测New API 在高并发下的响应稳定性和内存占用比 One API 略有优势三是对请求日志、令牌列表等做了细节改进查问题更快。但需要注意分支项目的上游同步是有滞后风险的。如果后续One API主分支更新了大量新功能New API可能需要一段时间才能同步。我的建议是如果你之前没部署过任何网关直接上New API问题不大如果你线上已经跑了One API并且稳定没必要为了追新而迁移等真有需求再说。3. 同台对比按你实际场景打分四款网关各有侧重参数层面很容易罗列但真正落到自己环境里还是要看匹配度。我从功能、部署、运维、扩展几个维度做了对比顺便把选型逻辑讲清楚。3.1 功能维度对比表以下是我在相同测试条件下同一台4核8G服务器、同样的上游模型、各网关默认配置的体感对比不是官方参数仅供参考维度WoolGateLiteLLMOne APINew API项目定位轻量可视化网关Python SDKProxy全功能管理型网关One API 优化分支上游渠道适配数一般极多多多OpenAI兼容接口支持支持支持支持流式SSE透传支持支持支持支持控制台界面现代美观朴素传统全面传统全面令牌配额管理基础一般强强多用户/多租户弱弱强强按token计费统计基础中等强强故障自动转移支持支持支持支持配置复杂度低中中中扩展/插件生态弱较强较强较强Python代码集成弱极强弱弱这张表看下来它们的分工其实已经很清楚了。WoolGate适合要“快”的场景LiteLLM适合要“代码灵活”的场景One API和New API适合要“管人、管钱、管配额”的场景。3.2 部署与运维难度别小看“好不好维护”我踩过不少部署的坑这里单独说说运维体感。WoolGate是四款里最容易上手的官方提供了镜像docker run一条命令就能起服务然后访问网页初始化跟着提示填渠道、建令牌十分钟能跑通。日志界面做得也好调用失败时能看到请求和响应体。LiteLLM的部署本身不难但对环境有要求。你得熟练使用pip、虚拟环境以及config.yaml里各种字段的含义。debug模式开起来以后日志量很大需要提前规划日志收集。如果你本来就在Python技术栈里工作维护成本很低如果团队全是Java或Go背景我建议慎重这玩意儿出问题的时候不会Python基本无从下手。One API和New API部署都走Docker方案环境变量不多数据落SQLite或MySQL。日常维护主要是备份数据库、检查令牌过期、清理日志表。因为功能多偶尔会出现配置项之间互相影响的情况但通常翻一眼文档能解。整体来说只要能把Docker Compose跑熟这两款难度是可控的。3.3 我怎么选一个可以照抄的决策流程如果现在有人问我“该选哪款”我会先反问三个问题你是纯做应用开发还是需要同时运营几十个下游用户前者选LiteLLM或WoolGate后者闭眼选One API或New API。你的团队技术栈是什么Python多选LiteLLM其他语言为主选One API系或者WoolGate。你的核心诉求是快速上线还是长期稳定可控图快选WoolGate图稳选New API或One API。举两个真实场景。场景一一个创业团队做AI客服后端是Node.js三个开发者模型就用了两三家希望一周内上线。WoolGate就非常合适界面友好配置简单省去很多沟通成本。场景二一个中型公司在做AI中台要给内部五个部门发不同额度的token对接十多个模型还要按月输出成本报表。这种一定要上One API或New API它们俩的多租户和计费统计能力才是真正的刚需。4. 部署实战三套可以直接抄的配置理论聊够了直接上干货。我把自己实际部署成功的流程整理成三套方案对应上面三句话的结论。所有配置都是我跑通过的复制时改掉密码和密钥就能用。4.1 用 Docker Compose 先把 One API / New API 拉起来One API和New API的部署方式几乎一样下面以New API为例One API把镜像名换成justsong/one-api即可。新建一个docker-compose.ymlservices: new-api: image: calciumion/new-api:latest container_name: new-api restart: always ports: - 3000:3000 environment: - TZAsia/Shanghai - SESSION_SECRETplease_change_this_to_a_long_random_string - SQL_DSNroot:your_passwordtcp(mysql:3306)/new_api - REDIS_CONN_STRINGredis://redis:6379 depends_on: - mysql - redis volumes: - ./data:/data mysql: image: mysql:8.0 container_name: new-api-mysql restart: always environment: - MYSQL_ROOT_PASSWORDyour_password - MYSQL_DATABASEnew_api volumes: - ./mysql-data:/var/lib/mysql redis: image: redis:7-alpine container_name: new-api-redis restart: always volumes: - ./redis-data:/data启动命令就一条docker compose up -d启动后访问 http://服务器IP:3000 首次打开会让你设置管理员账号。进去之后第一件事是进入“渠道”页面添加你的上游模型。比如要接OpenAI渠道类型选OpenAI密钥填你的OpenAI Key代理地址按需设置要接本地vLLM渠道类型选OpenAI兼容代理地址填 http://你的vLLM服务地址:vLLM端口 。渠道添加完到“令牌”页面创建一个新令牌。下游应用连接时base_url指向 http://服务器IP:3000 api_key填这个令牌模型名填你在渠道里配置的逻辑模型名整个链路就通了。4.2 LiteLLM 的 Python 式部署与 OpenAI 兼容接入LiteLLM适合跟Python代码深度绑定。先装依赖pip install litellm[proxy]然后写一个config.yamlmodel_list: - model_name: gpt-4o litellm_params: model: openai/gpt-4o api_key: os.environ/OPENAI_API_KEY - model_name: claude-sonnet litellm_params: model: anthropic/claude-3-5-sonnet-20241022 api_key: os.environ/ANTHROPIC_API_KEY - model_name: qwen-max litellm_params: model: openai/qwen-max api_base: https://dashscope.aliyuncs.com/compatible-mode/v1 api_key: os.environ/DASHSCOPE_API_KEY - model_name: local-vllm litellm_params: model: openai/qwen2.5-72b-instruct api_base: http://127.0.0.1:8000/v1 api_key: fake-key这里有个细节litellm_params里的model字段前缀决定了走哪个供应商适配器比如openai/、anthropic/、bedrock/等。本地服务用openai/前缀加api_base指向本地地址就行。启动命令export OPENAI_API_KEYsk-xxx export ANTHROPIC_API_KEYsk-ant-xxx export DASHSCOPE_API_KEYsk-xxx litellm --config config.yaml --port 4000启动后LiteLLM会在 http://localhost:4000 暴露OpenAI兼容接口/v1/chat/completions、/v1/completions、/v1/embeddings这些路径都能直接用。你可以用curl验证curl http://localhost:4000/v1/chat/completions \ -H Content-Type: application/json \ -H Authorization: Bearer any-random-string \ -d { model: qwen-max, messages: [{role: user, content: 你好}], stream: true }注意LiteLLM如果没开启master keyAuthorization里的值是随便填的建议生产环境通过--master_key参数设置主密钥并配合详细的令牌管理规则。4.3 WoolGate 的快速启动与消息模型分组WoolGate 我体验下来最大的优势就是快。官方给的启动方式很简单一条Docker命令起服务docker run -d \ --name woolgate \ -p 8080:8080 \ -v /opt/woolgate/data:/data \ woolgate/woolgate:latest启动后访问 http://服务器IP:8080 进行初始化设置。创建管理员账号后你会看到一个引导流程添加渠道、创建模型分组、生成令牌。整个过程基本都是鼠标点选不需要写配置文件。我特别说下它的模型分组功能。在“模型”页面新建一个分组比如命名“main-chat”把gpt-4o、qwen-max、claude-sonnet都加进去保存后系统会生成一个逻辑模型名。下游申请令牌时把这个分组关联到令牌上应用调用时model参数填“main-chat”就行。后续想切换主力模型只需在后台调整分组里的渠道优先级——比如把某家模型置顶或下线完全不用改应用代码。这个操作对业务团队非常友好产品经理自己都能在后台做模型AB。4.4 接好上游后的第一件大事验证流式响应和中断渠道和令牌配好后很多人以为跑通一个普通chat请求就完事了但大模型应用大多需要流式输出所以务必第一时间验证SSE。给一个Java后端Spring WebFlux常见的接入写法WebClient client WebClient.builder() .baseUrl(http://网关地址/v1) .defaultHeader(Authorization, Bearer 下游令牌) .build(); FluxString stream client.post() .uri(/chat/completions) .bodyValue(Map.of( model, main-chat, messages, List.of(Map.of(role, user, content, 讲个笑话)), stream, true )) .retrieve() .bodyToFlux(ServerSentEvent.class) .map(ServerSentEvent::data);前端拿到这个流后逐段渲染。关键点是前端的中断处理比如用户点击“停止生成”时前端要主动调用AbortController的abort方法const controller new AbortController(); const response await fetch(/v1/chat/completions, { method: POST, headers: { Content-Type: application/json, Authorization: Bearer ${token} }, body: JSON.stringify({ model: main-chat, messages, stream: true }), signal: controller.signal, }); // 用户点击停止时调用 controller.abort()前端abort之后网关侧对应的上游请求必须被同步断开。我实测四款网关在这点上都处理得不错但如果你自己做了基于Nginx的反向代理一定要确认Nginx的proxy_buffering已经关闭否则SSE数据会被缓冲导致前端收到一坨一坨的碎块打字机效果彻底报废。5. 踩坑实录部署和接入过程中最常见的6个坑部署和接入这两个环节我前前后后折腾了一周多踩了不少坑。这里挑6个最有代表性的整理出来避免你们再走一遍弯路。5.1 模型名映射与渠道匹配混乱这是所有网关最容易踩的第一个坑。上游模型名、网关逻辑模型名、应用侧传入的模型名三者经常对不上。比如你在One API渠道里填了真实模型名“gpt-4o-2024-11-20”下游应用传入“gpt-4o”如果没做模型重定向网关会直接报model not found。通用的解法是在网关后台把逻辑模型名统一成业务可读的名字再用“模型重定向”功能把逻辑名映射到不同渠道的真实模型名。比如应用侧固定传“gpt-4o”后台把它重定向到“gpt-4o-2024-11-20”“qwen-max”任一渠道。这样运营换模型时应用代码是不动的。配置完务必用curl实测一遍三个名字的关系别凭感觉。5.2 SSE流式响应被缓冲前端打字机效果卡顿这个现象很像“流式请求没有生效”前端等了很久才一次性收到全部内容或者内容一跳一跳地出现。原因通常是两层一是网关本身对流式透传支持不好二是中间加了一层Nginx且没关缓冲。我当时的Nginx配置里代理转发需要手动加上proxy_buffering off; proxy_cache off; proxy_read_timeout 300s; proxy_send_timeout 300s;如果不关proxy_bufferingNginx会等上游数据积累到一定大小或连接关闭才往下发SSE就被“攒”住了。关掉之后再测逐字渲染就正常了。5.3 并发超时与上游限流的隐形冲突网关有一个默认超时时间如果上游模型本身响应很慢尤其本地vLLM在高峰期网关会先于上游超时导致应用收到504。但调大超时又会带来另一个问题并发上来时所有慢请求都挂在网关和上游之间占用大量连接和内存。我的经验是分三档处理第一把网关超时设成上游SLA的1.5倍左右别贪大第二对上游限流错误429做“熔断自动切换”配置而不是无限重试第三根据模型吞吐估算最大并发在网关层设置合理的请求并发限制避免慢请求拖垮整个网关。5.4 密钥管理的隐蔽坑很多人把上游密钥直接写进前端代码或者让前端直连网关这是大忌。网关的价值之一就是把上游密钥“藏”在服务端。下游令牌权限要最小化能只给某个模型就不给全部模型能用过期时间就不用永久令牌能被吊销就及时吊销。另外生产环境务必把管理后台和API代理入口分开。比如管理员后台只允许内网访问OpenAI兼容API端口才对外开放。我见过把8888管理端口直接暴露公网的黑客爆破弱口令后直接把所有上游渠道key都拖走了——这个后果相当酸爽。5.5 账单与额度统计对不上跑了一段时间后可能发现网关报表里的费用跟上游平台账单对不上通常是两个原因一是流式请求和非流式请求的计费逻辑不同有些网关对流式请求的token估算不准确二是部分国内厂商按“模型按次”或“按请求字符数”计费网关统一按token计费时必然有误差。解决办法是在网关后台按“渠道”维度核对费用不要只看总报表同时把网关的计费单价跟上游实际单价保持同步改了上游价格就及时更新。如果只是内部成本分摊误差控制在10%以内通常能接受。5.6 升级与数据迁移要养成备份习惯One API和New API之间切换、或者做版本升级时最容易出问题的是数据库。SQLite版迁移到MySQL版或者从One API迁到New API都涉及表结构变化。直接拿旧库文件启动新版本镜像可能遇到启动失败或数据读取异常。建议建立基础设施级的习惯每次升级前先备份数据库文件迁移前先在新环境起一个临时实例验证一次确认令牌、渠道、日志数据都正常后再切换线上流量。我个人的做法是每周自动备份一次数据库升级前额外手动备份一次这样任何翻车都能秒级回滚。问题现象排查方向快速解法请求返回model not found模型名映射/重定向后台检查逻辑模型名与渠道模型名前端流式输出卡顿/一次全出来Nginx缓冲关闭proxy_buffering并确认网关透传SSE大量504超时网关超时/上游负载分层设置超时配置429熔断与自动切换费用报表对不上计费单价/token统计按渠道维度核对及时同步上游单价管理后台被扫描攻击端口暴露管理端口限制内网强化密码升级后数据异常数据库结构不兼容先备份新环境验证后再迁移回到我自己的环境最终选了New API作为主网关原因是团队里有大量配额管理和报表需求稳定性优先。但Python端的快速原型项目我依然会单独起一个LiteLLM实例做验证。选型这件事没有标准答案只有适不适合你的实际场景。如果你也是刚刚开始搭建AI模型接入层我建议先按最小可行方案跑起来——选一款、接一个渠道、用一个下游应用完全打通再逐步加渠道和权限控制这比一开始就追求“全功能”要稳得多。另外网关上线后一定要记得定期检查令牌过期时间、上游价格变动和数据库备份这三个事看着不起眼关键时刻都能救命。