Tech
“我们对GPU的误判”：云计算中的一场豪赌
一家公司在云计算领域对GPU的投资及其面临的挑战，揭示了市场需求与技术现实之间的差距。
几年前，我们坚信互联网应用开发者需要GPU来进行AI/ML推理任务，并为此推出了Fly GPU Machines。Fly Machine 本质上是在我们的裸金属服务器上运行的Docker/OCI容器，而GPU Machine 则是在此基础上映射了硬件Nvidia GPU，可以实现快速CUDA计算。
我们和业内其他公司一样，都正确预判了AI/ML的重要性，甚至可能还低估了它。然而，我们推出的产品似乎与市场的需求并不匹配，这笔赌注看起来并没有获得预期的回报。
如果你正在使用Fly GPU Machines，请不要担心，我们不会取消这项服务。但如果你期待我们推出更强大的GPU产品，可能要等上一段时间了。
GPU之路的坎坷
GPU Machines 对我们来说并非一个小项目。Fly Machines 运行在一个非常小的hypervisor上(通常是Firecracker，但GPU Machines 使用的是Intel的Cloud Hypervisor，一个非常相似的、支持PCI直通的Rust代码库)。而Nvidia的生态系统并不支持微型虚拟机hypervisor。
GPU 让我们的安全团队感到非常担忧。GPU 几乎是最糟糕的硬件外设：它进行着密集的多方向直接内存传输(甚至不是双向的：在常见的配置中，GPU 之间会互相通信)，进行任意的、由终端用户控制的计算，并且所有这些都运行在我们正常安全边界之外。
为了降低风险，我们做了一些昂贵的措施。我们使用专用服务器硬件来部署GPU，这样GPU工作负载和非GPU工作负载就不会混合在一起。正因为如此，Fly Machine 只能被调度到GPU机器上的唯一原因是它需要一个Nvidia GPU的PCI BDF，而任何设备上的可用数量都是有限的。这些GPU服务器的利用率大大低于我们普通的服务器，因此成本效益也较低。
我们还出资请Atredis和Tetrel两家公司对我们的GPU部署进行了两次大型安全评估。这些评估价格不菲，而且耗时很长。
安全问题并非我们必须应对的最大成本，但它却间接导致了一个微妙的原因。
如果我们按照Nvidia的建议，建立一个标准的K8s集群来调度GPU作业，让我们的GPU用户共享一个单一的Linux内核，我们就能很快地推出GPU，并且走在Nvidia驱动程序的“幸福之路”上。
或者，我们可以使用传统的hypervisor。Nvidia 建议使用VMware，但如果我们使用QEMU，他们也能让事情正常运作。我们很喜欢QEMU，也可以为它构建一个安全故事，但Fly Machines 的重点是启动速度只需几毫秒。我们无法在Nvidia 的“幸福之路”上提供我们想要的开发者体验。
因此，我们花费了几个月的时间，试图(最终失败了)让Nvidia 的主机驱动程序在Intel Cloud Hypervisor 中工作，以映射虚拟化的GPU。有一次，我们甚至修改了闭源驱动程序的十六进制代码，试图欺骗它们，让它们以为我们的hypervisor是QEMU。
我不确定这一切最终是否真的重要。由于Nvidia 的驱动程序支持限制，我们始终无法探索某个细分市场，即“thin-slicing GPUs”。如果我们没有遇到这个问题，我们本可以为开发者提供一个非常便宜的产品，而开发者喜欢“便宜”，但我无法证明这些客户是真实存在的。
另一方面，我们致力于为GPU 工作负载提供Fly Machine DX。除了PCI/IOMMU 的问题之外，仅仅让整个硬件GPU 在Fly Machine 中工作就是一个巨大的挑战。我们需要能够使用正确的Nvidia 驱动程序的Fly Machines；我们的堆栈构建的前提是客户的OCI 容器几乎完全定义了Machine 的根文件系统。我们不得不在flyd 编排器中解决这个问题。而且，几乎所有人想要用GPU 做的事情都涉及到有效地获取包含模型权重的大文件。这也非常令人头疼！
当然，我们还购买了GPU。很多GPU。昂贵的GPU。
事与愿违
最大的问题是：开发者并不想要GPU。他们甚至不想要AI/ML 模型。他们想要的是LLM。系统工程师可能对如何使用CUDA 加载他们的模型，以及最好的GPU 是什么，有聪明而挑剔的看法。但软件开发者并不关心这些。当一个发布应用的软件开发者来寻找一种让他们的应用向LLM 提供提示的方法时，你不能直接给他们一个GPU。
对于这些开发者来说，他们可能占据了大部分市场，一个新兴的公共云似乎不太可能与OpenAI 和Anthropic 竞争。他们的API 速度足够快，而且以“每秒token数”来考虑性能的开发者并不会在意毫秒级的延迟。
这让我们感到难过，因为我们真的很喜欢我们在解决方案空间中找到的点。在亚马逊上发布应用的开发者会将工作外包给其他公共云，以获得具有成本效益的GPU 访问权限。但随后，他们将会在处理数据和模型权重时遇到困难，需要(以高昂的成本)从S3 往返传输千兆字节的数据。我们拥有应用服务器、GPU 和对象存储，它们都位于同一个机架顶部交换机下。但推理延迟似乎并不重要，所以市场并不关心。
除此之外，仅仅考虑到那些关心GPU 而不是LLM 的系统工程师：这里的硬件产品/市场匹配非常糟糕。
从事严肃AI 工作的人需要大量的GPU 计算。对于他们来说，一整个企业级的A100 都是一个折衷方案；他们想要的是H100 的SXM 集群。
据我们所知，MIG 为你提供了一个UUID 来与主机驱动程序对话，而不是一个PCI 设备。
我们认为，可能存在一个面向使用小型GPU 进行轻量级ML 工作的用户的市场。这就是Nvidia MIG 所做的，将一个大型GPU 切分成任意小的虚拟GPU。但是对于完全虚拟化的工作负载来说，它还没有成熟；我们无法使用它。而且我不确定有多少这样的客户，或者我们是否能获得每个服务器所需的客户密度。
剩下的是L40S 客户。有很多这样的客户！我们去年降低了L40S 的价格，并不是因为我们对GPU 感到失望，而是因为它们是我们库存中唯一人们似乎大量使用的部件。我们对它们很满意。但它们只是某些应用需要的一种计算方式；它们并不是我们核心业务的驱动力。它们并不是我们GPU 赌注的回报。
实际上，所有这些都只是在说，对于大多数软件开发者来说，“启用AI”他们的应用程序最好通过调用像Claude 和GPT、Replicate 和RunPod 这样的API 来完成。
我们学到了什么？
看待一家初创公司的一个非常有用的方法是，它是一场学习的竞赛。那么，我们的成绩单如何呢？
首先，当我们2022 年开始走这条路时，我们(像许多其他公司一样)运行在一个有点像AI/ML 燃素时代的背景下。当时，行业对AI 的关注尚未围绕少数几个基础LLM 模型展开。我们期望会有各种各样的主流模型，就像Elixir Bumblebee 所期待的世界一样，人们像使用Ruby gem 一样，从货架上获取不同的AI 工作负载。
但是Cursor 出现了，正如他们所说，一旦他们看到了Karl Hungus，你如何让他们回到农场呢？现在看来，事情的发展方向更加清晰了。
GPU 是对Fly.io 公司信条的一次检验：当我们考虑核心功能时，我们为10000 名开发者设计，而不是为5-6 名开发者设计。这花了一点时间，但信条在这里胜出：为第10001 名开发者提供的GPU 工作负载是一个小众的东西。
看待一家初创公司的另一种方式是将其视为一系列的赌注。我们在这里投入了大量的筹码。但是，参加这场比赛的买入给了我们很多可以玩的筹码。永远不进行任何形式的大赌注并不是一个成功的策略。我宁愿我们直接输掉坚果牌，但我认为参与这手牌是正确的选择。
这里需要牢记一件非常重要的事情，我认为很多初创公司的思考者都忽略了这一点，那就是这笔赌注在多大程度上涉及到收购资产。显然，我们在这里的一些成本是无法收回的。但是，那些没有产生收入的硬件部分最终会被清算；就像我们拥有的IPv4 地址组合一样，我更有信心进行有可交易资产支持的、具有持久价值的赌注。
最终，我认为无论我们做什么，GPU Fly Machines 都不会对我们产生巨大的影响。正因为如此，我非常高兴我们没有为了它们而影响其他的产品。安全问题减缓了我们的速度，导致我们可能比原本可以的要晚几个月才了解到我们需要了解的东西，但是我们正在缩减我们的GPU 野心，而没有牺牲任何隔离性，而且具有讽刺意味的是，其他人运行的GPU 使得这个故事变得更加重要。我们的Fly Machine 开发者体验也是如此。
我们创办这家公司时，是为了构建一个用于边缘计算的Javascript 运行时。我们了解到，我们的客户并不需要一个新的Javascript 运行时；他们只是希望他们的原生代码能够正常工作。我们推出了容器，无需任何说服。我们对Javascript 边缘函数的看法是错误的，我认为我们对GPU 的看法也是错误的。通常，我们都是通过对很多事情的错误认识来找到正确答案的。
本文译自 The Fly Blog，由 BALI 编辑发布。
