三款免费AI网关实测对比：LiteLLM、New API、1Panel选型指南

1. 为什么突然测评三款免费AI网关

先说缘由。我被AI网关这个概念"骗"过很多次，最早以为是某种高大上的网络设备，后来发现干的事情其实很朴素：统一管住你手里的各类模型API，给你一个标准的OpenAI兼容地址，顺便帮你记账、限流、分配Key。

真正逼我动手的是一堆烂账。手上同时用着几个不同平台的模型API，项目代码里到处散落着各自的BaseURL和密钥，团队成员各领一个Key，月底对账全靠翻聊天记录。后来看到LiteLLM、New API和1Panel AI网关这三款免费方案，索性全部搭了一遍，踩了不少坑，今天把这轮测评的完整过程写下来。

这篇内容适合谁看：正在被多模型接入、API Key分配、请求日志混乱困扰的开发者，或者单纯想找个免费工具统一管模型调用的个人站长。测完我的结论是：没有绝对最好的网关，只有最贴合你使用习惯的方案。三款工具的定位完全不同，后面我会逐个拆解。

2. 测评环境与统一基准

先交代我的测试条件，免得后面数据失真。测试机是一台2核4G的云服务器，系统是Debian 12，三款网关全部用Docker Compose部署在同一台机器上，保证资源水平一致。

我用自己的OpenAI兼容并支持多个模型的聚合渠道作为上游测试源，三款网关都配成同一个上游渠道，再通过各自暴露的API去调用同一个模型，变量就控制在网关本身。

统一基准：

• 部署耗时：从开始拉镜像到第一个请求成功返回
• 首次请求延迟：冷启动后第一个请求的响应时间
• 连续请求延迟：预热后连续10次请求的平均响应时间
• 失败率：500个连续请求中的失败数量
• 资源占用：容器空闲状态下CPU和内存占比
• 运维成本：日常配置、日志查询、Key管理是否顺手

我不追求实验室级别的绝对精确，那没意义。网关层会增加多少延迟、配置起来痛不痛苦、出了问题能不能快速定位，这三个才是真实使用中最关心的。延迟我用curl计时，连续压测用自带脚本跑，没有上重型压测工具，因为网关场景下中小流量的表现更有参考价值。

3. LiteLLM：Python玩家眼里的万能代理层

LiteLLM在GitHub上有很高的star量，核心定位是给LLM应用提供一个标准化的OpenAI兼容入口，后接各种模型服务。我的理解是它像一个语言翻译官：你的应用只会说OpenAI那套话，它帮你转成别家模型听得懂的话再转回来。

3.1 部署与初始化

LiteLLM的部署非常简单，官方提供了Docker镜像，一条命令能跑起来。我用的是docker-compose方式，配置文件如下：

services: litellm: image: ghcr.io/berriai/litellm:main-latest ports: - "4000:4000" volumes: - ./config.yaml:/app/config.yaml command: ["--config", "/app/config.yaml"]

关键在config.yaml，这是LiteLLM的主配置入口，模型路由、密钥、限流规则全在这里定义。我配置了两个上游模型，一个兼容OpenAI接口，一个走兼容接口，核心片段如下：

model_list: - model_name: gpt-4o litellm_params: model: openai/gpt-4o api_key: sk-xxx api_base: https://your-upstream.example.com/v1 - model_name: claude-3-5-sonnet litellm_params: model: anthropic/claude-3-5-sonnet-20241022 api_key: sk-yyy

LiteLLM的模型配置逻辑是"别名+真实模型参数"，model_name是你暴露给业务方的名字，litellm_params指向真实的模型。这样业务方永远只用gpt-4o这个名字，你随时可以把它换成其他模型，业务方无感知。

3.2 日常配置与实测数据

配置好了之后，我把请求地址指向http://IP:4000/v1，传入任意API Key（LiteLLM支持master key机制），请求模型名填config里的别名。300个连续请求测下来，失败率是0，连续请求平均延迟比我直连上游慢大约35ms。这个额外开销主要来自LiteLLM的转发和日志记录，中低流量下可以忽略。

功能层面LiteLLM确实丰富：支持多模型负载均衡、请求重试、超时设置、预算控制、自定义鉴权。最常用的是它的budget功能，可以把每个Key的每日消费上限写死，超了就拒绝请求。我团队里有人跑测试脚本忘关循环，多亏这个设置才没烧太多钱。

LiteLLM自带一个简单的管理界面，能看请求日志和消费统计。但说实话界面比较朴素，胜在信息完整，每个请求的模型、耗时、token消耗都能查得到。

3.3 优劣势小结

