《原动力 x 云原生正发声 降本增效大讲堂》第五讲——通过云原生管理KubernetesGPU资源原创

各位网友大家好，欢迎观看原动力云原生正发生降本增效大讲堂系列技术直播。期待已久的第二期直播来了，那第二期聚焦全长景在线Co GPU资源效率提升、Co资源托普感知调度主题原动力原生正发生降本增效大讲堂是由中国新通院、腾讯云Fi产业标准工作组联合策划。目的是与开发者一同交流提升资源利用率、降本增效的方法与优秀实践。啊，我们在6月23号，6月30号，还有7月7号呢，进行了第一期的三场直播，直播的主题分别是云原生降本增效优秀实践案例分享。Co云上资源的分析与优化，Co集群利用率提升实践，欢迎大家观看回放。点击当前下方的往期直播，或者在进入活动主题专题页面即可观看。在这里分享一个独家喜讯，腾讯原生成本优化平台bore荣获国家级大奖。

云计算中心科技奖办公室在8月2日公布了2022云计算中心科技奖的获奖名单。腾讯原生成本优化平台of荣获云计算中心科技奖卓越奖啊，这也是我们国内的首个云原生工具获得此特殊的一个奖项啊。云计算中心科技奖呢？是由国家科学计算奖励工作办公室审核并备案的。那是社会科技奖励目录中，在云计算中心科技领域给予的唯一国家级奖励。旨在奖励绿色云计算中心中应用的科技创新成果和产品，为经济社会发展和国家节能减排事业做出的重要贡献。今天我们请到了腾讯云容器研发中心高级工程师徐贝老师为我们分享如何通过云原生管理Co GPU资源，大家有什么问题呢？可以随时在弹幕区提问进行互动。好的，我们有请徐贝老师。

啊，大家好，我叫徐贝，来自腾讯云容器产品中心，那我在公司内部主要负责K8S容器啊GPU相关的这个架构与研发，那我本身在原生领域已经深耕十年之久啊，主要的领域是在原生以及啊在联很多方向，那我本身也是K8的社区啊，Memory k EP的这样一个作者，那大家如果有兴趣啊，其实可以在社区联系到我。好，那接下来先啊进入我们今天的这样一个分享内容。啊，那我今天给大家分享的主要是我们腾讯云怎么样通过云生的方式去在这个云上管理K8以及GPU资源。那今天啊分享的内容主要分为三块，那第一块首先我会给大家介绍当前开发的社区是怎么样去发现跟使用GP啊这个物理卡以及这个物理资源的，那第二块就是因为社区本身的这个方案实际上还是有一些限制跟不足的，那我们是怎么样通过方式啊去解决啊，就是KS上面使用GPU资源的这些问题的，那最后最后一块就是因为其实在云上啊，我们整个GPU的这个卡的啊，整体的利用率还是比较低的，那我们怎样通过一个QGQ的这个容器化的方式去帮助客户或者业务去提升GPU资源利用率啊，降低单卡。

啊，使用成本。那首先当前在开的社区里面啊，实际上更多是通过所谓的一个resource加上应用的方式去啊，给用户提供G的这个物理资源支持的。那也也就是说，其实每个provide厂商啊，G的厂商都会实现他自己的所谓的DP的这样一个agent，这些agent，那在底层节点层面会将底层的这些物理卡去做一个扫描上报，上报到集群里面啊，用户实际上是通过扩展资源的方式，在这个跑创建的时候啊，去指定这个需要多少物理卡啊，也就是右右边这一侧就是啊，用户在创建pod的时候，需要在contain里面啊去啊申请这个具体的物理卡的这样一个啊一个资源数，那前面的这个这些扩展资源实际上是DP。

啊的这些GPU去啊，自定义的那这些这个啊DP实际上会在每个。外的节点上面去做启动，那并且啊在内部会去调用各个的这个GPU的厂商的一些设备的这些工具，去将这些设备卡的这个资源啊扫描并且上报上来，那这些啊资源在节点层面际上就是啊一些这个可分配资源，那从这个层面上来说，实际上PU跟啊CPU和内存起码是在po层面使用层面啊其实没有任何区别，那这也是啊KS我们提供的一个通用的这个方式。

啊，并且其实这个扩展资源跟啊DP的这个方式啊，它本身是一个通用方案，不光是能支持GPU卡这样一个资源申请和这个扫描啊，其实包括ipga或者是一些其他的一些啊，加速芯片的这个设备其实都都是可以支持的。啊，但正是因为这些，它这个方案本身是一个通用方案嘛，所以说它在。支持专用芯片的这个方案上还是略显不足的，那回到GPU的这个领域，首先啊，实际上这个GPU层面，那用户在pod里面，那只能支持申请整卡的方式，那共享卡的方式实际上是没办法支持的啊，这样的话就会导致单个这个呃物理负载，如果用满单张物理卡的话，实际上会对这个单个物理卡造成资源层面的浪费，那它的整体的用卡成本就会非常高，那第二块是说因为本身的这个扩展的资源啊，实际上是一个标量的设备。

