三种“平台层”网关：Sub2API、New API、LiteLLM 各管哪一层

第 1 篇的三款工具（9Router、Magpie、CLIProxyAPI）主要服务“一个人、几个账号”。本篇三款多了一层平台：有用户、有分组、有按倍率或预算结算的台账，通常还需要数据库和 Redis。不过它们面对的问题并不相同，所以本文不做总排名，而是按层次分开讲：

• Sub2API：把 AI 订阅账号的配额分给多个用户使用，自带充值和计费；
• New API：自托管网关，核心是渠道、用户、分组、额度和成本；
• LiteLLM：Python SDK 加 AI Gateway，面向企业的多厂商 API 治理，重点是虚拟 key、预算、路由和可观测性。

证据标注沿用第 1 篇：〔文档〕〔源码〕〔推断〕。本篇没有部署观察。

1. Sub2API：订阅配额分发平台

定位与依赖。 README 把它定义为“订阅配额分发管理”平台：用户拿平台生成的 API Key 调用，平台负责鉴权、计费、负载均衡和转发〔文档〕。它强制依赖 PostgreSQL 15+ 和 Redis 7+，可以用 Docker Compose 或安装脚本（systemd）部署，首次访问 8080 端口走设置向导。如果没有预设管理员，启动时会随机生成管理员邮箱和密码，并打印到日志里。README 特意提醒不要用 [email protected] 这类容易被猜到的值。

接入层次。 上游平台包括 Anthropic、OpenAI、Gemini、Antigravity、Grok，以及 Kimi、智谱、DeepSeek、MiniMax 等。账号类型分得很细〔源码：constants.go〕：

对外端点有 /v1/messages、/v1/chat/completions、/v1/responses（含 WebSocket）、嵌入、图片、视频、语音和 Gemini v1beta。

调度与失败语义。 会话粘性用 Redis 记录“会话哈希 → 账号”，默认保留 3600 秒。粘性允许“逃逸”：账号的首字时间（TTFT）滑动平均超过 15 秒时，跳过粘性去选别的账号〔源码：config.example.yaml〕。用户和账号两个维度都有并发上限。失败循环先在同一账号上重试，再切换账号。

有一个平台层才有的概念叫“利润门”：如果选中的账号不满足分组的利润约束，就否决并重新选号，次数有上限，防止空转〔源码：failover_loop.go〕。这说明它的调度目标不只是“能不能答”，还包括“这一单划不划算”。

部署时有一个现成的坑：Nginx 默认丢弃名字里带下划线的请求头，session_id 也会被丢掉，结果是多账号环境下的粘性失效，需要加上 underscores_in_headers on;〔文档：README_CN〕。

计费口径：“精确”是相对平台价卡而言。 README 写的是“Token 级别的用量追踪和成本计算”。源码里的价格采用和 LiteLLM 一样的 per-token 格式，默认从维护者自己的价格仓库拉取，同时校验对应的 sha256 文件，本地另有回退文件〔源码：config.go〕。在价格之上，还会叠加分组倍率、峰时倍率、服务等级（priority）倍率以及图片和视频单价；分组还可以设日、周、月美元上限〔源码：group.go〕。

所以平台台账上的数字，是“上游报告的 token × 平台价卡 × 倍率”。它对平台内部结算是准确的，但它不是上游订阅的真实成本：订阅按月付费，额度窗口有自己的规则〔推断〕。内置支付支持易支付、支付宝、微信和 Stripe。

需要知道的边界。

• 账号可以绑定 TLS 指纹模板，用来模拟 Claude Code、Node.js 等客户端的握手特征〔源码：tls_fingerprint_profile.go〕。这是条款风险最集中的地方之一。
• 管理端有提示词审计和内容审核功能。平台的终端用户应当知道，运营方可以查看他们发出的内容。
• 许可方面，LICENSE 是 LGPL-3.0，贡献需要签 CLA。CLA 授予项目所有者再许可的权利，包括以专有方式许可。README 还写着“从未授权任何个人或组织基于本项目开展商业化运营”，并提示可能违反上游条款〔文档：README_CN〕。开源许可、作者声明和上游条款是三件不同的事，用于商业运营前需要专业的法律判断。

