最近两周我一直在折腾AI网关起因特别朴实手上模型API越来越多OpenAI、Claude、DeepSeek、通义、豆包、智谱各家接口风格还不一样代码里到处是硬编码的base_url和密钥管理混乱不说项目交给同事维护时简直是一场灾难。后来实在顶不住了决定找个免费的AI网关统一收纳这些乱七八糟的接口。市面上开源的AI网关项目确实不少但真正常见、处于“开箱能用”状态的我筛下来集中测评了三款LiteLLM、New API外加1Panel官方出的AI网关。这三款定位不太一样但都覆盖了“免费、自托管、统一转发”这个核心场景。这篇文章不讲虚的直接把部署流程、配置要点、性能实测数据还有我踩过的坑都摆出来。如果你是个人开发者或小团队想把多个模型API收拢到一个入口管理这篇测评应当能帮你省下一整天的调研时间。1. 三个项目各是什么定位差别在哪里开始之前先把概念对齐。所谓AI网关说白了就是在你的应用和各家大模型API之间加一层反向代理所有请求先打到网关再由网关转发给真正的大模型服务商。这层代理不是单纯转发它统一了请求格式、聚合了密钥管理、补充了限流、计费、日志、负载均衡这类基础设施能力。再直白一点没有网关之前你接一个模型就要在代码里写一套SDK初始化接三个就要三套密钥散落在各个环境变量里。有了网关你的应用永远只面对一个OpenAI格式的接口背后挂多少个模型、模型换成哪家、密钥改没改应用层完全不用关心。这三款产品在解决同一类问题但切入的姿势完全不同。LiteLLM是Python社区里最活跃的AI网关项目之一它的核心哲学是“translator”——把市面上几乎所有主流大模型API转换成OpenAI兼容格式。你只要有OpenAI SDK就能调用Claude、Gemini、Bedrock、Hugging Face甚至各种自建模型配置通过一个config.yaml就能全部搞定Cloud Native味道很重适合有一定技术基础、偏好代码化配置的开发者。New API则更像是为“运营管理”设计的。它有完整的管理后台渠道、令牌、分组、额度、日志、充值面板一应俱全界面做得相当完善适合需要给多人分配额度、或者搞一套内部模型平台供团队使用的场景。这个项目是One API的衍生分支但在功能和易用性上做了不少扩展。1Panel AI网关是1Panel开源面板团队出的新功能模块。1Panel本身是个开源的Linux服务器管理面板定位对标宝塔但整体技术栈更现代化基于容器管理应用。它的AI网关更像是把网关能力内置到了面板生态里和面板的网站、数据库、容器管理联动胜在开箱即用、运维门槛低。三个项目并不是同一个维度上的纯竞争关系LiteLLM偏开发者工具New API偏服务运营平台1Panel AI网关偏面板集成能力。但这恰好覆盖了不同人群的真实选择放在一起对比评测才有参考价值。2. LiteLLM实测配置驱动的全能翻译官先说我花时间最多的LiteLLM。这项目文档写得不错社区活跃度也高GitHub上星数相当可观。它的核心能力就是把非OpenAI格式的API转成OpenAI格式然后通过config配置路由策略、密钥管理、预算限额和日志追踪。2.1 核心原理为什么大家都往OpenAI格式上靠LiteLLM之所以有用前提是整个生态已经默认OpenAI的API格式是事实标准。这就像USB-C成为充电口标准一样——不管各家硬件内部怎么设计对外统一用同一个口子兼容性立刻拉满。你本地装好LiteLLM代理服务后所有请求发到http://localhost:4000/v1/chat/completions带上OpenAI格式的JSON请求体。LiteLLM收到后根据你配置的模型名和密钥信息转成对应厂商需要的真实格式发给上游API再拿回结果转成统一的OpenAI响应格式返回给你。这样一来你的应用代码里只需要写一种调用方式背后模型随便换。我实测下来这种做法在模型切换场景中特别香比如某天DeepSeek的API不稳定我在config里把流量切到通义千问应用代码一行不用改只改配置就完成故障转移。2.2 部署步骤Docker Compose一把梭LiteLLM支持pip安装和Docker部署。我个人强烈推荐Docker Compose方式原因很简单它依赖PostgreSQL存数据、依赖Redis做缓存和限流裸机pip方式装这些依赖太费劲了容器化一条命令全部解决。我的docker-compose.yml配置如下version: 3.8 services: litellm: image: ghcr.io/berriai/litellm:main-latest container_name: litellm depends_on: - postgres - redis ports: - 4000:4000 volumes: - ./config.yaml:/app/config.yaml environment: - LITELLM_LOGINFO - DATABASE_URLpostgresql://litellm:litellm_passwordpostgres:5432/litellm - REDIS_URLredis://redis:6379 command: [--config, /app/config.yaml, --port, 4000] restart: always postgres: image: postgres:16-alpine container_name: litellm-postgres environment: - POSTGRES_DBlitellm - POSTGRES_USERlitellm - POSTGRES_PASSWORDlitellm_password volumes: - pgdata:/var/lib/postgresql/data restart: always redis: image: redis:7-alpine container_name: litellm-redis restart: always volumes: pgdata:部署过程很顺畅唯一注意的是首次启动时LiteLLM会做数据库迁移要等一小会儿。判断是否启动成功的标准很简单浏览器访问http://服务器IP:4000能看到LiteLLM的管理后台登录页。2.3 模型路由与密钥配置实操LiteLLM的精华全在config.yaml里面。我的配置示例拆给大家看model_list: - model_name: gpt-4o litellm_params: model: gpt-4o api_key: os.environ/OPENAI_API_KEY - model_name: deepseek-chat litellm_params: model: deepseek/deepseek-chat api_key: os.environ/DEEPSEEK_API_KEY - model_name: qwen-max litellm_params: model: qwen/qwen-max api_key: os.environ/DASHSCOPE_API_KEY - model_name: claude-3-5-sonnet litellm_params: model: anthropic/claude-3-5-sonnet api_key: os.environ/ANTHROPIC_API_KEY注意model_name是你自己定义的对外名称litellm_params.model才是真实模型标识。LiteLLM对每家有特定的前缀约定比如deepseek/、qwen/、anthropic/它靠这个前缀识别对应厂商的转换逻辑这个细节很容易踩坑。路由策略方面我实际测试了两种比较有用的配置模式。一种是fallback主模型挂了自动切备用模型router_settings: fallbacks: - {deepseek-chat: [qwen-max]}另一种是权重路由按比例分配流量。比如一天中80%的请求走便宜模型20%走高质量模型这个对降低成本有奇效router_settings: routing_strategy: weighted model_group_config: - group_details: mixed-model model_group: mixed models: - model_name: deepseek-chat weight: 80 - model_name: gpt-4o weight: 202.4 密钥管理与预算控制LiteLLM支持虚拟密钥机制你可以为每个开发人员或每个应用创建单独的虚拟密钥然后在虚拟密钥上绑定预算、限流规则甚至可以指定这条密钥能访问哪些模型。这个功能对公司内部或多人团队特别友好。比如我给前端同事一个只允许调用deepseek-chat的密钥月预算50块超过了直接拒绝调用给算法同事一个能调用所有模型的密钥但限流是每分钟60次。这样既隔离了权限又不会出现某个人写错了代码把所有预算烧光的情况。创建虚拟密钥的操作在管理后台的Virtual Keys页面完成密钥格式是sk-xxxx落库后仅在创建时显示一次原始值之后只能看到脱敏形式所以创建出来了立刻保存好。2.5 LiteLLM实测性能数据网关这类中间层的性能最直接的影响就是多一层转发的延迟。我拿一台2核4G的云主机做网关同区域访问上游API用python脚本压了1000次请求得到的平均额外延迟大约是8ms左右P99额外延迟在25ms上下。这个额外成本对于对话式LLM应用来说基本可忽略——一次模型响应通常要1到3秒8ms的转发开销占比不到1%。但要注意这只是同区域的成绩如果网关和上游API不在同一个地域额外延迟会显著升高所以在部署时尽量选择离上游模型服务商最近的地域。3. New API实测自带管理后台的模型运营平台再来看New API。如果说LiteLLM是为开发者准备的瑞士军刀New API更像是为管理者准备的控制面板。它的前身是One API项目属于社区里相当活跃的分支国内用户群体很大尤其适合需要给团队分配模型额度的场景。3.1 渠道-令牌-分组三层模型New API的管理逻辑核心是三层架构渠道、令牌、分组。渠道是上游模型服务的代称。比如你申请了一个DeepSeek的API Key那就在New API后台创建一个渠道渠道类型选择DeepSeek填上密钥和对应的模型列表这个渠道就就绪了。令牌是给下游使用者应用、开发者、团队成员的访问凭证。令牌可以绑定一个或多个分组可以设置额度上限、过期时间、模型权限甚至IP白名单。分组的作用最巧妙。你可以创建“default”和“vip”两个分组把DeepSeek渠道加到两个分组里把GPT-4渠道只加到vip分组。分配给普通成员的令牌绑定default分组分配给核心成员的令牌绑定vip分组这就实现了不同成员看到不同模型集合的效果。3.2 Docker Compose部署New API部署同样推荐Docker方式。官方提供了docker-compose.yaml我为了演示起见整理了一个最小可用版本version: 3.8 services: newapi: image: calciumion/new-api:latest container_name: new-api restart: always ports: - 3000:3000 volumes: - ./data:/data environment: - TZAsia/Shanghai - SQL_DSNroot:newapi_passwordtcp(mysql:3306)/new-api depends_on: - mysql mysql: image: mysql:8.0 container_name: new-api-mysql restart: always environment: - MYSQL_ROOT_PASSWORDnewapi_password - MYSQL_DATABASEnew-api volumes: - mysql-data:/var/lib/mysql command: --default-authentication-pluginmysql_native_password volumes: mysql-data:SQL_DSN连接的是容器内的MySQL数据持久化在volume里这样升级容器不会丢数据。默认端口3000启动后访问http://服务器IP:3000第一次进入会让你初始化管理员账号。3.3 上手配置与渠道接入示例登录后台后操作流程按顺序来先进入“渠道”菜单点“添加渠道”。以DeepSeek为例类型选DeepSeek名称随意填密钥填你从DeepSeek平台申请的API Key模型列表填deepseek-chat,deepseek-coder代理地址保持默认即可然后保存。保存后强烈建议点一下“测试”New API会发起一个真实的模型调用请求来验证渠道配置是否正确。这一步能省很多排查时间渠道密钥错了、网络不通、模型名不在列表里测试调用都会直接报错。之后进入“令牌”菜单创建令牌。设置名称、选择分组、设置额度。额度单位是美元也可以留空表示不限额。返回的令牌就是类似sk-xxxxxxxx的字符串你需要复制出来保存好页面刷新后不会再展示完整令牌。最后应用侧接入就简单了curl http://服务器IP:3000/v1/chat/completions \ -H Authorization: Bearer sk-你的令牌 \ -H Content-Type: application/json \ -d { model: deepseek-chat, messages: [{role: user, content: 你好}] }New API对外暴露的就是OpenAI兼容接口SDK和应用侧代码完全不用改只换base_url和API Key。3.4 New API比LiteLLM强在什么地方两个项目我都跑了真实项目和压测New API有两个明显优势是我感知比较强的。一个是管理后台的成熟度。LiteLLM的管理后台功能也不少但更多是“够用”页面设计偏程序员审美。New API的后台操作流程、数据表格展示、日志筛选体验都做得更像一个成熟商业产品运营人员也能轻松上手。另一个是渠道故障隔离机制。New API支持渠道级别的自动禁用当某渠道连续报错达到阈值时系统会标记渠道异常并自动在下游请求中跳过它配合通知渠道把告警推到钉钉或飞书。这个能力在LiteLLM里需要额外写脚本或者配置webhook才能实现。New API的token级审计日志也做得很细每个令牌的每次调用都记录模型、tokens数、耗时、错误信息这对于排查线上问题和做成本分摊非常有用。4. 1Panel AI网关实测面板生态里的轻量选择最后说1Panel AI网关。1Panel这项目我关注挺久了它是个开源Linux服务器面板对标宝塔但底层技术栈是容器化的应用商店、网站管理、数据库管理全是围绕Docker构建的。AI网关作为内置应用天然延续了这个思路。4.1 为什么面板里要内置一个AI网关1Panel内置AI网关这件事表面看是一个功能聚合其实是针对一个现实痛点很多个人站长、小型团队会用面板来管理自己的服务器和网站当他们想接入大模型API的时候并没有意愿去学YAML配置或者命令行部署一个专门的网关服务。对他们来说最自然的路径是在面板里找到AI网关应用点击安装打开Web界面填上各家模型的API Key然后在应用里获取一个统一的OpenAI兼容地址和密钥直接拿去用。这个路径我不需要给他们写部署文档他们自己就能完成。这就是1Panel AI网关的核心定位它不是给云原生极客准备的而是把AI网关从“开发者工具”降维成“服务器功能”。4.2 安装与首次配置我是在一台腾讯云轻量服务器上装的1Panel系统是Ubuntu 22.04安装命令那一行就不贴了直接去官网复制对应系统的一键脚本即可。装好后进入应用商店找到AI网关应用点击安装。1Panel会自动拉起一个独立的容器同时会默认创建一个MySQL数据库供网关使用。安装时间大概一两分钟完成后在已安装应用里进入管理页面。首次进入AI网关管理页面会引导你配置模型供应商。支持的供应商列表比我预期广OpenAI、Azure OpenAI、Anthropic、DeepSeek、通义、豆包、智谱等主流服务商基本都有选择供应商后填API Key即可完成接入。之后在网关的“API Key”页面创建一个访问密钥拿到一个统一入口地址。1Panel AI网关对外也兼容OpenAI格式所以应用代码侧接入方式和New API基本一致。4.3 功能完整度与实测感受功能方面1Panel AI网关覆盖了基础但完整的链路统一入口、多模型管理、密钥管理、令牌额度限制、调用日志、成本统计。我重点测了它的成本统计页面会按供应商维度汇总每日token消耗和费用估算做月度复盘够用了。延迟方面由于1Panel AI网关部署在同一台机器上的容器里网络链路比LiteLLM多走一层但也在内网实测额外延迟在5~10ms之间和LiteLLM相当。它在模型路由策略上相对保守没有LiteLLM那么灵活的fallback和权重分配也没有New API那种多租户分组的运营玩法。但产品完成度在同类型面板应用里已经相当不错胜在零成本上手、界面友好、和服务器本机网络环境天然打通。5. 三款AI网关怎么选一张表说清楚三款产品各有侧重选型不是找“最好的”而是找“最适合你当前场景的”。维度LiteLLMNew API1Panel AI网关定位开发者网关运营管理平台面板集成功能部署难度中需配置YAML和数据库中Docker一条龙可解低面板一键安装管理界面基础型够用成熟全面简洁友好模型路由灵活支持权重和fallback渠道自动容错无权重路由基础偏简单多租户分组弱强分组权限清晰弱额度与审计支持虚拟密钥和预算令牌额度精细可审计基础额度限制运维熟悉度要求高中低适合人群Python开发者、代码化配置党团队平台管理员、需要精分额度的人个人站长、面板用户、轻量使用我的具体建议是如果你平时写Python习惯用代码管理基础设施选LiteLLM它的配置灵活度和生态兼容性在三者里排第一如果你是要搭一个给团队公用的模型平台成员多、需要按人分配额度、看日志查账选New API如果你本来就装好了1Panel只是想快速把多个模型的API收拢到一个入口不需要太复杂的路由策略直接用1Panel AI网关就够了。6. 实测踩坑记录与问题排查速查表最后分享一下我在真实环境中遇到的坑这些细节文档里不一定写得很明显但实战中几乎都会撞上。6.1 LiteLLM的数据库连接与迁移问题LiteLLM首次启动时会自动执行数据库迁移如果PostgreSQL还没就绪就启动迁移会失败然后容器反复重启。解决方法是给litellm服务加一个healthcheck等PostgreSQL健康后再启动主服务。另外并发量上去后PostgreSQL默认连接数可能不够用建议在PostgreSQL配置里把max_connections调到200以上。6.2 New API的MySQL版本兼容New API对MySQL版本有一定要求。我一开始图省事用了MySQL 5.7结果建表时报错后来换成MySQL 8.0才顺利通过。热词里有人提到“1Panel的mysql无权限”也应该是类似的版本或账号权限问题。如果遇到Access denied for user这类错误先确认你的MySQL账号有没有对对应数据库的完全权限不要只给select权限网关运行需要建表、写数据。6.3 1Panel AI网关的常见报错1Panel AI网关我在Windows上没法直接装它依赖Docker环境Windows用户建议走WSL2或者装Docker Desktop后开Linux容器。官方给的安装脚本也是面向Linux的Windows下硬跑容易出各种奇奇怪怪的路径问题。如果你在1Panel AI网关中配置模型后调用报401先检查密钥配置区域是否有隐藏空格或换行符——这类问题在Web表单粘贴时经常出现密钥字段看起来对实际上末尾多了个回车。6.4 键值问题排查速查表现象可能原因排查与解决调用返回401或403密钥错误、密钥未生效、密钥被禁用后台重新生成密钥确认状态为启用报model_not_found模型名和网关配置不一致用网关后台实际配置的model_name请求超时上游API慢、网络链路长换地域部署、调大timeout日志有3200错误余额不足或限流触发检查令牌额度与速率限制配置并发高时响应变慢数据库连接耗尽或Redis未启用启用Redis做缓存和限流调整连接池容器反复重启依赖服务未就绪或配置文件语法错误查看容器日志等待依赖服务健康后再启动我自己最终的生产方案是LiteLLM做网关层New API做团队管理平台两套并存——LiteLLM负责灵活的路由和故障转移New API负责给团队分配额度。1Panel AI网关则部署在另一台轻量服务器上专门给那些只需要简单统一入口的附属项目用。这三款免费工具的成熟度已经相当可以了。除非你的场景对网关性能有极端要求或者需要网关支持非常特殊的私有化模型协议否则这三款里总有一款能解决你90%的需求。工具选型这事别纠结于谁的星多先想明白你要管多少人、要分多少额度、要控制多少成本答案自然就出来了。