AI 网关工具横评 · 第 3 / 3 篇（展开目录）

三篇横向比较 9Router、Magpie、CLIProxyAPI、Sub2API、New API、LiteLLM 六款开源 AI 网关：前两篇按“订阅接入”和“平台层”分别深读，第三篇给出对比表、选择路径与组合方式。事实截至 2026-10-20，以官方文档与源码为证据。

  1. 把订阅接进 Agent：9Router、Magpie、CLIProxyAPI 源码深读
  2. 三种“平台层”网关：Sub2API、New API、LiteLLM 各管哪一层
  3. 六款 AI 网关怎么选：从个人开发到生产网关的选择路径与组合

约 12 分钟 · 截至 2026-10-20 · 汇总前两篇的文档与源码分析，组合方案中标〔推断〕的部分未实测

读完你能： 用一张表找到六款工具在关键维度上的位置；按“个人开发者 / 小团队 / 多用户服务 / 生产网关”找到起点；知道两层网关串联时，令牌、用量和重试各会出什么问题。

前两篇分别拆开了订阅接入型的三款和平台层的三款。本篇不再重复每款的细节，只讲横向判断。表中的事实都能在前两篇找到出处；选型建议和组合方式属于〔推断〕，用之前请在自己的环境里验证。

1. 六款的共同点

  1. 对外都讲 OpenAI 兼容协议，多数还讲 Anthropic Messages 和 Gemini。 但“能转换”不等于“无损”。New API 的 README 直接写了协议特有字段可能无法完整映射；9Router 以 OpenAI 格式为中转；CLIProxyAPI 按源和目标逐对写转换器。工具调用、推理块、缓存控制这类字段，切换前要用自己的 Agent 实际跑一遍。
  2. 都把“切到下一个账号或渠道”当作可用性的主要手段。 区别在于：哪些错误触发切换；切换前会不会先冷却账号；响应开始输出之后还能不能切换。
  3. “成本”大多是按价格表估算的。 结算以适用的上游账单或订阅权益规则为准。网关台账记录的是“网关看到的 usage × 网关的价格”，在其中任何一环加了缓冲、倍率或缺失值，数字就会偏离。
  4. 都在快速迭代。 六个仓库在 2026-10-15 到 10-19 之间都有发布或提交，选型时要固定版本，升级前看发布说明。

2. 关键差异总表

表中“—”表示该项不是这款工具的设计重点，或本文没有核实，不表示“不支持”。

维度 9Router Magpie CLIProxyAPI Sub2API New API LiteLLM
层次 个人订阅路由 Agent 配置 + 订阅网关 无头订阅代理 订阅配额分发平台 渠道 / 用户 / 额度平台 企业 API 治理
语言 JS（Next.js） Go Go Go + Vue Go + React Python
必需存储 本地 SQLite 本地 JSON 文件 本地 JSON（可换 PG / Git / S3） PostgreSQL + Redis SQLite 起步，可换 MySQL / PG 网关管理需要 PostgreSQL
订阅 OAuth 主业 主业（读 Agent 原有登录 + 插件） 主业 主业 少数（Codex 渠道） 少数（ChatGPT、Copilot）
账号选择 fill-first / 轮询 / combo 回退 按重置时间等 5 种 + 条件粘性 轮询 / 加权 / fill-first Redis 粘性 + 逃逸 + 利润门 优先级 / 权重 + 亲和 5 种路由策略 + 亲和
输出开始后续写 — 不切换 — — — 可选，仅纯文本
内置用量 估算成本，客户端流式 usage +2000 逐请求 JSONL，可导出 OTLP 不内置，60 秒内存队列 按价卡 × 倍率的台账 额度单位 × 倍率 价格表算出的花费 + 响应头
终端用户与支付 — 仅网关 key 限额 — 内置支付 用户 / 分组 / 套餐 虚拟 key / 团队预算
会改写请求 较多（省 token、提示词替换） 可选中间件 以协议转换为主 策略改写 service_tier 等 参数覆盖 / 模型映射 按 provider 转换
许可 MIT MIT MIT LGPL-3.0 + CLA AGPL-3.0 + 署名条款 MIT + 企业目录 + 运行时门控

