核心结论

IBM LSF 的优势不在于“某个调度算法比 Python 排序高级”，也不在于用什么编程语言，而在于它把调度实现成了一个经过长期生产验证的分布式资源操作系统：

• 同时管理 CPU、内存、GPU、软件许可证、主机属性、队列和项目配额；
• 在公平性、吞吐量、紧急程度、大作业等待时间和资源利用率之间动态权衡；
• 持久化跟踪每个作业的完整生命周期；
• 在管理节点、执行节点或网络发生故障后恢复状态；
• 支持全球多集群、云端弹性扩容、审计与企业级运维。

对于芯片设计，LSF 恰好解决了最昂贵、最棘手的几个问题：海量验证任务、超大内存签核任务、昂贵而细粒度的 EDA license、流片前的突发算力需求，以及跨地域设计团队之间的资源争夺。

“LSF 是事实标准”应当稍微严谨地表述为：

LSF 不是 IEEE、JEDEC 那样的正式标准，也没有公开、权威的全球市场份额证明它垄断市场；但它确实是大型商业 EDA Computing Farm 中最主流、生态兼容度最高的调度器之一。AWS 的半导体参考架构直接称其为 “the most popular job scheduler in EDA”。与此同时，Slurm、Grid Engine、PBS 等仍被采用，所以它不是唯一选择。AWS EDA reference architecture

---

一、先定义与 IT 自研平台的比较基线

这里把“Python 简易调度平台”假定为：

数据库保存任务
→ Python 服务扫描待运行任务
→ 根据 priority / FCFS 排序
→ 查看服务器 CPU、内存是否空闲
→ SSH、Agent 或 subprocess 启动作业
→ 收集退出码和日志
→ 失败后按规则重试

这类平台在以下环境完全合理：

• 几十台机器；
• 单一或少量任务类型；
• 数十到数百并发任务；
• 用户和部门之间没有复杂权益关系；
• CPU/内存是主要资源；
• 故障后允许人工处理；
• 平台团队能控制所有提交入口。

但随着需求增长，自研平台通常会逐步加入数据库锁、资源租约、心跳、调度策略、配额、抢占、许可证、主备切换和多集群。此时它已经不再是“Python 脚本”，而是在重新开发一个 LSF/Slurm 类系统。

所以真正应该比较的是：

成熟分布式调度系统与自研分布式调度系统，而不是 IBM 产品与 Python 语言。

---

二、LSF 的核心架构原理

LSF 把控制面和执行面分开：

用户/EDA Flow
     │ bsub
     ▼
mbatchd：作业、队列、状态与事件管理
     │
     ▼
mbschd：资源过滤、策略计算、主机选择
     │
     ▼
执行节点 sbatchd：启动、监控、信号控制、状态回报
     ▲
     │
各节点 LIM → 管理 LIM：收集负载和资源状态

一次调度大致经过：

资格检查
→ 作业优先级与 Fair Share 排序
→ 资源需求过滤
→ 用户/项目/队列/主机限制检查
→ 并行资源、预留和回填计算
→ 必要时抢占
→ 选择执行主机
→ 派发
→ 持续监控和记账

IBM 文档说明，mbatchd 将候选作业交给 mbschd，后者根据作业优先级、调度策略和资源状态选择主机；资源信息由各节点 LIM 汇总提供。IBM：LSF job lifecycle

这比一个定时运行的 Python while True 循环多出的关键能力是：

• 一致的状态模型；
• 调度决定与执行状态闭环；
• 事件持久化；
• 节点代理与进程控制；
• 故障后的状态重建；
• 多种策略在同一决策点统一执行。

---

三、Fair Share 的技术原理

1. 它不是平均轮流，也不是硬配额

假设组织给三个部门配置：

AI 验证部门：60 shares
物理设计部门：30 shares
IP 团队：10 shares

这通常不是把集群永久切成 60%/30%/10%。

当后两个团队没有作业时，第一个团队可以借用空闲资源；等其他团队重新产生需求，之前大量使用资源的团队会因为历史消费较高而降低动态优先级。

因此它同时实现：

