Make every GPU-hour count: Progress tracking in Red Hat OpenShift AI

让每一小时GPU时间都物尽其用：Red Hat OpenShift AI中的进度跟踪

Component | Article_teaser

2026年7月30日

6分钟阅读

人工智能

Shilpa Chugh

软件质量工程师

Subpattern | social_share_set

Component | social_share

分享

Subpattern | subscribe

Component | social_icon

订阅RSS

Component | Icon

© Red Hat, Inc. CC-BY-4.0许可

Subpattern | results_nav

组布局

Component | Nav_links

• 返回所有文章

Component | Generic

周五晚上，Priya作为一家金融服务公司的机器学习（ML）工程师，向每小时收费55美元的GPU集群提交了一个欺诈检测微调任务。该任务预计需要运行约40小时，计算成本约为2200美元。她反复检查超参数设置后提交了任务，随后回家度过了周末。

周一早上，她打开笔记本电脑。模型在周五晚上某个时间点停止了学习，但任务仍在运行——在毫无进展的训练过程中消耗了整整两天的GPU时间。这造成了超过1500美元的计算资源浪费，她必须从头开始。

如果这个场景听起来很熟悉，你并不孤单。每个运行过多日训练任务的从业者都面临这些令人不安的问题：

• 模型真的在学习吗？
• 是否应该提前终止并尝试不同的超参数？
• 它能在周二利益相关者审查之前完成吗？

缺乏认知的成本是真实的。按需GPU集群每小时费用可能高达50美元。一次多日训练运行就可能轻松达到数千美元，而配置错误的运行可能在任何人注意到之前就浪费整个周末的计算资源。在共享集群中，影响会成倍放大：一个停滞的任务不仅浪费一个团队的预算，还会阻止其他团队访问他们所需的GPU。一个团队的盲目运行会变成另一个团队的延误。问题不在于团队疏忽，而在于他们是在盲目行动。每一小时GPU时间都很重要——但如果没有对训练进度的实时可见性，太多时间都被浪费了。

可观测性鸿沟

这里有一个令人不安的事实——从平台角度来看，一个收敛良好的训练任务和一个完全停滞的任务看起来完全相同。两者都是处于运行状态的Pod，消耗相同资源，显示相同的绿色状态指示器。Kubernetes无法判断你的模型是否在学习。

如今，监控训练进度是可能的——但比应该的要困难得多。

• 日志分散且难以使用：在分布式训练任务中，日志分布在多个Pod中。找到相关输出需要知道查看哪个Pod、如何访问它以及如何解读特定框架的日志格式。这需要Kubernetes专业知识，而大多数数据科学家和AI工程师不应该为了监控训练运行而需要掌握这项额外技能。质量差且无结构的日志不容易被机器读取，因此无法驱动自动化。

• 外部工具解决了可观测性但增加了管理负担：像MLflow和Weights & Biases这样的实验跟踪平台在其领域内表现出色。但它们需要额外的基础设施进行部署和维护，需要管理API密钥和访问控制，并且它们在平台层之上运行。它们还与Kubernetes API断开连接，这意味着将它们与自定义Kubernetes原生工作流和自定义操作符集成更加困难。它们可以告诉你训练循环内部发生了什么，但无法告诉平台正在发生什么。

• 每个框架都有自己的实现方式：PyTorch DDP、FSDP、DeepSpeed、JAX——每个框架都有自己独立的日志记录规范、指标格式和进度汇报方式。框架之间缺乏一致性，这意味着管理异构训练环境的平台团队无法获得统一的视图。

• 没有标准的API：到目前为止，训练任务一直没有标准化的方式向平台汇报进度。结果是管理共享GPU集群的平台管理员只能猜测哪些任务在正常进行、哪些任务卡住了、哪些任务即将完成。缺乏这种可见性，使得容量规划和故障排查只能依靠猜测。

缩小差距：Red Hat OpenShift AI中的进度跟踪

