龙空技术网

惊人的算力成本背后,自动驾驶公司如何加速研发创新

CSDN 379

前言:

此时兄弟们对“测试开发工程师和算法工程师”大约比较关心,你们都需要学习一些“测试开发工程师和算法工程师”的相关内容。那么小编同时在网摘上网罗了一些关于“测试开发工程师和算法工程师””的相关资讯,希望各位老铁们能喜欢,姐妹们一起来了解一下吧!

【摘要】AI算法模型的开发,测试和训练是自动驾驶公司最重要的工作之一,它们都需要大量GPU算力来支撑。然而,“一人一卡”的简单独占式GPU分配方式会导致GPU分配率高但实际利用率低,造成大量算力的浪费。基于远程GPU的GPU池化技术能够做到动态分配和自动释放GPU资源,是解决这个问题的关键方法。

当前业界在GPU虚拟化和池化方面的实践主要集中在三个层次:(1)硬件层;(2)内核层;(3)运行时层。在硬件层实现GPU虚拟化的主要代表是英伟达的MIG,它的优点是性能损失小,缺点是只支持固定比例的GPU切分,只支持部分英伟达高端GPU。在内核层实现GPU虚拟化的主要代表是英伟达的vGPU,腾讯的qGPU,以及阿里的cGPU。英伟达的vGPU的优点是支持全部企业级GPU,支持虚拟机(如KVM,VMware)和容器环境,缺点是只支持固定比例的GPU切分。因为英伟达并未开放其GPU驱动(内核态和用户态)的所有接口,腾讯的qGPU和阿里的cGPU只能支持容器环境,不能支持虚拟机环境。此外,英伟达的MIG和vGPU,腾讯的qGPU和阿里的cGPU都不支持基于远程GPU的GPU池化,不支持动态分配和自动释放GPU资源,不支持GPU资源的超分超售。本质上,英伟达的MIG和vGPU,腾讯的qGPU和阿里的cGPU都是站在单张GPU卡的角度来实现GPU切分,而不是站在整个数据中心的角度来实现对所有GPU资源的池化管理,因此并非完整的GPU池化方案。

在运行时层实现GPU虚拟化和池化的主要代表是趋动科技的OrionX GPU池化软件。OrionX的优点是(1)兼容性好,支持市面上所有型号的英伟达GPU;(2)功能完备,支持虚拟机和容器环境;(3)性能优异,即便是远程GPU也只引入了非常小的性能损失;(4)使用灵活,支持基于远程GPU的GPU池化,支持动态分配和自动释放GPU资源,支持GPU资源超分超售;(5)管理简单,具有完整的控制面,支持通过GUI,命令行以及RESTFUL API来管理整个数据中心中的所有物理和虚拟GPU资源,提供GUI界面来可视化所有物理和虚拟GPU的监控和告警信息等;(6)企业级功能完备,支持故障卡自动隔离,GPU任务热迁移,软件自动灰度升级等。

OrionX的主要缺点是,由于需要支持已公开的英伟达用户态驱动和库接口,同时还要实现整个数据中心GPU池化所需的管理平面,自身的研发工作量非常巨大,同时远程GPU的性能优化难度很高。作为自动驾驶领域的深耕者,文远知行通过对当前主要技术路线和产品的仔细分析,认为运行时虚拟化是GPU池化技术的基础,并选择了趋动科技OrionX GPU池化软件来建设弹性GPU资源池,更从容地开展自动驾驶技术的研发工作,加快在该领域内开拓创新的步伐。

作者 | 文远知行 陈飞,趋动科技 陈飞 责编 | 梦依丹

在新一轮科技革命背景下,汽车智能化发展已成必然趋势。这当中,作为“智能化”核心之一的自动驾驶,在监管、技术和商业化方面持续积累、不断完善,即将迈入发展快车道。据麦肯锡预计,中国未来很可能成为全球最大的自动驾驶市场。至2030年,自动驾驶相关的新车销售及出行服务创收将超过5000亿美元。