设备数它实际上是没有这个啊，没有这个就是在集群层面，实际上是没有这个GPU的分配关系的啊，那实际上它在这个调度器层面，更多是这样一个加减的操作，那最终给这个GPU分给这个负载，或者是给这个的容器分配GPU设备啊，实际上是在DP的那个里面去做的。那这样这样的话会就会导致在集群层面，用户实际上是很难去啊，看到就哪些物理的这个GPU跟哪些容器是去做关联的，那其实这个本身啊，在整卡的方式下面，那它的这个问题还不是这么多吧，因为本身这个一张啊GPU如果只给单个容器用的话，实际上这个。客户其实啊也啊并不是很需要知道这个GP的这个具体的关联关系，但是因为随着这些GP共享术的这个逐渐靡嘛，那我我们如果想将多个容器啊去在同一个这个GPU卡上，那实际上这个分配关系啊还是必不可少的，那最后一块就是其实刚才我也说了，就是每个GPU的provider都会实现它各个的DP，比如说主流的像英伟达ND或者英特尔那这些GPU的厂厂商，那都会有自己的P的实现，那这样的话就会造成在一个集群里面，这个DP的这个方案会非常多，那不管是在用户侧的使用，还是在呃in的这个管理员在集群层面的管控啊，都会带来非常多的复杂度，那这块其实也是通用方案带来的一些不足。

那正因为有这些问题啊，那我们在想说能不能通过一个方案同时解决这三个问题，首先这个方案啊，是可以支持整卡分配以及GPU共享，同时啊所谓的这种双战去使用的啊，也就是说我们可以通过一种方案去同时支持单个这个给单个炮的容器去啊分配整改，或者是能支持多个pod的容器啊，去共享同一个GPU卡的这样一个使用方式，那这样的话，其实可以尽尽量最大的程度的去降低啊客户层面的使用的这样一个复杂度，那第二块就是我们啊希望提供一种方式，原生的方式能让用户在集群里面。

可以以很非常直观的方式将GPU的这些物理卡的信息啊去啊查看出来，那这样的话有利于不管是用户层面对资源的这个控，或者是啊管理员层面对这个底层的GP卡的这个管理，其实都是有非常大的帮助，也就是说我们最终希望通过一种方式，呃，能增加这个GPU在啊开发的集群里面的这样一个可见性。啊，最后就是我们希望通过一个技术或者一个方案，能将底层所有地P全做统一，那这样的话啊，管理员在做集群初始化的时候，实际上只是需要去啊部署一个组件就可以了，那这个组件其实可以动态在啊，通过底层的这个扫描机制，或者是你给他配参数，那它可就可以将相应的这个物理卡资源去扫描出来啊，这样的话啊，不管是对集群层面的复杂度来说，还是对这个管理管理员来说，那他的这个用卡的这个使用的这个复杂度啊，其实是会大幅度降低的。

那也就是有，因为有这样的背景啊，所以说啊，我我们在内部也是。啊去总结了非常多的这样一个用户层面的使用的这个反馈啊，以及我们真实的这样一个就是业务层面的需求，那我们啊设计出了一个原生的方式啊，去在开发的上面统一啊管，让支持用户统一管理和这个使用啊GPU资源，那这个方案本身实际上是分为三个啊大的这个模块，这块就是我们在前端。我们在前端啊，实际上是定义了两种啊，GPU的资源也是GPU的call啊，加上这个GP的memory，那我们将一个GPU的物理卡那去划分成100个100份，那这样的话，我们在算力申请的时候，一份实际上就是就是代表啊这个GPU啊物理卡的这样一个1%的这样一个算力，然后呢，在显存层面，实际上我们目前是支持GB级的显存的这个切分，那照比级的切分目前也在啊这个规划以及实现。

那这是在第一块，就是我们在呃资源层面做了两个这个标准化资源的定义。那第二块就是我们有一个资金的GPUCD，那这在这个CD里面，实际上我们可以看到。单个物理卡以及啊这个物理卡与它上面容器啊所所用资源层面的一个关联关系，那实际上通过这种方式啊，我们我们本身底层有一个DP在启动的时候，会将它节点层面所有的这个容器以及它的这个理做一个这个更新扫掉，这样的话，用户在啊集群层面就是可以通过啊get c ID的方式获取到整个集群层面的这个GPU的资源的这个分配情况，那通过这种方式实际上极大增加了这个物理卡层面在集群层面的这样一个可见性。那。第三块就是我们有一个自研的这个基于KS一个三点resource schedule的这样一个GPU的这个扩展调度器，在这个调度器里面啊，实际上我们可以针对GPU资源做精细化的调度，那什么。

