工作负载云与附加率的下坠

在过去的五年里，出现了一种新的商业模式：企业拥有特定的计算工作负载，并完全将底层基础设施抽象出来。客户只需支付服务费用，无需关心其背后运行的是什么。而供应商则会成为运行该工作负载方面的全球最佳服务商（进而也就成为了该工作负载的云服务提供商）。

我将这类公司称为“工作负载云”企业。我认为它们代表了当下最值得关注的基础设施领域新业务。Snowflake、Vercel*以及像 fal*这样的新兴企业已经率先开辟了道路，还有更多初创公司正在跟风布局。

随着 LLM 的不断进步，价值正从代码层面向计算层面转移。如果你的产品最终只是一份包含若干行代码、且可在任何地方运行的文件，那么在编写代码的边际成本逐渐趋近于零的背景下，你就需要思考这样的产品是否还能创造价值。而如果你的产品是一种服务——比如能够比其他任何人更高效地运行特定的计算任务——那么你面前的机遇将是巨大的。

仅满足于 5%的收益

传统的基础设施软件公司负责销售代码，而客户则自行管理计算资源。云计算虽然让这一流程更加便捷，但价值分配并未改变：随着计算任务从本地环境转移到云端，AWS、Azure 和 GCP 占据了绝大部分利润，而软件供应商只能获得其中的一小部分收益。

这催生出了许多成功的企业。不过这些公司的目标只是帮助开发者在云端进行开发，而非拥有他们的计算工作负载，这也限制了它们进一步发展的可能。像 Pre-Atlas Mongo 和 Redis 这样的数据库供应商虽然提供 DBMS 软件，但数据库实际运行在 AWS 上，并由客户团队中的数据库管理员负责管理。而 GitLab 和 JFrog 这类 CI/CD 公司则负责协调用户的 CI 系统，相应的计算任务则由云服务提供商来处理。

两者之间的利润分配差距极为巨大。三大云服务提供商的年度营收高达 2000 亿美元，而那些帮助客户在云端运行的软件，其营收仅占其中的一小部分。虽然这类软件的毛利率更高，但两者的毛利润绝对额差异依然非常大。

而要守住这一优势正变得越来越困难。在代码的边际成本逐渐趋近于零的背景下，纯软件已变成了一种商品。原本占云服务费用 5-10%的基础设施软件支出比例，现在降到了 1-2%。对于那些从事基础设施业务的初创公司来说，解决办法就是不再以软件提供商的形象出现，而是要转型为云服务提供商——即拥有这些计算工作负载的所有权。

Snowflake 与 Databricks 开了路

最初的迹象来自数据领域。2014 年，Snowflake 将数据仓库中的计算与存储功能分开，并推出了一项服务，让数据团队无需管理基础设施即可实现规模扩展。对于客户而言，他们不再只是数据基础设施之上的一个层，而是成为了数据基础设施本身。这样一来，他们获得的不再是 10%的附加费，而是全部收益。

起初，他们把大部分收益都回馈给了云服务提供商。但随着他们在运行这些工作负载方面积累了更多经验，利润率提升到了 1001#70%。关键在于，计算任务在何处运行——目前仍以 AWS 为主——属于实现细节，客户无需操心，除非他们主动想了解。

Databricks*也紧随其后。该公司开始销售用于运行 Spark 作业的软件，并向客户收取两份账单：一份来自 Databricks，另一份来自其云服务提供商。在过去的三年里，他们逐渐实现了对工作负载的完全掌控。2024 年，首席执行官 Ali Ghodsi 宣布该公司将迈向“100%无服务器架构”。如今他们只发送一份账单，且无需管理任何基础设施。虽然毛利率从 85%下降到了 70%左右，但毛利润的增长速度却显著加快。

很容易将“数据与 AI 云”这种概念视为营销手段。但它让人想起克里斯·迪克森在 2014 年所描述的移动时代的全栈式转型：当时特斯拉、优步和网飞等公司选择打造端到端的产品或服务，而非采用部分功能组合的方式，从而占据了各自市场中巨大的份额。

新的商业模式正在逐步普及。

当今最优秀的基础设施公司正在采用这一策略，并将其应用到所有的生产工作负载中：

• Vercel* 先打造了前端云，接着是网页云，现在则推出了 AI 云。

• Supabase 与 Neon*（现已并入 Databricks）打造了 Postgres 云服务。

• fal*打造了生成式媒体云平台

• Baseten、Together、Modal 以及 Fireworks 都构建了 LLM 云服务。

• Railway 打造了 Python 云平台

• Browserbase*打造了浏览器云平台

• Blacksmith 打造了 CI 云平台

