摘要

  • Slurm 分配节点、CPU、内存、GPU 和其他资源，将分区、优先级、服务质量规则、公平份额和预留转化为队列决策。
  • TRES、GRES、拓扑和 cgroups 让运营方能够把加速器作为受物理约束的资源进行调度；仅有 GPU 数量并不能保证合理放置或高效执行。
  • Slurm 开发者于 2010 年创立 SchedMD，以提供商业工程、支持和培训服务；NVIDIA 于 2025 年 12 月 15 日收购该公司，并承诺继续以开源、供应商中立的方式开发。
  • 收购后的可信度将取决于多供应商测试、版本发布行为和贡献模式，而每个集群运营方仍须对用户实际体验到的政策负责。

空闲的 GPU 不一定是可用的 GPU

在 Slurm 集群中，物理上空闲的加速器不会自动分配给下一个提出请求的人。作业首先必须符合某个分区的准入条件，匹配所请求的资源组合，满足账户和服务质量规则，不受相关节点预留的阻碍，并且优先级高于竞争作业。只有满足这些条件，调度器才会分配资源并允许作业启动。

这一过程使 Slurm 不只是一条队列。对于大量高性能计算和 AI 系统而言，它是准入与资源分配控制平面。用户提交作业；slurmctld根据集群状态和政策进行评估；计算节点上的slurmd进程启动并监控工作；slurmstepd管理各个作业步骤。可选的slurmdbd服务会在数据库中记录作业、资源使用情况和账户关系。

其影响不仅是技术性的，也是经济性的。一个 AI 集群的 GPU 总量可能足够，却仍无法启动大型训练作业，因为空闲设备分散在不合适的节点上、处于不适用的拓扑之后，或已为其他项目预留。调度器可以通过表示相关约束来减少这种浪费，但无法凭空增加缺失的 GPU、修复拥塞的互连网络，也无法让低效应用产生价值。

因此，Slurm 的重要性来自应用运行之前作出的决策。二十多年来，该项目一直在把一个简单问题——现在谁可以使用哪台机器？——转化为一套可配置系统，用于分配日益异构且昂贵的基础设施。

Slurm 将本地政策转化为机器使用时间

Slurm 起源于由 Lawrence Livermore National Laboratory 牵头的合作，并于 2002 年首次发布。它最初用于协调大型 Linux 集群中相互独立提交的并行工作，而不要求每个应用都了解整台机器。原始架构将资源分配与作业执行分离，并提供可供不同机构调整的统一控制层。

这种基本分工至今仍清晰可见。控制器集中掌握节点、作业和调度状态，计算节点守护进程则执行已经获得授权的工作。备用控制器和持久化状态可以减轻控制器中断的影响，但高可用性仍取决于一致的状态、正常的身份验证、网络可达性和经过测试的恢复程序。“容错”是一种设计能力，并不保证每次控制平面故障都不会造成影响。

更深层的变化来自 Slurm 不断增加的政策机制。分区将节点归入服务类别或管理资源池。关联关系把用户和账户与份额、限制及历史使用量连接起来。服务质量规则可以改变优先级、限制或抢占行为。预留可以为维护、活动或指定用户保留资源。多因素优先级可以综合作业等待时间、公平份额、作业规模、分区、QOS 和站点自定义因素。

Slurm 并不存在统一的公平定义。一所大学可能优先支持长期配额使用较少的项目；国家实验室可能为某项任务预留容量；商业 GPU 运营方可能建立差异化服务等级。同一套软件能够表达这三种模式，因为政策由各站点自行定义。

这种灵活性既是 Slurm 的优势，也是其运营风险之一。当分区相互重叠、例外不断累积、多个权重体系彼此影响时，队列可能变得难以解释。即使软件完全按照配置运行，用户也可能认为结果毫无规律。调度器可以计算优先级，但机构仍须说明政策的合理性。

公平份额决定谁要等待，而不定义何为公平

公平份额常被说成调度器的一项客观属性。实际上，它是一种把机构资源分配选择延伸到未来的机制。历史使用量、账户层级和配置份额会影响后续优先级，使资源消耗低于应得份额的群体，相对于超额使用的群体获得优势。

这使核算成为治理的一部分。slurmdbd可以记录一个或多个集群中的作业、步骤、关联关系和可跟踪资源。管理员利用这些记录生成报告、执行成本分摊、设置使用限制并计算公平份额。因此，一个看似只是行政用途的数据库字段，也可能影响研究人员或工程团队下一次获得稀缺算力的时间。

台账质量至关重要。如果用户被映射到错误账户、资源使用记录不一致，或历史数据保留方式不正确，由此产生的优先级可能在技术上有效，却不符合机构政策。项目成员变化、共享服务账户和人工修正记录都需要治理，因为调度器可能把它们视为资源资格的依据。

