时间到了大家下午好欢迎来到我们这个演讲我是来自英特尔的郭云春这个演讲是一个由IBM和英特尔合作的演讲那坐在下面的两位是来自IBM的蒋鹏慧和苏俊另外我们还有一个来自英特尔的同事长志他因为个人原因不能来到会场但是他也做了很多的贡献那我们这个演讲的题目是通过East2o Kepler和智能调度实现优化的微服务性能和可持续性我们会覆盖这样几个话题问题 挑战和要素East2o和微服务Kepler和能耗模型接下来就是我们实现的一个AI助力的一个智能调度的一个算法然后是个结论我们先来看一下问题和挑战微服务能够给我们云原生的应用开发带来灵活性和便捷性所以微服务在云原生的领域使用越来越广但是微服务它天生带有分布式的特性其中有细利度的隔离然后多组互的管理等等这些都会导致能源消耗的增加从而导致基础设施的成本更高另外就是因为它的分布式的特性所以导致它的微服务之间的通信也非常的多不仅有同一个机器上的通信也有跨机器 跨集群的通讯这些都会引入延迟 并且影响性能我们从环境可持续性上来看因为微服务的快速的应用已经导致就可能会导致能耗和碳足迹的增加这些也是可持续发展需要关注的问题所以我们需要在性能需求和环境可持续发展中取得一个平衡这就要求我们尽可能的去优化我们的微服务部署能够提高能源的效率并且能够在不影响性能的情况下提高能源的效率我们关注两个问题一个是性能的优化 一个是能耗的优化我们希望在性能优化和能耗优化中找到一个相对来说比较优的一个解下面我来讲一下就是现状的一些要素微服务刚才介绍过了就是它是一个松偶盒的架构并且在云原生应用的领域使用的非常广泛服务网格它能够给微服务提供流量管理附带平衡 可观测性等功能East2是一个开源的服务网格的一个软件然后还有就是KaplerKapler是一个新星的一个CNCF的一个Sandbox中的一个项目它能够提供能耗的监控我们下面会有一些详细的介绍这里我不多说另外就是K8s的调度本身已经是一个灵活并且可配置的一个架构并且我们可以去插入我们自己的策略它相对来说已经各种策略和算法已经比较多但是这些策略和算法的配置和应用还是要我们人去做一些决策所以说我们希望能够去借助AI来实现智能决策和自动化因为AI这里在我们IT领域现在用IT院为领域用的也比较广了如果说AI能够助力到K8s的调度策略的自动化的配置上去我们也许能取得一个更好的效果基于这个想法我们设计了这样一个系统架构就是Kapler和Eastel它们都能够监测到一些系统的和应用的Metrix这些Metrix通过普罗米修斯传递给我们的核心组建智能监控器然后在智能监控器里面使用了这样一个sorry 错了 智能调度然后在我们的智能调度里面使用了AI的算法我们会根据这个环境的情况去生成Reward然后这个Reward会告诉Policy Generator去调整它的调度的策略调整到一个比较优的一个情况下然后调整的策略就会通过K8s的API配到ETCD里面去然后K8s的调度通过监控ETCD的变化然后去重新Risk Generator就重新调度Police重新调度完Police之后系统进入一个新的状态然后新的状态下又会产生Metrix以及新的Reward然后这样是一个循环的这样几个循环的次数下来的话我们就会在系统中取得一个比较好的一个状态这个是我们的一个架构的设想然后接下来就是我来讲一下我们会介绍一下就是刚才介绍的几个要素再展开来介绍一下那那个首先Eastio和微服务这个Eastio其实是大家都肯定很熟我相信来到这儿的话所以我就不多说它是一个开源的服务网格的这样一个平台然后它的服务代理采用的是N1然后能够给我们这个云元生的应用带来标准通用的流量管理 安全管理和摇测的功能其中摇测的功能是Eastio非常重要的一个功能那Eastio就是通过生成一些服务指标来去监控的那这些专门针对流量来说它有这样一些指标比如说像RequestCount就是请求数它是Counter类型的然后还有RequestDuration就是请求的实验它是Distribution类型的还有就比如说RequestSizeResponseSize就是请求大小和想应的大小对于GRPC来说它也有这个消息数这样一个统计那通过这些指标我们就可以对应用中的网络的流量有一个全局的包括到一些细节的一个非常完整的一个途径就能够出现在我们的我们就能够掌握到为了更好的去做测试我们选择的是康奈尔大学开源出来的一个微服务标准测试的一个套件叫DestarBench然后DestarBench它有很多的workload就是很多的负载我们使用了这个Hotel Reservation这样一个负载它是模拟了一个酒店预定系统的一个微服务的应用它使用的是沟浪编写然后服务和服务之间的通信使用的是GRPC去做的通信在我们对这个负载去做深入的分析的时候我们发现它一共有八个业务逻辑然后有九个后台的数据服务的逻辑数据服务的数据相关的服务然后另外还有一些基础设施之称的这些服务所以一共是十九个服务从服务的个数以及多元性上考虑我们认为Hotel Reservation是可以模拟一个真正的微服务的一个附载的所以我们会使用这个附载来去做测试在我们把这个附载部署到K8S上去之后并且启用了Eastel之后我们就可以在Kialli里边监控到服务和服务之间的调用以及它们的流量那左边就是它的服务和服务之间调用的链路图然后右边就是它的一些指标的一些细节信息就是它的这个流量指标的信息好 那我下面把时间给彭惠好 谢谢营春刚才我们已经讲到了这个我们在微服务当中的话遇到了问题我们如何平衡这个能耗和这个我们的性能然后我们刚才也介绍了其中的一个要素是关于我们用比如说Eastel来进行这个服务网格的一些监控来了解我们这个整个流量的这些性能然后那接下来的话我给大家引入另外一个要素就是Kapler和能耗模型那Kapler的话这个是一个新兴的一个CNCF的项目那么今年的话已经通过这个CNCF的review进入Sandbox阶段那么主要是由Red High的Inter和IBM的这些同事还有一些其他同事一块来去维护的这个项目那么当然大家如果感兴趣可以加入我们然后一块来维护这个项目那Kapler的话在这里头我们从这个名字里头来讲的话我们是讲的是Koopnate Space的Ephesite Power Level Exposer所以我们也搞了一个协音所以取了这几个名字的首字母然后正好跟我们的Kapler定律也比较吻合然后我们需要在希望能够在能耗上面有所突破那么从设计机出的时候我们就有三个理念第一个是无处不在第二是清亮级第三个是科学那么我们也研究过现有了很多的这些能耗的监控的工具那么很多能耗工具蛮强大但是可能有很多的极限性比如说它只是X86或者是说它只是骆机那么实际上我们知道在云的环境下面的话这个虚拟机还是占主流的那么如果要是不支持这个虚拟机的能耗的这个测量的话那么这些工具可能相对来说还是有局限性的那么同样的话这个架构也具有很大的这个扩展性那么扩展性的话能够支持除了这个X86那么同样对ARM对这个S390这些的话也提供相应的支持那么再有的话就是我们采用比较清亮级的这种EBPRF的技术然后对整个的系统进行监控的话对系统的干扰会比较小那么再有的话就是说我们其实如果大家去看这个就是研究领域的话有很多很多的PAPR但是这个PAPR也凉又不起那么IBM研究院有很多的同事参与到这个Capler项目上然后从中的话也有很多的这个PAPR已经发表的和未发表的都用用用到这个我们的这个产品当中去所以整个这个能耗的模型的话相对来说还是蛮成熟的当然了这个也是我们需要和大家同人一块来去把它逐渐的更加完善的过程那么Capler这块的话显而言之的话它主要是使用的EBPRF的一个机制来去提取我们的这些CPU的instruction counter或者是我们Linux的一些trips point然后通过这些的话我们有一些就是通过这个RPL直接能够获得这些能耗数据那么有一些的话我们获得不了的话我们从逻辑上面把这些信息从通过一些workload的家载把它放在里头去的话形成一些模型然后这样通过一些机器学习的方法然后训练出一些模型之后的话再把它放到我们的这个虚拟机上面去然后进行估算注意点这块的话大家可以观察一下的话我们这边左边的话主要是EBPRF的这个流程然后右边左边这边是EBPRF来获取这个trips point或者是这些 counter然后下面的话是我们支持就很多的扩展性包括这个RPL、STPI或者是我们通过这个GPU的一些家属器来去获取这些能耗然后把这些能耗都放到这个Cyberload去的话我们通过访问Kubernetes的API的话和POD的这些信息进行关联这样的话我们就能够获得到这些POD来获的这些能耗那么有一些的话直接的话我们就突出给这个普罗米修斯然后任何普罗米修斯兼容的这些抗修门的话就能够获得到这些能耗那么当然有刚才讲到了有一些的话是虚拟机这样的话我们就需要一些模型这些模型的话我们有一个model server这个model server的话它会训练出一些模型来或者是离线的或者再线的方式这样的话同时的和我们的Cyberload进行工作然后形成一个我们统一的一个训练的结果然后接下来的话进行模型的估算然后生成我们的这些能耗那么在这里头的话我们具体来看一下的话从这个逻辑这边的话那么主要的一些指令包括CPU的instruction然后什么catchmiss啊或者是cycle这些那么这些的话那如果支持RPL的话本身它就这些信息就能获得到那么对于这个虚拟机来说的话我刚才讲到了如果要是没有办法使用就KMM如果没有穿透的情况下的话我们就需要使用这个Mosnolink的一些机制来去对这些能耗进行一些估算那么在这里头的话Cyberload提供出了很多的这个指标那么这些指标的话那么既有本身我们这个node的信息我们的这个pod的一些信息那么同样的话也有一些关于就是细度的一些contributor或者component的一些指标比如说我们的一些call CPU的一些等号比如说一些uncall就是那些GPU的一些能耗包括DRAM 包括IO那么这些的话都会组合在一起来给你提供一些细度的一些这个指标那么这些细度的指标的话就可能能帮助大家能够获取到这些botnack然后来对这些进行一些调油那么同样的话也会对这个coop那次上面的不同的limus space的话进行汇种那么下面的话就是一个这个模型服务器就是一个model storemodel store这边的话主要是我们讲到了因为这个model store本身它是来去模拟我们的work load然后采集出这些信息来应用到我们的虚拟机环境下面所以说我们这边分成就是我们这个code的这个主程部分和这个我们的deploy的部分那么大家可以访问我们开pro网站的话去看到我们model store的这些主见包括我们的model store我们的model DB就是这里头有一些很好的训练好的那么再有的是capler的话就是我们的主要的这个工程那么这个工程的话可以把这个capler DB里头的那些训练好的一些模型的话提交给这个capler那么部署的时候的话可以有多种模式那么有一些的话就是把训练的结果直接的注入到这个capler里头去直接去使用那么这种的话那么就不可辨再有的话就是我们可以有一些动态的一些online的一些training的过程那么这个过程的话就比较友好那么能够随着我们实时的这些动态的变化来获取动态的这些能好的信息好然后由于我们不同的这个大家的这个技春器和技术器或者是我们采集的样率是不一样的所以大家选择的模型可能也会不一样比如说有一些的话只支持sigroup或者是只支持couplets或者是io就是说我们根据我们不同的这种workload我们可以选择不同的modesower里头的这个功能级功能特征柱我们在这里头来去使用到就是我们实际的这个能耗的估算当中去那么在这里头的话可以选择其中的一种或者几种来进行估算那么在这里头的话也有很多的这个counter那么在这里头的话选择的这个模型的话也是不一样的那么最近的话我们那个有做了很大的这个扩展那么除了这个现行的回归的方式的话我们现在的话还有这个T度回归的模型然后多像式的回归的模型可以和这个都根据不同的这个workload来进行选择来选择不同的精度和不同的特征值我们开布勒的这个主席的话特意主负要强调一下这个事情所以说这个我们也做了很多的研究的工作所以在这块的话大家可以根据不同的这个需求来去选择不同的这个模型那么到底说了半天了我们开布勒长得啥样那开布勒实际上输出的就是一些matrix但是matrix不是很友好的能够大家看到所以我们和Graphana来结合在一起这个Graphana这边的话就可以看到我们根据这些matrix的话生成了很多的这些输出那么在这里头的话中间的这一块的话是针对于不同的这个pod每一个pod上面的我们这个能耗的这个这个根据时间来生成的这个火焰图那么在这里头的话再有的话可以把它分解出来有不同的这个contributor帮成我刚才讲的是call的uncall的或者是我们的deram或者是iOR这些那么接下来的话在这里头是我们针对于不同的name space的能耗的这个信息那么这些信息的话可以根据这个实际的比较的话大家可以来看到不同的这个能耗可以看到实际上capular整个的开销是蛮小的那么针对于这些的话我们一般来说只是根据这个告诉说我们多少胶儿或者是千瓦那么在这上面的话可以根据不同地区的poe来去生成相应的这个我们的这个相对于美亚天然气是有所带来的能耗是什么样子的那好我先停到这里然后先交给开文好谢谢彭绘刚才营春和彭绘分别介绍了East Hill和capular我想在他们两位的讲过程当中大家反复地听到几个关键词能源资源 能耗和调度那随着技术的不断的迭代和眼镜我们也在不断的追问一个问题就是在有限的系统资源下我们能不能够完成更好的调度从而降低能耗我们也注意到这一个问题是越来越多的引起了大家的探索所以我们希望有一种方法可以集成已有的技术通过智能化去解决实施监控 自动化来增强微服务的管理所以接下来我们在这里展开的给大家介绍一下AI助力智能调度这一话题我们的研究和进展那提到这个调度我知道调度其实要考虑的因素很多在这里我们把它简单的归纳为三类包括性能因素 能耗因素还有其他因素这里所说的其他因素主要是指一些环境因素还有包括人员的因素而这一因素恰恰在我们后面的研究当中发现是最为重要的一个因素之一所谓的智能调度就是我们系统的考量上面三个种类的因素将它们进行一个实验从而完成调优 构建和评估再找到一个最适合的调度策略部署到实际应用生产环境当中这里不但涉及到对性能 能耗指标的捕捉和计算更重要的就是我们刚才提到的其他因素也就是人员因素的考量因为我们知道调度的策略都是人为制定的那有没有更好的办法帮助我们去制定调度的策略或者是从性能因素 能耗因素这些指标当中找到我们相应做进行调度策略制定的一个规律所以为了验证不同的调度策略会产生不同的影响 特别是能耗上面我们做了两个实验首先可以看到这里面有两个试译图这是我们实验环境当中展示了个三节点的K8的集群一个主节点 两个工作节点在所有的节点我们都部署了Capler和Israel在主节点我们还是部署了加压应用和智能调度逻辑这里面的数据存储服务和业务逻辑服务是根据调度的不同我们部署到不同的节点当中通过这两个场景的对比或者是我们就发现一个非常有趣的现象首先我们在第一个场景当中我们是尝试着使用了K8S的默认的调度策略就是每个服务三个副本然后他们会被不同的调到不同的节点当中第二个场景的话我们在设计这个策略的时候就考虑到一个问题是不是同样的一个应用他们保持更好的亲和性我们可以在无论是数据存储服务或者是业务逻辑服务进行一个规律分别部署到不同的节点上会更有效这里面我们给大家介绍一下我们的测试环境测试环境的指标以及我们在整个测试过程当中所使用的线程线程我们是从2到128连接数也是相应的乘以时进行调整数据是从2K到10K测试时都是60秒下面有列出了我们的测试命令所以实验的结果就是在我下面这张图里面展现的我们还是可以看到两个不同的策略其实它产生的Latency TPS包括性能其实还是有很大不同的从性能方面测试结果的区别主要还是体现到了KBIS默认场景它的无论是P99延迟还是TPS都是要好于第二个我们想象的这种亲和性场景右侧就是Grefana这个图看到的是两个不同场景的能耗这里面我们以为亲和性会降低的能耗但实际上两个场景的能耗基本相同所以做了这个实验之后就提出了一个问题既然我们想象的策略并没有带来很明显的不同那我们是不是有更多的策略怎么样考虑这些其他的策略我们甚至是不是可以应用AI上面的一些特点能够帮助我们人员上因素上更好地捕捉到不同的调度的策略所以接下来我们请彭绘再次回到台上给我们来讲我们用AI如何来增强这个智能调度的好 谢谢凯文刚才讲到了我们有两个场景一个是利用KBIS默认的调度那么这样的话我们有两个worknode可能两个pod在一个node上另外一个pod在另外一个node上面然后第二个场景上面我们把数据有的跟数据服务的放在一个node上面然后把所有的basin logic和业务逻辑的放在了另外一个node上面然后我们得到了一个结果那么在这个过程当中的话我们人为的去想象了我们有一些调度的策略但是这个调度的策略我们想想是不是还有更优的一些方案那么这样的话我们就借助了一些AI的一些方式来去跟我们进一步的这种探究来去那么在这里头的话我们采用了一些AI的方式的话这里头主要给大家讲这个强化学习的这种方式那么后面的话我们还有一个通过居类和销量数据库来去做的那么在这里头的强化学习的话英文是reinforcement的能力那么在这个过程当中的时候我们左边的话是一个比较经典的强化学习的一个方式在这里头的话涉及到几个要数这个agent它就要像大脑它来去做策略的制定接下来下面这个environment是环境那么在这里头的话有一些新书和输出那么这个大脑的话会制定出一些action这些action会输用在这个environment上面environment会根据这些action的话来进行一些状态的改变那么它这个状态的改变之后的话这个environment的话会给这个agent进行一些回馈那么在这里头的话就相当于给它一个reward那么这个的话是一个正反馈还复反馈这个我们不确定那么这个的话我们就可以引用到我们这个场景下面的话这个大脑的话就是我们智能调度的这个模型而这边的这个environment的话就相当于是这个我们K8s的这个集群那么这个里头的话这个智能调度的话它主要是来接受这个我们的这个当前的这些状态比如说它观察我们的这个工作负载包括e-steal和cabular的一些metrics以及相应的我们的这个系统的一些性能值本来CPUmemory和其他的一些利用率那么接下来的话它会进行一些思考然后来生成一些action这些action会作用到这个环境当中去也就是到我们的K8s这个环境当中去然后接下来的话这个环境做出了一些反馈之后的话它会接受这些reward来进行下一步的这个运算那么在这里头的话K8s集群这一块的话它是接受我们的这些action的一些动作来去对整个集群的状态进行一些调整然后接下来的话会生成一些reward来反馈给我们的这个智能调度这一块那么在这里头的话我们想了因为我们这个K8s上面的这些状态到底是什么样的是合理呢我们自己想象出的一些状态的话可能不一定是合理的所以我们参考了这个K8s的这些文献的话这里头的话给出了我们一些标准的一些状态空间因为在这里头的话实际上在这个前患学习里头的话主要是构造一个Q矩阵Q矩阵里头的话它是m乘n的一个矩阵里头这个矩阵里头的每一行可能是一个状态空间而又矩阵的每一列的话就是take action那么在这里头的话每一个元素的话就相当于是说我当前这个状态take action之后我会获得多大的人有reward的一个情况在这里头然后在这里头的话我们就会把这个应用到我们的这个里头去来去分别定义我们不同的这样的一个状态和相应的动作那么状态刚才我讲到了有K8s里头相应的一些不同的状态级那么这些动作里头的话我们虽然这个K8s里头讲了弄的这个轻和性或者反轻和性或者是通过某些标签但是它是一些action的话那么我们可以通过不同的选择就有点像夏琦一似的是到底往前走 往后走我们这个里头就是这个泡的到底放在哪个node上面去然后我们有几个副本数以及我们需要水平扩展还是水柱扩展然后形成一些action然后针对这些action的话我们会算出一个award这个award的话我们主要是采用三个这个维度比如说我们的因为刚才我们讲到了要做这个能耗的有坠油然后我们性能的坠油还有一些其他因素所以针对这个的话我们会把它归一化然后形成一些权重然后最后算出一个award了这个award的话就形成了一个我们mch组织分当中的一个元素然后接下来的话我们就会对每一个元素的话去添我们相应的值在这里头的话实际上它每一周一步的时候它都会算一个q值那么这个q值的时候的话会参考reward的情况以及相应的当前状态和将来状态因为它有一个要预判它要预判几步它才会好的所以通过这个来说的话我们模拟了一个模型然后应用到我们当前的场景上面去然后这个算力的话就相当于是说我们能够判断一下我们这些泡的究竟是放在哪个node上面去然后果真的话这个前化模型的话它就给我们推荐出了几个可能的一些轴法然后有一些相应的award那么其中的话有一个就是说我给大家展示一下的话这个状态就是相当于是说我们把数据库还是放在某一个node上面去然后其他的业务逻辑的话我们并不是放到另外一个node上面去而是相应的把这个放到了kbis的话比较均匀的分配到不同的node上面去那么接下来的话我们就按照这个前化学习的模型的话进行了相应的验证那么接下来的话我们看一下这个部数的方式的话就是通过刚才Desi讲的就是我们的这个自动调度通过edcd来去反馈到我们的这个kbis集群里头然后得到了一个这样的一个分配的一个泡的一个状态的一个结果那么有了这个结果之后的话我们同样的话施加了这个workload那么施加这个workload之后的话我们看到我们的这个pqp9的延时是率现的这一条然后吞吐率是这个也是率现的这一条那么在这里头的话可以看出来我们的吞吐率跟kbis的基本上是平那么我们的这个pqp9的延时反倒好一些了那么这个的话因为我们本身这个均匀性的这个分配然后导致了这样的一个比较好的一个结果那么从能耗的角度来讲的话我们得到了更可喜的一个结果就是说由于我们要展示这个变化嘛所以最左边的和最右边的话就是我们采用了前面两个场景当中的能耗的计算的一个方式而这个中间的话就是我们采用了新的这个调度策略来形成了这个能耗的一个这样的一个结果所以说通过这样的一个智能调度的一个结果的话我们发现通过这个就机器学习或者是人工智能的话能够帮助我们去找到一个比人想象的可能更好的一个这样的一个结果那么同样的话我们在这里头的话给大家形象的去看一下我们到底大家哪一种的话大家是一个哪样的一个排名那么在这里头的话第三个产品的话排名是蛮靠前的然后后面的话就是前面两个场景那么再往下的话就是另外一个我们通过这个具类分析然后通过我们分析这个我们的这个炮的之间的一些特点来通过我们的相量数据过来进行的相应的这种调度那么这个调度的情况下的话我们就要分析我们的工作负载的特性到底是CPU密集型的还是iO密集型的然后通过这个的话我们把它形成一些模型之后的话那么再来新的这些我可乐的时候的话我们再通过我们实现的模型的话来进行相量数据的比配然后来形成一个比较好的一个调度的一个策略是这样的然后最后小节一下的话就是说我们现在的话是通过E-Still和Cyberler的话能够帮助我们来会收集到这些能耗的一些和性能的一些信息这些信息的话对于我们智能调度来说是一个很好的input那么这些input的话能够帮助我们通过这些比较成熟的一些人工智能的一些模型来去实现我们比较好的智能决策实施监控和智动化的一个过程那么再有的话就是从整个的验证过程当中的话我们看出来有一些这个推断的结果是有效的那么最后的话我们想做一个广告就是说我们Cyberler的话这是一个sustainability的一个repo这个奥格上面的话我们主要是Cyberler的项目但是我们也有一些其他的cliber或者是我们的sustainability的一些项目那么这些项目的话也正在就是蓬勃的发展过程当中然后我们每两周的话会开会然后大家如果要是对这个贡献比较好的话我们就会接待大家去加入成为Menten了然后这样的话大家可以一起弓箭这个我们Cyberler的这个项目也是大家也是蛮open的就是我们很多同事在美国这印度这日本还有这欧洲很多同事都在一起工作所以也是蛮国际化的一个项目然后最后一个广告就是我们有一位同事在楼下在这个K-Ox上面这个展台是P4P4A然后如果大家感兴趣的话今天和明天的话他都会在这里头然后会有更详细的关于Cyberler的一些介绍那好 我先挺到这里然后大家有没有什么问题或者建议对方会 建议团队我觉得您讲得非常好而且工作做得也很好就是基本上把我们写的可持据算白皮书里面那些主要观点在你们这儿我觉得实现得很好因为我们要平衡就像你说的可持续和性能安全等等的这些关系你这里面提到了智能化的一些东西而且你说到用到积蓄学习的模型深度学习的模型你具体用的是哪些模型然后你们现在这个全名大模型我觉得这个提法就有错误因为我们觉得是应该用基础模型是吧大模型只是大与年模型它一种你们没考虑过用一些比如说现在比较活的那种基础模型来结合这些复计做一些分析谢谢 程伯其实我们没有提大模型我们提的就是用的强化学习模型和我就说你们用的是就像现在最热的大模型对 所以我们还没有用那种对你用的还是一些比较成熟的模型对就是深度学习的对做基础学习对 是的好 谢谢我有几个小问题就是一个就是咱们这边介绍的这个就是在那个真实的生产环境里面就不知道有没有已经有这种上线的适用的效果如果有的话可以跟我们分享一下第二个就是本身我们这一块的调度像是通过AI去做这种训练包括这种反馈式嘛 对吧就是在这个AI本身就是我们来完成这件事情本身的开销这一块就我不知道有没有评估包括刚才说的那个就是咱们就是想要用这种项目呢或者说大概什么样的场景比较适合或者说它的整个机军的规模大概要达到什么程度我们用AI的调度方式才能取得相对比较好的效果然后最后一个小问题就是那个我刚才理解的可能就是我们现在通过AI去调度实现这种它的部属的这种调度我不知道后面会不会去基于这种更细利度的比如说流量的调度去做一些这种更细的这种反馈式了对 谢谢非常好 我觉得这几个问题都非常好如果记得不对的话你帮我提示一下第一个是就是说我们这个用在生产系统上面整个的Cabular的话我们也接触了很多客户然后有一些客户的话都是用在生产系统里头的这里头的话应该从那个我们的Meeting Minutes让大家可以去找到一些生产的环境然后第二个问题就是说我们AI训练的话对整个系统的一些影响我觉得你问住要害了就是说我们其实很多的训练和预先的准备这些工作的话我们不得已的话挪到另外一个节点上面去做就是我们没有在这三个节点上面做否则的话我们曾经试图跑在其中的一个节点上结果把那个节点跑掉跑挂了 根本就起不来了所以整个训练的开销还是蛮大的然后再有的话你讲到是流量这一块的话确实这个细腻度的话就是蛮重要的因为我们现在的话可能只是这个实验当中的第一步或者第二步那么将来的话我们如果要是对流量这一块进行监控包括Esteo给我们提供很好的监控的这个话包括我们通过一些其他的工具也能才能每一跳当中的部署的情况你可以想象 我其实我们虽然有比较简单的我们的十几个服务但是实际上组合起来也是蛮多的然后它整个构造出这个矩阵的话时间也是蛮多的所以整个这个过程如果再加上细腻度的话整个训练的过程就会非常的耗时所以我们先从第一步来仇起然后这样的话我们才能够在有限时间内跑出这个模型来去训练当然我们如果要是将来设计好了更好的一些优化的点因为我们现在的话给它提示一些就是如果要是我们指关键这几个我们人为先过滤一下然后接下来的话只是在过滤的这几个点上面进行相应的调整这样的话算的这个算力会小很多因为那四个问题我抽过了哪一个还有一个就是那个就是您觉得咱们这个就大概什么样的场景比较适用于我们这个或者是继续的规模明白是这样的就说实际上我们也做IT这么多年了可能关注这个Performance也是非常多的也非常重要的RAS所以整个这个就是从性能这个角度来讲实际上大家已经比较满成熟的这些技术和手段了但是现在的话包括这些就是我看除了IBM以外的话国内的也参加过很多研讨会的话像阿里同训华为他们也建了很多的这些标准和规范来去支持可持续计算那么在这个过程当中的时候就一定要考虑这个能耗和性能的平衡因为有的时候这个能耗实际上好了它性能实际上下来了所以在这个过程当中的话我觉得我们这个方案的话在将来尤其是在我们碳中和碳拿风的这个大的背景下面的话是一定要考虑的一个这样的事情所以这块的话所以可持续计算这块的话可能我们的大背景都在里头然后这个角的这个环境下面的话那么可能是有一些企业先走到前面了但是可能后面的话也会越来越多的企业跟上来来去做这一点事情好 谢谢你好就是那个我问一下就是前面有一张图就是我把就是谁说都可以就是那个Capler那个我看你们主要采的是那个CPU的相关的数据但是有几个问题就是我们那个对就是就有个Metric那个对它主要是一些CPU的数据就是但是我们的就是反正就是我们平时工作的经验上来讲反正因为就是能耗这件事情确实是很重要就是说因为它会影响到那个商家密度之类的东西它实际上本质上除了性能其实还有成本就是反正它确实很重要但是我们在工作过程中它可能会有一些问题就是说是这样就是这个功耗呢它实际上就是你除了在调度上优化的时候其实还有一些是如果你调度没有办法避免的时候它实际上就涉及到capping嘛对吧就是说其实能耗本质上本质上就是我的认知啊它和频率相相关对吧就是和主频之类的东西相相关或者当然你说的这些就是你把CPU利用率降下去它肯定是有用的但是我们实际测的效果是说你CPU降下去其实和频率相关性非常非常高然后呢但是我的问题是就是开不了本身它会考虑就是比如说它的X嘛就是因为你除了调度以外你除了采集以后有没有一些主动限电的策略就是capping的策略但是capping呢现在我的认知就是一个机架上或者是一个服务器它本身能耗CPU只占一部分对吧它其实如果你跑EGO的话那EGO其实更是大头就是CPU或者是内存带宽比如说ARM的那种带宽它就也是大头就是后面我不知道就是社区上这块怎么考虑以及这块你们有没有一些后续的一些规划好的谢谢这个问题也比较深入了正好我也做过一些研究啊因为在这里头的话CPU这块是最鞋眼的或者是说刚才这位同事讲的是说跟主频相关的那么这个除了这个CPU以外的话其实内存啊包括IO实际上这些的话实际上或者包括我们EGO系统的这些的话也是会有影响的但相对来说的话内存的这个消耗会比较稳定比如一季的话大概是0.04千瓦没小时就说这块的话相对来说我们如果申请了多少内存的时候的话我们一般按照这个数目就能算出来这个能耗那么包括IO的话我们有不同的这个Device那么有一些的话是比较固定的就本身数据传输的但是也有一些比如加密卡IBM很多加密卡实际上它的能耗也会比较耗时或者GPU的刚才你讲到的这个所以这就是为什么我们有一个这个Accelerator和这个Customization的过程那么这个过程的话实际上社区也是非常欢迎大家来去针对于自己的场景的话来做相远的扩展那么这一块的话能够扩展出一些大家适合自己场景的一些包括这个建模的这一块的话也是我们社区里有比较完备的文档怎么样地去训练出一些模型来然后把这些模型夹载到我们的这个整个的Cabular的项目当中去所以这位同事讲到的也是非常重要的一点就是我们现在给的例子里头CPU是在大头大家看到的但并不是唯一我们其实很多人研究的话也都扩展到方方面面然后实际上在这里头的话不同的这个比如说IBM的主机和这个我们X86的话实际上我们模型是不一样的我们正好最近我们正在做IBM主机的这个机程和这个Cabular所以整个的这个大家的模型是不一样的然后也相应的这个考量方式也是提供了另外一个角度所以也非常感谢这个同事帮我们透开了试录您好我这儿来去补充一个问题吧就是刚才咱们这个讲解其实全都能耗这个角度来去讲那我觉得说应用在跑到咱们的实际的这个KBS环境当中的话还有两个更重要的指标一个就是稳定性第二个是荣誉性因为从稳定性上来说的话您那个是一个比较简单的测试环境而实际生产环境当中的话微服之间的这个依赖关系可能是一个完全网状的相对来说是比较随机的因为它是松火核嘛还需要调用所以在这种情况下的话这个就是经过深度学习接着强化学习它得出来的这个结论它是在这个round time的时候去强行的去介入去调度呢还是说是在下一次部署的时候去调度因为我看到您这个在CabularCabular这边去调的这些策略的话全部都是KBS继续自己提供的一些原生的策略然后是在这个调度上面去进行干预原生的这些策略它进行调度的时候它其实是在下一次部署的时候或者是外部环境发生了变化的时候它才会触发这个动作那如果说您这里去强行继续干预的话那是说就是运行室环境直接进行干预了呢还是说OK我也是下一次部署的时候比如说发板啊或者是有这个外部环境发生变化的时候进行干预对 我觉得你这个问题也是非常好的其实我们这个实验本身是找到了一些可能的调度的一些策略它是需要改变但什么时候改变其实这是一个很开放的一个问题因为我们本身部署好了之后的话它本身在那个预围如果你要是强行地做了的话就像您刚才讲到的我们可能稳定性荣誉性就会上市所以这个整个事情的话并不是说我们找到了一个好的我们就去干预就改了而是说刚才您讲到的可能我们下一次部署的时候或者是一个比较idol的时间我们再去再去有一些调整是吧好 然后第二个问题的话是荣誉性的问题因为如果从能耗这个角度单独去讲的话比方说我们有如果有实态服务器那可能平常的时候会保证说所有的这些泡的全部都分布在这实态服务器上面但是它一定不是一个能耗最低的选择如果从能耗最低角度来讲的话那可能是咱们为原态服务器设定了80%或者什么样的一个罚者的情况下它会尽可能地去部署在五台或者六台的服务器上面可能其他的机器就会被集群的策略去在资源池边去删剪掉那这种情况下如果说在既有的这些节点发生了故障的情况下那么剩余的节点还能不能将当前所有泡的容量全部都附载掉我觉得这就是一个问题所以从荣誉性角度来讲可能也是要有一点考量的没错Cyberl实际上您可以看到实际上它会部署到所有的Running的Node上面去所以它会采集所有的当前的符本的能耗那么如果要是比如说某些符本发生了迁移或者是发生了推出的话或者减少或者增加的情况下的话它实际上就是给了我们一个指标它不来决定我们到底是应该把它杀掉而反倒是我们刚才讲的通过智能调度来提供一个策略或者是说我们通过后续的方法介入进来去做一些调整所以它更多是一块表我们管它叫做Meter然后这个表来去帮助你提供更多的一个指标是的 可观测性更加完整OK 好 谢谢好 谢谢好 那我们时间差不多了我们开完设计欢迎大家加入然后有什么问题可以给我们开一宿可以联系我们好 谢谢大家