就是什么这个什么叫这个精细化调度，那实际上我们可以在这个调度器里面同时感知到单个物理卡这样一个资源，那这个其实是针对社区的一个大的改进，那在传统的社区的方案里面啊，更多刚才我也说了，它更多是针对物理卡层面的单个资源的加和解啊，实际上他并不知道这个节点上面这个布里卡跟。啊，所申减炮的容器之间的这样一个对应关系，那实际上我们开发这个调度器就是为了解决这个问题，那我们我们在啊这个调度器里面，实际上是能感知到单个这些物理卡的资源，也就是说我们不再去分配单个卡，而是分配单个卡里面的具体资源，并且能啊去以这个物理卡去作为调度单位，那这样的话，整个在这个资源，可见资源的这个力度层面比原有的方式啊又低了一层，那这样的话实际上可以可以。

啊，在集群内部，那使得整个的这个GPU资源的这个分配情况啊，做这个极大的改善，那最后我们有一个统一的DP的这样一个agent，这个agent。啊，这是第一点，第二点就是我们在这个框架上面啊，去实现了主流的GPU provider的这样一个支持，包括英达MD，英特尔以及啊，包括这些整卡的这个提供商。以及那我们呃，后面可能会提到的这个G容器化的这样虚拟化的这样一个方案，包括Q，包括那最终达到效果就是我们在一个方案里面啊，实际上支持任意的这个GPU资源的申请以及分配，那通过这种方式啊去降低了啊层的整体的用户，不管是用户来说，还是这个管理员来说的这样一个啊，就是用卡以及管理的成本。

啊，这是我们整个方案的这样一个啊大体的架构。那首先在资源层面，刚才其实我也说了，就是我们定义了两个标准的GPU资源，那一个是QG，就是q g memory q GP Co，本身我们会将单卡的匈牙利分成100份，那每一份是代表这个单卡的1%，那用户是通过这种方式，实际上就是可以去啊做这个就是百分之几的这样一个啊共享卡的申请，那第二块就是QGQ的memory，那这个memory本身目前是GB为单位的，那用户可以在啊单卡内部去，比如说单个T4大概是4GB用户啊，实际上可以以GB为单位去申请这个T4里面的啊部分的显存。啊，这是共享卡的这个模式啊，这个在使用层面跟原有的成卡的这个使用其实没有任何区区别啊，都是在这个pod的卡里面啊去。

做这个扩展资源层面的申请，那只是说这个资源啊，是我们啊给用户提供的，这是第一个原有的，这是第一个这个共享卡方式的这样一个实现，那不光是共享卡，实际上我们可以在这个方案里面啊，去实现这样一个整卡的分分分配啊，也就是说这个KT本身啊，刚才我也说了，就是我们会。将一个GPU卡分成100份嘛，那这样的话，一个啊GPU的物理卡就代表100个算力，那如果你的算力值小于100的话，那其实你本身就是一个共享卡的模式啊，对吧？那如果你的算力值钱的时候大于100，呃，大于100之后，那你必须是这样一个100的整数倍，那这样的话，你就是一个整的模式啊，比如说一百两百三百这种。啊，这样的话就通过这种方式，实际上用户啊，也可以同时去做这个整整卡的申请。啊，这是我们在这个资源统一上做的啊，这个标准化的这个事情，也就是说去啊，通过两种资金的资源呢，去兼容共享卡的方式，以及这个呃，整卡的这样一个申请和分配方式，那第二块是是说我们在K8S里面啊，实际上是有一个CRD的这样一个实现，那这个CD是什么东西。

啊，那这个CRD本身就是一个这个CRD实际上一个GPU的CD，实际上是就是对应单个节点层面的啊一个物理卡啊，当然这个物理卡里面会有很多的这个信息啊，啊就是我们整个在这个CRD，我们整个在底层，因为刚才我也说了，我们在底层是有一个自己的DP的这个agent的实现的，这个agent本身在启动的时候啊，就会根据参数的设置，以及对啊底层这个资源的扫描去将这个啊节点下面所有的物理卡。先去扫描出来，然后呢，呃，再会去将pod层面的这个。啊，资源去做一个汇总，然后将pod跟这个这个GPU的这个物理卡去做一个对应关系的这个计算，那最终啊，它会将这个整个的这个对应关系以及分配情况啊去。