自动驾驶实现的过程,简单的来说是从感知、决策到执行,即依据特定的算法来分析当前场景下从各种传感器采集到的车辆本身及外部数据,做出决策后进行执行。这个过程实现对于人工智能(AI)/机器学习(ML)有着很深的应用和依赖。因此,自动驾驶发展的瓶颈主要在于这些AI算法模型上的突破。为了找到最佳的AI算法模型,算法工程师需要不断地调整超参数,对每天的路测数据进行处理,反复训练优化自动驾驶模型,并进行大量验证测试工作,以迭代出更准确的算法。这些工作的背后需要大量算力资源(GPU资源),且随着自动驾驶企业的业务发展、研发团队规模的扩大,企业不仅对GPU资源的需求在快速上升,在这些GPU资源使用上也逐渐面临着一些新的难题。

文远知行在自动驾驶研发中的资源挑战和运维需求

作为国内知名的L4级自动驾驶技术公司,成立于2017年的文远知行WeRide总部位于广州,在中国北京、上海、深圳、无锡、南京、圣何塞、阿布扎比、新加坡等地设研发和运营分部,团队规模超过1000人,其中大部分为研发工程师,在技术研发、商业模式和企业运营等方面都拥有丰富的海内外实践经验。

AI算法模型开发测试工作是文远知行最重要的工作内容之一。公司AI研发团队负责包括camseg(图像分割)、lidetect(激光雷达检测)、camdetect(摄像头检测)等在内的多种自动驾驶AI算法开发、模型训练以及测试。AI算法工程师需要独立的开发环境进行算法开发、训练、测试等工作,并且在算法开发与训练方面,尽管算法模型日益庞大和复杂,但依然要保障训练效率和计算性能。因此,最初文远知行采取为一个算法工程师固定分配1-2块GPU卡的方式来满足开发调试的需求。但这种方式也带来很大的不便:

1.资源分配不够灵活,难以快速满足每个算法工程师的用卡需求

文远知行数据中心内GPU资源需要支撑所有进行中AI项目开发、测试、训练等场景的使用。公司内部,不同阶段、不同类型的多个项目并存,这些项目所处的周期可能会不一样,模型复杂度和训练数据集大小也不一样,对于资源的需求也不一样;同时每个算法工程师需要独立的开发测试环境来开展工作,以及随着文远知行后期上线新的自研开发平台后,算法工程师人数和资源需求的增长都要求资源的分配要具备弹性和伸缩性,能够为不同项目、不同算法工程师快速配置所需的资源环境。而文远知行当前这种单人单卡的使用方式,不仅无法为资源灵活分配赋能,且会影响到算法工程师的工作效率以及研发项目的进度。因此,如何实现GPU资源的弹性伸缩和动态调度成为了迫切的需求。

2.低GPU利用率,导致硬件成本高昂

AI开发测试的工作过程中本身就需要耗费大量GPU资源。文远知行现有的GPU资源分配方式,即GPU卡一旦被分配出去即被独占,即使GPU卡闲置也无法共享给其他任务使用,会造成数据中心内GPU资源占用分配率高但实际利用率低,资源闲置情况频繁严重,增加企业在算力使用上的成本。另外,如果按照50-60人的研发团队规模来计算,要满足每个算法工程师的需求,最终总量上需要提供70~80张GPU卡才够用。这无疑会加剧文远知行在算力资源上的成本支出。因此,对文远知行来说,迫切需要设计和实现一种任务之间灵活动态共享GPU资源管理方式,提高GPU资源的使用效率,降低算力使用成本。

3.缺乏统一资源管理监控能力,导致管理复杂

