算力任务优先级调度，重要业务优先分配GPU
当多个人或任务共用一台GPU服务器时，最头疼的就是重要业务被无关任务挤占显卡。
本文用零基础也能照做的方式，讲清如何在Linux主机和容器环境里，通过优先级调度让核心业务优先获得GPU资源，并给出验证和排错方法。
先确认你的GPU环境和任务类型
动手前需要明确两件事：显卡驱动是否正常、任务以什么形式运行。
- 检查GPU状态：
nvidia-smi，看到显卡型号和显存占用即正常。 - 确认任务类型：是直接运行的Python进程，还是通过Docker或Kubernetes启动的容器。
- 记录重要业务的进程名或容器名，后面设置优先级要用到。
如果nvidia-smi报错，先解决驱动问题，优先级调度无从谈起。
在单机上用进程优先级保护核心任务
对于直接跑在宿主机上的任务，最直接的方法是调整进程的nice值和CPU亲和性，间接影响GPU调度顺序。
- 找到重要业务的进程PID：
pgrep -f your_script.py - 提高优先级（降低nice值，需要root）：
sudo renice -n -10 -p - 如果业务支持，绑定到特定CPU核心减少争抢：
taskset -cp 0-3
注意：nice值只影响CPU调度，GPU调度还需依赖驱动和上层框架。
更可靠的做法是在业务代码中设置CUDA流优先级，例如在PyTorch中使用torch.cuda.Stream(priority=-1)。
容器环境下的GPU优先级分配
如果任务跑在Docker里，可以通过--cpuset-cpus和--gpus参数控制资源。
- 给重要容器分配固定GPU：
docker run --gpus '"device=0"' --cpuset-cpus="0-3" your_image - 对非关键容器限制GPU使用：
docker run --gpus '"device=1"' --cpuset-cpus="4-7" your_image
Kubernetes用户则通过resources.limits和节点亲和性实现。
例如在Pod的YAML中指定nvidia.com/gpu: 1，并用nodeSelector绑定到特定GPU节点。
更精细的调度需要安装GPU共享插件，具体以官方文档为准。
避坑：这些做法可能让优先级失效
- 不要只依赖nice值，它不会改变GPU内部的调度顺序。
- 多个容器同时请求同一块GPU时，默认可能轮询分配，需要显式指定设备。
- 如果使用MIG（多实例GPU）技术，每个实例独立调度，优先级设置方式不同。
- 避免在业务高峰期动态调整大量进程，可能引发短暂卡顿。
验证优先级是否生效
设置完成后，用以下方法检查：
- 运行
nvidia-smi观察重要业务进程是否稳定占用GPU，没有被其他任务频繁打断。 - 查看进程的nice值：
ps -o pid,ni,cmd -p - 容器内执行
nvidia-smi确认可见设备正确。 - 模拟高负载场景，启动一个低优先级任务，观察重要业务是否仍能获得足够算力。
如果发现重要业务仍被抢占，回看容器启动参数和CUDA流设置，确保优先级传递到了GPU层。
常见疑问
问：没有root权限能调整优先级吗？
可以调整自己启动的进程，但降低nice值需要sudo。容器内通常以root运行，影响不大。
问：Windows服务器上怎么操作？
通过任务管理器设置进程优先级，但GPU调度依赖显卡驱动面板，建议查阅对应厂商文档。
问：优先级调度会影响性能吗？
合理设置不会，但过度限制可能导致低优先级任务饿死，需要平衡。
按照以上步骤，你可以让重要业务在共享GPU环境中获得更稳定的算力。
先从小范围测试，确认无误后再推广到生产环境。
