排队的不一定是许可证，但所有人都把它当许可证问题

仿真许可排队这事，十个人里有九个第一反应是“买少了”。采购那边一被催，就去加买两套solver，加完管三个月，下个项目节点一到，照样排。钱花了，队还在排。你不能说他们错，但根子往往不在数量上，在你根本没分清到底是谁在等什么。

仿真任务“卡住”至少有三种死法，混在一起看永远看不清。第一种是许可证拒斥（denial） ，license server日志里写得明明白白，DENIED，拿不到token，任务连启动都启动不了。第二种是算力排队，许可证拿到了，但集群节点满了，Slurm里PENDING reason写的是Resources，跟license没关系。第三种最隐蔽，许可证在等一个根本不需要等的东西——比如Abaqus提交Job前先去预借token，结果前处理阶段就把token攥在手里，求解器还没开始跑，别人已经进不来了。你把这三种混成一个“排队久”，后面所有的动作全是盲打。

还有个更底层的事得先说清楚：仿真许可的计量单位不是“一套软件”，是token。Abaqus/Standard单核起步就是5个token，每加一核并行再吃1到2个，一个8核的Explicit任务一口气干掉12到15个token不稀奇。ANSYS那边，HPC Workgroup按核线性吃，HPC Pack是指数级打包，1个Pack扛8核，2个Pack扛32核，3个Pack扛128核。你不按token去算需求，按“谁装了软件”去判断够不够，永远对不上账。

先别急着动调度，把日志拆开看一眼

摸底这件事不需要上工具，lmstat和license server的debug log就够用。FlexNet的日志里DENIED事件带着时间戳、用户、feature和请求数量，你按小时聚合一下，就能看到拒斥到底集中在哪个feature、哪个项目组、哪个时间段。然后拿这张表和集群调度器的PENDING reason对一遍——如果DENIED高的时段和Resources PENDING高的时段不重合，说明许可证和算力是两个独立的瓶颈，你优化其中一个，另一个照样卡。

第二步，把会话持续时间分布拉出来。仿真许可最操蛋的浪费不是“没人用”，是“打开了不关”。有人Workbench挂着过夜，有人Abaqus/CAE开了一整天只改了俩参数，GUI进程和求解器进程抢同一个token池。你光看峰值并发觉得池子刚好够，实际上里面至少两成token被僵尸会话焊死了。FlexNet的心跳默认三分钟一次，超过五分钟没心跳才回收，这个阈值在桌面工作站场景下太长了。先把这个问题认清楚，再谈买不买。

调度能解决的事，别用采购预算去补

任务分级不是搞个“高优先级”“低优先级”两个QoS就完事了。工业仿真里真正的分级是按token消耗量和可延迟性切的。一个128核的CFD批量扫参任务，token消耗能顶几十个前处理会话，它凭什么跟交互式建模抢同一个池子？把大批量、可延迟的求解任务强制走夜间提交窗口，白天只留交互式前处理和中小规模调试的容量，这是最朴素也最有效的错峰。不需要什么高级算法，Slurm里一个begin time约束加QOS就能做。

并行核数上限是另一个该焊死的东西。普通仿真任务卡在4核，高优先级放宽到8核，超了要审批。工程师不是故意的，他只是觉得“多给核跑得快”，但多给核吃的是token，不是免费的算力。你把并行上限拿规则锁住，许可证池的周转率立刻上一个台阶。

还有抢占这件事得泼盆冷水。Slurm本身不直接支持因为“许可证不可用”去抢占低优先级作业，你配了QOS Preempt也未必按你想的方式生效。所以别把希望全押在调度器的抢占上，更稳妥的做法是按项目或部门给token配额，软限额提醒、硬限额卡死，让一个项目组在节点前把整个池子抽干这种事从规则上就不可能发生。配额不是公平问题，是防雪崩。

容量预测靠的是节点日历，不是年度平均值

仿真排队的本质是脉冲式需求。一个汽车研发中心，下午两点到四点Abaqus占用率能顶到95%，一天剩下二十个小时使用率只有15%到25%。你拿月均利用率去跟老板说“还有空间”，节点一到全组干瞪眼。容量分析的起点是项目节点日历：下一轮碰撞仿真、下一轮热管理评审、下一轮工艺验证，各自什么时候要多少token、多少核时，提前四周跟项目经理对一遍，而不是等DENIED飙了再去翻日志。趋势比单点有用，至少覆盖一个完整项目周期，淡季的平均值专门用来骗人。

一个厂子里的真事

某汽车零部件厂，结构仿真用Abaqus，热管理用ANSYS Fluent，两套license server各管各的。问题出在每个项目节点前两周，Abaqus的Explicit token被8核以上的大任务吃到见底，小规模的Standard验证任务全堵在DENIED里。采购的方案是加买两套Abaqus token包。IT多留了个心眼，先把license日志和Slurm的PENDING reason对了一遍：DENIED集中在Explicit的feature上没错，但并发峰值离授权上限还有距离，真正的问题是几个常驻的Explicit会话挂在那儿不释放，加上一批Standard任务申请了8核并行但实际只跑4核的活，白吃token。动作不复杂：Explicit会话闲置45分钟强制回收，Standard的并行核数默认锁4核、超4核要走审批，大批量扫参任务挪到晚上十点后自动提交。一个季度后再看，Explicit的DENIED降了七成多，白天交互式任务的排队时长缩了一半，一套新token没买。ANSYS那边更冤，Fluent的HPC Workgroup许可被几个几千核的粗网格试算瞬间抽干，后来用调度器把超过128核的作业强制导向HPC Pack，Workgroup池子留给中小任务，拒斥直接归零。这事从头到尾没什么高明技术，就是把“谁在等、等什么、为什么等”拆开看了一遍。买许可是最贵的那种懒。