EDAS：实现GPU无服务器计算中的快速数据加载

《ACM Transactions on Architecture and Code Optimization》：EDAS: Enabling Fast Data Loading for GPU Serverless Computing

针对现有GPU服务器less系统数据加载延迟和资源争用问题，本文提出EDAS系统。通过用户请求标注数据属性（如大小、读写性），EDAS实现并行数据加载与分阶段资源退出机制。实验表明，EDAS使函数执行时间缩短16.2倍，系统吞吐量提升1.91倍。

　　在现代云计算环境中，GPU的集成正变得越来越重要，尤其是在需要高性能计算的任务中，例如深度学习推理和科学计算。这些任务通常需要快速访问大量数据，而GPU在执行计算任务时的高效性使得其成为处理这些任务的首选资源。然而，现有的GPU服务器端系统在数据加载方面存在显著的瓶颈，导致GPU的利用率低下。本文提出了一种名为EDAS的新系统，旨在解决这一问题，从而提升GPU在服务器端的性能表现。

### 数据加载瓶颈与挑战

现有的GPU服务器端系统，如阿里云的Function Compute和Azure Function，普遍采用固定大小的GPU资源分配模式（称为FixedGSL）。当一个GPU函数被触发时，系统会为其分配一定量的GPU资源，例如1/24的A10 GPU或1/12的T4 GPU。然而，这些资源的分配方式并不完全符合GPU在实际应用中的需求。例如，许多GPU函数（如深度神经网络推理和科学计算服务）只需要几十到几百毫秒的纯计算时间，这意味着它们在数据加载阶段可能花费大量时间，尤其是在共享集群环境中。这种数据加载过程常常受到网络和PCIe带宽的限制，导致严重的资源争用问题。

具体来说，现有系统中，GPU函数在启动时需要先创建GPU上下文，这通常需要约100毫秒。在GPU上下文创建完成之前，数据加载过程会被阻塞，即使数据已经在CPU内存中准备就绪。此外，由于多个GPU函数可能同时访问数据库，网络和PCIe带宽的争用进一步加剧了这一问题。实验结果显示，共享集群中的GPU函数平均数据加载时间比单独运行时长6.1倍，即使在网络带宽不是瓶颈的情况下，数据加载时间仍会比单独运行时长4.8倍。

这些数据加载瓶颈不仅影响函数的执行效率，还降低了整个系统的吞吐量。在实际应用中，这种延迟问题可能会导致资源利用率低下，从而影响系统的整体性能。因此，如何优化数据加载过程成为提升GPU服务器端性能的关键。

### EDAS系统的设计与创新

为了解决上述问题，EDAS提出了一种新的数据加载管理机制，通过增强用户请求的规格，允许开发者为GPU函数的数据输入添加额外的属性信息，如数据大小和读写属性。这些属性信息为系统提供了优化数据加载所需的洞察，使得EDAS能够主动管理数据的加载过程。

EDAS的核心创新在于其对数据加载和上下文创建的解耦处理。传统上，GPU函数需要在上下文创建完成后才能进行数据加载，这导致了严重的顺序依赖问题。而EDAS则通过并行化这两个阶段，使得数据加载和上下文创建可以同时进行。这不仅减少了数据加载的总时间，还提高了GPU资源的利用率。

为了实现这一目标，EDAS引入了两个关键接口：`EdasLoadToGPU()`和`EdasDumpToDB()`。这些接口允许GPU函数在不依赖于上下文创建的情况下访问预先加载的数据，并且在数据加载完成后可以将结果直接写回数据库。此外，EDAS还设计了一个统一的内存守护进程（memory daemon），负责管理数据的加载和共享，同时通过执行拦截器（execution shim）确保数据加载的正确性和一致性。

### 数据加载优化方案

EDAS采用了两种主要的数据加载优化方案：并行化数据加载和多阶段资源释放。并行化数据加载方案允许系统在GPU上下文创建的同时进行数据加载，从而减少了整体的延迟。而多阶段资源释放方案则通过释放写入数据、GPU上下文和只读数据的顺序，优化了数据的共享和资源利用。

