New in Together GPU Clusters: Reliability and control for production GPU clusters

Together GPU 集群新特性：生产级 GPU 集群的可靠性与控制能力

过去几周，我们向 Together GPU 集群推出了一系列改进，这些改进针对大规模运行训练和推理的实际操作场景：硬件会失效、调度器会出现泄漏、团队也会超出最初使用的单管理员 kubeconfig 工作流。本文将介绍我们推出的特性，解释我们为何以这种方式构建它们，以及这些改进对您当前在 Together 上运行的工作负载意味着什么。

这些改进可以归纳为两个主题。第一个是平台健康性：通过被动健康检查、自动节点修复和 Slinky 1.0，专注于检测并恢复那些实际会导致作业中断的故障模式。第二个是操作控制：新增集群详情视图、外部 OIDC、启动脚本和接受测试退出选项，专注于为您的团队提供必要的可见性、访问权限和自定义钩子，以支持组织规模的增长。

实时检测和修复故障

如果您曾在大型集群上运行过持续数天的训练作业，您一定熟悉这种模式。GPU 会从 PCIe 总线脱落，Xid 错误会使节点失效，热节流会悄无声息地限制作业吞吐量，直到损失曲线变平您才注意到问题。

这些是大规模环境下的稳态故障模式。关键在于您能多快发现它们，以及恢复的彻底性。

我们之前已经运行了主动健康检查，这是一种通过已知良好基准测试硬件的合成测试。主动检查在节点初始化和空闲节点时非常有用。被动检查则将覆盖范围扩展到实际工作负载运行时出现的故障。

图：健康检查标签页显示当前运行的所有主动健康检查及其历史信息

因此我们推出了被动健康检查，其工作方式类似于告警，并在集群的每个节点上持续运行，通过观察实际工作负载、日志和指标来实时发现性能下降。当前的覆盖范围包括 GPU 从总线脱落、热节流、Xid 错误、Slurm 节点故障时的排水操作，以及不断扩展的硬件和软件故障信号集。

这些检查对运行中的作业几乎零开销地监控实时工作负载。了解更多关于健康检查的信息。

图：节点修复建议和集群修复历史的修复标签页

检测本身只是一个仪表板，所以我们将被动检查与自动节点修复相结合。当我们的监控系统检测到节点级问题时，会生成推荐的修复方案并提交给操作员审核。根据故障特征自动映射出四种修复操作：

• 重启：原地重启并保留本地数据。适用于临时性问题的默认操作

• 重新配置：从干净镜像重建节点并清除本地数据

• 故障转移：将工作负载转移到新的裸金属节点并清除本地数据

• 移除：将节点从集群中移除并发送至 RMA

我们相信带有温度的自动化：您的训练检查点和推理副本价值太高，无法冒险依赖自动化排水系统。我们的“人机协作”方法让您始终掌握主动权——系统负责检测和推荐，您进行审批，Together则处理优雅的恢复操作。这是智能与安全的完美平衡。我们已经在为特定故障模式构建完全自动化的节点修复方案，但目前我们优先确保您的生产工作负载持续运行。了解更多关于节点自动修复的信息。

结果？您将数小时的支持工单时间缩短为几分钟的产品内操作时间。从问题发现到解决，您能比以往任何时候都更快重新投入工作。

Together Slurm-on-K8s 2.0：Kubernetes上Slurm的未来

在Kubernetes上运行Slurm不应该感觉像一场与崩溃守护进程、僵尸进程或调度器漂移的持续战争。我们基于对开源项目Slingshot的分支，从零开始重建了Slurm-on-Kubernetes架构，让那些“故障时扩展”的头痛问题成为过去式。

我们的升级架构为集群带来了以下改进：

自我修复的工作者守护进程：瞬时故障在所难免，但不应该导致节点崩溃。新架构对工作者进程进行监管，可自动在原地重启，确保长时间训练任务保持韧性。

