同一集群里，有的算力服务器排满任务，有的设备却长期空闲，原因未必是硬件性能不同。常见问题在任务调度和资源分配：任务申请量与实际需求不符、队列规则限制了可运行节点，或任务虽然启动，却没有充分使用分配到的设备。排查时应先找出负载不均发生在哪一层，再做小幅调整。
先区分“没分到任务”和“分到后没用满”
先记录一段有代表性的繁忙时段，观察每台算力服务器的 CPU、加速卡利用率、显存占用、内存和网络吞吐，同时查看队列中等待任务的数量。若设备利用率持续偏低、队列里仍有任务等待，重点检查调度条件；若任务已运行但利用率低，则应检查程序是否受数据读取、CPU预处理或通信速度限制。
利用率没有适用于所有任务的统一合格线。可把连续约10至15分钟明显低于同类任务的情况作为初筛信号，再结合任务阶段判断：模型加载、保存结果时利用率下降可能正常，持续计算阶段低迷才更值得追查。单看平均值容易掩盖短时空闲或个别设备过载。
按顺序检查任务调度与申请资源
- 核对队列和节点状态。若使用 Slurm，可用 squeue 查看等待与运行任务，用 sinfo 查看分区和节点状态，再用 scontrol show job 查看具体任务的资源要求及等待原因。重点检查分区、账户、节点特性等限制是否把任务锁定在少数机器上。
- 比较申请量与实际使用量。查看任务申请的 CPU 核数、内存和加速卡数量，并与运行期间的实际占用对照。申请过多可能造成资源碎片：例如一台机器剩余资源足以运行小任务，却因每个任务要求整组资源而无法放入。申请过少则可能让程序争抢内存或 CPU，拖慢处理。
- 检查设备绑定和任务并行度。确认分配给任务的设备确实被程序使用，多进程或多卡任务也要检查进程是否均匀落到设备上。可先用一个代表性小任务测试不同并行配置，比较耗时、利用率和资源占用；不要仅为提高数字而盲目增加进程。
- 排除计算之外的瓶颈。若加速卡占用不高、CPU或存储读写却繁忙，检查数据是否逐批加载、是否重复读取，以及预处理是否跟得上计算。此时增加加速卡通常不能直接解决问题，调整数据缓存、读取并发或 CPU 配额可能更有效。
- 小批量验证，再修改规则。先选少量相似任务调整资源申请或队列约束，比较任务等待时间、完成时间和节点间负载。确认改善后再推广；保留调整前后的配置，便于发现是否把拥堵从一个分区转移到了另一个分区。
根据调度方式选择排查入口
批处理集群：先看队列规则
Slurm 常用于批处理计算场景，适合检查分区、作业优先级、资源请求和节点可用状态。对等待任务，可结合 squeue 与 scontrol show job 的信息判断是资源不足，还是约束条件过窄。若使用 sacct，可回看已结束任务的资源记录；统计口径受集群配置影响，应与运行时监控交叉核对。
容器编排场景：关注资源声明与设备分配
Kubernetes 场景中，检查 Pod 的资源请求与限制、节点标签、污点及设备插件分配情况。资源请求会影响调度落点，声明的加速设备数量也不等于程序实际用满。与 Slurm 的批作业队列相比，Kubernetes 更需要同时核对 Pod 状态、节点可调度性和容器内程序表现，避免只根据节点总利用率下结论。
常见问题
利用率高就代表分配合理吗？
不一定。高利用率可能伴随显存不足、任务排队或完成时间变长，应同时看吞吐、等待时间和失败情况。
空闲设备很多，任务为什么仍在排队？
可能是任务申请的资源组合不匹配，或分区、节点标签、优先级等条件限制了可选节点。先查看调度器给出的等待原因。
应该先加机器还是先改配置？
若现有设备因队列约束或资源碎片未被有效使用，先调整任务调度与资源申请更合适；若任务持续排队且现有节点已被合理利用，再评估扩容。算力服务器的排查结论应以实际任务表现和资源记录为依据。