文远知行研发团队日常工作涉及到大量AI开发训练工作流程,且随着算法工程师人数和资源需求的增长,如果缺少平台级的管理工具,会出现资源管理难、利用率低、没有统一监控告警等问题。文远知行意识到需要一个统一的GPU管理工具,全面掌控服务器内CPU、GPU、内存、网络I/O、任务负载、磁盘健康状况、资源使用情况等信息,通过监控告警规则设置快速发现问题并给予通知,帮助运维团队高效完成GPU资源运维管理工作。

综上,文远知行亟需一个行之有效的方案,来赋予开发场景下GPU资源弹性伸缩和统一管理的能力,提高其利用率的同时为每个算法工程师按需分配资源,并帮助团队高效完成GPU资源的运维管理工作。

文远知行对GPU池化技术的探索

针对GPU资源在使用过程中的问题,我们进行了技术探索,期待利用GPU虚拟化或GPU池化的技术去解决AI算法开发和运维的问题。

GPU作为一类外部设备,往往通过PCIe接口(或其它接口如SXM4等)和计算机系统连接。计算机上运行的软件,包括内核态、用户态代码对GPU硬件的访问经过硬件(包括CPU、PCIe桥片等)进行硬件执行处理之后,都会转化成PCIe的TLP报文发送到GPU硬件上,由GPU硬件进行解析并处理。PCIe的TLP报文格式是国际标准,是公开的,但是报文承载的信息是GPU硬件厂商自己定义的,一般都是非公开的。

出于系统安全、功能方面的需求,从CPU硬件到操作系统设计上明确划分了代码执行的两个运行态:内核态和用户态。在内核态中运行的代码受到操作系统以及CPU硬件的特殊保护,用户态的代码只能通过操作系统预先定义好的标准接口,调用内核态的代码。和设备相关的有 ioctl,mmap,read,write 等少量接口,而通过这些接口被调用的内核态代码一般是预先安装好的设备的内核态驱动。这样保证内核态和用户态的安全隔离,防止不安全的用户态代码破坏整个计算机系统。

图1: GPU应用全栈逻辑架构

各种各样的使用英伟达GPU的应用(程序),包括聊天机器人,也包括深度学习的各种框架,以及使用GPU的Photoshop,都运行在用户态。但是所有这些应用都并不能通过上面说的ioctl、read、write等接口直接和GPU的内核态驱动、GPU设备进行交互,原因在于英伟达并没有公开这些接口的使用方法。英伟达通过提供一层由GPU用户态驱动和GPU运行库构成的厂商用户态软件层来允许各种英伟达GPU应用使用GPU设备。这层对外提供的接口包括英伟达自家定义的 CUDA,也包括由社区共同制订的OpenGL、Vulkan接口等。

总结来看,从硬件到上层应用,有三层接口可以用来实现GPU虚拟化或者GPU池化,一是PCIe硬件接口层(硬件层),二是OS内核暴露的 ioctl、read、write等设备驱动接口层(内核层),三是用户态的CUDA、OpenGL、Vulkan等应用运行时接口层(运行时层)。从原理上,由于这三层接口都在业内各种应用层之下,所以无论在那一层做GPU虚拟化和GPU池化都可以覆盖GPU应用需求,具有很好的通用性。

针对当前的深度学习类型的应用,可以进一步把应用分为两层,一层是例如TensorFlow、PyTorch、PaddlePaddle、Mindspore等这样的深度学习框架,它们具有一定的通用性,但是各种框架之间并没有定义统一的接口,所以针对某一个深度学习框架定义的接口做GPU虚拟化或GPU池化是不具有通用性的。而且人工智能应用仅仅是整个GPU应用的一个细分领域,还有例如云桌面、云游戏、超算、模拟仿真等细分领域。因此在深度学习框架(框架层)做GPU虚拟化和GPU池化的通用性很局限。框架层再往上是一个个垂直应用的细分领域(AI应用层),例如ChatGPT这样的聊天机器人,做图像识别的 OCR等。在这样的AI应用层做GPU虚拟化和GPU池化的通用性就更差了。

图2: 不同层级虚拟化技术的通用性比较

