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 LiteLLM：Python生态里的“瑞士军刀”
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服务器、同样的上游模型、各网关默认配置）的体感对比，不是官方参数，仅供参考：
| 维度 | WoolGate | LiteLLM | One API | New API |
|---|---|---|---|---|
| 项目定位 | 轻量可视化网关 | Python SDK+Proxy | 全功能管理型网关 | 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.yml：
services: new-api: image: calciumion/new-api:latest container_name: new-api restart: always ports: - "3000:3000" environment: - TZ=Asia/Shanghai - SESSION_SECRET=please_change_this_to_a_long_random_string - SQL_DSN=root:your_password@tcp(mysql:3306)/new_api - REDIS_CONN_STRING=redis://redis:6379 depends_on: - mysql - redis volumes: - ./data:/data mysql: image: mysql:8.0 container_name: new-api-mysql restart: always environment: - MYSQL_ROOT_PASSWORD=your_password - MYSQL_DATABASE=new_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.yaml：
model_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_KEY=sk-xxx export ANTHROPIC_API_KEY=sk-ant-xxx export DASHSCOPE_API_KEY=sk-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 key，Authorization里的值是随便填的；建议生产环境通过--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(); Flux<String> 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_buffering，Nginx会等上游数据积累到一定大小或连接关闭才往下发，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模型接入层，我建议先按最小可行方案跑起来——选一款、接一个渠道、用一个下游应用完全打通，再逐步加渠道和权限控制，这比一开始就追求“全功能”要稳得多。另外，网关上线后一定要记得定期检查令牌过期时间、上游价格变动和数据库备份，这三个事看着不起眼，关键时刻都能救命。