这正是队列争议难以简单归结为软件缺陷的原因之一。漫长等待可能由需求过高、不准确的运行时长请求、资源预留、较低的公平份额系数、拓扑要求、QOS 规则造成，也可能只是因为作业无法装入当前空闲资源。Slurm 提供了这些机制，但运营方需要足够的可观测性来还原究竟是哪一项发挥了作用。

因此，对用户而言，可解释性也是服务质量的一部分。如果人们能够看到作业为何处于等待状态、适用什么政策，以及满足什么条件才能启动，就更容易接受队列结果。随着集群成本和商业重要性上升，这种透明度正在从研究人员的便利工具转变为管理议题。

回填调度让空闲间隙产生有效工作

严格的优先队列可能浪费容量。一个大型高优先级作业或许排在最前面，却必须等到足够多的节点空闲后才能启动。如果没有额外机制，本可在这段预留时间之前完成的小型作业也可能继续等待，导致资源闲置。

Slurm 的回填调度器通过估算高优先级作业何时可以启动，再安排预计不会造成延迟的低优先级工作来解决这一问题。调度器并非只问下一个该运行哪个作业，而是判断某个作业能否利用暂时空档，同时维持排在前面作业的预计启动时间。

这一机制很有价值，因为大型集群经常处于碎片化状态。部分节点提前完成，其他节点仍被占用。短作业可以装入空档，而不改变机构认为更重要的作业的启动时间。因此，回填调度可以同时提高利用率并缩短等待时间。

其效果取决于所获得的信息。如果用户申请的运行时间远超实际需要，调度器可能认为作业无法安全装入空档；如果申请时间太短，作业可能在完成前被终止。拓扑和加速器约束也可能使理论上可用的空档无法使用。故障则可能使预计时间表失效。

回填调度浓缩体现了 Slurm 的运行模式。软件可以依据申报状态作出复杂决策，却无法准确预知未来。更好的队列结果依赖准确的请求、可靠的集群状态，以及能为调度器留出权衡空间的政策。

GPU 使资源分配的形态与规模同样重要

加速器改变了“可用容量”的含义。申请 8 个 CPU 通常比为分布式训练作业申请 8 个 GPU 更具可替换性。加速器型号、内存容量、PCIe 或 NVLink 关系、网络位置和节点构成，都可能决定资源分配能否达到预期性能。

Slurm 通过可跟踪资源 TRES 和通用资源 GRES 表示异构资源。GPU 可以计数、划分类型并与节点关联。设备和 cgroup 集成可以限制作业仅使用分配给它的加速器。拓扑插件和约束则能帮助调度器在一定程度上依据物理机器结构放置工作。

这使 GPU 从附属外设变成可调度的经济单元。管理员可以核算加速器使用量、限制访问、预留特定设备类型，并围绕稀缺硬件设计政策。对 AI 基础设施而言，这一点很重要，因为队列经常在决定谁能使用集群中最昂贵的组件。

不过，资源模型的价值取决于它能在多大程度上反映拓扑。分散在多个节点、通信路径不合适的 8 个空闲 GPU，未必等同于位于两台紧密互连服务器中的 8 个 GPU。调度器可以依据已配置的拓扑作出选择，却无法自动推断所有网络、内存或应用依赖关系。

利用率也存在同样的限制。仪表板可能显示 GPU 已分配，但作业实际上可能在等待存储、集体通信或数据加载，也可能不断失败。Slurm 可以告诉运营方谁在何时占用了资源，但仅凭这些信息无法证明加速器当时正在进行有效工作。

调度器位于互连基础设施之上，却仍依赖它

Slurm 不在数据传输路径中。作业启动后，应用流量会在处理器、内存、互连和存储之间流动，不经过调度器。但这并不意味着调度器可以独立于物理基础设施运行。

资源放置决策可以使工作集中或分散在不同交换机、区块或加速器域中。了解拓扑的资源分配可能缩短并行作业的通信距离；忽视拓扑的分配则可能在原始容量充足的情况下仍造成性能低下，因为真正可用的带宽位于其他位置。

调度器还依赖准确的节点状态。GPU 可能存在但并不健康；节点可能仍可与控制器通信，但其存储路径已经降级；网络分区可能使运行中作业的实际状态与控制器视图不同。插件、节点健康检查和本地运维流程需要把这些物理状况转化为调度器能够采取行动的状态。

这形成了一条在性能报告中容易被误读的边界。作业运行缓慢时，根本原因可能是资源分配、应用行为、存储、网络争用、加速器健康状况，或多项因素共同作用。如果集群处于空闲状态，原因也可能是需求不足、资源碎片化、预留或故障，而非调度算法不佳。

