您可能未充分利用您的GPU

Ryan Donovan: 厌倦了在扩展时崩溃的数据库限制和架构？跳出“行和列”的思维定式。MongoDB由开发者构建，为开发者服务。它具备资产合规性、企业级就绪，并且精通AI。立即在 mongodb.com/build 上开始更快的构建。

[Intro Music]

Ryan Donovan: 欢迎来到 Stack Overflow 播客，一个畅谈所有软件和技术话题的地方。我是主持人 Ryan Donovan，今天我们要讨论 GPU 短缺问题，或者等一下——这其实是 GPU 利用率问题？我们今天的嘉宾，Mithril 的创始人兼 CEO Jared Quincy Davis 将为我们解答。欢迎来到节目，Jared。

Jared Quincy Davis: 嘿，谢谢，Ryan。感谢邀请。

Ryan Donovan: 节目开始，我们喜欢先了解一下我们的嘉宾。你能简单快速地给我们介绍一下你是如何进入软件和技术领域的吗？

Jared Quincy Davis: 当然，很乐意。有很多不同的起点可以说，但也许有一个时刻与许多其他 AI 研究领域的人相似——我在 2015 年深受 DeepMind 的 AlphaGo 的启发。那时，我对科技的许多不同领域都很感兴趣。我觉得机器人技术很酷，认为量子计算很有趣，认为核聚变将是一个非常重要的问题，觉得生物计算、生物信息学中的很多工作都很有趣。但 AlphaGo 让我确信应该将精力集中在 AI 上，因为很明显，尽管它只是在玩围棋游戏，但这是一种非常通用且可扩展的方法，你可以将这种“配方”应用于一系列具有相同数学特征的问题。是的，这确实鼓舞了我，我想在这方面努力。我觉得如果我们在这一领域取得很大进展，如果我们解决了阻碍该方法更广泛适用的那些问题，那么我们就可以将其用于许多下游应用。我认为这真的很重要，因为我们已经看到了 AlphaGo 这样的东西在 AlphaFold 等应用中的能力，但我想说的是，我们在世界上拥有大量的技术进步和科学进步是非常重要的。否则，世界将非常“零和”甚至“负和”，而我认为这种最广泛定义为“做事的新方法和更好方法”的技术进步，使世界变得“正和”。所以，很明显，AI 技术——这些都是让世界变得更“正和”的巨大杠杆。我们面临很多挑战性问题，我认为我们目前拥有的工具不足以应对它们。因此，我认为我们必须构建更好的工具，这就是我一直在做的事情。我认为整个社区集体已经为此努力了相当长一段时间，现在我们有了更好的工具，并且我们正在开始找到更好的使用它们的方法，这就是为什么现在是个激动人心的时代。

Ryan Donovan: 你说得对，自从 AI 兴起以来，很多人都在努力为其找到合适的工具，但很多人也在扩大他们的硬件规模。听一些人说，他们试图弄清楚“如何获得足够的 GPU 来训练并现在对涌入的所有数据进行推理？”而你告诉我这不是 GPU 来源问题，而是效率问题。你能稍微谈谈这个吗？

Jared Quincy Davis: 我认为人们对 GPU 有很多常见的误解。其中之一是：人们确实经常认为存在短缺，但可以说，并不存在短缺。有很多容量，但存在一些市场效率低下，阻碍了人们获取容量，以及一些技术挑战使得难以很好地使用它们。例如，GPU 存在大量的所谓“防御性购买”，人们必须为他们的峰值需求做预留，他们必须“以防万一”地预留，必须为确保未来的某种需求而锁定容量，而不是根据需求动态扩展并将资源释放回公共池。我认为这导致大量资源被隔离在那些不一定能很好利用它们的群体中，造成了许多闲置容量，等等。因此，我们很多工作的出发点实际上是“好吧，几乎是在提醒生态系统——试图恢复公有云的原始承诺是什么？”那就是，你不需要预留固定容量。我认为原始公有云有很多很多好处，但其中一个主要理念是容量将是弹性的。你不需要那么严格地进行容量规划。你不需要预留固定容量，无论使用与否都需要付费。你可以弹性地使用容量，如果你的工作负载是“令人尴尬的并行”，可以扩展，如果一个工作负载在一台机器上运行一千小时，但也可以在一千台机器上运行一小时，那么你可以快一千倍，以相同的成本运行得快得多。这正是云计算的革命性之处，在 IT 行业是前所未有的。这个特性在今天的人工智能领域并未得到扩展，因此人们根据他们感知到或认为将是峰值需求来购买容量。他们不使用它，每个人都被迫自己经历这些，就像在云时代之前的日子，在本地或托管设施购买资源一样。我们部分论点在于，许多“新云”实际上更像是“新托管设施”，在 AI 云生态系统中并没有真正意义上的适当云。