• work-conserving：有工作时尽量不让资源闲置；
• entitlement：长期资源分布接近组织约定；
• anti-starvation：避免用户或队列长期拿不到资源。

2. 动态优先级是反馈控制

LSF 10.1 默认公式可以简化表示为：

\[P_u = \frac{S_u}{ C_uF_c+ R_uF_r+ (1+J_u)F_j+ A_uF_a+ G_uF_g }\]

其中：

• $S_u$：用户或用户组的 shares；
• $C_u$：带时间衰减的历史 CPU 消费；
• $R_u$：当前作业累计运行时间；
• $J_u$：正在使用和预留的 slots；
• $A_u$：插件提供的内存等附加成本；
• $G_u$：GPU 当前及历史消费；
• $F_*$：不同资源的权重。

默认情况下，最近的 CPU 消费影响更大，较早的历史会衰减；作业开始后动态优先级逐渐下降，作业结束后回升。IBM：Dynamic user priority

这本质上是闭环反馈：

获得资源
→ 资源消费增加
→ 动态优先级下降
→ 其他用户更容易获得资源
→ 作业结束或历史衰减
→ 优先级逐渐恢复

而常见 Python 调度器只有开环排序：

jobs.sort(key=lambda j: (-j.priority, j.submit_time))

它不会自动补偿过去的资源消费。

3. 层级公平对应真实组织结构

芯片公司的权益结构通常不是平铺用户：

SoC 项目
├── CPU 子系统：40%
│   ├── RTL：50%
│   └── Verification：50%
├── GPU 子系统：35%
└── IO/IP：25%

LSF 可以先在项目之间分配，再在项目内部按团队或用户分配。否则，一个有 500 名工程师的部门会天然压过只有 30 人、但组织份额相同的部门。

Fair Share 还能配置在：

• 单个队列内；
• 跨队列；
• 主机分区；
• 用户或用户组；
• 队列之间；
• 多层用户组结构。

IBM：Fair share scheduling

---

四、LSF 相对自研平台的技术优势

能力	常见自研平台	LSF 原理
公平性	FCFS、静态优先级、硬配额	动态用量、时间衰减、层级 Fair Share
资源模型	CPU、内存	CPU、内存、GPU、许可证、动态及自定义资源
并行作业	手工找 N 台机器	多节点 slot、compound requirements、拓扑约束
大作业等待	容易被小作业持续挤压	资源预留 + backfill
紧急任务	排队或直接 kill	suspend、resume、requeue、checkpoint、preemption
防止资源超售	读取实时利用率	声明需求、reservation、allocation limits
高吞吐短任务	中央调度器容易成为瓶颈	job array、chunk、分层 Session Scheduler
故障恢复	依赖数据库和自研状态修复	事件日志、节点代理、主节点接管、状态重建
跨地域	多套平台或自研转发	MultiCluster、job forwarding、云端弹性节点
运维与审计	自研报表和日志	pending reason、accounting、历史报表、RTM
生态集成	每个工具写 adapter	大量 EDA/HPC 工具已有提交模板和集成

1. 多维资源匹配

LSF 作业资源条件不仅是“需要 8 核”：

8 CPU
+ 128 GB 内存
+ 特定型号主机
+ 某个软件版本
+ 2 张满足特定属性的 GPU
+ 4 个 EDA license feature
+ 本地 scratch 空间

它还支持并行作业中不同组件具有不同需求，例如 master rank 使用更多内存，其他 rank 使用普通节点；也可以表示多组替代资源条件。IBM：Resource requirements

CPU 和内存亲和性还能精确到：

• NUMA；
• socket；
• core；
• thread；
• CPU binding；
• 本地内存绑定；
• pack 或 distribute。

IBM：Affinity string

这对大内存布局、时序分析和多线程 EDA 工具会直接影响性能。

2. Reservation 防止内存超售

实时监控值存在滞后。例如作业声明需要 100 GB，但刚启动时只用了 5 GB。如果只看当前可用内存，调度器会继续派发其他作业，最终导致 swap 或 OOM。

LSF 使用：

\[available = current\ reported\ value - resources\ already\ reserved\]