因此，对运营方真正有用的衡量范围是从请求到工作完成的完整路径：队列延迟、分配质量、启动成功率、执行时间、重试、损失的工作量和最终完成情况。GPU 总体分配率具有参考价值，但并不等同于有效产出。

SchedMD 将开放项目转化为支持业务

随着 Slurm 走出实验室，机构需要的不再只是源代码。生产集群需要可预测的版本发布、故障排查、升级协助、培训，以及能够应对特殊站点配置的工程师。Slurm 开发者于 2010 年成立 SchedMD，以提供这一商业服务层。

这一安排形成了常见的开源合作模式。代码继续按照项目许可证开放，客户则为复杂生产系统所需的专业知识、支持和开发付费。商业业务为维护者持续开展工程工作提供资金，也让运营方在控制大型集群的队列出现异常时拥有升级处理渠道。

SchedMD 还成为知识汇聚点。大型调度系统会积累大量难以仅靠文档掌握的运营细节，包括故障恢复、升级顺序、插件交互、核算边缘情况和特殊政策的影响。雇用核心维护者的公司可以把这些经验转化为支持优势，而无须拥有每一项贡献或每一个部署。

这种区别很重要，因为 Slurm 的政策始终由本地决定。SchedMD 可以提供代码、补丁和指导，但不会决定大学、国家实验室或商业 AI 服务内部的公平份额权重、预留安排或账户资格。Slurm 的用户体验一部分来自上游软件，另一部分来自机构自身的规则体系。

到 AI 提高可调度 GPU 容量的价值时，SchedMD 的角色已经超出传统软件供应商。它是一个开放控制平面的主要商业管理者，而许多运营方早已把该控制平面嵌入工作流、脚本、核算系统和操作程序。

NVIDIA 改变了项目管理的激励结构

NVIDIA 于 2025 年 12 月 15 日宣布收购 SchedMD。该公司表示，Slurm 将继续保持开源和供应商中立，同时称 SchedMD 的开发者将获得更多加速计算系统和工程资源。许可证并未突然变成专有许可证，此次收购也没有把本地调度政策的控制权从运营方转移给 NVIDIA。

发生变化的是项目主要商业管理者周围的激励结构。NVIDIA 不只是一家资助维护者的软件公司，也是 GPU、网络和系统的主要供应商，而这些产品的性能可能取决于工作负载如何被发现、放置和启动。

这既可能带来益处，也可能引发担忧。更早接触复杂 AI 系统可以改进测试，并缩短从硬件变化到调度器支持之间的时间。同样的紧密关系也带来一个合理问题：竞争性加速器、互连和系统设计是否仍会得到同等重视。

收购后最初几个月的现有证据，不足以断言项目已被控制，也不足以证明其完全中立。公开开发仍在继续。Slurm 26.05 及后续补丁显示版本工作保持活跃，2026 年 7 月发布的补丁还处理了崩溃及其他运营问题。Slinky 也继续开发。这些迹象比收购当天的承诺更能体现项目管理状况，但仍无法回答长期的比较性问题。

NVIDIA 还称 Slurm 被广泛用于领先的超级计算系统，并表示 SchedMD 在收购时支持数百家客户。这些说法表明其规模，但仍是企业自行报告且对应特定时间点的数据，并非对私有 AI 集群、研究系统或所有调度器部署的完整统计。

因此，供应商中立性应当被视为一项可观察的工程检验：能够通用的接口是否仍保持通用？影响竞争硬件的问题是否得到公开且及时的处理？发布流程和持续集成环境是否真正覆盖异构硬件？外部贡献者是否仍能影响代码，而无须通过 NVIDIA 的专有产品？

开源赋予运营方退出权，但不提供免费的替代方案

Slurm 的开源许可证很重要，因为运营方可以依照其条款检查、修改和再分发代码。这为软件被直接转为闭源设置了正式障碍，并在项目管理变得不可接受时，为社区提供合法的分支开发途径。

然而，仅有许可证并不能产生可行的分支。大规模调度需要熟悉控制器状态、核算、插件、版本发布、安全和广泛硬件组合的维护者，还需要测试系统、用户信心，以及愿意为受支持版本移植修复的人。

实际切换成本也远高于更换一个可执行文件。成熟的 Slurm 环境会积累作业脚本、账户结构、历史使用数据、自定义插件、监控、操作程序和用户习惯。另一款调度器即使技术能力足够，也可能需要高成本迁移政策和机构知识。

因此，NVIDIA 的所有权值得审视，但不能把可分支性当作完整答案。最有力的中立形式，不是在问题出现后理论上可以离开，而是在离开成为必要选择之前，项目就能持续适用于异构基础设施。

