Sub2API：LLM 网关：多账号、限流、计费 统一搞定

2026年4月27日 · 3483 字 · 7 分钟 · Sub2API AI API网关 Claude Code Codex Gemini

封面图 前段时间我介绍过 CC Switch，它解决了多客户端配置下“怎么切更顺手”的问题。

但如果你开始长期、高频、甚至多人共用 AI，很快就会撞上一堵更厚、更疼的墙：

  • 账号乱：Claude、Gemini、Codex 散落在不同账号，Key 满天飞。
  • 并发难：用户一多，限流报错（Rate Limit）瞬间教你做人。
  • 账单黑：用量统计不清，成本像个吞金黑洞。
  • 落地烦：想做个收费小产品，计费、支付、权限还得从零手搓。

CC Switch 解决的是“客户端体验”，而今天我们要聊的 Sub2API，解决的是“后端生存”。

它不是简单的配置切换，而是一个完整的 AI API 网关：统一接入账号池、智能调度请求、自带限流计费、甚至打通了支付闭环。

这篇文章不打算只罗列功能。

我更想借着 Sub2API 讲透一个真相：在 AI 规模化落地的路上，真正拉开差距的不是“怎么接模型”，而是如何让模型稳定、可控、可计费地跑起来。

为什么说，真正复杂的不是接模型，而是管流量

调通一个 API 只需要 30 秒，但维持一个生产级应用却需要 24 小时待命。

接入模型只是“推门而入”，管理流量才是“深海潜航”。

当你从“自己玩”变成“给别人用”，你会发现代码根本解决不了这些问题：

  1. 高可用焦虑：Key 突然失效、模型半夜宕机、网络波动，你的业务是不是直接停摆？
  2. 并发教做人：用户稍微一多，官方的 Rate Limit（限流）会瞬间把你踢出局，你有没有自动重试和账号池调度？
  3. 账单黑洞：没有精细的配额管理，一个 Bug 或一次恶意刷量，就能让你一夜欠下数千美金。

真正让开发者失眠的，从来不是怎么调通 API，而是如何在模型抽风、流量激增、Key 被封的深夜，依然能让应用稳如老狗。

这就是为什么我们需要 AI 网关：它不是简单的“传声筒”，而是 AI 系统的“保险丝”和“调度站”。

1. 账号池

你只用一个账号时，事情很简单。

但只要你开始追求稳定性，或者希望多人共用，马上就会进入 账号池 模式。

这时候要考虑的就不是“能不能调用”，而是:

  • 当前该分给哪个账号
  • 哪个账号还有额度
  • 哪个账号当前压力最小
  • 哪个账号暂时不该继续打

这已经不是普通代理能处理的逻辑了。

2. 请求会话链

尤其是 Claude、Gemini 这类依赖上下文和会话状态的模型，请求不是独立散点。

如果同一个 session 一会儿走账号 A，一会儿走账号 B，结果往往就会很难看。

所以你需要的不是随机轮询，而是 带粘性的调度。

3. 成本精确

一旦你给别人提供服务，或者自己有多个业务线共用模型调用，成本核算就不能再靠估算。

你需要知道:

  • 谁用了多少
  • 用的是哪个模型
  • 每次大概花了多少钱
  • 这个用户到底赚不赚钱

否则你会发现产品在涨，账也在涨，但你根本不知道问题出在哪。

4. 计费、收费闭环

很多工具做到最后都卡在这里。

调用能通，后台也能看，但一涉及:

  • API Key 发放
  • 用户权限
  • 套餐额度
  • 在线充值
  • 费用扣减

整件事就从“技术玩具”变成了“平台工程”。

而 Sub2API 值得看的地方，恰恰是它把这几层都往前做了一大步。

一句话理解 Sub2API

如果只用一句话概括:

Sub2API = AI API 网关 + 账号调度系统 + 计费系统 + SaaS 后台。

GitHub 地址: https://github.com/Wei-Shaw/sub2api

Wei-Shaw/sub2api cover

它不是一个单纯的中转脚本。

更像是一个能让你把 Claude、GPT、Gemini、Codex 这类模型能力，真正包装成服务的平台底座。

官方给它的定位也很直白:

AI API Gateway Platform for Subscription Quota Distribution

翻成更容易理解的话就是:

把上游订阅能力，变成下游可管理、可分发、可计费的 API 服务。

Sub2API 厉害是这 6 个能力

下面这几项，基本就是它和普通“中转脚本”拉开差距的核心。

1. 多账号统一管理

Sub2API 支持的不只是普通 API Key。

它也支持 OAuth 类型账号，这对 Claude、Gemini 这类场景非常关键。

这意味着你可以把多个上游账号放进一个统一池子里管理，而不是手工切来切去。

它解决的是:

  • 一个账号扛不住怎么办
  • 多个账号怎么统一调度
  • 哪个账号出问题时怎么自动绕开

对个人开发者来说，这是省事。

对做平台的人来说，这是底层能力。

2. API Key 分发能力

这是很多人最容易忽略、但最值钱的一层。

Sub2API 不只是帮你连上上游。

它还能让你给下游用户发自己的 API Key。

这件事意味着什么？

意味着你不再只是“自己在用 AI”。

而是在搭一个 自己的 AI API 平台。

你可以基于它做:

  • 团队内部统一调用入口
  • 面向客户的 API 服务
  • 给 Agent、插件、自动化流程提供统一底座

3. Token 级精细计费

很多项目一说计费，其实只是“调用次数统计”。

但这在 AI 场景里通常不够。

因为不同模型单价不同，同一个模型输入输出成本也不同。

Sub2API 做得比较关键的一点，是它把统计精度下探到了 Token 级。

这意味着你可以更精确地做:

  • 按量收费
  • 不同模型差异化定价
  • 成本核算
  • 利润分析

