yuchen5

我们正在使用自己的硬件构建一个公共云。为此，我们筹集了资金，并且做了一些投资。而这样做的原因之一就是：为了让我们的客户能够使用 GPU。简单来说，GPU 对于加速 AI/机器学习（ML）任务很重要。可是经过时间后我们发现：GPU 固然很重要，但实际上它的应用还没达到我们想象的程度。

几年前，我们做了一个投资押下赌注，认为向互联网用户提供应用程序的公司可能需要 GPU，以此用来加速 AI 和机器学习任务。基于此，我们开发了 Fly GPU Machine。

什么是 Fly GPU Machine？

Fly Machine 其实就是在我们全球的裸金属服务器上运行的虚拟机，里面是一个 Docker/OCI 容器。而 GPU Machine 则是在 Fly Machine 的基础上，加入了一个硬件映射的 Nvidia GPU，能让它更快地执行 CUDA 计算。

跟行业其他公司一样，我们判断 AI 和机器学习会变得非常重要，甚至可能低估了它的影响力。不过，我们做的这个产品似乎没能完全符合当下的需求。也就是说，这个投资现在看起来没那么赚钱。

如果你正在使用 Fly GPU Machine，别担心，我们不会把它们取消掉。但如果你在等我们推出更强大的版本，可能得再等一段时间。

开发这个产品花了什么代价？

GPU Machine 对我们来说不是一个小项目。Fly Machine 运行在一个非常小的虚拟化管理程序上（通常是 Firecracker，但 GPU Machine 使用的是 Intel 的 Cloud Hypervisor，它是一个类似的 Rust 代码库，支持 PCI 透传）。Nvidia 的生态系统并不专门为支持这种微型虚拟机管理程序设计。

GPU 让我们的安全团队非常紧张。GPU硬件的特点是：它涉及大量的内存数据传输（甚至不是双向的：在常见配置下，GPU 之间是互相通信的），而且计算过程可以由最终用户控制，这些操作都在我们通常的安全边界之外。

为了降低风险，我们做了几个比较贵的措施。我们将 GPU 部署在专用的服务器硬件上，确保 GPU 和非 GPU 工作负载不会混合。因此，Fly Machine 被安排在 GPU Machine 上的唯一原因是它需要为 Nvidia GPU 分配 PCI BDF，而每台机器上可用的数量是有限的。所以这些服务器的利用率比普通服务器低，因此在成本效益上远不如我们的普通服务器。

我们还进行了一些大型的安全评估，找了两家公司（Atredis 和 Tetrel）来检查我们的 GPU 部署。这些评估费用不低，而且花了不少时间。

虽然安全不是我们面临的最大成本问题，但它间接带来了一些隐性成本。

我们本可以按照 Nvidia 的建议，快速部署 GPU。Nvidia 建议用标准的 K8s 集群来管理 GPU 任务。如果按照这种方式操作，我们就能直接使用 Nvidia 的驱动程序了。

另外，我们也可以使用传统的虚拟化管理程序，Nvidia 推荐用 VMware。不过，我们也可以用 QEMU（另一种虚拟化工具），它很灵活，但 Fly Machine 的核心理念就是它们能够在毫秒级别启动。如果走 Nvidia 的“快捷路径”，我们无法提供理想的开发者体验。

最终，我们花费了数月时间尝试（并最终未能成功）让 Nvidia 的主机驱动程序正常工作，以便将虚拟化的 GPU 映射到 Intel Cloud Hypervisor。有一段时间，我们通过十六进制编辑封闭源代码驱动程序，让它们误以为我们的虚拟化管理程序是 QEMU。

我不确定这一切最后是否真的有意义。市场中有一部分我们从未能真正探索的领域，因为 Nvidia 的驱动支持让我们无法有效地利用 GPU。要是没有这些问题，我们本可以为开发者提供一个非常便宜的选择，而开发者都喜欢“便宜”，但我无法证明这些客户是否真实存在。

另一方面，我们依然承诺会为 GPU 工作负载提供 Fly Machine 的开发者体验（Fly Machine DX）。除了 PCI/IOMMU 的问题，单纯让整个硬件 GPU 在 Fly Machine 上运行就已经是一个挑战。我们需要能够启动并安装正确 Nvidia 驱动程序的 Fly Machines；我们的技术栈假设客户的 OCI 容器几乎完全定义了机器的根文件系统。为了实现这一点，我们在 flyd 调度器中做了很多工程化调整。而且几乎所有人使用 GPU 时，都需要高效地获取包含模型权重的大文件，这也是个麻烦！

最后，当然，我们买了很多GPU，花了很多钱。

为什么这个项目不成功？

