不好意思,刚刚调PPT花了一点时间那我们现在开始,我叫邵伟然后我是来自自己跳动的研发过程师然后今天我和我的同事曹赫给大家带来的分享的题目是...不好意思是在Qubilettis的系统之上去构建一个惊喜化和智能化的资源管控系统首先会由我来给大家去介绍一下我们今天分享的一个大纲诶,这个怎么了?怎么是?我们今天的分享主要会分为四部分的内容然后第一部分我们主要是会去介绍一下我们这个系统也叫catalyst,然后它的一个产生的背景主要是会去结合我们自己的一些业务特点去介绍一下为什么我们要去做这么一个事情它主要是去解决那些问题那在第二部分,我们会以catalyst的这个系统为稀有点详细的介绍一下它的实现的一些细节然后以及我们基于这个系统去在内场去做了在内场和火山去做了那些比较具体的事情那可能重点是我们会基于catalyst去介绍一下我们如何去实现在离线的混合部属从而去实现整个集群全职GN66的提升然后同时我们也会在catalyst的这个系统之上去扩展一些原生Qubilettis的一些调度的语意和能力比如说我们会去支持像GPU的这种共享调度还有更加惊喜化的这种微拓不敢制的调度等等然后此外的话,我们还会将catalyst里面其中一部分的比较独立的能力给抽取出来然后并且去形成了一些比较开箱解用的这种资源效能的套件然后实现这种直接开箱解用的能力然后第三部分的话,我们会用一些可量化的数字介绍一下这套系统在我们字节内部和火山落地之后产生了什么样的一些收益和效果最后的话是因为我们这套系统目前已经是一个carry的状态了然后我们后视的一些迭代和开发都会在开源社区里面进行那最后一部分我们也会简单的介绍一下我们在开源社区后面的一些计划以及我们的mouse stone等等OK,那接下来就让我们进入第一部分的分享首先为了更好的去解释这个事情我可能需要去对字节内部的一些原生的一些发展历史人做一个简单的介绍其实字节在大概是16年左右就开始去进行一些原生化的一些探索和改造到目前为止的话我们整个字节内部的几个服务体系大概会分为四块的部分然后第一部分的话主要是以一些典型的微服务为主大家都知道字节这边的微服务主要是然后这些服务他们的特点更多的是说是一些web类型的服务然后他们对于整个延迟会更加的敏感就意味着说这些服务可能会更加的去看重像CPU的调度延迟等等一些系统指标那第二类的服务的话主要是偏一些推荐广告类型的服务然后这些服务的特点是他们通常是用私家家去写的一些重型的服务然后这些服务在运行的过程中可能会去露的一些比较大的模型去做推理那就意味着这些服务在运行的过程中可能会更加的对于像类似的容量或者是类似的贷款等等这方面的资源会有一些比较重要的影响那就意味着说我们再去支持这些业务的原生化改造的过程中需要去做更多的像这种牛马级别的调度和管控然后第三部分的话主要是会偏向一些训练和大数据的作业比如说一些分布式的训练然后一些通过Spark去跑一些报表等等相关的作业然后也就是我们通常意义上所说的理线作业然后这部分作业他们的特点是说他们会更加地去种吞吐但是对于延迟相对来说不会那么敏感更多的是说我们需要在给定的时间里面去完成一些给定的任务那这部分的作业其实在资源使用形态上就能够和微服务这种业务形态有很好的一些互补的特性我们可以去利用这些特性去做一些混合部署和持发的事情然后第四部分的话主要是一些偏存手劣的服务然后这类服务可能对于稳定性的要求会更加地高那就意味着说我们再去支持这些业务上云的过程中需要去提供更强的稳定性同时在资源的编排和调度上需要去支持一些更加精细化的然后更加威脱不感知的这种能力才能够支持他们的诉求那截止到目前为止我们整个字节在国内的规模已经是非常庞大了然后这边给大家去设一组数字就是我们现在整个国内大概已经有了超过九十万的节点和超过一亿的炮的实施了在区运行然后去支撑了超过实施了六百万的在线的deployment和超过三十万的这种理线的这些作业那为了去支持这么庞大的职群规模和业务的场景我们需要去面临的一个问题就是说我们如何去进行更好的资源优化以及如何更好地去做这种精细化的调度去满足业务对于极致性能的要求具体来说的话主要我们希望说为业务提供的能力有三点第一点是我们希望资源从业务的视角上来看是尽可能实话的也就是说我们希望去尽可能地去利用不同业务他们对于资源使用模式上的这些差异性和互补性去实现混合部署然后使得说我们可以将全集群天级的利用率尽可能地坐在一个比较平的水平线上从而去提高资源利用效率第二点是我们希望为业务去提供更强的弹性能力这样就无论是像HPA、VPA或者是资源超买等等这种模式然后去一方面是说使得我们在资源流转的效率上能够得到一个更好的提升同时也使得说我们可以给业务去提供更多的这种售卖模式上的形态然后使得业务可以去用更低廉的总体成本去获取自己所需要的算力然后第三部分的话就是我们希望我们整套编排调做的体系能够实现更强的经济化管理的能力因为我们知道不断的市面上会有一些新的这种硬件和一些业务类型出现比如说像大模型这种我们就希望我们的整套编排调做的体系在面对这些新场景新硬件的时候能够以一种更加智能化和可插拔的方式去进行经济化的调度和支持为了做到这一点我们就抽象出来了我们从那一步孵化了一套新的系统叫Catalyst然后这个英文单词它其实是衍生字Catalyst就是第一个单词C的那个单词它的本意是催化剂然后我们是希望说能够基于地条系统为所有运行在Guberlattice之上的这些work load去提供更加强劲的这种资源编排和管控的能力从而去实现更好的这种业务的支持那大家可以看到我们整套系统大概从上到下会分为四层最上层是我们的API层然后在API层里面我们会去去扩展和补充原生Catalyst的这种QS的表达能力因为原生的那个表达能力当我们去需要去做一些更精细化的这种业务诉求的时候其实是不太够的那通过扩展这个我们可以去给业务一个统一的这种节目的视角业务可以在这个节目上去表达自己的一些更加精细化的资源管控上的诉求然后在中间这一层的话我们会有基于原生的schedule framework去写的各种各样的这种scheduling的这种plug-in从而去实现精细化调度的能力同时我们还基于原生的那个custom metric的那个API去扩展了我们资源的一条数据链路从而去为中心层的这些无论是幅画上的推理还有资源的超买等等这些能力去提供一些数据支撑那在单击测的话我们会有一套资源的这种监控基于eBPF的监控体系然后去补充我们所需要的单击上的一些所需要的监控数据同时我们会有一些agent的组件去结合这个实施数据以及业务运行时的一些具体的状态从而去实施的调整业务的资源供应量的情况从而去匹配从而去更好地在匹配业务资源诉求的基础上去实现资源的附用那最底下的弯弯就是自己内部定制的内核我们会在内核里面去继承一些更多的patch去补充像io 像网络等等各方面的这种资源隔离的能力和机制从而去实现更好的这种单击的隔离的特性ok下面将时间交给我的同事老贺然后后面会由他来给大家介绍一下catalyst的一些具体实现细节好的然后接下来向大家介绍一下catalyst在自己一些应用的场景第一个也是最重要的就是在离线混布在线混布其实来源于我们在做容量规划室遇到一些挑战因为在线的微服通常是具有一个朝气现象就是当晚高峰的时候然后因为用户的使用量可能比较多然后所以对资源的消耗也是非常多的然后当夜间的时候可能用户的使用量就变少了然后对资源的消耗也进入了一个低谷然后我们从图上可以看到在那个波峰和波谷之间的这部分资源其实在夜间是被浪费掉的然后第二个现象就是说我们的业务方他们通常会有一种过度申请资源的这样一种趋势就是从而去保证他们服务的一个稳定性然后这部分过度申请的资源也就被浪费掉了那么如何去有效地利用这部分资源呢然后我们在刚刚稍微介绍到的自己的这些业务的类型的时候也有提到就是通常这些在线的微服务它是比较测重于比较测重于CPU的使用比较看重服务性RBC调用的一个实验然后离线的这些作业它其实更看重内存以及吞吐然后这两种业务类型它们对资源的使用模式其实是天然上是互补的所以我们就很自然地想到就是去用离线作业去填补业间的时候在线微服务对资源使用的这样一个空白对 因为我们将在线的微服务和离线的作业把它们混不在一个节点上然后不可避免的它们之间就可能会有一些互相影响所以首先我们要做的一个事情就是对服务进行分析也就是QL引入一些QLS的等级就QLS怎么理解呢就是说它其实表达了服务对于资源质量的一种诉求它其实可能会在很多维度去影响服务的资源质量比方说这些单机上的隔离的这些方式我们是怎么配置的以及当资源发生竞争的时候然后我们去做一个压制还有驱逐的顺序然后其实我们在K8S原生的QLS等级的基础上扩展了四种与其争交的QLS级别然后我们可以从这个表格来看到第一种叫Dated Cours然后顾名思义呢它就是独占的CPO核心它不会与其他的工作负载去共享这些CPO核心然后在此技术之上我们更进一步地去支持一个语异叫妞马班顶就是允许它去绑定妞马或者独占妞马从而获得一个更加极致的一个性能然后它的话会比较适合一些对性能极度敏感的业务比方说刚刚介绍到的苏广推他们的一些在线的一些服务然后第二个叫Short Cours然后它的话就是就是多个服务它会共享一个CPO资源池然后在此技术之上呢我们也支持说进一步根据这些服务的内心然后比方说可能有一些像Flink或者一些Redis这样一些不同类型再去进一步把分更吸力度的资源池然后它的话会比较适合一些能够容忍一些CPO线流或者说一些服务之间的干扰这样的一些服务典型那就是微服务然后第三个叫Requiem Cours然后它的话就是我们常买出来的一些资源它的资源质量其实相对没有保障然后甚至这些泡的可能会被驱逐然后它的话就比较适合对延迟不敏感然后对吞吐会更敏感的一些业务典型典型那就是一些模型训练或者像大数据的一些作业然后最后一个叫System Cours然后它的话是一些预留的CPO核心然后主要是为了保证单机上一些比较关键的一些A进测的一些稳定性然后大家可能会有一些疑问就是为什么我们的这些QRS等级都是以什么什么Cours来命名的然后这是因为我们在时间的过程中然后发现服务对资源质量的诉求主要是以CPO为主的所以我们就以CPO作为一个主导的资源维度然后对QRS等级作为一个命名然后会显得可能更加清晰一些然后就在这四种QRS等级之上的然后其实可能右方大家会有一些更多的一些资源质量的诉求然后我们其实通过引入了一个叫QRS Inhancement这样一个概念去做一个支持的对典型就比方说刚刚介绍到的Numa Banding然后一起Numa独占还有我们在做流量打标时候它的一个流量的等级对 我们有了这四种QRS级别之后其实对于不同的QRS级别我们会对它有不同的资源管理策略然后那么我们怎么去注入我们这些定制化的资源管理策略我们首先来回顾一下KPS原生的单级资源管控的方式就是Kubi8它会通过CRI协议然后去调用运行室KantarD然后KantarD它会把翻译成OCI的一些协议然后其实从这过程中我们就可以看到其实会有一些Hook点然后一个比较简单的方式就是我们想到可能在单级上引入一个旁固的一个agent然后让它去绕过Kubi8直接与KantarD进行一个交互然后去异步的去更新你们期的一些资源分配对 但这种方式就是因为它是一个异步的它就可能会造成一些racing然后导致业务的性能可能会有一些损失然后如果我们要去做同步的一些资源管控其实我们也会有这样三种方式对应了三个Hook点然后第一个Hook点就是我们看到第三张图就是我们引入一个CRI的proxy去解驰Kubi8对KantarD的一个CRI请求然后在这个proxy中我们就可以去定制我们的策略但是这种方式会有一个问题就是CRIproxy的运位可能会比较麻烦然后第四张图KantarD其实在比较高的版本中它引入了一个叫NRI的特性原生的去支持对资源的分配去做一些扩展然后我们可以在我们的NRIparking中去定制我们的一些资源分配的策略实现一些注入对 但是这种方式其实就要求KantarD的版本要在1.7.0以上才能够使用可能很多场景下其实不满足的然后最后一种就是我们可以对Kubi8去做一些Hook也就是我们接下来要介绍到QRM的方案QRM的方案我们其实是借鉴了Kubi8中的Device Manager和Device Parking的这样一种设计模式我们去引入一个和Device Manager同期的Manager叫KOS Resource Manager建成QRM然后它的话主要是为了去取代原生的CPU Manager和Memory Manager因为CPU Manager和Memory Manager它们的策略是写死的不只是扩展的所以我们就引入了QRM可以通过一个插件化的方式去实现对像CPU然后内存然后网络将一些资源维度的一些增强的一些管控策略然后我们这个QRM Manager它就也会把自己注册为投报级Manager的一个子Manager所以我们可以借助KOS原生的一个Vitope管理的能力去实现像Numa 清合这样一些增强的策略然后其实我们就是在Kubi8的策略去做扩展还有一个优势就是说我们可以在炮的OrderMate的阶段就提前的做一些资源的分配然后一些积极一些资源的准入然后如果发现这个节点其实不能满足一个资源分配的需求的话可以在比较早期就把它给拒绝掉然后产生一个OrderMate的失败然后从而去触发像一些虫雕度这样一些国际OK然后我们从工程上具备了这样一种策略扩展能力之后那么这个策略我们具体要怎么设计呢然后这就是服务发向和资源预测要做的事情然后这里我们其实面临的一个问题就是我们如何去评估一个节点它有多少资源可以出让给理先作业就是它有多少资源是实际没有利用的然后我们做资源做服务发向的话可能一个比较直观的想法就是用服务的一些业务指标然后比方说它的一些P99的请求实验或者说它调用下诱服务的一些粗务率但是可能对于我们在单机上的这样管理的组建来说如果去基于业务指标去做管控的话相对是不那么直观的也不那么容易获取的然后另外一个就是像这些业务指标通常是有一些服务的框架去提供的但是可能在我们内部会有各种各样的一些服务框架然后它们打出来的这些业务指标可能在含义然后包括在格式上也会都有一些不同所以我们想到了一个比较容易实现一个比较折中的方案就是基于系统指标去做服务发向和资源管控然后具体来说我们就会具体来说因为其实我们如果我们去问一个业务它最在乎的一个系统指标是什么往往它自己也是不清楚的所以我们就引入了一个data pipeline然后对这些服务的业务指标和它的系统指标去做一些计算和分析然后去分析出与它最在乎的一些服务指标比方说P99的实验然后它相关度最高的系统指标比方说是单机上的一些CPU的调度延迟然后当我们找到了这样一个比较核心的对它最重要的一个系统指标之后我们会进一步通过data pipeline然后去分析就是它期望的P99有调度实验它所对应的一个CPU调度延迟的这样一个期望的值然后从这张图中我们可以看到就是这条红线就是我们就是业务它期望的一个CPU调度延迟的一个期望值然后下面的这条蓝色的线就是我们对这个业务的一个资源的攻击量然后下面是对它一个放大我们可以看到看到通过我们去调控对它一个资源攻击然后使得这条黑色的线就是这个业务它实施的一个CPU调度延迟的一个状态然后使它能够稳定在这样一个目标值的附近然后从而使它的P99的实验也能够稳定在它期望的这样一个值的附近然后我们有了这样的符合发向能力之后我们其实还需要去结合一些单击上增强的一些隔离的一些手段主要是在这样几个维度去增强了资源隔离然后第一个就是CPU然后CPU的话其实是一种比较简单也是比较有效的方式就是通过CPU赛的去划分不同的资源池可能一个CPU池是给在线给达雷克铁扣给去用的一个是给12扣去用的就把它们做一些隔离然后对于像R3开始然后还有像内存带宽的一些竞争然后我们是通过英特尔的RDT技术然后去实现了一些隔离对然后刚刚对于一些一些像搜广推之类的业务然后我们发现通过CPU赛去做管控的时候可能不是那么的及时然后我们对于它的话就引入了一个叫Skyde idle叫一个调度类然后去实现对 理线作业的一个快速压制对于内存来说我们主要是通过像CGOOP级别的一些内存回收然后去避免去出发CGOOP级别的一些直接内存回收然后导致的一些线流然后还有通过像绑定NUMA去实现一个究竟的NUMA访问去加速服务的一个性能然后我们还引入了一个用户态的一个for the weather去实现一些像驱逐或者 Job开始这样一些操作就是当发生资源竞争的时候去做一些到底然后对于磁盘这个资源维度来说然后一个比较简单的策略就是我们对在离线进行了分盘然后去硬隔离避免他们之间的一个干扰然后还有我们对在线业务他的日志去做的IO做一些异不化的处理然后在这机会之上我们还引入了像IOCOST这样一些CGOOP VR的一些隔离能力然后实现了一些实现了IO的一个权重还有线流对于网络来说一个比较简单的方式也是通过多网卡的方式让在离线业务区用不同的网卡然后在这机会之上我们也引入了一些像流量分级然后并且对于不同级别的服务的流量我们通过EBPF加上EDT算法去实现单级上的一个带宽限制对 这里可能需要强调到一点就是隔离它只是一种手段而非目的实际上我们是应该通过应该基于我们实际的业务场景去找到最合适的隔离的方式我们前面介绍到的其实都是偏严发的角度然后当我们这个系统提供给SRE然后对于我们从运萎的角度然后也提供了多层级的一些动态的配置管理的能力然后首先就是集群级别它会是一个modernal配置比方说一个集群它是否使用混布然后第二个级别就是接电池的级别通常我们可能会对CPO的接电和GPU的接电划分不同的接电池然后它们也可能会运行一些不同的资源管理策略然后第三个级别就是接电级别然后它的话主要是用于比方说发生一些故障的时候我们可能把故障的几个接电单独圈出来然后去做一些debug的一些操作然后还有一个就是对于刚刚介绍到服务发向来说我们其实支持服务级别的一些差异化的SL的配置就比方说我们刚刚介绍到那个期望的系统制标然后它的一个目标值是多少OK然后第二个引用场景是GPU共向调度然后这个场景它的一个问题的背景就是说原生的K8S它支持整卡的力度去做一个容器的调度和分配然后在一些场景下比方说AI推理的场景或者说开发机的场景它实际上是用不满一整张卡的然后我们把整张卡分配给它就会造成一个比较大的一个自然浪费所以我们就就实现了就基于MGPU这样一种这样一种隔离的机制然后实现了一个GPU共向调度的方案然后它的话会支持1%力度的算力的力度以及以照币的显存力度的一个容器调度然后我们从这张整体的架构图中可以看到我们实际上是在K8S原生的Sky-GLIN 4M Work这样一个扩展机制的基础上去实现了一个叫GPU-12用的一个PARGIN然后我们在单机上的话是通过Device-PARGIN的机制然后实现了一个叫MGPU-Device-PARGIN去做单机上的一个MGPU资源量的一个上报和分配然后这里我们其实会遇到一个问题就是K8S原生的Device-PARGIN的API其实是非常受限的比方说其实在接口参数中是没有像POD和Container它的一些原信息的所以我们的Device-PARGIN其实是不知道当前它自己在处理的是哪个POD和哪个容器然后这里我们就也通过一些比较巧妙的方式去对它做一些定位然后另外一个问题就是说我们其实引入了两种扩展的资源一个叫算力一个叫显存然后对于原生的Kubit来说它其实会把它当成两种设备这里有可能造成一个问题就是算力和显存实际上被分配到了两张GPU卡上这个容器实际上是起不来的所以我们的一个解决方式就是说在调度器里面直接对算力和显存做一个出合我们可以看到我们就是在这些扩展点去做一些增强实现了一个两级调度然后第一级就是K8S原生的接电调度第二级就是一个卡级别的调度然后我们进一步的把这个调度算法去抽象成了一个最优化的问题然后我们通过一个DFS的搜索算法然后加上一些简直的操作去优化这样一个调度的性能对 这一部分因为时间的关系可能就不进一步展开了然后我们在那个11月的KubitCon北美上也会有一个相关的分享大家如果有兴趣也可以关注然后第三个应用场景就是脱补感知调度对 这里大家可能会问其实K8S的Kubit不是已经有一个脱补解决这样一个组建了吗然后为什么我们还需要做这样一个事情是因为K8S原生的调度器它其实不会去感知单机上的一个微透铺然后这就可能导致调度器把这个泡的调度到一个相对不是那么好的一个节点然后就可能导致单机上Kubit在做Ornament的时候造成非常多的一些Ornament失败的情况对 然后第二个问题就是K8S原生的这些透铺性和策略它其实只考虑了牛马透铺所以我们就做了两件事情第一个是引入了一个脱补感知调度把中心的调度和单机的嘴台分配做了一个打通然后第二件事情就是我们在牛马透铺性和基础上然后去扩展了一些其他维度资源的一些透铺性和就比方说在大模型的训练的场景下其实我们往往会通过RDMA去加速GPU之间的一个通信然后就一个是我们可以从左边这张图中看到单机上的GPU和RDMA它们其实也会有不同的一些连接方式比方说最上面的可能是连在一个PCIe入Compice这样一个级别之下然后这个就可以保证是我们可以通过GPU Direct RDMA就GDR这样一种方式去加速GPU之间的一个通信然后更吸力度的我们其实可以看到GPU和RDMA它们所连接的PCIe Switch它的一个级别越低就它们之间的距离越近其实性能会越好然后第二个场景就是说我们的RDMA其实底层连接的交换机也是分为多个级别的然后可能最近的就是叫S0然后可能再更下层我们叫S1然后那么在多级多卡这样一些训练场景之下然后可能在一个交博中不同泡的然后它分配的RDMA它们如果属于同一个S0它的性能可能就会比跨S0之间的交互会更好一些这是我们的第二场景然后这一部分因为时间关系也不作展开了然后我们会在库比抗北美的分享中去做详细的介绍对然后最后一个场景叫就是资源相能套件对它的话其实是因为一些像云上的用户或者社区用户对它们来说去落地混布的门槛其实是非常高的因为它可能需要它有很多类型的一些业务总盔比方说要有在线幅然后它还有有你现在的作业然后并且这些总盔的业务可能还都要有相当大的一个规模然后它才会得到一个比较好的一个资源收益所以为了降低这些云上用户或者社区用户他们使用就是他们去提高资源效率的一个门槛然后我们就引入了这样一系列的一些能力对我们可以从这张图中看到就是绿色的部分除了最右边的这个混布然后左边我们引入了三个功能然后第一个叫规格推荐就是我们会给予一个服务它历史的一个资源用量然后为它推荐一个比较合适的一个request的一个值对然后第二个叫潮汽混布潮汽混布的话就是说我们通过HPA然后实现一些节电的分时复用然后我们因为潮汽混布我们不会让在离线运行在同一个节电上所以因为不需要更多的一些增强的隔离措施所以相对本来看也会更低对第三个就是节电的潮汉对然后我们会通过一些webhook去拦截Cubit一些资源商报然后对它做一些放大然后并且我们通过像单机上的一些干扰检测会一些环节的措施进一步保证了它的稳定性然后为了使这些潮汉的资源能够更稳定然后我们也用了一些像长短周期结合的一些预测算法然后使得这个更加合理对然后通过资源超卖就能是用户在无感知的情况下能够调度更多的泡的然后去提升它的一个资源分配率然后进一步去提升资源利用率OK然后接下来我们来介绍一下Kargas的在自己内外常购地的一些对一些效果然后当前Kargas已经部署超过90万的节点然后管理了数千万的CPU核心然后把整体的一些资源利用率然后从23%提升到了60%OK然后最后一部分我们来介绍一下社区的一些进展对 我们已经我们从QE开源到现在已经发布了三个版本然后0.1版本中我们主要支持一个基础的一个混布的功能然后在0.2版本中我们对这些混布功能做一些增强然后在0.3的版本中我们也用了一些像刚介绍的配置一些智能化的算法然后在0.4版本0.4版本我们预计会在就是这个月底去做一个发布然后就包括我们刚刚介绍到像拓布感觉调度以及自愿意像汤验中的这样一些新的功能OK然后大家如果对我们这个项目感兴趣非常欢迎大家和我们交流并且参与到社区的一些工作中大家可以通过我们有一个社区的双周会然后是每两周的周四晚上的7点半对然后还要可以通过Slack以及社区的废书群然后和我们做一些联系对然后接下来是我们的之后在CoopyCon北面上的一些演讲大游戏区可以关注好对然后我们今天要分享的就是这些然后大家如果有问题欢迎提出你好我有两个小问题第一个问题是刚才提到GPU的过程中其实它是把那个算力和显存分开但事实上对于服务来讲比如说我是一个应用的部署者可能我对我未来的那个GPU的算力或者显存的使用量并不是特别的清晰那这地方如何去做这个决策而且这地方为了显然如果你是十分空分的话还带来一个严实上的影响包括后续我教我了解好像生态上对监控那一块做的也不是特别精细那么如何去让我们它需要的比如说的算力的一个水位或者显存的水位这是第一个问题对明白对 这确实是一个问题这个我们可能会有一些几个方式就比方说第一个是我们刚刚介绍到的规格推荐然后去做一个结合对 规格推荐对于新服务你没有它的一直运信心怎么去选择呢就比如说对我来说选择一个显存比如说我只选择了两季可能我的服务都跑不起来那么这个可能对我来说是一个困扰对就是一些就可能会采用一些更保守的一些策略的就像说可能出示配置的一些比较大的值对 就比较大然后另外我们其实就我们这个IPGPU的方案就支持一些QoS的能力就是GPU调度算法上的一些你说显存可以抄吗对比如说我选择4GB但实际上我可以用的更多对 是的就假设两个容器它跑在一张卡上然后一个容器它可能申请了30%的一个算力当然实际上只用了10%然后在我们一些QoS的配置之下其实可以另外一个容器就可以把这部分没用的资源给用起来但如果另外一个容器起来之后不会出现显存分配失败的情况了吗这个情况股灵性是不是会有一些风险对 显存我们是硬隔离的然后算力什么对 算力上我们可以会有这样一些这样一些灵活分配的一些策略这种灵活分配的策略对你后面的那个比如说用户车的那个监控显示会不会也有一些影响有办法去很好的刻画就比如说我升级30%但实际上我有一40%那我的监控能否就是很好的刻画这个使用率情况呢对就是其实我们可能会有一些不同的线比如说可能有它它的一些申请量然后还有一些它实际的分配量还有它实际的实际的一些使用量就通过不同的曲线去做一些刻画你们是基于时间片的统计去算那个算力的使用率是吗对 是OK第二个问题我想了解一下刚才你提到QS我看到你们那个第一个dedicated calls你们讲的是说关于原来NUMA是强制作坊间的但是在sharing的那个calls里面shared calls里面反而是没有NUMA做清合的因为在我认知里面好像因为CPU set它其实是是绑到盒上但是NUMA清合和它这个还不是一个维度那么为什么shared calls里面是是不可以去做这个NUMA清合的因为有些场景比如说一些由于维加过的原因比如说MD它可能仿存延迟比较高那这种情况下其实是这种共享的和通常讲一下如果你不去做NUMA清合它也会带来一些仿存延迟的问题这个可能也也有业务上的POR延迟会有影响这个你们是有什么特别的考虑吗这可能对首先那个QS和那个和那个enhancement我们叫enhancement其实NUMA binding它更多的是一个enhancement的能力其实两个现在没有说一定会有强绑定的关系正交的只是说对于我们的业务小型来说可能现在Dedicated和NUMA binding这个组合关系使用的更多所以我们现在是支持了这样的一个能力但是不代表说short course不能去做NUMA binding这样一个事情其实是一个最佳实践推荐值对吧实际上也可以在那边做一做更进一步的一些配置对明白好的结束了对因为时间的问题可能好谢谢大家对也非常欢迎大家参与到卡拉雷斯特社区中