这两年接到的咨询里，有一类明显在变多：实验室或者研发部门原本手里只有三五台工作站，活儿排不开了，想升级成一个"能排队、能记账、能多人共用"的小集群。然后第一个卡住他们的问题不是买什么机器，而是——用不用上 Slurm。这东西在超算那边是标配，可在十来台机器的场景里，它到底是解决方案，还是新的麻烦源？我们这一篇就把话说明白：Slurm 管什么、不管什么，一套能跑起来的集群要怎么拆角色，硬件六个维度该怎么选才不交学费，以及那些真正烧钱踩过的坑。
先给几条可以直接抄走的结论：
Slurm（Simple Linux Utility for Resource Management）本质是一套资源管理器加作业调度器。你把一堆机器交给它，它就负责回答三个问题：谁先跑、跑在哪台、跑多久。听起来朴素，但落到多人共用环境里，这三件事每一件都是吵架高发区。
没有调度器的集群，真实运行状态往往是这样的：A 同学在群里问"昨天谁占了 3 号机"，B 同学说自己周一到周三要用全部内存，C 同学偷偷在晚上起了一个 40 核的作业把机器烧到凌晨。资源没有被恶意抢占，但也没有任何秩序，真正的浪费发生在"大家都不敢提交大作业，怕影响别人"这件事上。Slurm 干的就是把这个社交协调过程变成机器规则：你提交作业，它按优先级排好队，分配具体的 CPU 核、内存、GPU，到时间就杀，跑完就记账。
分区（Partition）是把硬件按类型或者按用途切开的一组节点，可以简单理解成"队列"的物理载体——比如把带 GPU 的机器划到 gpu 分区，把大内存的划到 fat 分区。作业（Job）是一次申请，作业步（Job Step）是一次作业内部可以被单独记账的执行单元，一个跑 MPI 的任务通常就是一个作业下挂着若干个步。QOS（服务质量）是在 CPU、内存这些资源配额之外，额外套一层"限速器"，限制单个用户或单个账号最多能用多少资源、单个作业最长能跑多久。记账（Accounting）由 slurmdbd 配合数据库完成，把每个作业的资源消耗写进库里，这是公平份额（Fairshare）能生效的前提——没有记账数据，Slurm 不知道谁用多了谁用少了。回填调度（Backfill）是个很讨巧的机制：为了让大作业能起，调度器会预留资源，但等待期间如果有小作业能塞进空档而不影响那个预定时间点，就让它先跑，集群整体利用率因此明显抬高。
这句话我们在方案沟通里说过不止一次，哪怕我们自己卖机器。
如果集群规模在 5 台计算节点以内，用户就那么三五个人，作业之间基本不冲突——比如一个人跑 CFD、一个人跑渲染、一个人做数据处理，各自固定在自己的机器上——那 Slurm 带来的收益非常有限，而它带来的维护成本是实打实的：你要维护 MySQL/MariaDB、要维护 slurmdbd、要同步所有节点的配置文件和用户体系、升级时还要考虑版本兼容性。这几件事每一件都能让一个不专门做运维的老师头疼半天。这时候一个简单的 Excel 排班表加几行 SSH 脚本，效率比一套装歪了的 Slurm 高得多。
反过来，下面几个信号出现任何一个，就该上了：用户数超过十个并开始互相抱怨资源；有不同类型的硬件需要按类分配（比如只有一部分机器有 GPU）；需要"公平"——比如多个课题组共同出资买了这批机器，必须证明谁用了多少；作业运行时间超过几小时，需要断点续跑和可靠的排队；或者你在混合 AI 训练和传统 HPC 作业，两边抢同一批节点的优先级问题必须有人裁决。一句话，Slurm 解决的是"多人、多类型、需要长期秩序"的问题，规模不是唯一判据，冲突强度才是。
一套最小可用的 Slurm 集群至少要有四类角色，它们可以物理合并，但逻辑职责必须分清。
控制节点上跑 slurmctld，负责所有调度决策。另外通常还会跑 slurmdbd（记账守护进程）和它背后的 MySQL 或 MariaDB。slurmctld 本身对硬件要求不高——它不吃 CPU 也不吃内存，几百个节点的集群用一台普通双路机器就够——但它的可靠性要求极高。它挂了，正在跑的作业一般不会立刻死（slurmd 会继续干活），但新的作业排不进去、状态查不了、作业也管不了，实际效果就是集群停摆。所以生产环境里至少要做冷备：把配置、状态目录和数据库定期同步到备用机，必要时手动切过去。有条件就配高可用（比如用 Keepalived 加共享状态存储），成本不高，买的是心理安宁。
登录节点是用户唯一应该直接接触的机器，作业在这里编译、在这里提交、在这里看结果。它不参与计算，所以别把它算成算力。登录节点的常见坑是"用户顺手在上面跑程序"——一旦有人在登录节点跑了重活，所有人交互命令都会卡。做法是给登录节点的 shell 加资源限制，或者干脆用 cgroup 把它的 CPU 和内存框住。规模稍大的环境会把"提交节点"和"登录节点"分开，前者只跑 sbatch/srun，后者供人 SSH 进来编辑、编译。
计算节点上跑 slurmd，它是真正执行作业的进程。一台机器的 slurmd 挂了，Slurm 会把这台节点标记成 down 或 drain，排队的作业自动绕开——这是 Slurm 最有价值的能力之一，也是它对"机器总有一台会坏"这件事的默认假设。但这里有个前提容易被忽略：所有节点的用户 UID/GID 必须完全一致。如果你的集群是用本地账号（passwd/shadow 手工同步）而不是 LDAP 这类集中认证，那么新增一个用户就要在所有节点上重复一遍，漏一台就意味着这个用户提交到那台机器的作业会以诡异的权限错误失败。规模上到二十台以后，本地账号基本就是自找麻烦。
共享存储可以是软件方案也可以是独立节点，NFS 是最容易起步的选择，规模大了会转向 Lustre、GPFS、BeeGFS 这类并行文件系统——后者在聚合带宽和元数据性能上是另一种量级，但也意味着专门的运维投入，这里只定性提一句，具体能跑出多少聚合带宽取决于盘数、网络和配置，任何脱离环境报出的数字都不可信。至于要不要把"管理网络"和"计算网络"分开：管理的意思是 SSH、监控、NTP、Slurm 心跳；计算的意思是 MPI 通信和文件读写。二十台以内、作业不算通信密集型，一张万兆网通常够用；上了通信密集型的求解器或者节点数再翻倍，就该考虑管理网独立，避免一次大规模数据落盘把 SSH 都挤掉。
选 CPU 之前先问一句：你的求解器是怎么并行的。
CFD、显式动力学这类以显式时间推进为主的求解器，单个时间步要在整个网格上做显式推进，本质上是串行走时间轴的，它对单核主频和内存带宽最敏感，核数堆到一定程度加速比就掉得很难看。这类场景应该优先买主频高、内存通道多、单路或双路核心数中等的机器。反过来，反过来，渲染农场、蒙特卡洛、参数扫描、基因比对这类作业（行话叫 embarrassingly parallel，意思是这些作业之间几乎不用互相说话，尴尬到不需要通信），一个帧一个进程、一个样本一个进程，谁也不理谁，那核数就是硬通货，主频低一点完全能接受，性价比反而更好。蛋白结构预测里的某些阶段、以及大量 AI 数据预处理，也属于吃吞吐的那类。
AVX-512 能显著加速部分数值密集 kernel，但它带来的功耗 spike 会让 CPU 在运行这类指令时自动降频，而同一块 CPU 上跑着没用 AVX-512 的其他作业时，也会被连坐降频。这在"一台机器同时塞好几个作业"的共享集群里尤其尴尬：一个做向量化优化的同学把整机的频率都拉下去了。解决办法不是禁用 AVX-512，而是在分配层面让作业按核绑定（--cpu-bind），把能共享核的作业按亲和性摆好；实在理解不了降频影响，就在采购时跟供应商的工程师明确沟通你的 workload 类型，让他给建议。别怕问——问了不亏，不问就得自己熬夜排查性能抖动。
这一段请慢点看，因为踩坑率最高。
绝大多数 HPC 集群的失败配置不是 CPU 不够快，而是"每台机器 128 核却只配了 64GB 内存"，每核分不到 0.5GB，任何一个稍微大一点的网格就 OOM。常见的经验区间是这样的：渲染和参数扫描这类轻内存作业，每核 2GB 左右比较从容，也就是一台 64 核机器配 128GB；通用 CAE/CFD、生物信息的比对环节，每核 4GB 上下是安全区，64 核对应 256GB；大型隐式求解、超大网格、以及一些需要在内存里装下完整模型的场景，每核 8GB 甚至更高都不算奢侈。另外，永远给机器本身留余量——操作系统、文件系统缓存、突发的元数据操作都要吃内存，把 100% 都分给用户是危险的。
同一颗 CPU，插满内存通道和不插满，性能能差出肉眼可见的一截。双路机器每颗 CPU 通常支持多个内存通道，采购时务必确认配置是"满通道"插法。举个具体的错法：一台机器买了 256GB，但只用了 8 条内存插在其中一部分通道上，容量看着到位了，带宽却是残的，跑 CFD 的同学会觉得"这机器怎么这么慢"，然后怀疑是 CPU 选型错了。判断这类问题不用高深工具，用内存带宽基准跑一遍，对比同型号满插机器的公开数据就能定位。
不管硬件配多足，系统层面也必须设边界。Slurm 里应该启用内存作为可分配资源（SelectType 配 CR_Core_Memory 之类），并给每个作业或每个 QOS 设定 --mem 或 --mem-per-cpu。这样作业超内存会被调度器杀掉而不是把整机拖到 swap 里卡死——后者是一个节点从"变慢"滑到"失联"再到"上面所有作业全挂"的过程，通常发生在凌晨三点。
集群里的 I/O 大致分三种：读输入、写临时中间结果、写最终结果。前两种量大但不要紧，最适合放在计算节点本地的 NVMe 上，跑完就丢，术语叫"scratch"。这么做有两个好处：一是本地盘的吞吐和延迟远好于任何网络存储，二是脏数据不污染网络。本地盘的要求很简单——容量够放下一个作业的中间文件、写不坏的可靠型号，不需要最贵。真正要精心规划的是共享存储：它放的是所有人的家目录、程序、输入数据和最终结果，是集群唯一必须"持久化且所有人可见"的部分。
长时间作业的 checkpoint（断点保存）是所有共享存储的压力测试。假设二十个作业同时把自己几十 GB 的状态写出去，那一刻的并发写带宽需求是平时的几十倍。轻量的做法是给 checkpoint 目录单独挂一个存储池，并在 Slurm 里限制并发 checkpoint 作业数量；重一点的做法就是上并行文件系统，把数据和元数据分散到多个存储节点上。这里不报具体性能数字——NFS 到底能扛几个并发写，取决于你的 NFS 版本、网络、后端磁盘阵列和下层 RAID，脱离环境讲数字没有意义。要紧的是在采购前做一次真实压测：起你预期最大规模的并发作业，写一次真 checkpoint，看延迟曲线，别等新课题进场第一天才发现。
最后一句老生常谈但必须说：共享存储的可用性是全集群的单点。至少做定期快照、异地备份或者双副本，同时确认"快照隔多久一份、回滚要多久、回滚期间服务是什么状态"。这一条与各家的产品政策直接相关，签约前问清楚写进合同。
很多人以为搞 HPC 集群就得先拉一条很粗的外网。这是误会。Slurm 发出的都是小报文，说的全是"你去这台机器""作业结束了""节点还活着"，几百个节点加起来也不占多少。真正能把带宽榨干的是三件事：多人同时往共享存储写 checkpoint、作业跑完把几十上百 GB 结果拉回本地工作站、以及 AI 训练场景里数据集的反复读取。换句话说，带宽要配在计算节点到存储这一侧、以及存储到外部下载这一侧，而不是管理网络上。这也是为什么"内外网应当分离"在 HPC 里是常识：内网互联负责作业通信和存储读写，外网只承载交互和结果下载，两者各走各的路，互不干扰。
如果你跑的是密耦合求解器（跨节点的 MPI 通信非常频繁），那真正决定加速比的是网络延迟和它的一致性，而不只是带宽数字。这也是为什么 HPC 通常会考虑 InfiniBand 或 RoCE 这类低延迟组网方案，配合支持 RDMA 的网卡——RDMA 说白了就是让数据绕过 CPU 直接从一台机器的内存进另一台机器的内存，少走两次搬运，延迟和 CPU 占用都降下来。如果你的作业基本是"各算各的，最后汇一下"，那这套投入就未必值，普通的万兆以太网足够，把省下来的钱加到 CPU 和内存上更划算。
这一段最容易被忽略，但它是"买回来上不了架"的直接原因。
机房给你的是一份"每安培多少钱"的账单，本质上是限制你这台服务器能拉多少电。常见的起步档是 10A 或者 16A 每机柜（按 220V 算，大约对应 2.2kW 和 3.5kW 的量级），普通 1U/2U 机器放几台没问题；可一台装了八张高性能 GPU 的训练服务器，满载功耗往往就要三四千瓦起步，双路高频 CPU 加满内存的计算节点单台也轻松到五六百瓦往上。把这些机器塞进普通机柜，要么上架被拒，要么被强制降功率运行。高密机柜（功率密度更高的机架）单价自然比普通柜位贵，但你别无选择——除非你把负载摊到更多低配机器上，而那又会让你的加速比和软件授权成本变得更难看。
我的建议是：先确定目标机型满载功耗，再确认目标机房能提供的单柜功率上限，最后反过来确认一柜能放几台、总共要几个柜。这个顺序如果做反了，你会经历"机器已经付款发货、机房说放不下"的经典悲剧。另外，GPU 满载时吹出的千瓦级热量不是玩笑，风道设计、冷热通道隔离、以及必要时的液冷方案，都要在这一步一起定。液冷在功耗优化上的收益，行业公开的参考区间大致在节省电费两成到四成（预估，以实际账单为准），但它的前提是有机房侧的配套，不是你租台机器就能自动享受。
一个常见的误区是给每个课题组划一个分区。这在短期能让大家感觉"公平"，但长期一定造成资源碎片——A 组的机器闲着 B 组排队，物理上明明有空闲算力却跑不了。正确的画法是按硬件和作业特征分组：gpu、fat（大内存）、short（短作业通道）、long（长作业通道）、serial（串行小作业）。然后给每个分区设置节点归属和访问限制，让"谁能用什么"通过 QOS 和账号来控制，而不是通过固化硬件所有权。
公平份额（Fairshare）的逻辑是：历史上用得越多的人，接下来优先级越低；用得少的人优先级往上抬。它是一个随时间衰减的动态值，所以新人不会因为来得晚就被永久压着。没有公平份额的集群，结局往往是一个人用一个大作业占满全队列，其余人排队几小时甚至几天。配置上要盯的是衰减窗口（Half-Life）设得太长会让历史欠账拖很久，太短又让"公平"变得过于即时，一般按集群作业周期的一到两周左右起调，跑一个月看实际排队分布再微调。
如果你给分区设了最大运行时间（比如 48 小时），就必须同时给用户提供 checkpoint 机制，否则那些需要跑一周的作业会被硬杀，用户会想尽办法绕开限制——最常见的绕法是拆成一堆小作业反复重排，反而更浪费。反过来，如果允许无时限作业却不要求写 checkpoint，一次硬件故障就是几天的算力损失。我们的建议是：长时限分区强制要求作业时申明 checkpoint 路径，短时限分区用来跑那些本来一两天就结束的任务。
GPU 在 Slurm 里通过 GRES（通用资源）管理。配置得当之后，GPU 就不再是"谁先 SSH 上去谁用"，而是可以被申请、被记账、被独占分配的正规资源——比如一个作业申请两块 GPU 时，调度器会保证这两块卡在作业运行期间不会被别人分走。这里最容易被忽略的是模式绑定：同一台机器上的 GPU 用不用同一种分配模式（独占 vs 共享），直接决定这块资源能不能被多个作业切分。要做细粒度的 GPU 共享或切片，得先确认你的硬件和驱动层支持哪种切分方式，再在 GRES 配置里对应起来，别指望调度层凭空造出一小块显存。
抢占（Preemption）是让高优先级作业把低优先级作业踢下去的机制，听着很爽，但代价不小：被抢占的作业如果不支持 checkpoint/resume，就是白跑。所以它最值得开的场景是两类——一是明确的教学/演示作业被生产作业抢占（被踢掉不可惜），二是短期的高优先级任务需要立刻拿到资源且对方支持续跑。而在"大家都跑长任务、都不写 checkpoint"的集群里开抢占，等于给自己制造一群愤怒的用户。要不要开，取决于你的作业可恢复性，而不是取决于你有多想要这个功能。
硬件一定会有坏的。Slurm 的价值在于它能自动把坏节点摘出去（drain），后续作业不再分配。但已经跑在上面的作业怎么办？这就体现出应用层容错的必要性：MPI 作业最好用支持节点失败续跑的实现，长任务必须定期 checkpoint，或者在作业提交脚本里捕获失败信号并自动重排。别指望调度器替你做这些——它只知道"进程没了"，不知道"这个模型重跑要不要从头来"。
所有节点的时钟必须同步到同一个源。这件事的重要性被严重低估：记账数据要靠时间戳，跨节点的日志要靠时间戳对齐才能排查 MPI 通信问题，有些调度逻辑和许可证管理机制本身就对时钟漂移敏感。SSH 卡顿、日志前后颠倒、任务莫名超时，很多时候查到底就是 NTP 没配好。做法很简单，所有节点配同一个内部 NTP 源，控制节点对上游校时，其余节点对控制节点校时，定期检查偏移。
作业超时或者用户 Ctrl-C 之后，进程不一定真的走了。尤其是某些 MPI 实现或者调用了外部程序的脚本，主进程死了，子进程还在机器上吃 CPU，而 Slurm 认为这个资源已经被释放并分配给下一个人了——新作业一上去就和幽灵进程抢核，性能掉一半还说不清为什么。解决办法是在 Slurm 里配合 cgroup 限制（TaskPlugin、Prolog/Epilog 清理脚本），保证作业结束或超时后，属于这个作业的所有进程被彻底回收。这一步非常便宜，但很多人直到被投诉才发现没做。
Slurm 跨大版本升级时的配置文件兼容性、数据库 schema 变更、以及与旧版 slurmd 的通信协议差异，都可能一次性把集群搞瘫。稳妥做法是先在两三台测试节点上验证，再滚动升级。另外一个现实问题：Slurm 本身不管认证，用户体系要你自己解决。规模一旦上去，LDAP/FreeIPA 这类集中认证几乎是必选项，把 UID/GID 全局统一，顺便把家目录权限和 SSH key 分发的流程理顺。
下表把搭建 Slurm 集群常见的几类租用形态放在一起比一遍。价格相关的部分我们严格按来源分两类：官网明示价标注"以官网实时价为准"，推算价标注"（预估，以实际账单为准）"。
| 用途 / 形态 | CPU 与内存档位 | 网络与内网互联 | 机柜功率密度 | GPU 可选性 | 价格（月，含口径标注） |
|---|---|---|---|---|---|
| 控制 / 登录 / 提交节点 | E5-2620 级单路，内存按需，负载极轻 | 千兆/万兆内网互联即可，调度流量很小 | 常规 10A/16A 柜位即可 | 一般无需 GPU | 裸金属 E5-2620 ¥999（官网价，以官网实时价为准） |
| 通用计算节点（双路） | E5-2698v4×2，核数导向，建议每核 4GB 左右起 | 建议万兆内网互联，管理网与作业网可分可合 | 常规功率，密度取决于单台满载功耗 | 可选 RTX3080 ¥1080 等（官网价） | 裸金属 E5-2698v4×2 ¥3999 起（官网价，以官网实时价为准） |
| GPU 计算 / 混合分区节点 | 多路 CPU 配大内存，注意内存插满通道 | 建议低延迟组网（RDMA 类方案需具体咨询） | 满载功耗高，需确认单柜功率上限 | T4 ¥900 / V100S ¥1500 / A100 40G ¥2800 / RTX3090 ¥1750（官网价） | 按卡型计费，以官网实时价为准 |
| 弹性 GPU 切片（调试 / 小占比作业） | 按需申领，跑小作业与预处理 | 共享内网互联，带宽按所持配额 | 由平台侧承担 | A100 1/20 切片 ¥900、A16 1/16 ¥210（官网价） | 按切片计费，以官网实时价为准 |
| 8 卡 GPU 整机（大模型训练 / 重渲染） | 双路旗舰 CPU，大内存，本地 NVMe 做 scratch | 节点内高速互联 + 跨节点低延迟组网 | 必须走高密/高功率机柜，先问后下单 | 8 卡整机型，H100 等整机方案 | H100 8卡整机月 ¥8–12 万（官网价，以官网实时价为准）；8卡A100 80G 月 ¥2.5–4万（预估，以实际账单为准） |
| 大陆地域起步参考 | 依具体机型而定 | BGP 多线等，按机房而定 | 按各机房实际供电条件 | 视节点是否开放 GPU | 起步参考：华西 ¥599 / 华东 ¥699 / 华南 ¥799 / 华北 ¥899（官网价，以官网实时价为准） |
如果你第一次搭 Slurm，我一般会先推这套当主力计算节点：E5-2698v4×2 双路，裸金属形态，官网 ¥3999 起（以官网实时价为准）。它核数够、价格可控，用来跑 CFD、渲染、参数扫描、生物信息比对这一类吞吐型作业非常顺手。裸金属的好处是没有虚拟化层抢资源，调度器看到的就是真实硬件，部署 slurmd 时少一层幺蛾子。真要说经验的话：先把三五台跑通 Slurm 的全部链路（提交、记账、故障摘除、重排），确认流程没问题了，再横向加机器。机器数量永远比单机性能容易补。
如果你的团队是"AI 训练与传统 HPC 混跑"，那我更推荐把两类资源分开来管理：训练侧上稳定的 GPU 整机或者按需的 A100 40G ¥2800、RTX3090 ¥1750、T4 ¥900 这类整卡（均为官网价，以官网实时价为准），确保长训练任务独占；开发和调试侧用 A100 1/20 切片 ¥900 或者 A16 1/16 ¥210 这种小切片（同样为官网价），省钱也能跑通流程。这两批资源都注册进同一个 Slurm 集群，通过不同的 partition 和 QOS 管起来，做到"谁也不能饿着、谁也不能独吞"。一万网络在深圳南山深耕 IDC 19 年（成立于 2007 年），自营机柜上架快，硬件故障有自动迁移机制，加上 BGP 多线覆盖华南、华东、华北等多个节点，你要是团队成员分布在全国各地做异地协同，这种多节点的部署自由度会比较实用。
为什么坑：slurmctld 挂掉之后，正在运行的作业虽然能继续算，但新作业排不进去、状态查不了、作业取消和调度全停。更恶心的是 slurmdbd 和数据库如果在同一台机器上一起挂，记账数据还可能丢一段，公平份额直接失准。
怎么避：至少做冷备——把 Slurm 的配置目录、StateSaveLocation 和数据库定期同步到备用机，并演练一次切换流程（演练这一步最常被跳过，真出事时才发现备份的数据格式对不上）。预算允许就做高可用。同时把操作系统盘快照用起来，回滚比重装快得多。
为什么坑："128 核配 64GB"这种配置在纸面报价单上特别诱人，单价看着特别低，但真跑起来 CFD 或者大基因组比对，作业起几十分钟后在内存峰值崩掉，用户会把账算到集群头上。更隐蔽的是整机被拖到 swap 里，节点从慢变成失联，连带杀掉上面的其他作业。
怎么避：先按作业类型定每核内存区间（渲染类约 2GB、通用仿真约 4GB、大模型隐式求解 8GB 往上），并在采购前用真实算例压一次峰值内存；同时在 Slurm 侧把内存设成可调度资源，让超内存的作业被杀而不是拖垮机器。
为什么坑：多人同时写 checkpoint 是共享存储最凶险的一刻。单台 NFS 在小规模下很安静，一旦并发上来了，写延迟飙升是小，元数据服务阻塞是大，最坏的结果是所有人作业卡住、超时，然后集体重排，形成雪崩。
怎么避：把 scratch 和 checkpoint 尽量下沉到计算节点本地 NVMe，只有必须持久化的东西走共享存储；给 checkpoint 目录单独规划容量和带宽，在调度层限制同时写 checkpoint 的作业数量；规模往前走的时候提前评估并行文件系统，并做一次真实并发压测。
为什么坑：这是唯一一个改不回来的坑——CPU 不够可以加机器，内存不够可以加条，机柜功率不够意味着你得换柜、换楼层甚至换机房，时间成本和迁移成本都很大。八卡 GPU 服务器和高密度双路机器的满载功耗远超普通 1U 机器的想象。
怎么避：下单前把目标机型的满载功耗（不是标称 TDP，是实测满载功耗）列出来，找服务商确认单个机柜能给到多少安培、单柜总功率上限是多少、有没有高密/高功率机柜选项、价格怎么算。顺序必须是"先问功率再下单"，反了就等着吃瘪。
为什么坑：默认配置下的 Slurm 基本是"先到先得"，第一个甩上去一个"用全部节点、跑三天"的作业的小组，会让后面所有人的排队时间变成以天计。时间一长大家就开始跑关系、占机器，集群秩序直接退回到没有调度器的状态。
怎么避：上线第一天就把 QOS 建好：限制单用户同时运行的作业数和总核数、限制单作业最大时长、按账号设配额；同时启用 slurmdbd 记账和公平份额，并定期检查 fairshare 的实际分布。资源是买来的，规则是设计出来的。
为什么坑：用户按了 Ctrl-C、作业超时、程序崩溃退了一半，都可能留下还在吃 CPU 的子进程。而 Slurm 认为资源已经释放并分给了下一个人，新旧两个进程在同一批核上打架，新作业性能腰斩，排查起来还特别费劲。
怎么避：启用 cgroup 相关的任务插件，让 Slurm 能可靠地回收属于某个作业的全部进程；配 Epilog 脚本做节点级别的残留清理；给所有分区设默认 Walltime，防止无限期占用；再加一个简单的巡检——定期看有没有属于已结束作业的残留进程。
看规模和自己能接受多大风险。十来台以内的集群，把 slurmctld、slurmdbd 和数据库都塞在一台不上业务的机器上是完全可以的，甚至可以和登录节点合体——只要这台机器别被用户当算力用。但一旦上了二十台、或者集群停半小时会有人打电话给你，那就该单独拆出来。它不是算力瓶颈，slurmctld 本身资源消耗很低，关键是"没人去折腾它"和"有地方能恢复"。我做过的项目里，出问题的控制节点几乎都是因为有人顺手在上面编译程序或者跑数据导致的。所以拆机不是为了性能，是为了隔离人为扰动。
异构完全行，而且很常见。Slurm 天生支持不同配置的节点，你只要用 node 定义里的 CPU 数、内存、Features 把机器描述清楚，再用 partition 分区分组就行了。实际上很多课题组就是逐步攒起来的：第一批买了双路 E5，第二批上了新一代平台，第三批加了 GPU 机器，混着跑很正常。真正需要注意的是两件事：一是版本一致性——MPI、编译器、数学库的版本要在共享存储上统一管理，别让用户在自己机器上装出三种 OpenMPI；二是作业的可移植性——编译时的优化选项如果针对某代 CPU 做了激进优化，挪到老机器上可能直接非法指令。混跑之前先做一轮兼容测试。
起步用 NFS，够用且好维护，别一上来就上重量级方案。判断要不要换的信号是有客观迹象的：一是并发 checkpoint 时几个作业一起写，延迟明显飙升到影响作业本身时间；二是元数据操作（大量小文件创建、列出、删除，比如生物信息里几百万个碎片片段）明显卡；三是聚合带宽需求超了单套存储能提供的量。这三个信号出现任意一个，就该认真评估并行文件系统或者把热点数据拆到多个存储池。具体能跑多少带宽、多少 IOPS，跟你用的盘、网络、NFS 版本和后端阵列强相关，任何脱离你实际环境报出来的数字都不要信，压一把真实作业最准。
核心做法是把两类资源拆成不同的 partition，然后用 QOS 和账号做配额。举个具体的：给 AI 组一个 gpu 分区并限制单用户可以同时占几块卡、单个作业最多多久；给仿真组一个 cpu 分区限制总核数；再加一个允许大家都能用的通用分区来吃碎片资源。公平份额要打开，否则抢占窗口期会让某一组长期吃不到东西。另外强烈建议对长训练任务做 Resume 的支持——模型训练天然有 checkpoint，恢复起来容易，所以它在 Slurm 里的优先级策略可以设计得更灵活。混跑不难，难的是提前把规则讲清楚写下来。
盯四件事：单柜给多少安培、单柜总功率上限多少、能不能提供高功率/高密度机柜、以及超额部分怎么计费。另外要问清散热方式——风冷能不能压住你这种满载功耗，如果压不住，有没有冷热通道隔离或者液冷方案。还有一个很实操的点：上架前是否支持实测功耗，能不能给你一个明确的"这批机器按这个配置放进来，功率上没问题"的书面确认。这些问题问出来不丢人，反而是内行的表现。机器买回来上不了架，是所有问题里最难看的那个。
有可能，但可控。风险点主要在三个地方：新版的配置指令可能改了名字或者默认值变了，导致 slurmctld 起来报错； slurmdbd 背后数据库的 schema 需要升级，没做备份就升，账本可能回不去；旧版 slurmd 和新版 slurmctld 之间的通信协议是否兼容，通常官方会说明支持跨几个版本。稳妥做法是：先在两三台不重要的节点上升，验证作业提交、记账、节点恢复都正常，再滚动升级其余部分；升级前务必备份配置文件和数据库。别在结题或者大作业高峰期做升级，这是常识但每年都有人违反。
渲染农场其实是 HPC 调度场景里比较独立的一支：作业量大、单作业短、几乎不需要节点间通信，对调度器的考验主要在吞吐（每小时能调度多少个作业），而不是某种复杂的全局一致性。Slurm 完全能做，而且它的 backfill 回填机制对"一堆短作业和一两个长作业混排"特别友好。对渲染农场来说，真正要注意的反而不是调度器，而是三件小事：一是许可证（license）能不能被多个作业正常获取并收回，二是输入输出路径在各节点必须一致（挂同一个共享存储），三是抢占 worker 时要温柔些，让正在渲的帧渲完再下线节点。这三条做好了，Slurm 跑渲染农场很稳。
我的排序是：内存 > 共享存储的可靠性 > 网络 > CPU 主频。理由很实在——CPU 慢一点只是算得久，内存不够是作业直接崩，共享存储挂了是全组停工，网络差则取决于你的作业类型是不是密耦合。真正不要急着花钱的是"管理面的花哨功能"：一开始不需要特别复杂的图形门户或者计费系统，把 slurmctld、slurmdbd、共享存储和 NTP 这几样做扎实，比什么都强。等人真的多了、机器真的超十台了，再考虑上 Web 门户、镜像管理之类的周边。预算有限就先保证机器健康地一直跑着。
Slurm 解决的是人和人之间抢资源的问题，不是"让机器变快"的问题——搞清楚这一点，你能省下至少一半预算。真正决定一个 HPC 集群好不好用的，是那些看起来毫无技术含量的东西：每核内存给够、控制节点有备份、home 目录有备份、checkpoint 有地方写、机器时钟有人同步、僵尸进程有人清。这几件事听着土，但它们决定你的集群是"能用三年"还是"三个月后没人愿意用"。我们的建议一向是先小规模跑通整套流程——从提交到记账到故障重排——然后按作业类型的真实负载加机器。硬件可以晚点买，规则必须从第一天就有。
本文涉及的一万网络产品形态与价格口径，参考自官网公开页面：https://www.idc10000.net/ （含裸金属服务器、GPU 服务器租用、AI 算力云与 GPU 定制等栏目）。文中官网明示价如 E5-2620 ¥999、E5-2698v4×2 ¥3999 起、RTX3090 ¥1750、RTX3080 ¥1080、T4 ¥900、V100S ¥1500、A100 40G ¥2800、A100 1/20 切片 ¥900、A16 1/16 ¥210、H100 8卡整机月 ¥8–12 万、大陆地域起步价（华西 ¥599 / 华东 ¥699 / 华南 ¥799 / 华北 ¥899）等，均以官网实时价为准；涉及推算部分如 8 卡 A100 80G 月 ¥2.5–4万等，一律标注为预估价格，以实际账单为准。HPC 集群软件、网络协议与硬件选型建议为通用技术经验分享，不构成性能承诺。具体配置可用性、节点资源、带宽费用与合同条款，均以签约时最新报价与合同为准。
Copyright © 2013-2020 idc10000.net. All Rights Reserved. 一万网络 科技有限公司 版权所有 深圳市科技有限公司 粤ICP备07026347号
本网站的域名注册业务代理北京新网数码信息技术有限公司的产品
