ARK: GPU-driven Code Execution for Distributed Deep Learning 论文主要包括两个工作：改善 GPU Driven 模式下的 DMA 调用方式、使用 GPU 用户态调度避免 CUDA Kernel 函数调度带来的延迟。笔者主要阅读了 ARK 论文中的第一个部分，即使用外部 DMA 驱动代替由 GPU thread 启动的 DMA 启动。
ARK 在背景介绍中谈到，集合通讯中存在的两种控制模式 CPU Driven 和 GPU Driven。CPU Driven 模式的缺点主要在于小数据包情况下，控制 overhead 不可忽略，通信带宽大幅度降低，而 GPU Driven 模式的缺点主要在于大数据包情况下，GPU 中 L2 Cache 利用率下降的问题。
事实上，在 NCCL 中，并没有使用 CPU Driven 这一模式，所以论文中使用 CPU Driven 作为 baseline 具有一定的误导性。NCCL 在 2.13.4-1 版本中已经实现了论文中的软件 GPU Driven 模式，即将 DMA 启动的部分从 GPU Thread 卸载到 CPU Thread 上面，从而避免了 CUDA IPC 模式下MMIO 带来的性能损耗。
所以可以得到，论文中的硬件 DMA 模型相比于现阶段 NCCL 的模型将会在小数据包的情况下具有一定的性能改善。这是因为现阶段 NCCL 中 GPU - CPU 通信需要通过共享内存模式进行控制位的同步，而小数据包情况下，即使是共享内存的方式，其通信延迟也是不可忽略的。使用一个 GPU 能够直接控制的 DMA 能够避免共享内存这一步的通信延迟，因而能够很大程度上改善小数据包情况下的延迟。在 NCCL 的测试数据下，使用 CudaMemcpy 来搬运数据，在单次通讯的数据小于 1M 时性能是低于默认方案的。
但是，论文中提出的方案有两点要求：Hardware DMA 与 GPU 在同一 PCIe switch 下，GPU 能够直接控制 Hardware DMA。这种要求的部署难度是比较大的，现阶段容易实现的 RNIC 方案，如果使用 GPU Thread 直接控制，控制延迟在几十 us 左右，而如果使用 CPU Thread 来控制 RNIC，虽然控制延迟降低到几 us，但是无法消除共享内存带来的延迟。另外，本论文的所有测试结果都是在 PCIe 上面测试得到的，在 NVLINK 下能否得到性能提升，还是一个疑问。