GPU （ Graphics Processing Unit ），即图形处理器，是一种由大量核心组成的大规模并行计算架构，专为同时处理多重任务而设计。 GPU 在大规模并行运算上具有巨大优势，为大数据、人工智能训练和推理任务以及图像渲染等场景提供了显著的计算性能加速支持，但在实际使用中会产生资源管理困难、利用率低等问题。 AIStation 是浪潮推出的一款人工智能开发平台，可实现 GPU 资源的精细化调度。本文将重点介绍浪潮 AIStation 推理平台的 GPU 共享技术能力和应用场景。

GPU 计算资源的运维痛点

对于人工智能开发人员、 AI 系统研究机构或进行数字化转型的新型 / 传统企业来说，在使用 GPU 计算资源时通常会面临如下几个问题：

1.         GPU 资源管理困难。 GPU 相对 CPU 价格较贵，作为高价值硬件资源， GPU 很难做到像网络、存储一样的运维、管理一体化。在实际应用环境下，经常出现多进程、多人员、多任务复用同一 GPU 资源的情况，长时间的资源等待严重降低了业务流程的推进效率，降低了产品迭代的速度；

2.         GPU 资源使用效率低。 算力需求较小的 AI 服务（ on-premise 或 cloud ）通常无法满负载使用一块 GPU 卡，并且用户在使用 GPU 资源时也需要显性地区分不同型号的 GPU ，以适配不同架构、型号 GPU 的计算核心、驱动和其他版本组件，为用户带来了更高的使用门槛；

3.         GPU 资源快速申请、回收困难。 在生产环境中， AI 服务对 GPU 资源的申请与释放需要基于任务负载的使用周期，以及不同任务在波峰 / 波谷时对 GPU 资源的使用量，按照在线请求数量（ QPS ）进行自动扩缩容，才能够满足线上 AI 服务的实时高并发、低延迟的需求；

为了彻底解决上述问题，工业界已经提出了多种 GPU 共享方案。并且在云原生趋势下，利用云原生技术和标准 Docker 进行容器化部署，已经成为业内云服务对异构计算资源的通用方法。

表1 业界现有的GPU共享方案

如何将多个任务同时运行在同一张 GPU 卡上，同时对共享资源进行严格的隔离，是业界的一个重要研究方向。此外，业内需求还包括如何在生产环境中对细粒度 GPU 资源（小于整卡的显存、计算核心）进行扩缩容（即多个任务运行在一张 GPU 中，此 GPU 中的任务同样需要在负载增加时，能够运行在不同的 GPU 卡上），以及适配多版本官方组件。上述需求不但要考虑技术方面的实现，还要根据实际生产过程中的不同类型指标进行资源的自动伸缩。针对以上亟待解决的问题， AIStation 推理平台提供了稳定 GPU 细粒度资源的分配、调度和管理能力，为企业用户带来了高效利用 GPU 资源的最佳解决方案。

AIStation 推理平台 GPU 共享功能简介

AIStation 推理平台基于 Kubernetes 容器编排与计算资源发现、调度能力进行构建，支持容器化应用的生命周期管理和微服务架构，提供多种推理服务的发布方式和持续交付能力，简化推理服务上线流程，为用户提供稳定、快捷灵活的生产环境服务部署平台。

GPU 共享系统为 AIStation 推理平台自研技术，针对使用 GPU 作为计算资源的应用提供多容器（或服务）共享同一块 GPU 加速卡的能力。用户可对多种架构的 GPU 加速卡进行细粒度的资源分配、调度，并通过计算请求量（ QPS ）、 CPU 使用率、内存使用率等指标自动进行扩缩容操作，能够保证推理服务快速响应在线请求、提升 GPU 资源的复用率，同时对底层第三方组件不具有任何侵入性，可将其轻松移植到不同的应用场景下。

AIStation 提供以下 GPU 共享技术能力：

l     提供 GPU 显存的细粒度分配与调度能力；

