过去几周，我们对 Together GPU 集群进行了一系列更改，旨在应对大规模训练和推理运行中的运营现实：硬件故障、调度器泄漏，以及团队规模超出最初使用的单管理员 kubeconfig 工作流。本文将介绍我们交付的内容、构建方式，以及这对您目前在 Together 上运行的工作负载意味着什么。
这些更改分为两个主题。第一个是平台健康：被动健康检查、自动节点修复和 Slinky 1.0，专注于捕获和恢复实际导致任务宕机的故障模式。第二个是运营控制：新的集群详情视图、外部 OIDC、启动脚本和验收测试可选退出，专注于为您的团队提供随着组织发展而运行集群所需的可见性、访问权限和自定义钩子。
在故障发生时捕获并修复
如果您在大型集群上运行过多日训练任务，您会熟悉这种模式。GPU 从 PCIe 总线上脱落。Xid 错误使节点退出轮换。热节流悄然限制任务的吞吐量，直到损失曲线变平您才注意到。
这些是大规模下的稳态故障模式。关键在于您多快捕获它们以及多干净地恢复。
我们已经运行了主动健康检查，即针对已知良好基线对硬件进行测试的合成测试。主动检查在资源调配时和空闲节点上很有用。被动检查将覆盖范围扩展到实际工作负载运行时出现的故障。
图：健康检查选项卡显示当前运行的所有主动健康检查及历史信息
因此，我们构建了被动健康检查，它像警报一样工作，持续在集群中的每个节点上运行，观察实际工作负载、日志和指标，以在性能下降发生时立即呈现。目前的覆盖列表包括 GPU 从总线脱落、热节流、Xid 错误、故障时 Slurm 节点排空，以及不断扩展的硬件和软件故障信号。
这些检查以接近零的开销观察正在运行的任务上的实时工作负载。了解更多关于健康检查的信息，请点击此处。
图：节点修复建议和集群修复历史的修复选项卡
检测本身只是一个仪表板，因此我们将被动检查与自动节点修复配对。当我们的监控系统检测到节点级问题时，它会生成推荐的修复措施，并呈现给操作员审查。有四种修复操作，根据故障特征自动映射：
重启： 原地重启，保留本地数据。临时问题的默认操作
重新配置： 从干净镜像重建节点，清除本地数据
故障转移： 将工作负载转移到新的裸金属节点，清除本地数据
移除： 将节点从池中取出并送去 RMA
我们相信自动化需要人的参与：您的训练检查点和推理副本太宝贵了，不能冒险使用自动排水。我们的“人在回路”方法让您保持控制——系统检测并推荐，您批准，然后 Together 处理优雅恢复。这是智能与安全的完美平衡。我们已经在为特定的故障模式构建全自动节点修复选项，但目前，我们优先确保您的生产工作负载不中断。了解更多关于节点自动修复的信息，请点击此处。
结果如何？您将数小时的支持工单变成了几分钟的产品内工作流。从检测到解决，您比以往任何时候都更快地回到资源池中。
Together Slurm-on-K8s 2.0：Slurm on Kubernetes 的未来
在 Kubernetes 上运行 Slurm 不应是一场与崩溃守护进程、僵尸进程或调度器漂移的持续战斗。我们基于 OSS 项目 Slinky 的分支，从头重建了我们的 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讨论。
图：集群概览页面，显示高级健康和利用率信息
图：节点页面，显示节点详细信息及操作
用于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 的特定提供商说明。Together 对 Slurm 和 Kubernetes 集群的 OIDC 支持即将推出。
用于集群自定义的启动脚本
大多数生产集群都需要一些基础镜像中没有的设置：内部包、临时空间准备、监控代理、作业完成时的 Slack 通知。我们曾看到客户通过 SSH 登录每个节点手动执行这些操作，或者提交支持工单等待我们处理。启动脚本将这些设置作为自助服务能力纳入集群配置。
启动脚本 允许您通过 shell 脚本自定义 Slurm 工作节点、登录节点和控制器，这些脚本在特定生命周期事件触发：
节点启动时： 安装包、配置工具、运行节点接受工作前需要完成的任何设置作业开始时： 暂存数据、准备临时空间、配置每个作业的环境作业结束时： 清理临时文件和残留进程、发送 Slack 通知、启动下游管道
脚本在 Together Cloud 控制台中配置，可在创建时应用于新集群，无需重建。结果：您原本需要提交工单或手动运行的自定义设置，现在只需声明一次，即可自动应用于整个集群。我们甚至会对脚本进行错误验证，以避免后续静默失败。了解如何根据自定义设置配置启动脚本的更多信息，请点击此处。
验收测试，针对更大、运行时间更长的集群可选启用
在 Together AI，我们既服务于大规模生产训练/推理工作负载，也服务于短时突发实验或单节点研究集群。对于这些较小或短生命周期的集群，我们默认跳过验收测试套件（该套件验证 GPU 健康、网络和存储），直接进入可用状态。对于大多数集群，更快的可用时间通常是更好的默认选择：减少等待，更快实现价值，尤其是我们持续对集群中空闲节点进行健康检查。
对于更大的集群或长时间运行的训练作业，情况则相反。在配置时发现故障节点远比在第 47 个 epoch 发现要划算，而且验证成本相对于集群生命周期而言很小。对于这些情况，我们建议在集群创建时启用验收测试。
这是一个刻意的权衡，我们在 UI 中明确提示：验收测试默认禁用以加快配置速度；对于多 GPU 训练或长时间运行的生产集群，我们建议在集群创建时启用。
运营上的变化
综合来看，这些变化为运维人员提供了一条更短的路径，从“出现问题”到“集群再次可用”，产品中包含了健康信号、修复操作、访问控制和集群历史记录。
研究人员和机器学习工程师能够获得更高的作业可靠性，抵御硬件故障，并在性能下降时得到更清晰的信号。平台团队能够获得更好的控制面，用于访问、修复、定制和事件审查。运维人员能够获得持久化的核算数据、每个集群的GPU利用率指标，以及一个集群视图，该视图首先回答基本问题：集群是否健康、是否正在被使用、最近发生了什么？
下一步计划
您将继续看到我们围绕以下主题的进展：被动健康检查覆盖更多故障模式、更多可安全实现端到端自动化的修复操作、对节点实际运行状况的更深入可观测性，以及对大多数大型训练作业所依赖的Slurm和Kubernetes技术栈的持续投入。
如果您在Together GPU集群上运行训练或推理工作负载，并且上述内容与您遇到的问题相关，请与我们联系。我们是构建该系统的团队，希望听取哪些功能有效、哪些方面仍需简化。