团队里用的 AI 服务越来越多——OpenAI、Deepseek、通义、豆包、Claude……每个平台一套 API、一套 Key、一套计费口径。配置越来越乱，调用越来越散，于是总有人会提出：
要不我们自己搭一个 AI Gateway 吧？自建，或者买个现成的。
这个想法非常自然。我也有过。
搭建一个 AI Gateway 一次解决所有的问题，多好的 KPI 叙事。
但是，仔细一想，把账一算，我决定放弃在公司里自建 AI Gateway。
先给结论
对绝大多数公司来说，自建或购买 AI Gateway 的 ROI 都很低。
注意，决定性的因素不是你用了多少种 AI 服务。哪怕你接了十几个平台，只要项目规模没到、团队能力没到，这笔投入依然不划算。
真正划算的前提只有一个组合：项目数足够多，且你本来就有一支扛得住 7×24 的运维/平台团队。 否则，你大概率是在用一个永久性的负债，去换一两天就能消化掉的麻烦。
下面展开说为什么。
一、AI Gateway 到底解决了什么
先得承认，AI Gateway 的确能解决公司的一些问题：
- 多平台 fallback：同一个模型要在多个供应商之间兜底。比如 Deepseek，要做 Deepseek 官方 → 火山引擎 → 阿里云百炼 的 fallback 路径，每个业务都得自己写一遍。
- API Key 轮换要重启服务：换一次 Key 就得重启应用。三个服务用到了就至少轮换三次，再乘上多环境（dev / staging / prod），数字很快就上去了。
- 请求监控各自为政：对 AI 调用的监控，每个业务都得自己实现一套。
- 接口不统一：想换模型，就得重新对接一个平台的 SDK，而不是一套接口打天下。
- 申请 Key 流程慢：业务向运维申请 Key，走流程要时间。
- 成本统计粒度粗：很多 AI 平台的成本统计很弱，做不到按 Key 或按 Project 维度归集，只能在业务代码里自己埋点。
这听起来非常的美好，也很能打动老板们。
二、它没告诉你的：引入它解决了问题，但也带来了问题
AI Gateway 解决了问题，但是同时，也带来了一些问题：
- 单点故障。这是最致命的一条。原来一个平台挂了，只影响用它的那个服务；现在所有 AI 调用都走 Gateway，Gateway 挂 = 全公司的 AI 功能一起挂。你做的事情，本质是把「分散的、互相独立的故障」，合并成了「一个相关的、全局的故障」。
- 更新和重启的代价被放大。这一点最讽刺。业务服务重启，挂一下只影响一个服务，谁都敢动手；可 Gateway 是全公司 AI 的咽喉，它的每一次升级、重启、配置变更，都牵动所有业务。于是你会越来越「不敢动它」——更新得排窗口、走变更评审、半夜操作、备好灰度和回滚预案。结果是：AI Gateway 本想解决的痛点之一就是「轮换 Key 要重启业务服务」，到头来它自己的一次重启，反而成了更让人提心吊胆的事。 你没有消灭「重启的恐惧」，只是把它从分散的小恐惧，攒成了一个集中的大恐惧。
- 模型 / 服务支持滞后。新模型、新平台出来了，Gateway 不一定第一时间支持。自建的，要自己写适配；买现成的，要等供应商排期。结果是：业务想第一时间用上新东西，反而被 Gateway 卡住了。
- 复杂业务适配不了。有些调用要用平台特有的参数、特有的流式协议、特有的多模态格式。统一抽象层总会「漏」，最后业务还是得开后门绕过 Gateway——那这层抽象的意义就打了对折。
- 接入反而变慢。本来业务直连，几行代码的事；现在要先让 Gateway 支持，再让业务接 Gateway，链路变长了。
三、算账
把上面两节放到一起算，关键在于看清两种成本的本质区别。
「配置麻烦」是一次性成本：
- fallback 逻辑，写一次就能复用；
- 轮换一次 Key + 重启 ≈ 1 小时；
- 接一个新平台 ≈ 几小时到一两天。
它的特征是：有边界、可预估、能随业务自然分摊、出问题只影响单个服务、任何一个业务开发都扛得住。
「AI Gateway」是持续性负债：
它是所有 AI 调用的必经之路，是一个关键单点。要让一个关键单点持续可靠，你要长期付出：高可用部署、监控告警、容量规划与限流、版本升级、安全加固，以及——有人 7×24 待命。
它的特征是：无边界、长期、需要专门能力、一出问题就是全局性的。
自建 vs 购买，区别也在这里：
- 买 SaaS Gateway，相当于把「7×24 运维」外包给供应商。你花的是钱，省的是人。但你换来了新的外部依赖、数据出境 / 合规风险、额外延迟，以及供应商自己的单点。更别说它是按通用场景设计的，你那些复杂的路由规则——按用户等级分流、按地域就近、按成本预算切换、按业务上下文动态选模型——它不一定支持得了，最后要么做不到，要么只能把业务反过来迁就产品。另外，连 Cloudflare 这样的行业标杆都会出事故，把自己的稳定性押注在一家公司上，风险可想而知。
- 自建 Gateway，需要自己出人「7×24 运维」，还要进行根据需求进行二次开发。
四、技术决策里一个反复出现的陷阱
把 AI Gateway 这个案例再抽象一层，你会发现它只是个引子。它背后是一个容易被人遗忘的技术决策问题：
当解决问题时，你愿意付出一次性成本，还是持续性成本？
几乎所有「要不要引入某个平台 / 中间层 / 框架」的决策，本质都是在这两者之间做选择。这个选择是非常艰难的。
拿 AI Gateway 来举例，现实中，因为一次性成本通常是可见的，让人难受的，他们还可能在公司里不断抱怨，所以问题容易被人放大，且让 AI Gateway 的方案更容易进行美好叙事。
而持续性成本是没有发生的，是需要决策者根据经验来判断的。说白了，只有踩过坑的人才懂。
作为 Leader，选择 AI Gateway，就必须承受 AI Gateway 带来的所有问题的持续成本，且不一定能真正解决问题。而反之，就必须不断接受抱怨的压力，甚至来自上级领导的压力。
而我写这篇文章，也就是为了让所有人看清问题的本质，让大家站在不一样的角度来看这个问题。
五、那到底什么时候该上？
说回来，AI Gateway 不是不能上。当下面几条同时成立时，它就从负债变成了杠杆：
- 规模足够大：项目数多、调用量大，统一治理的收益被摊开后，才盖得过它的固定成本。
- 运维能力是存量，不是增量：你本来就有平台 / SRE 团队，加一个 Gateway 是顺手的事，而不是凭空再养一个人、多排一班岗。
- 治理是硬需求：必须按 Project / Key 维度归集成本、必须审计、必须统一限流和合规——这些业务直连很难做到，此时 Gateway 的价值不可替代。
- 真要上，优先买，别自建：把 7×24 外包出去，至少你不用自己扛单点。自建是最重的选项，只有在数据合规、成本、定制化都卡死时才考虑。
判断标准其实很简单——先分清你缺的是「省事」，还是「治理」：
- 只是嫌配置烦 → 那就只是一两天的麻烦。忍一下，或者用脚本 / IaC 把它自动化，都比上网关便宜得多。
- 真的需要全局治理，而且养得起 → 再上网关。
写在最后
回到 AI Gateway：对绝大多数公司，别急着自建，先忍着，或者用脚本 / IaC 把配置自动化；真要上，等规模和团队都到位了，优先买现成的。
但比 AI Gateway 更值得记住的，是它背后那道题——
一次性成本是看得见的疼，持续性成本是看不见的债。 我们的本能，总是先去消灭那个当下就疼、还有人天天在耳边抱怨的一次性成本；却很少有人去算，为此签下的那笔债，未来要用多少个 7×24 去还。
最后，用于成语收尾：没有金钢钻，别揽瓷器活。