同样的逻辑也适用于商业支持。即使代码开放，运营方仍可能依赖雇用核心维护者的公司所提供的专业知识。如果这些知识逐渐集中于单一硬件生态，源代码可以继续开放，而实际支持边界却可能不再中立。

Slinky 将两个控制平面放入同一套环境

现代 AI 基础设施越来越多地把批处理调度与 Kubernetes 结合。平台团队可能希望用 Kubernetes 管理资源配置、运算组件、服务和容器生命周期，同时保留 Slurm 的作业模型、公平份额、预留机制和并行工作负载语义。

Slinky 是 SchedMD 连接这两个体系的尝试。其slurm-operator可以通过面向 Kubernetes 的机制部署和管理 Slurm 组件，slurm-bridge则在共享资源上协调 Kubernetes 与 Slurm 之间的工作。首个稳定版本系列于 2025 年末出现，1.2.0 版于 2026 年 7 月 2 日发布。

其吸引力显而易见。机构可以保留既有的 Slurm 政策，同时使用云原生工具管理周边基础设施，从而减少为批处理计算另建一整套独立运营环境的需要。

难点在于权限归属。Kubernetes 和 Slurm 对期望状态、工作负载所有权及恢复有不同的模型。如果发生故障后两个系统都认为自己控制某个节点、设备或工作负载，集成方案必须明确哪一方的状态具有权威性，以及如何使另一方重新保持一致。

这并非否定该方案的理由，却说明判断 Slinky 时应依据运营证据，而非仅看架构是否整洁。涉及两个编排系统时，生产部署需要说明如何处理升级、隔离、RBAC、控制器故障和局部网络分区。

Slurm 的发展史不断扩展调度器所协调的边界。与 Kubernetes 的集成延续了这一趋势，但每增加一个控制面，都更需要明确故障发生时责任会转移到哪里。

队列可以提高利用率，却仍可能产生糟糕结果

Slurm 为运营方提供多种方式，使昂贵容量得到更有效的利用。回填调度可以减少闲置空档；公平份额可以在一段时间内分配访问权；了解拓扑的资源放置可以改善局部性；预留可以保护关键工作；抢占则能为紧急或高等级作业腾出空间。

每种机制也都有代价。如果预期作业没有到来，预留会使容量闲置；如果应用无法保存检查点，抢占可能毁掉已有的有效工作；拓扑规则可以保障某个作业的性能，却增加其他作业的资源碎片；公平份额也可能奖励已经不再符合机构优先事项的政策。

当运营方只优化单一指标时，风险会进一步增加。把设备持续分配给因其他环节而停滞的工作，也能形成很高的 GPU 分配率。把作业放入会延长执行时间的资源组合，也能降低队列等待时间。激进抢占可以保障某个服务等级，却浪费被中断作业已经消耗的电力和算力。

对 AI 基础设施而言，更合适的指标是单位稀缺容量和时间所完成的有效工作。Slurm 对这一结果有所贡献，但它只是其中一层。训练框架、存储、网络设计、检查点、加速器健康状况和用户请求质量，都会影响资源分配能否创造价值。

这也是上游责任与本地责任之间的边界。如果站点选择偏向某个账户的政策、过度使用预留或设定不切实际的抢占规则，结果不应自动归因于 SchedMD 或 NVIDIA。如果调度器错误计算状态、不当处理设备或引入回归，则上游行为才是相关层面。

可信的运营体系必须具有足够的可审计性，才能区分这些情况。

真正的控制权分散在多个参与方之间

Slurm 的项目管理看似集中，因为一个控制器负责调度集群，而一家公司如今雇用了项目中的许多专家。实际上，控制权是分散的。

上游维护者决定哪些代码进入版本。NVIDIA 拥有 SchedMD，可以分配工程资源。硬件供应商贡献集成工作并提供测试系统。集群管理员选择版本、插件、拓扑模型、账户、QOS 和限制。机构管理者决定谁有资格获得稀缺算力。用户决定申请哪些资源，以及如何准确描述运行时间。应用本身则决定分配到的资源能否得到高效利用。

这种分层控制是理解 Slurm 的核心事实：没有任何单一参与方能控制完整结果。

它也解释了队列治理为何变得具有战略意义。当加速器不那么稀缺、价值也不那么高时，一条欠佳规则可能只是令人烦恼。在大型 AI 环境中，同样的规则却可能改变等待时间、资源碎片化程度，以及最终完成有效工作的昂贵容量规模。

Slurm 的成就在于，一套通用的开放系统能够表达截然不同的分配模式，而不强迫所有机构接受同一种公平定义。它的局限也恰恰相同：软件无法保证所选模式明智、清晰或正当。

因此，长期考验不只是 Slurm 是否继续调度作业，而是运营方能否持续还原作业为何获得或失去稀缺算力，同时上游项目能否在运营方希望使用的异构硬件环境中保持可信。