在集群里面创建对应的这个所谓的我们我们定义的这个GPU的CRD出来，那这样的话，实际上用户在这个集群里面就可以通过我们这个CRD啊去做这个资源的这个可见，那大家可以看到就是右侧实际上就是我们这个我们的GPU的CD里面啊存在的一些这个信息，那包括这个。呃，包括我们的这个就是GPU本身节点，就是这个节点层面GPU的这个index的号，那就是英伟达，比如说英伟达的方式下面就是英伟达0123后面的那个index。那以及这个啊，这个GPU物理卡本身所具有的资源，那比如说这个显显存显存啊。显存也是可以扫描上来的，包括这个GPU本物理卡本身的这个model的这个型号，那这是呃，我们现网环境的一个T4的这个卡，那以及它所在的节点啊，对吧，以及它这个设备层面的路径。

那并且是这个实际上我们还本身是有一个status这样一个一个属性的，那在在这个status里面啊，它就是它就会能去啊展示出这个GPU跟。呃。容器层面相关的这样一些关联关系，包括哪些的容器啊，是部署在这个GPU上面，那大概是用了这个GPU的多少的算力以及显存，那这些的管理关系都是可以看到的，那这样的话，用户啊，比如说管理员想去看整个集群层面GPU卡的分情况啊，那这个时候实际上就是可以通过我们提供的CRD啊去做这样一个。呃，查看那非常就是使整个的这个集群层面的GPU的资源管理啊，这个难易程度大大降低了。啊，这是我们在这个推流可行性层面啊，做的一些这个创新以及探索啊，这个功能其实也是在我们现网啊大规模使用了。啊，这个其实大家如果有兴趣，其实可以在T的这个Q的产品里面去做体验。

那最后我们在这个统一框架层面啊，实际上刚才我也提到了，那首先前端我们是有两个啊，自定义资源的这样一个定义，包括跟memory啊，这是这个资源定义标准的层面的一个事情，那实际上这个层面做的是统一用户使用GPU资源的入口。啊，标准统一啊，这是第一块，第二块就是啊，我们在这个中间层这样一个调度器层面，那我们是有自己的这样一个KPI的调度器，那这个调度器实际上是能同时感知啊节点以及GP级别的这样两层的这样一个调度关系，那能做到原有方案的这个。做不多的这样一个精细度，那能使整个集群层面的GU的这个资源分配，分配的这个效率啊大大提升，那最后一块就是我们在底层有一个统一的所谓的unified GPU的的这样一个frame，那这个里面首先是对用户层面提供了统一的统一的这样一个入口，就是你可以通过通过我们这个D。

啊，GPU的技术啊，这是第一点，第二点就是我们默认也是跟呃主流的这些DP做了这个融合，包括这个主流的GPU的R，那因为达到AMD的英特尔的卡啊，我们都是可以支持整改分配的，那并且我们也是跟我们自己的GPU容器化的方案去做了深度集成，包括QGP啊，包括微的，那最终给客户或者用户带来的啊这样一个收益就是我们可以通过一个DP或者通过一个方案。啊，去在集群里面实现任意的GPU的技术啊，最终去极大的简化了啊，不管是用户来说，还是这个管理员来说啊，管是这个GPU资源使用啊，资源申请，或者是底层的GPU的管理的这个复杂度啊，最终使整个用户在KS层面啊，使用GPU的效率啊会大大提升啊，这是我们整个在这个技术框架层面，或者是在使使用效率层面啊做的一些这个优化的尝试。

那第三块是想跟大家大家介绍一下，就是我们啊，怎么样通过这些共享的这样一个技术在底层。去提升GPU资源利用率的啊，这个其实其实这个产品本身啊，我们啊，我们我我我们我们在去年就已经在现公测，然后今年是在今年上半年已经在网去大规模的这个铺，也就是所谓的T的。这个。它能完成三个大的这个功能啊，那这块就是它可以支持多容器的这个共享啊，单个GPU啊，这个所谓的多容器，它可以是一个pod里面多容器，也可以是呃，多个泡道里面的多容器。啊，就是它可以支持容器间去。共享单个这个物理的G啊，这是第一点，第二点就是它实际上是能提底的啊，GP的算力和显存层面的，那这个实际上也是我们对于业界的一些其他的这个共享方案的一个啊，非常大的优势啊。

