两个开源项目New-API + Sub2API，搭建你自己的 AI 模型聚合网关

大家好，我是蓝戒。这篇笔记想和你聊聊：”New-API + Sub2API 搭建属于自己的 AI 模型聚合网关“。

文章会涉及一些关于"对外服务"的讨论，但我想先说在前面：本文重点是技术方案本身，而非教你如何"做生意"。涉及商业化的部分，更多是帮你理解这套架构在真实场景中的位置，以及它的边界在哪里。

---

一、为什么会有"AI 网关"这种需求？

如果你最近在用 AI，可能会发现一个现象：身边接入大模型的开发者越来越多，但他们的痛点也越来越一致——

• OpenAI、Anthropic、Google 各家的 API 格式都不一样，接一家写一套代码；
• 不同模型的计费、限流、错误码各不相同，运维成本高；
• 单一渠道一旦出问题（限速、宕机、封号），业务直接中断；
• 个人或小团队想统一管理多个 Key、控制成本、做用量统计，缺乏趁手的工具。

于是就有了"AI 网关"这个中间层的需求：把多家模型的接口聚合起来，对外暴露一套统一的、标准化的 API。

在企业内部，它解决的是"多模型统一治理"的问题；在面向第三方的场景里，它演化成了所谓的"AI 中转站"。两者技术内核一样，区别只是服务对象。

而搭建这样一个网关，技术门槛其实不高。社区里有两个比较活跃的开源项目可以组合使用：New-API 和 Sub2API。下面分别拆解。

---

二、New-API：开源的 AI 模型聚合网关

2.1 它是什么

New-API 是一个基于 Go 语言开发的开源 AI 网关项目，从早期的 One-API 项目衍生而来，在社区里有较高的关注度。它的核心定位可以用一句话概括：

将各家 AI 模型的异构接口，统一封装为一套标准 API。

举个例子：OpenAI 的对话接口是 /v1/chat/completions，Claude 用的是 /v1/messages，Gemini 又是另一套规范。如果一个应用想同时调用这三家，开发者得分别适配。New-API 做的事情，就是让你只用一种格式（通常是 OpenAI 兼容格式）发请求，由它在后端完成协议转换。

2.2 主要能力

（1）多模型聚合
支持 OpenAI、Claude、Gemini、DeepSeek、通义千问、文心一言、智谱 GLM、Midjourney、Suno 等主流模型，基本覆盖目前常见的需求。

（2）协议格式转换
相比早期的 One-API，New-API 不仅支持 OpenAI 格式互转，也支持以 Claude 原生格式、Gemini 原生格式对外暴露，方便不同客户端接入。

（3）多渠道负载均衡
同一个模型可以配置多个上游 Key，按权重随机分发；某个渠道返回错误时自动重试下一个，对调用方透明。

（4）计费与配额体系
内置按 token 计费、配额管理、充值码、邀请机制等模块，并支持对接常见支付方式，适合需要做用量核算的场景。

（5）用户与权限管理
支持多级用户分组、模型访问权限控制、IP 白名单、速率限制等精细化策略。

2.3 部署

部署用 Docker 一行命令即可：

docker run --name new-api -d --restart always \
  -p 3000:3000 \
  -e TZ=Asia/Shanghai \
  -v ./data:/data \
  calciumion/new-api:latest

启动后访问 http://你的IP:3000，默认账号 root、密码 123456，第一件事一定是改密码。之后就可以在后台配置上游渠道、创建用户、生成令牌。

---

三、Sub2API：把订阅会话封装为 API

3.1 它解决什么问题

New-API 的前提是你有上游的 API Key。但实际操作中会遇到一个情况：有些模型的 API 额度获取门槛较高（例如 Anthropic 对个人开发者的 API 配额管控较严），而很多人手里持有的是 ChatGPT Plus、Claude Pro 这类面向终端用户的订阅账号——它们只能在网页端使用，不直接提供 API 接口。

Sub2API 的思路是：通过模拟浏览器会话的方式，把订阅账号的对话能力封装为一个 OpenAI 兼容的 API 端点，从而让 New-API 可以把它当作普通渠道接入。

3.2 工作原理（简化版）

1. 用户在 Sub2API 后台录入订阅账号的会话凭证；
2. Sub2API 维护一个会话池，模拟网页端的请求行为；
3. 对外暴露一个 /v1/chat/completions 端点；
4. New-API 将其作为渠道之一接入，对调用方完全透明。

3.3 部署

docker run -d --name sub2api \
  -p 5000:5000 \
  -v ./data:/data \
  calciumion/sub2api:latest

3.4 一个必须正视的边界问题 ⚠️

这部分我必须单独拎出来说，而不是放在文末轻描淡写带过：

通过 Sub2API 将个人订阅账号转为 API 对外提供服务（尤其是收费服务），通常违反 OpenAI、Anthropic 等服务商的用户协议。具体来说：

• 账号共享条款：个人订阅明确限制单一自然人使用，不允许多人共用或转售；
• API 商用条款：将网页端会话包装为 API 商用，属于规避官方 API 计费体系；
• 后果：轻则账号封停（沉没成本），重则可能涉及违约责任。

因此，Sub2API 这类工具更适合用于个人自用场景——比如你自己有多个客户端，想用统一接口调用自己的订阅账号，而不是用于对外提供服务。如果用于对外服务，建议优先采用官方 API Key 渠道。