Ryan Donovan: 这很有趣。就像你说的，这是云计算的承诺之一。你拥有可扩展的、灵活的资源。为什么这种灵活性不适用于 GPU？

Jared Quincy Davis: 有几个原因，有些是经济上的，有些是技术上的。我认为部分原因是，我们过去几十年为使 CPU 共享真正高效而构建的一些东西，在 GPU 环境中应用得并不那么好。举一个更直观的例子，这些 GPU 工作负载的一个非常独特之处在于，它们通常是“大语言模型工作负载”。那么，“大”是什么意思呢？我认为当人们使用“大”这个术语时，他们大致引用的一个可行定义是，系统需要比单个最先进的服务器所能提供的 GPU 内存更多，来容纳模型的权重和参数。因此，当你处于“大”的范畴时，一个特点是需要多个节点、多个服务器，这就变成了一个并行计算问题来处理这些结构。在这种设置下，节点并非完全可互换的。你关心诸如连续性的问题。你会对彼此接近或具有高带宽互连的节点给予额外的权重。这意味着 GPU 分配不是一个你可以贪婪地、简单地处理的问题。它实际上是一个复杂得多的问题。你必须考虑你正在分配的工作负载的“形状”，所以它更像是俄罗斯方块，而不是出售独立单元。你必须说，“如果我分配了这个连续的块，那么我就不能再分配其他特定大小的连续块了，因为这在某种程度上挤占了容量。”这有点困难，更具挑战性。相比之下，许多更经典的大数据工作负载是独立的，是令人尴尬的并行，工作没有这种连续性和互连性要求。所以我认为，这意味着在 GPU 环境中，你必须重新思考调度方式，或许还包括定价模式，所有这些都需要重新设计以提高效率。否则，由于分配决策不佳，最终会导致大量利用不足，这是一个难以处理的问题。因此，很多公司选择不去解决那个在某种程度上比语言建模更难的问题，他们说，“实际上，我只会将大部分单租户的整个容量块分配给一个大型客户，让那个客户自己想办法处理利用率和相关的经济问题。”所以，这已经成为主要的模式——只将大块容量以批发方式长期（例如两年、三年、五年等）出售给客户。然后让客户自己想办法，把负担放在客户身上，这实际上与亚马逊倡导的云计算的原始价值主张之一背道而驰，即云将为你处理复杂性；它能让你专注于“让你的啤酒味道更好”的事情（这是常用的类比），而不必处理基础设施的复杂性。

Ryan Donovan: 如果我理解正确，CPU 工作负载的原因之一是，你只需要说“做一件事，然后把结果给我”。你大概需要这个大语言模型连续地驻留在 GPU 的内存中，对吗？