啊，相当于你其实你要做这PU共享，你要通过GPU共享去提升汽车用率，那你首先要去保证底层不同的这个业务共享资源之间的这些隔离嘛，对吧，相当于你业务稳定，那才能啊，这个共享的事情才能成立嘛，啊这个其实这个强隔离的这个功能，实际上是我们这个方案跟业界。的方案的一些大的一些这个优势吧，那最后一块就是啊，我们还实现了一个业界所谓的在点缓的这样一个功能，那其实大家可能更多的听到的是CPU层面在点缓。对吧，也就是说我们在CPU内核级别，实际上是能针对不同的这个process，或者针对不同的啊C去做这个啊高优啊中优啊低啊这样这样一个优先级的这个设置，然后内核层面会根据啊优先级的不同去做这个啊，就是不管是这个资源分配啊，资源抢占这些这个高低优的这样一个调度的这个功能啊，那实际上这个GPU。

资源层面跟就是原有的这个CPU层面，其实是场景是类似的。啊，所以说我们其实也是仿照了CPU的在联缓步的这样这样一个这个成熟的技术啊，我们独独家的创新性的在这个GPU层面也实现了在联缓可以支持啊，就是高低的这样一个一些的负载，在GPU层去做这个高低的这样一个抢占。啊，那通过这种方式也是能极大提升GPU的整体的这个利用率的。那在特点层面啊，那我们整个的这个特点其实啊还是比较鲜明的，首先就是我们在这个灵活性层面是支持啊算力跟显存的这样一个灵活配比，也就是说啊，我们算力是支持1%的这样一个力度设置啊之前也说了，就是我们单看。啊是分配分分分类层面是分成了100份，那用户就可以以这个1%为这个。啊力度，然后1%为这个去做这个算力层面的资源申请，然后在显存层面，目前是支持GB啊，别的显存设置啊，那后期也在规划去支持照壁，那这样的话，如果照币方面的支持，实际上我们在啊用一些小的碎片的显存的这个效果上会非更好。

啊，第二块就是刚才也说了，就是我们底层显存和算力的资源是支持强隔离的，也就是说啊，你。啊，多个这个业务去啊，共享这个GPU资源，实际上我们可以限制你只能使用你申请的这些资源啊，也就是说多个业务共享单个GPU卡他们之间啊，是不会做到不会有这样一个资源抢占的，也是最大程度保证啊这个这些这些这个负载之间的这样一个，呃，服务质量啊，也不会因为说你因为有了PU共享啊，给你虽然给你提升了GPU利用率而损失你的这个啊就服务保障的啊，这点是。绝对不允许的啊，目前我们是通过强高级的方式啊，也就是在底层去内核层面去实现这样一个保证。那在点混部，其实刚才我也说了，就是我们整个功能是在业界唯一啊在点混部功能，然后呢，我们可以通过这个在点混部的这样一个功能，将整体的GPU利用率啊压到最高，那目前现网数据甚至可以将GPU的负载提升到100%。

啊，在这个整体的覆盖度上面，那主流卡都是支持的，那安就是我们的这个VOA架构，以后的像T4V100啊，以及我们最新的安培的架构啊，这些主流卡都是可以支持的。那在这个原生方面啊，这个更没什么说了，就是我们整个方案就是围绕KS在去做设计。那在K里面，那原有你怎么去用GPU卡的资源，那整个流程其实没怎么变，只是说。啊，你需要把资源的这个申请换成我们自己的这个资源定义。然后呢，在兼容性层面，那因为我们我们是出于底层嘛，所以说用户原有怎么用GPU的这个设备，那目迁到我们的设备，迁到我们QQ的这个容器方案上面，那还是可以怎么用啊，你在这个业务层面，其实不需要做任何的重编重换的这样一个。呃，这样一个这个就是操作啊，最后在性能层面啊，就是我们在性能损耗其实做的经优化的非常高啊，就是啊，我们目前在线网实测的这个吞吐实际上是接近零损耗啊，然后在这个真实环境里面，目前业务反馈是肯定是在个位数以下。

啊，所以说在这个呃，性能损耗层面是没有任何问题。啊，然后这是我们整个QQ的这个一个技术架构，那里面其实也是分了三个大的部分，一块就是在开发的层面。啊，我们是在围绕QGP做了啊，就是自己的这样一个，就是K8调度器，扩展调度器，以及啊我们自己的DP，但是这两个实际上是跟刚才我说了所谓的运营商的这个方案是一个方案，只是说我们会我们将的这个技术。啊，去在这这个方案里面去做了支持。啊，这是第一点，第二点就是我们在底层实际上是有一个自己的Q的状态，然后在状里面会做相应的。这个QQ的这个设备的创建啊，这个资源申请啊，以及。

