Presentation: Chaos Engineering GPU Clusters

混沌工程GPU集群 - InfoQ

InfoQ 首页 演示 混沌工程GPU集群

DevOps

框架之下：为什么代理上下文是一个基础设施问题（网络研讨会 8月27日）

混沌工程GPU集群

Like

新下拉阅读列表

• 阅读列表

查看演示

• 垂直

• 水平

• 全屏

速度：

• 1x

• 1.25x

• 1.5x

• 2x

50:22

总结

Bryan Oliver探讨人工智能基础设施的前沿领域：大规模GPU集群的混沌工程。他分享了工程领导者如何应对复杂拓扑结构、RDMA等网络协议以及NUMA错位问题。了解七种实用的故障注入策略，以最大化数百万美元硬件的效率并构建强大的可观测性循环。

个人简介

Bryan Oliver是一名设计和构建复杂分布式系统的工程师。过去三年来，他专注于Thoughtworks的平台、GPU基础设施和云原生领域。他受邀在全球各地的会议上发表演讲。他还是Manning出版社的多部著作作者，包括《Effective Platform Engineering》，以及O'Reilly出版社的《Designing Cloud Native Delivery Systems》。

关于会议

QCon AI是一场由实践者主导的会议，专注于安全扩展这些工作负载所需的工程学科。它直接提供访问同行组织在生产环境中使用的架构蓝图和故障指标。

INFOQ 事件

• 2026年7月16日，东部时间下午1点 工程的智能时代：如何规范、构建、测试和运营AI驱动系统 演讲者：Juveria Kanodia - Harness工程高级总监

• 2026年8月6日，东部时间下午1点 构建用于高风险事件响应的AI代理评估 演讲者：Brianne Bujnowski - Datadog AI高级产品市场经理，Benjamin Barton - Datadog高级软件工程师

• 2026年8月27日，东部时间下午1点 框架之下：为什么代理上下文是一个基础设施问题 演讲者：Boyd Stowe - Tacnode创始解决方案架构师

演讲稿

Bryan Oliver：我在Thoughtworks Radar上工作。这是一份我们每年发布两次的出版物。基本上，这是一份我们分享对全球技术和Thoughtworks客户的技术观点和见解的出版物。我正在撰写第二本书，因为我并不享受空闲时间，与O'Reilly合作。实际上，我们刚刚将标题改为“Designing Intelligent Delivery Systems”，因为我们正在回应AI部署中出现的许多新的调度模式。我经常做演讲，偶尔也会为Kubernetes和其他开源项目做出贡献。你可能会猜测这意味着我可能有资格做这个演讲。对这个问题的回答是否定的，我没有。这个领域极其复杂。我演讲的主题每天都在变化。我认为我们中没有人在这个规模上拥有超过一年的经验。我认为没有人真的拥有，但我们会试一下。

什么是真正的大规模GPU？

GPU Concepts Primer: Hardware

要理解本次讨论，你需要掌握一些术语。第一个是XID错误。这些本质上只是GPU故障代码，类似于编程世界中的内核恐慌。ECC是错误校正码，这是一种能检测并纠正位翻转的内存保护机制。了解这一点很重要，但即使不了解也没关系。流式多处理器是GPU内部的计算单元。NVLink是NVIDIA的高速GPU互联技术。我们稍后会详细讨论。热节流是指GPU在过热时会自动降频，如果你经常在桌面端运行高难度游戏，应该对此有所了解。事实上，单个H100 GPU上就有大约90个热传感器，任何情况都可能触发节流。DCGM是数据中心GPU管理器的缩写，这是NVIDIA开发的两个程序组成的套件。其中一个名为dcgmi，另一个是DCGM-Exporter。前者可以实际控制和操作GPU，我们稍后会讨论；后者主要用于监控，主要在Kubernetes生态中使用。

GPU Clusters

让我们谈谈GPU集群，因为这就是我们在这里的原因，许多节点上都配备了GPU。如果回到2004年，当时石溪大学视觉计算中心的一群研究人员想要模拟化学和生物攻击如何在曼哈顿的城市区域（特别是时代广场）扩散。他们试图通过理解不同攻击模式下的空气动力学来帮助城市建立防护和防御模型。他们使用了计算流体力学的一种方法，我甚至无法向你解释这个方法的含义或工作原理，但他们采用了晶格玻尔兹曼方法，并开发了相应的模拟程序来实现这一目标。在进行这项研究时，他们发现了一个有趣的现象。由于他们属于视觉计算中心，数据中心内配备了大约30个GPU节点。