Red Hat OpenShift AI现在为分布式训练任务提供了生产级的进度跟踪功能，该功能已集成到Kubeflow Trainer v2中，并从Red Hat OpenShift AI 3.4版本开始正式发布。您可以在任务进行时实时查看其状态，并在为时已晚之前采取行动。该功能通过为数据科学家、机器学习工程师和平台管理员提供训练任务实时性能的可见性，直接解决了可观测性差距问题。

这种可见性基于三个支柱：

• 仪表板可视化：实时进度指标可以直接在Red Hat OpenShift AI仪表板中查看。一目了然地看到进度百分比、当前步骤和总步骤数、当前训练轮次、剩余时间预估、训练损失以及TrainJobs的评估指标。无需额外工具，无需额外配置。

• SDK集成：通过Kubeflow SDK可以以编程方式访问相同的进度数据。这使团队能够构建自动化的流水线，根据实时指标对训练进度做出反应——触发提前停止、发送通知或根据实时指标重新分配资源。

• 多框架一致性：无论使用PyTorch DDP、FSDP、DeepSpeed还是JAX，进度跟踪的实现方式都保持一致。它还通过CustomTrainer API支持自定义训练代码。这为不同框架提供了统一的使用体验。

实时观察训练过程

理解进度跟踪功能的最佳方式是亲身体验其使用过程。有三个关键步骤：

• 启动训练任务：您使用Kubeflow SDK从笔记本提交训练任务，方式与现在完全相同。如果您使用HuggingFace Transformers，进度跟踪会自动启用——无需任何代码修改。集成会检测到Kubeflow环境，并开始从您的训练循环中报告指标。

• 查看进度：在训练运行期间，实时指标会显示在Red Hat OpenShift AI仪表板中：进度百分比、剩余时间预估、已完成的步骤数、训练轮次、梯度范数、训练损失和学习率。无需查看日志末尾，无需通过SSH连接到Pod，也无需设置外部工具。

图1：Red Hat OpenShift AI仪表板显示任务列表，其中运行中的TrainJob进度条显示40%完成度。

图2：任务进度和实时指标的详细侧边面板。

• 根据所见采取行动：进度跟踪功能真正节省了您的时间和计算资源。注意到损失值没有改善？提前终止任务，节省数小时的GPU时间。发现某个运行比预期更快收敛？为团队成员释放资源。精确掌握任务完成时间，从而合理安排计划——无需再猜测结果是否能及时准备周二的干系人评审。

使这一功能切实可行的关键特性：

• 零配置：无需额外基础设施，无需外部依赖，无需额外配置。进度跟踪开箱即用。

• 极低开销：在自然训练检查点报告指标，且不影响训练性能。

• 跨框架兼容：无论您使用PyTorch DDP、FSDP、DeepSpeed、JAX还是自定义训练代码，使用体验都完全一致。

受益人群

数据科学家和机器学习/AI工程师无需通过SSH连接到Pod或查看日志，即可实时查看训练损失、进度百分比和预计完成时间。早期发现训练发散或停滞——在周六早晨而非周一发现停滞任务，可节省数小时的GPU时间。通过仪表板快速对比不同训练运行，迅速识别出表现最佳的超参数配置。

平台管理员可获得集群中所有训练任务的统一仪表板视图。无论任务使用DDP、FSDP还是DeepSpeed，他们都能看到一致的指标，并通过了解哪些任务在进展、哪些停滞、哪些接近完成，做出更优的容量规划决策。

在多团队共享同一集群的多租户GPU环境中，这种可见性直接提升资源利用率和投资回报率。对于构建GPU即服务模式的组织而言，进度跟踪填补了关键缺口——将"GPU利用率黑箱"转变为可观测、可管理的系统。最终，这使平台团队能够消除基础设施瓶颈，并自信地为数据科学家提供所需资源以加速AI创新。

超越监控：构建更智能训练的基础

