在生产环境中运行 AI，你真的准备好了吗？

CoreWeave 是为 AI 而生的云平台，结合下一代基础设施和智能工具，为全球最复杂的 AI 工作负载提供动力。

在 X 上与 Peter 联系。

---

Ryan Donovan：大家好，欢迎来到 Stack Overflow 播客。我是 Ryan Donovan，再次在 HumanX 现场录制。今天我们要讨论在生产环境中运行 AI 所需的一切。我的嘉宾是 CoreWeave 的 CTO 和联合创始人 Peter Salanki。欢迎参加节目，Peter。

Peter Salanki：非常感谢，很高兴能来。

RD：你对从端到端运行生产 AI 有全面的理解。特别是，有哪些人们不会想到的东西是这个堆栈的一部分？

PS：用于运行 AI 工作负载（包括训练和推理）的堆栈与传统的超大规模云架构看起来完全不同。我认为这是，你知道，我们经常被问到"为什么亚马逊不这样做呢？"——他们在过去 20 年为自己的使用场景构建云的方式与 AI 所需的方式完全不同。传统云是围绕我喜欢称之为"黑盒模式"构建的。你可以获得虚拟机或某种实例，但你并不真正知道发生了什么。一切对你来说都被很好地抽象化了。如果你运行的是易于并行化的东西（如网站或 API 服务器），这样很好。但当你运行 AI 工作负载时，你突然面临超级计算机规模的工作负载。它们都是同步的。它们都一起运行。如果任何组件出现故障，那么你的整个工作就会失败。此外，在传统云中，你有网络带宽和来自服务器的冗余上行链路，你会为了冗余而浪费一半的网络带宽。对于 AI 工作负载，如果我告诉 AI 研究人员我们要削减一半的网络带宽，但他们的工作永远不会崩溃，他们会用更粗鲁的语言告诉我滚蛋。所以这里的使用场景不一定是设计成永远不失败的。它们被设计成能够失败，然后我们找出哪里失败了、哪个组件出了问题、隔离它，然后有效地在不失去进度的情况下重新启动。为了构建这样的基础设施与构建那种为了永远不失败而建立所有这些冗余的基础设施完全不同。

RD：所以你提到了网络方面……我一直在和人们交谈，他们说网络一直是 AI 工作负载的主要瓶颈。这也是你的经验吗？

PS：是的，网络——我会说网络总是最难的部分，因为它也是高度相互联系的。

PS：它是相互联系的，如果我们看看 NVIDIA 的最新一代 Grace Blackwell 芯片，就会看到非常复杂的情况。一个服务器有一个计算托盘，上面有四个 GPU，然后从每个 GPU 出来四条网络链接。实际上是四条 200-Gig 网络链接，它们进入所谓的多平面架构，以便能够建立真正非常大的集群。这使得网络既非常大——这些集群中有数十万条电缆和连接器——也非常复杂，难以管理和操作。当你扩大计算规模、扩展浮点运算吞吐量时，芯片现在能够更快地进行计算，现在你想同步你的梯度，或者如果你进行推理，你可以并行化推理或进行分离的前缀解码，你需要快速移动所有这些数据。所以随着我们扩展计算，网络扩展的压力是持续的，而且那些缩放的方式非常不同，因为有物理方面——里面有激光，对吧？当我们超过一定距离时，我们需要使用激光，而不是电子。扩展激光很困难，它们会产生大量热量，而且在缩放网络和缩放芯片之间有完全不同的物理方面。我不是说扩展芯片很容易，只是它是不同的。所以是的，网络总是像最终的瓶颈。当我们让计算机运行得更快时，人们会说好的，我想让我的同步延迟尽可能低。

RD：有没有——有办法绕过这个问题吗？像使用更多的链路、更大的管道，或者只是获得更好的路由软件——有办法缓解这种网络延迟吗？