这些节点都是单GPU配置，节点之间通过1Gbps的链路连接。他们注意到，当在GPU集群上运行模型时，相比标准集群，性能提升了约100倍。具体来说，该模拟程序每步计算一个晶格玻尔兹曼方法仅需0.31秒，这比在CPU集群上执行速度快4.6倍。这标志着GPU集群的开端。这篇论文非常著名，它实际上赢得了超级计算会议的"时间考验奖"，这是这些论文能获得的最负盛名的奖项之一。一个有趣的事实是，这项发现比CUDA早了两年，因此他们不得不使用图形着色器来表达计算，或者说，他们必须通过让GPU假装在渲染像素的方式来"欺骗"GPU进行科学计算。

我认为这个发现非常有趣。回到与这一历史背景相关的内容，上世纪60年代和70年代我们有高性能计算。2004年我们讨论了那篇论文。2000年代，CUDA在2006年推出，GPU集群开始迅速发展，主要得益于这篇论文。2020年代我们有了大语言模型。2024年我们提出了在Kubernetes上实现更好AI的呼吁。这就是时间线的简略版本。去年早些时候在KubeCon巴黎的贡献者峰会上，Tim Hockin登台发言时说："我们已经成功创建了一个用于微服务和API的通用工程平台，现在我们需要解决AI问题，否则我们的项目将被取代并被淘汰。"这基本上是向所有贡献者发出的行动号召，而这次会议确实是一个重要转折点，因为Kubernetes此前一直专注于支持AI，但从那时起，AI成为了该项目的主要关注点。

造成这种转变的原因有很多，但最主要的原因是目前广泛使用的训练平台和技术被称为Slurm，它从时间线早期阶段就已经存在。Slurm的管理非常复杂，缺乏Kubernetes今天操作员期望的许多弹性功能。它也无法帮助我们处理今天看到的大量遥测数据和混沌问题。最重要的是，我们希望利用Kubernetes来应对复杂性的增长，这就是今天讨论的主题。

复杂性来源于几个方面。其中之一是多租户架构，比如你正在使用ChatGPT，它运行在某个GPU上。你发出的所有请求都会进入一个多租户环境。虽然存在性能优先级的问题，但增加复杂性的最大因素是网络增强，特别是GPU之间的网络连接。我们将探讨这些内容，帮助你开始理解如何进行混沌测试并观察其表现。简单来说，我们讨论的是通过不同协议和技术直接将GPU连接在一起。第一个技术称为RDMA（远程直接内存访问）。如果你想象一下，这其实是传统服务器中数据包传输方式的过度简化版本。在这种场景下，数据流不再从应用层直接到GPU，而是会通过网络交换机从应用层传输到GPU，再传输到另一个GPU。

你可能会注意到这个过程完全跳过了内核。这是有意为之的设计。用一句话概括RDMA的原理，它本质上允许一台计算机直接读取另一台计算机的内存，绕过操作系统。GPU也可以实现这一点。如果从传统网络的角度来看，传统网络架构包括应用层、套接字层、TCP/IP层、设备驱动和网卡硬件。而在RDMA架构中，数据流会经过应用层（可能是NCCL或其他协议），然后通过libibverbs库，最终完全绕过内核。如果你想观察这些请求，必须创建自己的eBPF Hook才能看到。RDMA有多种形式，其中一种是基于汇聚以太网的RDMA（ROCE）。这种技术在RDMA早期阶段被广泛使用。

这种技术成本效益很高，但速度较慢，因为它本质上是基于以太网的RDMA。现在出现了其他替代方案，其中一种称为InfiniBand。这是一种网络架构技术，可以显著提升GPU之间的连接速度。它本质上是在数据中心层面扩展了RDMA的性能。此外还有NVLink和NVIDIA的NVSwitch技术，其工作原理非常相似。由于直接集成在GPU的NVLink上，它的速度稍快一些。总之，这些技术都是在RDMA等协议基础上构建的。

GPU概念总结：网络

复杂性开始

现在我们对即将面对的内容有了基本了解。让我们来谈谈这些复杂性。在GPU集群世界中，我们首先要考虑的是拓扑感知调度。我的意思是，如何将AI工作负载（无论是训练还是推理）部署到一组特定的节点上？如果其中某个节点发生故障，另一个节点也发生故障，我们是否需要将拓扑部署转移到另一组节点？这背后存在一些复杂性，同时也有需要这样做的原因。在这些GPU集群中，我们开始定义拓扑时不仅考虑区域、数据中心和可用区，还考虑机架，甚至特定GPU或GPU组所在的物理位置。这样做的原因是性能。当我之前提到在集群中使用RDMA时，通信速度受到GPU到GPU互连架构的限制，也受到物理距离的限制。