Jared Quincy Davis: 通常不仅仅是在单个 GPU 上，而是分布在多个通过互连连接的服务器和节点上。这使得一些事情变得有点困难。在 AI 的背景下思考。另外，很多标准工具也存在问题。许多现有的标准虚拟化工具不能直接应用于 GPU。你需要做一些工作才能将云中标准的虚拟机应用于 GPU，处理 GPU、网卡等，并在 GPU 和 GPU 资源上下文中获得完整的性能，等等。所以这有点不同。这导致了一些摩擦，我认为这是一个很大的原因。老实说，经过反思，我认为另一个重要原因是，我们认为云计算是理所当然的，并没有充分认识到个体参与者的决策和个别人物的愿景在多大程度上影响了其演变方式。我们觉得这是自然而然的，但事后看来，我开始意识到，回顾并阅读资料时才发现，云计算最初的一些价值主张是多么反直觉和富有争议性。当我和人们讨论在 GPU 上下文中使用弹性或按需模型时，我听到的一些论点并非 GPU 及其特性的专属。它们实际上同样适用于传统云中的 CPU 和存储的通用论点。我意识到很多人并不真正理解云计算，我相信在当时也是如此。显然，当时有很多大型托管公司，传统模式很强大，而 AWS 所做的是非常创新的。甚至在 AWS 已经进入市场几年后，谷歌和微软等其他参与者才对这个类别产生兴趣并自己进入。所以，我认为另一部分是——尽管传统云取得了成功，但人们并不真正理解它为什么成功、人们关心什么、它的革命性在哪里，并且他们没能将这些经验移植到这个新的 AI 云环境中。

Ryan Donovan: 就像你说的，云是基于特定芯片架构的虚拟化或抽象化构建的。而 GPU 是大规模并行的，我们需要在虚拟机管理程序层面进行怎样的重新思考？

Jared Quincy Davis: 这可以是一个非常深入的话题。我想说，即使在真正根本性的重新思考之前，你只需要处理表达节点的实际拓扑结构，CPU 到 GPU 以及 CPU 到网卡的亲和性拓扑。你必须能够以某种方式表达系统的拓扑结构。你必须进行内存初始化、PCI 初始化等操作。有很多事情你需要做，需要对标准技术进行一些移植和适配，以便虚拟机快速启动并交付完整性能。你知道吗，即使不做一些完全新颖的事情，只是将我们今天已经拥有的东西很好地应用到 GPU 环境中，就需要大量非平凡的工作，而许多大型云厂商甚至还没有做。许多大型云厂商只是提供裸金属，根本不支持多租户。他们只是提供单租户、长期的规模预留，对吧？所以他们决定绕过很多这样的问题，只选择一个单一的大客户——别提什么民主化了——就像 OpenAI 这样的大客户，并以长期为基础，将原始容量分配给他们，这几乎像是一种金融、私募股权式的计划。

Ryan Donovan: 每次我在云上看到 GPU，基本上都是按小时购买单个单元。这就是我们目前的模式。客户如何更好地利用他们拥有的 GPU 和 GPU 时间？

