大家好啊，我是 jianpeng。今天和大家聊一下芯片研发集群，以及 LSF、OpenLava、Slurm 等调度系统。
验证团队要跑几千个不同 seed 的回归，后端团队需要一台大内存机器做布局布线，签核阶段又多出一批 STA 分析角。这些任务都需要算力，运行方式却不一样。
回归往往能拆成大量独立作业；综合和布局布线更关注单机 CPU、内存与线程；STA、DRC、LVS 则涉及分析角、分块和前后依赖。具体并行方式由工具决定，调度器负责把资源安排好，并持续跟踪任务。
比较集群系统之前，应先明确研发任务怎样组织。AWS 的半导体 Slurm 技术文章也是从工作流和算力波动讲起，再解释调度器怎样满足这些需求。[2]
下面这张图把提交、调度、执行和结果连起来。重点看调度层怎样把任务送到普通 CPU、大内存或其他合适的节点。
平时说的“LSF 集群”“Slurm 集群”，通常就是按调度系统给整套计算环境起名。IT/CAD 还要把存储、网络、工具和用户管理接进来。
以下每个系统单独一章，分别说明功能与优势、开源或商业属性、适用规模，以及具体的芯片研发场景。
一、LSF：让多个项目共用算力
LSF 是商业软件。 IBM Spectrum LSF 将作业调度、项目资源政策和企业支持放在同一套体系中，尤其值得已有 LSF 工具链的团队关注。[3]
下面的架构示意图梳理了 LSF 的作业提交、调度管理和执行节点之间的关系。
mbatchd 管理队列、作业状态和派发，mbschd 负责调度决策；执行节点负责运行任务，并反馈作业状态与负载信息。[28]
成批回归可以统一管理。 作业数组把同一脚本的不同输入组织成一组，还能限制并发；作业依赖可以衔接编译、仿真与结果汇总，减少逐个提交和查询的工作。[4]
项目之间可以按规则分配。 队列、优先级、公平共享、抢占与回填，用来落实团队约定：日常回归分享资源，关键签核任务优先，大任务等待时让合适的小任务利用空档。[5]
资源池也能继续扩展。 CPU、内存和主机条件帮助任务找到合适机器；MultiCluster 支持集群协作，Resource Connector 则用于接入和释放外部弹性资源。许可证感知可按需要加入配套组件。[6]
LSF 的优势是把这些能力整合起来，共同服务多项目运营。IBM 的 Cadence 案例就把本地与云资源用于芯片设计、系统验证和 EDA 工具开发。[7]
LSF 适合优先纳入中大型、多团队、多站点或混合云平台的候选，覆盖 RTL 回归、综合/P&R、STA 和 DRC/LVS。小集群也能用，是否值得采购要结合现有流程与服务需求判断。
二、OpenLava：延续熟悉的批处理方式
OpenLava 是开源项目，具有早期 LSF / Platform Lava 的技术背景，保留了 bsub、bjobs 等命令习惯。[8]
下面的架构示意图展示了 OpenLava 从提交作业到分配计算节点的基本过程。
OpenLava 的主要调度逻辑与队列管理集中在 mbatchd，计算节点上的 sbatchd 负责本地作业，LIM 提供主机负载信息。它与现代 LSF 的组件划分并不相同。[29]
它的基础能力可以从三件事理解：队列与负载选机负责分发作业；资源表达式描述机器条件、资源需求和放置方式；作业数组与依赖把不同 seed、参数和前后步骤组织起来。
例如，CAD 可以用统一入口让工程师提交一组仿真，等编译完成后再运行，并控制并发数量。交互式批处理和可重运行选项，也为调试和特定恢复策略提供了基础。
它的吸引力是操作模型容易被已有 LSF 风格环境理解，同时源码可读、可修改。这里的“熟悉”指命令和概念，不表示与现代商业 LSF 的全部行为相同。
OpenLava 可在小型、任务稳定的计算集群或存量环境中评估，用于独立仿真、参数扫描、编译测试。原项目与衍生分支的来源、补丁和维护责任需要明确；现有资料不足以给出可靠的统一推荐节点数。
三、Slurm：把多类计算放进一个资源池
Slurm 是开源软件，也可采购 SchedMD 商业支持。 它面向 Linux 集群，既能组织 EDA 批处理，也能承载其他 HPC 任务。[9]
下面的架构示意图展示了 Slurm 的提交入口、控制服务与计算节点分工。
slurmctld 管理资源分配，节点上的 slurmd 负责执行端管理；可选的 slurmdbd 将记账信息写入数据库。srun 还会与执行端交互，不能将所有命令都理解成同一条通信路径。[30]
数组与依赖适合回归、PVT 和参数扫描：一个脚本按索引选择输入，限制同时运行的子任务，再衔接后处理。提交、队列查询与历史查询也有清楚的工具分工。[10]
CPU、内存和 GPU 资源管理让不同任务找到不同节点。普通回归、大内存实现任务，以及工具支持的 MPI/GPU 计算，可以进入同一平台，而不必各自维护一套机器清单。
账户、QOS、公平共享与记账用于落实项目政策并查看资源消耗。回填则尝试利用大任务等待期间的空档，合理的资源与运行时限申请会影响效果。[11]
Slurm 的优势是资源模型清楚、开源生态成熟，并能统一多类计算。AWS 的 ParallelCluster 半导体方案还展示了与弹性云资源配合的路径。[2]
规模可从小型 Linux 计算池到大型 HPC。Frontier 有接近一万计算节点的 Slurm 部署参照，体现大型系统管理能力，不能直接换算成 EDA 短作业吞吐。[12] 适合有 Linux/HPC 运维能力、愿意维护 CAD 封装的团队。
四、SGE / Grid Engine：按任务需要组织计算集群
Grid Engine 同时有开源和商业发行版。 SGE 通常指历史 Sun Grid Engine；现在还要分清开源 OCS、商业 GCS 或 Altair Grid Engine 等具体产品。[13]
下面的架构示意图用于理解 Grid Engine 的作业提交、集中管理和节点执行流程。
图中以现代 Grid Engine 发行版为例，调度线程位于 qmaster 内；作业下发到执行主机后，由 execd 和作业对应的 shepherd 管理执行。逻辑上的“调度器”不一定是独立进程。[31]
Grid Engine 通过三组功能组织计算任务：数组与依赖管理重复任务，适合仿真、测试向量和参数扫描；资源属性（complex）描述内存、机器特征与站点资源；并行环境（PE）定义槽位如何分配，再与工具的进程启动方式衔接。[14][15]
例如，同样申请多个 slots，一个工具可能只需要单机多线程，另一个才支持跨机器。把 PE 与启动脚本对齐，CAD 才能准确表达任务如何使用分到的资源。
它的优势是批处理模型直接、资源属性可配置，也能延续已有的 qsub 工具链。共享策略还能按项目份额和使用历史安排资源。
Grid Engine 可列入部门级到大型工程计算集群的候选。当前维护方描述了少量主机到数千节点的覆盖范围，但要绑定具体发行版，不能套用到所有历史 SGE 分支。[13]
对已有 Grid Engine 流程、主要运行回归、编译和参数扫描的团队，持续改善这套平台本身就可能是合适选择。
五、Volclava：字节跳动的开源调度器
Volclava 是字节跳动开源的项目，基于 OpenLava 2.0。 它与后面的 Volcano 是两个系统。官方推荐用于少于 100 节点、调度性能要求不高的小规模集群。[16]
下面的架构示意图展示了 Volclava 的作业提交、调度与状态查询流程。
作业提交和派发仍由 mbatchd 主线处理。启用查询分流后，部分查询可由查询子进程处理；这条可选路径不会替代主服务的调度职责，默认也不开启。[32]
公开版本的改进主要落在三个方面。批量提交把多条作业提交打包，适合一组回归或参数扫描，减少重复交互。[17]
查询与通信优化包括可选的查询子进程分流和 epoll 通信处理。经常由工程师或监控程序查询状态的团队，可以结合查询负载评估；分流功能需要配置启用。
资源规则与记录更清楚：队列和作业请求可以整合并展示有效结果，峰值及平均内存记录帮助调整后续申请；esub 扩展则用来接入站点提交规范。[17]
Volclava 的优势是保留 LSF 风格入口，并改进提交、查询和资源信息这些日常操作。适合官方推荐范围内的回归集群、编译测试和参数扫描，也适合希望统一资源申请的小型 CAD 平台。
“少于 100 节点”是推荐条件，不是硬上限。是否符合自己的需求，还要看提交频率、排队量和查询压力，不能由字节公司的基础设施规模推导这个项目的规模。
六、Volcano：在 Kubernetes 上组织批处理任务
Volcano 是开源的 Kubernetes 批处理系统。 对已有 Kubernetes 平台、计划容器化部分研发计算的团队，它提供了另一种组织方式。[18]
下面的架构示意图梳理了 Volcano 在 Kubernetes 中组织批处理任务的组件关系。
官方图展示了准入校验、控制器、调度器与 Kubernetes 资源之间的关系。控制器管理作业生命周期，调度器选择执行节点；实际容器运行由 Kubernetes 的节点机制承担。[33]
VolcanoJob 与 Gang 调度管理多角色任务、数量与生命周期，让需要协同启动的成员在满足最小条件后再推进。它适合分布式训练、MPI 等协作任务；独立回归用例通常可以分别调度。[19]
队列共享与调度政策负责多团队分配：配置资源保障、容量、借用与回收，再结合优先级、公平共享和回填安排任务。
异构资源、拓扑与框架集成则服务更丰富的负载。已有 Ray、Spark、MPI 或 PyTorch 任务时，可以沿用 Kubernetes 的 API、部署和监控体系。[18]
优势就在于批处理能够接入既有云原生平台。芯片研发可评估的对象包括容器化回归、验证日志分析、研发数据处理和设计空间探索中的算法训练，具体工具仍要满足目标运行环境。
已有多团队共享的 Kubernetes 计算池，可以结合现有容量评估。官网锐天案例披露过200 个计算节点，但它是金融计算案例，不能写成 EDA 性能成绩。[20] 平台容量还要结合任务形状与控制面能力判断。
七、PBS：兼顾日常批处理与并行计算
OpenPBS 是开源软件，PBS Professional 是商业产品。 两者有共同技术背景，仍要按具体版本确认交付功能与支持方式。[21]
下面的架构示意图梳理了 PBS 的作业提交、调度决策和节点执行流程。
pbs_sched 作出调度决策，pbs_server 协调作业下发，执行主机上的 pbs_mom 管理任务。pbs_comm 位于通信层，负责消息路由，并不承担额外的调度决策。[34]
数组作业与依赖把同脚本、不同输入的任务组织起来。PBS Professional 用户指南直接将 EDA 仿真列为数组应用场景，适合仿真、PVT 和参数扫描。[22]
资源请求与放置策略可以描述所需资源块与分布方式，既服务单机大内存作业，也能为应用真正支持的跨节点计算安排资源。公平共享、回填与记账再帮助多个项目共用平台。
Hooks 扩展接口允许管理员在提交、执行等节点加入站点逻辑，例如检查申请、补充环境或执行规则，让 CAD 规范进入日常流程。[21]
它的优势是批处理与并行资源模型完整，也提供开源自维护和商业交付两种选择。已有 PBS 经验，或者 EDA 与电磁、热分析等 CAE 任务共池时，尤其值得评估。
规模覆盖小型到大型 HPC。Aurora 的 10,624 个计算节点使用 PBS Professional，为商业产品提供超万节点科研案例；这不是任意 OpenPBS 安装的容量保证。[23]
八、Accelerator：让大量 EDA 作业快速周转
Altair Accelerator 是面向 EDA 与 HPC 的商业调度软件。 它主要服务任务数量多、周转频繁的研发环境。[24]
下面的架构示意图展示了 Accelerator 怎样衔接作业提交、调度政策和执行资源。
vovserver 维护资源和作业状态并分派任务，计算节点上的 vovtasker 启动、管理作业并回报状态。图中的任务分派方向与网络连接发起方向不同：tasker 本身也是连接服务端的客户端。[35]
事件驱动调度在提交、完成和资源变化时触发处理，相同调度条件的任务归入 bucket。面对大量重复回归，这种组织方式减少了重复处理相同条件的工作。[24]
公平共享、优先级、抢占和预约帮助协调日常回归与关键签核任务。CPU、内存、主机条件和 NUMA 控制，则让任务匹配到合适资源。
Jobclass保存可复用的提交设置，方便 CAD 为常用工具准备统一入口。需要峰值算力时，还可结合 Rapid Scaling；Annapurna Labs 的官方案例展示了芯片前后端流程与弹性 CI 的应用。[25][26]
它的优势是围绕 EDA 任务周转，将调度响应、项目政策和提交规范结合起来。适合中大型、任务多且周转频繁的研发计算集群，涵盖 RTL 回归、编译/CI、后端实现、签核和云端扩容。
厂商方案页描述过 5 万以上计算核、50 万以上排队任务。前者是资源量，后者是待处理工作量，不能改写成节点数或同时运行量。[27]
九、怎样按研发任务选择集群
八类系统的适用性，需要结合日常研发任务判断。下面五类任务重点涉及批量分发、单机资源、流程依赖与多节点协同；同样数量的服务器，面对这些负载时，调度压力也会不同。
下表汇总各系统的属性、适用规模和研发场景，用于筛选候选；不同单位的案例数字不宜直接比较。
| | |
|---|
| | |
| | |
| | |
| | |
| | |
| | |
| OpenPBS 开源；PBSPro 商业；小型至大型 | |
| | |
选型可以从一份作业清单开始：任务类别、CPU/内存、运行时长、每天提交量和前后依赖。再结合团队已有的脚本与运维经验，以及开源控制力或商业支持的需求，选择两三个系统深入比较。这样，每项调度功能都会对应到一件具体的研发工作。
引用链接
- 1. 芯片研发计算集群选型：LSF、Slurm 等八类调度系统详解
- 2. AWS：用 ParallelCluster 建设半导体 Slurm 集群
- 6. IBM：MultiCluster；Resource Connector
- 8. OpenLava 原始说明保留版本；bsub 手册
- 13. HPC-Gridware：GCS/OCS；产品规模定位；Altair Grid Engine
- 14. Oracle：任务提交；资源属性；调度策略
- 19. VolcanoJob；队列资源管理；调度框架
- 21. OpenPBS；PBS Professional 管理指南
- 22. PBS Professional 用户指南
- 23. ALCF：Aurora 概览；作业运行与 PBS
- 24. Accelerator：调度方式；功能导读
- 25. Accelerator：Jobclass；硬件资源；NUMA
- 26. Altair：Annapurna Labs 芯片设计云端案例
- 29. OpenLava 原始 mbatchd / sbatchd 手册；LIM 手册
- 31. Altair Grid Engine 组件与调度线程；HPC-Gridware 架构说明
- 32. Volclava 查询分流说明；客户端请求处理代码
- 33. Volcano 官方架构与原图；官方图源与许可证；Kubernetes 组件
- 34. PBS Professional 安装指南：服务与通信组件；PBS 编程指南
- 35. Altair Accelerator 运行原理；Taskers