这些GPU之间的距离越近，通信速度越快。现实情况是，你希望AI工作负载尽可能高效运行，但GPU的性能和可靠性远不如CPU。数据中心的实际情况通常是：有一台完全宕机，三到四台运行正常，还有两台性能较差但仍在运行。你希望将工作负载部署到没有这些问题的节点上，并且部署在连续的物理块中，即彼此紧邻的节点。这听起来简单，但实际操作起来却非常困难。这也是我们现在在构建大规模GPU基础设施时必须解决的问题之一。

如果我们考虑更详细的网络架构图，并且之前提到过InfiniBand，可以想象一种脊叶（spine-leaf）网络架构，其中包含一组GPU服务器。如果你使用InfiniBand、NVLink或NVSwitch，那么每台节点之间可以实现约100千兆比特到600千兆比特每秒的传输速度。NVLink提供的带宽约为600千兆比特每秒。当你运行Allreduce操作时（我之前提到过，比如你将任务部署到八个GPU上时，Allreduce操作会同时使用所有GPU），这个任务运行速度的瓶颈取决于这八个GPU中性能最差的那个。你可以想象，这可能会带来一些非常棘手的场景。第一种情况是，如果你成功将任务部署到一个拥有八个GPU的节点上，这将是执行该操作最高效、最快的方式。

如果你将任务部署到至少同一机架内的节点上，这些节点之间通过NVLink或极短路径的RDMA进行通信，性能仍然会非常不错。但当你将相同任务部署到不同机架时，性能下降会非常明显。我认为在这种情况下，速度会从原本的每秒600千兆比特下降到每秒100千兆比特。如果你考虑多节点场景，这个问题会进一步加剧。我们注意到的一个现象是，比如你比较Allreduce延迟时，如果任务部署在不同机架但属于同一网络拓扑或交换机，其延迟会比默认不使用拓扑感知的场景低很多。例如，拓扑感知的Allreduce操作延迟为20毫秒，而默认方式下延迟为40毫秒。这是一个非常重要的改进，提升了46%的性能。这种提升非常显著。但问题在于，实现拓扑感知的复杂性较高。你可以使用各种组件来实现拓扑感知，无论是Kubernetes还是Slurm等系统。

你可以使用节点标签、拓扑信息和亲和性规则，或者自定义调度器和自定义调度插件。然后你需要通过一个拓扑感知的调度流程，包括提交Pod、基于节点进行过滤、对拓扑进行评分等步骤。这是一个相当复杂的算法过程。拓扑感知调度器正在不断涌现，每天都有新的调度器在CNCF项目中推出。

继续增加复杂性的是变异性问题。我之前提到过，GPU的可靠性并不高。如果你将一大组CPU和一大组GPU进行比较，并仅从整体可靠性和稳定性角度观察，GPU的表现会明显更差。这是因为GPU的性能不够一致。例如，如果你有100块完全相同的GPU，它们的性能也不会完全一致。有些GPU可能因为散热、供电或制造当天的工艺差异等原因表现更好。这里存在许多不同的变量。最近在亚特兰大超级计算大会2024上发表的一篇论文讨论了变异性感知问题。现在，变异性问题也逐渐成为一个重要的研究领域。在这个领域中，我们需要认识到并非所有GPU的性能都相同，因此需要根据实际观测到的性能来安排工作负载。

这听起来既有趣又具有挑战性，因为观察到的性能受到许多不同因素的影响。如果我们从简化后的图表视角来看，假设我们有三种不同的作业类型。类型C是优先级非常高的客户作业。类型B可能是那种会受到某个节点冷却问题影响的作业，比如Allreduce操作中，落后的GPU会影响整个组。类型A则是不受某个GPU性能低于其他GPU影响的作业。我们会优先处理类型C，因为这是高优先级客户作业，将它们放置在绿色区块中。接下来是类型B，因为它们会受到任意一个GPU性能低于其他GPU的影响。

最后，类型A可以放置在这个区块中，其中可能有一些作业表现不佳，但系统并不在意。论文提出的基本思路是，如果你能够获取数据中心的遥测数据和相关信息，不仅了解节点的当前状态，还能了解节点上不同类型作业的性能表现，你就可以开始对作业部署方式进行分类和优化。不过，这确实非常复杂。再次强调，我们正在为这个故事增加更多复杂性。

