转自NVIDIA开发者社区，稍作修改，仅作学习笔记使用！如有侵权，请联系博主删除！url: https://mp.weixin.qq.com/s/ASkkgfcrdQNahfQnRWbHdw

如图表 1 所示，我们最多可以将 A100 切分成 7 个实例，每一个实例可以提供给不同的使用者运行不同的程序。在使用者的程序对 GPU 的计算量要求比较少的情况下，MIG 最多能够提供高达 7 倍的吞吐量。此外，由于每一个实例都有各自的计算资源和内存资源，因此不必担心因为其中一位使用者的计算量过大或是程式运行错误而干扰到其他的使用者。

MIG 的一个重要的应用，是让提供云服务的公司能够将 GPU 切分成数个实例，并将这些实例提供给不同的承租者使用。由于不同实例之间的计算资源与内存资源都是透过硬件分离，因此能够确保资料的安全性、错误的隔离，以及提供稳定可靠的服务。

在 MIG 推出之前，我们也能够透过 CUDA MPS (Multi-Process Service) 来提高 GPU 使用率。但 MPS 的缺点在于，多个使用者会使用共同的内存，因此使用者的程序会互相影响，除了无法保证推理的速度和吞吐量之外，也有可能因为其中一位使用者的程序出错而导致其他使用者受到干扰。而 MIG 克服了 MPS 面临的问题。MIG 藉由硬件上的分离，保证了使用者的程序不会互相干扰，进而能够让程序的时延和吞吐量能符合预期。

在表格 1当中，我们比较了多流 (multi-stream)、MPS 以及 MIG 的优缺点。其中，多流的使用限制较少，同时也很灵活，但对代码更动的需求大，并且无法避免使用者之间的互相干扰，使用者必须小心的使用以避免产生错误。MPS 则不需要更动代码即可使用，可以同时执行的程序也较 MIG 多 (48 与 7)，内存的使用与分配也是自动处理的，不需要人工的介入。缺点在于，无法避免多个用户对于 GPU 资源的竞争；最后，MIG 虽然可以同时执行的程序数量最少，但和 MPS 一样不需要使用者另外更动代码，同时在安全性与可靠性上面也是三者中最佳的。这三样技术并不互相冲突，使用者可以根据使用的情境与场景选择与搭配使用。

图表2  GPU 实例与计算实例

图表 2 展示了 GPU 实例和计算实例的区别。不同的 GPU 实例之前，他们的内存系统是分开的，以此能够保证内存的服务品质 (QoS, Quality of Service)，并且避免受到其他使用者的错误干扰。而在一个 GPU 实例当中，可以有多个计算实例，例如图表 2 中最左侧的 GPU 实例包含了四个计算实例，这四个计算实例各自负责了不同的工作，但他们的内存是共用的。透过这样子的设计，MIG 提供使用者灵活的调度 GPU 的资源。

表格 2 展示了不同大小的 GPU 实例他们具备的流处理器比例、内存比例、以及可以分配的数量。从图表 3，我们可以更清楚地看到MIG是如何对整个 GPU 去进行切割。在 A100 中，我们共有 8 份内存以及 7 份流处理器可以使用。其中，最小的实例 MIG 1g.5gb，具备一份内存和一份流处理器。而 MIG 2g.10gb 具备两份内存以及两份流处理器。需要特别注意的是，MIG 3g.20gb 和 MIG 4g.20gb虽然具备的流处理器数量不同，但同样拥有四份的内存。最大的实例 MIG 7g.40gb 则具备所有的流处理器以及内存。在使用时，我们可以灵活的分配实例的大小。举例来说，我们可以使用一个 4g.20gb 实例、一个 2g.10gb 实例，以及一个 1g.5gb 实例。图表 4 展示了我们使用的 GPU 实例。这里需要注意的是，虽然我们使用了所有的流处理器，但只有用到 7 份的内存，有一份内存会浪费掉。

注意：GPU实例编号依据：1、2、3、4、7五种slice（按照计算单元compute来划分）

当然，目前 MIG 的使用上还是有限制的。首先，MIG 只支援 Linux 系统，并且要求CUDA 11 以及 450.36.06 以后的 NVIDIA 驱动软体。另外，在开启 MIG 时，不支援图像的接口(像是 OpenGL)、不支援 GPU to GPU P2P 的传输 (包括 PCIe 和 NVLINK)、GPU instance 之间的 CUDA IPC 也不支援，但支援计算实例之间的 CUDA IPC。

图表5 MIG 管理树状图