以及这个拉扣的一些管控。啊，就是这一层实际上是跟KS或者原生相关的这些，包括schedule啊，包括DP啊，包括我们的time的这些实现，然后下面是跟内核相关的啊，其实刚才我也说了，就是我们的方案为什么在啊隔离层面做的非常好，那就是因为啊我们实际上不是基于库大层面做的API劫持，那我们是基于。呃，我我们在英伟达的方案里面，实际上是基于英伟达的D之间做这样一个拦截，这个拦截实际上更是。啊是结构层面的，那所以说它并不会因为你扩大PPI本身的变化啊，造成任何的影响啊，所以而且又因为本身是在在内核层面做了隔离嘛，所以说我们的吸力度或者我们的层级是低的，那层级越低吸力度其实是这个越高的啊，这样的话，我们的这个不管是QS层面的一些把控啊，不管是刚才我说的兼容性层面的一定是最好的。

然后这个。啊，这个其实就是我们整个的这个方案的一个核心的架构，那分两层啊，这一块就是开发的相关的，运营商相关的，那我们有自己的这个调度器，我们有自己的DP，以及我们有自己的time去做啊，跟科发的相关的这些啊，资源的创建啊，申请啊，以及设备的这个创建啊，这是第一层，第二层是说我们的设备是基于啊这个个内就是两个um MD跟KMD之间的这样一个CH结持，所以说我们在不管是在稳定性层面，不管是在兼筑性层面啊，都是做的非常好。啊，然后在使用层面，其实也是非常简单啊，首先在集群层面，那我们我们是有自己的一个包，那用户其实在集群里面把这个QG的组件去做创建跟开启啊就可以了，然后呢，我们一般是通过节点的方式去做申请，也就是说。啊，在一个集群里面呢，你可以通过节点池去啊，去围一堆一堆的这样一个节点啊，比如说有就比如说节点池A是可的节点池那B那个那个啊节点池B是用的整卡的，然后呢，可能C是这个MD的这个整卡的，那用户在前端创建的时候，比如说QQP，那你就把相应的no以及。

那我们的Q的独有的这这个就是我们QV的这个资源的值啊，去附上这样的话啊，用户在创建的时候。在创建的pod的时候，就会根据你的这个select去做这个节点池层面的分配，那你就会落到这个K的这个节点池里面，那如果是。比如说你想用整卡，或者是想用这个啊，其他的这个provide的这个卡，那就是把这个节点池的这个标签，也就是no select的这个标签去换成别的节点池啊就可以了，那通过这种方式，我们实际上可以从在一个K发集群里面啊，去支持不同的这个这个GPU的这个去使用不同的GPU的使用的资源。

那并且在这六层面啊，我们目前是能支持到单个GPU物理卡级别的，而不再是啊集群层面的这种加加减减。啊，也就是说我们首先节点层面，我们可以我们我们我们节点和GPU2，我们节点和GPU其实是能实时双层所谓的这种调度了。那首先这个我们啊，在节点层面，我们会根据这个整整个GPU卡的这样一个使用情况，比如说它的request的这个。总数啊，比如它的可用总数啊，比如说它的这个，呃，就是就是你你到底是说就是可用，可用数越多我越往里掉，还是说可控数越少我越往里掉啊，通过这种方式去支持这个冰派以及SP不同的这种啊调度策略啊，这是节点层面，然后在物理卡级别啊，实际上就是我们我们在K8的特斗器的，我们在我们自研的这个GP斗器里面，实际上。啊，是能感知到两个物理卡的啊，这个其实有点类似于就是啊，我们先调度到节点啊，那节点层面实际上是这些卡的一个总数嘛，啊这个总数里面是支持的，以及这些调度策略。

然后在下一层我们会选完节点之后，那我们会我们我们的这个GPU器里面。接着还能选GPU卡，嗯，那这个卡其实因为刚才我也说了，就是因为本身我们有这样一些共享方案，所以说在GP的单个里面可能会多个容器的。那这样的话就是不不可避免的就需要在这个调度器里面感受到单个GPU物理卡的一些资源的分配情况，那我们在这个选卡的过程里面，同样是能支持并以及SP的调度这些策略，那也就是说说我们最终通过这种所谓的to胎这种两层调度的策略，那能非常好的满足用户。啊，这个使用QQ或者调度QQ的这样一些这个需求。

那并且在这个底层算力隔离层面啊，那我我们除了这个刚才我说的就是所谓的强隔离，就是fix这种方式。以外，那我们同样也支持所谓的be跟，那什么叫be呢？这个be就是说没有算离隔离啊，就是说我我们因为显存本身没法做overla嘛，所以说在这个显存本身是首先用户在做这个切卡的时候，实际上我们更多推荐用户先去做啊显存层面的这样一个。啊，判断。比如说你单个T4的卡，你想去布三个或者四个这个每个显存13GB的这样一个业务，那在这个基础上之后，你再去选择你相应的一些算力隔离策略，那比如说你这些。啊，算力之间本身就不想要去做这个隔离，想去充分利用GPU整卡，那你觉得他们之间即使有资源争抢也是对业务影响不大啊的话，那你可以将底层的算力的隔离的策略就设成B，就是说我们底层不做，不给你做任何的啊算力层面的隔离。

