每个开发团队迟早要面对的AI技术栈问题

总有一天，你的工程团队会问出这样一个问题——事后回想会觉得理所当然，但现在却越来越多人开始认真思考：为什么我们要把这么多开发基础设施交给外部服务商？

这不是在唱反调，也不是要大家完全抛弃托管AI服务。而是说，当AI编程工具越来越深入日常工作的时候，越来越多团队开始从实际基础设施的角度来考虑这件事了。

最近我看到一个挺有意思的案例，正好说明了这个问题的重要性。Parity的一个小团队决定做个"20%时间实验"——给几个工程师充分自由，去探索自托管AI模型能不能真正用来做开发工作。本来只想试试看，结果一跑就是好几个星期，25个工程师一起跑出了将近130亿tokens的量。

这些数字挺让人意外的。光是前三天，就处理了超过30亿tokens，GPU计算成本大约是每百万tokens 0.1美元。整整一个月下来，总花费大概1200美元。这不算少，但也没很多人想象中"自托管AI"那么烧钱。

真正的成本和你想的不一样

最让我印象深刻的一点是：GPU计算成本虽然确实存在，但其实是比较小的那部分。更大的投入是工程时间——搭建基础设施、做性能基准测试、学习怎么稳定运营这个系统。

在做基础设施决策时，这其实是个反复出现的模式。直接成本看得见、容易做预算。但隐性成本是你团队在建立新系统运营知识的过程中花费的时间和精力。Parity团队的赌注是：这种知识会产生复利效应——现在投入建设基础设施、基准测试和运营手册，就是在为未来的工作负载积累能力。

这种思路对搞过云托管、容器编排或者托管数据库的人来说应该很熟悉。你要权衡的是运营复杂度vs获得的控制权、成本节约和战略灵活性。有时候托管方案胜出，有时候自己掌控整个技术栈更合适。

"简单架构"实际上是什么样的

Parity那篇文章里让我很喜欢的一点，是他们把架构描述得非常清楚。他们并没有搞什么定制的、专门构建的推理集群。他们的技术栈其实相当简洁：

在开发者工具和模型之间加了一个通用接口层（他们用的是LiteLLM）。接口层后面，vLLM负责模型服务。GPU算力是从云服务商租来的。整个设计刻意保持简单——让工程师能继续用自己熟悉的编码环境和客户端，同时团队还能灵活选择哪个模型、哪个供应商在背后响应请求。

很多团队在否定自托管方案时都忽略了这个关键点：你不需要在控制权和便利性之间二选一。一个设计合理的抽象层，意味着你的开发者还是用他们一直用的工具。区别在于，你来决定哪个模型来响应、什么数据被记录、成本怎么分摊。

打个比方，就像DNS管理。开发者不需要搞懂DNS传播的具体细节才能正常使用域名。他们面对的是一个简洁的界面。但在界面背后，有人做了关于域名服务器、TTL和冗余的深思熟虑的选择。同样的原则在这里也适用。

数据告诉我们的真相

Parity实验的运营数据才是对想尝试类似方案的团队真正有用的部分。他们追踪了上下文长度、请求并发数、吞吐量和队列时间——这些都是基于真实开发工作流程的数据。

有几个数字特别值得注意：

99%的请求使用的上下文不到50万tokens。超过一半的时间里，系统其实只处理一个并发请求。峰值时，预填充处理速度达到每秒16.8万tokens，首token平均响应时间约3.34秒。

请求形态的分布说明了一个重要的事实：大多数时候，你的推理基础设施处理的是相对较小、单线程的开发者请求。那些考验系统极限的并行请求场景其实是例外，不是常态。

这对容量规划有实际意义。你不需要一直为峰值并发负载准备资源。一个设计良好的系统可以动态扩展，同时保持基础成本在合理范围内。

核心问题：控制权还是便利性

我觉得这类实验真正有价值的地方在于：它们在教整个行业，"AI基础设施独立性"在实际中究竟是什么样子。

我们正处在一个有趣的过渡期。AI编程工具正在成为团队构建软件的必需品，但整个行业还在摸索怎么负责任地运行这些工作负载。数据留存、成本可预测性、模型可用性、供应商锁定——这些问题都是开发团队开始认真对待的真实顾虑。

Parity的实验说明，自托管推理比很多人以为的更容易实现。你不需要一个大型工程组织或者定制硬件才能起步。你需要的是明确的需求、合理的架构，以及愿意投入建立运营知识的意愿。

这个权衡是否值得，完全取决于你的具体情况。但关键是——它确实是个可行的选项，这一点值得了解——尤其是当AI工具越来越深入地集成到我们交付软件的方式中。

在云托管格局中的位置

从云基础设施的角度看，这个趋势有一些有意思的启示。能够租用GPU算力而不是直接购买，大幅降低了入门门槛。你获得了自托管基础设施的运营灵活性，却不需要承担购买硬件的资本支出。

这和我们在云计算其他领域看到的演进是一样的。托管服务抽象掉了复杂性，但也抽象掉了控制权。云基础设施上的自托管方案给了你更多控制权，却不需要你自己构建和维护物理硬件。

对于像Vibe Hosting这样的平台上的团队来说，问题变成了：你希望怎么使用AI能力？是偏好完全托管AI服务的简单性？还是更看重能切换模型、控制成本、搞清楚底层到底发生了什么的能力？

对大多数团队来说，诚实的答案可能是混合方案——部分工作负载用托管服务，其他方面建立自托管能力。关键是理解在每个方向上你在放弃什么。

最后

软件开发用自托管AI已经不是理论探索或者大企业专属的事情了。工具已经成熟，成本已经下降，运营模式也越来越清晰。

不管你是决定自己跑推理基础设施，还是继续用托管服务商，理解这些权衡正在成为工程领导者的必备知识。现在愿意花时间了解这些的团队，未来在AI工具继续演进的背景下，会在基础设施决策上处于更有利的位置。

AI在开发领域的未来，不仅仅是关于你用哪个模型——而是关于谁在掌控运行这些模型的底层技术栈。这个问题，值得每个认真对待开发基础设施的团队认真思考。

你的团队在AI基础设施方面采取了什么方式？是完全依赖托管服务、正在探索自托管方案，还是在两者之间找平衡？关于AI基础设施独立性的讨论才刚刚开始。