很多人最开始接 AI API，都是在代码里直接写 OpenAI、Claude 或 Gemini 的地址。项目少的时候没问题，等你手里有三四个模型供应商、两三个项目、十几个 API Key，就会开始乱：
- 一个项目用 OpenAI 格式，另一个项目用 Claude 格式；
- 同事拿了主 Key，月底账单是谁用的说不清；
- DeepSeek 便宜，但有时候想自动 fallback 到别的模型；
- 给客户或内部工具分发 Key，又不想暴露上游真实 Key；
- 预算有限，希望每个 Key 有额度、限速和日志。
这时候就轮到 AI API 网关了。简单说，它就是你自己搭一个“模型入口”，后端接多个模型供应商，前端只暴露一个统一 API 地址。应用侧以后只需要改 base_url，不用到处改代码。
2026 年自建 AI API 网关，中文圈最常见的两个选择还是 One-API 和 New-API。One-API 是老牌项目，轻量、好理解；New-API 是基于 One-API 衍生出来的活跃分支，功能更多，支持 OpenAI、Claude、Gemini 等协议转换，也更适合多人、多渠道、多模型的场景。
先说结论：不是所有人都需要自建。
如果你只是个人用 ChatGPT，或者偶尔在脚本里调一下 DeepSeek，直接用官方 API 就够了。自建网关反而多了一层维护成本。
但下面几种情况就很适合：
| 场景 | 自建网关的价值 |
|---|---|
| 多个模型供应商 | 一个入口管理 OpenAI、Claude、Gemini、DeepSeek、通义、豆包等渠道 |
| 多个项目共用 | 每个项目发独立 Key，出问题可以单独停用 |
| 团队内部使用 | 可以看用量、额度、消费来源 |
| 给客户二次分发 | 不暴露上游真实 API Key |
| 想做成本控制 | 给每个 Key 设置额度、限速、模型权限 |
| 想做兼容层 | 让只支持 OpenAI 格式的工具接入更多模型 |
我见过最典型的用法是：一个 VPS 上跑 New-API，公司内部的 Dify、LobeChat、脚本任务、客服机器人都走这个统一入口。谁用多少 token，在后台一眼能看到。某个渠道抽风，就把它权重调低或者临时停掉，应用代码不用动。
这两个项目名字很像，但现在定位已经不太一样。
| 对比项 | One-API | New-API |
|---|---|---|
| 适合人群 | 想要轻量、简单、稳定的人 | 想要更多模型、更完整后台、更活跃维护的人 |
| 项目成熟度 | 老牌项目，逻辑清晰 | 社区更活跃，功能迭代更快 |
| 部署方式 | Docker / 单二进制 | Docker / Docker Compose / 面板 / 集群 |
| 协议支持 | 以 OpenAI 兼容为主 | OpenAI、Claude、Gemini 等多协议转换更强 |
| 功能复杂度 | 较低 | 较高 |
| 许可证 | MIT | AGPL-3.0 |
我的建议很直接：
- 个人自用、只想统一几个 OpenAI 兼容接口：One-API 够用；
- 团队使用、要多模型、多 Key、用量统计、协议转换：优先 New-API；
- 商业二开或闭源分发：务必看清许可证，New-API 是 AGPL-3.0，不要忽略这个坑。
One-API 官方仓库是 songquanpeng/one-api，New-API 现在比较活跃的是 QuantumNous/new-api。部署前建议先看 README 和官方文档，因为环境变量、镜像名和数据库支持会随版本变化。
AI API 网关本身不跑模型，只转发请求和记录用量，所以对 VPS 要求不高。真正烧钱的是上游模型，不是网关。
我建议这样选：
| 用途 | 推荐配置 |
|---|---|
| 个人自用 | 1 核 1GB 可以跑，2GB 更稳 |
| 小团队内部 | 2 核 2GB 起步 |
| 多人分发 + MySQL | 2 核 4GB 更舒服 |
| 高并发或商业服务 | 单独数据库 + 反代 + 监控，不建议省钱硬扛 |
磁盘 20GB 起步就够。日志别无限保留，不然几个月后你会发现数据库比程序大得多。
系统推荐 Ubuntu 22.04/24.04 或 Debian 12。容器部署最省事，后续迁移也方便。
下面用 New-API 举例。One-API 逻辑类似，只是镜像和环境变量略有差异。
先准备目录：
mkdir -p /opt/new-api
cd /opt/new-api
写一个最小可用的 docker-compose.yml：
services:
new-api:
image: calciumion/new-api:latest
container_name: new-api
restart: unless-stopped
ports:
- "3000:3000"
environment:
- SQL_DSN=root:change_this_password@tcp(mysql:3306)/new-api
- TZ=Asia/Shanghai
depends_on:
- mysql
mysql:
image: mysql:8
container_name: new-api-mysql
restart: unless-stopped
environment:
- MYSQL_ROOT_PASSWORD=change_this_password
- MYSQL_DATABASE=new-api
- TZ=Asia/Shanghai
volumes:
- ./mysql:/var/lib/mysql
启动：
docker compose up -d
docker compose logs -f new-api
然后访问：
http://你的服务器IP:3000
第一次登录后，马上做三件事：
- 修改默认管理员密码；
- 关闭不需要的公开注册；
- 配好反向代理和 HTTPS，不要长期裸奔 3000 端口。
如果你用 Nginx，可以这样反代：
server {
listen 80;
server_name api.example.com;
location / {
proxy_pass http://127.0.0.1:3000;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
}
再用 Certbot 或 acme.sh 签证书。生产环境不要只开 HTTP。
网关部署好只是第一步，真正要花时间的是渠道配置。
常见渠道可以这样分：
| 渠道类型 | 例子 | 注意点 |
|---|---|---|
| OpenAI 官方 | GPT-4o、GPT-4.1 等 | 价格高但稳定，注意账单限制 |
| OpenAI 兼容 | DeepSeek、Moonshot、OpenRouter 等 | base URL 不同，模型名要对齐 |
| Claude | Anthropic Claude | 协议和 OpenAI 不完全一样，New-API 更省事 |
| Gemini | Google Gemini | 部分模型上下文长，但速率限制要看清 |
| 国内模型 | 通义、豆包、智谱、文心等 | 鉴权和模型名经常不同，别照抄 OpenAI 参数 |
配置时建议按“用途”分组，而不是把所有渠道一股脑塞进去：
- 低成本聊天：DeepSeek / 通义 / 豆包；
- 高质量写作：Claude / GPT；
- 长上下文处理：Gemini / Claude 长上下文模型；
- 测试环境：便宜模型，限制额度；
- 生产环境：稳定渠道，单独 Key。
这样后面排查问题会轻松很多。
很多人自建网关最大的收益不是省钱，而是“权限收回来”。
正确姿势是：
- 上游真实 API Key 只放在网关后台；
- 每个项目、每个用户、每个环境分配独立 Key；
- Key 设置额度、过期时间、模型权限；
- 不同用途分开统计，比如
dify-prod、lobechat-home、crawler-test； - 出问题直接禁用单个 Key，不影响其他项目。
不要一个 Key 打天下。尤其是把 Key 写进前端项目、公开 GitHub 仓库、第三方插件时，泄露只是时间问题。
如果你只是自己用，限速可以宽一点。但只要给别人用，限速一定要开。
建议从这几个维度控制：
| 控制项 | 建议 |
|---|---|
| 每分钟请求数 | 防止脚本死循环刷爆额度 |
| 每日额度 | 防止单个用户把预算用完 |
| 模型权限 | 普通用户只能用便宜模型，高价模型单独授权 |
| 渠道权重 | 便宜渠道优先，高价渠道兜底 |
| 失败重试 | 别无限重试，上游 429 会越打越糟 |
一个真实的坑：某个脚本把异常重试写错了，模型接口 500 后每秒重试几十次。没有网关限速的话，上游账单会非常难看。有网关的话，最多就是这个 Key 被限流，不至于把整套系统拖死。
大部分 OpenAI 兼容工具只需要改两个地方：
API Key: 你在网关里生成的 Key
Base URL: https://api.example.com/v1
比如 Python：
from openai import OpenAI
client = OpenAI(
api_key="sk-your-gateway-key",
base_url="https://api.example.com/v1"
)
response = client.chat.completions.create(
model="deepseek-chat",
messages=[{"role": "user", "content": "写一段 VPS 备份脚本说明"}]
)
print(response.choices[0].message.content)
Dify、LobeChat、Cherry Studio、LibreChat 这类工具通常也能配置 OpenAI 兼容地址。填你的网关地址，就能把多个模型统一接进去。
AI API 网关暴露在公网，风险不比普通网站小。至少做这些：
- 管理后台强密码，能开 2FA 就开；
- 后台不要暴露在默认路径，或者用 Cloudflare Access / Basic Auth 再挡一层；
- Nginx 层加基础限速；
- 只开放 80/443，不要直接开放 3000；
- 数据库密码不要用示例里的
change_this_password； - 定期备份 MySQL；
- 记录异常用量，比如某个 Key 突然暴涨；
- 上游平台也设置预算提醒，不要只信网关。
Nginx 简单限速示例：
limit_req_zone $binary_remote_addr zone=aiapi:10m rate=10r/s;
server {
listen 443 ssl http2;
server_name api.example.com;
location / {
limit_req zone=aiapi burst=20 nodelay;
proxy_pass http://127.0.0.1:3000;
}
}
这个不是万能防护，但能挡住一部分脚本误用和低成本扫描。
网关本身可以重建，最重要的是数据库。
建议每天备份一次：
mkdir -p /opt/backups/new-api
docker exec new-api-mysql mysqldump \
-uroot \
-p'change_this_password' \
new-api > /opt/backups/new-api/new-api-$(date +%F).sql
再配合 rclone 或对象存储同步到异地。不要只把备份放在同一台 VPS 上，硬盘坏了等于没备份。
迁移时一般就是三步：
- 新服务器安装 Docker；
- 拷贝
docker-compose.yml和 MySQL 数据/备份； - DNS 切换到新服务器。
如果业务比较重要，建议先在新机上恢复一遍，确认后台、Key、渠道和日志都正常，再切域名。
上游叫 deepseek-chat，你的应用里写了 gpt-4，当然会报错。先在网关里确认模型映射，再改应用配置。
有些反向代理或 CDN 会缓冲响应，导致流式输出变成“一次性吐出来”。Nginx 里可以关掉 proxy buffering：
proxy_buffering off;
429 大多是上游限速或余额问题。先看渠道日志，再看应用日志，不要一上来重启容器。
检查这三个点：
docker compose ps
ss -lntp | grep 3000
ufw status
容器正常不等于端口可访问，防火墙和云厂商安全组也要看。
如果你只是想快速把多个 AI API 统一起来，我建议直接上 New-API。它功能更全，社区更活跃，适合 2026 年这种多模型混用的环境。
如果你很在意简单、轻量、许可证宽松，One-API 仍然可以用。只是后续你可能会遇到功能不够、协议转换不够方便的问题。
最稳的落地方式是：
- 用 2 核 2GB VPS 起步；
- Docker Compose 部署 New-API + MySQL；
- Nginx 反代 + HTTPS；
- 每个项目单独发 Key；
- 开额度、限速、日志；
- 每天备份数据库；
- 上游平台也设置预算提醒。
AI API 网关不是为了炫技。它真正解决的是“模型越来越多，Key 越来越乱，账单越来越难看”的问题。如果你已经在多个项目里接 AI API，现在花半小时搭一层网关，后面会省很多排查和管理时间。