趋动科技:论软件定义GPU对AI数据中心优化的必要性

摘要:

今天AI数据中心为企业提供了 学习开发、测试和生产所需的软硬件环境。然而,GPU作为高价值硬件,却并没有做到像SDN网络、分布式存储一样的数据中心级统一运维、管理和使用。这导致了GPU当前在数据中心的尴尬现状:利用率低、成本高、分配和管理困难。

彻底解决这些痛点的方法需要借鉴软件定义存储解决存储问题、软件定义网络解决网络问题、用软件定义算力来解决GPU问题。采用软件定义算力理念的GPU池化技术,站在整个数据中心的高度,以GPU虚拟化为基础,突破了传统GPU虚拟化技术只能支持GPU共享的限制,融合了GPU共享、聚合和远程使用等多种硬核能力,打造全能型软件定义GPU。通过把物理GPU抽象成类似于分布式存储,可以通过网络在数据中心内全局统一运维和管理、任意使用的抽象资源,GPU池化技术解决了当前用户的痛点。正如当年软件定义存储刚出现的时候,有一种观点认为软件定义存储性能不如硬件存储,不适合重要应用,GPU池化技术推动的软件定义GPU也遭遇了同样的认识误区,一些片面的观点认为GPU池化技术会引入性能损失,不适合于 学习。从技术的发展来看, 学习能够、也应该拥抱GPU池化技术,二者应互相配合,才能为用户提供更适合云的解决方案。

随着 学习如火如荼地在各企业的落地,很多企业都通过自建私有云或者使用公有云的模式,拥有了自己的AI数据中心,对内或对外提供 学习的开发、测试和生产环境。在AI数据中心里,算力通常由GPU等加速芯片来提供。由于GPU成本很高,带GPU的计算资源和不带GPU的计算资源的成本相差很大,因此如何优化一个AI数据中心的运营是各个企业的基础架构部门、平台部门和应用部门特别关心的话题。

优化一个数据中心,首先看组成现代计算机系统的三大件:计算、网络和存储。现代的数据中心运营用软件定义网络(SDN)做网络资源抽象,用分布式存储做存储资源抽象。这些今天看起来顺理成章的技术,也曾经历虚拟网络不如物理网络性能高抖动小,分布式存储不如本地存储性能好延迟低且还浪费网络带宽的质疑。直到今天这些经过抽象后的资源性能仍然不如直接使用物理硬件,但是最后其征服整个业界的本质原因就是资源的全局统一运维、管理和使用。“计算“作为三大件之一也不例外。特定地,对于服务于 学习的AI数据中心,“计算”更多地是围绕着GPU。对GPU资源做数据中心范围内的资源抽象,使其成为和SDN网络、分布式存储一样的全局统一运维、管理和使用的资源,是优化AI数据中心的必然思路,也是行之有效的方法。

AI数据中心的痛点

趋动科技已经服务于互联网、金融、教育、电信、交通运输等多个行业的头部客户。下面是我们看到的很多客户在运营AI数据中心中遇到的痛点:

1) GPU资源静态分配。各个小组/部门使用GPU的负载差异非常大,但是由于应用分管、组织架构等的原因GPU资源无法轻易在部门之间流动,造成GPU资源无法被高效利用。

2) 开发场景GPU利用非常低。在开发的过程中,程序员可能在写代码,可能在调试bug,甚至可能空闲了去干别的事情。这时候GPU资源大部分处于空闲,但是传统独占GPU资源的模式使得GPU资源无法给别人使用。而开发人员并没有主动释放资源的动力。

3) 开发场景GPU使用体验差。有部分企业通过任务提交系统一定程度解决开发场景GPU利用低的问题。但是这种模式下开发人员的体验差,他们需要保存环境、打包镜像、提交任务并且等待完成。这种模式会浪费比GPU更昂贵的 学习算法工程师的时间和注意力。如果是在调试bug,这种模式对工程师是个噩梦。

4) 从应用侧看GPU资源不够用,从运维侧看GPU利用率低。独占GPU的模式使得宝贵的GPU资源很快就被各种场景分配出去了,应用方总抱怨GPU资源不够,但是平台方看GPU的利用率确实不高。