把“已经承诺但尚未实际消耗”的内存也扣除。IBM：Resource reservation

简易平台如果只读 /proc/meminfo 或 psutil，很容易在作业启动增长期过量派发。

3. Reservation + Backfill 解决大作业饥饿

大型签核作业需要 20 台大内存节点。如果每次释放一台机器就被小作业拿走，大作业可能永远凑不齐资源。

LSF 会：

1. 为大作业规划未来资源；
2. 计算预计启动时间；
3. 允许短作业临时占用这些预留资源；
4. 前提是短作业能在预留时间前结束。

\[now + estimatedRuntime_{small} \le reservedStart_{large}\]

这同时降低空闲率并保护大作业。IBM：Backfill scheduling

4. 抢占是完整状态转换，不只是杀进程

高优先级 tape-out 作业可以抢占普通回归测试。LSF 可配置：

• 挂起低优先级作业；
• 恢复；
• 重新入队；
• 终止；
• 从 checkpoint 恢复；
• 抢占 slot、GPU、内存或自定义资源；
• 抢占多个作业，直到满足新作业的完整资源向量。

IBM：Preemptive scheduling

Python 平台很容易发送 SIGKILL，但要安全实现 suspend/requeue/checkpoint，还需处理进程树、容器、许可证释放、状态记账和重复执行。

5. 高吞吐任务使用层级调度

芯片验证经常生成几十万到数百万个相似任务。如果每个 5 秒任务都经过中央调度、网络派发和进程初始化，调度开销可能超过计算时间。

LSF Session Scheduler 的办法是：

中央 LSF 一次分配一批资源
→ 在该分配内部启动轻量 task scheduler
→ 连续复用节点执行大量短任务

IBM 文档称 Session Scheduler 面向大量短任务，可在一个会话内处理最多 50,000 个短任务，并把单任务调度从中央控制面下沉。IBM：Session Scheduler

这是典型的层级调度：全局层保证组织政策，局部层优化派发延迟。

6. 故障恢复

LSF 把提交、队列变化、主机变化和作业状态写入事件日志。管理主机失败后，候选管理主机可以接管并询问各执行节点，重建正在运行的作业状态。

执行主机失败时：

• rerunnable 作业重新排队；
• checkpointable 作业从检查点恢复；
• 其他主机的作业不受影响；
• pending 作业继续保留。

IBM：Fault tolerance and automatic management host failover

自研平台要达到这一水平，需要实现：

• 持久化事件或状态机；
• 幂等派发；
• 心跳与失效检测；
• fencing，避免双主调度；
• 执行节点状态对账；
• 孤儿进程处理；
• 重启后资源重新计算。

---

五、为什么 LSF 特别适合芯片设计

1. EDA 同时包含两种截然不同的负载

前端验证通常是：

• 大量独立仿真；
• 参数扫描和回归测试；
• 单任务中短时；
• 总任务数极大；
• 适合 job array、chunk 和高吞吐调度。

后端和签核可能是：

• P&R、STA、DRC/LVS；
• 单任务运行数小时或数天；
• 极高内存和 I/O；
• 多线程或多节点；
• 失败重跑代价很高。

普通平台往往只对其中一种优化。LSF 可以用不同队列、应用 profile 和策略同时管理二者。

公开案例显示，IBM 自身的 EDA 环境曾覆盖七个站点、超过 40,000 个处理器，每年运行超过 1.5 亿个 grid jobs；这些作业在大小、紧急程度和资源消耗方面差异很大。IBM EDA case study

Cadence 的公开案例则描述了约 10,000 名工程师、五个主要数据中心以及每月数百万作业的规模，并使用 LSF 管理本地与 IBM Cloud 资源。IBM：Cadence case study

2. EDA license 可能比计算节点更稀缺、更昂贵

EDA 工具通常通过 FlexNet 等系统，按 feature 发放许可证。例如某个作业可能同时需要：

1 × simulator
4 × parallel_engine
1 × waveform_option
1 × special_IP_feature

只按照 CPU 空闲派发会产生以下问题：