然后我们还有异步快照功能。如果回顾一下训练早期的快照机制，快照本质上是备份当前机器学习运行的状态。现在可以实现异步快照，即每个节点、每个GPU都可以异步上传当前状态，这些状态会被集中管理。这虽然很好，但实现起来也非常复杂。不过我们需要这样做，因为在同步模式下，所有工作节点都需要暂停。正如你之前记得的，每个机架的成本高达300万美元。暂停操作已经不再是可行的选择，因为成本极高。对于一个100GB的模型，我认为一次同步检查点可能需要长达一分钟。这会带来巨大的成本。如果你每10分钟进行一次检查点，就会损失约10%的利用率。解决方案是我们在所有节点上进行快速快照。所有GPU和节点只需几毫秒即可完成。

训练过程永远不会被阻塞。我们只在写入完成时才提交操作。这听起来不错，但实际实现起来相当复杂。此外，这里也存在一些问题。最后，我们还有称为NUMA（非统一内存访问）的节点。简单来说，NUMA是一种逻辑上的CPU或核心组划分方式，这些组直接连接到系统内存，而GPU则通过最短路径物理连接到内存。这意味着，如果有一个双插槽的GPU板，板上的GPU之间存在共享内存路径。你也可以思考在这种情况下作业的调度方式。例如，本地访问更快。当GPU需要访问的CPU内存位于同一节点时，延迟更低、带宽更高，通过直接PCIe路径连接，无需跨插槽通信。

当需要跨节点访问内存时，如我们在RDMA上下文中提到的，这确实是我们需要做的事情，但能避免时应尽量避免。这种情况下会导致更高的延迟、更低的带宽、更多的跨插槽链接，同时你还会使用到我们之前提到的互连架构。这些因素都会产生影响。数据加载、检查点写入可能会变慢。CPU预处理和多GPU训练会变得非常复杂，并可能因这些因素而变慢。仅举一个基本数据为例，NUMA对齐不当可能导致GPU性能下降高达40%。再次强调，这会增加复杂性，但同样重要且代价高昂。如果你考虑默认Kubernetes中的NUMA感知调度，或非NUMA感知调度，比如我们把一个Pod部署到Kubernetes上，这个Pod是一个需要两个GPU的GPU工作负载。简单来说，它会被调度到NUMA 0和NUMA 1两个不同的NUMA节点上。

这些节点并非NUMA对齐节点，它们没有共享内存。我们将看到约50%的性能损失。而如果我们使用Kubernetes新版本的NUMA节点拓扑感知功能，就不会出现这种性能损失。我们将获得本地CPU到GPU的直接PCIe访问，本地内存到GPU的数据传输，所有资源都来自同一个NUMA节点。这看起来像是一个显而易见的改进，但再次强调，这会增加更多复杂性，带来更多需要解决的问题，使我们更难在环境中观察和处理弹性问题。现实情况是，默认的K8s调度器，如果你直接部署使用，开箱即用，它并不了解NUMA。它只是在分配GPU时不会考虑CPU亲和性。你必须考虑实现自己的调度器、自己的拓扑感知、自己的可观测性，所有这些都需要在进行大规模GPU训练和推理时处理。

在进入混沌部分之前，先做个简要总结。这个领域的复杂性极高。刚才提到的只是你在处理大规模GPU集群时需要解决的几个问题。还有更多问题，但这些都是最核心、最昂贵的，需要提前处理。传统的混沌工程方法将不再足够。仅仅拔掉某个节点的电源并不能解决问题。正如你所看到的，这个领域现在需要解决的问题类型完全不同。最后，调度是一个非常复杂的问题，正如你所看到的。

混沌鸿沟

让我们先思考这个鸿沟。将其与传统的混沌工程进行对比。在传统混沌工程中，你将处理无状态工作负载、通用硬件、单一网络和以CPU为中心的故障，比如Java中的内存泄漏、CPU资源耗尽、磁盘空间满等。而在GPU场景中，训练是有状态的，首先就完全不同。你有模型权重，有检查点。我们还提到了许多其他因素。成本。我们提到每个机架成本高达300万美元，仅举个例子。这些事情非常昂贵。仅仅租用H100一小时，就不是你通常在AWS上启动节点并刷信用卡的典型操作。你可以这么做，我认为现在其实相当实惠，但过去不行。使用GB200时，你无法这么简单地操作。两套网络。你现在需要考虑传统网络模型和GPU互连网络模型，这两者都需要在混沌工程中处理。

