GPU as Code：趋动OrionX产品的创新之路

在当今快速发展的云计算和DevOps领域，IaC (Infrastructure as Code) 已经成为提升IT基础设施管理效率的关键实践。趋动科技的OrionX产品，通过软件定义GPU硬件，为开发者和运维团队提供了一种全新的AI算力资源管理方式。本文将深入探讨OrionX如何通过"GPU as Code"的理念，实现GPU资源配置和管理流程的大幅度简化，以及这一创新实践如何为企业的运营效率和业务发展带来显著的正面影响。同时，来自视源股份刘卓，也将从企业AI算力发展和实践的视角，分享他对OrionX理念价值的深刻见解。

1. GPU as Code的实现与优势

OrionX通过环境变量的设置，实现了GPU资源的动态管理和自动化部署。开发者可以通过简单的环境变量定义，如ORION_VGPU、ORION_GMEM、ORION_RATIO等，来精确控制GPU资源的分配。这种环境变量的设置方式，不仅简化了配置过程，还提高了资源分配的灵活性和可重复性。开发者可以在代码中直接引用这些环境变量，实现自动化的资源部署和扩展，从而加快了开发周期，降低了运维成本。

一种是部署镜像时的Yaml里的设置，其申请GPU资源部分代码块如下：

#用来申请Nvidia物理GPU
resources:
  limits:
    nvidia.com/gpu:2 
#用来申请OrionX vGPU，env部分为可选（Nvidia）
resources:
  limits:
    virtaitech.com/gpu:2
  env:
  - name :ORION_GMEM
    value :"2000"
  - name :ORION_RATIO
    value :"30"
  - name:ORION_VGPU
    value:"1"

申请其它卡类型资源（物理和虚拟卡都支持）：

#寒武纪MLU：
resources:
  limits:
    virtaitech.com/mlu = 1
    virtaitech.com/mlu-mem = 4000
    virtaitech.com/mlu-ratio = 50

#海光DCU：
resources:
  limits:
    virtaitech.com/dcu = 2
    virtaitech.com/dcu-mem = 4000
    virtaitech.com/dcu-ratio = 60

#华为NPU：
resources:
  limits:
     virtaitech.com/npu:1
  env:
  - name :ORION_DEVICE_TYPE
    value:"NPU"
  - name :ORION_DEVICE_NAME
    value:"Ascend 910"
  - name :RION_VDEVICE_TEMPLATE
    value:"vir02"

更重要的是容器部署之后，例如在一个Jupyter Notebook的开发容器里，开发者可以根据实际对于GPU的需要来调整对于资源的变更，例如：

import os
# 更新环境变量以调整GPU资源
os.environ['ORION_GMEM'] = '4096'
os.environ['ORION_RATIO'] = '50%'
os.environ['ORION_VGPU'] = '1'
# ...更多环境变量设置...

通过export一个环境变量，即可更新应用程序的运行GPU的环境，OrionX提供了丰富的环境变量来进行控制，例如：OrionX提供了丰富的环境变量来进行控制，例如：

ORION_GMEM=4096
ORION_RATIO=50%
ORION_VGPU=1
ORION_RESERVED=0
ORION_DEVICE_ENABLE=1
ORION_CROSS_NODE=1
ORION_DEVICE_NAME=H800
ORION_DEVICE_TYPE=GPU # 还可以指定 MLU，DCU，NPU（24年会增加更多）
ORION_K8S_NODE=node1

通过这种方式，用户不仅可以变更GPU资源，还可以在开发容器里实时变更GPU的型号，甚至是更换GPU的厂商，可以说是非常方便。对开发者而言，GPU设备的调遣只需要一个变量的指定即可触达。这是目前其他的基于容器的GPU共享技术所不能做到的，只有真正的软件定义的GPU才能实现这样的能力。另外，正如系列文章的第一篇《GPU over IP/IB》中提到的，OrionX管理的是数据中心级的GPU资源池，所以只要资源池有满足条件的资源即可被当作代码进行调用。

2.OrionX的自定义GPU规格的能力