PS：我的意思是有一定程度上可以，对吧？就像最后有很多创意解决方案，更多就是更多，是吗？我觉得这个领域总是这样。不过有不同的网络架构，对吧？如果你看 TPU，他们使用的是所谓的 Torus 架构，这非常巧妙，直到一定的规模，之后就根本不扩展。现在行业已经落地的方案是，如果你看最新一代 NVIDIA 芯片的设计，你有不同的扩展域，我们称之为纵向扩展域，就是机架，我们有，比如说，72 个 GPU。它们在 Emulink 上有真正高效的网络通信，完全是电气的。那里没有光纤。然后我们可以保持功率使用和故障率都很低，因为我们实际上没有涉及光学器件。但由于我们不能在较大的距离上这样做，因为我们只在铜上做，当我们扩展到超过那个规模的更多芯片时，我们回到传统的光学传输和传统的网络扩展。有很多技术正在研究通过广域网进行训练，你可以连接多个吉瓦级的数据中心。有些人在生产中有效地使用它们。这是一个权衡。所以有正在开发的常规方法，有人在使用它们，但这总是一个权衡，对吧？你总是要调整你的模型，你可能会失去一些准确性，这可能是可以接受的，但作为模型开发人员或研究人员，如果我只能拥有无限的一切，这意味着我可以不受限制地工作，对吧？所以问题永远不会消失。我们只是每天都在约束中工作。

RD：我的意思是，无限的一切意味着无限的金钱，对吧？

PS：是的。在这种情况下，似乎有些人也有。

RD：很好。对于这种 AI 工作负载，你需要每个实例有很多内存，对吧？通常因为你在内存中保存了整个模型。这与传统云工作负载不同吗，还是这是一个众所周知的问题？

PS：我认为——我的意思是，现在这一切都是不同的，你与内存的交互方式在 AI 工作负载中与运行数据库（你不一定会在每次计算中访问每个内存段）的方式非常不同。在传统推理查询中，你会一直访问所有 GPU 内存，这意味着你会受到内存带宽的严重限制。在一些传统用例中，你也可能受到限制。在大多数传统用例中，大多数开发人员不会真正每天担心内存带宽。如果你是 AI 开发人员，你会每天担心它。我们从专家混合技术中获得了一些新颖的技术。我想现在已经有两年了，因为它真的开始流行，对吧？它允许你——你仍然需要内存，但你不是一次为所有请求激活所有内存。所以现在，突然之间，我们实际上可以请求——再次说，一个模型真的很大，但我们不需要用每个请求激活内存的每个字节，这允许我们有更少的内存带宽需求。有新颖的技术出现来帮助我们使这变得更有效，但内存带宽比内存大小是更大的瓶颈，同样的事情也适用——我们可以通过将更多 GPU 连接在一起来扩展内存大小，但随后你对网络施加了压力，然后我们又回到网络了。

RD：回到网络。另一个压力一直是 GPU 速度，显然。人们一直在寻找最新的 Blackwell 服务器是什么，最快的 NVIDIA 芯片是什么。但我也听说这个问题不像"更多 GPU"那样容易简化，有一个 GPU 效率方面，人们没有有效地使用他们拥有的能力。你同意吗？

PS: 好吧，这个问题有很多种回答方式，对吧？首先是，你能否扩展到无限规模的集群？这里存在一些瓶颈，很大程度上取决于网络——这就是为什么网络总是这么关键。然后这些瓶颈通常会被克服。现在我们可以相当有信心地将集群扩展到数十万个 GPU。这肯定有利有弊。我不认为每个人都应该构建 10 万个 GPU 的紧密耦合集群并运行 10 万个 GPU 的紧密耦合任务，因为那会给基础设施的可靠性造成巨大压力——包括你如何构建生命周期、故障管理，所有我早前提到的东西，对吧？这在某种程度上正是我们专业化的领域。我们可以管理数十万个节点和数百万个网络连接，这些都在等着给你制造麻烦，但我们要让它对我们的客户完美运作。这很难，但在某些使用案例中，比如大规模预训练时，这是值得的——是的，是的……更多 GPU、更多计算力会帮你更快完成。但很多其他使用案例不一定需要，你可能会过得更好……你知道，用更小的规模做东西，让自己轻松一点。然后还有利用率的问题，这有点不同。也就是说：我的研究人员或我的团队有多有效地在使用计算资源？我们看到这是一个日益重要的问题，特别是来自企业客户的反馈——比如理解一个申请 2000 个 GPU 的项目，他们真的在有效使用它们吗？他们的算法是否适配良好？他们是否在浪费一半的算力，对吧？所以我们通过可观测性和 AI 软件栈做的许多工作就是弥补这个差距——我们可以让研究人员和项目所有者看到他们的计算资源被使用得有多高效，基础设施对他们的支持有多好，而不是……你知道，钱就这样打了水漂。

