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. LiteLLMPython玩家眼里的万能代理层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-yyyLiteLLM的模型配置逻辑是别名真实模型参数model_name是你暴露给业务方的名字litellm_params指向真实的模型。这样业务方永远只用gpt-4o这个名字你随时可以把它换成其他模型业务方无感知。3.2 日常配置与实测数据配置好了之后我把请求地址指向http://IP:4000/v1传入任意API KeyLiteLLM支持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_DSNroot:passwordtcp(mysql:3306)/new-apiNew 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. 三款网关横向对比与选型建议三款网关我都实际用了一段时间放在一起对比各自的画像已经很清晰。维度LiteLLMNew API1Panel AI网关部署难度中依赖YAML配置低网页初始化低面板一键安装管理界面简单完善简洁模型兼容性强服务多中模板多中主流几家令牌/子账号支持强粒度细基础支持日志查询基础强可筛选基础预算限制支持支持未深入验证延迟损耗约35ms约40ms约50ms适用人群开发者个人/技术团队中小团队、需要多人管理1Panel使用者、轻量需求按场景选型我的建议是个人开发者代码里用了多个模型服务想统一接入规范选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-size50m \ --log-opt max-file3 \ --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在传输中被抓包。别看这两项不起眼能挡掉大部分恶意扫描。