1. 作业占用了 64 核；
2. 应用启动后才发现 license 不可用；
3. 作业在许可证调用处等待或失败；
4. CPU 和内存被白白占用。

LSF License Scheduler 把许可证抽象成可调度 token：

检查 CPU/内存/GPU
+ 检查 license token
→ 都满足才允许启动
→ 启动后应用仍向真实 license server checkout

token 数与真实许可证数对应，可以按用户、项目、集群和层级份额进行分配，也支持跨集群共享和许可证抢占。IBM：License Scheduler

这对半导体公司极其重要，因为优化目标不是单纯提高 CPU 利用率，而是：

\[\text{有效产出} = f(\text{CPU},\text{内存},\text{存储},\text{许可证},\text{截止时间})\]

某些情况下让少量 CPU 暂时空闲，等待正确的许可证组合，反而比启动一个无法继续执行的作业经济得多。

3. Tape-out 前的需求具有巨大突发性

平时集群可能够用，但流片前需要突然增加大量验证和签核能力。永久购买峰值规模会长期闲置；不增加资源又可能错过上市窗口。

LSF MultiCluster 和 Resource Connector 可以：

• 在站点间转发作业；
• 把本地资源池延伸到云端；
• 根据 pending workload 创建云节点；
• 空闲后释放节点；
• 尽量保持原有 bsub、队列和 EDA flow 不变。

AWS 专门发布了 LSF + FSx for ONTAP 的 EDA 混合云参考架构，强调在不改变用户工具和流程的情况下把本地 EDA 集群扩展到云端。AWS EDA reference architecture

4. 芯片项目对公平性的要求不是“人人平均”

临近 tape-out 的项目可能必须获得大部分资源；普通回归仍不能完全饿死；多个部门又有长期预算权益。

LSF 可以把这些不同概念分开：

• Fair Share：长期相对权益；
• queue priority：当前业务优先级；
• preemption：紧急作业回收资源；
• guaranteed pool：对服务类别保证最低资源；
• limits：防止某用户或项目超过上限；
• backfill：利用保证或预留暂时不用的空档。

这种策略正交性比写一个巨大 Python score() 更容易治理。

---

六、为什么会形成“事实标准”

1. 它很早就进入了 EDA Computing Farm

LSF 的历史可以追溯到 Platform Computing 和更早的 Utopia 研究项目。它在 Linux 集群、云计算普及之前，就已解决异构 Unix 工作站的负载共享问题。

芯片公司早期积累的：

• bsub 提交脚本；
• 队列规则；
• EDA wrapper；
• license 适配；
• 监控报表；
• 运维 SOP；
• 工程师使用习惯；

后来都成为沉没成本和兼容性资产。

2. 形成了工具—人员—基础设施的网络效应

当大量客户使用 LSF 后：

• EDA 厂商提供现成的 LSF 提交方式；
• 云厂商发布 LSF EDA 参考架构；
• 存储厂商针对 LSF Computing Farm 优化方案；
• 运维工程师熟悉 bsub/bjobs/bqueues/bhosts；
• 企业内部 flow 默认以 LSF 作业模型为接口；
• 新项目继续采用 LSF 的成本低于迁移。

例如 Ansys Electronics 和 Lumerical 的官方资料直接列出 LSF 集群集成。不过它们也支持 Slurm、Grid Engine、PBS/Torque，这再次说明 LSF 是主流惯例，而不是唯一标准。Ansys HPC integration、Ansys Lumerical scheduler integration

3. 它覆盖了 EDA 最困难的长尾问题

调度器前 70% 的功能并不难：

• 队列；
• 找空闲机器；
• 启动作业；
• 读取退出码。

真正形成壁垒的是后面 30%：

• overlapping user groups；
• 跨队列 Fair Share；
• 许可证 feature 组合；
• 大作业预留和短作业回填；
• 多个限制同时生效；
• 抢占时资源是否真正释放；
• 管理节点切换期间防止重复派发；
• 节点失联后作业究竟是 running、lost 还是 unknown；
• 多站点 WAN 断开时谁拥有作业；
• 数百万作业时如何避免中央调度器过载。