RD: 对。你提到了协调，比如 100 个 GPU 的集群。

PS: 10 万个 GPU 的集群。

RD: 哦。好吧，那似乎……

PS: 100 多个你在自己地下室里就能做。

RD: [笑声] 这似乎是利用率问题的另一个方面，对吧？我想知道……在什么时点这会变成一个调度问题？

PS: 调度问题总是存在的，是的。嗯，这总是研究人员之间的一场"战争"，你懂吗？研究人员的梦想是拥有 10 万个 GPU 只为自己使用，随时可用，对吧？但那样的话它会有大量空闲时间，从成本角度说根本不可行。所以问题是你如何确保安排任务并构建调度器，让你作为研究人员，或者如果有推理使用场景需要扩展，能在需要时获得计算资源，但不会有闲置的计算，对吧？还要处理抢占和优先级。这非常复杂。那里有很多工作在进行，既有专有方案也有开源方案。Slurm 最初是任何类型高性能计算中最受欢迎的调度器。它是 90 年代的技术，源自 HPC 超级计算机。但 Kubernetes 世界有很多新的……发展，比如 Q 调度器试图更好地解决这个问题，也是以更加云原生的方式。但这绝对是一个大问题，无论规模大小，每个人都在与它搏斗，因为即便你，姑且说，有"无限的钱"，你实际上也得不到无限的 GPU，所以你仍然需要明智地使用它们。

RD: 对。作为硬件提供商，你也想充分利用它，而不是……你知道，某人陷入一个限制，比如你现在不能用 GPU，都满了。

PS: 是的，完全同意。所以，我是说，我们……我们帮助我们的客户，呃，我们参与……你知道，调度栈和可观测性栈，像我们……我们帮助他们所有需要的东西。他们的目标应该是有效地构建或运行模型、服务他们的使用案例或构建 AI 智能体。不应该是和基础设施搏斗、研究我的基础设施怎么样。所以当我们看我们开发的工具和产品时，要点就是：你们做你们擅长的，我们处理所有其他的。本质上就是这样。还有，在我们的客户之间，如果你没有在长期预留的实例合约中购买 GPU，那我们如何才能制定商业模式让你在需要时获得计算资源，同时我们也能填充其他客户，而不会对所有人都贵得要死呢？容量管理这块真的很有意思。

RD: 是的。你对构建 AI 应用的开发者有什么建议，来有效地……在你们的硬约束内工作？特别是对于直接 GPU 访问调用这样的东西。

PS: 是的，我是说，我对这个领域的开发者的总体建议是：别把事情复杂化，好吧？像这样开始：这里涉及太多复杂的层，技术发展得非常快，对吧？库、模式都在飞速变化，什么都不是真正成熟的。所以如果你把事情复杂化了——比如哦，我想要一个巨大的 GPU 集群从第一天就能跑，或者我想在还没有任何用户的时候就为我的第一个推理栈做分散服务这样的复杂东西。

