自研还是购买 AI 网关：锁定你未来 18 个月的关键决策

关于 AI 网关是自研还是购买的决策，几乎从来不是基于某种决策框架做出的。它往往在第一周由一位对该问题感兴趣的工程师凭直觉决定，然后在第九个月由一位厌倦了账单的总监重新审视。这两个时刻都不是做决策的最佳时机，而且双方都没有站在未来 18 个月的关键维度上来衡量这一选择。

自研路径的诱人之处在于第一个月非常便宜。在 OpenAI 前面加一个 200 行代码的代理，写一个 switch 语句将“claude”请求路由到 Anthropic，再加上一个重试循环，团队就交付了一个看起来像网关的东西。到了第九个月，那个代理变成了 1.2 万行代码，充斥着写了一半的重试逻辑、失效机制混乱的 Prompt 缓存、没人敢相信的成本统计、在上次事故中触发方式错误的备用路由、与技术栈其他部分脱节的可观测性模式，以及在第一个企业客户提出要求后强行加入的租户限流。每一个功能都是“购买路径”在第一天就能交付的功能的拙劣复制。而当初写那 200 行代码的工程师已经离职了。

购买路径的诱人之处在于第一个月会让人感到不适。账单上每一笔调用的溢价都清晰可见，而等值的研发工时成本却从不会以这种方式呈现。“但我们想拥有它”的本能会开始作祟，尤其是在一种将拥有基础设施所有权视为美德的企业文化中。到了第九个月，该团队的研发工时都被投入到了公司赖以生存的 AI 功能上，而不是去重复建设业内每个 AI 团队都在独立重建的底层管道。

“自研还是购买”这种表述本身就掩盖了真正的问题。网关并不是一个单一的决策。它大约是捆绑在一个类别下的十几个功能决策，而正确的答案几乎总是“局部购买”配合“外科手术式的精准自研”。知道哪些部分该保留、哪些部分该委派，是区分“完成 AI 产品”的团队与“完成 AI 基础设施”的团队的关键。

自研路径的真实成本模型

内部自研网关的账单并不体现在基础设施的条目上。它消耗的是本该投入到产品开发而非网关上的工程师精力。

一个在生产规模下运行的、类似于 LiteLLM 风格的自托管代理，每月的基础设施费用大约在 200 到 500 美元，加上 100 到 400 美元的日志和指标存储数据库费用，以及 200 到 800 美元的可观测性工具费用。这只是便宜的部分。昂贵的部分是资深工程师 20% 到 30% 的精力投入，按全额薪酬计算，这在任何功能开发之前就意味着每月 3,000 到 6,000 美元的支出。一旦你不再忽略那些计算起来令人心痛的部分，生产环境的部署成本通常会落在 2,000 到 3,500 美元的总拥有成本（TCO）范围内。

这还只是稳态下的成本。自研成本是独立且前期投入巨大的。内部网关交付的每一个功能的第一个版本，其实都已经被其他团队交付过上百次了：指数退避重试、Token 计数的结构化日志、针对不稳定供应商的断路器、供应商凭证的密钥库、按租户和路由索引的成本分配表。每一个项目在第一次做时都是为期一周的项目，而在第二次做时就会变成一个为期四个月的项目——因为团队会发现第一版没法处理流式响应、没法处理工具调用、没法处理取消请求，也无法处理新模型略有不同的错误描述。

真实的 TCO 问题不是“运行这个代理要花多少钱”，而是“我们为了网关投入了多少个人·季度的精力，而这些精力本可以花在公司销售的产品上”。那些估算了这一点并对结果感到满意的团队，通常都有特定的理由：数据合规要求不能离开其 VPC、绑定到专有能力的自定义路由策略，或者在某种规模下，托管网关的溢价在绝对美元数额上变得非常有感。而那些没有进行估算的团队，通常也在支付这笔账单，只是体现在了不可见的预算科目中。

购买路径究竟包含了什么

托管网关在账单上看起来昂贵的原因是，账单上列出的项目正是自研路径往往会忽略的。如今一个面向生产的供应商提供的典型功能涵盖：横跨 100 多个供应商的统一 API、带有 PII（个人身份信息）脱敏的结构化请求和响应日志、兼容 OpenTelemetry 的追踪（traces）、带有回滚功能的 Prompt 模板版本管理、基于向量检索的语义缓存、针对供应商错误或延迟阈值的自动备份路由、用于租户限流和预算的虚拟密钥、在达到限制时直接阻断而非仅仅告警的分级支出上限、内容审核和模式（schema）强制执行的护栏，以及 SOC 2 审计员认可的审计日志。

在列表中随便挑一个功能，自研的估时可能是“一周，也许两周”。但如果是整个功能包，真实的估时则更接近于两个人·年才能达到功能对等，并且每年还要额外投入半年时间来跟进每季度都会发布破坏性变更的模型供应商。

成本拥有权的平衡点随流量规模而变化。在每月 LLM 支出低于 2,000 美元的情况下，托管平台的免费额度或调用溢价显然比运行任何自托管方案的工程师工时成本要便宜。在 2,000 美元到 10,000 美元之间，所有路径都是可行的，决策更多取决于功能覆盖面而非金额计算。当每月 LLM 支出超过 10,000 美元时，自托管在纯金钱成本上开始胜出，但这前提是团队拥有真正的 DevOps 能力，且对比的对象是按调用溢价收费的供应商，而非固定收费的供应商。

