2026 one-api / new-api 部署教程：自建 AI API 中转网关，一套密钥接入全部模型

手里有大模型 API 的人，几乎都会遇到这几件烦心事：

ChatGPT 账号额度有限，充值麻烦，还有封号风险；DeepSeek、Kimi、通义各平台一个 Key，项目里换来换去；团队几个人用同一个 Key，谁调了多少钱根本不知道，超限了全体遭殃。

one-api 就是专门解决这些问题的：一个自建的 API 网关，把各种模型渠道统一成一个 OpenAI 兼容接口。你自己只用维护一个 Key、一个地址，剩下的渠道管理、额度统计、访问控制都交给它。这篇文章完整讲清楚怎么部署和使用。

一、one-api / new-api 是什么？#

one-api 是 GitHub 上 30k+ Star 的开源项目（作者 songquanpeng），核心功能一句话：LLM API 管理 & 分发系统。

聚合渠道：OpenAI、Azure、Anthropic Claude、Google Gemini、DeepSeek、通义千问、Kimi、智谱、Ollama 本地模型……几十种渠道，在一个后台统一管理
统一出口：对外只暴露一个 OpenAI 兼容接口，所有客户端（ChatGPT-Next-Web、NextChat、LangChain、Dify、各类 IDE 插件）改个 base_url 就能用
令牌体系：给不同用户/项目发不同的令牌（类似 API Key），每个令牌可以设额度、限速、分组
额度统计：每个渠道的调用次数、Token 消耗、费用一目了然

new-api 是 one-api 的社区增强分支。one-api 后期更新变慢后，社区 fork 出 new-api 继续维护，在保留全部功能的基础上加了：

多租户/用户注册与充值系统（适合做分享站）
更完善的渠道分组、限流策略
AI 网关、日志审计等新特性
活跃更新（截至 2026 年仍在维护）

怎么选？#

对比项	one-api	new-api
定位	经典原版，稳定	增强分支，功能多
用户注册/充值	基础	完整（适合分享给朋友/社区）
更新频率	基本停更	持续维护
适合场景	自用、小团队	自用+分享、需要多用户管理

个人/小团队自用选 one-api 就够；要开给多人用、或者想要充值积分功能，选 new-api。 两者的部署方式几乎一样，本文以 one-api 为例，new-api 只需把镜像名换成 calciumion/new-api。

二、部署前的准备#

服务器：1 核 1G 就能跑（网关本身很轻，内存占用 200MB 级别），有域名更好（配 HTTPS 用）
Docker + Docker Compose
模型渠道的 API Key：比如 DeepSeek 的 Key、OpenAI 的 Key

网关本身很轻，对服务器要求不高，但要注意：如果你要中转 OpenAI/Claude 这类海外模型，服务器最好选能直连海外的节点，否则请求还是会卡在网络环节。预算有限的话可以看伤心的云的美国洛杉矶机——1核1G 才 18.88 元/月，海外线路直连 OpenAI 等模型 API 很顺，跑网关加日志存储绰绰有余；香港款则适合中转 DeepSeek 等国内模型，大陆访问后台管理界面也快。免备案、随开随用，先小机器跑起来，流量大了再升级。

三、Docker Compose 部署 one-api#

1. 创建部署目录和配置文件#

1
mkdir -p /opt/one-api && cd /opt/one-api

新建 docker-compose.yml（含 MySQL，数据持久化更稳）：

1
services:
2
  mysql:
3
    image: mysql:8.0
4
    container_name: one-api-mysql
5
    restart: always
6
    environment:
7
      MYSQL_ROOT_PASSWORD: your-root-password
8
      MYSQL_DATABASE: oneapi
9
    volumes:
10
      - ./mysql:/var/lib/mysql
11

12
  one-api:
13
    image: ghcr.io/songquanpeng/one-api:latest
14
    container_name: one-api
15
    restart: always
16
    depends_on:
17
      - mysql
18
    ports:
19
      - "3000:3000"
20
    environment:
21
      SQL_DSN: root:your-root-password@tcp(mysql:3306)/oneapi
22
      TZ: Asia/Shanghai
23
    volumes:
24
      - ./data:/data

想省内存可以去掉 MySQL 服务，把 SQL_DSN 删掉，one-api 会退回到内置 SQLite——个人自用完全够。

2. 启动#

1
docker compose up -d

等十几秒，访问 http://服务器IP:3000：

首次访问，注册的第一个账号自动成为管理员
登录后进入「设置」，把「系统名称」「网站地址」改成自己的

3. 配置 HTTPS（推荐）#

