企业官网建设流程全解析

最近两周我一直在折腾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_LOG=INFO - DATABASE_URL=postgresql://litellm:litellm_password@postgres:5432/litellm - REDIS_URL=redis://redis:6379 command: ["--config", "/app/config.yaml", "--port", "4000"] restart: always postgres: image: postgres:16-alpine container_name: litellm-postgres environment: - POSTGRES_DB=litellm - POSTGRES_USER=litellm - POSTGRES_PASSWORD=litellm_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: 20

2.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: - TZ=Asia/Shanghai - SQL_DSN=root:newapi_password@tcp(mysql:3306)/new-api depends_on: - mysql mysql: image: mysql:8.0 container_name: new-api-mysql restart: always environment: - MYSQL_ROOT_PASSWORD=newapi_password - MYSQL_DATABASE=new-api volumes: - mysql-data:/var/lib/mysql command: --default-authentication-plugin=mysql_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网关怎么选：一张表说清楚

三款产品各有侧重，选型不是找“最好的”，而是找“最适合你当前场景的”。

我的具体建议是：如果你平时写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 键值问题排查速查表

我自己最终的生产方案是LiteLLM做网关层，New API做团队管理平台，两套并存——LiteLLM负责灵活的路由和故障转移，New API负责给团队分配额度。1Panel AI网关则部署在另一台轻量服务器上，专门给那些只需要简单统一入口的附属项目用。

这三款免费工具的成熟度已经相当可以了。除非你的场景对网关性能有极端要求，或者需要网关支持非常特殊的私有化模型协议，否则这三款里总有一款能解决你90%的需求。工具选型这事，别纠结于谁的星多，先想明白你要管多少人、要分多少额度、要控制多少成本，答案自然就出来了。