周三下午，团队里第三个人问你要那个大模型API的key。你翻聊天记录，发现上一次分发的时候忘了设额度，月底账单比预期多出42%。这不是某个人的问题——当调用AI接口的人超过两个，靠手动管理账号和密钥，出乱子只是时间问题。

Sub2API做的事很直接：在所有上游AI供应商前面放一个统一的访问入口。你这边只要给用户发一套Sub2API签发的key，网关在后端负责身份认证、请求路由、用量计算、并发限制。上游到底是哪个OpenAI账号、哪个Claude工作区、哪张Google AI Studio密钥，调用方完全不用知道。

打开网易新闻 查看精彩图片

按照项目官方文档的描述，Sub2API目前支持的模块包括：多种上游账户类型接入、平台级API密钥管理、token粒度的用量记账、粘性会话调度、单用户与单账户并发控制、速率限制、组合分组，以及一个管理后台。换句话说，企业里常见的那套API网关能力，它专门针对生成式AI的场景做了一遍。

但有一点需要说清楚：网关不生产算力。如果上游账户被停用、触发限流、或根本不支持某个模型，Sub2API没法凭空变出访问能力。项目的README文件也明确提醒，用订阅账号分发配额的行为，可能违反上游服务商的条款。所以第一版部署建议先在内部跑，使用自己有权使用的账户，并且在开放给更多人之前读完服务商的使用协议。

什么时候值得把网关请进来？如果你这边还是一个人直接调一个官方API，多加一层网关通常只会让链路更脆弱。自托管开始产生回报的节点，是当权限管理和请求路由已经变成协作中的协同痛点——比如多人共用不同供应商的多个账户，或者需要按人按模型精确控制用量的时候。

部署需要的环境是：一台Linux服务器、Docker 20.10或更新版本、Docker Compose v2、一个域名，以及至少一个已经在用的上游账户或API密钥。PostgreSQL和Redis都包含在官方提供的Compose堆栈里，不用额外准备。

项目官方给出了一套部署准备脚本。建议先把它下载下来看一遍内部逻辑，而不是直接执行。建立工作目录后，用curl从仓库拉取脚本，用less检查内容，再加上执行权限后运行。运行的过程中脚本会自动生成docker-compose.yml、创建.env环境变量文件、生成PostgreSQL密码和应用密钥、准备好本地数据目录。生成的敏感信息会打印在终端上——这个终端输出不要截图发到任何公开的issue或聊天窗口里。

启动之前，先编辑.env文件。如果同一台服务器上还要跑Nginx或Caddy做反向代理，建议把Sub2API的监听地址绑到127.0.0.1，避免8080端口直接暴露在外：BIND_HOST设置为127.0.0.1，SERVER_PORT保持8080，ADMIN_EMAIL填入管理邮箱，ADMIN_PASSWORD替换为一个强密码，TZ按实际情况设置。

有三组敏感值必须保持稳定：JWT_SECRET、TOTP_ENCRYPTION_KEY、POSTGRES_PASSWORD。后期改动可能导致已有的session失效、两步验证配置损坏，或者数据库连接报错。这些值不要随手换掉。

配置完成后用docker compose up -d启动服务，用docker compose ps检查容器状态。网关跑起来之后，还不能直接把它交给同事用——你需要先验证几件事：通过反向代理从外部能访问到登录页、API密钥能不能正常创建和删除、上游请求到底有没有按规则路由到正确的账户、用量记录是实时写入还是延迟、并发限制是否真的生效。这些都亲自点一遍，再考虑分发第一枚key。