后台管理、令牌调用走 HTTPS 更安全。用 Caddy 一行配置搞定自动证书：

1
api.example.com {
2
    reverse_proxy 127.0.0.1:3000
3
}

或者用 Nginx Proxy Manager 面板点几下配好反代和证书。

四、核心概念：渠道、令牌、分组#

这三个概念是 one-api 的灵魂，先理解再操作：

渠道（Channel）：一个渠道 = 一个模型来源。比如「DeepSeek 官方」是一个渠道，「OpenAI 官方」是另一个。一个渠道里可以配置多个 Key，自动负载均衡和故障切换
令牌（Token）：对外发的「钥匙」。一个令牌绑定一个分组，客户端拿令牌访问你的网关
分组（Group）：渠道和令牌都属于某个分组，默认分组是 default。可以建 vip、免费 等分组，实现不同用户用不同渠道/额度

五、实战：接入 DeepSeek + OpenAI，发给两个客户端#

1. 添加渠道#

「渠道」→「添加渠道」：

类型选 DeepSeek，填你的 DeepSeek API Key，分组默认 default
再添加一个类型选 OpenAI，填 OpenAI Key
保存后点渠道列表右侧的「测试」，绿色对勾 = 连通

2. 创建令牌#

「令牌」→「添加令牌」：

名称随便写（比如 chat-web）
额度填一个上限（比如 100 万 token 等价额度），超了自动停用——这就是给用户限量的方法
分组选 default

创建后把令牌复制下来（只显示一次），类似 sk-xxxxx 的字符串。

3. 客户端接入#

以 ChatGPT-Next-Web / NextChat 为例：

模型地址（API Base URL）填：https://你的域名/v1
API Key 填：刚才创建的令牌 sk-xxxxx
模型名填：deepseek-chat、gpt-4o 等

以 Dify 为例：模型供应商选 OpenAI 兼容模式，API Base URL 填网关地址，Key 填令牌，然后 Dify 里就能同时用 DeepSeek 和 GPT 了——一套网关，所有应用统一接入。

原理很简单：one-api 收到的请求带模型名，自动路由到对应渠道，把响应转发回来。客户端根本不知道背后有多个模型商。

六、进阶玩法#

多用户与配额#

在「用户」页面可以创建子账号（需要开启注册或手动添加）。给每个用户单独发令牌、单独设额度，谁超额了、谁调用失败，日志里一清二楚。new-api 还支持用户自助注册 + 虚拟充值，方便小范围分享。

模型映射#

渠道配置里的「模型映射」可以把一个模型名映射成另一个：比如把客户端请求的 gpt-4o 映射到实际的 deepseek-chat，实现「客户端代码一行不改，底层模型随便换」。

监控与告警#

配合 Nezha 监控盯服务器资源，配合 one-api 自带的日志页面盯调用量。渠道连续失败会自动禁用并告警，不用天天盯着。

七、常见问题（FAQ）#

Q1：one-api 和 new-api 哪个好？ 自用选 one-api（稳定简单）；要开分享站/多用户充值选 new-api（持续维护、功能全）。部署方式一样，迁移容易。

Q2：访问后台很慢 / 令牌调用超时？ 后台慢先看服务器带宽和延迟；调用超时优先排查渠道连通性——海外模型渠道在海外节点上跑更稳（见上文选型）。另外确认防火墙放行了 3000 端口。

Q3：渠道测试失败，显示 Unauthorized / Invalid API key？ Key 填错了，或者该渠道类型选错（DeepSeek 渠道类型不能选 OpenAI）。也有可能是网络问题——在服务器上 curl 渠道官方接口试试通不通。

Q4：客户端提示「model not found」？ 令牌可用但模型名不在任何渠道里。检查：客户端填的模型名是否与渠道支持的模型名一致；渠道是否属于该令牌的分组。

Q5：怎么给别人用又不让他乱来？ 创建令牌时设额度上限 + 选只读分组；new-api 下可以给子账号设每日限额。令牌泄露了就在后台一键删除，比直接暴露上游 Key 安全得多——这也是中转网关的核心价值。

Q6：数据会丢吗？ 令牌、渠道配置都存在数据库里，容器删了也不丢（MySQL 数据在 ./mysql 卷里）。建议定期把 /opt/one-api 目录备份走。

延伸阅读#

把自己的模型渠道管理起来，是每个重度 AI 用户迟早要做的事。one-api/new-api 部署成本极低、收益直接：一个入口管所有模型，一个令牌发所有人，额度开销一目了然。按本文步骤，半小时就能把网关跑起来。

音乐