PS: 就像……放松点，你知道，用现成的工具。如果你不需要构建自己的推理栈，你知道，用我们的，或者用那些擅长运行这些东西的其他人，专注于构建你的模型，专注于构建你的产品，是的，这是我最好的建议之一。从我的角度，一些客户，你知道，我们在他们的旅程中和很多客户合作。有些人带着……你知道，远大的目标来了，我想要最新的芯片，我需要很多，因为，你知道，我们要改变世界。我就想，你可能会花……你的大量时间……你知道，管理这个复杂的基础设施，你如何在这些不同的扩展域上调度，就像我们谈 Envilink 和扩展网络时讨论的。像，也许我们，你知道，让你先用简单的架构开始，这样你就能专注于构建产品、构建模型，然后从那里迭代，我们一起走这个旅程。所以，你知道，当我说有些人花太多时间把事情搞复杂时，就是这个意思。就像我们讨论微服务时的情况，对吧？经典梗。像，我开始一个项目，你知道，它是我的吐司机网络服务，然后，像，我花两个月搭了 18 个微服务。有点类似。我喜欢微服务，但我不认为一切都需要是 18 个微服务。为工作选择正确的工具然后开始。在很多情况下，正确的工具可能不是……你知道，第一天就搞一堆原始 GPU。

RD: 听起来你说的是人们在过度为应用程序做未来防护。在某个时刻他们可能会需要那种复杂性。

PS: 是的，但那样的话就及时投资。而当你达到那个规模并期望爆炸式增长时，你今天认为应用会是什么样子，一年后它看起来还是这样的几率小到你无论如何都得重写。

PS: 这就是我告诉我的开发者的——像我们行动非常快，事情变化非常快。像我们构建一些东西，哦，这个规模，你知道，会是——好的我们，你知道，我们构建这个系统，能做 10 倍的规模。然后六个月后，对吧，我们被要求构建包含 50 万个芯片的数据中心。

PS: 然后我们搭了一个能扩展到……你知道，20 万个芯片的系统。他们说，好的，我们要重写这个。这一直在发生。所以当我看我团队的软件开发时，就像，好的，我们需要构建好的东西，我们可以……你知道，我们可以审视它。它必须可靠。但预期它活不过六个月。所以预期你会重写它。如果我们最终进入一个世界，好的，它活了超过六个月，我们反正也会重写。但像，在系统中做某种计划性淘汰……允许我们专注于正确的事情而不是过度架构。然后我们六个月内又学到新东西，因为市场又向我们转向了，这个领域似乎总是这样。

RD: 这听起来几乎像一切都是原型，某种程度上，对吧？

PS: 我不知道我是否会这样说。

RD: 这是一个非常简约主义的……我喜欢简约主义的观点。

PS: 但确实会有变化，对吧？因为变化太快了。新模型不断涌现，然后我们要改变做事的方式。在推理方面，比如分解式服务，对吧？我们对推理的理解在变化，投机式解码也在变化。所以如果你构建一个非常刚性的框架，你就死定了。

PS: 我的意思是，从云提供商的角度看，我尽力构建真正好的原语，然后我们可以在这个基础上适配和扩展。这些原语必须非常扎实，对吧？真的非常扎实。但在上层，我们如何把这些整合在一起——如何在数据中心里把它们整合在一起——我需要在那方面保持灵活，也需要容易改变。

RD: 是的。就像你说的，AI 能力、软件——都在快速变化，但硬件必然要慢一些。

RD: 那么考虑到这一点，你怎么规划数据中心容量？

