实验室公用GPU服务器排期，核心答案就一句话：先用带锁的共享目录加轮询脚本解决眼前冲突，再按任务时长和显存用量切到正式调度系统（如Slurm），规则越透明，大家越省心。这不是技术选型问题，是人情世故和资源分配问题，多数实验室走到第三步就崩了，不是卡在命令上，而是卡在“谁先谁后”的默契上。
为什么你的实验室总是在抢GPU
这几年深度学习框架迭代快，模型参数量从亿级涨到千亿级，单卡显存早就吃紧，实验室几名学生共用一台GPU服务器，最常见的画面是：甲在跑Transformer训练，显存占了80%，乙要测一个批量推荐模型，一看`nvidia-smi`全是红的，只能干等，丙更惨，昨晚提交的`python train.py`还没跑到第一个epoch，早上起来发现进程被OOM killer杀了。
根子在于大家把GPU服务器当成“个人电脑”用了，训练任务本质上是批处理作业有明确的开始、结束时间，有资源需求描述（几卡、多少显存、多少CPU核），但实际操作全是“抢座式”：谁先占上谁用，谁脸皮厚谁用得多，这不叫排期，叫丛林法则。
行业共识是：GPU服务器排期的核心不是“排队”，而是“资源描述”和“时间片隔离”，你连自己任务要几卡、跑多久、峰值显存多少都说不清楚，任何调度系统都没法帮你优化。
排期前先算清三笔账
动手搭调度系统之前，你需要把实验室的实际使用情况摸个底，不用精确统计，大致估一下就行：
- 训练任务类型：是CV、NLP还是推荐系统？不同任务吃显存的节奏完全不一样，CV训练常常前几分钟显存就冲满，NLP推理则是CPU密集。
- 单卡/多卡比例：有多少任务确实要8卡并行，有多少其实单卡就能跑，只是代码里写死了
CUDA_VISIBLE_DEVICES=0,1,2,3。 - 任务持续时长：5分钟就能测完的调参任务，和跑48小时的预训练任务混在一起调度，前者永远吃亏。
把这三笔账算完,你会发现一个扎心的事实：多数任务的显存需求根本没那么高，是代码习惯和默认配置把资源”绑架”了，很多人直接沿用开源项目的默认配置，一上来就申请4卡，实际利用率不到一半。
48小时内的临时排期方案
如果你实验室就一台8卡机器，三五个学生用，不想上重调度系统，用基于文件锁的轮询脚本是最务实的选择，这个方案的核心思路是：不搞复杂队列，只做”按天锁卡”。
共享目录加锁文件
在服务器上建个共享目录，/data/gpu_lock`，每个学生用自己的学生证号或邮箱前缀建锁文件，用`nvidia-smi`查当前显存占用，谁要跑长任务，先写个`.lock`文件到共享目录，里面写明预约时间段和任务描述。
# 伪代码示例
for i in {0..7}; do
if [ ! -f /data/gpu_lock/GPU_$i.lock ]; then
touch /data/gpu_lock/GPU_$i.lock
echo "student_zhangsan 2026-03-12 08:00-20:00" > /data/gpu_lock/GPU_$i.lock
break
fi
done
用crontab每小时跑一次巡检，自动清理超过预约时间还没释放的锁文件，有个小技巧：在锁文件里加入PID字段，巡检时用ps -p $PID判断任务是否还活着，如果进程死了就自动解锁。这套方案能解决70%的冲突，剩下的30%靠微信群吼一声：“我把卡锁到晚上8点，8点后你随便用。”
窗口期的”先到先得”规则
排期不可能做到绝对公平，但可以做到规则透明，行业里通用的做法是：
- 工作日白天（9:00-18:00）自由竞争，谁先占卡谁用，适合做快速实验和调试。
- 晚间和周末（18:00-次日9:00）固定给长任务，按申请顺序排，不开新实验，只跑已验证的训练脚本。
- 每周五下午清理一次报废任务,不给手动杀进程留任何情面。
这个分时段的规则要写进实验室的README.md里，新来的学弟学妹第一件事就是读这个文件。不要靠口头传话，写在代码仓库里的规则才叫规则。
一周内落地的正式调度方案
如果轮询脚本撑不住了（人多了、任务杂了、有人开始不讲武德了），就该上Slurm或K8s + Volcano，这两个方案在高校实验室和中小公司里普及率最高，学习成本低，社区资料全。
Slurm部署的简化路径
Slurm是高性能计算领域的标配调度器，对GPU支持很成熟，部署不需要你从零编译源码，直接用包管理器装：
# Ubuntu/Debian 系 apt-get update && apt-get install slurm-wlm # 配置 /etc/slurm/slurm.conf，关键参数是 GresTypes=gpu
配好slurm.conf后，用scontrol定义一个gpu资源类型，然后用sbatch提交任务，学生只需要学会三个命令：
sbatch train.slurm提交训练脚本squeue查看排队状态scancel取消任务
一份典型的train.slurm脚本长这样：
#!/bin/bash #SBATCH --job-name=train_resnet50 #SBATCH --gpus=1 #SBATCH --time=08:00:00 #SBATCH --partition=gpu #SBATCH --output=train_%j.log python train.py --batch_size 64
用--gpus=1显式声明需要几张卡，调度器会自动分配并隔离，其他人跑nvidia-smi只能看到自己的进程。排队队列一出现，实验室的吵架频率骤降八成，因为优先级和排队时间都是系统算的，不是人吵出来的。
用Fair Share策略防”卡霸”
实验室里总有那么一两个人，一次提交100个任务把队列塞满，Slurm的`FairShare`抢占机制就是为这种人准备的，配置`PriorityType=priority/multifactor`，然后根据学生的历史使用量动态调整优先级：
# slurm.conf 中的关键配置 PriorityType=priority/multifactor PriorityWeightFairshare=1000 PriorityWeightAge=100 PriorityWeightPartition=100 PriorityWeightQOS=100
用sshare查看每个用户的公平份额占比，用得多的用户自动降低优先级。行业共识是：公平调度最重要的不是写代码，是定好权重，你让跑大模型的实验室和专做推理的实验室用同一套权重，很快会失衡。
排期之外的成本核算
很多实验室忽略了GPU服务器排期背后还有个隐藏问题显存碎片化，多个小任务同时跑在8张卡上，每个任务占2~3GB，看起来卡都“有用”，但你想跑个需要20GB显存的大任务时，发现哪张卡都放不下。
按卡计费还是按时计费
如果你实验室接了横向项目，需要在服务器上做成本核算，可以参考云厂商的计费逻辑，但没必要搞得太复杂：
- 按卡时（GPU-hour）计费：一张卡运行一个小时算1个卡时，适合训练型任务。
- 按时段计费：白天高峰时段单价是夜间低峰时段的1.5~2倍，适合推理服务和临时测试。
某高校实验室的公开做法是：每张卡每天收20~30元的“电费和折旧费”，学生用个人课题经费转账到实验室账户。这不是真收费，是逼大家珍惜资源，免费的资源最容易浪费，这是经济学常识。
补卡和扩容的决策依据
排期排到极限了还是不够用，该补卡还是扩容？看两个指标：
- 平均队列等待时间：如果作业平均等4小时以上，说明算力确实不够，可以考虑采购新卡。
- GPU利用率曲线：如果晚上利用率明显低于白天，说明不是卡不够，是排期规则有问题，应该调整时段分配。
选卡建议：实验室预算有限的话，买两张RTX 4090比买一张A100更实用，推理任务显存需求没那么大，训练任务用多卡并行跑也撑得住，据工信部统计，近年来高校实验室的AI计算需求年均增长较快，但采购审批周期长，最好在排期方案里预留扩展接口。
机房服务器排期的进阶玩法
多台服务器联动的排期比单机复杂得多，但实验室阶段通常用不上，如果你实验室有好几台不同型号的GPU服务器（比如一台A100、两台3090），可以按服务器分池管理：
gpu-a100池：给大模型训练和跑长任务gpu-rtx3090池：给快速实验和课程设计gpu-inference池：给线上demo和日常推理
每台服务器的排期策略用不同的脚本或不同的Slurm分区,互不干扰。分池比统一调度更适合异构硬件的场景，因为不同型号的卡跑同一份代码性能差异很大，混在一起调度会浪费算力。
相关问题
实验室GPU服务器排期不准怎么办
“不准”通常指实际跑完时间和预约时间差太多，建议三层处理：第一层，在锁文件或Slurm脚本里写预估时长，跑完自动写日志；第二层，每周统计一次预估vs实际时长的偏差率，超50%的任务统一标记；第三层，在共享目录里放个`wall_time.csv`，让每个人自查，公开数据比任何监督都有效。
多人共用GPU服务器怎么分配最合理
没有绝对公平的方案，只有成本最低的方案。先看任务性质：如果多数任务是短调试（跑5分钟就结束），用排队脚本就行；如果多数是长训练（按小时计），必须上Slurm，再定公平规则：按账号维度统计卡时，每周额度用完即止，下周恢复，某高校实验室实践过：用邮件列表同步排期结果，比任何花哨系统都好使，因为全球通行的调度基准就是“先声明，后使用，超时自动释放”。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/789384.html