Lastly, GPU-specific failures. Things like ECC errors, thermal throttling, and XID events. These are all foreign things. To point out, the current tools, some of them are starting to address these things, but they currently do not understand CUDA or DCGM, which limits their ability to help you do chaos engineering in this context. This may have changed. I'm not sure. I know Gremlin's starting to work on GPU stuff. At least as I know of now.

Let's first split things here a little bit. There's inference and there's training. In the inference world, we have stateless requests. You can load balance GPUs, horizontal scaling is possible, and model weights are read-only. In the inference world, it's fairly similar to the traditional chaos engineering approach. You still need to think about some of the complexity in the network. It's not as complex as the training world. In the world where we have stateful workloads, GPUs have to work in sync. Fixed topology requirements and those checkpointings are critical. There's a few different approaches we can take. Like in that traditional one, we can first just employ the normal chaos engineering approaches you do today, like killing nodes, latency injection, noisy neighbor, that kind of stuff. It's in the training world where we need to start thinking about new solutions, such as fault injection, checkpointing, fabric, and cascading failures.

We'll talk about some of those. There are four things we need to test. First, hardware simulation, this is ECC, thermal events, power problems, and XID errors. The second is resource exhaustion: VRAM, out of memory, and compute saturation. Even on these things with 14 terabytes of memory in a single rack, you still see these things occur when you're training really large models. Network faults, like in that GPU-to-GPU link, NCCL timeouts, fabric partitions. Then, lastly, we need to test workload disruption. What happens when we stop the job on one of the nodes? There's an important note. You are using incredibly expensive hardware when you do this. Try not to damage it while you're running potentially dangerous chaos experiments on your hardware. Dangerous to the hardware, not to yourself, I hope. The first problem is overflow. If we go back to our simple example, one node has eight GPUs.

This is not true of all nodes. It's just we're using it as an example. Some training jobs require set numbers of GPUs. They're calibrated. They're written for that number. Like the weights and everything are all calibrated for this node. I get we'll have eight GPUs. Stopping one is actually stopping the entire node. Because when you think about it, like in that Allreduce operation, for example, I mentioned before, it's using all of the available GPUs within the operation and it is bottlenecked by the slowest one. One of them being dead means the whole thing is kaput. We can think about something like node overflow, how we handle this problem. Where in the typical Kubernetes world or even just general distributed computing world, we've got maybe a set of idle nodes. Maybe we have a little bit of extra capacity in our cluster. Or we have a node autoscaler where we can just cycle in these nodes and put them in and everything comes back up and is running and everything is great.

听起来不错。但在GPU领域，事情并非如此。当某个GPU宕机时，其他所有GPU上的任务都会面临风险。真正的问题在于，我们能否随时准备一个备用GPU？不行，因为这些硬件是直接连接的。我们能否准备一些备用节点？答案是可以，但成本非常高。规模越大，成本越高。如果你要为大量任务、客户或内部团队设计溢出处理能力，溢出越多，浪费的成本也就越多。我想用一句话总结：这就是为什么混沌工程和可观测性如此重要。在调度之前，你需要了解系统的健康状态。

训练任务的弹性引发了诸多问题。在这样的背景下，让我们考虑几个场景。我们能否直接移除故障的GPU？不行，因为它们是物理连接的。此外，该任务现在也无法仅使用三块GPU运行。如果我们要用三块GPU运行，就必须停止任务、修改配置、重新部署，然后重新启动。我们能否移除所有四块GPU并重新调度？在我们讨论的拓扑结构中，它们会去往哪里？首先，我们需要确保检查点（checkpointing）已完成。其次，我们要部署到连续的节点、NUMA感知节点，这些都是我们之前提到的内容。你不能简单地重新调度，必须考虑诸多因素。我们能否直接移除整个节点？这是处理问题最昂贵的方式，因为现在你必须等待另一个节点上线，或者从预留池中获取可用节点。

也许你已经拥有额外的节点，但这就又回到了额外成本的问题。在这样的背景下，混沌工程的目标是：你根本不想遇到这个问题。你希望已经在数据中心、硬件和基础设施上运行混沌实验，从而提前了解数据中心中问题所在，并避免将工作负载部署到存在这些问题的区域。你无需回答这个问题，因为实际上并没有完美的答案。简要总结一下，随时准备额外节点的成本极高。正如我所说，了解GPU基础设施的状态要经济得多。不过，了解状态本身也颇具挑战性。假设你拥有一个大规模的GPU数据中心，你需要建立自己的控制平面监控平台，收集所有节点和GPU的匿名遥测数据，但不收集运行在它们上的任务信息。