这张表里最影响决策的有三行：

  • 必需存储：决定运维重量。不想维护数据库，就先排除 Sub2API，以及要用管理功能的 LiteLLM。
  • 订阅 OAuth：决定能不能接个人订阅。New API 和 LiteLLM 只覆盖少数订阅 provider，订阅池化不是它们的设计目标。
  • 许可：决定能不能改了再对外分发。AGPL 的署名附加条款和 LiteLLM 的运行时门控，都必须在选型阶段弄清楚，而不是上线以后。

3. 四种情景的选择路径

个人开发者：一台电脑，几个 Agent，几份订阅

起点是 Magpie 或 9Router。

  • 同时用多个 Agent，又不想手改每个 Agent 的配置文件：选 Magpie。它会直接修改各 Agent 的配置，并且尽量复用各 Agent 原有的登录，不另存一份凭据。
  • 想要按“订阅 → 便宜 → 免费”逐级回退的组合，以及省 token 功能：选 9Router。但要接受它会改写部分请求，用量数字也要按它的口径理解。
  • 喜欢纯配置、无界面：选 CLIProxyAPI。记得把 host 改成 127.0.0.1。

这个情景用不上第 2 篇的平台：PostgreSQL 加 Redis 的维护成本，换来的是一个人用不到的用户体系。

小团队：几个人共享一个网关

起点是服务器上的 Magpie 或 CLIProxyAPI，每个成员发一个独立的 key。

  • Magpie 的网关 key 可以绑定可用的模型和账号，并设置多窗口限额，适合“按人限额、按池隔离”。
  • CLIProxyAPI 的客户端 key 只做鉴权；要按人统计，还得自己部署外部采集。

当团队需要正式的用户、分组和额度管理时，在前面加一层 New API，把订阅代理当作它的一个渠道〔推断〕。

不管选哪种，都要先确认上游条款允许多人共用。小团队共享个人订阅，正是条款最常明确禁止的用法。

多用户服务：对外发 key、收费

如果上游是订阅账号，Sub2API 的设计最贴近这个需求：账号类型细、粘性和利润门、内置支付都有。但它自己的 README 已经写明了条款风险和“无商业授权”声明。

如果上游是正式 API key，New API 更合适：有用户和额度体系、多数据库可选，README 里还列了对外服务所需的合规义务。

上线前建议至少做三件事：

  • 按自己的服务形态（内部使用、对公众提供、转售等）和所在地区，核实适用的监管要求。备案、内容安全、实名、日志留存等是否适用、如何适用，因情况而异，本文不给法律结论；New API 的 README 列了它认为相关的事项，可作为核对起点；
  • 告诉用户运营方能看到哪些内容；
  • 做好台账与上游账单的差额核对。

生产网关：组织内多团队、多厂商

起点是 LiteLLM，或者以 New API 作为控制台。

LiteLLM 的路由策略、部署亲和、按厂商设预算，以及有明确边界的“流中途续写”，都是为正式 API 设计的。需要 SSO 和高级报表时，先对照企业功能列表评估授权费用。

订阅接入型工具不建议出现在这个情景的主路径上。订阅额度和条款都不是为组织级生产流量设计的〔推断〕。

4. 常见组合，以及组合的代价

组合 适合 主要代价〔推断〕
Agent → Magpie / 9Router → 订阅与 API key 个人 网关挂了所有 Agent 一起停；需要开机自启和健康检查
New API → CLIProxyAPI → 订阅 小团队要用户体系 两层都会重试；用量要在两层分别核对
New API → Sub2API（渠道类型 59）→ 订阅 已有 New API，要加订阅池 两套倍率叠加，台账口径更难解释
LiteLLM → 正式 API key 生产 企业功能需要授权；需要 PostgreSQL

串联最容易出的三类问题如下。

令牌：明确由谁刷新。 对于采用 refresh token 轮换、又没有跨进程协调的集成，两个进程各自刷新同一份凭据，可能让另一方手里的旧令牌失效。各提供方对旧令牌的宽限期和并发规则不同，实际后果要看具体提供方。Magpie 文档说导入 ChatGPT 账号时会先刷新，导入后来源工具需要重新登录，这也是令牌轮换的结果。本站的策略是单写入者：迁移时先停掉旧系统的刷新，再交给新系统；旁路的采集器、面板一律只读，用权限受限的 key 访问，不碰原始令牌。本站从旧网关迁到 Magpie 时就是这样做的〔部署观察〕。