进度跟踪不仅是监控功能，更是构建智能训练的基础。一旦平台能够获取实时训练进度数据，一系列更智能的行为便成为可能。虽然这些高级功能目前还不是Red Hat的产品承诺，但基础架构已经就绪。上游Kubeflow Trainer社区正在积极探索多个方向：

• 更智能的超参数调优：目前，Katib等超参数优化引擎依赖脆弱的正则表达式解析日志来评估试验性能。通过Kubernetes API直接获取训练指标后，Katib可以原生读取训练状态——实现更紧密的集成和更高效的试验编排。这是上游社区正在讨论的KEP。

• 弹性扩展：收敛速度和预计完成时间数据可用于指导扩容和缩容决策。快速收敛的模型可以释放GPU资源给其他团队，而陷入平台期的模型则可请求更多工作节点。上游社区正在探索TrainJob中的弹性PyTorch支持以实现这一目标。

• CLI进度可见性：kubectl get trainjob命令内置PROGRESS %列，可将训练进度直接带到命令行，使操作员无需依赖仪表板或SDK即可获得即时可见性。

• 更智能的检查点机制：虽然 OpenShift AI 已经支持周期性和按需模型检查点保存，但通过提供 ETA（预计到达时间）和进度数据，平台可以更智能地决定检查点时机——例如根据任务 ETA 自动保存状态。上游社区正在探索使用 CRIU 实现透明 GPU 检查点，以增强 TrainJob 的容错性和恢复能力

这些是 Kubeflow 项目正在积极探索的领域——并非产品承诺，但它们说明了为什么进度跟踪的重要性超越了即时功能：它为整个训练堆栈构建了数据层基础。

分布式训练的进度跟踪功能已在 Red Hat OpenShift AI 3.4 中正式发布。了解更多信息，请阅读 Red Hat OpenShift AI 官方文档。您也可以通过启动 Red Hat OpenShift AI 60 天免费试用亲自体验。

Block | Dynamic pattern deluxe promo

Component | Band_header

Resource

适应性企业：为什么 AI 准备度就是抗风险准备度

这本电子书由 Red Hat 首席运营官兼首席安全官 Michael Ferris 所著，帮助 IT 领导者应对当前面临的 AI 技术变革和颠覆性挑战。

Component | spacer

Component | Cta_multi_basic

Subpattern | simple_cta

Component | CTA

获取资源

Deluxe mbox

Component | Card_header

关于作者

Subpattern | speaker

Card layout

Component | Image_embed

Component | Person

Shilpa Chugh

Subpattern | social_links

我是 Red Hat 的软件质量工程师，专注于 Kubeflow 和分布式 AI 训练。我致力于打造高效且具有弹性的大规模基础设施，并在 Kubernetes 上分享分布式模型训练和微调的见解。

查看该作者的更多作品

类似内容推荐

Dynamic pattern

Blog post

Red Hat OpenShift 机密计算和沙箱功能最新进展

介绍 asago：开源 AI 安全与治理编排工具

Original podcast

技术访谈 | 用开源定义主权 AI

技术访谈 | 开源 AI 战略解析

Subpattern | card_flex

Subpattern | text_basic

继续探索

• 什么是智能体 AI？ 文章

• 预测性 AI 与生成式 AI 对比 文章

• 构建生产级 AI/ML 环境的关键考量 电子书

• 以 Ansible 方式实现生成式 AI 视频

• 通过现代应用平台实现创新与转型 电子书

Keep Exploring mbox

Subpattern | simple_text

按频道浏览

探索所有频道

Pattern | raw_html

自动化

关于 IT 自动化的最新动态，涵盖技术、团队和环境

人工智能

平台更新，帮助客户随时随地运行 AI 工作负载

混合云

探索我们如何通过混合云构建更灵活的未来

安全

关于如何在不同环境和技术中降低风险的最新动态

边缘计算

关于简化边缘运算平台的最新动态

基础设施

关于全球领先的企业的 Linux 平台最新动态

应用程序

深入探讨我们解决最复杂应用挑战的方案

虚拟化

企业虚拟化的未来，适用于本地或跨云的工作负载