陷阱在于将这个平衡点视为问题的全部。成本只是一个维度。差异化、合规性、退出成本和运维成熟度是其他维度，且通常占据主导地位。

大多数团队都会跳过的差异化问题

在选择任何路径之前，必须先确定的框架是：哪些网关功能是每个 AI 团队都需要的大宗商品化基础设施，而哪些功能是对你特定产品起核心支撑作用的？

通用清单很长，而且并不怎么有趣。供应商抽象、退避重试、请求日志、基础可观测性、按模型和团队进行的成本追踪、语义缓存、内容护栏、虚拟密钥管理。没有哪个团队的客户会因为他们的重试逻辑更好而选择他们而非竞争对手。对于这些功能，正确的答案几乎总是“买”：供应商已经交付了这些功能，并在比你规模更大的公司生产环境中经过了磨练，而内部构建这些功能的团队只是在进行“基础设施观光”。

特定产品的清单较短，但值得为之投入。一种利用只有你的应用程序才能访问的信号的专有路由策略：这就是差异化。一种针对你所在领域的失败模式训练的自定义安全过滤器：这就是差异化。在响应返回给用户之前，根据你团队特定的质量标准运行的线上流量评测：这就是差异化。与你的自定义计费方案挂钩、财务部门必须据此对账的多租户成本分摊：这就是差异化。在这些功能上，购买通用版本要么行不通，要么会产生阻碍。

正确的架构姿态是购买通用表面，并在其上构建一个轻量级的、有主见的层来处理差异化的部分。分叉路口不在于“使用 Portkey 还是自己写”，而在于“将不产生差异化的部分交给供应商，而为产生差异化的部分保留一个 1,500 行的适配器”。做到这一点的团队能完成他们的产品。而将界限向任一方向多划一个功能的团队，要么为本可以拥有的自定义功能支付溢价，要么重新构建了一个本该租用的通用功能。

退出成本才是真正的供应商锁定问题

供应商锁定是“自建派”用来吓人的鬼怪，也是“购买派”不屑一顾的问题。双方通常都错估了锁定的实际成本。

值得认真对待的数据点：企业 AI 基础设施项目的迁移成本平均约为 315,000 美元；最近的调查显示，81% 的企业领导者担心 AI 供应商依赖，只有 6% 的人声称他们可以在不中断业务的情况下切换供应商。锁定是真实的。它也并非购买路径所独有。一个耗时两人年开发的内部网关同样是一种锁定：仅仅因为最初的架构师离职，而下一任架构师想要换个框架就要重写代理，这与从供应商那里迁移出来的成本一样高。

正确的问题是退出成本，而不是抽象的锁定。如果团队必须在 18 个月内从供应商 A 换到供应商 B，或者从托管网关换到自托管网关，答案是“一个季度的自律工作”还是“长达六个月的重写”？如果是重写，那么这种锁定就是结构性的，值得进行成本评估。如果是一个季度，那么锁定是可以接受的，而替代路径的成本可能会超过它。

保持退出成本可控的架构模式是一个稳定的内部接口，它独立于底层的连接，表达你团队的 AI 能力需求。这不只是一个只有 30 行、仅仅是用不同的导入路径重新导出供应商 SDK 的封装。它是一个有主见的能力层，你的 codebase 调用的是“总结”、“分类”、“提取结构化数据”和“带引用回答”等动词，而不是特定供应商的端点。作为产品的网关是目前实现这些动词的工具。如果产品发生变化，只需移动实现方式，而调用点不需要变动。做到这一点的团队拥有为一个季度的退出周期。而将供应商细节直接连接到应用程序代码中的团队，无论网关是自建还是购买，都面临着重写。

决策卫生：让选择透明化

这篇文章真正关注的失效模式是：网关决策很少根据其自身情况进行重新审视。自建决策是在第一周做出的，并继承了当时成立的理由。购买决策是在第九个月迫于突然增长的预算压力而做出的。这两个时刻都没有迫使实际的考量维度呈现在同一页面上。

一个可行的方法简单而乏味：一份年度自建与购买决策记录，像架构决策记录一样编写，明确列出差异化维度、成本维度、合规维度和退出成本维度。它列出了团队目前正在构建的功能和目前正在购买的功能。它指明了当前分工正确的假设条件，并承诺在下一年重新审视该记录。供应商格局在变，团队能力在变，去年还很重要的 AI 功能今年就成了通用商品。当这些参数发生变化时，这份记录能让决策保持诚实。

这种方法的另一半是关于“由谁决定”的问题。喜欢解决技术挑战的工程师不应独自决定，讨厌账单的总监也不应独自决定。决策应由工程、产品和财务共同做出，因为重要的维度属于不同的职能部门：成本属于财务，差异化属于产品，退出成本属于工程，合规属于法务。任何单一职能部门做出的网关决策，在至少一个重要维度上都会是错误的。

AI 网关是基础设施，其爆炸半径堪比数据库，差异化潜力则类似于负载均衡器。那些在没有明确核心支撑的情况下就开始构建的团队，会花一年时间重新构建本可以租用的东西。那些在没有明确战略重点的情况下就购买的团队，会发现供应商并没有提供他们真正需要的东西。做得好的团队处于两者之间，他们之所以能达到那里，是因为有人不厌其烦地将决策落实在了纸面上。