NVIDIA 收购了门卫：SchedMD 与 Lock-In 实际所在
I’m happy to translate the article for you, but I need the text you’d like translated. Could you please paste the content (or the portion you want translated) here? I’ll keep the source line, formatting, markdown, and any code blocks exactly as they are while translating the rest into Simplified Chinese.
Source: …
NVIDIA收购SchedMD
在 2025年12月15日，NVIDIA收购了SchedMD，这是一家位于犹他州Lehi、拥有40名员工的公司。收购价格未披露，新闻稿强调了对开源的承诺，而大多数报道则聚焦于NVIDIA不断扩大的软件组合——因此完全错过了重点。大多数人没有意识到这件事有多么重大。
SchedMD维护着 Slurm，这是一款在 TOP500超级计算机的65 % 上运行的工作负载管理器，其中包括超过一半的前10名和超过一半的前100名。每当研究人员提交训练任务、每当机器学习工程师排队进行批量推理、每当国家实验室为模拟分配计算资源时，都有很大可能是Slurm在决定哪些GPU实际运行这些任务。
大家一直在关注CUDA的护城河。Judah Taub最近的 Substack文章 完美地阐述了这一点：编程模型是锁定的根源，存在五条可能的逃生路线，分别是OpenAI的Triton、Google的TPU、AMD的ROCm、Modular的Mojo以及Tenstorrent的RISC‑V方案。所有这些都是有效的竞争威胁。
但值得称赞的是，NVIDIA看穿了编程模型的争论，识别出加速规模扩展的关键途径之一。他们买下了守门人。
Slurm 实际做了什么
如果你从未向 HPC 集群提交过作业，Slurm 就像是看不见的基础设施，这正是它的设计初衷。研究人员只需键入
sbatch my_training_job.sh他们的代码就会在 GPU 上运行。但到底这些 GPU 如何被分配、作业何时真正启动、哪些节点负责分布式训练的哪一部分、竞争的作业如何排优先级、你的实验是今晚运行还是下周二运行——这些全部都是 Slurm 在背后处理的。
正式描述 听起来几乎 过于基础：
“分配对资源的独占和/或非独占访问，提供一个用于启动、执行和监控工作的框架，并通过管理待处理作业队列来调解资源争用。”
实际上，Slurm 是将组织政策转化为计算资源分配的层。它包括以下方面：
- 公平共享调度 跨研究组
- 优先级覆盖 用于对截止日期敏感的项目
- 资源限制 防止单个用户垄断集群
- 抢占策略 平衡吞吐量
- 对 Hilbert‑curve scheduling 的响应，优化网络拓扑
……以及更多功能。甚至可以在不需要 SSH 的情况下直接启动作业！
每个使用 Slurm 的组织都在多年的调优过程中将其资源管理理念编码进配置文件中，分区定义和服务质量策略中蕴含了机构知识，计费系统与项目经费和预算挂钩，用户培训也围绕 Slurm 命令展开。这不是一个可以在周末随意替换的程序。
为什么 Slurm 胜出
Slurm 并不是显而易见的选择。当 2001 年在劳伦斯·利弗莫尔国家实验室（LLNL）开始开发 时，HPC 领域仍在使用专有调度器：
- PBS（Portable Batch System）在各处都有变体
- IBM 的 LoadLeveler 主导了它们的生态系统
- Quadrics RMS 处理专用集群
- Platform Computing 的 LSF（Load Sharing Facility）为企业 HPC 提供服务
LLNL 想要一些不同的东西，因为他们正从专有超级计算机转向商品化的 Linux 集群，需要一个 能够扩展到数万节点、在各种架构上 高度可移植、且 开源 的资源管理器。2002 年的首次发布（https://www.schedmd.com/about-schedmd/slurm-history/?ref=distributedthoughts.org）故意保持简洁，名称最初代表 “Simple Linux Utility for Resource Management”（后来的缩写被舍弃，但 Futurama 的梗仍保留）。
接下来发生的事情是开源在基础设施市场取胜的案例研究。
- PBS 分裂为 OpenPBS、Torque 和 PBS Pro（现为 Altair），社区被稀释。
- LSF 在 IBM 于 2012 年收购 Platform Computing 后转为商业化；许可证费用在大规模使用时成为障碍。
- Grid Engine 的所有权在 Sun、Oracle 和 Univa 之间来回跳动，侵蚀了社区信任。
Slurm 始终专注于 单一代码库，采用 GPLv2 许可证，无法被闭源，并拥有 插件架构，让组织能够在不分叉的情况下进行定制。2010 年，Morris Jette 和 Danny Auble 离开 LLNL，成立 SchedMD（https://en.wikipedia.org/wiki/SchedMD），创建了一种商业支持模式，在保持软件免费的同时为持续开发提供资金——这相当于 Red Hat 的做法，只是应用于 HPC 调度。
2023 年的 Hyperion Research 数据（https://hyperionresearch.com/product/slurm-remains-top-resource-manager/?ref=distributedthoughts.org）显示，**50 % 的 HPC 站点使用 Slurm**，而紧随其后的 OpenPBS 仅为 18.9 %，PBS Pro 为 13.9 %，LSF 为 10.6 %。这一差距并未缩小，反而在扩大。
双门策略
与所有这些噪声并行，NVIDIA 并没有坐视不理。
在 2024年4月，NVIDIA 收购了 Run:AI ，金额约为 7亿美元。Run:AI 构建基于 Kubernetes 的 GPU 编排……
（原文在此截断；文章的其余部分在此之后继续。）
Source: …
Run:AI vs. Slurm – 两条通向同一目标的路径
如果 Slurm 是超级计算机和传统 HPC 集群管理 GPU 工作负载的方式，Run:AI 则是云原生组织在 Kubernetes 上实现同样功能的方式——不同的范式服务于相同的功能，而 NVIDIA 现在拥有两者的调度层。
Run:AI 的世界
Run:AI 处理的是容器和微服务孕育出的世界：
- 在 GKE、EKS 或本地 Kubernetes 集群上运行的组织
- 围绕以下工作流构建的 数据科学团队
- 思考方式是 pod 和 deployment，而非批处理队列和节点分配的公司
Slurm 的世界
Slurm 处理的是超级计算孕育出的世界：
- 国家实验室
- 研究型大学
- 进行分子动力学模拟的制药公司
- 进行风险模拟的金融机构
- HPC 先于云出现的组织，在这些组织中，“规模”意味着拥有数千节点的专用集群
两条道路都通向 GPU，且 NVIDIA 现在掌控着两者的流量。
Source: https://judahtaub.substack.com/p/the-startup-escape-plan-for-cuda?ref=distributedthoughts.org
实际的锁定表现
Judah Taub 的 CUDA 分析 正确指出，编程模型会产生真实的锁定，因为为不同平台重写 GPU kernel 成本高昂，而围绕 CUDA 的库、工具和社区知识生态则是数十年累计的投资。
但是 编程模型可以抽象化，编译器可以翻译，兼容层也存在。
- PyTorch 通过 ROCm 在 AMD GPU 上运行。
- JAX 在 TPU 上运行。
你编写的代码不一定要永久绑定到 CUDA，尽管迁移会有摩擦。
编排黏性
编排会产生另一种黏性，因为你的工作流是通过 Slurm 编码的：
- 每个批处理脚本
- 每个作业数组定义
- 每个依赖链，诸如“仅在步骤 A 成功完成后才运行步骤 B”
这不仅是代码；它是制度记忆。
- 计费系统 通过报告与 Slurm 集成，向部门负责人展示 GPU 配额的使用情况。
- 内部计费系统 为内部项目计费。
- 合规日志 验证政府资助的研究在批准的基础设施上运行。
你的用户通过不假思索的命令、作业挂起或失败时的调试直觉、HPC 团队编写的培训材料以及凌晨 2 点在 Stack Overflow 上搜索的答案来了解 Slurm。
你的集群拓扑已针对 Slurm 的算法进行优化：
- 与 Slurm 对胖树拓扑的理解相匹配的网络配置
- 反映组织层级的分区结构
- 在局部性和公平性之间平衡的节点分组
切换调度器不是重新编译，而是一次重组。
承诺与模式
NVIDIA 表示 Slurm 将保持开源且供应商中立，而 GPL‑v2 许可证本身就使得闭源在法律上存在问题，因此 SchedMD 现有的客户不会被切断。
但对路线图的控制不同于对代码的控制。
- 当 NVIDIA 优先考虑功能时，哪种硬件会首先获得一流的 Slurm 支持？
- 当性能优化发布时，哪些 GPU 能受益最大？
- 当 Slurm 与 NVIDIA 其他软件栈的集成日益紧密时，“供应商中立”的承诺是否意味着对 AMD 和 Intel 加速器同等优化？
这种模式在企业软件中屡见不鲜：
- Oracle 并不阻止你使用 MySQL。
- Microsoft 并不阻止你在非 Azure 云上使用 GitHub。
然而，集成点、打磨程度以及性能优化往往倾向于所有者的产品。
NVIDIA 官方的说法强调，Slurm “构成了全球开发者、研究机构和云服务提供商用于运行大规模训练基础设施的关键基础设施”，这确实如此——而现在 NVIDIA 已经拥有了这项关键基础设施。
Source: …
分布式差距
传统的 HPC 调度——无论是 Slurm 还是其竞争者——都假设一种特定的架构：一个大型、中心化的集群，作业在节点之间调度，使得优化问题成为在统一系统内将作业匹配到资源。
当 数据与计算共址 时，这种架构运行良好，训练作业从高速并行文件系统读取，模拟在已预置到本地存储的数据集上运行，使得集群本身成为一个独立的世界。
但世界正在改变
- 数据主权要求 意味着数据集并不总能移动到 GPU 所在的位置。
- 边缘部署 产生的数据不应仅为进行推理而跨网络传输。
- 联邦学习 需要在各机构之间协调训练，而不将敏感信息集中。
- 多云策略 将计算分散在不同的提供商、地区和架构上。
Run:AI 通过基于 Kubernetes 的编排提供帮助，但前提是使用 Kubernetes；Slurm 支持 HPC 工作负载，但前提是传统的集群架构。两者都未解决以下问题：
“我有 50 个地点的数据，12 种不同配置的计算资源，以及阻止我把它们当作一个大集群的监管约束。”
NVIDIA 的收购加强了向中心化的引力：更大的集群、更多的 GPU，要求把你的数据带到我们这里。这对许多工作负载而言是有效的架构，对超大规模的基础模型训练来说可能是唯一的架构。
但它 并不是唯一重要的架构，真正分布式计算的编排缺口仍然广阔。（我们有一些想法，如果你感兴趣 :)）
NVIDIA 实际理解的内容
致谢: NVIDIA 了解了全局，… (内容续)
NVIDIA的行动手册：掌控编排层
硬件竞争吸引了大家的注意——AMD 的 MI300X、Intel 的 Gaudi、Google 的 TPU，以及筹集数亿美元打造定制硅片的初创公司——让所有人都聚焦在芯片上。
NVIDIA 把视角提升到上层，认识到 谁掌握编排层，谁就掌控了哪些芯片运行哪些工作负载的决定权。调度器不仅仅是分配资源；它还编码了关于存在哪些资源以及如何使用这些资源的假设。
通过收购 Slurm 和 Run:AI，NVIDIA 确保无论你使用哪种范式（传统 HPC 还是云原生 Kubernetes），调度 GPU 工作负载的软件层都来自 NVIDIA。换句话说，CUDA 的替代方案仍然需要通过 NVIDIA 的编排来运行。这就像同时拥有道路和红绿灯：车辆可能不同，但都在同样的交叉口停下。
这对其他人意味着什么
现有 Slurm 用户
- 短期内变化不大。
- 软件仍然是开源的。
- SchedMD 的支持合同预计会继续。
- 那些围绕 Slurm 工作建立职业的 40 名员工现在已成为 NVIDIA 员工，预计拥有 NVIDIA 的资源。
构建 NVIDIA 硬件主导地位替代方案的开发者
- 形势变得更加严峻。
- 您的新加速器需要软件生态系统的支持，这现在意味着要么：
- 说服 NVIDIA 所拥有的 Slurm 将您的硬件视为一等公民，或者
- 从头构建自己的编排层。
思考集群模型之外分布式计算的任何人
- 信息很明确：主要厂商并未为您构建。
- 真正分布式、异构、尊重数据重力的部署所需的编排层在他们的产品组合中并不存在。
这既是挑战 也是 机遇。
护城河
- CUDA 护城河 – 真实、可见、持续被讨论，并且是竞争能量的焦点。
- 编排护城河 – 较为低调，因为 Slurm 没有像 GPU 那样成为头条，调度软件也不“性感”；它只是实际决策发生的地方。
想了解智能数据管道如何降低你的 AI 成本吗？
或者不看。我有什么资格告诉你该怎么做呢？
注意： 我目前正在写一本关于机器学习数据准备的真实世界挑战的书，聚焦于运营、合规和成本方面。
I’d love to hear your thoughts
最初发布于 Distributed Thoughts.