自建中转的隐性成本：一个月要花多少钱、花多少时间

先算软件成本：这一项确实是零

One API、New API、LiteLLM、sub2api 都是开源项目，软件本身不花钱。这一项是真的零，不需要打折。

问题在于，它只占总成本的一小部分。

成本项一：服务器与网络

一个够用的配置：

注意服务器位置：要访问海外模型，节点必须在境外（新加坡节点国内延迟可控制在 80ms 以内）。但如果是给国内团队用，还要考虑国内访问该节点的稳定性 —— 有些线路晚高峰抖动明显。

小计：￥50–200 / 月。

成本项二：时间投入（最容易被低估的一项）

按实际做过的人反馈，把一次自建跑起来并稳定运行，时间分布在：

如果按 ￥200/小时折算（这是一个偏保守的开发者时薪），首月约 ￥1200–2600，此后每月 ￥200–800（不含故障）。

这一步的结论很关键：自建的成本主要由「后续维护」决定，而不是首次部署。

成本项三：隐性成本

升级风险

One API 有过「版本升级破坏数据库结构」的记录。New API 相对规范，但也是高频发布。每次升级前要备份数据库、验证迁移，这本身就是一项常驻工作。

安全责任

自建意味着这些责任全部在你这边：

• 密钥管理：网关里的上游 Key 一旦泄露，损失直接由你承担；
• 访问控制：谁能用、用多少、如何限额；
• 审计与留痕：出问题时要能回溯；
• 日志合规：日志里可能包含请求内容，涉及数据留存与隐私问题。

用别人的中转站，这些责任在对方；自建，全在你这边。这不是成本数字能完全表达的。

单点故障

自建网关自己挂了，全家断。而中转站通常有多渠道冗余 —— 你把它看成「依赖别人」的风险，也要看到它同时是「别人的冗余」。

要解决这一点，你得自己做高可用（多实例、健康检查、自动切换），这又是一层工作量。

什么规模以下不该自建

一条实用的判断线：

只有你一个人用 → 不要自建。 直接拿平台 Key，或者直接用现成的中转站。省下的时间远超过省下的钱。

2–3 人、用量小、能接受偶尔手动处理 → 可以自建，但用最低成本方案。 单个轻量服务器 + SQLite，不做高可用，接受偶尔手动重启。这种情况下自建的主要收益是统一管理（不用每人一套 Key）而不是省钱。

3 人以上、账记在一个人名下、或已在多个平台有 Key → 该自建。 触发条件是那句经典的痛点：「某个同事的 Key 用超了，其他人的活全停了」。这时候自建解决的不是成本问题，是治理问题。

有对账、限额、审计要求 → 必须自建或使用企业级托管。 这类需求现成中转站基本无法满足。

什么情况下自建一定划算

三种明确的情形：

1. 你已经有多个平台的免费额度（各家送的试用额度），需要一个统一出口把它们用起来 —— 这是最划算的场景，零边际成本盘活存量；
2. 团队内多人共用一个出口，需要按人分配额度；
3. 对数据流向有硬要求（不允许请求经过第三方），必须自己收口。

一个务实的中途方案

如果你处在「想统一管理但不想承担全部运维」之间，可以分两步：

第一步：用现成中转站，但在代码里把所有调用收敛到一个 base_url 变量 + 一个配置项。这样切换成本极低。

第二步：当团队规模或审批要求到了，再把那个 base_url 指向自建网关。前端代码一行不改。

这个做法的好处是：你不需要为了「将来可能要自建」而现在就付出运维成本，同时也不会把自己锁死在某一家站上。

本站的选型文章反复强调同一件事：先把自己的使用模式想清楚，再决定要不要引入一层自己维护的基础设施。