Jared Quincy Davis: 我们对此的设计方法是从头开始，专门为此构建系统——我认为首先要认识到我们今天所处的领域真正独特之处。未来几年一个非常有趣的基础设施问题围绕着正在出现的两类工作负载之间的“分叉”，这两类工作负载非常不同，需要为它们优化的目标函数也截然不同。一类工作负载是实时、低延迟领域，比如你的网络智能体、你的副驾驶、你的同步聊天会话等等。另一方面，你有异步的、对经济更敏感的工作负载类别，这在某种程度上包括你的深度研究、像 Codex 这样的后台编码智能体、你的索引工作。这并非全新问题。即使在传统搜索中，这个问题也以某种形式存在，比如谷歌有后台索引工作和实时服务，但我认为在 AI 上下文中，这个问题在某些方面变得更加极端。变化的程度、硬件选择、模型变异的数量都更大。所以在某些方面，我认为这是一个更丰富的问题。因此，问题部分变成了：“好吧，你需要什么样的架构来很好地平衡这些不同类型的工作负载，并能够可能将你想用于训练或实时推理的相同容量也高效地用于批量推理和后台工作？”如何重叠使用这些资源？我认为这些想法中很多在以前的系统工作中也有先例。我认为中心组织原则需要是——抢占性需要成为优先考虑，但要推向极致。这是我们构建系统的很大一部分。我们构建了一个系统，它将抢占性、优先级的理念推向极致，几乎使用拍卖作为一种拥塞控制形式，就像网络中的那样，基本上将工作负载映射到不同的 SKU，同时考虑到 SKU 之间的异构性。有些 SKU 位于更有利的位置，拥有更全面的合规认证、更好的网络连接（进出数据中心）、更好的互连、更近的存储等等。因此，考虑到所有这些变化，说“好吧，我应如何将工作负载路由到满足所有硬性标准的芯片上？”然后还要最大化一个满足函数，这个函数基本上是关于最大化工作负载成本（这是拥塞的函数）与我的工作负载对那种计算单元所描述的“价值”之间的“盈余”。是的，这基本上意味着每个工作负载都应该根据该工作负载进行特定定价。所以，与其拥有固定的每小时 GPU 价格，你不应该考虑为“分配”定价，而应考虑为“工作负载”定价。一个工作负载如果能提供更大的灵活性，比如说“嘿，我是可抢占的”或者“我有灵活的 SLA，我只需要在未来 24 小时内运行 4 小时”，或者说“实际上，我没有严格的连续性要求，节点是分解的或分开的也可以”，等等。工作负载给你的灵活性和自由度越多，你能赋予它的经济性就越好。这样的系统是有益的，因为对于那些需要严格启动、对延迟敏感的工作负载，你可以满足它们，并且在优先级管理的池中始终保持一定的最小容量。所以你是在用一定程度的价格不确定性来换取可用性的确定性，这样它们就可以在需要时以透明的、市场驱动的价格运行。另一方面，对于那些灵活的工作负载，比如“嘿，你可以在夜间非高峰时段运行我”，那么你可以给这些工作负载巨大的折扣，达到 10 倍、20 倍甚至更多。所以总体而言，这是一个高效得多的系统。我认为这对于能够共享资源非常重要，这样我就可以在白天将用于峰值流量的相同节点，在夜间用于离线工作负载。这些经典的想法不仅在我们自己的第一方硬件上扩展到 Baird 规模，而且也提供给用户，让他们能够在本地硬件上、在与我们合作的其他云（如 Oracle、Nebius 等）的云硬件上，甚至在客户端侧使用。

Ryan Donovan: 这听起来几乎像是你为 GPU 工作创建了一种 Lambda 无服务器模式。而且听起来，这本质上是一个调度问题。

Jared Quincy Davis: 关于 DCP 工作负载的一个有趣之处是，你确实必须至少对一些工作负载考虑存储和数据引力。这不是一个压倒性的因素，因为 GPU 受内存带宽限制严重，但它肯定是一个因素。所以，这很大程度上是一个调度问题，并不像一些规范的无服务器工作那样理想，但从广义上讲，它 100% 是一个调度问题。这就是为什么我们引用“Omni Cloud”（全能云）这个概念，其理念是，目前进行任何复杂操作的用户都是多云，甚至可能包括本地部署，比如他们会使用 AWS 或 GCP 来处理一些事情，然后为了大量 GPU 需求，他们会使用另一个 AI 原生云，比如我们或其他公司。特别是在 GPU 背景下，你希望是“全能云”，因为 GPU 成本中资本支出相对于运营支出的比例非常高，如果存在未充分利用的资源，只要能高效调度，将工作负载路由到那里就会带来巨大的经济优势。因此，你希望能够抢先地在各种云的 Spot 实例上运行你的工作负载，能够在获得经济优势的地方获得预留实例，并且拥有迁移工作的灵活性。我们发现很多人都想要这个，我们能够在这方面帮助他们正是他们看重的价值主张。

Ryan Donovan: 我们几个月前（节目播出时）采访了芯片设计公司 Arm，他们谈了很多在资源受限的环境中，将部分 GPU 工作负载转移到 CPU 上。你们考虑过这样做吗？