l     提供 GPU 计算核心的细粒度分配与调度能力；

l     提供基于 HPA 的细粒度 GPU 资源扩缩容能力；

l     提供基于 QPS 的细粒度 GPU 资源扩缩容能力；

l     提供基于 GPU 共享的高可用部署能力；

l     提供多种型号 GPU （ V100 、 T4 、 A10 ~ A100 、 RTX2080 ~ 3090 ）共享能力；

l     极低的计算性能损耗（平均损耗低于 1.3% ）；

GPU 显存的细粒度分配与调度能力。 用户可以将多个不同类型的服务部署在同一张 GPU 卡上，当多个服务的所需 GPU 显存能够“恰好”满足单张 GPU 的实际显存数量，此时 GPU 资源的使用率可以达到 100% 。如图 1 中的 Case1 所示， Container1 和 Container3 、  Container2 和 Container4 的组合分别可以完全满足现有 GPU 资源的显存额度。更多的情况为，用户可以通过配置文件设定“服务所需GPU显存资源申请额度”， AIStation 将组合后能够达到最大 GPU 利用率的服务调度到同一张 GPU 卡，进而提升 GPU 资源的使用率。

图1 不同场景下AIStation对显存的细粒度分配与调度

AIStation 能够保证各服务之间的显存隔离。如图 1 中的 Case2 所示， AIStation 通过后台算法计算出最优的调度策略，为预部署服务提供最小剩余资源与服务安全保障方案，在合理调度服务到不同 GPU 卡后，可以为其他服务提供空闲的 GPU 资源；对于跨节点的 GPU 资源， AIStation 同样能提供细粒度分配与调度能力。

提供 GPU 计算核心的细粒度分配与调度能力。 GPU 计算资源包括显存（ Memory ）与计算核心（ Kernel ），当所部署的服务对计算核心使用率不高，或无需使用整卡的计算核心即能满足现有延迟要求时， AIStation 可在单张 GPU 内对计算核心进行细粒度的划分并且兼顾 GPU 显存划分。如果同时设置 GPU 计算核心和显存的细粒度划分，以计算核心分配为主，单张卡的计算核心分配 ≤100% 。

图2  AIStation 对计算核心的细粒度分配与调度

提供基于 HPA 的细粒度 GPU 资源扩缩容能力。 AIStation 支持原生 Kubernetes 的水平自动扩缩容（ Horizontal Pod Autoscaler ），可基于 CPU 利用率、平均内存利用率等指标自动扩缩服务的副本数量。

图3 AIStation平台GPU共享系统的HPA

提供基于 QPS 的细粒度 GPU 资源扩缩容能力。 AIStation 支持实时服务请求流量的水平自动扩缩（ Traffic Pod Autoscaler ），可根据在线服务访问流量（ QPS ）指标自动增加或减少服务副本数量，用户可以配置上线服务的预设 QPS ，当服务请求大于（或小于）预设值时，后台程序会自动判断并执行扩缩容操作，在满足实例副本的资源申请配额条件下，按照细粒度的资源调度方式申请最佳的 GPU 资源。

图4 AIStation平台GPU共享系统的TPA

极低的计算性能损耗。 AIStation 平台 GPU 共享系统的性能损耗很小，不会对用户应用的性能产生影响。其劫持调度器采用 C++ 编写，并且采用了 Pod 代理来接收用户应用的 GPU 内存申请和 GPU 时间片申请请求， Pod 代理可以处理绝大多数的来自用户应用的请求，只有在用户应用需要重新申请 GPU 时间片时， Pod 代理才需要将用户应用请求转发到劫持调度器。这样的架构设计能够避免劫持调度器过于繁忙而造成系统性能下降的问题。我们进行了如下的性能损耗测试，加速卡型号： NVIDIA GPU Tesla T4 ，软件： TensorFlow Benchmark ，深度学习模型： ResNet50 ，精度： FP32 ， BatchSize=1 、 4 、 16 ，性能数据如图 5 所示。

