gpu调度粒度

节点级调度粒度

• 原理：在节点级调度粒度下，Slurm 将整个计算节点作为调度的基本单位。当一个作业请求 GPU 资源时，Slurm 会检查集群中哪些节点拥有可用的 GPU 设备，然后将作业分配到合适的节点上运行。这种调度方式不区分节点内具体的 GPU 设备，只要节点上有满足作业需求的 GPU 数量即可。
• 适用场景：适用于对 GPU 设备的具体特性和资源隔离要求不高的作业。例如，一些大规模的深度学习训练任务，只需要一定数量的 GPU 进行并行计算，而不关心具体使用哪些 GPU 设备。
• 示例：假设一个集群中有三个节点，每个节点配备 4 块 GPU。一个作业请求 8 块 GPU，Slurm 可能会将该作业分配到两个节点上，每个节点分配 4 块 GPU，而不会指定具体使用节点内的哪几块 GPU。

设备级调度粒度

• 原理：设备级调度粒度允许 Slurm 对节点内的单个 GPU 设备进行精确调度。作业可以请求特定数量和编号的 GPU 设备，Slurm 会根据作业的请求，在节点内分配具体的 GPU 设备给作业使用。这种调度方式可以更细粒度地管理 GPU 资源，提高资源利用率。
• 适用场景：适用于对 GPU 设备有特定要求的作业。例如，一些需要进行 GPU 间通信优化的作业，可能需要指定相邻编号的 GPU 设备，以减少通信延迟；或者一些对 GPU 性能有差异感知的作业，需要选择性能较好的 GPU 设备。
• 示例：一个作业请求使用节点 1 上的 GPU 0 和 GPU 1，Slurm 会检查节点 1 上的 GPU 0 和 GPU 1 是否可用，如果可用则将这两块 GPU 分配给该作业。
• srun --nodes=1 --nodelist=node01 --gres=gpu:0,1

此命令表明作业将在 node01 节点上运行，且使用编号为 0,1 的 GPU

实例级调度粒度（如结合 MIG 技术）

• 原理：随着 NVIDIA 的 Multi - Instance GPU（MIG）技术的出现，GPU 可以被分割成多个独立的小 GPU 实例。Slurm 可以结合 MIG 技术，实现实例级的调度粒度。在这种调度方式下，作业可以请求特定数量和规格的 MIG 实例，Slurm 会根据作业的请求，在节点内分配合适的 MIG 实例给作业使用。这种功能使得 GPU 的利用率更高，尤其适用于那些无法完全利用 GPU 计算能力的工作负载。
• 适用场景：适用于对 GPU 资源需求较小的作业，或者需要在多个作业之间更细粒度地共享 GPU 资源的场景。例如，多个轻量级的深度学习推理任务可以共享一个 GPU 上的不同 MIG 实例，提高 GPU 资源的利用率。
• 示例：一个节点上的一块 GPU 被分割成 4 个 MIG 实例，一个作业请求 2 个 MIG 实例，Slurm 会检查该节点上是否有 2 个可用的 MIG 实例，如果有则将其分配给该作业。

以A100 40GB显存为例，A100一张卡的SM单元(streaming multiprocessor)数量(类似CPU的核心数)为108，一个GPU运算实例的{BANNED}最佳小粒度是14个SM单元，也就是说在分配GPU的SM单元数量时必须是14的整数倍。如果申请规模为28 SM单元数，10GB显存的运算实例，设在单张A100上这样的实例个数{BANNED}最佳多为X个，那么必须满足28 * X <= 108(SM单元总数限制) 且 10 *X <= 40(GPU显存限制),所以X{BANNED}最佳大为3。每14个SM单元称作一个Slice，每张A100卡有7个Slice。

示例：

#!/bin/bash

#SBATCH --nodes=1

#SBATCH --nodelist=node01

#SBATCH --gres=gpu/MIG-1g.10gb:1

作业就会在指定节点上使用相应的 MIG 实例运行，gpu/MIG-1g.10gb：明确请求的资源类型为 GPU 的 MIG 实例，且具体规格是 1g.10gb。其中，“1g” 代表该 MIG 实例使用了 GPU 计算资源的 1 份切片，“1g” 所代表的具体计算资源（如 CUDA 核心数量、计算单元等）是固定的一组配置，是基于 GPU 硬件设计划分好的。“10gb” 表示该实例分配到了 10GB 的显存。

什么是 NVIDIA MPS（Multi-Process Service）

NVIDIA MPS 是 NVIDIA 提供的一项技术，允许在单个 GPU 上同时运行多个计算任务，通过将 GPU 资源虚拟化，在多个进程间共享 GPU 的计算核心、内存等资源，从而提高 GPU 的利用率。MPS 依赖于一个守护进程来管理多个进程对 GPU 的访问. MPS基于C/S架构，配置成MPS模式的GPU上运行的所有进程，会动态的将其启动的内核发送给MPS server，MPS Server借助CUDA stream，实现多个内核同时启动执行。除此之外，MPS还可配置各个进程对GPU的使用占比。

MPS的作用：

