CERN：K8s 下 MIG vs time-slicing 的可复现损耗与落地配置

作者：Gaponcic Diana, Ricardo Rocha, Diogo Filipe Tomas Guerra, Dejan Golubovic（CERN）

摘要：GPU和加速器使高能物理（HEP）能够跟上不断增长的数据量和计算复杂性的步伐。如何提高目前昂贵且稀缺资源的整体效率和共享机会仍然是一个挑战。

本文描述了HEP中GPU使用的常见模式，包括交互访问的低整体使用率的波动需求，以及更可预测但可能突发的 workloads。然后探讨了共享和分区GPU的多种机制，包括时间分片（time-slicing）和NVIDIA设备的物理分区（MIG）。最后展示了针对代表性HEP用例的大量基准测试结果。

1. 引言

GPU正在改变组织访问和使用数据的方式，CERN也不例外。高能物理（HEP）分析和部署正在被重新思考，因为数据的复杂性和数量不断增长，传统的计算方法难以高效处理。在这种情况下，加速器仍然是实现高效机器学习（ML）的关键。

问题在于，许多用例实际上无法充分利用可用硬件。这可能是由于多种原因造成的：针对CPU设计的工作负载、批处理大小考虑不当、对硬件需求的假设错误等。

即使专家充分了解软件和硬件，并致力于获得最佳性能，由于开发过程的迭代性质，一些资源仍将保持空闲。为了解决这个问题，重要的是找到共享可用资源的方法。这可以在基础设施层面或GPU本身完成。

2. 基础设施层面的资源共享

在基础设施层面共享意味着建立单一的GPU访问入口点。无论在GPU上运行什么：模拟、推理、CI jobs、训练等，用户都通过一个统一的平台访问。GPU始终被使用，一旦GPU释放，它就可以重新分配给其他人。这也提供了一个通过公共云访问GPU或其他加速器（TPUs、IPUs）的机会。

Kubernetes在不同用例和利用模式方面做得很好。其中许多可以用Kubeflow（Kubernetes上AI平台的工具基础）覆盖。对于其他用例，可以在同一集群或多个集群中部署专用服务。

共享资源池的好处：

增加了CERN的GPU产品（因为许多专用GPU可以添加到公共池中）
提高了整体GPU利用率（因为GPU空闲时间更少）

3. GPU层面的资源共享

共享GPU有很多好处，但共享也带来了复杂性。一个主要好处是成本优化，因为加速器价格昂贵，组织可以通过向更多用户提供访问权限并提高整体硬件利用率来受益。这同样适用于能源和可持续性意识。

同时，在多租户设置中，我们引入了以前不存在的新问题。其中一些是噪音邻居问题、数据隔离的缺乏、由于管理多个用户并发的复杂性导致效率损失等。这些问题是确保多个工作负载可以安全地同时运行在同一芯片上的关键点。

3.1 时间分片（Time-slicing）

时间分片是一种共享机制，调度程序为所有GPU进程分配相等的共享时间，并以轮询方式交替处理。如图2所示，进程如何共享内存，而计算资源一次分配给一个进程。

为了在Kubernetes中配置GPU，我们需要将它们视为特殊资源，并有一种方法来识别它们、分配给工作负载并监控其健康状况。为此，我们可以使用NVIDIA gpu-operator。该operator自动管理使用GPU所需的NVIDIA软件，包括NVIDIA驱动程序、设备插件、容器工具包等。

在Kubernetes上启用时间分片需要向gpu-operator提供一些额外配置。首先，我们需要让设备插件知道它需要使用ConfigMap中可用的配置。然后，需要将所需共享选项的描述添加到引用的ConfigMap中。

当配置正常工作时，节点将开始宣传nvidia.com/gpu.shared资源，而不是默认的nvidia.com/gpu。

时间分片适用于广泛的NVIDIA架构，它是设置GPU并发的简单方法，提供无限数量的分区。另一方面，没有进程/内存隔离，也没有设置优先级的能力。

3.2 多实例GPU（MIG）

多实例GPU（MIG）是一种将GPU分区最多7个实例的机制，每个实例完全隔离，拥有自己的高带宽内存、缓存和计算核心。A100 40GB上的分区如图4所示。

在Kubernetes上启用MIG需要向GPU operator提供一些额外配置。首先，我们需要决定MIG策略（mixed/single/none），然后让MIG管理器知道它需要使用nvidia-mig-config中可用的配置。

MIG的一个非常重要的附加功能是能够为每个实例获取遥测数据。每个实例都可以独立监控，遥测允许对每个实例的性能、资源利用率和健康指标进行详细洞察。