5) CPU、GPU的配比困难。服务器按批次采购,平台/运维要求机器的型号配置是相对固定的。但是应用的类型却多种多样,且未来还在不断变化,不同应用需要的CPU、GPU配比是不一样的。固定的配比容易造成资源的浪费。

6) 同一个任务负载存在波峰波谷、不同任务负载差异大两个复杂维度使得GPU的分配特别困难,难以高效使用。

从痛点可以看到,虽然实体上是一个数据中心的运营,但是一个企业的运营说到底是围绕着人、业务和企业制度来运作的。看一个技术对企业带来的价值,最终还需要体现到这几个方面。以数据中心云化为例,之所以其成为最佳的实践,是因为该技术对采购、运维、研发、生产、风控等整个链条的人和部门组织架构都产生了深刻的影响;对安全、可控、效率等业务需求和企业制度同样产生深刻的影响。

上面提到的痛点实际上很好涵盖了一个企业运作的多个方面。分析完客户实际中遇到的痛点,我们发现产生痛点的一个根本原因在于,GPU资源作为高价值的硬件资源,但却不具备像SDN网络、分布式存储那样数据中心级别的统一运维、管理和使用的一等公民身份。因此用户迫切需要一种技术来消除这种差距。

解决痛点的方向——GPU池化技术

彻底解决这一痛点的方法需要借鉴软件定义存储解决存储问题、软件定义网络解决网络问题、用软件定义算力来解决GPU问题。采用软件定义算力理念的GPU池化技术,站在整个数据中心的高度,以GPU虚拟化为基础,突破了传统GPU虚拟化技术只能支持GPU共享的限制,融合了GPU共享、聚合和远程使用等多种硬核能力,打造全能型软件定义GPU。

趋动科技的OrionX 产品是世界范围领先的数据中心级GPU池化软件,关注 学习服务在企业内的全链条优化,通过先进的技术解决客户的实际痛点。

趋动科技:论软件定义GPU对AI数据中心优化的必要性

OrionX并非一个传统的GPU虚拟化软件。传统的GPU虚拟化只支持本地GPU共享,而OrionX可以把GPU当作像分布式存储那样作为全局统一运维、管理和使用的抽象资源,其能力是传统GPU虚拟化的超集,支持GPU共享、聚合和远程使用等多项硬核技术。

OrionX把物理GPU资源抽象成可以通过网络在数据中心内任意服务器都可以直接使用的通用资源,对软件保持近似于物理GPU的兼容性,支持常用的 学习框架(TensorFlow, PyTorch,PaddlePaddle等),支持 学习的训练/推理/未来更多计算模式,支持追求极致性能的手写CUDA代码的应用,可以充分利用成熟的 学习的生态和社区力量。

OrionX支持开发、测试、生产各个环节,可以隔离,可以混合部署,保持统一使用模式,并且支持不同环节的不同优化策略。

OrionX支持本地共享/远程共享、本地独占/远程独占、跨物理节点多合一各种灵活的用法,支持动态配置资源,每一种功能都有实际对应的使用场景。

OrionX GPU资源池内的GPU算力即取即用,对其他上层软件保持资源管理的透明性,做到资源的有效利用。

OrionX对如何提供虚拟GPU,哪些底层细节需要隐藏,哪些真实参数需要暴露都有科学的考虑和设计,并留有丰富的接口和配置,允许平台层甚至应用层做定制化和优化,甚至二次开发,例如任务的排队、优先级的定义、亲和性等,甚至 学习框架本身都可以利用OrionX GPU资源池提供的能力去做非常有用的优化。

OrionX GPU池化软件的效率

正如当年软件定义存储刚出现的时候,有一种观点认为软件定义存储性能不如硬件存储,不适合重要应用,GPU池化技术推动的软件定义算力也遭遇了同样的认识误区,一些观点认为GPU池化软件会引入性能损失,不适合于 学习。针对 学习的两类最重要的任务我们来分析这种观点的片面性:

训练任务