Jared Quincy Davis: 通常不会。对于我们很多客户和他们的工作负载来说，实际上它们是非常 GPU 密集型的，但很多 GPU 工作负载在 CPU 上运行通常效率不会很高。所以实际上几乎总是相反的情况。这些人是将 CPU 工作负载，或者过去在 CPU 超级集群上运行的工作负载，迁移到 GPU 原生架构上。从重写围绕 CPU 构建的模拟系统到使其“神经化”，比如神经 GCM 类型的东西。所以实际上几乎总是完全相反。在 CPU 上做事情的人们发现这极其低效，他们可以在 GPU 上以极短的时间和成本完成同样的事情。这只是在能效、时间效率和成本效率上要高出许多。实际上，我们在大规模应用上看到的情况恰恰相反。就我所知，并没有多少人尝试将任何严肃的工作负载运行在 CPU 上。确实存在一些卸载/加载的情况，比如当你内存非常受限时，如果你试图在本地设备或一些非常小的芯片上运行一个大模型，你可能想尝试将权重逐层加载到 GPU 中并逐层运行。这非常慢，我认为你不会为任何严肃的应用这样做。我认为你最好还是给自己弄一个好的 GPU。当然，如果你不能——理想情况是在云端——如果你真的想在本地运行，也许你会那样做，但除此之外，我们并不常见这种情况。

Ryan Donovan: 这是一个资源不那么受限的情况。那么，关于 GPU 的另一点是，我们看到更好的 GPU 在规模上扩展，但也看到一些出口受限制地区的用户有效利用了较弱的或较旧的 GPU。你认为这是更多人应该考虑的事情吗？

Jared Quincy Davis: GPU 的一个独特之处在于，它们的总拥有成本中，资本支出占主导，而不是运营支出，这意味着 GPU 相对于 CPU 来说相当节能。因此，拥有 GPU 的成本主要是购买 GPU 的成本，而很多回收成本的假设和定价假设，一方面很大程度上取决于利用率问题，但另一方面也很大程度上取决于折旧；你假设芯片的使用寿命有多长？英伟达已经加快了创新速度；现在每六个月就有新的芯片型号，这种情况在未来几年甚至更久可能都会持续。所以，我认为现在很明显，新 SKU 的推出会越来越快。这不是一个三到五年的系统，更像是三到五个月，虽然不完全是这样，但几乎是。因此，能够延长芯片的有效使用寿命非常重要。为了将资本支出分摊到更长的时期——这肯定将是一个重要的方向。所以，我认为很多公司一直在寻找更有创意的方式来使用旧的 SKU，小公司尤其如此，一些旧 SKU 的生命周期比人们可能预期的要长。比如，仍然有人在用 A100（安培架构），当然还有 H100 等等，尽管现在已经有 H200、Blackwell 并以相当大的规模部署了。所以，我认为，是的，你绝对可以使用旧芯片，特别是用于运行蒸馏模型等。我认为一个区别在于，你可能会在最新最强的芯片上进行大规模、繁重的训练；如果你生产了一系列模型，你也可能在你最大模型的最新最强芯片上进行大量批量推理，用于谷歌离线兴趣推理，以生成合成数据或生成训练数据，然后你只用这些数据来蒸馏出运行成本更低、服务成本更低的推理模型。然后，这些运行成本更低、服务成本更低的模型更小，需要的 GPU 内存更少，因此你可以在旧款、较小的 SKU 上运行它们相当长一段时间，从而延长这些旧款、较小 SKU 的生命周期。这对于实时服务是这样，甚至对于生成 RL 展开以训练下一代模型也是如此，也就是所谓“RL 循环”，在训练后阶段。我认为旧款 SKU 肯定有用途，我认为要让经济性成立，需要人们在寻找使用稍旧 SKU 的方法上发挥一些创造性，至少是这样。

Ryan Donovan: 那么，从另一方面来说，对于坐拥一堆旧款 GPU 的人来说，他们应该在什么时候开始考虑新款？新款 GPU 仅仅是功能更强，还是有实质性的质量差异？