这些能力来自多年真实客户边界条件，而不是单纯算法论文。

4. 商业支持符合芯片公司的风险模型

芯片调度基础设施是生产关键系统。它停摆几小时，可能导致数千名工程师等待；调度错误可能浪费昂贵 license 或延误 tape-out。

因此大型企业重视：

• 明确的产品支持责任；
• 长期兼容与升级路径；
• 紧急问题响应；
• 成熟诊断工具；
• 版本认证；
• 全球部署经验；
• 安全与审计能力。

商业授权虽然昂贵，但与服务器、存储、EDA license、工程师时间以及一次流片失败的成本相比，可能只是较小比例。

5. 路径依赖使替换成本很高

即使另一个调度器的某项算法更先进，迁移仍需要修改和验证：

数千个提交脚本
+ 项目与队列策略
+ license 集成
+ 作业依赖
+ 报表和计费
+ EDA GUI/flow
+ 运维监控
+ 全球站点流程

芯片 flow 强调可重复性。任何基础设施变化都可能影响结果路径、性能、许可证获取或截止时间。在没有显著收益时，企业通常不会在 tape-out 关键链路上更换已经稳定运行的调度器。

这是一种典型的事实标准形成机制：

早期进入
→ 大客户采用
→ 工具商适配
→ 运维人才与脚本积累
→ 云和存储生态继续适配
→ 迁移成本上升
→ 新项目优先沿用

---

七、公开证据能支持到什么程度

支持“广泛使用、主流”的公开证据包括：

• AWS 半导体架构团队明确称 LSF 是 EDA 中最流行的 job scheduler。AWS
• Qualcomm 发表的 KDD 论文描述 LSF 用于其芯片设计资源调度，并称其被多家半导体企业采用。KDD 2016 paper
• Cadence 使用 LSF 管理本地和云端 EDA 计算资源。Cadence case study
• IBM 自身公开了七站点、40,000 多处理器、每年超过 1.5 亿作业的 EDA 使用案例。IBM EDA case study
• Ansys 等工程软件供应商提供直接 LSF 集成，同时也兼容其他主流调度器。

但没有公开且独立审计的当前全球份额数据，因此不宜声称：

• 所有头部芯片厂都使用 LSF；
• LSF 是唯一可选调度器；
• LSF 在所有 HPC 市场都是第一；
• 换成 LSF 必然提升某个固定百分比。

IBM 自身案例曾报告利用率提升约 10%、作业启动从分钟缩短到秒级，但这是特定旧环境与迁移条件下的结果，不应直接外推到其他公司。

---

八、对 IT 运营团队最现实的决策建议

如果自研平台目前只服务小规模、规则稳定的内部任务，没有必要因为 LSF 功能多就立即替换。

当以下条件中出现四到五项时，应该认真评估 LSF、Slurm 或其他成熟调度系统：

• 每天十万级以上作业；
• 多个部门争用同一资源池；
• EDA license 已成为主要瓶颈；
• 大内存作业频繁等待或 OOM；
• 流片前需要云端 burst；
• 需要抢占但不能直接杀作业；
• 管理服务故障后难以恢复真实状态；
• 多站点存在重复建设和资源闲置；
• 自研团队大量时间消耗在调度边界条件；
• 缺少可靠的资源记账、审计和容量规划数据。

评估时不要只看“CPU 利用率”，应该测量：

\[\begin{aligned} &\text{作业排队时间}\\ &\text{端到端周转时间 TAT}\\ &\text{license 空闲率和等待时间}\\ &\text{内存申请/实际使用偏差}\\ &\text{大作业启动时间}\\ &\text{失败与重复执行率}\\ &\text{流片前峰值承载能力}\\ &\text{每次有效验证结果的基础设施成本} \end{aligned}\]

最终，LSF 在芯片行业的地位不是靠某一个神奇算法形成的，而是因为它把资源、许可证、政策、故障、规模和组织治理统一到了同一套生产控制面中，并且很早进入了 EDA 生态。对大型芯片公司来说，真正购买的不是“队列排序”，而是 tape-out 关键路径的可预测性。