适合： 已经确认上游允许、要把订阅额度分给一小群人、需要充值和计费闭环的运营者。不适合： 只在自己电脑上用的个人开发者（PG + Redis 太重）；把合规放在第一位的组织；想要“透明透传”的人——平台可以按管理员策略过滤、拒绝或强制改写 service_tier 等字段，即使选默认的 pass，fast 也会被规范成 priority〔文档：Fast/Flex 策略〕。

2. New API：渠道、用户与额度管理

来历与许可。 New API 是在 One API（MIT）基础上二次开发的，现在采用 AGPLv3，并依第 7 条加了附加条款：修改版只要提供界面，就必须在显著位置保留 “Frontend design and development by New API contributors.” 署名和指向原项目的可见链接〔源码：NOTICE〕。AGPL 的网络条款意味着：对外提供修改过的服务时，要向用户提供对应的源码。组织政策不允许 AGPL 时，README 给了单独授权的联系邮箱。截至 2026-10-20，最新发布是 v1.0.0-rc.45（2026-10-17），发布说明称这是 v1 正式版之前最后几个 RC 之一。

存储与多节点。 主库可以是 SQLite（默认）、MySQL 或 PostgreSQL；日志可以单独放一个库，包括 ClickHouse；Redis 可选。部署多节点时，所有节点必须共用主库和 SESSION_SECRET；没有共享 Redis 时，限流计数是各节点分别算的〔文档：README.zh_CN〕。这个限制写得很直白，规划容量时要算进去。

协议与渠道。 支持 Chat、Responses、Anthropic Messages 和 Gemini，加上 Realtime 和 Responses 的 WebSocket、图片、音频、嵌入、重排，以及 JS 任务插件。四种文本协议之间的转换由独立模块 RelayKit 完成。README 自己说明：“协议特有的工具与字段可能无法完整映射”〔文档：L157〕。

渠道有 50 多种。和本系列直接相关的有两种：

• 类型 57 “ChatGPT Subscription (Codex)”：带 OAuth 刷新任务，每 10 分钟检查一次，令牌剩余有效期不足 24 小时就刷新〔源码：codex_credential_refresh_task.go〕。这个渠道的适配器在当前源码里直接拒绝 /v1/messages 和 Gemini 请求〔源码：codex/adaptor.go〕，所以 Claude Code 不能经由它直接用 ChatGPT 订阅。
• 类型 59 “Sub2API”：New API 可以把一个 Sub2API 实例当作上游，模型列表从上游 /v1/models 动态获取〔源码：channel.go〕。

重试语义。 DecideRelayRetry 的判断顺序是：严格会话亲和失败时不重试；指定了渠道时不重试；渠道类错误重试；明确不可重试的错误停止；之后按状态码白名单决定，并受全局重试次数限制〔源码：relay_error.go〕。“亲和优先于重试”是有意的取舍：为了保住缓存和会话一致性，宁可失败也不换渠道。

计费口径。 额度用内部单位记账，QuotaPerUnit = 500000，即 50 万额度对应 1 美元〔源码：constants.go〕。扣费公式由模型倍率、补全倍率、缓存倍率和分组倍率组成，还支持表达式阶梯定价和订阅套餐。它的输入是上游响应里的 usage，所以上游报多少，New API 就记多少。第 1 篇提到的 9Router 会给客户端的流式 usage 加 2000 个输入 token，它放在 New API 后面时，这部分会被原样计入用户额度〔推断〕。

访问控制与合规。 有用户、分组、细粒度权限、API Key 限制，支持 OAuth/OIDC、通行密钥和两步验证，控制台里能看审计日志。README 用了相当篇幅说明：面向公众提供服务或转售 API 时，需要完成备案、内容安全、实名、日志留存、税务和上游授权等合规义务〔文档：L59-L77〕。

适合： 团队或组织的内部网关、需要用户与额度体系的多模型服务，或者在订阅接入层（CLIProxyAPI、Sub2API、Magpie）前面加一层统一的发 key 和计费。不适合： 主要需求是“多个订阅账号的池化与配额感知路由”的人——这不是它的核心，订阅类渠道只有少数几种；还有修改界面后对外分发、但不能接受 AGPL 和署名条款的团队。

3. LiteLLM：企业 API 治理层