图5 GPU共享与GPU直通的性能对比

GPU 共享与 GPU 直通（应用的容器直接运行在 GPU 上）在不同 BatchSize 的情况下，性能对比如下：（ 1 ） BatchSize=1 时，性能损耗约为  1.3% ；（ 2 ） BatchSize=4 时，性能损耗约为  0.37% ；（ 3 ） BatchSize=1 时，性能损耗约为  0.7% ，从测试数据中，可以看出 GPU 共享与 GPU 直通的性能非常接近，几乎不受影响。

AIStation 基于业务场景设计

无侵入式架构设计。 AIStation 具备无侵入特性。业界的一些 GPU 共享产品要求对用户应用、 CUDA Runtime 、 CUDA Driver 、或者 NVIDIA Driver 做出一定的修改，这会给很多用户带来困扰，同时会带来一些业务不稳定的问题。而 AIStation 不需要做上述修改，可以轻松移植到其它平台中，并且只需要 YAML 和 Docker Images 即可部署，支持开箱即用。

高可用（ HA ）设计。 AIStation 平台 GPU 共享系统的每个控制组件都采用高可用设计，每个主节点上面都会有一个 GPU 共享系统 Controller 模块和一个 GPU 共享系统 Scheduler 模块。在同一时间，每个模块的多个实例中只有一个是 Leader ，这个 Leader 负责本模块的业务处理，如果一些硬件问题或者网络问题导致此 Leader 挂掉了，那么 Leader 选举机制会立刻选举出新的 Leader ，实现了控制组件的高可用机制。

精细化监控设计。 AIStation 可对每个用户应用 Pod 的 GPU 利用率进行实时监控。它计算每个应用 Pod 的 GPU 利用率，然后借助 TSDB （时序数据库）存储这些数据，从而实现了精细化的 GPU 利用率实时监控。

典型案例

某金融行业客户案例

在某金融行业客户的保险业务中，用户生产环境目前包括图像识别服务、 OCR 识别服务及语音识别服务，用于支撑企业内部运营管理及线上业务办理，用户希望构建统一的算法应用平台，集中管理不同 ISV 算法应用，提高资源利用率。

生产环境的厂商应用按裸机方式或者 docker 方式进行烟囱式部署管理，资源利用率较低，并且大量 OCR 服务在服务请求波谷时，对 GPU 资源依然采用整卡占用的形式，严重影响 GPU 资源的复用效率，导致其他服务存在大量推理计算时，需要进行人为干预，如果调峰不及时还会出现请求响应不及时、计算延迟较高、计算中断等一系列问题。

图6 烟囱式部署与GPU共享部署对比

客户启用 AIStation 推理平台后，上述问题得到了根本性解决，大规模推理业务场景下的资源管理能力显著提升。其中， GPU 资源的复用率提升了 300% ，有效缓解了“任务多、加速卡少”、“负载计算少、资源占用多”等问题，使客户能够灵活应对各种不同类型的线上推理服务，极大提升了业务系统的稳定性。

某能源行业客户案例

某能源客户场景有 2 台 8 卡 V100 （ 32GB 显存） GPU 服务器， 28 人开发团队，客户希望能够合理分配这 16 张 GPU 卡给开发者做推理测试。因为人均不到一张 GPU 卡，如何合理高效的分配使用 GPU 资源，是用户急需解决的问题。

图7 GPU卡较少，而用户较多

用户在使用浪潮 AIStation 以后，通过设置 GPU 共享策略，将每个 GPU 切分为 8 个实例，每个实例可以使用 4GB 的显存，原来的 16 块 GPU 卡相当于变为了 16*8=128 个实例供开发用户使用，每个用户可以分到 4~5 个实例。每张 GPU 卡的利用率提升为原来的 8 倍。

图8 AIStation将每张GPU卡划分为8个实例