PS: 是的，规划时间和容量是我们现在最大的挑战之一。特别是像我们说的，架构在变化，需求也在变化。如果你回看两三年前，那很简单。我尽可能多地建造 H100，把它们接到一个集群里，就这样。对吧？大家都在跑大型预训练任务或推理，当时相对简单。要么推理跑在一台服务器上，都一样，要么在几台服务器上扩展。但本质差不多。现在就不一样了——在训练方面，你有预训练，有强化学习测试时计算，涉及不同类型的 GPU，你知道，像老一代的芯片，对解码可能真的很不错，但你不会用于预训练，但现在你可以用它参与强化学习循环。然后你还有一大堆 CPU 计算用于运行评估和运行你的智能体，对吧？所以数据中心变得更加异构，推理一侧也是如此。这意味着我们需要……再次为灵活性和可互换性而构建，在数据中心设计中有很多这样的考虑。这也很不同于传统超级计算机或超大规模数据中心的设计方式，它们的 SKU 组合是提前数年就决定的。我们会尽可能地做后期绑定。所以我们构建数据中心的时候，我们到处都铺液冷，然后在最后一刻，我们可能实际上不会在那里放液冷服务器，我们的设计允许我们最后一刻改变 SKU 组合和放什么东西。我们知道几年后，比如六年后，可能需要重建。我们也在考虑，好吧，假设每芯片的功耗会继续下降。我们怎么猜测六年内可能发生什么，并尽量不必重建整个数据中心，尽管很多东西可能——

RD: 是的，我是说——现在六年感觉像是一个永恒的规划周期，对吧？

PS: 是的，确实如此。当我们在 2020 年部署第一批 A100 GPU 时，我想，这些东西，你知道，很快就会淘汰。我不需要长期维护它们。现在，嗯，我们坐在这里，仍然在以相同容量、相同价格签署新合约，有时甚至比 2020 年还高。这相当疯狂，对吧？你可能以为一个六岁的 GPU 在这个领域应该是没用的，但由于计算需求变得如此异构，它们仍然能在最前沿的推理和智能体管道中非常有效地使用。

RD: 是的。我听说的另一个复杂因素是，由于 AI 和数据中心的爆炸式增长，供应链承受着难以置信的压力。

RD: 尤其是内存，但基本上是所有东西。

PS: 是的，情况在变化。有很多变化，对吧？每周我都在为不同的供应链问题失眠。曾经是 GPU 芯片。然后是 LAN 供电壳。现在是 NAND 和内存。

RD: 你知道，当我们离开我们的数据中心时，他们基本上清空了所有服务器。数据中心硬件有二级市场吗？

PS: 肯定有。现在对 NVMe、SSD 和 DRAM 都有一个巨大的二级市场。由于各种原因，我们直接从制造商那里采购。你知道，在 COVID 时期的那次供应链危机中，我们做了很多事，比如在 eBay 上扫荡 DRAM 芯片。但在我们的规模上，我们已经没办法那样做了，可惜。那曾经很有趣。但是，是的，市场上有很大的二级市场。我的收件箱每天收到大约五个以上的询问，有人说：我有 400 根 DRAM 芯片。我想，那对我来说有点太少了。或者，你能卖给我一些 DRAM 芯片吗？

RD: 所以，你知道，我们谈过了各种让你夜不能寐的事情。这看起来像一个打地鼠游戏，每次你解决一个问题，就冒出一个新问题，对吧？你修好网络，又是内存问题；你修好内存，又是网络问题。

PS: 这就是我生活的定义。

RD: 是的。有没有可能达到某种均衡？还是你认为产能会一直在变化，特性也一直在变化？

PS: 我不认为会。我认为，你知道，以为我们永远会有足够的计算、事情会放缓是一个谬误。我也不认为现在的疯狂程度曾经出现过——从需求和压力的角度，既要构建更多，又要推进技术。我们就像，肯定会活在一个独特的时刻。我不会说这个时刻会在一年内结束。我没看到任何迹象表明有东西在放缓——无论是推进技术还是扩大规模的需求都在放缓。完全相反。

RD: 是的，我想你早前可能提过功率限制的问题。我们听说人们现在讨论的新问题是芯片的功耗，大家都在试图弄清楚如何优化。功耗对你来说有多大的顾虑？

PS: 我的意思是，功率算是终极限制吧，但还有很多其他限制要讨论，比如内存等。功率这个事，我一年前为它失眠更多。从我们的角度看，我们已经确保了功率供应，也确保了数据中心空间，够我们在接下来...