那或者是说你觉得业务之间必须有这个隔离墙隔离，那我们业务比如说我的底层的这些共享这个业务啊，是一些在线推离或者推荐啊，搜索这些，它的这个延迟就是需要非常低。是吧，我即是想用GP共享技术，那也不希望因为引入GPU共享技术而对业务层面有任何的这个困扰，你就可以将我们层policy设置可以按照。申请这个值去做强的保证，比如说你申请了20%的这样一个算力的资源，那底层就是给你去限制到20%以内。啊，这是所谓的我们的face share这样一个固定配合的啊，Policy的策略，那还有一种策略就是实际上就是be跟中间的这样一个所谓的这样一个方案啊，他的意思就是说我我给你设最小值，那我们保证你在最小值之内的这些资源是100%可以啊申请到或者100%不受影响的，但是呢，如果整卡。

有空闲或者整卡没有，就那些算力没有被分出去，那实际上是你可以抄的啊，但是你抄完之后呢，那如果这些资源被申请了，或者被其他的啊业务去占用了，那你需要把这些超卖的，把这些超占的资源去还回来。那实际上通过这种波的方式，那更能去，就是他在保证最小配额的这个基础上，能去最大化的用GPU的空闲资源，那实际上这种方式啊，是能兼顾强隔离以及这个这个就是利用率之间的一个平衡的。这是我们整个算力，格力在啊策略层面的一些支持以及实现。那我们还有一个非常重磅的功能，就是所谓的Q，那这个其实跟CP的这个概念是一样的，那我们在层面是支持高和低两种。

啊D的定义，然后这个pod的定义，用户可以通过的方式啊去做，这个是在创建的时候去指定啊，指定这个pod到底是一个高优pod还是一个Du pod。啊，比如说我们一般将在线的推理的这个pod设置为高优啊，因为在线推理一般是它的它的延迟啊，它的这个SLV是需要非它的延迟需要非常低啊，它的S非常高啊，因为因为都是给一些在使用。那还有一些所谓的do任务，更多是一些离线训练，那这些离线训练实际上啊，它的特点就是它的这个SV会比较低，那即使没有资源，我也可以可以容忍短暂的一些啊停止啊，但是我对整个GPU的这个利用率占有会非常高，我可以去使用你GPU闲置的一些资源。那在传统的方式下实现。不可能将在线推理跟离线训练回归在同一个GPU卡上，因为离线训练总会把GPU把这个在线推理的这些。啊，尤其是算力层面的一些资源去抢走嘛，对吧，但是有了我们的点混技术之后，那实际上啊，就可以通过高低高低高低的这样一个。

限制啊，或者是这样一个配置去做设置。那也就是说我们将在线推理设置成高优的，那我们将离线的训练啊设置成do的，那我们在这个调度层面，我们会将啊高优的这些在线推理去做打散的分布，比如说我们一个G的卡。分配一个在线推理啊，它总会就是它的这个，这种打散的作用是说它总能保证在这个就是。无理卡，你在业务就在线业务有需求的时候，我能将这周的这个底层的资源去做抢占啊，这样的话，最大化的保证在线的这个这在线的这个推理的这个业务总能去使用GPU资源，那在离线训练层面，我们更多通过B的方式去做填满啊，也就是说啊，我们可能在一个GPU的物理卡上去布一个在线推理，然后布多个离线训练。

那它的整个原理就是啊，底层比如说在线推理，平时它是在这个显示的时候，那这这时候这周的资源利用率肯定是最低的嘛，有很多大量的闲的资源啊，是被释放出来了，那这时候在上面的很多离线训练就会将这些闲的这周资源啊去做这个。使用和抢占，那这个时候他的训练，因为本身训练的对这个资源的占有会非常高嘛，那这个时候可以升，基本上可以达到100%，那当然是你在这个能满足存的前提下，因为存刚才我也说他本身是将在前分没法做overlap。那这个时候整体的这个解决利用率会非常高，那当前端的这个在线推理的业务有流量进来，他要去做搜索的推荐啊这些对吧，他要去做一个商品的推荐，或要去做搜索的这些。这些推荐的时候，那我们为何会迅速。探查探查到这个在线推理业务的，有这个业务请求呢，会将整整个上面的这些训练的这些process全部放住，那这个时候在线推理就去啊，完成他的这个前端业务请求啊，当这个前端业务请求结束之后。