具体而言，EDAS的多阶段资源释放机制分为五个阶段。在第一阶段，多个请求可以共享只读数据，从而减少重复的数据加载。在第二阶段，系统在无请求时释放GPU上下文，以减少资源争用。在第三阶段，系统将只读数据从GPU缓存到CPU内存，利用CPU内存的高性价比和大容量优势。第四阶段中，系统在无请求时释放CPU内存中的只读数据，以减少内存占用。最后，在第五阶段，系统释放CPU上下文和容器，为后续请求腾出资源。

这种分阶段的资源释放机制使得系统能够更灵活地管理GPU资源的使用和释放，从而在减少资源争用的同时，提高数据的复用率。实验结果表明，EDAS在减少数据加载时间方面表现出色，其函数执行时间比现有系统降低了16.2倍，系统吞吐量提高了1.91倍。

### 实现与安全性

为了实现EDAS系统，研究团队使用了Docker和Nvidia Container Toolkit来构建应用沙箱，确保每个GPU函数在独立的容器中运行，从而避免资源争用。此外，使用GRPC进行消息传递，使得不同组件之间的通信更加高效。为了存储数据，EDAS还集成了MinIO，一个兼容S3的对象存储系统，支持高效的数据访问和管理。

在安全性方面，EDAS采用了一种基于沙箱的模型，将不信任的函数和数据访问隔离，防止恶意用户对主机或其他租户造成影响。此外，EDAS通过GPU上下文隔离和统一的内存管理机制，确保数据访问的安全性。即使某个GPU函数崩溃，也不会影响其他函数的执行，因为每个函数都运行在独立的上下文中。

### 实验评估与结果

为了验证EDAS的性能优势，研究团队在多个实验中进行了测试。实验环境包括配备A10 GPU的服务器和集群，以及配备A100 GPU的服务器。实验结果显示，EDAS在处理各种类型的GPU函数时，显著优于现有的FixedGSL、FixedGSL-F和DGSF系统。在函数执行时间方面，EDAS的平均响应时间比现有系统降低了16.2倍，系统吞吐量提高了1.91倍。

此外，EDAS在处理大规模的GPU函数时也表现出良好的可扩展性。在集群环境中，EDAS的性能优势依然显著，其平均响应时间比现有系统降低了10.5倍和9.5倍，系统吞吐量提高了1.55倍和1.14倍。这表明，EDAS不仅在单个GPU上表现出色，在集群环境中同样具有良好的性能表现。

### EDAS的性能优势

EDAS的主要优势在于其对数据加载的优化和对资源的高效管理。通过并行化数据加载和上下文创建，EDAS能够显著减少函数的启动时间和数据加载延迟。同时，通过多阶段资源释放机制，EDAS能够更好地利用只读数据的共享特性，减少重复的数据加载，从而降低资源争用。

在实验中，研究团队还测试了EDAS在不同GPU上的表现，包括A10和A100。结果显示，EDAS在A100 GPU上的性能优势更为显著，其平均响应时间比现有系统降低了10.3倍和9.8倍，系统吞吐量提高了1.73倍和1.22倍。这表明，EDAS不仅适用于不同类型的GPU，还能够适应不同规模的计算需求。

### EDAS的未来展望

尽管EDAS已经取得了显著的性能提升，但其仍然存在一些局限性。例如，对于某些需要复杂数据管理的GPU函数，EDAS的优化方案可能需要进一步的改进。此外，EDAS目前主要支持基于PyTorch、TorchPhysics和PyHalide等框架的GPU函数，未来的研究可以扩展其支持范围，以适应更多类型的应用。

总的来说，EDAS通过引入新的数据加载管理机制，有效解决了现有GPU服务器端系统在数据加载方面的瓶颈问题。其设计不仅提高了GPU的利用率，还优化了系统的整体性能，使得GPU在云计算环境中能够发挥更大的作用。随着GPU技术的不断发展，EDAS的优化方案将为未来的高性能计算提供重要的支持。