我们对于 GPU 的看法错了 [译]
作者：Kurt Mackey
推特：@mrkurt
“我们选择了人迹罕至的道路，但后来才发现它之所以罕至，是有原因的。”
插图：Annie Ruygt
我们正在构建一家公共云服务，使用自有的硬件。我们筹集了资金来做这件事，并做出了一些赌注。其中之一就是为我们的客户提供 GPU。现在我们来汇报一下进展：GPU 不会消失，但似乎也不会成为推动我们业务的主要动力。
几年前，我们投入了不少精力，赌开发者会在向用户交付应用时需要 GPU，用于 AI/ML 推理任务。为了实现这个目标，我们打造了 Fly GPU Machines。
Fly Machine 是一个运行在我们全球裸机服务器集群某处、基于硬件虚拟化的 VM 中的 Docker/OCI 容器。如果这个容器绑定了英伟达的 GPU 设备，就成了 GPU Machine，可以进行高速 CUDA 计算。
和业内几乎所有人一样，我们对 AI/ML 的重要性判断没错，实际上我们可能还是低估了它的重要性。然而，我们推出的 GPU 产品并没有契合当下的需求。这场赌注并没有看上去那么奏效。
如果你正在使用 Fly GPU Machines，不必担心：我们不会把它们下线。 但如果你在等待我们更大规模地升级这一产品，推出某种 v2 版本，那么恐怕会失望，因为这件事短期内不会发生。
它花费了我们什么
构建 GPU Machines 对我们来说并不是一个小项目。Fly Machines 通常运行在一个小型但颇具特色的虚拟化层上（一般使用 Firecracker，但在 GPU Machines 上使用 Intel 的 Cloud Hypervisor，这是一个与 Firecracker 类似的 Rust 代码库，支持 PCI 直通）。然而，英伟达的生态系统并没有为这种微型虚拟机环境提供完整支持。
我们的安全团队对 GPU非常警惕。GPU 几乎是最复杂、最危险的硬件外设：它可以进行多向的直接内存传输（不仅是双向，有些配置下 GPU 之间还能互相通讯），并且允许用户在这个硬件上执行任意计算，这些都在我们常规的安全边界之外。
为降低风险，我们做了几项成本不菲的工作。首先，我们采用了专门的服务器硬件来部署 GPU，让 GPU 与非 GPU 的工作负载完全隔离。这样一来，只有真正需要显卡 PCI 直通的 Fly Machine 才会被调度到配备 GPU 的服务器上，而在任意机器上可用的 GPU 数量是有限的。由于这些 GPU 服务器的总体利用率比普通服务器要低得多，成本效益自然也更差。
此外，我们还投入资金，邀请 Atredis 和 Tetrel 对我们的 GPU 部署进行大规模的安全评估。Matt Braun 目前正在撰写这些评估的详细报告。这些评估既昂贵又耗时。
从直接成本来看，安全问题并不是最大的，但却在某种程度上推高了整体投入。举个例子：我们本可以用英伟达推荐的方法快速上线 GPU——搭建一个标准的 K8s 集群来调度 GPU 任务。那样的话，我们只要让所有 GPU 用户共用单一的 Linux 内核，就能走上英伟达提供的“官方驱动支持”的康庄大道。
或者，我们也可以用传统的虚拟化手段，比如英伟达建议的 VMware（虽然听起来挺搞笑），又或者用 QEMU。我们对 QEMU 并不排斥，也能勉强给它套一个安全方案，但 Fly Machines 的核心价值在于它们能够在毫秒级快速启动，而使用 QEMU 很难保持这种“开发者体验”。
为此，我们花了好几个月时间尝试（并最终失败）在 Intel Cloud Hypervisor 上让英伟达主机驱动支持虚拟 GPU。我们甚至还尝试过对闭源驱动进行十六进制修改，以欺骗它把我们的 Hypervisor 当成 QEMU。
回头看，我不确定这些弯路最终是否真的影响了结果。有一部分潜在市场我们没能触及，很大原因是英伟达的驱动支持不足，无法让我们“切片”使用 GPU。如果能支持这种按需切分的方式，我们也许能做出更便宜的 GPU 方案，而“便宜”往往对开发者很有吸引力，但我也不能百分百确定这是否真能带来足够多的客户。
另一方面，我们想要在 GPU 工作负载上提供与 Fly Machine 相同的开发者体验，这就意味着我们必须彻底解决 PCI/IOMMU 问题，让客户在一个完整的硬件 GPU 上跑他们的容器。要做到这一点，首先要保证 Fly Machines 能启动合适的英伟达驱动；我们原本的技术栈是把客户的 OCI 镜像当作机器的完整根文件系统，这就需要在 flyd 调度器里进行特殊处理。此外，大多数人使用 GPU 都需要快速拉取庞大的模型文件，这又是一大难题。
当然，我们还买了一堆 GPU，价格不菲。
它为什么不奏效
最大的问题在于：开发者并不真正想要 GPU。他们甚至不真正想要 AI/ML 模型，他们要的是 LLM。系统工程师也许会关心如何用 CUDA 加速模型、哪款 GPU 最合适，但多数软件开发者只想让自己的应用能够调用大型语言模型，并不想自己去搭建 GPU 环境。
对于这批开发者——很可能占市场的主流——一个初出茅庐的云厂商想和 OpenAI 或 Anthropic 竞争，基本不现实。后者提供的 API 已经足够快，开发者对性能的衡量方式是“每秒多少 token”，对毫秒级别的时延并不在意。
（对此我们也只能感到无奈）
这让我们很失落，因为我们对解决方案的定位还是很有自信的：在 Amazon 上构建应用的开发者，为了获取更高性价比的 GPU，常常需要外联其他云服务，但他们会遭遇数据和模型权重传输的难题——从 S3 拖回海量数据，光传输费就不低。我们这里恰好把应用服务器、GPU 和对象存储都放在同一个机架顶层交换机下面，如果推理时延有关键意义，这会非常有吸引力。可现在看来，推理的毫秒级延迟尚未成为大多数人真正关心的问题，所以市场并不买账。
再者，抛开只想用 GPU 而不是 LLM 的系统工程师不谈，硬件和需求之间也存在明显的错配。
在做深度 AI 工作的人眼里，所需的 GPU 算力大得惊人。一块整机级别的 A100 对他们而言都只是退而求其次；他们真正想要的是多个 H100 的 SXM 集群。
我们曾考虑为更小的用户群提供更“小型”的 GPU 方案，这正是英伟达 MIG 所做的事情——把一个大 GPU 切分成多个小的虚拟 GPU。然而，在完全虚拟化的环境中，这项技术并不成熟；我们无法在 Intel Cloud Hypervisor 上利用它。此外，真正对“小 GPU”感兴趣的用户数量有多少？即使有，也不见得能让我们在每台服务器上得到理想的用户密度。
至于那些需要 L40S 的客户，确实存在不少。我们去年调低了 L40S 的价格，并不是因为我们对 GPU 不看好，而是因为库存里这一型号的 GPU 用的人还比较多。对我们来说，这些 GPU 就像是一种普通的计算资源，有时一些应用会用到它们，但它们并没有成为我们业务的“爆款”。换言之，并没有验证我们的 GPU 赌注是正确的。
说到底，对于大多数软件开发者而言，“让自己的应用具备 AI 功能”最简单的办法是通过 Claude、GPT、Replicate 或 RunPod 之类的 API，而不是自己配一块 GPU。
我们学到了什么
从创业公司的角度看，这就是一场“学习竞赛”。那么我们得到了哪些收获？
首先，当我们在 2022 年开始走这条路时，AI/ML 的关注点还不像现在这样几乎都集中在大型语言模型上。我们以为将来会出现各式各样的主流模型，就像 Elixir Bumblebee 设想的那样，人们会像使用 Ruby gems 一样随取随用各种 AI 模型。
但现实是，Cursor 等等的出现，让大家的注意力都被少数几家顶尖的 LLM 模型吸引住了。未来的走向变得更为明朗。
在 Fly.io 我们有条原则：做核心特性时要面向 1 万个开发者，而不是只迎合 5~6 个特定客户。这次验证下来，依旧是这条原则胜出：面向绝大多数开发者的 GPU 工作负载还是“小众需求”。
从另一种角度看创业公司：它是一系列“赌注”的组合。我们在 GPU 这件事上投入了不少筹码，但当初之所以能这样做，也是因为我们有足够的“筹码”可用。如果一家公司从不做任何大的尝试，也很难取得真正的成功。我们当然希望能“一击即中”，但我并不后悔最初的选择。
还有一点，很少有创业者会去强调：我们在 GPU 上的投入其实也带来了“资产”。当然，其中不少投入无法回收，这是不可避免的。但硬件部分如果最终闲置了，还可以变现，就像我们囤的 IPv4 地址 一样——只要这些资产依旧保值，我就不会太担心。
归根结底，我认为无论我们怎么做，GPU Fly Machines 都不太可能成为主流爆款。就这一点而言，至少我们保持了对主产品的坚持，没有为兼容 GPU 而在安全性上妥协。安全问题的确让我们花了更多时间才看清市场，但当我们决定收缩 GPU 业务时，我们依旧守住了完整的隔离方案。讽刺的是，别家（而不是我们）运营的 GPU，反而使得我们的安全隔离故事更有说服力。还有，我们的 Fly Machine 开发者体验也没有受到负面影响。
我们在创建公司之初，曾想做一个为“边缘计算”专门打造的 JavaScript 运行时，后来发现大家并不想要新的运行时，他们更愿意直接运行自己的本地代码。于是我们就支持了容器，大家都觉得这样才顺理成章。同理，这次我们在 GPU 上的判断也不够准确，但很多时候，找到正确答案的过程就是不断地犯错、纠正，再犯错、再纠正。
我们对 GPU 的看法是错了，但这正是我们发现正确道路的方式。