要实现这种可观测性，你需要做一些工作，但这是值得的。你想要采取的措施是监控任务及其性能。这是一种“观察并等待”的策略，也就是说，你可以构建一个架构，其中包含一个匿名遥测数据控制平面。但这还不够，你必须实际使用它，并提前预防这些问题。你需要提前找出问题所在。这种方法无法应对随机故障。我们需要主动应对，而这就是混沌工程发挥作用的地方。

我今天为你准备了七个案例，你可以立即用于在GPU集群上实施混沌工程。第一个案例是DCGM故障注入。DCGM是我之前提到的项目，由NVIDIA开发。它允许你进入某个节点，实际上向GPU注入故障。你可以针对特定的GPU并为其制造故障。这个项目由NVIDIA开发，或者更准确地说，是其具备故障注入能力的特性。他们之所以这么做，是因为需要测试自己的硬件。他们想看看当制造预期的故障时，硬件会如何表现。在构建自己的硬件时，他们实际上在进行自己的混沌工程。现在我们可以复用这一能力，并为其添加一个API接口。通过这个能力，我们可以实现NVLink故障、电源管理、热节流、XID错误和ECC内存错误等操作。

这些都属于我们可以注入的错误类型。我必须感谢Chronosphere的Rob Skillington提出了这个想法。他和我正在合作开发一些相关内容，这个案例是他提出的，非常有价值。举个例子，你可以注入一些错误，比如GPU从总线脱落、GPU停止处理、内存页面错误，或者一些退化性问题，如ECC页面退役或预判清理。你基本上是将这些错误直接注入到GPU上。接下来你需要自问：为了确保混沌实验成功，你的监控系统是否能检测到这些错误？因为这些错误并不容易发现。你需要确保在GPU上正确实现了监控。警报是否触发？调度器是否做出响应？也就是说，这些数据是否被推送到你的可观测性平台。然后，部署AI工作负载到基础设施的调度器应该能够利用这些信息。

最后，作业是否能够进行检查点并恢复？这涉及多个方面。这种混沌方法可以有效锻炼多个团队，因为你可以测试可观测性能力、警报能力、调度和部署团队，以及实际使用你基础设施的机器学习工程师，确保他们正确实现了备份、恢复和检查点机制。非常实用。

第二个案例可能是我最喜欢的。我应该在幻灯片上放一张“这是一只好狗”的图片，因为这个案例基本上就是“点燃GPU并观察平台的反应”。虽然稍微复杂一些，但基本上你可以使用像GPU Burn这样的项目，这是一个容器化的GPU资源耗尽工具。他最初编写这个工具是为了在桌面GPU上进行测试，比如用于游戏，但你可以在大规模基础设施中使用它，并将其作为Pod部署到任意数量的GPU节点上。当节点上有多个GPU时，它甚至可以针对特定的GPU进行操作。这将允许你测试诸如OOM处理、CUDA上下文、内存碎片化、热管理等问题，因为你会将GPU的利用率提升到最大，测试电源输送和噪音邻居的影响。

你可以在混沌实验中做的一件事是，基本上将这个Pod作为边车容器部署到运行另一个训练作业的节点上。这就是你的噪音邻居测试。你将看到当另一个作业使用所有资源时，原本应该运行的作业会发生什么。它会被重新调度吗？它会进行检查点并执行清理吗？你如何处理这些场景？这是一个非常实用的案例。

回到RDMA主题，如果我们考虑传统的网络混沌，现在在GPU环境中需要以不同的方式思考混沌工程。传统的网络混沌方法对我们帮助不大。为了在网络层面实现混沌，我们需要尝试几种不同的技术。第一种是NCCL环境变量。你可以尝试禁用部分变量、增加开销或强制某些算法运行。这相对容易实现，今天就可以完成。第二种是在IP over IB上进行流量控制。这基本上就是添加延迟、丢包和带宽限制。你今天就可以在GPU互连网络中实现这一点，只是使用的工具与平时不同。最难的是eBPF Hooks。正如我之前提到的，要在RDMA环境中观察GPU之间的流量，需要创建监控每个GPU发送和接收事件的eBPF Hooks，因为这些操作会绕过内核。

它不会经过IPtables或TC。如果你想在这一层级进行混沌工程，需要自己编写eBPF程序才能实现。这将允许你测试多节点训练恢复、集体操作弹性等场景。例如，当你在多个节点的16个GPU上运行Allreduce时，可以通过此类测试观察性能下降情况。为了更具体地说明，左侧是NCCL变量环境修改。我们只需调整这些变量然后运行训练任务即可，这非常容易实现。中间场景则是进入节点运行TC。虽然需要一定基础设施访问权限，但整体来说操作难度不大。这是一个已定义的API和可用的CLI工具。