这些公司的增长速度更快、规模也更大，远超以往几代基础设施初创企业——值得注意的是，它们往往在那些投资者因收益过低而认为规模过小的市场中取得成功。以下就是它们的发展策略：

1. 挑选一种对计算能力和/或存储资源需求较高的关键工作负载，为开发者提供能够运行该工作负载的服务，而非软件。

2. 屏蔽复杂细节。无需配置，也无需扩展。这是一种更高级的基础架构，易于启动且便于扩展。

3. 在云服务提供商最薄弱的环节——速度与开发者体验方面与它们竞争，成为开发者部署工作负载的首选平台。随着人工智能代理开始代表开发者完成各项任务，这就要求不断提升代理体验，使其成为任务处理流程中的标准组成部分。

4. 成为该业务领域的全球顶尖服务商。通过优化技术架构并跨客户整合资源，从而实现更出色的性能表现，同时降低总拥有成本，这是任何单个客户都无法做到的。

在初期，拥有计算工作负载比交付软件更为困难。成本高昂，利润空间狭小（我和 Notable Capital 的合伙人 Glenn Solomon 曾在文中详细探讨过无服务器模式的利润状况以及其随时间的变化趋势），而且在获得初创企业和业余用户的认可之前，还无法接触到真正的企业客户。但从长远来看，这类业务比那些依赖软件使用费模式的企业更具价值——更重要的是，也更有竞争力。

核心知识产权并不在于那些像素之中。

这类业务的护城河在于其运行的系统本身，以及通过运行这些系统所获得的持续学习能力。你可以截取用户界面的截图并重新创建它，但无法让人工智能去搭建一个全球分布的边缘部署网络，然后再对整个架构进行优化。

工作负载云的核心知识产权体现在那些用户看不见却能持续受益的幕后技术中——包括分布式系统的运行、硬件优化以及可靠性工程等。Vercel 之所以备受赞誉，离不开其对开发者需求的精准把握，而这其实正是深层基础设施优化的体现；二者密不可分。

这也正是为何这类企业比纯软件公司更能抵御人工智能带来的威胁。要运营一个可靠的浏览器云服务或构建一个全球分布式的数据库，需要开展实实在在的工作，而这些工作是无法在笔记本电脑上完成的。此外，通过多年运行各类计算任务所积累的运营经验，也会成为更强大的竞争壁垒。

当企业将重点放在工作负载上时，他们也就获得了为运行该工作负载的任何用户提供服务的权利。初创公司不再需要根据企业规模或最终用户类型来区分市场，它们可以向从企业到个人开发者再到人工智能代理的各类用户销售产品。而对工作负载的极度专注迫使初创公司随着工作负载的变化而调整产品、定价及服务形式。最典型的例子就是客户群体从开发者转变为人工智能代理。

代币领域的计算云服务

人工智能代理正以前所未有的速度消耗计算资源并创造新软件，这使得从事计算业务比以往任何时候都更具价值。

处于最有利位置的“工作负载云”，就是那些位于智能体任务处理流程中的服务：要么直接为智能体提供所需的计算能力（如 Fireworks、Supabase、Browserbase*），要么成为智能体部署新工作负载的默认选择。目前，当 Claude Code 用 JavaScript 编写代码时，它会默认将其部署到 Vercel 上；而使用 Python 编写时，则会部署到 Railway 上。能够成为默认选项，无疑能带来巨大的优势。

这些公司起初规模太小，巨型云计算厂商根本不会重视它们；但后来由于在各自领域表现过于出色，巨型厂商已无法与它们有效竞争。越来越多的公司开始向更底层的环节深入——Railway、Blacksmith 以及那些推理云服务提供商都在自行建设数据中心，并已取得了不错的初步成果。拥有硬件不仅能提升利润空间，还能实现更深度的垂直整合。随着人工智能降低了定制化芯片开发的门槛，一些公司将会打造专为自身工作负载设计的硬件。

如今正是构建工作负载云的绝佳时机。其发展路径已然明确，带来的收益极为丰厚，而且那些投身于此的公司正在打造出纯软件永远无法企及的竞争优势。

Notable 的团队曾有机会与众多优秀的 workload cloud 公司合作，包括 Vercel、fal、Browserbase、Inngest 以及 Neon。如果您正在苦苦思索如何为特定的工作负载提供最佳服务，我们非常希望与您见面交流。

—

¹Public infrastructure SaaS companies (excluding cyber) do a combined ~$22.6B ARR, even when including NET, MDB, and SNOW, which are closer to workload clouds  

感谢 Aashay Sanghvi、Divyahans Gupta、Tristan Handy、Zac Smith 以及我的同事 Glenn Solomon 对这篇文章提出的反馈。