编程猫少儿编程网站,南宁市规划建设局 网站,公司网站模板中英文,php 设置网站根目录★深度学习#xff1b;模式识别#xff1b;图像处理#xff1b;人工智能建模#xff1b;人工智能#xff1b;深度学习算法#xff1b;强化学习#xff1b;神经网络#xff1b;卷积神经网络#xff1b;人工神经网络#xff1b;VIBE算法#xff1b;控制系统仿真#…★深度学习模式识别图像处理人工智能建模人工智能深度学习算法强化学习神经网络卷积神经网络人工神经网络VIBE算法控制系统仿真机器学习高性能计算数据挖掘超算ACL算力计算机视觉PSUTransformerPLMSLMNLMLLMGalacticaOPTOPT-IMLBLOOMBLOOMZGLMRedditH100H800A100A800MI200MI250LaMAOpenAIGQARMSNormSFTRTX 4090A6000AIGCCHATGLMLLVMLLMsGLMAGIHPCGPUCPUCPUGPU英伟达Nvidia英特尔AMD高性能服务器蓝海大脑多元异构算力大模型训练通用人工智能GPU服务器GPU集群大模型训练GPU集群大语言模型生成式AIMLDLC图像分割预训练语言模型AI服务器GH200;L40SHBM3eGrace Hoppergracehopper异构计算集群集群管理资源管理系统 随着人工智能在工业和学术界大规模的应用深度学习训练需求日益迫切。各组织机构投入大量资金购置和搭建配置GPU和InfiniBand网卡异构计算集群。集群管理系统(也称平台)支持模型训练提供作业、数据和模型管理并提供资源隔离。资源管理系统是深度学习系统的基础企业级场景下上层框架和应用通常在资源管理系统提供的资源上运行。 异构计算的主要驱动力来自于暗硅和异构硬件的发展趋势。数据中心硬件日益多样化用户以多租共享的方式使用硬件。因此统一管理需求逐渐产生。为管理计算和存储异构硬件通常需要在统一空间内对其进行抽象和管理最终实现用户对硬件透明化的使用。异构计算集群调度和资源管理系统在人工智能系统中类似于传统操作系统对底层异构资源如GPU、CPU等进行抽象对上调度深度学习作业并分配资源。在启动作业后还需进行资源隔离、环境隔离和作业生命周期管理。 异构计算集群管理系统简介 异构计算集群管理系统是一种系统软件负责管理计算机集群内的多个节点的硬件如GPU、CPU、内存、磁盘等和软件资源如框架、作业、镜像等并为计算机程序通常是深度学习训练作业提供通用服务如作业提交、调试、监控、克隆等。简而言之异构计算集群管理系统是一种管理和优化计算机集群内硬件和软件资源的系统软件旨在为深度学习训练提供通用服务。 一、多租环境运行的训练作业 多租环境提交运行作业
在企业级深度学习场景中大型企业通常拥有许多机器学习科学家和工程师并且拥有大量GPU服务器。为提高效率和资源共享面向深度学习场景设计的多租户平台系统备受青睐。如上图所示在企业环境下不同用户会提交不同框架如PyTorch、TensorFlow等的深度学习作业具有不同的资源需求如单GPU卡、多GPU卡共享一个物理集群以减少硬件资源的浪费。 当前深度学习场景下平台系统管理的资源是异构的如CPU、GPU等。与深度学习开发者独占服务器进行模型训练相比多用户共享多GPU服务器有很大的不同。这也为异构计算集群管理系统简称平台或深度学习平台的设计带来相应需求主要体现在以下几个方面 1、多作业(Job)和多用户 1每个用户为不断改进模型、超参数调优、调试和优化作业向平台提交大量作业。
2不同人工智能团队(如计算机视觉、自然语言处理、语音识别等)都使用平台。每个团队很多工程师会在同一时间段内向平台申请资源来执行作业。 2、作业环境需求多样 当前深度学习技术栈不够统一不同的用户可能使用不同的框架和库如TensorFlow、PyTorch、Hugging Face等。用户可能使用开源项目其中有些项目较老旧有些则使用最新的框架。用户不希望频繁地进行版本适配。此外开源框架的版本也可能不一致导致底层依赖如NVIDIA CUDA的版本也不同。在共享机器的情况下需要确保环境相互独立不受其他用户安装的Python、PyTorch等版本的影响。 3、作业资源需求多样 用户提交的深度学习作业包括分布式训练作业、单机训练或调试任务以及大规模分布式训练任务。这些作业的需求资源量各不相同有些需要更多的资源有些则需要较少的资源。即使申请的GPU数量相同不同的作业和模型也会导致资源利用率的差异。平台需要按需分配资源以减少资源的碎片化。用户希望作业能够像使用独占资源一样运行不受其他作业的资源和命名空间冲突的干扰以便尽快完成模型训练。平台需要实现作业运行期间的资源隔离以确保服务质量。 4、服务器软件环境单一 平台方在购买和部署资源时难以预测和规划用户未来的软件和版本需求这主要是因为用户使用的框架和库多种多样而且版本也不尽相同。为了简化运维平台方通常会统一操作系统和驱动并保持版本一致以减少兼容性问题。但这与用户多样化的环境需求相矛盾。即使部署不同系统和环境也难以精确地适配用户不断变化的需求。 5、服务器空闲资源组合多样 尽管平台批量购买同型号机器但因用户申请资源和作业生命周期不同资源释放后平台空闲资源组合非常多样需要设计调度策略提高资源利用率。 从上述问题可以看出需要统一的平台系统来支撑调度和资源管理。其在底层抽象和管理计算资源在上层为应用提供隔离且易用的作业运行环境。简而言之是支持深度学习应用管理分布式GPU服务器集群的操作系统。 二、作业生命周期 在展开平台组件与功能前先了解一下深度学习作业作业的生命周期在平台上是如何提交和执行。 GPU 集群 1、平台上作业生命周期 1作业提交与排队 用户首先在本地测试作业依赖环境并将其打包为镜像然后上传到公共镜像中心。接着将代码和数据等上传到平台的文件系统中。之后通过提交工具如Web、命令行、API填写资源申请、启动命令、部署方式、镜像、代码和数据路径等信息在提交时需要权衡资源需求和排队时间。 2作业资源分配与调度 平台在收到资源申请后会将其排队等待调度器的轮询。当调度器轮询到该作业时会根据集群的空闲资源状况和调度算法决定在哪些有空闲资源的节点上启动该作业。如果无法满足作业的资源需求作业将继续排队等待。如果提交作业失败或超时用户需要调整作业信息后重新提交。 3作业执行完成与释放 作业被调度后平台会在有空闲资源的节点上启动作业下载镜像挂载代码和数据进行资源限制与隔离然后启动执行。平台在执行中收集运行指标和日志以供调试。作业完成后平台释放资源继续分配给其他作业使用。 2、可以将作业在平台上的状态抽象为以下状态机 1)作业准备与提交触发作业提交动作 ●提交成功
●提交失败重新开始提交 2)作业排队触发作业调度动作 ●调度成功
●调度失败重新开始提交 3)作业部署运行触发作业执行动作 ●执行成功
●作业失败重试次数N重新开始提交
●作业失败重试次数N作业失败退出 用户的操作实际上是在这些状态之间不断切换最终达到作业成功执行或失败。如果执行成功用户可以在完成后获取结果和模型。 三、集群管理系统架构 异构集群管理系统架构 异构集群管理系统通常包含多个组件。其中调度器负责资源与作业的管理监控系统负责监控系统的健康状态并发出警报Web界面提供用户交互接口存储系统则用于存储数据、模型和代码。 1、平台的主要组件包括 1)集群调度与资源管理模块 统一管理集群资源调度作业到空闲资源上回收已完成作业的资源。控制平面可以选择Kubernetes、Mesos等系统也可以使用面向深度学习作业的定制调度器。 2镜像中心 存储Docker镜像供用户提交和共享镜像作业下载镜像。可以使用公共中心如Docker Hub也可以构建私有中心或使用云镜像中心。 3存储模块 扮演数据平面角色存储数据、模型和代码。用户上传和作业下载数据。 4作业生命周期管理器 部署、监控、重试作业以及诊断错误是单作业的控制平面所涉及的任务。在这个平面上可以构建自动机器学习系统而不需要考虑其他作业。在平台接口的基础上可以选择使用K8S Operator、Framework Controller或YARN AppMaster等工具来实现这些功能。 5集群监控与报警 监控硬件、服务和作业状态并进行报警是监控系统的一项重要任务。在这个过程中可以选择使用Prometheus、Grafana、AlertManager等开源系统来实现监控和报警功能。此外也可以开发自定义监控指标来满足特定需求。 6集成开发环境 为用户提供Web门户、REST API、IDE(如VS Code、Jupyter Notebook)等用于作业提交、管理、监控和调试。 7测试集群 为隔离生产环境可以部署一个小规模的测试集群用于开发和测试。 2、平台部署模式 1本地部署 一些公司出于数据合规等需求选择使用开源平台或自研平台进行本地部署保证数据和镜像在自有数据中心这对运维和开发工程师要求较高。需要自建数据中心或在已有基础设施上部署初始投资大且需资源规划。需要全职运维团队维护软件、监控等且需要平台服务软件的定制开发能力。硬件迭代速度快经过一段时间后容易淘汰更新又需要高成本。 2公有云部署 一些公司购买云的IaaS或PaaS服务来搭建平台减轻运维压力利用云平台的最新技术实现弹性扩缩容但数据和代码需上云长期成本高。初期投资小按用量付费大部分运维由云供应商完成适合初期使用。但一些公司出于数据合规无法全部上云。成本随规模增长可能无法承担。 3混合云 一些公司采用敏感数据在本地非敏感数据和弹性资源在云端的方案。 4多云 一些公司为防云供应商锁定或综合选择性价比会采用多云方案和工具。 本地与云部署成本趋势 训练作业镜像与容器 平台作业与开发体验 集群管理系统需要面对多个用户的作业共享服务器资源为解决环境依赖和资源隔离问题需要采用镜像和运行时资源隔离等机制。下面将从作业在集群管理系统上的依赖隔离、运行时资源隔离以及人工智能作业开发体验几个方面进行介绍。 一、深度学习作业 在本地机器或独占服务器上开发训练模型时环境问题较少还未暴露更多挑战。独占环境的情况如下:
●无需考虑依赖环境和资源隔离问题
●Python环境依赖路径在本地通过包管理器或环境变量隔离
●GPU环境依赖路径固定在本地通过环境变量切换
●数据直接上传到本地磁盘带宽高
●直接在磁盘执行启动脚本修改调试方便 如果环境准备好可以通过下面的脚本启动训练:
python train.py --batch_size256 --model_nameresnet50
{
// 作业名称
jobName: resnet,
// 镜像名称
image: example.tensorflow:stable,
// 输入数据存储路径
dataDir: /tmp/data,
// 数据结果存储路径
outputDir: /tmp/output,
...
// 任务规格:资源需求、启动脚本等
taskRoles: [
{ ... taskNumber: 1, cpuNumber: 8, memoryMB: 32768, gpuNumber: 1, command: python train.py --batch_size256 --model_nameresnet50 }
]
} 从作业提交规格示例可以看出当用户将作业提交到有4块GPU服务器时,平台需要提供以下支持: 1、环境依赖 1问题 平台集群中的机器系统和环境都相同如何支持用户使用不同的深度学习框架(如TensorFlow和PyTorch)、库和版本? 2解决方法 通过指定的image镜像名称解决环境依赖问题。用户需要提前将依赖打包构建为Docker镜像提交到指定的镜像中心供作业下载使用。 2、数据与代码 1问题 平台上运行的是深度学习训练作业每个作业需要输入数据和代码。如果直接上传到服务器会造成过大负载则无法复用数据和代码。 2解决方法 通过指定dataDir和outputDir路径来处理作业的输入数据和输出结果。用户提前上传数据和代码到平台指定的文件系统路径下未来平台会将网络文件系统中的数据和代码挂载到运行作业的机器上。 3、资源申请量 1问题 用户提交单GPU、多GPU或分布式作业平台无法静态分析作业资源需求如果不明确配置会导致资源浪费或不足。 2解决方法 用户明确声明所需GPU、CPU和内存资源平台根据策略分配匹配的空闲资源。 4、资源隔离 1问题 同一服务器上运行多个作业时,如何避免作业间互相干扰? 2解决方法 平台可以通过容器cgroup等技术对进程进行资源限定和隔离。 5、任务部署模式 1问题 对于分布式作业如果用户不说明平台无法知道需要启动的任务数。 2解决方法 用户明确告知需要启动的任务数量平台启动多个任务副本进行训练。 6、作业启动命令 1问题 平台需要知道作业的启动命令来启动和执行代码。 2解决方法 用户在作业中明确描述启动入口命令启动并执行代码。 二、环境依赖镜像Image 当用户在平台上执行作业时首要问题是本地环境与集群环境差异
●服务器没有预装所需个性化环境
●不同作业需要不同框架、依赖和版本安装繁琐且重复
●服务器上有大量重复安装的库占用空间
●深度学习特有问题需要安装CUDA、框架等 平台需要采用以下技术方案来解决 利用镜像隔离整体环境并在之上创建新环境以层级构建的方式复用每一个层级此方法既保证个性化环境同时也确保性能和资源消耗最小。此方法主要依赖主流平台通过Docker镜像来实现而Docker镜像则通过Union文件系统等机制实现高效存储。 Union文件系统联合挂载多个目录以形成一个合并的视图而Docker则利用此机制以更高效地存储文件和包。Docker支持多种Unionfs例如下一层的AUFS和更上层的OverlayFS。 下面将通过一个实例来理解和构建镜像以及使用方法。用户编写的Dockerfile可通过其中的命令构建和打包镜像构建成功后可上传到镜像中心。平台在启动作业时会下载镜像到服务器并使用它来配置作业环境。 PyTorch 镜像文件中包含的依赖
三、运行时资源隔离容器 当用户在平台上执行作业时如何避免作业间的资源争用干扰实现资源隔离
●集群资源被共享如何确保作业进程不相互干扰和抢占资源?
●如何让不同作业在同一台机器上运行在独立的命名空间避免冲突?
●如何在保证隔离的同时使作业启动越快越好?
●深度学习的特殊问题如何隔离GPU的核和内存?
●平台通常使用容器技术解决运行时的资源隔离。容器主要通过两种机制实现资源隔离 控制组Cgroups可以控制、统计和隔离一组进程的资源(如CPU、内存等)。 命名空间Namespaces将系统资源包装在抽象中使每个命名空间中的进程拥有独立的资源实现命名空间隔离。
由于深度学习目前依赖GPU进行训练为让容器支持挂载GPUGPU厂商通常会提供针对Docker的特殊支持。例如NVIDIA提供nvidia-docker。用户可以参考其文档进行环境配置。 但由于GPU等加速器虚拟化支持不如CPU成熟目前主流是以加速器为粒度进行挂载和隔离无法像CPU那样进行细粒度的时分复用、内存隔离和动态迁移。 环境配置完成后用户可以运行挂载特定数量GPU的容器。例如通过以下NVIDIA Docker命令在容器中挂载2个GPU
nvidia-docker run --gpus 2 --rm nvidia/cuda nvidia-smi此命令会启动一个容器,并挂载2个GPU进容器,容器内可以看到这2个GPU。 四、从操作系统视角看 GPU 技术栈 操作系统通常负责进程的资源管理和多任务调度。在计算机中GPU被抽象为设备操作系统通过ioctl系统调用进行设备控制。有两种主要思路试图将GPU技术纳入操作系统的管理并提供多租户、虚拟化等功能支持 1、修改内核 将GPU设备驱动和调度逻辑集成到内核中通过扩展内核实现GPU的虚拟化和调度。但这种方法需要修改内核代价较大。 2、在用户空间实现资源管理组件 通过封装内核接口提供调度和虚拟化支持。这种方法兼容性较好也更容易迭代。已经有一些相关工作实现了用户级的GPU虚拟化管理。 将GPU纳入操作系统统一资源管理的目的是让GPU能够像CPU一样被多任务调度这是实现GPU多租户和自动化管理的基础。 CPU和GPU技术栈与操作系统抽象
从图中可以看出操作系统能够为CPU程序提供大量的系统调用支持同时也能对各种硬件进行抽象管理并支持用户的多进程与多租户。然而在GPU程序的情况下当前的模型更像是客户端与服务器之间的抽象GPU被视为一种设备CPU程序会向GPU提交作业并从其获取响应结果。然而操作系统对GPU本身的操作通常只能通过有限的交互与控制来实现通常使用的交互方式是ioctl。 五、人工智能作业开发体验Development Experience 在使用集群管理系统时人工智能算法工程师通常会使用以下工具进行人工智能作业与Python脚本的开发 1、客户端集成开发环境IDE 这种工具提供完整的开发环境可以进行Python开发、调试、语法高亮等功能例如Visual Studio Code。在人工智能场景下算法工程师主要使用VS Code进行Python程序开发、调试、语法高亮、智能代码完成、预装代码片段和版本管理Git的支持。用户可以根据自身需求更改主题、键盘快捷键、首选项并安装添加额外功能的扩展。 2、一站式人工智能开发插件 Tools for AI当前已改名为Visual Studio Code Azure机器学习扩展。此工具提供部署到云端或边缘的支持、常用深度学习库的支持、本地实验再部署到大规模集群、集成自动化机器学习以及通过CI/CD工具跟踪实验和管理模型。 3、代码完成工具 Kite for VS Code适用于VS Code的各种语言通过海量代码库训练人工智能模型提供智能代码完成服务包括智能感知、代码片段和光标跟随的文档AI代码完成。Kite支持Python等文件类型代码补全将大幅提升开发生产力这也是集成开发环境的优势。同时OpenAI也开源了Copilot进行常见语言和通用程序的智能化代码提示和程序合成Program Synthesis。使用VS Code等类似的客户端IDE进行开发的特点是功能强大调试、补全等功能完善。 通过Web界面提交作业到集群 开发者在提交作业到集群之前通常会经历三个阶段的开发。首先会在自己的开发环境中进行编程和测试确保程序没有错误后才会提交到集群平台。 Python人工智能程序的编写可以在本地使用VS Code等工具进行。VS Code通过插件方便了本地调试、代码静态检测和代码完成这能够显著提升开发效率同时不需要等待平台资源的排队。对于快速开发初始程序这种方法非常方便。如果本地设备没有GPU可以考虑安装CPU版本的深度学习框架进行开发和测试。 如果有可用的测试服务器挂载有GPU开发者可以在第二个阶段将作业提交到测试服务器进行测试。对于小规模作业也可以在服务器上完成一定程度的训练。然而GPU无法满足大规模多卡和分布式训练或者搜索空间巨大的超参数搜索需求。因此调试完成的程序可以在测试服务器上构建Docker镜像或上传数据等。在此阶段使用VS Code配合Remote SSH插件进行远程开发比较适合。 当用户确保程序开发完成时可以将作业提交到平台进行批处理作业的执行用户可以选择使用命令行工具、Web或REST API进行作业提交。由于GPU是稀缺资源可能会经历一定的排队流程例如数小时。在这种情况下用户可以利用闲暇时间继续开发新的作业或阅读论文寻找新的优化点或调试其他作业和模型。提交作业后可以参考下图的流程进行作业的完整执行。这个过程更适合通过Web访问作业监控界面、SSH登录到作业进行调试或者通过作业容器部署启动Jupyter进行交互式开发。 人工智能作业的不同开发环境 如图所示开发者通常会经历以下三个阶段本地开发、测试服务器开发和打包程序提交到平台执行。在每个阶段都会进行相应的操作。首先在本地开发阶段开发者会在自己的计算机上编写和测试程序。然后在测试服务器开发阶段会对程序进行更严格的测试以确保其能够在生产环境中正常运行。最后在打包程序提交到平台执行阶段开发者会将程序打包并提交到集群管理系统进行批处理。在执行作业的过程中开发者需要监控作业状态并进行调试以确保程序能够顺利执行并返回正确的结果。根据训练结果开发者可以调整和优化程序然后开始下一次的作业提交。 人工智能作业开发体验时序图 如下图所示当作业已经调试完成用户会经历以下的步骤与平台交互完成训练过程
●用户首先上传数据到存储
●上传镜像到镜像中心
●提交作业规格。填写数据镜像路径资源需求和启动命令行
●集群调度器调度作业
●空闲 GPU 节点拉取Pull镜像
●空闲 GPU 节点启动作业
●挂载文件系统
●作业运行启动
●作业监控不断汇报性能指标和日志用于观测与调试
●训练完成作业保存结果 提交到集群的作业生命周期 调度 平台调度器 在作业进程启动之前平台需要进行决策确定当前作业应该在哪些服务器和GPU上运行以及哪个作业可以优先执行进而进行调度决策。下面将围绕调度问题的抽象和优化目标以及可用于深度学习作业调度的传统调度算法进行介绍了解作业调度的经典问题和解决方法。 一、调度问题优化目标 调度是分配资源以执行任务的过程。在深度学习平台中资源包括处理器、GPU、内存等而任务则是用户提交的作业。调度活动由称为调度器的进程执行。调度器的算法通常旨在使所有计算机资源保持忙碌让多个用户高效地共享系统资源实现目标服务质量。 在运行深度学习作业的集群服务器上会部署一个操作系统进行作业管理与调度即异构资源管理系统也称作深度学习平台。该系统不同于传统操作系统其特点是运行的“进程”一般为深度学习作业。 每台服务器挂载多块商用 GPUInfiniBand 网卡等异构硬件。深度学习平台也要在整体上对作业提供所管理的硬件的“一定抽象层次”上的多路复用。同时由于整个系统不仅一个用户会提交多个作业整个资源池被多个公司内部组和用户共享这就是多租Multi-Tenancy系统。 1、作业延迟与吞吐相关指标 1排队延迟 描述作业在调度器队列中等待资源分配所花费的时间。排队延迟越低代表用户作业需要等待的时间越短越高效。其主要受两个因素影响 ●公平性
用户作业是否能够公平地分配到所需的资源 ●局部性和资源碎片化问题
可能导致资源无法分配和等待 2平均响应时间 从提交请求到产生第一个响应的时间量的平均值。 3平均作业完成时间 一批作业的平均完成时间该指标能够代表系统性能。如考虑分布式作业的局部性影响通信时间进而影响平均作业完成时间。 4完工时间 一批作业中第一个作业到最后一个作业整体完成时间时间越小越好。有些调度算法也考虑所有作业的整体完工时间作为优化目标因为最小化完工时间等价于最大化资源效率。 5吞吐 单位时间能完成的作业数量吞吐量越大越好。 2、平台资源利用率相关指标 1资源利用率 描述用于作业的资源占总资源的百分比利用率越高越好。 2资源碎片 作业分配后造成个别节点资源无法被再分配产生碎片问题。碎片越少代表资源浪费越少。也是和资源利用率相关的指标。 3、公平与服务水平相关指标 1公平性 资源使用在平台用户或组之间平均或按指定配额比例分配。 2服务水平协议 服务级别协议是平台和用户之间的承诺。如平台服务的公平性、质量、可用性、责任等在平台和用户之间进行约定和达成一致。
如下图所示平台中包含以下集群与作业的包含层级关系不同层次中蕴含不同的调度问题可以将之后涉及的面向深度学习调度算法也映射到其中的层级问题的解决方法。 平台中的作业调度问题总览 二、单作业调度—群调度 群调度是一种在并行系统中使用的调度算法用于调度相关的线程或进程在不同的处理器上同时启动和运行。深度学习作业通常需要群调度以确保所有必需的加速设备都准备好后才开始训练过程。如果没有使用群调度可能会导致问题的出现。因为深度学习作业通常需要同时执行多个任务如果有依赖任务没有启动已启动的任务可能会在等待同步点或频繁切换上下文而无法继续运行进而导致训练任务无法进行。 同时已启动的任务如果不释放资源可能会导致资源的浪费产生死锁现象。如下图所示两个作业都申请了部分资源但还需要其他资源才能启动这就产生了死锁现象。 并行启动执行作业可能产生的问题 通过利用群调度技术可以同时启动深度学习任务进程以解决之前提到的例子中的问题。如下图所示可以让作业A、B和C交替执行以确保所有任务能够顺利完成。这种方式让已启动的任务能够继续运行而不会因等待其他未启动的任务而造成训练中断或资源浪费。 并行执行作业可能产生的问题 当然群调度也存在一定的局限性。比如可能会增加资源碎片化的风险并且在共享集群中的利用率较低。如图中的t1和t2时间段GPU 7和8就处于空闲状态造成了资源浪费。 三、作业间调度—主导资源公平 DRFDominant Resource Fairness调度 在包含多种异构资源的系统中实现多作业公平的资源调度是一项挑战。深度学习作业需要使用CPU、GPU和内存等多种资源因此需要一种考虑多种资源的公平调度策略。DRFDominant Resource Fairness是一种用于多资源公平调度的算法通过使用主导份额的概念来比较多种资源的分配。 与其他策略不同DRF满足几个理想的属性。首先鼓励用户共享资源从而保证公平性。其次DRF是防策略的即用户没有动力通过谎报需求来增加作业资源的分配。用户基于最大最小公平谎报更多的资源则需要更多的排队时间。同时DRF是无嫉妒的即用户不羡慕其他用户的分配。最后DRF分配是帕累托有效的即不可能在不损害某些人利益的前提下使另一些人获益。 DRF调度策略的简要总结是通过同类型资源在集群整体资源中的份额确定主导资源。基于最大最小公平的针对多资源类型例如GPU、CPU的调度算法。 2个作业的DRF调度实例 以下的资源申请需求中主导资源是内存。 以下的资源申请需求中主导资源是GPU。 四、组间作业调度—容量调度Capacity Scheduling 除能够公平地分配多个作业外平台管理员还需要考虑如何让多个小组共享集群以及如何为多个组织共享集群资源。在共享集群资源的同时还需要为每个组织提供最小容量保证以确保能够获得所需的资源。空闲资源应该能够弹性地供其他组织利用以提高资源利用率和减少资源浪费。 相比传统容量调度调度深度学习作业也需要考虑调度 GPU 及 GPU 显存容量。Capacity Scheduler是大数据平台中常用的主流调度器可以将深度学习训练作业和大数据作业都视为批处理作业。允许多个租户安全地共享一个大型集群并在分配容量的限制下及时为应用程序分配资源。 以下图为例Team A、B、C共享集群每个组都有多个用户每个用户都会提交作业使用集群资源。如果不考虑组间公平性Team A即使再申请45的资源如果没有使用完毕也会造成浪费同时也会让Team C无法申请资源产生饥饿现象。 资源占用过多造成其他组无法分配资源问题 所以容量调度为支持多租Multi-Tenant资源共享设计了以下的策略集合 1、提高利用率Utilization 1虚拟集群Virtual Cluster组能够看到的是虚拟资源视图并不绑定具体机器作业启动后才会分配相应的资源这样有助于提高资源利用率。 2层级队列Hierarchical Queues支持队列的分层结构以确保在允许其他队列使用空闲资源之前在组织的子队列之间共享资源从而提供更多的控制和可预测性。 3队列内可以正交组合其他作业间调度算法如先进先出FIFODRF等。在异构计算场景中仍然可以采用适合多维资源调度的其他自定义调度器。 2、多租与提升公平性Fairness 1从某种意义上说队列将分配到网格容量的一小部分因为它们可以使用一定容量的资源。提交到队列的所有应用程序都可以访问分配给队列的容量。管理员可以对分配给每个队列的容量配置软限制和可选的硬限制。 2允许多用户以多租形式使用集群。控制单用户的可以消耗的最大资源防止其占用过多资源导致其他进程无法申请资源。 3、弹性和SLA
1奖励资源Bonus Resource 对于其他组没有使用的资源可以临时免费出让给有需要的团队但当资源持有者需要时则需要抢占资源归还给持有者。
2抢占Preemption配合奖励资源使用保证对用户提供的服务等级协议SLA 如下图所示当管理员配置最小和最大的组使用资源限额这样能够确保组与组之间都有可用的资源。 容量调度 五、虚拟集群Virtual Cluster机制 在集群内组和用户所看到的的资源配额一般情况下并没有绑定到具体的物理机器而是在调度后决定作业部署的物理机器。这背后是通过虚拟集群 (Virtual Cluster) 映射所实现的。而虚拟集群和之前介绍的控制组Cgroups的设计较为类似。在此会看到很多集群产生的问题在传统的操作系统中都能找到类似的设计问题与原则。 如下图所示虚拟集群会配置用户组的配额和视图物理集群是在调度后在运行时绑定的。这样可以大幅提升资源利用率减少资源碎片。 虚拟集群和物理集群映射与绑定 六、抢占式调度 一些集群管理员希望通过策略共享虚拟集群内的空闲资源以减少组内资源的浪费但单纯出让资源并不能保证原有用户能够随时回收对应的配额资源从而无法保证对原用户的SLA服务等级协议。这个问题可以通过抢占调度来解决也就是当资源的原有用户需要资源时终止使用奖励资源的作业进程回收资源给原配额用户。抢占调度通常用于以下场景 1、让资源饥饿的作业或短作业抢占一定资源以降低作业的平均响应时间 由于深度学习作业的韧性并不完善因此一般不会为此类需求使用抢占调度。如下图所示APP2长时间无法得到资源就无法执行而其执行时间实际上很短。这就需要通过抢占机制进行调度让APP2获取一定资源执行以保证降低平均响应时间。 作业等待时间过长问题 2、出让虚拟集群的空闲资源形成奖励资源供其他虚拟集群中的作业使用从而提高整体资源利用率。 在深度学习中通常出于这个原因使用抢占调度。如下图所示A队列中配置10个可用资源但由于集群有空闲资源多提供20个奖励资源给C6和C7。此时如果C队列需要使用20个资源集群应该保证能够触发抢占。当APP1的C6和C7使用的资源被标记为可以被抢占后其资源可以通过以下步骤被抢占 1从过度使用的队列中获取需要被抢占的容器即队列A的C6和C7。
2通知作业即队列A控制器即将触发抢占。
3等待直到被抢占作业运行终止。 抢占强度 抢占式调度对深度学习作业带来挑战因为深度学习作业在被抢占时只能失败而在默认情况下无法像传统操作系统一样进行上下文切换。目前有些工作通过提供框架或设备驱动库层的检查点机制配合调度器实现抢占与恢复但由于并非原生支持因此存在一定的开销且支持的框架与场景有限尚未得到广泛应用。未来可以设计更好的深度学习检查点和恢复技术以减少抢占后作业失效造成的被强占作业资源无效使用的问题。 数据进行模拟看能否提升当前目标并超越基准算法。最后对结果进行分析并形成分析报告或论文。 面向深度学习的集群管理系统 下面将介绍针对深度学习负载和GPU服务器特点而设计的平台调度算法以更好地满足新负载和硬件的需求并提高资源利用率等指标。 一、深度学习工作负载的需求 1、深度学习训练作业 vs. 传统的数据中心批处理作业 1执行时间长 训练时间持续数小时甚至几天 2迭代计算 作业主干部分是迭代的计算每轮迭代可以切分为小时间窗口的任务 3内存数据量动态变化 在训练过程中不同的时间点做检查点有不同的内存数据量 4性能可预测性 资源消耗可预测性可以通过运行时监控获取 2、分布式深度学习训练作业的特点 1对GPU拓扑结构敏感 数据并行策略通信传递梯度模型并行策略通信传递中间结果张量GPU与GPU之间传输带宽容易形成瓶颈。所以考虑GPU亲和性的任务放置策略对降低分布式训练作业的完工时间有帮助。 2反馈驱动探索 在自动化机器学习场景下用户会一次性提交大量的深度学习作业。这些作业的特点是反馈驱动探索。用户通常会尝试多个作业配置多项工作并利用这些工作的早期反馈准确度误差等来决定是否优先考虑或终止其中的某些作业。 根据深度学习作业的特性和硬件体系结构软件栈和硬件栈的支持可以协同设计面向深度学习的作业调度策略以提升资源利用率等指标。 二、异构硬件的多样性 深度学习作业训练时主要的计算单元是GPU而用于这种计算的服务器通常会挂载多块GPU。这种硬件体系结构在某些方面与传统的数据中心作业使用的服务器有所不同因此也带来了一些挑战。 1、通信代价 由于多块GPU之间的互联方式多样不同的放置方式可能会受到GPU拓扑结构的影响进而影响数据通信的代价和性能。GPU根据一定的拓扑结构挂载在PCIe总线或交换机上因此GPU与GPU之间的通信可能会在节点内跨越PCIe、PCIe交换机或者在节点之间跨越InfiniBand或以太网。 2、资源争用 由于作业本身可能会与其他作业共享服务器、数据总线等资源因此也会受到来自其他作业的争用和干扰。GPU拓扑结构与任务的放置方式会影响多卡与分布式作业的训练性能。因此可以考虑启发优化策略即根据集群和服务器节点的GPU拓扑结构的亲和性来调度任务。 三、深度学习平台的管理与运维需求 深度学习平台需要对上管理深度学习模型训练作业对下管理以GPU和InfiniBand为代表的异构硬件平台管理与运维也面临一些挑战。相比机器学习工程师、数据科学家等使用平台的用户深度学习平台管理员更加关注以下的设计目标 1、效率 GPU集群价格昂贵更新换代频繁如何有效地规划集群提升投入产出比以及如何在现有集群中减少资源碎片提升利用率是平台管理员面临的重要挑战。调度算法在一定程度上能够优化和提升集群的资源利用率。 2、公平性 使用深度学习平台的用户既有工程目的也有很多是科研目的。在训练生产模型的同时也有一些是研究投稿、赶论文截止的需求。这使得相比传统批处理调度场景用户有类似特定时段的峰值资源使用需求。平台需要保证各组资源使用的公平性同时提前规划好用户的资源使用同时兼顾峰值利用需求需要管理员设计好相应的策略。 3、稳定性 1由于深度学习框架的设计者在初始没有像大数据社区一样把容错当成第一要义框架提供基础的检查点机制但是需要用户控制没有自动备份与恢复的支持在之后的设计版本和社区工具中才有弹性等功能的支持。这给底层平台带来比较大的运维负担。 2由于节点上的异构硬件也有一定概率产生硬件问题例如GPU故障造成平台稳定性的挑战。如何高效、敏捷地发现和修复故障除了工具的支持还需要系统化的系统设计、开发流程设计与管理策略设计共同作用。 4、可维护性 平台团队同时在开发和运维平台可维护性也是平时减少运维负担的一个重要考虑的因素。通过微服务等手段将功能模块尽可能地拆分能够让故障的定位与修复最小化同时良好的DevOps流程搭建、敏捷的开发与项目管理也为平台的可维护性提升起到关键的作用。 5、用户体验 用户体验良好并统一的作业提交、作业管理与调试工具能大幅提升用户的开发生产力同时也能减轻平台运维工程师的负担。 除以上指标平台也会关注性能吞吐、完工时间等指标。平台本身模块众多涉及的外部交互的软硬件多样使用和维护的用户也很多所以其面对的问题场景较为复杂。作为平台设计者和使用者需要全面考虑性能只是其中的一个环节还要以系统化的视角去设计和管理整个异构资源为上层应用负载与用户提供更加透明与便捷的用户体验。 四、深度学习负载与异构硬件下的调度设计 下面将从深度学习平台的调度算法入手介绍考虑不同设计目标和侧重点的调度算法设计。这些调度器由于设计目标不同所基于的假设也不同同时实现和对作业的入侵性也不同。因此在选用和设计调度器时需要考虑不同算法的优劣势并根据平台现状酌情选择。 1、框架与平台协同设计的调度器设计 1反应模式Reactive Mode 类似于传统调度器的事件驱动设计根据不同的事件和状态如作业到达、离开、失效触发调度策略。可以将其整体策略抽象为一个状态机。 分布式作业调度受局部性影响 通过图表可以看到将同样需要2块GPU卡的作业分别调度在相同PCIe交换机、跨交换机和跨节点下进行部署运行会产生40%~5x的降速。因此对于多卡作业考虑部署的局部性通过亲和性调度可以让作业执行更快节省更多的资源执行其他作业从而对整体完工时间有益并提升资源利用率。 当触发调度时该调度策略优先考虑亲和性在调度过程中按照以下优先级考虑和排序节点进行作业分配以减少深度学习作业的数据I/O开销并提升性能。其优先考虑的待分配节点优先级为 ●拥有相同亲和性的节点。
●还未标注亲和性的节点。
●有不同亲和性的节点。
●进行超额订阅在有相同亲和性的节点暂停和恢复其他作业。
●不满足以上条件则作业排队等待。 以图为例调度器将需要1个GPU的作业放在一起但需要2或4个GPU的作业放置在不同的服务器上。此外通过选择负载最小的服务器试图平衡每台服务器上的超额订阅负载以防止1个GPU需求作业的服务器中各有6个1个GPU需求的作业。 16 块 GPU 集群中Gandiva 调度实例
2内省模式Introspective Mode 应用于作业执行后持续监控并定期优化当前作业的放置Placement同时通过扩展框架支持细粒度的检查点和恢复功能为后续备份与迁移策略提供基础原语的支持。通过不断监控作业利用率和节点资源利用率进行作业的装箱Bin Packing、迁移Migration、增长收缩Grow-Shrink、超额订阅和时间切片Time Slicing进而提升整体资源利用率降低作业的完工时间Makespan。 装箱Bin Pack是指在保证GPU显存约束的情况下根据浮点运算量将更多的作业装箱到相同GPU提升资源利用率。时分复用Time Slicing则是利用框架层或底层实现的检查点和恢复机制多个作业可以通过时分复用共享单块GPU。这可以类比于一种粗粒度的进程上下文切换Context Switching机制。 迁移Migration则是利用框架层或底层实现的检查点和恢复机制当有空闲资源或奖励资源时动态迁移作业使用奖励资源加速训练。当作业需要被抢占以归还资源时迁移作业保证作业之前的训练不失效。 上图展示了一个集群实验的示例。在多作业调度的场景中有4个需要2块GPU的作业这些作业都已经调度但其中3个作业没有好的亲和性J1、J2和J3只有J0的GPU被打包分配到了相同的节点。3分钟后一个使用DeepSpeed框架训练的作业训练完成并释放8块GPU其中3块在图中以绿色圆圈表示并分布在不同服务器。这三块GPU有潜力提升当前多个作业的训练效率。 调度器启动迁移流程重新分配J1、J2和J3到放置在一起的GPU。为减少碎片选择将空闲GPU最多的服务器上的作业进行迁移。然后开始迁移正在运行的作业从当前服务器空闲GPU更多的到另一个服务器空闲GPU更少的以便同作业的任务可以在同一台服务器的GPU上执行。 Gandiva不断重复这个过程直到非空闲服务器上的空闲GPU数量小于一定阈值实验中使用3/4作为阈值或者直到没有作业能够受益于作业迁移。 共享资源集群中Gandiva 进行作业迁移实例 2、面向特定场景问题多租的调度器设计 排队延迟问题 上图展示两个月内的日志数据涉及一个拥有2232个GPU的集群11个租户私有集群共享多租集群以及HiveD优化后的共享多租集群情况。其中红色线条显示了由于多租环境下的要求作业需要满足节点亲和性硬约束尽可能将作业调度到通信距离更近的节点导致平均有7倍的延迟。HiveD OSDI 提出如果调度深度学习作业时同时考虑多租环境和GPU亲和性会尽可能将亲和性高的资源整体分配给作业这会导致集群调度容易出现排队延迟较高的异常。 HiveD通过设计多级单元格Cell结构并采用伙伴单元格分配Buddy Cell Allocation算法以确保在满足上述约束的前提下资源能够高效分配降低排队时间和资源碎片化。同时HiveD能够与其他调度器兼容集成使用。 下图展示了四个级别的单元格结构GPULevel-1、PCIe交换机Switch(Level-2)、CPU套接字SocketLevel-3和节点级别Level-4。当前实例集群有一个机架由四个8-GPU节点组成由三个租户A、B和C共享。 HiveD机架的多级单元分配示例 蓝海大脑异构集群管理解决方案 随着企业规模逐渐扩展特别是私有云数据库架构中经常存在多种硬件机型和操作系统版本对这些硬件进行批量更换和升级是一项高风险、高成本的工作。蓝海大脑异构集群管理解决方案不仅可以协助企业充分利用现有设备还提供了平滑过渡方案为新型硬件、异构芯片的灰度替换提供支持。同时该解决方案还支持国密算法加密副本的混合部署为企业国产化升级提供安全稳定的解决方案。 蓝海大脑异构集群管理解决方案通过主备集群架构备集群使用新型硬件完成了第一阶段的灰度验证期间对主集群业务没有任何影响。AI异构计算平台包含AI计算、AI存储、AI加速、AI容器四大核心套件具有高性能、高弹性、高速互联、高性价比等特性。AI计算方面提供基于自研GPU硬件架构X-MAN的高性能实例充分满足AI单机训练、分布式集群训练、AI推理部署等对算、存、传的性能诉求。AI存储方面基于AI存储架构从数据上云、数据存储、数据处理和数据加速为计算提供全链条的支撑。AI加速方面通过存训推一体化加速通过对存储访问、模型训练和推理的加速进一步提速AI任务。AI容器方面AI容器提供GPU显存和算力的共享与隔离集成PaddlePaddle、TensorFlow、Pytorch等主流深度学习框架支持AI任务编排、管理等。 一、业务挑战 1、高风险 传统数据库硬件的批量替换风险很高因为缺乏有效的灰度方案来逐步引入更改而异构复制方案又难以确保数据的一致性。如果同一批次硬件或操作系统存在统一问题往往会集中爆发严重的情况下可能对业务造成不可挽回的损失。 2、高成本 传统替换方案往往需要部署专属环境来进行长期验证这会产生高昂的资源并行成本。这些成本包括但不限于购买和维护额外的硬件、能源消耗和管理人力资源以监视和维护这些并行系统。 3、难以维护 搭建异构验证环境不仅消耗硬件资源而且使得整个数据库基础架构更加复杂维护起来更加困难。这种复杂性可能会导致潜在的错误和故障增加了维护成本和难度。 二、方案优势 1、兼容开放支撑海光、鲲鹏、Intel等多种芯片及其生态满足不同的用户和场景需求 兼容多种类型的芯片包括海光、鲲鹏和Intel等并且可以支持这些芯片的生态系统。 2、功能一致数据库自动适配用户无需区分底层的芯片形态透明无感 自动适应不同的底层芯片形态无需关心底层的硬件细节感觉就像在使用一个统一的功能一致的数据库。 3、数据一致支持异构芯片副本数据一致性校验确保数据一致性和正确性具备容灾切换能力 保证在异构芯片上的副本数据保持一致性通过数据一致性校验来确保数据的准确性和一致性。同时这个系统还具备容灾切换的能力可以在发生故障时快速切换到备用系统上。 4、混合部署支持多副本混部、主备集群混部、机房混部等多种形态支持长期混部运行 支持多种部署形态比如多副本混部、主备集群混部和机房混部等。不同的部署形态可以满足不同的业务需求并且系统还支持长期混部运行使得系统的可用性和稳定性得到了极大的提升。 5、灰度切换支持按可用区Zone切换最细粒度支持按表分区灰度切换支持平滑灰度迁移替换 支持灰度切换用户可以选择按可用区进行切换最细粒度可以按表分区进行灰度切换。 6、灰度加密支持国密算法加密副本的混部为全局开启加密存储提供平滑过渡方案 支持使用国密算法进行加密可以在混部过程中对数据进行加密为全局开启加密存储提供了平滑过渡方案。 7、异构资源统一管理提供多集群的计算、存储、网络等资源的统一视图 并实现多集群网络打通、镜像统一管理 提供多集群的计算、存储、网络等资源的统一视图实现多集群网络打通和镜像统一管理。 8、构建基于多种指标的自动伸缩策略搭配负载均衡器实现业务弹性 基于多种指标的自动伸缩策略结合负载均衡器可以实现业务的弹性扩展和收缩保持业务的高可用性和性能。 9、支持x86/ARM/国产化等多架构裸金属服务器的管理帮助用户实现上电自动发现、一键部署开通与统一网络管理 支持x86、ARM和国产化等多架构裸金属服务器的管理并且可以帮助用户实现上电自动发现、一键部署开通和统一网络管理等功能。 10、实现与虚拟机、容器的业务网络打通 帮助用户实现与虚拟机和容器等不同环境之间的业务网络打通使得不同环境之间的通信更加顺畅和高效。 三、应用场景 1、高性能计算(HPC) HPC领域利用异构集群进行天气预报、地震分析、石油勘探等科学计算。典型配置是使用多核CPU服务器组成主集群,同时加入GPU服务器用于并行加速。也会采用不同的网络拓扑和互联来优化吞吐和延迟。 2、人工智能(AI) AI训练任务会使用成百上千张GPU来搭建规模巨大的异构集群例如NVIDIA的DGX SuperPOD。针对不同的训练阶段,可以灵活使用不同型号的GPU服务器。AI推理任务则会采用专门的AI加速卡,按需弹性部署。 3、大数据分析 大数据平台如Apache Hadoop、Spark会搭建以标准X86服务器为中心的大规模集群并加入GPU服务器用于机器学习算法的并行加速。不同类型的分析任务可以负载到不同规格的服务器上。 4、科学计算 利用异构集群进行天文统计学分析、粒子物理模拟、量子化学计算等。除了GPU服务器,也会采用FPGA、ASIC等专硬加速器进行优化。 5、工程设计 汽车、航空航天的设计需要进行复杂物理仿真,通过异构集群进行并行仿真可以大幅提升效率。此外还需要使用GPU渲染、图像处理。 6、金融 金融量化交易使用异构集群提升回测和交易性能。加入FPGA可以实现超低延迟的高频交易。区块链也需要大规模挖矿集群提供算力。 7、军事国防 异构集群可应用于军事仿真,指挥控制,图像识别等任务。出于安全考虑敏感应用会采用定制化芯片。