告别僵尸进程：告别过去孤儿进程堵塞PID表并阻塞新任务的日子。我们的架构会自动清理孤儿进程，确保每次节点都保持干净并随时准备工作。

持久化作业计费：过去sacct历史记录存储在临时存储中，这意味着Pod重启可能会清空整个计费数据库。我们已将计费数据迁移至持久化、PVC支持的存储，重启和重新调度不再影响数据。计费对账和作业分析在整个集群生命周期中保持完整。

可靠的进程清理：作业结束后，以前被守护进程化的子进程会脱离Slurm的视线并持续运行——在运行之间占用GPU内存和/dev/shm段，有时甚至需要数天才能手动清理。新架构在内核级别追踪每个作业的所有后代进程，并在作业结束时可靠地清理所有进程。节点上的下一次作业每次都能在干净的机器上启动。

重新调度后的准确GPU状态：Pod重新调度后，Slurm对GPU的视图过去会出现与现实的偏差——上一版本的过时GPU标识符会与真实硬件不匹配，受影响的GPU会悄无声息地从可调度池中消失。新架构在每个节点启动时都会重新构建Slurm的GPU视图，确保可调度池始终与节点实际硬件一致。

除了可靠性，我们的新架构还会在集群的Grafana仪表板中暴露DCGM指标，让您开箱即用即可获得精细的集群级GPU利用率可见性。

所有新部署的Slurm集群默认使用最新架构。如果您正在使用现有的托管Slurm集群，我们可以通过维护窗口免费为您原地迁移——请联系您的账户团队安排时间。了解更多关于Slurm-on-K8s GPU集群的信息。

运营控制

可靠性只是问题的一半。随着集群在不同团队之间扩展，访问权限、可见性和定制化本身就会成为运营问题。更多的人需要访问权限，但权限各不相同。操作人员需要在不通过SSH登录节点的情况下了解集群的运行状态。工作流程需要定制化，而无需将每次更改都变成支持请求。以下是最新推出的特性，帮助用户满足最关键的需求。

全新的集群详情视图

我们围绕操作人员实际提出的三个问题，重新构建了集群概览页面：

• 集群是否健康？
• 集群是否正在被使用？
• 最近发生了什么？

新视图可一目了然地展示节点健康状态：正常、启动中、不健康、待处理和暂停。它还显示所有GPU节点的实时使用指标，包括利用率、内存和网络带宽，并支持深入分析的Grafana钻取功能。同一页面还包含事件时间线，展示集群内节点状态转换，并集中显示集群的完整配置信息：区域、GPU类型、驱动版本、网络配置、操作系统镜像和计费费率。

概览页面旁边新增了三个标签页：

• 节点：提供带利用率数据、健康状态信号和节点操作（如修复/运行健康检查和SSH命令）的详细列表和网格视图。
• 健康检查：提供集群主动和被动检查事件的历史时间线。
• 修复：提供节点修复操作的相同历史视图。这两个功能都用于回答“上周这个集群到底发生了什么？”这类回顾性问题，并取代了以往通过Slack线程与我们沟通的方式。

‍

Fig: 集群概览页面，用于查看高层次的健康状态和使用情况信息

Fig: 节点页面，用于查看节点详细信息和执行操作

用于Kubernetes RBAC的外部OIDC

如果您的团队目前访问Kubernetes API，很可能是共享管理员kubeconfig文件。这种方法仅适用于单一操作人员，但随着团队规模扩大很快就会失效。团队需要按用户审计跟踪、按用户撤销权限、最小权限访问以及更清晰的成员加入和离职流程。

我们为K8s RBAC新增了外部OIDC支持以解决这些问题。现在您可以将集群配置为使用现有的身份提供商（IdP）进行身份验证，包括Google、Okta、Auth0、Microsoft Entra ID或其他OIDC兼容提供商。每个团队成员使用自己的身份运行kubectl，API服务器会将他们的令牌与您的IdP进行验证，标准的Kubernetes RBAC通过ClusterRoleBindings和RoleBindings控制他们的操作权限。您将获得按用户分配的Kubernetes访问权限、通过IdP实现的权限撤销、与个人用户关联的审计跟踪，以及标准Kubernetes RBAC实现的最小权限访问。