上图直观展示了上面各层的通用性。不过虽然硬件层、内核层、运行时层都有很好的通用性,但是每一层都有自己的特点,在支撑GPU虚拟化、GPU池化上都有其优缺点。

1)硬件层虚拟化:也就是基于例如PCIe接口上实现GPU虚拟化。要在这一层做GPU虚拟化,由于涉及到硬件设计,因此只能由GPU厂商来做,例如英伟达的MIG就是在这一层支持GPU的虚拟化。优点是硬件直接支持所以理论上对性能的影响最小。缺点是由于硬件设计的复杂度,所以只支持固定的GPU切分,只支持部分英伟达的高端GPU(如A100等),而且只支持同一个服务器节点内部的容器和虚拟机使用,不支持远程GPU以及基于远程GPU的GPU池化,不支持动态分配和自动释放GPU资源,不支持GPU资源的超分超售。

2)内核层虚拟化:也就是基于ioctl 等内核态接口来实现GPU虚拟化,工作在操作系统内核里面,英伟达的 vGPU方案就是一个典型的基于GPU内核态驱动的GPU虚拟化方案。由于使用了软件来实现GPU虚拟化,相对硬件虚拟化方案会引入一定的性能损失,但是相对有较好的灵活性,而且不依赖于GPU硬件,可以在所有企业级GPU上使用。不过由于英伟达GPU内核态驱动的接口以及用户态驱动的代码都是不开放的,因此只有英伟达自己可以在这层支持完备的GPU虚拟化能力。目前业内还有腾讯的qGPU和阿里的cGPU也工作在这层,但是由于缺少完整的接口细节,目前这两个方案都只能支持基于容器虚拟化的环境,而不能在非容器化环境以及KVM虚拟化环境中使用。此外,不论是英伟达的vGPU,腾讯的qGPU,还是阿里的cGPU,都不支持远程GPU以及基于远程GPU的GPU池化,不支持动态分配和自动释放GPU资源,不支持GPU资源的超分超售。

3)运行时虚拟化:利用CUDA、OpenGL、Vulkan等标准接口实现GPU虚拟化和GPU池化。这也是一种软件的实现方案。趋动科技的OrionX GPU池化软件选择的正是这个路线,这种技术方案拥有几个特点:

1、CUDA、OpenGL、Vulkan等接口都是公开的标准化接口,具有开放性和稳定性。所以基于这些接口的实现方案具有很好的兼容性和可持续性;

2、因为该方案运行在用户态,因此符合内核态代码不应承载过于复杂功能的工程实践,可以通过复杂的网络协议栈,复杂的操作系统支持来实现远程GPU的能力,从而支持GPU池化;

3、由于该方案工作在用户态,从部署形态上对用户环境的侵入性是最小的,也是最安全的,即使发生故障也可以迅速被操作系统隔离,而通过一些软件工程的设计可以具有很强的自恢复能力;

4、当然在运行时实现GPU虚拟化和池化方案的研发工作量相对前面两种方案(硬件层和内核层)要巨大得多,有数量级上的差异。其原因在于越是上层的接口,越是允许定义参数复杂的接口,接口功能越丰富、数量越大。

总结来说,趋动科技的OrionX GPU池化软件的主要优点有:

1、兼容性好,支持市面上所有型号的英伟达GPU;

2、功能完备,支持虚拟机和容器环境;

3、性能优异,即便是远程GPU也只引入了非常小的性能损失(在典型场景下性能损失小于5%);

4、使用灵活,支持基于远程GPU的GPU池化,支持动态分配和自动释放GPU资源,支持GPU资源超分超售;

5、管理简单,具有完整的控制面,支持通过GUI,命令行以及RESTFUL API来管理整个数据中心中的所有物理和虚拟GPU资源,提供GUI界面来可视化所有物理和虚拟GPU资源的监控和告警信息等;