OrionX的自定义GPU算力规格的功能，允许用户根据业务需求，将物理GPU设备定义为不同的规格化资源。例如，用户可以创建类似virtai.small、virtai.prod、virtai.dev等自定义规格（名称可以按命名规范任意指定），这些规格分别对应不同的算力和显存规格。在代码中，开发者只需指定所需的自定义规格，OrionX便会自动从资源池中分配相应的GPU资源。这种自定义规格的能力，不仅提高了资源管理的灵活性，还使得资源分配更加直观和易于理解，极大地提升了开发效率。

OrionX提供了命令行来进行自定义GPU规格的创建、更新和删除。例如，创建一个virtai.dev的规格用来提供给开发者：

orioncli add virtai.dev --display-name="GPU for internal dev" --memory=40000 --physical-devices='[{"device_name":"NVIDIA H100","ratio":50},{"device_name":"NVIDIA A100","ratio":100}]'

在这个例子中，virtai.dev的自定义型号被映射到了一个40G显存 25% H100算力，或者一个40G显存50% A100算力上。这样可以比较方便的为用户提供基于一定规格显存大小的自定义算力规格。在实际的场景中，最好映射几乎同等算力，相同显存大小的规格给同一个自定义型号以避免较大的性能差异。

3. OrionX的动态资源管理

OrionX的一个核心特性是其动态资源管理能力。作为软件定义的GPU硬件，OrionX能够实现资源的动态申请、动态释放和自动回收。这意味着开发者在编写代码时，无需手动申请或释放GPU资源。OrionX会自动监控资源使用情况，并在任务完成后自动回收资源，为其他任务提供服务。这种自动化的资源管理不仅提高了资源的利用率，还减少了因资源管理不当而导致的系统瓶颈。

例如：在下面的Jupyter Lab的notebook里，代码块的前2个Cell在运行时，并未用到GPU资源，此时是不用占用GPU卡的，只有当第3个cell在运行，当第一个CUDA API指令执行的时候，系统才开始进行GPU资源的分配、执行，当命令执行完成之后，如果在设定的idle time之后并未有其他的API执行，GPU卡即释放可供其他API分时复用。例如：设置ORION_TASK_IDLE_TIME = 120，在没有cell运行120s之后，在IDE里会有一个显示：Application will be idle migration soon in 120 seconds which is set by env "ORION_TASK_IDLE_TIME"。当下一个Cell运行的时候，GPU资源会重新分配并执行API，本进程之前与GPU相关的上下文信息会进行恢复，GPU资源的切换对开发者是透明无感的。

在类似开发场景中，镜像在运行之前必须将GPU卡进行分配和绑定，只能做到静态分配。也就是GPU卡一旦分配给容器或者某一个Jupyter环境之后，无论使用与否，都与该容器绑定，无法实现资源的隔离和动态管理。

有些方案会将一张卡分给多个开发容器进行共享使用以提高生产效率，但是这种方案缺乏隔离性，容易出现争抢，OOM或分配不到资源报错。如果使用了其它厂商的GPU容器共享方案，虽有一定的隔离性，但却失去了弹性和动态管理的能力。

OrionX提供的软件定义的GPU方式，不仅能动态管理，还能进行动态切换GPU（热迁移），能最大限度的提升效能和使用GPU的灵活性。

4. OrionX针对GPU的任务排队与优先级管理

在GPU资源池资源紧张的情况下，OrionX不仅提供了任务排队的能力，还引入了任务优先级和等待时间的概念，从而在资源分配上实现了更加智能和灵活的管理。这种机制超越了传统的容器级别GPU排队，提供了针对GPU使用的全局排队解决方案。

当开发者提交的任务需要GPU资源，而资源池中的资源已被完全占用时，OrionX允许这些任务进入等待队列。在资源变得可用时，例如前面的任务完成释放资源，OrionX会自动将等待的任务提升到运行状态。这种任务排队功能确保了所有请求GPU资源的任务都能得到公平的处理，而不会因为资源的临时不足而失败。

OrionX引入了ORION_RES_PRIORITY环境变量，允许用户为任务设置优先级。高优先级的任务在资源分配时会被优先考虑，从而确保关键任务能够及时获得所需的GPU资源。同时，ORION_RES_QUEUE_TIME环境变量允许用户设定任务在队列中的最大等待时间。

这为用户提供了更多的控制权，可以根据业务需求和资源策略来调整任务的等待时间。

OrionX的任务队列和优先级功能带来了显著的改进：

自动化处理：用户无需手动重试任务，OrionX会自动管理任务的排队和执行。