这不是锦上添花。

这是你能不能把 AI 服务做成生意的关键。

4. 智能调度和粘性会话

这一点非常重要。

也是我觉得它最像“平台基础设施”而不是“工具脚本”的地方。

Sub2API 不只是把请求发出去。

它会考虑:

  • 当前该选哪个账号
  • 如何避免把某个账号直接打爆
  • 同一会话是否需要固定走同一账号

如果你做过 Claude 相关接入，就会知道这有多关键。

因为很多问题，看起来像模型不稳定，实际是调度层没处理好。

5. 限流和并发控制

AI 服务一旦开放给多人使用，最怕的就是两件事:

  • 滥用
  • 打爆上游

Sub2API 提供的不是单一限流，而是更贴近实际业务的几层控制:

  • 用户级限流
  • 账号级限流
  • Token 速率限制
  • 并发控制

这意味着你可以同时保护两端:

  • 对下，防止用户无限冲
  • 对上，降低账号被风控或异常限额的风险

6. 内置支付系统

这是它非常“产品化”的地方。

很多开源项目做到 API 管理就停了。

但 Sub2API 继续把 支付和充值闭环 也接进来了。

目前文档里提到支持的支付方式包括:

  • 支付宝
  • 微信支付
  • Stripe

这意味着如果你要做一个收费 AI 产品，它不是只帮你解决“怎么调模型”。

而是连“怎么收钱”也往前走了一大步。

说白了:

很多人缺的不是模型能力，而是把模型能力包装成商品的能力。

Sub2API 补的就是这块。

它适合什么人

如果你符合下面任意一种情况，Sub2API 的价值会一下子变高:

1. 你想做 AI 中转平台

这是最直接的使用场景。

你希望把多个模型、多个账号、多个用户统一放到一个入口里管理。

那 Sub2API 基本就是冲着这个目标设计的。

2. 你在做企业内部 AI 网关

企业场景最在意的通常不是“能不能接上”，而是:

  • 权限怎么控
  • 成本怎么管
  • 调用怎么审计
  • 谁能用什么模型

这时候统一网关比到处散落的 API Key 更像正解。

3. 你想做 AI SaaS

比如:

  • AI 工具平台
  • 思维导图产品
  • 自动化工作流产品
  • Agent 应用

这些产品一旦走向多人使用，就迟早要面对:

  • 套餐
  • 额度
  • 调度
  • 计费
  • 充值

与其自己从零造轮子，不如先研究一套已经把大框架搭起来的方案。

4. 你在做 Agent 底座

如果你最近在研究 OpenClaw、MCP、Skills、Agent Workflow 这类方向，那更应该对这一层保持敏感。

因为 Agent 上层拼的是体验。

而底层真正决定可持续性的，往往是:

  • 模型接入是否统一
  • 成本是否可控
  • 请求是否稳定
  • 会话是否可靠

Agent 之所以越来越像“系统工程”，很大一部分原因就是网关层开始变重了。

一套更容易理解的架构图

如果你现在正在做自己的产品，可以把它理解成下面这个结构:

前端产品 / Web / App / Agent
            ↓
       统一 API 入口
            ↓
        Sub2API
（网关 / 调度 / 计费 / 限流）
            ↓
账号池 / 额度 / 会话 / 支付
            ↓
Claude / GPT / Gemini / Codex

这张图想表达的重点很简单:

Sub2API 不只是转发请求，而是把模型调用前后的账号、额度、调度、限流、计费都接起来。

技术栈

从公开信息看，Sub2API 的技术栈并不花哨，但很像是冲着“长期跑服务”去选的:

  • 后端: Go + Gin
  • 前端: Vue 3 + Tailwind
  • 数据库: PostgreSQL
  • 缓存: Redis

这套组合的好处就是:

  • 性能预期稳定
  • 工程生态成熟
  • 部署方式清晰
  • 二次开发门槛不算离谱

如果你本身就是做后端、平台、SaaS 或自动化系统的，这类技术选型会比较容易接住。

部署简单

按项目文档，Sub2API 提供了几种比较友好的部署方式:

1. 一键安装脚本

适合想快速跑起来的人。

curl -sSL https://raw.githubusercontent.com/Wei-Shaw/sub2api/main/deploy/install.sh | sudo bash

2. Docker Compose

更适合生产环境或标准化部署。

docker compose up -d

3. 源码构建

适合需要深度定制、二开或研究实现细节的人。

如果你只是想先验证方案，一键脚本和 Docker 都足够友好。

有一个坑

如果你前面用了 Nginx 反代，有一个配置不要漏:

underscores_in_headers on;

因为 Nginx 默认会丢掉带下划线的请求头。

而这件事会直接影响到 session 粘性路由，最终表现出来可能就是:

  • 会话失效
  • 多账号调度异常
  • 你以为是模型有问题，实际是反代层吞了头信息

这类坑很典型。

一灯短评

我越来越强烈地觉得:

未来 AI 产品的竞争，表面上是在比模型，实际上会越来越多地比基础设施。

谁能把多模型接入、账号调度、成本控制、计费闭环、并发治理这几层做好，谁才更有机会把产品稳定做大。

这也是为什么我觉得，Sub2API 值得单独研究。

它不是在帮你多接一个模型，而是在帮你补上 AI 产品最容易被忽略的“平台底座”。

如果你现在还只是停留在“怎么把 Claude 或 Codex 接上”的阶段，那这篇文章最想提醒你的其实只有一句话:

真正难的，从来不是接模型。

真正难的，是把模型能力做成一套能长期稳定运行的系统。

这，才是 AI 应用接下来最值得补的一课。


如果你也在持续研究 AI 工具、Agent、MCP、开源项目拆解，可以关注我。