MIG的优点：

硬件隔离允许进程安全并行运行，不相互影响
在分区级别提供监控和遥测数据
非常灵活的解决方案，可根据不同工作负载需求定制

MIG的缺点：

仅适用于Ampere、Hopper和Blackwell架构
重新配置分区布局需要驱逐所有正在运行的进程
根据所选配置文件布局，可能会损失可用内存

4. GPU共享机制基准测试

基准测试使用LHC粒子转弯模拟进行。我们使用为选定的GPU和CPU平台构建的OpenCL定向Simpletrack基准测试。详细信息：

使用Xsuite构建
重度GPU使用
CPU到GPU通信和内存访问较少
在NVIDIA A100 40GB PCIE GPU上运行
在Kubernetes 1.22集群上运行

4.1 时间分片基准测试

首先只在GPU上调度一个进程，然后慢慢翻倍进程数。最初我们比较在完整GPU上和时间分片成2个的执行时间。结果如表1所示。

粒子数量	共享x1 [秒]	共享x1 * 2 [秒]	共享x2 [秒]	损失 [%]
15,000,000	77.12	154.24	212.71	37.90
20,000,000	99.91	199.82	276.23	38.23
30,000,000	152.61	305.22	423.08	38.61

结论：

如果在专用GPU上运行1个进程，然后在2个相同进程上运行，执行时间预计会增加一倍。实际上，由于GPU需要执行上下文切换（从共享x1到共享x2），存在38%的性能损失。
使用时间分片在2个进程之间共享GPU会引入很大的性能惩罚。然而，增加GPU上的进程数（4、8）不会引入额外的性能损失。

4.2 MIG基准测试

完整的A100 GPU有108个流式多处理器（SM）。当在GPU上启用MIG时（7g.40gb），会损失10个SM——占可用计算的9.25%。

粒子数量	完整GPU，无MIG	完整GPU，有MIG (7g.40gb)	损失
5,000,000	26.365秒	28.732秒	8.97%
10,000,000	51.135秒	55.930秒	9.37%
15,000,000	76.374秒	83.184秒	8.91%

结论：

当我们在没有MIG和有MIG（7g.40gb）的完整GPU上运行基准测试脚本时，得出结论：9.25%的理论损失也在实验中得到验证。
如果我们不通过分区来利用MIG，就不应该在GPU上启用MIG，因为它会带来巨大的性能损失。
分区之间的缩放收敛到理想值。线性地，当可用资源增加时，执行时间变得更小。

5. GPU监控

监控是任何基础设施的重要组成部分。它允许跟踪和识别问题、预测用法或行为、设置警报等。Kubernetes使获取集群GPU使用情况的洞察变得相当容易。

我们可以从使用kube-prometheus-stack开始。另一方面，gpu-operator（特别是NVIDIA DCGM）从集群中的GPU收集指标，并将它们暴露给需要抓取的端点。通过这种方式，使用kube-prometheus-stack+gpu-operator，GPU指标已经生成，可用于Prometheus/Grafana堆栈进行可视化。

通常，默认GPU指标就足够了，但需要更细粒度/特定指标时，可以使用DCGM Field Identifiers，它允许启用和禁用非常广泛的指标。

6. 结论

总之，建立单一的GPU访问入口点是一个可以大大减少资源空闲时间的解决方案，同时也提高了CERN的整体GPU产品。然而，当用例无法充分利用可用GPU时，这不能成为解决方案。为此，我们需要开始在GPU层面考虑共享（逻辑或硬件）。然而，由于共享会带来性能权衡，必须有一种机制为将充分利用它们的用例提供专用GPU，以避免性能损失。因此，需要在不同基础设施层面共享的组合来实现最佳的GPU使用。

参考资料

Efficient Access to Shared GPU Resources - https://kubernetes.web.cern.ch/tags/gpu/
Kubeflow - https://www.kubeflow.org/
NVIDIA gpu-operator - https://github.com/NVIDIA/gpu-operator
MIG User Guide - https://docs.nvidia.com/datacenter/tesla/mig-user-guide/
Xsuite - https://github.com/xsuite/xsuite
Benchmarked script - https://gitlab.cern.ch/hep-benchmarks/hep-workloads-gpu/
kube-prometheus-stack - https://github.com/prometheus-community/helm-charts/
NVIDIA DCGM - https://developer.nvidia.com/dcgm
NVIDIA Field Identifiers - https://docs.nvidia.com/datacenter/dcgm/

联系方式

如果你有任何想法或建议，欢迎通过留言或邮箱联系我：787737563@qq.com