Jared Quincy Davis: 肯定有质量差异。新款 GPU 通常在某个地方支持更低精度的格式，你可以用它来进行更高效的训练，并且具有一些你可能关心的有趣学习理论特性。这是一点。有时它们还具有旧款没有的功能，比如支持——这有点小众——但比如 TEs，测试执行环境。但我想说，主要的原因之一就是你只是想要更多的 GPU 内存，想要更强的性能。这实际上是越来越重要的原因，因为，越来越地，扩展的限制不是芯片本身，而是获取足够的数据中心电力。就像电网规模的挑战，越来越突出。当电网规模的挑战是你的瓶颈，而你想要部署东西，并且希望获得尽可能多的“每瓦特浮点运算次数”，对于许多领先的实验室来说，资金往往不是约束，电力才是。至少在目前看来，他们似乎能够获得任意多的资本。但就你可以在一个相对紧凑的位置建立和交付的连续电力而言，存在物理世界的限制。这肯定是一个挑战，因此，在这种背景下，新芯片的好处在于，它们通常一代比一代能效更高，所以你确实能获得更多的每瓦特浮点运算次数。这绝对是一个优势，会促使你以比基本的、朴素的经济论证所证明的更快速度迁移到新芯片并更换你的设备。

Ryan Donovan: 假设你有一个混合设备群。你会在这些设备上运行同一个模型吗？你会考虑专用模型吗？

Jared Quincy Davis: 是的，我认为肯定是专用模型。我在这方面有很强的偏见，因为我的很多工作都围绕着复合 AI 系统的主题，而且我也认为生态系统专用模型可能会更加民主化，会出现更多拥有创新想法但可能不具备规模或其模型的通用性来取代 ChatGPT 地位的长尾玩家，但它们对某些领域会非常非常有帮助。所以，我非常看好复合 AI 系统、小模型、模型动物园等未来趋势。是的，我认为任何严肃的公司，从 OpenAI 到任何智能体实验室，从 Databricks 到像 Cursor 和 Cognition 等编码公司，等等。我认为每个人都在使用小模型，使用集成模型，对专用模型进行微调，特别是蒸馏专用模型，尤其是在注重工具使用效率的智能体环境中。我认为你肯定需要真正的大型推理模型，但也需要那些能高效、高保真、低延迟地调用工具的稍微更高效的模型，100% 是这样。所以，是的，我认为你已经看到了，即使在所谓的“大模型推理”中，也已经存在非常混合的设备群。一种主要技术是推测性解码，它基本上是将一个大模型与一个较小的“配对”模型配对，你通过这个“起草”模型来工作。那个起草模型基本上是一种推理速度优化技术，即使对于标准模型你也可以使用，你提前运行起草模型，然后让验证模型检查它的工作，只有当它需要纠正起草模型时才需要直接自己做这项工作。所以，即使你只是在服务一个大模型，也通常会伴随一个小模型，所谓的“帮助”起草并加速其推理。所以，是的，绝对是多模型特性。

Ryan Donovan: 这几乎就像 AI 实习生，对吧？

Jared Quincy Davis: 是的。这是个有趣的类比。是的，没错。有点像模型实习生。是的。

Ryan Donovan: 得有人检查他们的工作！

[Transition Music]

Ryan Donovan: 好吧，女士们，先生们，尊敬的来宾，又到了节目的这个时间，我们要向那些来到 Stack Overflow 并通过发布答案或提出问题为自己赢得徽章的人表示赞扬。所以，今天我们赞扬的是“populous”徽章的获得者——这个人发布的答案非常好，以至于其得分超过了被采纳的答案。祝贺 Razzi Abuissa 回答了“如何在 git 中找到最后一次合并？”我敢肯定这是个热门问题，如果你是提问者之一，我们会在节目说明中附上答案。我是 Ryan Donovan。我是 Stack Overflow 播客的主持人，也是这里博客的编辑。如果你有疑问、顾虑或话题想要讨论，等等，可以给我发邮件：podcast@stackoverflow.com。如果你想在互联网上找到我，可以在 LinkedIn 上找到我。

Jared Quincy Davis: 是的，我是 Jared Quincy Davis，Mithril 的创始人和 CEO。你可以在 X 上通过 @JaredQ_ 或在 LinkedIn 上找到我，当然你也可以通过 Mithril.ai 找到我。如果你正在构建 AI 应用，需要访问基础设施、GPU 以及不受阻碍的最佳经济性以使你的工作更轻松，请联系我们。我们很乐意与你合作。

Ryan Donovan: 好的，感谢收听，我们下次再聊。