最大的问题就是：开发者并不需要 GPU。他们甚至不太关心 AI/机器学习（ML）模型，开发者更关心的是大型语言模型（LLM）。系统工程师可能会对如何利用 GPU 加载模型、选择哪个 GPU 更好有一些深刻见解，但软件开发者并不在乎这些。当一个开发者在做应用时想要让应用调用 LLM 时，你给他们一个 GPU 也没有用。

对于这些开发者，估计是市场上大多数人，他们根本不觉得一个新兴的公共云能够和 OpenAI、Anthropic 这种大公司竞争。它们的 API 已经够快了，开发者关注的是“每秒处理的 tokens 数量”，而不是毫秒级的延迟。

（大家应该同情我们一下）

这让我们很难过，因为我们曾经很喜欢我们找到的这个“行业空白点”。那些在亚马逊上部署应用的开发者，可能会选择其他公共云来获得 GPU 的成本效益。但接着，他们又会面临巨大的数据和模型权重问题，得花大价钱从 S3 上回传几个 GB 的数据。我们有应用服务器、GPU 和对象存储都在同一个交换机下，但推理的延迟好像根本不重要，所以市场根本不关心这些。

除此之外，如果只考虑那些真的关心 GPU 的系统工程师：他们需要的是巨大的 GPU 计算能力。像 A100 这样的整个企业级 GPU 对他们来说只是一个妥协，他们真正想要的是由 H100 组成的集群。

我们认为，可能有一部分用户是做轻量级机器学习的，他们可能会需要一些小型GPU。这正是 Nvidia MIG 的用途，将一个大 GPU 切割成多个小 GPU。但对于完全虚拟化的工作负载，MIG 并不成熟，我们无法使用它。我不确定这些客户有多少，或者我们能否在每台服务器上吸引足够多的客户。

剩下的就是 L40S 的客户。其实这一类客户还蛮多的！去年我们下调了 L40S 的价格，不是因为对 GPU 失望，而是因为它是我们库存中使用率最高的一个产品。我们对它很满意。但它只是某些应用所需的一种计算资源，不能成为我们核心业务的驱动力，它并不是我们 GPU 投资成功的标志。

说白了，问题就是，绝大多数软件开发者，想要让他们的应用能用 AI，最好的方式还是通过调用像 Claude、GPT、Replicate 和 RunPod 这些服务的 API。

我们学到了什么？

从一个非常有用的角度来看，创业公司其实就是一个学习的过程。那我们这次的学习成果怎么样呢？

首先，当我们在 2022 年走上这条路时，我们和很多公司一样，处在 AI/ML 的“火焰时代”。当时，整个行业对 AI 的关注还没有聚焦到少数几个基础性的大型语言模型上。我们原本预计会有多种主流的 AI 模型，就像 Elixir Bumblebee 中所提到的那样，大家可以像用 Ruby gems 一样，随时提取各种 AI 工作负载。

但后来 Cursor 的出现改变了这一切，现在大家都更清楚接下来的发展方向。

GPU 的尝试其实是我们 Fly.io 公司理念的一次测试：我们设计核心功能时，是为 1 万个开发者考虑，而不是 5 到 6 个。虽然这条路走得有点慢，但事实证明，这种理念是对的：GPU 工作负载对第 10001 个开发者来说，是一个小众需求。

另一个看待创业公司方式是：公司在不断做出各种赌注。我们在这方面赌了很多，但这次投资给了我们足够的资源来继续做其他事情。永远不敢下注并不是一种赢家策略。虽然我们希望这次能赢，但我认为当初做这个赌注是对的选择。

这里要记住重要的一点是——很多创业者忽略了，那就是这次投资涉及了大量的资产购买。显然，一部分成本是无法回收的，但那些没有产生收入的硬件部分，最终会被清算掉；就像我们手里的 IPv4 地址一样，我更愿意做那些有流通价值、耐用的资产背书的赌注。

最后，我不认为无论我们怎么做，GPU Fly Machines 都会成功。正因为如此，我很高兴的是，我们没有为了 GPU 产品而妥协其他部分。安全问题拖慢了进度，让我们多学了几个月，但我们在不牺牲任何隔离性措施的前提下，减少了对 GPU 的期望。而且，讽刺的是，现在别人跑的 GPU 反而让我们的隔离性故事变得更加重要。同样的事情也发生在我们 Fly Machine 的开发者体验上。

我们一开始创办公司是为了做一个针对边缘计算的 Javascript 运行时，结果我们发现，客户并不需要一个新的 Javascript 运行时，他们只是希望原生代码能够正常运行。于是我们推出了容器，开发者们很快就接受了。我们当时错了，认为 Javascript 边缘函数会流行，而现在看来，GPU 的事儿我们也错了。通常，我们找出正确答案的方式，就是先犯很多错。