弹性计算技术指导及场景应用.pdf

导论本书选自 2023 年弹性计算社区的专题分享精华，集合 GPU 云服务器底层技术及实例使用详细讲解，主要为企业的实际场景业务，带来更多专业、底层的技术解决方案，提高 GPU 使用率，提高实例性价比。本书也集合了针对开发者们的热门、好玩的实践活动。目录页第 1 章GPU 云服务器底层技术篇.51.技术改变 AI 发展：CUDA Graph 优化的底层原理分析.52.技术改变 AI 发展：RDMA 能优化吗？GDR 性能提升方案.103.Ada Lovelace 架构解读及 RTX 4090 性能测试分析.16第 2 章GPU 云服务器实例使用篇.301.单实例上运行 Linux 桌面多开解决方案.302.vGPU 资源利用率的提升、监控与告警的实现.543.vGPU 驱动自动安装和升级.604.自动安装 NVIDIA GPU 驱动和 CUDA 组件.68第 3 章ECS 四大热门场景应用.741.所以！云服务器也可以玩转大模型？.742.免费试用 ECS，轻松搭建 WordPress 博客平台使用.863.ECS 部署 2048 小游戏.934.跟着技术蛋老师动手搭建 7*24 小时直播间.105第 4 章GPU 云服务器 AIGC 热门场景应用.1071.用 AI 唤醒老照片里的记忆（GPU 版）.1072.三张搞定 AI 形象照，开启 GPU 即刻体验.111第 1 章GPU 云服务器底层技术篇1.技术改变 AI 发展：CUDA Graph 优化的底层原理分析简介：随着人工智能（AI）的迅速发展，越来越多的应用需要巨大的 GPU 计算资源。CUDA 是一种并行计算平台和编程模型，由 Nvidia 推出，可利用 GPU 的强大处理能力进行加速计算。CUDA 异步执行模型对于 GPU 运算集中的 AI 应用场景，为了提升系统的性能，最大化地利用 GPU 资源是一个重要的优化方向。比较常用的方式是尽量将 GPU 运算转换为异步操作，CPU 侧负责任务提交，保证有足够的 cuda kernel 发送到 GPU，GPU 按照 CUDA Stream 流队列中的 Kernel 顺序执行。只要这中间不存在同步操作，GPU 完全可以不用等待，顺序地将所有的 kernel 执行完，然后再通知 CPU。CPU 运算和 GPU 运算是相互独立的协作关系。以上的模型是一个理想化的状态，听起来合乎逻辑，而且很完美。大致的运行效果如图1。可以看到 CPU 通过 CUDA API 已经将 Kernel 提前准备好，GPU 的任务一个接一个。GPU 的利用率也比较高。图 1 GPU 异步执行的典型场景对于一般的性能优化，达到这种状态已经很好了。但如果想进一步的优化就需要知道模型的实际运行情况。随着 GPU 算力的提升，计算任务的执行时间在慢慢缩小，一个 GPU 执行单元可能在 us 或者 ms 级完成。通常情况下一个好的 AI 运算框架或模型应该尽量让 GPU Kernel 的运算时间长一些，从而使得 GPU 的性能能够更好地发挥，因为有个事实是：GPU Kernel 提交到硬件也是有开销的，虽然这个时间可能只有 0.x us。这里的提交不是指的 cudaLaunchKernel而是更底层驱动和硬件之间的真正的提交。如果业务场景中有很多小的 us 级 Kernel 要执行，则整个系统的性能会随着短 Kernel的比例增加整体性能输出越来越差，GPU 资源并不能充分利用起来。CUDA Graph 性能优化效果CUDA Graph 可以通过 Capture 或 Create 的方式将多个 Kernel 组合在一起生成一个Graph，与 Kernel 融合不同，在 Graph 内部仍然是多个 Kernel 的形式存在，但提交操作只需要一次，如果可以将尽量多的 Kernel 组合在一起，那么理论上可以节约很多 Kernel 提交的开销。但 CUDA Graph 也有其自身的限制，它的设计思路是将多个任务单元作为一个快照进行组合，也就意味着这个快照的参数和结构组成是固定的，不能变换，同时实例化这个快照是比较耗时的，但如果这个快照被反复执行（replay）的次数足够多，实例化快照的时间是可以忽略的。以一个简单的 Kernel 为例介绍 CUDA Graph 是如何影响性能输出的。这里需要自己开发构造一个 Kernel：可以根据运算复杂度调整执行时间，但在运行过程中没有 Host 与Device 侧的数据交互。以下分析均基于这个自定义 Kernel 进行。通过对比 CUDA Graph 优化前后的性能数据（图 2）可以看到 CUDA Graph 对于执行时间越小的 Kernel 性能提升越明显，原因是Kernel 提交的开销占比会更大（假设单次提交的开销是固定的，接下来会证明这一假设）。图 不同执行时间 kernel CUDA Graph 优化后性能提升对照表CUDA Graph 性能优化原理为什么 Kernel 的提交会有系统开销并最终影响到 GPU 卡的性能输出？从图 1 的 GPU 异步执行逻辑来看，GPU 完全可以按照 CUDA Stream 的队列顺序自己控制 Kernel 的执行节奏，只要队列中的任务足够，就能输出最大的性能。Kernel 提交的开销究竟在哪里？图 3 可以有一个侧面的解释。在 Kernel 的执行过程中是有持续的双向数据流量的。而且这个流量和 Kernel 的执行时间是成反比的。这是个很重要的信息，因为 Kernel 执行过程中是没有运算数据流量的，HostToDevice 的流量就是 CPU 侧 Kernel 提交产生的，DeviceToHost 的流量就是 GPU 执行完 Kernel 需要和 Host 交互产生的。而且这个流量是和 Kernel 的提交频率有关，和 Kernel 本身并没有关系。图 不同执行时间 kernel 对应的 GPU 流量对照表进一步研究 Kernel 提交究竟会有多大的数据流量，图 4 做了一个展示，单次 Kernel的提交产生数据流量大约在 1KB，GPU 执行与 Host 同步的数据量大约在 0.22KB，而且从统计结果看与 Kernel 的大小无关。这也可以证明前面的假设：Kernel 的提交开销总体上是固定的。图 4.不同 Kernel 单次提交产生的数据流量对照表CUDA Graph 引入分析总结：cuda kernel 在执行时存在确定的 Host 和 Device 侧交互交互的频率或流量与 cuda kernel 的提交频率有关，与 cuda kernel 大小无关CUDA Graph 通过组合 Kernel 的方式可以将 Kernel 提交频率大幅降低，提高 GPU的性能输出，但对于执行时间长的 Kernel 性能优化不明显。对于 Host 与 Device 端延时明显的场景，这种优化都是有益的。因为这个 Kernel的提交开销本质上就是 H2D 延时的开销，延时越小 Kernel 提交的效率就越高。对于物理机为了能够得到极致的性能可以尽量减少中间 PCIe Switch 的级数，因为每一级的 switch 引入 RTT 延时大约在 0.3us，我们目前使用的 GPU Box 机型普遍有 2 级 Switch，引入 RTT 延时在 0.6us。如果是采用 gn7i 的机型，GPU 卡直连 PCIeRoot Complex，这 0.6us 是完全没有的，性能表现在小 Kernel 占比较高的场景中会更优越。2.技术改变 AI 发展：RDMA 能优化吗？GDR 性能提升方案简介：随着人工智能（AI）的迅速发展，越来越多的应用需要巨大的 GPU 计算资源。GPUDirect RDMA 是 Kepler 级 GPU 和 CUDA 5.0 中引入的一项技术，可以让使用pcie 标准的 gpu 和第三方设备进行直接的数据交换，而不涉及 CPU。背景：GPUDirect RDMA 是 Kepler 级 GPU 和 CUDA 5.0 中引入的一项技术，可以让使用 pcie 标准的 gpu 和第三方设备进行直接的数据交换，而不涉及 CPU。传统上，当数据需要在 GPU 和另一个设备之间传输时，数据必须通过 CPU，从而导致潜在的瓶颈并增加延迟。使用 GPUDirect，网络适配器和存储驱动器可以直接读写GPU 内存，减少不必要的内存消耗，减少 CPU 开销并降低延迟，从而显著提高性能。当前网络通信已经成为分布式机器学习的性能瓶颈，所以 GDR 技术的诞生对提高 gpu通信性能至关重要GDR 技术相较之前技术的升级点下图直观的展示了 gdr 技术的核心点所在，归纳来说就是 GPUDirect RDMA 技术使得数据流绕过主机内存和 CPU，直接走 pcie 链路，降低了传输延迟，加快了数据交换速度，并可以减轻 CPU 负载，释放 CPU 的计算能力，同时也避免了数据在主机内存中的复制，大大提升了性能。那么，GDR 就一定比传统方式快吗？前文介绍了 gdr 的优势，仿佛 gdr 对比传统方式有百利而无一害，那么 gdr 就一定快吗？我们可以看下如下拓扑结构我们拥有了如下图所示的拓扑，gpu 与网卡是跨 rc 的这时候假设我们想要与对端机器进行一个通信，使能了 gdr 之后的整个路径流程如下图所示首先是由网卡发起 dma read 的 request，gpu 收到之后再返回，网卡在收到 dma read 请求返回的数据接着 rdma write 到对端的网卡，再 dma write 到 gpu 中，由于gdr 技术是基于 pcie 标准的，所以整体链路都是需要通过整个 pcie 链路来触达，于是我们单看一端，链路就会是一个 dma_read request 翻山越岭，翻过 rc，翻过 switch到达 gpu 然后再是 tlp 包翻山越岭翻越 switch 翻越 rc 再到网卡，这么长的链路会导致延迟增大而如果不使用 gdr，整个链路则会是 gpu 数据搬运到系统内存，再从系统内存搬运到网卡，整体是 pipline 起来的，这种情况下，由于 pcie 链路长导致延迟大，使用 gdr 性能是可能差于不使用 gdr 的。那么 gdr 的合适使用场景是什么呢，比较推荐的场景就是 gpu 与第三方设备在同 switch 下的场景，这种情况下是存在性能增益的长拓扑链路的可能改进方案那么对于上面那种拓扑，是否存在方案可以将其性能提升呢？上面这种拓扑性能差的最大问题为整个 pcie 链路过长，如果能缩短链路就可以降低延迟，提升性能，于是我们把眼光放到了 dma_read 上。dma write 的优势如果将网卡发出的 dma read 替换成 gpu 发起的 dma write，就可以降低一半的 pcie 链路长导致的时延，同时 dma write 相较于 dma read 也存在本身性能上的优势，对于 read，pcie 采用切分传输的方式，首先需求方发起一个读请求，完成器发送 ACKDLLP 来确认需求方的读取请求，接下来完成器再返回一个 completion data，那个completion date 会被切分到多个 completion 包里，而 write 则是单一包，于是就会导致 read 的吞吐是低于 write 的吞吐的，举个例子，假设 read rerquest 是 512bytes，而 completion 包大小为 256 bytes，那么最大最理想的读吞吐则如下：completion packets 需要的数量为 512/256=2没有 ECRC 的 3 dword TLP 标头的开销为 2*20=40bytes最大吞吐为 512/（512+40）=92%下图即为这个例子的一个示意图，read 需要有两个 completion 包而 write 则是单一包即完成。以上的计算为读吞吐最大最理想的情况，pcie 标准定义了 read completion boundary(RCB)参数，这个参数定义了一个 read request 被几个 completion 包回复的边界，对于 root complext 来说，rcb 的值是 64bytes 或者 128bytes，对于其他 pcie设备来说，则是 128bytes。对于没对齐的 read request 来说，吞吐数据还会更差。所以改成 dma write 相较于 dma read 来说，有时延上的提升，同时也有吞吐上的提升。优化后的方案整体链路就如下图所示：简单尝试当前 rdma 协议是不支持这种方式的，所以就需要自己探索下是否可行，那么第一点就是 gpu 需要能主动对第三方设备发起 dma write，我们知道 gpu 是可以对 gpu 进行 dma write 的，那么下面就做一个简单的试验。可以看到是可以跑通的，即 gpu 可以对非 gpu 地址主动 dma write。可能遇到的问题那么如果需要让 gpu 来发起 dma write 还有哪些方面需要考虑呢？1）丢包问题首先，之前由网卡发起是因为网卡这边可以计算到发包一定能成功再发起 dma read请求，这样 tlp 包到了网卡就能顺畅发出去，不存在丢包风险，当前由 gpu 发起的话 tlp 包抵达网卡后，如果网卡接收到包就直接发出就存在丢包风险，所以需要有一个规避方案，网卡需要计算一定能发再发，于是就需要有一个缓存的地方将可能丢包的包先缓存起来2）调度问题其次，gpu 直接 dma write 到网卡的 tlp 包可能不会被网卡所接收，需要在 gpu 和网卡间达成约定，gpu 发的那些包网卡不进行丢弃而是调度管理起来发送到对端，那么就需要 gpu 这边能 kick doorbell，通知网卡收到的 dma 数据包需要留下，有一种方案就是移植部分 libverbs 到 gpu 上面去跑，这样子 gpu 就可以与网卡进行直接通信另一个就是需要封装一个 api，应用发起 rdma 命令后，使之前让网卡发起 dma read的流程变为让 gpu 发起 dma write总结综上所示，通过以下方法，可以提升 gdr 性能：上层封装一个 api 可以使 gpu 发起 dma write将 libverbs 移植部分到 gpu 上跑gpu 主动发起 dma write网卡那边增加缓存，对于不是一定有把握发成功的包先进行缓存，当确定能发送以后再将包发送出去当然，整个方案的落地也还有很多工作要做，需要修改 rdma 协议，同时在缓存与调度方面也需要很多工作进行，但收益也是显而易见的，能大大提升 gdr 的通用性与性能，使 gdr 在长 topo 链路时也变得可用。3.Ada Lovelace 架构解读及 RTX 4090 性能测试分析简介：随着人工智能（AI）的迅速发展，越来越多的应用需要巨大的 GPU 计算资源。Ada lovelace（后面简称 Ada）是 NVIDIA 最新的图形处理器架构，随 2022 年 9 月 20日发布的 RTX 4090 一起公布。背景：Ada lovelace（后面简称 Ada）是 NVIDIA 最新的图形处理器架构，随 2022 年9 月 20 日发布的 RTX 4090 一起公布。本节对 RTX 4090 以及 Ada 架构及其新特性先做一个全面的梳理。性能分析部分处理器参照物主要是 Hopper 架构的 GH100 和 Ampere 架构的 GA100/GA102，GPU 参照物主要是 H100（GH100）和 A100(GA100)或 3090 Ti(GA102)。Ada 架构跟 Hopper 架构的 GH100 一样，Ada 架构的 AD102 也采用了台积电的 4nm N4 工艺制程，这使得 AD102 得以集成高达 763 亿个晶体管，同时可以获得更高的频率，GPUBoost Clock 高达 52GHz，使得搭载 AD102 的 RTX 4090 成为目前频率最高的 NVIDIA GPU。AD102 搭载了新的第四代 Tensor Core，低精度数据类型上，跟 GH100 一样，新增支持业界首创的 FP8 数据类型，支持 INT8，但 Ada 增加了 Hopper 上去掉的 INT4；高精度数据类型上，支持 BF16 数据类型，支持 TF32 数据类型，但 Ada 去掉了 FP64 的TensorCore 支持。同样，Ada 架构每个 SM 张量核在等效数据类型上提供 Ampere 架构 SM 的 2 倍 MMA(矩阵乘法累加)计算速率。针对深度学习领域，同样提供稀疏神经网络的硬件加速支持，标准张量核心操作性能翻倍。得益于每个 SM 的 CUDA core 性能提升 2 倍（相比 Ampere 数量翻倍）以及更多的 SM 数量，IEEE FP32 的性能相比 GA102 也提升了近 3 倍。Ada 架构芯片搭载了新的第三代 RT Core（Turing 架构首次引入 RT Core，可实现硬件加速的实时光线追踪渲染。），每个 SM 的组合共享内存和 L1 数据缓存为 128KB，整个 AD102 的 L1 数据缓存可达 18432KB。显存带宽为 1TB/s 的 GDDR6X。支持 PCIe GEN4（双向带宽 64GB/s）。SM 架构Ada SM 架构最重要的是搭载了第四代 Tensor Core 和新的第三代 RT Core。架构总览Ada 完整的 AD102 芯片架构如下图所示：配置如下：12 GPCs,72 TPCs(6 TPCs/GPC),2 SMs/TPC,12 SMs/GPC,144 SMs per fullGPU128 FP32 CUDA Cores/SM,18432 FP32 CUDA Cores per full GPU4 forth-generation Tensor Cores/SM,576 forth-generation Tensor Cores perfull GPUGDDR6X,384-bit memory interface with 12 32-bit memory controllers288 FP64 Cores(2 per SM)，1/64th TFLOP rate of FP32RTX 4090 有一些裁剪，配置如下：11 GPCs,64 TPCs,2 SMs/TPC,128 SMs128 FP32 CUDA Cores/SM,16384 FP32 CUDA Cores per GPU4 forth-generation Tensor Cores/SM,512 forth-generation Tensor Coresper full GPU5 HBM2 stacks,10 512-bit memory controllersGDDR6X,384-bit memory interface with 12 32-bit memory controllerGPC 结构如果下图所示：Ada 架构每个 GPC 包含 1 个 Raster Engine（光栅化引擎），6 个 TPC，12 个 SM，16个 ROP(8 per ROP partition)。Ada 架构每个 TPC 包含 2 个 SM，每个 SM 包含 128 个 FP32 CUDA 核心和 64个 INT32 CUDA 核心（FP32 是 Ampere 的 2 倍，INT32 不变）、2 个 FP64 CUDA 核心（满足少量需要高精度的运算类型）、4 个第四代 Tensor 核心、1 个第三代 RT 核心。相比定位于数据中心计算的 Hopper，侧重于图形计算的 Ada 架构 FP64 核心数量大幅减少（上图因为数量太少并未画出），增加了一个 RT 核心。如图所示，Ada SM 划分为 4 个处理块，每个处理块均包含 32 个 FP32 CUDA 核心、16 个 INT32 CUDA 核心、1 个 Tensor 核心、1 个线程束调度器和 1 个分配单元。每个处理块还具有一个 L0 指令缓存和一个 16 KB 寄存器堆。这四个处理块共享一个L1 指令缓存，以及一个组合式的 128 KB L1 数据缓存或共享内存，是 Hopper GA100 的一半。整个 AD102 的 L1 缓存为 18432KB，相比 Ampere GA102 的 10752KB 提升了 70%。第四代 Tensor CoreAda 架构搭载的第四代 Tensor Core，大部分特性跟 Hopper 架构一样，最重要的是引入了一个新的数据类型 FP8。不同的是去掉了 FP64 的支持，增加了INT4 的支持。在 Tensor Core 性能上，AD102 相比 GH100，大概是 1/3 的水平，跟 GA100接近，是 GA102 的 2 倍。相比 Ampere 架构主要是新增了 FP8 的支持。L2 缓存AD102 的 L2 缓存增大到了 98304KB，是 GA102(6144KB)的 16 倍。更大的 L2 缓存使得 HPC 和 AI 应用可以将更多的数据缓存到 L2，而不是放到显存上，从而获得更高的读写速度，比如小 batch size 的深度神经网络的计算。GDDR6X 显存高达 1TGB/s 的 24GB 的 GDDR6X 显存，目前最高速的 GDDR 显存。GPU SpecRTX 4090 是最新一代面向图形计算场景的 GPU 卡，我们将 RTX 4090 与上一代 Ampere 架构 Tesla A100 和 RTX 3090 Ti 的主要参数做了对比如下：GPU TypeRTX 4090RTX 3090 TiA100(SXM4-80G)GPU ArchitechtureAD102(Ada Lovelace)GA102(Ampere)GA100(Ampere)GPCs(Graphics Processing Clusters)1177TPCs(Texture Processing Clusters)644254SMs(Streaming Multiprocessors)12884108FP32 CUDA Cores16384107526912INT32 CUDA Cores819253766912FP64 CUDA CoresN/AN/A3456Tensor Cores512336432RT Cores12884N/AGeometry Units6441N/ATMUs(Texture Units)512336432ROPs(Raster Operation Units)176112160INT4(TOPS)1322/2644640/12801248/2496INT8(TOPS)660.6/1322320/640624/1248INT32(TIPS)432019.5BF16(TFLOPS)864039FP16(TFLOPS)864078FP32(TFLOPS)864019.5FP64(TFLOPS)3N/A19.7Tensor Core FP8(TFLOPS)660.6/1322N/AN/ATensor Core FP16(TFLOPS)330/660160/320312/624Tensor Core TF32(TFLOPS)86/165.240/80156/312Tensor Core FP64(TFLOPS)N/AN/A19.5RTX-OPS(TOPS)19178.1N/AGPU Memory24 GB GDDR6X24 GB GDDR6X80 GB HBM2eMemory Clock(MHz)132512191593Memory Interface Width384-bit384-bit5120-bit(10*512-bit)Memory Bandwidth(GB/s)100810082039Interconnect Bandwidth(GB/s)PCIe Gen4:64PCIe Gen4:64NVLINK:600Default Graphic Clock(MHz)223013951155Max Graphic Clock(MHz)252018601410Power(Watt)450350400从 Spec 来看，使用新架构的 RTX 4090 相对于 RTX 3090 Ti，CUDA Core、TensorCore 以及 RT Core 的性能均提升了 2 倍左右，显存容量和带宽并没有变化。而相比 Tesla A100，Tensor Core 性能是基本相当，略高 5%。但是 Tesla A100 的显存带宽是 RTX 4090 的 2 倍，受限于显存带宽 4090 的算力发挥会受影响，推测小 bs 的 AI 任务 RTX 4090 会略有优势或者与 A100 接近，但是随着 bs 增大，Tesla A100 的性能应该会更好，而且随着 bs 增大差距会拉大。当然以上都是硬件的理论性能指标，那么 RTX 4090 的实际性能表现如何呢？下面通过一些实测数据来分析。性能实测我们测试了 RTX 4090 在图像分类、文本生成、图片生成这几个主要 AI 任务的训练和推理性能，并和 Tesla A100 做了相应对比。测试都是单卡，不考虑 GPU 间通信带宽对性能的影响。从下面的测试结果来看，基本跟上面的分析差不多，RTX 4090 算力略高于 A100，但受限于显存带宽，实际小任务时性能与 A100 接近，大任务时 A100 优势更大。图像分类(ResNet50)图像分类测试的是 TensorFlow ResNet50-v5 Training 的性能：TensorFlow ResNet50-v5 TrainingGPU numsbatchsize per GPUprecisionvariable_updatelocal_parameter_deviceall_reduce_spec4090(images/sec)A100-8 0 G(images/sec)A100/4090164fp16parameter_servercpuNone13241274.4696.26%1128fp16parameter_servercpuNone1356.46178251346%164fp16parameter_servergpuNone1614.91784.631 1 0.51%1128fp16parameter_servergpuNone147911978.991 3 4.36%164fp16replicatedgpuNone159491486.6935%1128fp16replicatedgpuNone1457.87201651 3 8.05%164fp16replicatedgpupscpu1595.171627.921005%1128fp16replicatedgpupscpu1460.312004.911 3 7.29%164fp16replicatedgpunccl1589.091786.491142%1128fp16replicatedgpunccl15343205131394%从测试结果看，bs=64 时 4090 性能与 A100 是接近的，但是到了 bs=128 时，差距可以达到 30%以上。文本生成（LLAMA）我们测试了 LLAMA 7b 文本生成推理任务，用吞吐也就是每秒生成的 token 数作为评估标准，值越大性能越好。GPUmodel sizeprecisionbatch sizethrought(tokens/s)40907bfp16146.38A1007bfp16146.3540907bfp16287.85A1007bfp16290.68从测试结果可以看到：Bs=1 时 4090 跟 A100 差不多，bs=2 时 A100 就超过 4090 了。图片生成（Stable Diffusion）Stable Diifusion 测试的是 WEB UI 场景固定 sampling step=20 生成 512*512 尺寸图片的时间，时间越短性能越好。测试了 Pytorch native 以及 xformers 加速后的生成时间。GPU加速库samplingstepsimage sizebatch sizetime(s)4090native20512*51210.9A100native20512*512114090 xformers20512*51210.6A100 xformers20512*51210.84090native20512*51286.8A100native20512*51285.44090 xformers20512*51284.5A100 xformers20512*51284.1从结果看，在 bs=1 时，4090 性能是优于 A100 的，但是当 bs 增大到 8 时，A100 的性能就明显超过 4090 了。总结RTX 4090 的 Ada Lovelace 架构继承了 Hopper 架构在 AI 计算方面的特性，同时搭载了新的第三代 RT Core，AI 性能和光追算力相比上一代 RTX 3090 Ti 均提升一倍，单 GPU AI 算力与 A100 接近。实际测试 4090 在小 bs 推理任务上可以与 A100 相当，但是首先显存带宽以及 GPU 间高速通信带宽的缺失，在多卡训练和推理任务上相比 A100 差距还是会很大。第 2 章GPU 云服务器实例使用篇1.单实例上运行 Linux 桌面多开解决方案简介：客户前期使用的旧异构实例面临更新换代，新的推荐异构实例性能更强，客户的业务软件运行时，GPU 使用率不高，需要探索多开方案，提高 GPU 使用率，提高实例性价比。背景：客户前期使用的旧异构实例面临更新换代，新的推荐异构实例性能更强，客户的业务软件运行时，GPU 使用率不高，需要探索多开方案，提高 GPU 使用率，提高实例性价比。此外，客户的业务软件多开后，必然涉及到多开的每个业务软件分别给不同的用户使用的场景，因此，在一个桌面中多开业务软件的方案不可行（操作及画面显示均互相冲突），需要探索整个 Linux 桌面多开的方案。Linux 图形应用容器化在不考虑桌面多开时，参考阿里云官方文档 Linux 图形应用最佳实践，Linux 图形应用容器化时，有两种方案：1）在 Host（注：此处的 Host 是相对于容器来说的，容器为 Guest，下文不再作重复解释）上运行 X Server：Host 上安装并启动 Xorg，将 X Server 的 unix socket 目录(/tmp/.X11-unix)映射到容器中并设置好权限，容器中设置好 DISPLAY 环境变量后，即可通过共享的 unix socket 向 Host 上的 X Server 发送图像渲染命令。此方案下，如果要查看显示结果，可以在 Host 上运行 x11vnc，然后使用 VNC Client 软件连接。该方案优缺点：优点：多个容器可以同时共享 Host 上的 X Server；缺点：多个容器的图像都是渲染到同一个 X Server 上的，互相之间会遮挡影响；2）在容器中运行 X Server：Host 上只需要安装 GPU 驱动，不做任何配置，在容器中安装并运行 Xorg。该方案优缺点：优点：Host 不用做任何配置，定制修改都在容器中，便于保存和迁移；缺点：GPU 是单个容器独占的，不能多个容器共享；Linux 桌面多开方案单显卡上启动多个 X Server 进程实现多开测试了三种方案：在 Host 上运行多个 X Server 进程；在 Host 上和容器中同时运行 X Server 进程；Host 上不运行 X Server，在多个容器中同时运行 X Server 进程；均不成功，后启动的 X Server 会接管硬件，使得后启动的 X Server 画面正常，而先启动的 X Server 画面黑屏。Multiseat 方案Multiseat 方案(MultiseatX、MultiseatOneCard、Multiseat-X.Org、MultiSeatTerminal X.org、Multiseat-Gentoo Wiki)是在多个显卡或者单个显卡的多个输出的基础上，实现多个独立桌面的方案，它受硬件的限制较大，多开数量有限，配置也相对复杂，暂不考虑该方案。Xephyr 方案Xephyr 是一个嵌套的 X Server，它本身运行在 X Server 中，对 X Server 来说它是一个应用程序，同时，它自身又是一个 X Server，为其他的应用提供服务。Xephyr 方案的最大缺点是，目前不支持 GPU 硬件加速。Xpra 方案Xpra 和 Xephyr 类似，是嵌套的 X Server，主要区别是，Xephyr 会将它提供的嵌套 XServer 作为一个窗口显示在当前 X Server 中，而 Xpra 倾向于提供一个虚拟的 X Server 环境，将显示转发到客户端去。参考：Whats the difference between Xpra and Xephyr?和 Xephyr 一样，Xpra 的最大缺点也是，不支持 GPU 硬件加速。VirtualGL 方案方案描述：VirtualGL（官方文档）是一个为 Linux/Unix 远程显示软件启用 OpenGL 硬件加速的开源工具。通常，一个 Linux/Unix OpenGL 应用程序会发送它所有的（包括 2D 和 3D）图形渲染命令和数据到一个 X Server。VirtualGL 通过在运行时将动态共享对象(Dynamic Shared Object,DSO)VirtualGL Faker 预加载到OpenGL 应用程序中来实现将3D命令和数据从 OpenGL 应用程序重定向到应用所在服务器中的 GPU。VirtualGL Faker 拦截并修改某些 GLX、EGL、OpenGL、X11 和 XCB 函数调用，将 OpenGL 渲染从 3D 应用程序的窗口转移到 VirtualGL 在 GPU 显存中创建的离屏缓冲区(off-screen buffer)。当 3D 应用程序交换 OpenGL 绘图缓冲区或刷新 OpenGL 命令缓冲区以表示它已完成渲染帧时，VirtualGL 从离屏缓冲区读取渲染好的帧并（通过 X Proxy，比如 TurboVNC）将它传输出去。使用 VirtualGL 时，GPU 可以给多个用户共享。VirtualGL 方案的很大一个优点是它的非侵入性。VirtualGL 监视一些 X11 命令和事件，以确定窗口何时被调整大小等等，但它不会以任何方式干扰 X11 2D 绘图命令到 X Server 的传递。在大多数情况下，VirtualGL 也不会干扰 OpenGL 命令到 GPU 的传递。VirtualGL 只是强制将 OpenGL 命令传递给应用服务器上的 GPU(通过 3D X Server 或与GPU 的 EGL 设备)，而不是传递给 2D 绘图命令的 X Server(2D X Server)。VirtualGL 内建支持两种图像传输协议（还支持协议扩展），VGL 传输协议和 X11 传输协议。VGL 传输协议当 2D X Server 不在应用程序服务器上时(比如 2D X Server 运行在客户端机器上)，最常使用 VGL 传输协议。VirtualGL 在专用的 TCP socket 上使用自己的(VGL)协议将渲染的帧发送到客户端，VirtualGL 客户端将帧解码并将它们组合到适当的 X 窗口中。VGL 传输协议可以以未压缩的形式(RGB 编码)传输帧，也可以使用 high-speed JPEG 编解码器实时压缩帧。它还支持立体图像对的交付，可以通过 VirtualGL 客户端将其重建为立体帧。整个框架如下图所示。图 1 VirtualGL 使用 VGL 传输协议框架图X11 传输协议X11 传输协议本身只是使用 XPutIm