---

四、组合起来的整体架构

把两个项目组合，整体调用链路是这样的：

调用方 → New-API（统一网关）→ OpenAI API（官方渠道）
                            → Claude API（官方渠道）
                            → Gemini API（官方渠道）
                            → 其他第三方 API
                            → Sub2API（仅个人自用场景）

对调用方而言，他只需要知道一个网关地址和一个令牌，就能调用所有接入的模型。

4.1 典型配置参考

模型	上游来源	适用场景
GPT-4o	OpenAI API	通用对话、生产环境
Claude 3.5 Sonnet	Claude API	长文本、代码场景
Gemini 2.0 Flash	Google API	高性价比、多模态
DeepSeek V3	DeepSeek API	国内可直连、成本低
国产模型	通义 / 文心 / 智谱	国内合规场景

4.2 应用场景

搭好这套网关后，常见的几类用途包括：

• 个人多客户端统一接入：你可能在用 Cherry Studio、Cursor、NextChat 等多个客户端，通过网关统一管理 Key 和用量；
• 团队内部共享：小团队成员共用一组上游 Key，由网关做权限和配额管理；
• 企业内部 AI 平台：作为公司内部 AI 中台的一部分，统一对接外部模型，并做审计、脱敏、日志留存；
• 对外服务：以官方 API Key 为基础，向用户提供聚合服务（这部分涉及合规问题，下一节专门讨论）。

---

五、关于"对外提供服务"的合规与现实考量

如果你考虑把这套网关用于对外服务（也就是俗称的"AI 中转"），有几件事必须正视，而不是只看到收益的一面：

1. 国内监管框架
在中国境内向公众提供生成式 AI 服务，需要遵守《生成式人工智能服务管理暂行办法》，涉及算法备案、内容安全等要求。直接将境外大模型 API 转售给国内用户，处于较为敏感的灰色地带。

2. 上游服务条款
即使使用官方 API Key 做转售，也需要确认是否符合上游服务商的转售许可条款。部分服务商对二次分发有明确限制。

3. 内容安全责任
作为服务提供方，你需要对用户通过你的网关产生的内容承担一定责任，包括违规内容过滤、日志留存、用户实名等。

4. 商业现实
单纯做"价差搬运"的模式，利润空间正在被快速压缩——上游降价、竞争者增多、用户对稳定性要求提高。如果只是看到"低门槛 + 看似可观的流水"就入局，往往会低估运维、客服、风控、合规的隐性成本。

5. 更值得探索的方向
比起做通用中转，把 AI 能力封装成面向特定场景的解决方案（例如教育场景的 AI 助教、法律场景的合同审查、企业内部的知识库问答）往往是更可持续的路径——技术门槛相近，但价值锚点完全不同。

---

六、从零搭建：完整实操步骤

下面给一份相对完整的部署步骤，默认场景是"个人或团队自用"。

6.1 准备工作

• 一台 VPS（建议 2 核 4G 起步）
• 一个域名（用于 HTTPS）
• 一个或多个上游 AI 账号
• Docker 环境

6.2 部署步骤

第一步：安装 Docker

curl -fsSL https://get.docker.com | bash

第二步：部署 New-API

mkdir -p /opt/new-api && cd /opt/new-api
docker run --name new-api -d --restart always \
  -p 3000:3000 \
  -e TZ=Asia/Shanghai \
  -v $(pwd)/data:/data \
  calciumion/new-api:latest

第三步（可选）：部署 Sub2API（仅个人自用）

docker run --name sub2api -d --restart always \
  -p 5000:5000 \
  -v $(pwd)/sub2api-data:/data \
  calciumion/sub2api:latest

第四步：Nginx 反向代理 + HTTPS

server {
    listen 443 ssl;
    server_name your-domain.com;

    ssl_certificate /path/to/cert.pem;
    ssl_certificate_key /path/to/key.pem;

    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;
    }
}

第五步：配置上游渠道

登录后台 → 渠道管理 → 添加渠道，填入对应模型的 API Key 即可。

第六步：创建用户和令牌

在用户管理中创建账号、生成令牌。调用方只需把任意 OpenAI 兼容客户端的 base_url 改为你的网关地址、api_key 改为生成的令牌即可使用。

6.3 运维建议

• 多渠道冗余：关键模型至少配置两个上游 Key，避免单点故障；
• 监控告警：用 Prometheus + Grafana 监控调用量、错误率、延迟；
• 速率限制：合理设置 QPS 上限和单用户配额，避免被滥用；
• 及时更新：关注两个项目的版本迭代，特别是安全补丁；
• 日志与审计：保留必要的调用日志，便于排查问题和应对合规要求。

---

七、写在最后

New-API + Sub2API 这套组合的价值，我个人认为更多体现在技术学习和个人/团队自用的层面：

• 它让你深入理解一个真实的 API 网关是怎么设计的；
• 它解决了多模型、多 Key 的管理痛点；
• 它让你对 AI 基础设施这一层有更直观的认知。

至于把它作为商业项目运营，我的态度是相对保守的——不是说没有机会，而是这个赛道的真正壁垒，从来不在"会不会部署"，而在合规能力、运营能力、对场景的理解，以及对风险的判断力。技术只是入场券。

如果你对 AI 工程感兴趣，搭一个自己的网关跑一跑、跟一跟两个项目的源码，比关注"能不能赚钱"本身更有长期价值。