6、企业级功能完备,支持故障卡自动隔离,GPU任务热迁移,软件自动灰度升级等。

OrionX GPU池化软件的主要缺点是,由于需要支持已公开的英伟达用户态驱动和库接口,同时还要实现整个数据中心GPU池化所需的管理平面,自身的研发工作量非常巨大,同时远程GPU的性能优化难度很高。

从以上三种主流方案比较来看,硬件层的虚拟化(例如:MIG)带来的好处是性能损失小,但是分配是静态的,配置变更较为复杂,解决的还是单块卡的共享问题。

内核层的虚拟化方案,例如英伟达的vGPU主要满足的是为虚拟机提供vGPU的需求,本质上还是解决单卡的共享问题,同样存在性能开销,静态分配,配置变更复杂的问题。好处是兼容性好,支持英伟达全部企业级GPU,使用感受和使用物理GPU较为类似,与物理卡相比,除了少量Profilers工具不支持外,基本一致(参考:)。文远的大多数场景都是基于容器的,所以这类方案也不是首选。在内核层工作的还有针对容器的qGPU和cGPU方案,其本质上也还是通过单卡的细颗粒度切分来满足GPU共享的需求,使用范围较为有限,同时由于其依赖于设备驱动程序,工作在内核态,出问题时往往影响面较大,难以分析解决和长期维护,在文远大范围使用存在着运维维护的障碍。

可以看到,以上二大类(硬件层和内核层) 方案的思路类似:把物理卡通过虚拟化技术转化成小卡,将小卡分配给虚拟机,容器或应用。一旦分配完成,其分配率往往为100%,但是其实际利用率往往依然较低。这两类方案的弊端是:无法做到GPU资源的动态分配和自动释放,不支持GPU资源的超分超售;不支持远程GPU及GPU池化,也不具备管理整个数据中心GPU资源的管理平面。本质上,英伟达的MIG和vGPU,腾讯的qGPU和阿里的cGPU都是站在单张GPU卡的角度来实现GPU切分,而不是站在整个数据中心的角度来实现对所有GPU资源的池化管理,因此并非完整的GPU池化方案。

最后,我们从运行时层方案中看到了GPU池化的希望,利用运行时的虚拟化,除了能实现将大卡转化成小卡,支持GPU细颗粒度共享,还能支持GPU资源的动态分配和自动释放,利用远程GPU功能打破物理服务器的边界,将GPU的管理和使用从单台服务器扩展到整个数据中心,实现了数据中心级GPU资源池需要的管理平面,能对整个数据中心的所有GPU统一纳管,统一监控告警,统一运维。运行时层方案的特点和软件定义网络SDN或软件定义存储SDS的理念类似,有完整的数据面和控制面,形成了完备的软件定义GPU方案SD-GPU(Software Defined GPU),是较为成熟的技术路线和方向。

GPU池化技术的运行和分析

之后经过对当前主要技术路线和产品的选型,我们认为运行时虚拟化是GPU池化技术的基础,趋动科技的OrionX GPU池化软件是更适合文远的方案。作为国内领先的AI算力池化技术企业,趋动科技致力于通过先进的技术解决客户的实际痛点。其数据中心级GPU池化软件OrionX,把GPU当作分布式存储那样的全局统一运维、管理和使用的抽象资源,融合了GPU共享、聚合和远程使用等多种硬核能力,打造全能型软件定义GPU。

借助于OrionX GPU池化软件,将多台GPU服务器上分散的物理GPU资源打造成一个统一的GPU资源池,算法工程师不仅可以按需使用GPU资源,灵活满足日常自动驾驶多种算法研发和训练需求,同时运维工程师可以通过OrionX的图形化管理界面(GUI)对资源进行调度和管理。

图3: GPU池化解决方案拓扑图

资源弹性调度,以有限资源满足更多算法工程师需求