最难的部分是在节点中植入eBPF Hooks。这可能是最复杂的方法，因为内核会在创建节点上的eBPF程序之前，先验证和检查所有部署的eBPF程序。这需要大量工作。你必须用C语言编写这些程序，但这也是最强大的方法。

第六点，检查点混沌。我之前提到过同步和异步检查点，这是备份AI工作负载或训练任务的方式。我们可以采取几种不同方法。例如在同步场景中，可以直接终止同步检查点，这将是一个很好的混沌测试，观察团队如何恢复。在异步场景中，可以填满检查点的存储卷。我们的意思是，每个异步检查点都有一个预创建的存储卷，只需填满它并观察检查点任务的响应。这实际上可能非常有趣，我认为这会是一个有趣的测试。你还可以通过网络分区到存储的方式，显著减慢某个异步检查点的传输速度并观察结果。最后是第七点，我之前提到过在GPU集群部署工作负载时NUMA感知的重要性。

这稍微有些棘手，但非常有趣。NUMA 提供了一个可用的 CLI API，你可以利用它来完成一些操作。你可以围绕它构建一个 API 接口。你可以执行远程内存分配、NUMA 节点内存压力测试，甚至模拟内存耗尽的情况。你还可以进行跨 CPU 的资源饱和测试，或者彻底关闭拓扑管理器以观察会发生什么。从这些操作中可能会出现一些有趣的现象，例如静默性能下降。这将是一个很好的测试，帮助你验证你的可观测性系统是否能捕捉到原本可能遗漏的问题。如果工作负载使用了 NUMA 亲和性，但你意外关闭了拓扑管理器，可能会导致其他 NUMA 节点上的工作负载受到影响，而你却未察觉。这些都是一些有趣的场景。为了说明其工作原理，我们可以通过 NUMA CTL 强制进行内存分配。

实际上，我认为我们可以使用 NUMA CTL。是的，这三个功能。要观察当前的一些问题，你可以使用 nvidia-smi 工具来实际查看这些问题。虽然这些操作都相对简单，但它们都有对应的 API，你可以通过简单的 Python 程序自行创建这些问题。这并不会太复杂。不过，在这种场景下仍存在一些可观测性缺口。正如我所说，你可以通过 nvidia-smi 查看 GPU 利用率、内存使用情况、功耗和温度，一切看起来都正常。但实际情况可能是任务耗时远超预期，因为 GPU 正在等待远程内存、PCIe 带宽、数据加载器，甚至比最佳配置慢了 35%。我的观点是，这可以帮助你开始识别默认监控工具开箱即用时可能遗漏的这些缺口，从而更好地检测和理解这些问题。你可以将 NUMA 统计信息、NUMA 事件、训练吞吐量、PCIe 带宽等指标添加到你的监控平台中。你将逐渐意识到这些功能的重要性，它们不是可有可无的附加项。

我之前提到过有七种方法，这些就是那七种。现在我们需要思考如何扩展混沌工程的规模，因为刚才我向你展示的主要是 CLI 和脚本操作，这在大规模集群中并不具备可扩展性或强大的功能。对此有几种可行的方案。第一种是编写自己的定时任务集，并在 Kubernetes 中为其添加 API 接口。然后你可以通过 CI/CD 平台以计划方式部署这些任务。我们目前与部分客户合作时会采用这种方式。你也可以使用 Chaos Mesh 或 Litmus Chaos 等工具，编写自己的混沌实验，并利用这些平台来执行它们。最后，我们即将启动一个开源项目，我们将其命名为 GPUDragon，就像 Chaos Monkey 一样，GPUDragon。为什么不呢？这个项目将在新年之后正式启动。

该 URL 当前已经上线，不过它只是一个空仓库。我们、Chronosphere 以及一些其他团队将在此基础上创建一个实际项目，首先实现之前看到的那七个混沌实验。我们欢迎贡献者加入。该项目将通过 Thoughtworks 以 MIT 授权协议开源。

我想再稍微多说一点关于可变性感知调度的内容，因为之前我们提到过它的关键性，以及如何在这样的背景下思考混沌工程，尽管可变性感知调度本身仍处于非常前沿的阶段。我之前提到过，并非所有 GPU 的性能都相同。当你开始在环境中使用混沌工程时，可以提前发现这种差异性。我的意思是，我们之前看到了节点布局和所有节点的地图，其中一些是绿色，一些是红色或黄色，你需要以某种方式获取这些数据。