用量：分清三层数字。 第一层是上游账单或权益记录，结算以适用的上游规则为准。网关也可能保存上游返回的真实 credits，但只覆盖经过它的请求、上游返回了的字段。第二层是网关台账：“上游报的 usage”经网关处理后的结果。第三层是估算成本：台账 × 价格表。串联时偏差会累积：9Router 给客户端的流式 usage 加了 2000 个输入 token，New API 再按这个 usage 扣用户额度，两层的误差就叠在一起了。上游没有返回的值（比如失败请求的积分）保留为“未知”，不要填 0，也不要按余额变化倒推。

重试与粘性：分清各层职责，控制总预算。 CLIProxyAPI 默认额外重试 3 轮，New API 也有全局重试次数。两层都开时，一次失败可能被放大成好几次上游请求，在限流场景下反而会加速冷却〔推断〕。粘性也一样：前一层在多个渠道之间轮换，后一层的会话粘性就失去了意义。会话相关的请求头还可能被反向代理丢掉，比如 Nginx 默认丢弃带下划线的头，Sub2API 文档专门提醒过。一种常见分工是：离上游最近的一层负责账号级的重试和粘性；前面的层负责渠道级的故障转移，并原样透传会话标识。同时给整条链路定一个总重试预算（例如前层少重试或只在渠道整体不可用时切换），避免两层的次数相乘〔推断〕。

5. 维护模式也是选型维度

六个项目的维护方式差别很大，这直接决定了你能不能修、能不能跟上版本。

项目 维护方式 对使用者的影响
Magpie 代码由 agent 编写、评审、合并；不接受外部 PR；发版极快 上游不接外部 PR，但用户仍可维护 fork 或本地补丁；发版快，宜固定版本，并保留旧二进制或镜像以便回滚
9Router 个人维护为主；GitHub Releases 页停在旧版本，版本记录在 CHANGELOG 和标签里 不能只看 Releases 页判断活跃度；升级前读 CHANGELOG
CLIProxyAPI 接受 PR；周边面板和统计工具都是独立仓库 生态灵活，但用量、面板等组件要分别评估各自的维护状态
Sub2API 接受贡献，但要签 CLA 贡献的代码可能被再许可，包括专有许可
New API 处在 v1 正式版前的 RC 阶段 跨大版本升级前先备份并读迁移说明
LiteLLM 公司维护，稳定版与 RC 分开发布，镜像有 cosign 签名 有校验链条可以利用；部分能力需要商业授权

迁移成本主要看三件事：

  • 凭据能不能导出导入。 Magpie 能导入 CLIProxyAPI、Sub2API 等工具导出的 ChatGPT 账号文件，导入时会先刷新令牌，来源工具之后需要重新登录。
  • 客户端要不要改。 Magpie 允许给网关 key 设置自定义值，迁移时客户端可以继续使用原来的 key。
  • 历史用量能不能带走。 各家台账的格式互不兼容，通常只能各自导出 CSV 或 JSON 存档，新旧数字不宜直接拼接。

6. 落地与迁移清单

  1. 固定版本：用镜像 digest 或标签固定版本。CLIProxyAPI 的管理面板默认自动从 GitHub 更新，可以关掉；Magpie 一天可能发好几次版。
  2. 检查暴露面：CLIProxyAPI 默认监听所有网卡；Magpie 在容器里要求外部请求带网关 key；9Router 默认要求登录和 API key。上线前用另一台机器实际测一次，看能不能未经鉴权访问。
  3. 管理面和数据面分开：Magpie 的面板用 serve --web，在同一进程里另开监听地址，不要再并行起一个 magpie web。CLIProxyAPI 的管理 API 没有密钥就整体关闭。面板只放在私网里。
  4. 用量链路先打通再切流量：CLIProxyAPI 需要常驻的外部采集；其他工具要先确认台账字段（缓存读写 token、积分）和上游口径对得上。
  5. 许可在选型时定：改了界面要对外分发的，先确认 AGPL 和署名条款；要用 LiteLLM 门控功能的，先评估授权。
  6. 条款按提供方确认：本系列所有的“支持”，都只表示技术上能接入。

精选参考资料