Netflix Treats GPU Reliability as a Distributed Systems Problem

TL;DR · AI 摘要
Netflix Treats GPU Reliability as a Distributed Systems Problem - InfoQ InfoQ Homepage News Netflix Treats GPU Reliabili...
核心要点
- 主题聚焦:Netflix Treats GPU Reliability as a Distributed
- 来源:InfoQ,建议结合原文判断细节。
- AI 分析暂不可用,本条为保底评分与摘要。
Netflix 将 GPU 可靠性视为分布式系统问题 - InfoQ
InfoQ 首页 News Netflix 将 GPU 可靠性视为分布式系统问题
DevOps
扩展 OpenTelemetry:管理收集器、配置和成本(11 月 19 日网络研讨会)
Netflix 将 GPU 可靠性视为分布式系统问题
2026 年 10 月 30 日 3 分钟阅读
作者:
- Craig Risi
#### 关注我们
YouTube
232K 粉丝
26K 粉丝
新
RSS
19K 读者
X
57.1k 粉丝
21K 点赞
Bluesky
收听本文 -
0:00
音频准备就绪
您的浏览器不支持音频元素。
正常
1.25x
1.5x
喜欢
新下拉阅读列表
- 阅读列表
Netflix 详细介绍了其构建大规模 GPU 训练和推理可靠性平台的方法,通过分层健康检查、自动化修复和容错训练,即使在硬件故障情况下也能保持任务运行。
这个问题对于大型 AI 训练任务尤为突出。一个模型可能需要在数百个 GPU 上运行数周,所有工作节点同步运行。因此,单个 GPU 故障、网络适配器性能下降或机器运行缓慢都可能导致整个工作负载停止或显著减慢。Netflix 基于 Kubernetes 构建了其 GPU 计算平台,并设计了自动检测故障、移除不健康资源并允许长期任务从机器丢失中恢复的机制。
该方法已取得可衡量的成果:Netflix 报告 GPU 节点可用率超过 99.95%,任务成功率从约 98% 提升至超过 99.5%。
传统的云健康检查可以确认虚拟机正在运行且可访问,但这并不意味着其 GPU 能够处理分布式训练工作负载。
Netflix 发现 GPU 可能在状态查询时正常响应,但一旦分配内存或开始持续计算就会失败。同样,网络适配器可能存在但链接数量少于预期,导致集体操作带宽大幅下降。
设备级检查使用 NVIDIA DCGM 监控 GPU 错误、内存、互连和热条件,而网络检查则检查高速弹性结构适配器接口的状态和数量。Kubernetes 节点代理将这些结果转换为控制器可操作的节点状态。
这些检查被有意设计为“故障关闭”模式。如果诊断工具挂起,其超时将标记机器为不健康,而不是让故障检查报告成功。当正常 GPU 诊断机制本身失效时,Netflix 还通过内核日志维护了回退路径。
检测故障只是问题的一半。Netflix 构建了控制器,逐步响应故障而非立即替换整个机器。
短暂问题最初可能阻止新任务,但允许现有任务继续运行。如果问题持续,机器将被排空,其任务将被迁移。根据故障类型,修复措施可能从终止有问题的任务或重置 GPU,到重启机器或完全替换机器不等。
这种方法与 Karpenter 的节点自动修复功能集成,Netflix 添加了确定容忍不同故障时间长度以及一次可中断集群规模的策略。
Netflix 也接受无法完全消除硬件故障。相反,其训练平台使故障恢复成本更低。
大规模作业利用检查点机制和弹性工作节点,当机器丢失时,训练可从最后一个健康的检查点恢复。平台随后可以自动重试失败,同时将应用程序失败单独分类,以避免因真实软件缺陷反复重启作业。
Netflix 将训练作业本身视为分布式系统。与其仅关注失败的机器,它能够识别出拖慢整个作业进度的单一低效节点。这很重要,因为 GPU 不需要发生故障就会影响同步工作负载的吞吐量。
Netflix 还利用 NVIDIA 的多实例 GPU (MIG) 功能,使较小的推理工作负载能够共享 GPU,同时在租户之间保持内存级隔离。
与为每个工作负载分配整个 GPU 相比,这提高了利用率。Netflix 正在朝着 Kubernetes 动态资源分配 (DRA) 方向发展,这应允许更精确的资源请求和拓扑感知调度,包括确保 GPU、网络适配器和 CPU 在机器内正确部署。
Meta 同样广泛使用硬件诊断、自动化修复、检查点机制和快速恢复。其近期工作重点是检测大规模 AI 集群中的硬件故障,包括难以发现的静默数据损坏 (SDCs)。Meta 报告称,在 Llama 3 的训练过程中,硬件故障导致的训练中断占比超过 66%。
Netflix 的架构特别强调闭环运维:在调度前验证硬件,执行期间监控硬件,识别故障域,自动修复,并衡量修复后的有效吞吐量。与此同时,Meta 在硬件级故障检测、集群维护和恢复方面投入了大量资源。
这两种方法反映了相同的底层现实:当 GPU 数量达到数千级别时,可靠性不能再简单地等同于保持单个机器的可用性。
main wrapper for authors section
关于作者
section title
main wrapper for each author
#### Craig Risi
显示更多
显示更少
#### 本内容属于 DevOps 主题
##### 相关主题:
- DevOps
- 人工智能、机器学习与数据工程
- Netflix
- Kubernetes
- 硬件
- 云
- AWS
- GPU
- 分布式系统
- 相关编辑内容
- 相关赞助商 智能代理 AI 威胁:为什么你的 Java 补丁策略已经不够
- 相关赞助商 了解 Azul 如何帮助 Java 团队降低 JVM 漏洞风险,加强应用安全性,并为智能代理 AI 做好 Java 环境准备。发现保障 Java 工作负载安全的同时保持性能和可靠性的实用策略。了解更多。
InfoQ 新闻通讯
每周五汇总 InfoQ 最新内容,每周二发送。加入超过 25 万名高级开发者的社区。查看示例
我们保护您的隐私。