那推理没有流量。底层的这个前置资源释放出来，那其他的离线又会占住，那最终通过这种方式，实际上我们可以将。整个底层的物理GPU利用率啊做的非常高，那的数据目其实我们有些这个有些业务有这个GP以分。啊，所以说这种在线混部的这个技术还是啊，尤其适用于又有又有这个在线推力，又有离线训练的这样一些啊客户场景的，那是能使整整个的单卡的业务层面的用卡成本极大的降低。那并且在这个性能层面，我们也是有非常多的mark的这个指标啊，因为刚才我也说了，就是你要做共享。啊，你肯定是要先去保证隔离的，对吧，你隔离做不好，你共享的利用率提升是没有意义的。

那这个隔离的好不好，其实更多体现在几个方面，第一块就是你的吞吐，不能因为有共享之后降低啊，大家可以看到就是我们的吞吐。啊，我们在做这个就是呃，QG的隔离之后的吞吐，它的sum值跟其实是一样的，基本上是一没有任何区别，也就是说你做了这个共享之后，你的整个了这个吞吐跟单卡的这个native的吞吐是没有任何区别的。呃，然后第二块就是你的这个延迟啊，不能是因为我有了共享之后，有了非常大的抖动，对吧，比如说你在线推理，那你原来单单卡导弹内得是20毫秒，那你如果做这个共享之后啊。一下子去对吧，有层面的这样一个问题，那肯定是不能接受的，那际上我们可以看到，就是我们有了这个层面的这个共享之后啊，实际上它的legacy本身的抖动。那方式没有没有跟这个就是就是它的抖动本身还是在一个非常大的精准线，没有因为共享层面有很大的这样毛刺的这个产生。

啊，然后在这个就是啊，QS方面啊，啊，也就是说我这个单个，呃，是不是。是不是只占用了他申请的这部分资源啊，那这个其实可以看到，就是我们我们的算力层面的QS是严格按照以上算力申请，当然它policy层面是有很多这个设置嘛，刚才我说过有大概有这个be，有有face share，有这个post，那在如果是强隔离的层面，强隔离的这个下面的Q就是按照你申请的这个QS去分配。啊，所以说你。不需要担心说我申请了20%的资源，但是在一些benchmark就是就是be size比较重的情况下，那我的这个的算力保证不了啊，这个是不存在的。然后下面是一个总的一个对比吧，啊，就是最终的我们的结论，就是我们在跑大量的mark的这个结论之后，Mark的这样一些测试之后，那最终的结论就是啊，我们整个垂P的容器虚拟化，实际上是啊，是能做到这个强隔离，并且是能去通过这个共享的方式去极大提升。

啊，用户业务的用款极大降低，极大提升用户业务的GPU利用率，以及极大降低业务层面的用款成本。啊，然后在整个数据层面，那实际上我们整个不管是在对内业务还是在啊自研业务已经是大规模去铺开用了，那我们目前是已经帮助上万的GPU去提升它的这个接收利用率。那在这个提升方面啊，比如说在线推理，我们一般可以将啊在线推理提升70%啊，这是我们向往真实测的一些数据啊，这个整个的提升还是非常可观的，那在线回场景下面啊，实际上我们可以甚至于将这个啊后的这样一个GPU利用率能升100%啊这样一个比例。那最终而且就是除了这些利用率的提升啊，就是我们在部署密度层面。

呃，也是起码是提升百分100%，也就是说原有的比如说一些啊业务。需要占用整卡，那这个时候可能我一个呃，一个业务值占用，比如说0.3卡，那这样的话就是我原有原有的一个无力卡，就可以给三个业务去使用。那通过这种方式我们也是能啊，就是从用户使用GP的角度啊，去降低啊用户业务，用户业务去使用GPU的这个用卡成本。通过这种方式将。在通过GPU利用率的提升的这个同时，将它的整个的资源成本啊去降到最低。OK，以上就是我今天给大家分享的内容，然后大家如果有什么问题，其实可以去通过啊。微信啊，或者通过在社区啊去联系我，好，谢谢大家的这个收听啊，再见。好的，非常感谢徐北老师的精彩分享，徐北老师首先介绍了当前基于Co的GPU使用方式以及弊端，然后介绍了如何使用云原生的方式去管理GPU资源，以及通过QGPU共享的方式来提高GPU的使用率啊。本期呢内容也是干货满满，那涉及到了很多细节的问题呢，大家也收欢迎收藏啊。本次的一个直播链接，那回放地址呢，也是我们当前的一个直播地址，也欢迎大家关注我们原动力云原生正发生降本增效大讲堂系列直播，我们在8月11日的晚上八点呢将进行第六讲。

好的，我们今天的直播就到这里，我们下期再见。