文远知行采用OrionX GPU池化软件,将昂贵GPU资源实现池化,实现AI开发测试任务与GPU资源分离部署,而OrionX vGPU资源池内的虚拟GPU算力即取即用,并对其他上层软件保持资源管理的透明性,显著提高了GPU的利用率。资源池中的虚拟GPU支持动态申请释放,能够自动根据调度算法使用整个数据中心的空闲GPU资源,不仅用同样的GPU资源数量支撑了数倍的开发人员,还可以快速为不同AI研发项目分配所需资源,在AI开发环境上实现GPU资源的降本增效。

远程调用,优化研发生产力

基于OrionX GPU池化软件对于远程GPU功能的支持,加上数据中心内部署了RDMA高速网络, AI开发环境不再被局限在某一台GPU服务器上运行。因此,文远知行的研发人员可以在无GPU的服务器上进行开发工作,配置好开发环境后,通过RDMA网络动态挂载和调用其他服务器上的GPU资源即可。

通过这个功能,算法工程师的应用可以无障碍地被部署到数据中心内的任意服务器之上,并且透明地使用任何服务器之上的GPU资源。面临训练大模型任务时,也能够快速调集多个GPU卡完成训练任务,且一键解决AI开发人员面临的训练模型中GPU/CPU配比和多机多卡模型拆分问题,为算法工程师节省大量宝贵时间,有效提高了研发效率。

统一管理界面,实行资源监控、管理和调配

文远知行通过OrionX将CPU、物理GPU、虚拟GPU实现统一纳管,在统一的图形化界面上对资源实现统一调度分配,实时监控。同时,OrionX还与Kubernetes环境实现无缝集成,可在K8S中实现对GPU资源池中资源的统一管理调度,简化了运维工作。此外,OrionX具备的大量企业级功能(如支持故障卡自动隔离,软件自动灰度升级等),都显著提高了运维工作的效率。

收益分析

从2021年构建起GPU资源池化之后,文远知行已经打破了一人一卡占用的模式,对GPU资源实现按需分配、灵活调度、弹性使用和自动回收,显著提升了物效人效,从而实现以少量GPU资源支撑大量算法工程师对独立开发环境的需求。

物理GPU资源利用率提升约4倍。通过OrionX GPU池化软件对GPU 资源的按需分配、自动调度和释放,算法工程师按需使用GPU资源,在AI开发环境上实现了GPU资源的降本增效。从整体来看,物理GPU使用率提升约4倍。

提升研发效率。面对本地服务器上GPU卡资源不足甚至没有的情况,算法工程师可通过OrionX远程调用+RDMA网络能力,直接调用其他服务器上的GPU资源,缩短了GPU卡资源调整和配置的时间周期,节省时间。

简化运维管理。运维工程师可借助图形化管理界面,对GPU资源池进行实时监控,统一调度和管理,有效提升了GPU集群管理效率,同时降低了运维复杂性。

削减成本投入。文远知行通过采用OrionX GPU池化软件,充分利用了现有GPU资源,原来需要为每一个算法工程师固定分配1-2物理卡,以至于需要70-80张卡才能满足一支50-60人的研发团队的需求,如今只需要16张卡就可以支撑该研发团队日常开发、测试需求,有效控制了对GPU新增采购的需求,从而降低了硬件成本的投入。

满足未来发展需求。面对研发团队人数的增长,以及后期还计划上线一个自研的开发平台的情况,文远知行可凭借OrionX对于主流GPU卡的兼容性,支持从单台到整个数据中心所有GPU服务器纳管,能轻松实现GPU资源池的横向扩展等功能特性,高效地实现“算力就绪”来支撑未来发展。

伴随自动驾驶进入高速发展阶段,作为自动驾驶领域深耕者的文远知行,在趋动科技OrionX GPU池化软件帮助下,可以更从容地开展自动驾驶技术的研发工作,加快在该领域内开拓创新的步伐。

标签: #测试开发工程师和算法工程师 #物理算法工程师工资一般多少 #算法算力流程优化