《Characterizing Deep Learning Training Workloads on Alibaba-PAI》[1] 分析了阿里一个训练集群上的负载特征(见下图):从任务数量上看,约59%的任务是单卡小任务;从GPU资源消耗上看,虽然81%的GPU是被分布式训练任务占用(单机多卡也算分布式),但是这其中有一半的资源是被小于8个GPU的任务所占用(1台物理服务器可满足);只有0.7%数量的任务是使用超过128个GPU(需要16台或更多物理服务器)。

趋动科技:论软件定义GPU对AI数据中心优化的必要性

这个分析表明,训练任务是非常多样化的,其规模有大有小。因此,整个数据中心的优化目标,应该兼顾训练任务的整体吞吐率,以及GPU资源的整体利用率。提升多个训练任务的整体性能,而非强调单个任务的性能,是实践中常见的选择,现在业内有非常多的研究工作都围绕此开展。 学习框架是很多训练任务依赖的一类基础软件,其设计目标之一是提升单个训练任务的性能。GPU池化软件的目标是通过充分利用数据中心内所有GPU资源,从而达到多任务的整体最优。这二者不矛盾。框架和池化软件可以互相配合,在达成多任务整体最优的情况下,尽量让每个任务的运行更加优化。同时,GPU池化软件可以通过技术手段尽量减少自身引入的性能损失。例如,OrionX GPU池化软件对于典型的TensorFlow、PyTorch训练任务可以达到98%以上的效率,即和物理GPU相比小于2%的性能损失。在和框架做共同优化的情况下,性能损失还能更低。

推理任务

和训练任务动辄小时、天、甚至周量级的完成时间不同,推理任务的完成时间要低得多。典型的在线推理业务,端到端的延迟需求一般在数百毫秒级别,包括了客户端到运营商网络、运营商网络到数据中心以及在数据中心内做各种处理的时间。这类实时性要求高的推理任务,需要GPU池化软件引入的额外延迟非常小。下面是趋动科技的OrionX GPU池化软件在推理任务上引入的额外延迟的数据:

趋动科技:论软件定义GPU对AI数据中心优化的必要性

即便在最为苛刻的,延迟最低的batch size 1的推理测试中,使用本地物理GPU做一次resnet152的推理延迟为 13.3 毫秒,而使用OrionX GPU池化方案通过RDMA网络使用远程虚拟GPU,延迟为14.1毫秒。GPU资源经过OrionX GPU池化之后,带来的0.8毫秒的额外延迟仅占数百毫秒的业务要求不足1%。这个数据充分说明了,趋动科技的OrionXGPU池化软件引入的额外延迟非常小,足以支持高实时性的在线推理业务。

总结

AI无疑是一个火热的词汇,但是放在整个计算机领域,应用的重要性不改变其技术的本质,其从硬件到软件的设计思路并没有什么特殊的地方,没有哪个设计思路是计算机发展史上的新鲜事。经历行业长期实践经验,数据中心云化是大势所趋。一个应用要上云,不是让云来适应应用,而是应用必须要适应云,否则只能被更适应云的竞争者所替代。GPU池化软件把物理GPU抽象成类似于分布式存储的,可以通过网络在数据中心内全局统一运维和管理、任意使用的抽象资源,是AI业务上云的必然选择。今天认为GPU池化软件会引入性能损失,不适合于 学习的看法,和当年认为软件定义存储性能不如硬件存储,不适合重要应用的看法一样,有着相似的片面性。 学习能够,也应该拥抱GPU池化技术,二者互相配合,为用户提供更好的,更适合云的解决方案。

谈到应用和云,就不得不提“云原生”。这是另外一个有意思的话题。感兴趣请关注我们下一期的技术分享。

(免责声明:本网站内容主要来自原创、合作伙伴供稿和第三方自媒体作者投稿,凡在本网站出现的信息,均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性,但不保证有关资料的准确性及可靠性,读者在使用前请进一步核实,并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏,概不负任何法律责任。
任何单位或个人认为本网站中的网页或链接内容可能涉嫌侵犯其知识产权或存在不实内容时,应及时向本网站提出书面权利通知或不实情况说明,并提供身份证明、权属证明及详细侵权或不实情况证明。本网站在收到上述法律文件后,将会依法尽快联系相关文章源头核实,沟通删除相关内容或断开相关链接。 )

Baidu
map