这篇文字主要讲述了公司在构建公共云服务过程中，对GPU支持的探索和挑战。公司最初投入大量资金，押注于为AI/ML推理任务提供GPU支持，并创建了Fly GPU Machines。然而，尽管GPU在AI/ML领域的重要性被正确判断，但公司发现其产品可能并不适合当前市场需求，尤其是开发者更倾向于使用LLM（大型语言模型）而非直接操作GPU。
原文点击标题：
几年前，我们投入了一大笔钱，我们正在用自己的硬件搭建一个公共云，赌那些向互联网用户发布应用程序的人会需要GPU，这样他们就能做AI/ML推理任务。为了实现这个目标，我们创建了Fly GPU Machines。
Fly Machine是一个Docker/OCI容器，它在我们全球的裸机服务器群中的某个硬件虚拟化虚拟机里运行。GPU Machine就是带有硬件映射Nvidia GPU的Fly Machine。它是一台能快速执行CUDA的Fly Machine。
和行业里的其他人一样，我们对AI/ML重要性的判断是对的。如果说有什么不同，那就是我们低估了它的重要性。
但我们想出来的产品可能并不适合现在。
这看起来像是一场没有回报的赌注。
我们需要什么
对我们来说，GPU Machines不是个小项目。Fly Machines在一个非常小的虚拟机管理程序上运行（通常是Firecracker，但对GPU Machines来说，是Intel的Cloud Hypervisor，这是一个非常相似的Rust代码库，支持PCI直通）。Nvidia的生态系统不太适合支持微型VM虚拟机管理程序。
GPU让我们的安全团队感到害怕。GPU几乎是最糟糕的硬件外围设备：密集的多向直接内存传输
（甚至不是双向的：在常见配置中，GPU之间会互相通信）
通过任意的、最终用户控制的计算，所有操作都超出了我们的正常安全边界。
我们做了一些昂贵的事情来降低风险。我们把GPU装在专用服务器硬件上，这样GPU和非GPU工作负载就不会混在一起。
所以，把Fly Machine安排在GPU机器上的唯一原因是它需要Nvidia GPU的PCI BDF，而任何机器上可用的PCI BDF数量都是有限的。
但是，这些GPU服务器的利用率极低，比普通服务器更不划算。
我们资助了Atredis和Tetrel的两项大型安全评估，来评估我们的GPU部署：Matt Braun现在正在写这些评估。它们不便宜，而且很耗时。
安全并不是我们必须直接处理的最大成本，但由于某种微妙的原因，它是一个间接原因。
我们本可以按照Nvidia的建议快速交付GPU：建立一个标准的K8s集群来调度GPU作业。如果我们采用这种方式，并让我们的GPU用户共享一个Linux内核，我们就会走上Nvidia驱动程序的幸福之路。
或者，我们可以用传统的虚拟机管理程序。Nvidia建议用VMware（呵呵）。但如果我们用QEMU，他们本可以让一切正常运转。我们很喜欢QEMU，本可以为其讲一个安全故事，但Fly Machines的重点在于它们需要几毫秒才能启动。我们无法在Nvidia的快乐路径上提供我们想要的开发者体验。
相反，我们花了几个月的时间尝试（但最终失败了）让Nvidia的主机驱动程序能够将虚拟化GPU映射到Intel Cloud Hypervisor。
我们对闭源驱动程序进行了十六进制编辑，以欺骗它们认为我们的虚拟机管理程序是QEMU。
我不确定这一切最终是否真的重要。有一部分市场我们从未真正探索过，因为Nvidia的驱动程序支持使我们无法对GPU进行深度加工。如果我们没有遇到这种情况，我们本来可以为开发人员提供非常便宜的产品，而开发人员喜欢“便宜”，但我无法证明这些客户是真实的。
另一方面，我们致力于为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速度足够快，而开发者在考虑“每秒令牌数”时不会以毫秒为单位来计算性能。
这让我们感到难过，因为我们真的很喜欢我们在解决方案空间中找到的要点。
在亚马逊上发布应用程序的开发人员将外包给其他公共云，以获得经济高效的GPU访问权。但随后他们将面临尝试处理数据和模型权重、从S3回传千兆字节（花费巨大）的困境。
我们的应用服务器、GPU和对象存储都位于同一个机架顶部交换机下。但推理延迟似乎还不重要，所以市场并不关心。
除此之外，只考虑那些关心GPU而不是LLM的系统工程师：这里的硬件产品/市场契合度确实很粗糙。
从事严肃AI工作的人需要海量的GPU计算。对于他们来说，整个企业A100是一个折衷方案；他们想要一个由H100组成的SXM集群。
据我们所知，MIG为您提供了一个UUID来与主机驱动程序对话，而不是PCI设备。
我们认为，对于使用微型GPU进行轻量级ML工作的用户来说，可能存在市场。这就是Nvidia MIG所做的，将大型GPU分割成任意小的虚拟GPU。但对于完全虚拟化的工作负载，它尚未成熟；我们无法使用它。我不确定有多少这样的客户，或者我们是否能获得所需的每台服务器客户密度。
剩下的就是L40S客户了。这样的客户有很多！去年我们降低了L40S的价格，不是因为我们对GPU不满意，而是因为我们库存中只有GPU部件似乎被人们大量使用。我们对它们很满意。但它们只是某些应用程序需要的另一种计算；它们不是我们核心业务的驱动因素。它们不是GPU的回报。
实际上，所有这些都只是在说，对于大多数软件开发人员来说，“AI化”他们的应用最好是通过对Claude和GPT、Replicate和RunPod等API调用来实现。
我们学到了什么？
看待创业公司的一个非常有用的方法是，这是一场学习的竞赛。那么，我们的成绩单是什么呢？
首先，当我们在2022年踏上这条道路时，我们（和许多其他公司一样）正处于AI/ML的燃素时代。业界对AI的关注尚未集中在少数基础LLM模型上。我们预计会有多种主流模型，这是Elixir Bumblebee所期待的世界，人们可以像使用Ruby宝石一样从货架上提取不同的AI工作负载。
但Cursor发生了，而且，正如他们所说，一旦他们见到了Karl Hungus，你如何让他们留在农场呢？事情的发展方向似乎更加清晰了。
GPU是对Fly.io公司信条的一次考验：当我们考虑核心功能时，我们为10,000名开发人员设计，而不是为5-6名开发人员设计。这花了一点时间，但信条在这里胜出：第10,001名开发人员的GPU工作负载是一件小众的事情。
另一种看待创业公司的方式是将其视为一系列赌注。我们在这里投入了大量筹码。但这次锦标赛的买入费给了我们很多筹码来玩。从不进行任何形式的大赌注并不是一个获胜策略。我宁愿我们翻牌拿到坚果顺子，但我认为在这手牌上全押是正确的选择。
这里要记住的一件非常重要的事情，也是我认为很多创业者忽视的事情，就是这次赌注涉及收购资产的程度。显然，我们的一些成本是无法收回的。但那些没有产生收入的硬件部分最终将被清算；就像我们的IPv4地址组合一样，我更愿意以具有持久价值的可交易资产为后盾进行赌注。
最后，无论我们做什么，我都不认为GPU Fly Machines会成为我们的热门产品。正因为如此，我很高兴的一件事是，我们没有为了它们而牺牲产品的其余部分。安全问题拖慢了我们的进度，我们可能比原本晚了几个月才学到我们需要学习的东西，但我们正在缩减我们的GPU野心，而没有牺牲我们的任何隔离故事，具有讽刺意味的是，其他人运行的GPU让这个故事变得更加重要。我们的Fly Machine开发人员体验也是如此。
我们创办这家公司是为了构建一个用于边缘计算的Javascript运行时。我们了解到，我们的客户不想要新的Javascript运行时；他们只是希望他们的原生代码能够工作。我们交付了容器，不需要说服。我们对Javascript边缘函数的看法是错误的，我认为我们对GPU的看法也是错误的。
这通常是我们找出正确答案的方式：对很多事情都犯了错误。
总之：
这个公司在技术实现上面临了诸多挑战，包括安全风险、硬件兼容性问题和高昂的成本。尽管进行了多次尝试和调整，如使用Intel Cloud Hypervisor和进行安全评估，但最终发现GPU Machines的市场需求并不如预期。
这个公司意识到，大多数开发者更倾向于通过API调用如OpenAI和Anthropic来实现AI功能，而不是直接使用GPU。