提前获取数据比事后发现客户运行在 GPU 基础设施上要好得多。当你实施这种混沌工程测试时，可以提前获取这些信息。然后你可以基于提前获取的数据做出可变性感知的决策。这使你能够建立基准线并验证调度策略。总之，除了成本因素外，我们还需要思考为什么这一点很重要。

我喜欢谈论可观测性反馈循环。第一部分是注入故障，正如我们之前看到的。第二部分是：我们检测到故障了吗？让我们确保我们确实发现了发生了什么。如果我们注入了热问题或电源问题，我们发现了吗？我们看到了吗？我们能看见吗？这些都是重要的问题，也是我们在这些 GPU 环境中一直在问自己的问题。如果我们看不到，就需要添加新的指标或告警。如果我们能看到，就会验证我们做了什么。然后我们会进行文档记录并重复这个过程。这个简单的流程非常强大。当我们开始在任何大规模 GPU 基础设施客户或其他场景中实施混沌工程以推动可观测性平台时，通过这个过程，可观测性能力会变得非常强大且非常稳健。因为与其被动等待问题发生，我们是基于之前解决过的问题，提前构建可观测性平台。

有一些检查清单或事项我想提及。第一部分是今天可以做的事情。你可以查看 GPU 利用率、内存使用情况、热状态。这些都是今天可以观察和分析的基本内容。我们描述的混沌工程方法将帮助你理解这些指标中哪些最重要，哪些需要开始跟踪。当前 GPU 可观测性存在一些空白。例如，没有任何指标能将 GPU 健康状态与作业性能相关联。实际上，将单个 Kubernetes Pod 映射到其实际使用的 GPU 上是非常困难的。这在今天并不容易实现。

总结与关键要点

总结一下，我们介绍了七种不同的混沌工程方法。实际上还有更多方法，这些只是我们今天讨论的一部分。DCGM 故障注入、GPU 烧毁测试、彻底摧毁测试、网络故障注入，共有三种不同类型。检查点机制和 NUMA 混沌工程，还有更多方法。目前对我们和即将启动的开源项目而言，这些是最重要的方法。本次分享的一些关键收获：我认为你现在应该明白，你必须这么做。这不是可有可无的事情。如果你每年花费数百万美元用于 GPU 基础设施，却不去提前发现可观测性平台的问题，这将耗费你大量资金。我建议你现在就开始。从基础做起：DCGM 故障注入、网络测试、检查点混沌测试，最后进入混沌可观测性循环。

从小处着手，逐步推进。一条新闻：NVIDIA 刚收购了 Slurm。尚不清楚这会对整体领域产生什么影响，但会很有趣。他们显然也在 Kubeflow 和 NeMo 等多个调度技术上投入研发。这可能意味着他们拥有调度技术，也可能对这个领域有积极影响。我们拭目以待。

资源与下一步行动

下一步行动：查看该仓库或直接点个星标。查看 DCGM，这可能是最直接的起点。你今天就可以用游戏电脑中的基础 GPU 进行测试，或者在线租用几小时。阅读相关论文，比如 PAL 论文非常值得一读。然后查看 Manning 出版的《平台工程》一书。虽然书中没有深入讨论 GPU 基础设施，但涵盖了整体平台工程架构。你可以在 Amazon 上找到这本书。

查看更多带文字稿的演讲

录制时间：

2026年7月10日

演讲者：

• Bryan Oliver

#### 相关赞助商

#### 相关赞助

• 2026年8月27日，东部时间下午1点：《底层框架之下：为什么代理上下文是一个基础设施问题》由 Tacnode 的联合解决方案架构师 Boyd Stowe 演讲

#### 本内容属于 DevOps 主题

##### 相关主题：

• DevOps

• 人工智能、机器学习与数据工程

• 混沌工程

• QCon AI 2025

• 系统韧性

• 文字稿

• QCon 软件开发大会

• 基础设施

• GPU

• 架构

• InfoQ

• 相关编辑

• InfoQ 社区热门内容：Slack 推出代理驱动的端到端测试以提高 UI 自动化测试的韧性 Node.js 26：默认启用 Temporal API，V8 14.6，以及一系列弃用功能 AI 模型上下文协议为企业的 AI 时代云安全提供集中式认证 意图驱动工程：云安全的新蓝图 Java 新闻速递：严格字段初始化、GlassFish、GraalVM、JReleaser、RefactorFirst WordPress 7.0 发布，核心引入 AI 基础功能，现代化管理界面和新设计工具