架构。 LiteLLM 分两层：Python SDK 负责调用各厂商、转换请求和响应、处理流式；AI Gateway（proxy）在 SDK 之上加了鉴权、限流、预算和路由。按官方架构文档描述的请求路径，鉴权时先查 Redis 缓存的 key 信息；响应返回后按“token × 价格表”算出成本，写进 x-litellm-response-cost 响应头，再通过 Redis 队列批量异步写入 PostgreSQL 的花费日志〔文档：ARCHITECTURE.md〕。网关的管理数据用 Prisma 存在 PostgreSQL 里。

对外端点有 /chat/completions、/v1/responses、/v1/messages 和 Gemini 的 generateContent，另外还有 MCP 网关和 A2A。

路由与失败语义：最工程化的一套。 默认路由策略是 simple-shuffle，可选 least-busy、usage-based-routing、latency-based-routing 和 cost-based-routing。还支持路由组、按厂商设预算、部署亲和（默认 TTL 3600 秒）和加权故障转移〔源码：router.py〕。

其中“流中途回退续写”enable_mid_stream_fallback_continuation 的边界写得很清楚：

• 默认关闭，只在异步路径上生效；
• 流在已输出纯文本之后中断时，用 assistant prefill 让备用部署接着写，而不是从头重新生成；
• 输出过工具调用、思考块、音频或图片、JSON 约束或强制 tool_choice 的流，一律不续写。

本系列其他工具大多只在“还没开始输出”时换账号；LiteLLM 把“已经输出了一部分”也做成了可配置的策略，并且明确列出哪些情况不做。

预算与 key。 虚拟 key、团队和组织都可以设 max_budget、预算周期和 TPM/RPM 限制〔源码：_types.py〕。花费按 SDK 内置的模型价格表计算，和 Sub2API、New API 一样是“按价卡估算”，不是厂商账单。好处是价格表随版本一起维护、可以覆盖；但它与厂商发票之间的差额（折扣、免费额度、缓存计价规则变化）需要另外对账〔推断〕。

订阅接入。 LiteLLM 也有 ChatGPT 订阅（设备码 OAuth）和 GitHub Copilot 两类 provider。ChatGPT 的令牌保存为单个 auth.json，目录默认 ~/.config/litellm/chatgpt，可用环境变量 CHATGPT_TOKEN_DIR 修改〔源码：authenticator.py〕。从这个设计看，它是“能接一个订阅当 provider”，而不是“多账号池 + 额度窗口感知”〔推断〕。

开源与付费的边界不只是一个目录。 LICENSE 写明 enterprise/ 目录适用商业许可，其余部分是 MIT〔源码：LICENSE〕。但 MIT 部分的代码里也有运行时门控：没有设置 LITELLM_LICENSE 时，部分功能会直接报“必须是企业用户”，例如 /spend/report 接口和 OAuth2 鉴权〔源码：spend_management_endpoints.py、oauth2_check.py〕。README 也把 SSO 列为企业版功能。

按官方的分层说明（2026-10-20 查看），开源网关已经包含虚拟 key、预算与限流、花费追踪、管理 UI 和负载均衡；SSO / SCIM、审计日志、组织与团队管理员、密钥管理器、IP 白名单、按团队分开的日志属于企业层。选型时要拿自己需要的功能逐项对照，不能只看许可证是 MIT。供应链方面，GHCR 上的镜像都用 cosign 签了名，README 给出了用固定提交里的公钥校验的命令。

适合： 统一治理多家厂商的正式 API key，需要按团队设预算、做可观测和多种路由策略的组织；也适合在 Python 应用里直接用 SDK。不适合： 主要目标是池化个人订阅、或需要面向终端用户的充值支付的场景；还有所需功能恰好在企业门控里、但预算不允许买授权的团队。

4. 三层不要混着比

三款都会在服务端留存请求元数据，有的还能审计提示词内容。作为平台的用户，要先弄清运营方能看到什么；作为运营方，要把这些写进对用户的说明里。

第 3 篇会把六款放在一起，按个人开发者、小团队、多用户服务、生产网关四种情景给出选型路径和组合方式。

精选参考资料

• Sub2API：README_CN、deploy/config.example.yaml、docs/PAYMENT_CN.md、LICENSE、CLA
• New API：README.zh_CN、NOTICE、RelayKit、v1.0.0-rc.45 发布说明、官方文档
• LiteLLM：ARCHITECTURE.md、router.py 参数说明、LICENSE、enterprise/LICENSE.md、v1.106.0 发布