图表7 开启 MIG 之后的 nvidia-smi

来确认我们能够创建的 GPU 实例。图表 8 是我们将看到的样子。第一列是 GPU 的号码、第二列是各个实例设定的名称、第三列是创建该实例时使用的 ID、第四列是该实例剩余可创建数目，以及该实例最多可创建数目、第五列是该实例的内存大小、第七列是流处理器的数目。

在创建完之后，我们可以会发现计算实例的资料会有所改变，如图表 12所示，可以发现所有 GPU 实例的可创建计算实例数目都为 0。接下来，我们再回头来看一下 “nvidia-smi” 目前的情况。从图表 13我们可以看见”MIG devices” 这一栏增加了新的资讯，里头包括了各个 GPU 实例的内存大小以及 ID，还有在 GPU 实例当中的计算实例的 ID 以及流处理器的数量。

图表12 计算实例资料-1

图表13 创建完计算实例后的 nvidia-smi

首先，我们透过 “nvidia-smi -L” 来得到所有计算实例的 UUID。从图表 14，我们可以看到各个计算实例对应的UUID。这边 UUID 的命名格式为MIG-<GPU-UUID>/<GPUinstance ID>/<compute instance ID>。以图表 14 为例，所有实例的GPU-UUID都是“38b3962a-109c-d69d-c3d3-3c2e8cff25cb”，而 MIG 1c.4g.20gb Device 0 的 GPU 实例 ID 为 2，计算实例 ID 为 0。

在建立完 FT 之后，我们接下来创建 7 个 1g.5gb 的 GPU 实例，并且在各个 GPU 实例上面创建一个计算实例。

nvidia-smi mig -cgi 19,19,19,19,19,19,19

nvidia-smi mig -gi 7,8,9,11,12,13,14 -cci 0

接下来透过

nvidia-smi -L

得到所有计算实例的名字之后，透过 CUDA_VISIBLE_DEVICES 这个环境变量来指定。

透过 nvidia-smi，我们可以看到7个实例同时在运行，如图表 19 所示。

表格 3 比较了 V100、T4、A100 不使用 MIG，A100 使用 7 个 MIG 计算实例、以及 A100 不使用 MIG 但使用 MPS 同时跑七个程式的时延以及吞吐量。这里需要特别注意的是，A100在batchsize 1时，会比 V100 还慢，这是由于 CUDA11 的新特性，FT 在使用 cuBLAS 时无法手动选择算法导致。从表格当中我们可以看到，在 batch size = 1 这种计算量比较小的情境下，MIG 可以带来 4 倍以上的吞吐量，而代价是时延会提升百分之五十。MPS 的效果则稍微比 MIG 要好一些。和上一代的 V100 与 T4 对比，A100 在开启  MIG 之后，吞吐量也提升成 3~4 倍。而在 batch size=128 这种计算量较大的情境下，开启 MIG 并不会带来什么效益，由于使用的流处理器较少(在使用 MIG 时，最多只能使用 98 个流处理器，而 A100 有 108 个流处理器)，因此吞吐量反而会些微的下降。在这种情境下，A100 的吞吐量为 T4 的 6 倍以上，V100 的两倍左右。

表格 4 比较了 V100 与 A100 使用 7 个 MIG GPU 实例在不同 batch size 下的吞吐量与时延。我们可以看到在 batch size 为 8 的时候，A100 的吞吐量已经很接近峰值，距离峰值不到百分之十；另一方面，V100 在 batch size 8 的食后，吞吐量距离峰值还有百分之三十左右，在 batch size 32 时，吞吐量距离峰值也还有百分之十左右。这代表和上一代的 GPU 相比，MIG 在提升 GPU 的使用率上有很大的进步。

表格 5 和表格 6 比较了A100、A100 使用一个 7g.40gb 的计算实例、以及 A100 使用 7 个 1g.5gb 的计算实例，在 BERT Base 和 BERT Large 上的差别。从这两张表格当中，我们可以得到几个结论。首先，A100 在不使用 MIG 下，和使用一个 7g.40gb 的实例下，其吞吐量和时延都差不多。其次，在 BERT Base 这个较小的模型上，MIG 在 batch size 1 时能带来四倍以上的吞吐量、在 batch size 4 时能带来两倍以上的吞吐量。只有到 batch size 64 以上才没有什么效益。而在 BERT Large 上，在 batch size 1 时，MIG 能带来百分之五十以上的提升，但在更大的 batch size 上，MIG 就没有什么明显的意义。