LiteLLM的优势很明显：模型兼容性全，配置灵活，尤其适合已经有Python技术栈、愿意用配置文件管理一切的人。缺点是上手门槛其实不低，config.yaml的字段很多，第一次配置需要翻不少文档；管理界面功能简陋，团队非技术成员基本用不来。另外LiteLLM的日志是明文记录，日志量大的时候占磁盘空间很快，需要定期清理或配置外部存储。

提示：LiteLLM默认日志级别是INFO，日常使用建议调成WARNING，减少不必要的写入量。日志文件可以配置rotation，防止长期跑下来撑爆磁盘。

4. New API：把渠道和令牌管理做到极致的开源方案

如果说LiteLLM是给程序员用的转发层，New API更像是给团队用的管理后台。它最早脱胎于one-api项目，之后独立维护，界面和交互都现代化了很多，尤其适合多人共用一套网关的场景。

4.1 部署体验

New API同样一条Docker Compose命令启动，默认端口是3000。启动后通过浏览器访问，首次登录强制要求修改管理员密码。整个初始化过程可以全程在网页完成，对不熟悉命令行的用户友好。

services: new-api: image: kdcloudone/new-api:latest ports: - "3000:3000" volumes: - ./data:/data environment: - SQL_DSN=root:password@tcp(mysql:3306)/new-api

New API默认使用SQLite，单机使用够了。如果团队规模大、并发高，建议改用MySQL，官方文档有迁移说明。我目前单机用SQLite跑了快一个月，没有出现性能问题。

4.2 渠道、令牌、日志实操

New API的核心概念就两个：渠道和令牌。

渠道就是真实的模型服务商配置，你在后台填上服务商类型、API地址、密钥，它就代表一个可用来源。比如我想把上游一个兼容OpenAI的服务接入，填上渠道名称、BaseURL和Key，状态设为启用，渠道就创建好了。渠道支持分组，意味着你可以把高优先级的渠道和备用渠道分开，启用自动禁用机制后，连续报错超过阈值的渠道会被自动踢下线，系统自动切换到备用渠道。

令牌是给调用方用的，一个令牌对应一个子账号，可以限制额度、设置过期时间、指定可用模型。我们的做法是每个成员一个令牌，每个项目一个令牌，月底在令牌列表里直接看各项目消费对比，不需要再翻日志手算。这一点解决了我之前对账的痛点，谁调了多少、哪个模型花钱最多，一目了然。

New API还支持模型重定向和复制，可以把同一个模型映射到不同的底层模型。比如业务方请求gpt-4o，你可以配置映射到别的模型，前端无感知。它还提供了简单的分享页面，可以把令牌包装成一个网页聊天入口，方便不开API的同事体验。

实测性能：连续300个请求，失败率为0，连续请求平均延迟比直连上游约慢40ms。和LiteLLM差距很小，主要消耗在New API的日志和令牌鉴权环节。它的日志查询页面比较完善，可以按令牌、模型、状态筛选，点进单条日志能看到完整的请求体、响应体和token消耗。

4.3 优劣势小结

New API最大的优势是用起来直观，渠道、令牌、日志三大模块都做得清楚，非技术同学也能看懂消费报表。后台自带用户体系，不用自己对接SSO。缺点是模型接入的格式适配不如LiteLLM灵活，部分非标准模型服务需要自己摸索配置；Docker镜像更新比较频繁，作者迭代节奏快，有时一周能发好几个版本，跟随主力版本升级时要留意配置兼容性。

注意：New API后台默认不开启敏感信息脱敏，日志里会记录完整的请求体和响应体。如果业务对数据安全要求高，记得在设置里关掉请求内容日志，或者配置脱敏规则。

5. 1Panel AI网关：面板玩家的内置方案

1Panel是我一直在用的开源Linux面板，主要是看中它界面清爽、环境管理方便。前段时间发现它应用商店里出现了AI网关相关条目，正好借这次测评的机会装上试试。

5.1 从面板到网关：安装路径

1Panel AI网关的安装入口在面板的"应用商店"里，找到后一键安装，它会自动编排好容器和依赖。整个过程不需要敲命令，对已经在用1Panel的用户来说体验很顺。

如果你的服务器还没装1Panel，可以先装面板再装网关，也可以接受它作为一个独立应用来部署。我的建议是，如果你本来就在用1Panel管理服务器，装它的AI网关最省事，省掉单独维护一套网关镜像的工作量。

5.2 配置过程与"未设置服务器地址"报错复盘

安装完成之后我遇到了一个报错，提示：当前未设置服务器地址，请先在面板设置中设置！这个提示一开始让我有点懵，因为我的面板一直用着正常，部署网站、数据库都没问题。