对于需要在任何有意义规模上管理访问权限的团队，这是一次重大突破。管理员kubeconfig文件将变成应急工具。成员加入和离职流程将在您的IdP中处理，这才是正确的方式。集群操作审计跟踪将来自安全团队已经信任的系统。

外部OIDC必须在集群创建时进行配置。请参阅OIDC设置指南了解完整流程，包括针对Auth0、Okta和Google的特定提供商说明。Slurm和Kubernetes集群的OIDC支持功能即将推出。

集群定制化的启动脚本

大多数生产集群需要一些基础镜像中没有的配置：内部软件包、临时空间准备、监控代理、作业完成后发送 Slack 通知。我们曾目睹客户通过 SSH 登录到每个节点手动完成这些操作，或提交支持工单并等待处理。启动脚本将这些配置移至集群配置中，作为自助服务功能实现。

启动脚本允许您通过在特定生命周期事件中触发的 shell 脚本，自定义 Slurm 工作节点、登录节点和控制器：

• 节点启动时：安装软件包，配置工具，执行节点接受任务前所需的任何设置
• 作业启动时：准备数据，创建临时空间，配置作业环境
• 作业结束时：清理临时文件和残留进程，发送 Slack 通知，启动下游流水线

脚本在 Together Cloud 控制台中配置，并可在创建新集群时直接应用，无需重新构建。结果：您原本需要提交工单或手动执行的自定义配置，现在只需声明一次即可在集群中自动应用。我们甚至会验证脚本的错误，避免后续出现静默故障。有关如何根据自定义需求设置启动脚本的更多信息，请参阅此处。

"Slurm 启动脚本"；控制台中的启动脚本配置

接受测试，大型和长期运行集群的可选启用

在 Together AI，我们同时服务于大规模生产训练/推理工作负载，以及短期突发实验或单节点研究集群。对于这些较小或生命周期较短的集群，默认情况下我们会跳过验证 GPU 健康状况、网络和存储的接受测试，直接进入可用性检查。对于大多数集群，更快的可用性是更好的默认选项：减少等待时间，更快实现价值，尤其是我们持续对空闲节点进行健康检查。

对于大型集群或长期运行的训练任务，情况则相反。在节点分配时发现故障节点的成本，远低于在第 47 个训练周期才发现的成本，而验证成本相对于集群生命周期来说非常小。对于这些场景，我们建议在集群创建时启用接受测试。

这是一个有意为之的权衡，我们在 UI 中会明确提示：默认禁用接受测试以加快集群部署；对于多 GPU 训练或长期运行的生产集群，我们建议在创建时启用。

操作层面的变化

综合这些改进，操作人员从"出现问题"到"集群恢复可用"的路径变得更短，产品中新增了健康信号、修复操作、访问控制和集群历史记录功能。

研究人员和机器学习工程师将获得更可靠的作业保障，硬件故障时能获得更清晰的故障信号。平台团队将获得更完善的访问控制、修复操作、自定义配置和事件审查界面。操作人员将获得持久的计费数据、按集群统计的 GPU 使用率指标，并能通过集群视图快速回答基本问题：集群是否健康？是否正在使用？最近发生了什么？

后续计划

你将持续看到我们的关注方向：被动健康检查将覆盖更多故障模式，端到端自动化安全执行的修复操作将更加丰富，对节点实际运行状态的可观测性将更加深入，同时我们也会持续投入Slurm和Kubernetes技术栈的开发——这些是大多数大型训练任务依赖的基础架构。

如果你正在使用Together GPU Clusters运行训练或推理工作负载，且上述任何内容与你当前遇到的问题相关，请与我们联系。我们是这套系统的开发团队，期待了解哪些功能已经奏效，哪些方面仍需要进一步优化。

→ 分享反馈 → 预约客户咨询时段 → 阅读文档 ‍