资源状态监控：用户无需持续监控资源的可用状态，OrionX会根据资源池的实际情况智能调度任务。

优先级满足：对于有轻重缓急之分的等待任务，OrionX能够根据预设的优先级进行全局排列，优先满足高优先级任务的需求。

这种任务排队和优先级管理机制，不仅提高了资源的利用率，还提升了用户体验。它使得资源管理更加符合实际的业务需求，确保了关键任务的顺利进行，同时为非关键任务提供了合理的等待时间。OrionX的这一创新功能，为DevOps实践和AI应用开发提供了更加强大和灵活的资源管理能力。

5. OrionX在DevOps中的应用

在DevOps的实践中，OrionX的动态资源管理发挥了至关重要的作用。它允许开发者专注于业务逻辑的实现，而将资源管理的复杂性交给OrionX。这种自动化的资源调度优化了任务的执行效率，减少了排队时间，提高了开发效率。同时，OrionX的透明化管理确保了资源的公平分配，支持了多租户环境的高效运作。

在传统的DevOps流程中，资源的分配和管理通常是一个复杂且耗时的过程。开发者需要手动申请GPU资源，等待批准，然后才能开始工作。而且，一旦任务完成，他们还需要手动释放资源，以供其他任务使用。这不仅效率低下，而且容易导致资源浪费和分配不均。

OrionX的出现，彻底改变了这种状况。它通过软件化的方式，将GPU资源的管理变得简单而高效。开发者可以通过简单的环境变量设置，轻松地指定所需的GPU资源。OrionX会自动根据任务的需求，动态分配和调整资源。当任务完成后，OrionX会自动回收资源，无需开发者手动干预。

例如，在一个典型的CI/CD流程中，开发者可以使用OrionX来为不同的阶段分配不同的GPU资源。在代码构建阶段，可能只需要少量的GPU资源。而在测试和部署阶段，可能需要更多的资源。OrionX可以根据这些需求，自动调整资源的分配，确保每个阶段都能高效完成。

此外，OrionX的透明化管理确保了资源的公平分配。在多租户环境中，不同的团队或项目可能需要共享GPU资源。OrionX可以根据预定义的策略，如优先级、队列等，自动调度资源，确保每个团队都能获得公平的资源分配。

视源电子中央研究院在AI开发领域曾依赖于物理GPU卡。自从引入OrionX，他们发现，原先基于物理GPU卡开发的镜像无需进行任何改造，便能通过"GPU as Code"的便捷方式实现无缝切换。无论是进行小规模资源的开发，大规模资源的模型训练，还是适度资源的推理任务，OrionX都允许通过代码精确控制资源分配，从而实现了一个流畅的DevOps流程。这一转变不仅避免了传统手动资源分配、使用、监控和回收的繁琐流程，而且显著提高了开发效率和GPU资源的利用率。

此外，OrionX也提供了丰富的监控、告警、报表和资源管控的功能，这个在后续的系列文章里进行阐述。

6. OrionX面对开发者的价值

OrionX为开发者提供了一种无缝的GPU资源管理体验。开发者可以保持现有的使用习惯，通过熟悉的环境变量设置，轻松地在代码中指定所需的GPU资源。OrionX的资源池化管理确保了任务的顺畅运行，即使在资源紧张的情况下，任务也能自动排队等待资源就绪。此外，OrionX支持按需动态变更资源大小，开发者可以根据任务需求动态调整资源配置，而无需手动处理资源的申请、批准、释放和回收。这种自动化的资源管理，使得开发者能够更快速地完成任务，提高了整体的开发效率。

结语

OrionX通过实现"GPU as Code"，为GPU资源管理带来了革命性的变革。它不仅提升了开发和运维的效率，还为AI和HPC应用的开发提供了更加灵活和可扩展的环境。OrionX的动态资源管理能力，进一步简化了资源的申请、使用和回收过程，使得开发者可以更加专注于创新和业务发展。随着技术的不断进步，OrionX将继续在推动企业技术创新和业务发展方面发挥关键作用。本文作为系列文章的第二篇，旨在为读者提供一个关于OrionX在软件化GPU资源管理方面的全面了解，助力AI开发者和Devops。后续文章将进一步深入探讨OrionX的创新之路以及在不同行业中的应用案例和成功故事。