• 提高 GPU 利用率：MPS 允许来自不同进程的内核和内存复制操作在 GPU 上重叠，从而实现更高的利用率和更短的运行时间。
• 减少 GPU 上下文存储：如果没有 MPS，每个使用 GPU 的 CUDA 进程都会在 GPU 上分配单独的存储和调度资源。相比之下，MPS 服务器分配一份由所有客户端共享的 GPU 存储和调度资源副本。
• 减少 GPU 上下文切换：如果没有 MPS，当进程共享 GPU 时，必须在 GPU 上交换调度资源。 MPS 服务器在其所有客户端之间共享一组调度资源，从而消除了 GPU 在这些客户端之间进行调度时的交换开销。

MPS的构成组件如下。

·         Control Daemon Process：负责启动和停止MPS Server，并协调客户端和MPS Server之间的连接，确保客户端能够顺利接入到MPS服务中进行GPU资源的请求和使用。

·         Client Runtime：集成于CUDA驱动程序库内部。开发者无需对CUDA应用程序代码进行重大改造即可使用MPS。当应用程序使用CUDA驱动进行GPU操作时，Client Runtime会自动处理与MPS Server的交互，从而使多个应用程序能够高效、安全地共享GPU。

·         Server Process：接收来自不同客户端的请求，通过高效的调度策略将请求运行在一个GPU设备上，从而实现了客户端之间的并发性。

注意事项

·         在NVIDIA MPS架构下，MPS Client（您提交的使用MPS功能的GPU应用）需要跟MPS Control Daemon保持交互。一旦MPS Control Daemon重启，这些MPS Client将错误退出。

1.启动mps：nvidia-cuda-mps-control -d

-d 是 nvidia-cuda-mps-control 命令的一个参数，其作用是让 MPS 守护进程以守护进程模式（即后台模式）运行。

2.查看mps守护进程是否启动: ps -ef | grep mps

3.关闭mps:  echo quit | nvidia-cuda-mps-control

4.查看GPU的模式，默认模式可用nvidia-smi -q | grep "Compute Mode"

可以通过命令：sudo nvidia-smi -i 0 -c DEFAULT 设置为默认模式。

5.启动时可以设置 CUDA_MPS_PIPE_DIRECTORY 环境变量来设置 MPS 的工作目录，如果没有设置则使用 /tmp/nvidia-mps 目录

ls /tmp/nvidia-mps  该目录是 NVIDIA MPS 在运行过程中使用的临时文件存储目录

You can view the status of the daemons by viewing the log files in

∕var∕log∕nvidia-mps∕control.log

∕var∕log∕nvidia-mps∕server.log

用户在提交作业时，需要指定使用 MPS 共享 GPU 资源。例如，在提交作业脚本中添加相关参数来表明任务需要共享 GPU：

#!/bin/bash

#SBATCH --gpus-per-node=2

export CUDA_MPS_ACTIVE_THREAD_PERCENTAGE=30

export CUDA_MPS_ACTIVE_THREAD_PERCENTAGE=30：将该作业使用的2个 GPU 线程比例设置为 30% ，即各占用两个 GPU30%的算力。MPS 的主要目的是允许多个 CUDA 进程并发地使用同一个 GPU 的计算资源，通过管理 CUDA 线程的并发执行来提高 GPU 的利用率。它主要关注的是计算核心（如 CUDA 核心）的使用，会根据 CUDA_MPS_ACTIVE_THREAD_PERCENTAGE 环境变量按比例分配 GPU 的计算线程资源。应用设置的CUDA_MPS_ACTIVE_THREAD_PERCENTAGE百分比之和大于 100% 时，一般不会出现排队情况。CUDA_MPS_ACTIVE_THREAD_PERCENTAGE用于限制每个进程可使用的 GPU 算力百分比。当多个进程的该参数总和超过 100% 时，NVIDIA 的 MPS（Multi - Process Service）会根据各个进程的需求和系统资源情况进行动态分配和调度，以尽量满足每个进程的算力需求，而不是让进程排队等待。

CUDA_MPS_ACTIVE_THREAD_PERCENTAGE 用于控制在 CUDA MPS 环境下，GPU 上活跃线程的相对比例。它影响着 CUDA MPS 如何分配 GPU 资源给多个并发的 CUDA 进程，从而间接地对 GPU 的利用率和多个进程之间的资源共享情况产生影响。

CUDA_MPS_ACTIVE_THREAD_PERCENTAGE 这个环境变量的作用是对 MPS（多进程服务）的线程活跃性进行控制，而不是直接限制 GPU 的使用率。也就是说，它会影响 MPS 在 GPU 上运行线程的活跃度，并非严格限制 GPU 的占用比例。

用命令：watch -n 1 nvidia-smi检测GPU 的使用率

然而，显存的分配并不在 MPS 的直接管理范围内。MPS 不隔离显存，需通过程序控制显存使用，避免多任务冲突

nvidia-cuda-mps-server

该守护进程通常存储在 Linux 系统上的 /usr/bin 下，并在与节点上运行的客户端应用程序相同的 $UID 下运行。这。当客户端应用程序连接到控制守护程序时，将按需创建 nvidia-cuda-mps-server 实例。不应直接调用服务器二进制文件，而应使用控制守护进程来管理服务器的启动和关闭。

nvidia-cuda-mps-server 进程拥有 GPU 上的 CUDA 上下文，并使用它为其客户端应用程序进程执行 GPU 操作。因此，当通过 nvidia-smi（或任何基于 NVML 的应用程序）查询活动进程时 nvidia-cuda-mps-server 将显示为活动 CUDA 进程而不是任何客户端进程。