排查之后发现，1Panel的AI网关需要依赖面板基础设置里的服务器地址来完成后续的回调、接口拼接。也就是说，你在面板设置里填的服务器地址必须正确，不能是内网地址或localhost，否则AI网关拿到内部地址后会无法正常通信。

在面板设置里把服务器地址改成实际可访问的公网域名恢复。这一步不会自动回填，很多人安装后第一次用就会卡在这里。

5.3 功能摸底与实测

1Panel AI网关目前的功能定位比较基础：模型渠道管理、令牌管理、基础日志。界面沿袭1Panel的简练风格，没有那么多花哨的东西。实测调用一次模型，延迟比直连上游多约50ms，在三款网关里属于中规中矩。

它最大的价值跟1Panel生态绑定：安装在面板内，统一开机自启、统一备份、统一升级，省去单独运维一套系统的精力。如果你本身是1Panel用户，愿意用它的All-in-One思路，这款网关足够日常轻量使用。

它的短板也很明显，离线模型类型支持少，配置自由度比不上LiteLLM，令牌粒度也不如New API细致。如果你需要复杂的负载均衡或预算控制，暂时不建议选它。

6. 三款网关横向对比与选型建议

三款网关我都实际用了一段时间，放在一起对比，各自的画像已经很清晰。

按场景选型我的建议是：

• 个人开发者，代码里用了多个模型服务，想统一接入规范，选LiteLLM。它的配置化治理能力在三者里最强，虽然界面上差点，但程序员最常用的还是改配置文件。
• 团队多人共用，需要对账、限流、分Key，无脑选New API。令牌和渠道这套设计就是为多人协作准备的，后台报表能省掉大量沟通成本。
• 已经在用1Panel管理服务器，想装个网关解决日常调用，选1Panel AI网关。它跟面板的深度集成是另外两款没有的优势，省心是第一位的。

7. 实测中遇到的共性问题与避坑清单

三款网关跑下来，有些问题是共通的，写出来给后来人提个醒。

第一个坑是Key前缀识别。OpenAI的Key，各家网关大多通过前缀判断渠道类型。如果你的上游Key不是标准前缀，网关可能识别不了，表现为请求直接报错。解决办法是网关里手动指定渠道类型，而不是依赖自动识别。

第二个坑是模型映射名不一致。同一个模型在网关配置里的名字，必须和上游渠道真实支持的模型名完全一致，否则会提示模型不存在。这个错误排查起来比较费劲，建议配置完渠道先用curl手动调一下真实模型名，确认能通再接网关。

第三个坑是日志磁盘占用。三款网关都默认写请求日志，长期高并发下日志文件增长非常快。我曾在LiteLLM上跑了一夜压测，日志涨了快10GB。建议从一开始就配置日志轮转和清理策略，不要等磁盘报警再处理。

# 给Docker容器添加日志轮转 docker run -d \ --log-driver json-file \ --log-opt max-size=50m \ --log-opt max-file=3 \ --name litellm \ litellm:latest

第四个坑是反向代理时的超时设置。网关前面如果挂了Nginx做域名转发，Nginx默认超时时间可能只有60秒，长任务请求还没返回就被nginx掐断。需要调大proxy_read_timeout和proxy_send_timeout，建议至少设300秒。这个问题三款网关都会遇到。

第五个坑是模型请求乱丢。LiteLLM如果配置了多模型负载均衡，某个渠道异常时会自动重试到其他渠道。但如果所有渠道的Key都失效了，网关不会给你明确的错误提示，只反馈一个通用错误。建议配置完就测试一次真实的坏Key场景，确认错误信息足够清晰，方便排查。

提示：使用AI网关时，建议在业务代码里加上超时和重试逻辑，不要完全依赖网关侧的重试。网关层重试次数太多会导致请求堆积，反而拖垮服务。

8. 一点个人体会

三款免费AI网关用下来，收获比我想象中大。原本混乱的API调用管理，现在统一走网关，代码里不用再散落各种BaseURL和Key。月底对账单直接从后台导出，团队成员各领各的令牌，哪个项目烧钱多一目了然。

如果你正在犹豫要不要上AI网关，我的建议是先从New API开始，它的网页管理对新手最友好，能快速解决Key管理和对账问题。跑顺手了再回头研究LiteLLM的配置化玩法，体验会更深。至于1Panel AI网关，我更看好它后续的迭代，毕竟跟面板的整合能力是天然的差异化优势。

最后再分享一个配置小技巧：不管用哪款网关，都建议在全局设置里开启"禁止匿名访问"和"仅限HTTPS访问"，前者防止网关暴露在公网被薅羊毛，后者避免Key在传输中被抓包。别看这两项不起眼，能挡掉大部分恶意扫描。