大家好首先自我介绍一下我是来自于英特尔软件先进技术事业群系统软件部云软件解决团队的工程师任杰我获得同事看录也是我们团队的架构师一起为大家带来一个技术分享技术分享的题目是开普勒在特定的硬件平台上是准确的吗这是我们今天的议程首先是介绍一下开普勒的基本概念大家首先看到了开普勒这个名词首先想到的是什么一看大多数人比较熟悉的是天文学的开普勒定律事实上社区也是在定了全称的名称以后发现有这么一个协英港并且设计了这样一个logal那么开普勒的全称在英文上全称是Copinatis Efficient Power Level Exporter所以这里也有几个关键字一个是他自己与Copinatis是针对云元生的应用的然后他针对的是power-level的metrics进行一个exporter一个数据指标的导出这个项目是社区是从2022年起步的然后在短短的一年多的时间里面吸引了大量的开发者涌入并且得到了Red Hat, IBM以及Intel等公司的大力支持这个项目在今年的6月份已经正式登陆了CNCF成为一个杀箱项目它的一个核心思想是利用了EPF的技术针对continental-level的Resource Usage进行计算并且进一步推理出在continental-level的一个能耗的情况它针对power相关的metrics进行了收集和导出并且针对一些云元生的应用程序定义了一系列的功率模型用来进行功率的测算以及推理那么这里有一个基本概念就是我们大家在物理学上都学过的power等于energy-treat time那么power就是我们所说的功率或者功耗energy是我们所说的能量、能耗那么从单位上说就是eWatt等于一焦而没秒这张图是整个开普勒社区的相关的生态里面的模块和系统的一个框图我们可以看到绿色背景部分就是开普勒本身它作为一个exporter它所包含各个软件模块的一个情况下面的红下面的红框部分就是我们针对的特定的硬件平台或者是虚拟机平台进行了一个能耗的统计和测算这个红框部分就是开普勒这个项目的核心value所在我们知道在一个硬件平台上我们可以很容易的拿到相关的能耗数据比如说是裸金属平台的话它们有这样一些测量电量的一些手段可以让我们得到一些平台上原始的耗能数据对于虚拟机平台来说虽然我们虚拟机里面相关的一些文件系统或者一些电表的数据的话没办法透传但是我们也可以引入一些机器学习的方法来进行相应的训练以及推理但是问题就在于这些硬件平台上的能耗在被收集之后被开普勒内部一个叫做Node Energy Consumption Collector的这样一个模块收集到以后我们仍然只能知道在工作节点上的能耗的情况但是在云原生的场景下我们基于Kubernetes部署应用程序的时候在系统当中是在工作和进行交互的是一个一个的container或者pod那么这些container和pod的能耗如何获取呢这个就是开普勒这个项目所要重点解决的问题那么它隐入的是一个基于比率的这样一个方法的一个功利模型这个比率指的就是这个pod或者这个container在系统中消耗资源的使用率去除以这个整个系统节点它所消耗的资源的数量怎么得出了这样一个比率这样一个racial作为推理推论pod或者container耗能的这样一个依据这就是开普勒内一个简单上的一个理论依据那么这些到底用哪些资源来判断这个资源使用率来作为这个比率的决定因素呢那么它就引用了eBPF的技术在内核中相应的观测点来观测跟这个container或者跟这个process相关的一些硬件指标根据这些硬件指标来类比于这个资源的使用情况那么这些指标包括一些performance counter里面性能技术器当中的一些技术技术指标也包括CPU使用的时间也包括在网络层面的一些软件ARQ的一些收发的一些技术等等此外我们可以通过C-group当中可以提取到process ID以及container ID之间的一个对应关系我们在内核观测点当中实际上是选择了这个叫task switch的这样一个hook点在这个点上实际上是可以判断出当前我在观测的是哪一个process的相关技术那么就可以得到process ID和这些指标的一个对应关系然后再根据C-group当中可以得到process IDcontainer ID的对应关系进行反查最终定位到这些指标属于哪一个container进而可以进行使用器级别的推算这就是整个开普罗的一个理论基础这是开普罗社区目前的知识情况我们可以看到社区其实是很用心的在做事情他们在针对不仅针对了可知计算也针对了机密计算进行了相应的规划努力的时间覆盖各种应用场景包括高颗易购的硬件平台包括容器的部署方式以及虚拟机的部署方式等等这里绿色的部分是已经实现的功能然后蓝色的是社区正在开发的红色的是在规划中的backlog中的一些item这里就是介绍了一下我们要开普罗能够从特定的硬件平台上采集到哪些能耗数据的源头分门别类可以集集ECPU的带内的数据以及平台的一些带外数据包括易购平台上针对GPU的一些能耗另外 开普罗中重点定义了这样几个概念一个是绝对功耗第二个是动态功耗以及带机功耗绝对功耗指的就是我们从Matric松手获取到原始数据并且计算出来的功耗就是绝对功耗它是绝对值但这个绝对功耗实际上并不能真实地反映一个工作负载或者一个container它的耗能情况因为这里面包含了idolpower所谓idolpower指的是当这个工作负载运行在这个系统上的时候无论这个工作负责是否在真正的工作还是它在进行大量密集的计算这个恒定不变的一个功耗情况这个称之为idolpower而dynamic power才是真正能够反映出这个工作负载或者应用程序对资源的一个消耗情况所以我们在太普罗的模型里面我们重点关注的是dynamic power这个是对容器的真正耗能产生决定影响和有意义的一个参数这就是刚才我们讲的两个方法一个是基于比例的方法其实这两个方法并不是并列的关系准确地说regression的方法也就是我们通常在机器学习中通常我们在机器学习中经常采用了一种回归测试的方法的话更多的是用来解决在虚拟机展展这样一些环境下面我们无法获取原始可能好数据的场景下我们用机器学习的方法来弥补而不管我们是从裸金属环平台上获取原始的数据还是通过机器学习的方法来推测数据最终这个数据都是基于节点级别的整体系统的一个耗能而我们要把它推换出基于容器的或者基于泡的级别的耗能的话还是要用到这个racial方法所以它们不是一个对并列的关系而是一个递进的关系我们相信能够通过物理方法获取到的测量到的数据一定是最准确的所以我们在优先考虑就是测量数据而对于机器学习的数据的话我们认为它是可能会有一定偶然性或者一定准确性的考量的这是训练模型的一个流程图我这里就跟我们今天的主题关系并不是特别大所以我这里只是一直带过感兴趣同学的话可以参考下面的社区的两篇论文其中一篇已经在今年7月份的IQ博弈的大会上已经发表了而另一篇的话也将在出现在CNCF的技术博客上好 我们下面主要介绍了关于整个开普勒的一个工作基礎和一个实现原理的部分接下来可能朋友们可能都会关注一个关于点就是说讲了这么多它的一些基本原理那么到底开普勒最终爆出来的数据是不是准确的呢或者这个开普勒在某个平台上会不会有差异呢这些为了解决这样一些肯胜为了解决这样一些肯胜我们肯定需要引入一些标准化的测试方法来验证我们的一些问题来解雜我们这样一些问题所以我们设计了这样一套针对平台的一个测试的验证框架以及在不同视角下看对这个框架进行相应的扩展这是我们这个框架的一个基本的工作原理和方法论首先它一定是基于自动化的一样一个流程我们充分利用了Get Up Action的机制在Self Hosted Runner上运行我们的工作流然后我们尽可能的遵循社区整个社区的测试框架的一个实现方案那么开普勒社区它本身在马上大部分是基于勾浪的所以它选择了是进口这样一个测试框架因此对于我们的 Platform Validation来说这个框架也是follow这样一个测试框架的它实际上提供了领域特定的一个语言模型然后也能够生成定制化的可视性比较好的一个格式的一个测试报告另外我们也要引入一个独立的用于测量功耗的这样和计算功耗的这样一个工具这个工具的目的是作为一个我们测试用力当中的一个比较基准因为我们可以从开普勒得到一个得到一些结果那么我们怎么去判断这个结果的准确性或者这个正确性呢我们就需要有一个独立的工具来提供一个对比的基准它会独立于开普勒儿去采集同样的采集一套数据然后采用的是采样和平均的这样一个计算方法然后把它作为一个对比的依据而对比的目标呢就是在这个目标应用程序的部署前后分别采集一次整个节点的一个功耗数据那么这个差值我们可以尽丝地认为就是这个应用程序的部署所带来的能耗的变化那么我们测试用力上的话主要是关注两方面一方面是正确性一方面是准确性这是我们在之前在我们的这个实际环境上跑的工作流的一个情况因为我们在整个就开普勒儿社区它基于的这个测试框架也是自动化测试的话它是在一个单节点的集群上进行的就是我们可能大家都比较熟悉的KIND这样一个单节节集它是一个在Dock融运型的K8S单节点集群因此我们相应的一些img的话都要在测试的时候实施地load到KIND的Dock融器当中去因此我们的工作流分回两个阶段第一个阶段是一些测试弓箭测试artifact的一个构建第二个阶段才是真正的一个测试用力的执行我们这里字体比较小我简单就描述一下就是它的测试了基本的执行步骤大概就是在首先是在我们的目标机器上部署一个KIND集群然后再将这个KIND集群上把开普勒这个运用程序部署上去最后在开普勒这个程序上在观测其他运用程序的耗能情况那么我们在部署KIND集群以及在部署开普勒的前后都用了刚才说到的达雷达这个工具进行独立的采集那么就可以得到相应的一个差值来做观察这是一个基本的一个设想自动化测试用力的设计可以是设计的一个考虑主要是从两个点上去采集数据一个是在开普勒上报数据的这一测就是一个Spot原始暴露出来的Metrix以及在普罗米修斯当中经过汇总之后通过计算通过实施数据的一个汇总和整合之后可以得到了一些通过PromeQL的查询语言可以查询到相应的一些有意义的一些参数和指标那么考察的角度就是正确性和准确性当然自动化测试用力也有它的局限性最主要的局限性就在于我们可能拿到的数据是节点级别或者是CPU Package级别所以它是一个整体的功耗或者能耗那么我们怎么去衡量容器级别的准确性呢这里面就在测试用力设计上就不可避免的会带来一个假设就刚刚前面提到的它要用一个差值来做对比那么假设这个差值是我们所观测的这个目标应用程序它部署所带来的耗能那么这里面就有一个前提假设了在我部署这个应用程序的过程当中不应该有额外的干扰否则这个假设的前提就不成立了但事实上我们的测试环境可能是比较复杂的可能会有一些额外的干扰举个例子比如说这是一个多租户的环境比如说在这个环境上除了container之外除了k8s之外可能还会运行一些vm那么这个vm里面它的应用程序的启动和执行会带来很多的不确定型所以这次自动化测试用力的一些曲线型我们从实测情况来看的话在数据的有证确性方面基本是OK的而在节点级别的准确性上也是比较好的我们这里有一个图可能字体比较小大家看不清楚大家可以线下的时候从我们的PPT都在顾必康的网站上都已经上传了大家可以在线下查看具体的数据情况我再简单讲一下就是这两例也是节点级别的一个比较偏差值的情况这个偏差值是用的是普罗米学生当中统计出来的开普勒报的数据的计算值以及我们的独立测试工具的差值我们可以看到这个差别是非常小的基本是一个各位书或者是小数典后面的这样一个偏差值是符合预期的但是在容器级别的比较上我们选取的一个在这个case里面我们选取的是观测开普勒本身部署所带来的能耗变化所以对比的对象是在开普勒部署前后Validator工具所采集到的差值以及在普罗米学生中查询到的开普勒POD所对应的能耗我们可以看到这个差别巨大物理实际上这个测试方法我在这里列出这个表格的目的其实是想告诉大家我们在测试用力的时候是经历了这样一个过程实际上这个测试用力是一个invalid的用力为什么这么说因为我们在部署开普勒前后分别采集数据这个所拿到的能耗数据包含了开普勒这个应用程序在启动过程中在它ready之前所有的能耗情况而普罗米学生当中能够计算出来或者能够查询出来的能耗是开普勒在正常工作之后它上报的数据所以前者一定是比后者要大一些所以这样的测试用力用这样的观测方法来做对比的话其实这个测试用力是一个invalid的测试用力那么我们怎么改进这个问题呢我们应该在开普勒正常稳定运行之后去观测一个新的应用程序工作复杂的部署来观测它的耗能的情况这个会比前面测试用力更加的准确那么我们这里就选取了比较常见的一个工作复杂叫Redis那么我们先观测一下它的部署情况当然我们为了能够让测试用力尽可能在下面下落了很多局限性所以我们在一个尽可能干净的环境下运行我们可以看到单节点的Redis部署前后的一个对比情况还是比较理想的我们进一步做了测试就是考察Redis集群从单节点扩充到双节点的一个变化情况这是一个在普罗米休斯当中采集到的这个曲线的情况这个颜色不是很突出一个绿色和蓝色绿色是原始的泡的而蓝色是新霍龙出来的泡的那么我们这里也用了一个比较简单的方法就是大概目测了一下它的平均的位置大概在这个位置的地方有一个值然后和我们这个工具采集出来的值进行对比得到了一个大致的情况还是比较理想的从定性的角度来说还是比较理想的进一步扩容从两个Raprica扩容到三个相关的数据在这里展示所以对于Redis这样一个简单的应用程序我们考察了它的部署以及它的这个扩容条件下的一个能耗的变化情况以及和我们的比较简准确对比可以看出在一些相对比较理想的测试环境下开普罗的数据在准确性上还是可以信赖的当然因为由于自动化测试存在很多的局限性所以我们其实可以更多的引入一些人工测试来弥补这个测试用力上的一些缺陷那么人工测试用力的话我们好处在由这样几点一个是我们可以去观察一个真实的相对比较复杂的工作负载它的一个耗能情况另外我们可以充分地利用云元生领域一些很成熟的可观测性以及数据可实化的工具来通过人的肉眼观察的方式能够很直观地找出相应的规律和比较他们之间的差异这样一种方式我们相对比较容易的设计我们的测试用力并且这些测试用力在稳定了以后我们还可以进行持续的自动化相对于我们的方法论就是我们先用人工测试的方式将一些测试用力稳定下来然后我们持续地把它自动化这样能够使测试用力更加的丰富也能够更多更真实地反映开普罗的准确性以及其他方面的一些表现我们在实际的测试工作工程当中我们选择了我们英特尔最近刚开源的一个工作负载就是云元生的AI推理流血线这个就是我们这个项目的开源的GateHop的地址感兴趣同学线下可以关注一下这个项目那么这个项目主要是在云元生的环境下部署AI推理的一些工作负载以流水线形式来进行AI模型推理并且可以进行多路的推理每一路采用不同的技术不同的加速技术来观测他们之间的差异所以这张图是一个四公格我们从四个角度来展示AI推理的一些情况左上角这是一个single page application就是单网页的应用程序它实际上是比较了五路输入的视频这五路输入的视频其实原始的视频流都是一样的但是我们采用了不同的加速技术对它进行硬件AI推理的加速我们去比较它的变化情况这个图里面可能现在看起来效果并不是特别明显但是如果我们回到左下角这张图的话就是它是从另外一个视角来看推理的效果选举的指标是推理的FPS也就是每秒推理的帧数来进行对比这个图里面我们可以看到采用不同的加速技术以后最终的FPS的效果差异是很大的其中应用了英特尔志强第四代可扩展处理器当中自带着AMX的高级矩阵扩展这样一种加速技术的这一路推理它的FPS的效果是最好的它只是最高的右上角这个图就是开普勒社区默认的自带的Granfana Dashboard的视翼图在这个图里我们可以只关键去观察这五路推理的所对应的容器它们的耗能情况做一个对比这个对比的话可能如果我们进一步在右下角这个Dashboard里面设计了这样一个Dashboard进一步去体现它们的差异我们用了一些数学的方法也就是说我们选取的这个选取的这个观测的这个目标就是说是一个Efficiency它的计算公式实际上是把这个推理所产生的能耗去除以FPS那么除出来的结果它的单位就是能量和美增的关系那么这个单位就是Giorr Frame从这个里面可以看出采用了不同的加速器以后我们的能耗的效率是有很大的变化的很大的差异的跟这个图里面出来的结论类似就是说采用了AMX加速技术之后可以获得更好的能源使用效率所以我们总结一下前面我们提到了很多客户也好很多社区的使用者也好他们提出的一些课就是开普罗到底准确吗在特定的音点平台到底准确吗我们可以得出这样一个结论在节点级别 在工作节点级别开普罗是准确的而在容器级别目前还没有一个非常有效非常有说服力的方法来证明它的有效性但是我们前面基于我们介绍了很多关于方法论和一些工作基地的一些描述大家也可以看到开普罗社区实际上是尝试用一种科学的方法来进行分析尽管这个方法可能目前还不够完美但是我们可以在现在流行的机器学习以及深度学习技术的辅助下不断地去完善这些数据并且不断地去改进这些数据最终使得开普罗能够相对真实的反应工作复杂的耗能情况另外我们通过上面这一页对比我们看到开普罗另外一个比较好的用处在于它可以在同一个时间横向的对比同时运行的不同工作复杂之间的耗能情况在容器级别对比因为是在同一个时间点所以前面说到的一些局限性一些相关的干扰因素对不同的工作复杂容器来说都是公平的那么他们的耗能相对比较值是值得信赖的那么未来的一些工作的话我想我们应该引入更多的工作复杂进行观测当然我光靠我们社区几个小伙伴的力量还是不够的希望更多的小伙伴能够加入到我们的社区能够贡献更多的一些工作复杂不同场景下的工作复杂来观测开普罗的能耗暴露能耗的表现性另外我们也要将平台尽可能地从传统的裸金属平台扩展到基于VM的平台这对于我们那些云服务提供上来是特别有意义因为云服务提供很多是通过虚拟机的方式提供服务给客户的那么在这些虚拟机上的一些能耗的情况会很有价值最后还有一块就是我们现在目前测试的场景更多的还是基于平台的测试某一个平台的准确性和证确性那么将来更多的引入一些继续学习的模型训练以及模型推理之后的话我们可能要进一步把我们测试的视角扩展到模型的验证上就是怎么去评价一个模型的推理结果的有效性和准确性这都是未来的一些工作也是社区的一些工作的方向好 今天分享大概就到这里看看大家有什么问题包括我前面提到的一些包括CAPRO社区的一些基本的一些概念和情况欢迎大家提问 谢谢我想问一下就是说社区说是模型评估就是说以后会可能会训练自己的对于能量测量的一个屏幕的模型是吧然后把它它是一个什么样的方式供给呢这是一个很好的问题我前面有一个跳过的地方实际上现在目前的话就是说社区针对不同的生活场景有不同的解决方案我不刚才也提到特别是针对虚拟机的场景的话我们因为无法准确地获得节点上的一些物理的电表的一些原始数据那么我们实际上采用的是这种机器学习的方式来进行学习那么在CAPRO社区里面是除了CAPRO EXPORT这个项目之外它还提供了CAPRO Model Server这个项目它和CAPRO的关系其实是相互相长的关系我们通过CAPRO暴露原始的数据或者是一些推理的数据给普罗米球司之后这些数据本身可以被CAPRO Model Server抓去那么在这个Model Server上它可以serving不同的Model然后可以进行直接推理也可以进行一些online的训练或者可以一些offline的训练最后将训练结果输入到它的Model DB里面那么这些Model DB里面数据这些Model都可能是针对不同的硬件平台的那么可以分门别类的管理然后我们在同一类型的硬件平台上的这些Model我们可以进行横向的对比来判断这个模型推理的结果的准确性这个推理的依据这个判断的依据主要是我们人工智能从常用到的平均方差片差这样一个指标就是MSC mean squared error以这个指标来评价这个模型的推理结果的表现看哪个模型的推理结果更加有效或者针对这种平台这种场景更加有效所以这里面的这个模型的管理一定是分门别类的可以说是不仅是 platform-specific而且甚至是可能是跟针对场景都是有一些特定的那么对于用户来说他们在Model Server里面查导到相关的模型然后针对这个模型的描述它每一个模型可能有一系列的描述的一些文件来找到它跟针对它的工作场景应用场景所匹配的模型来进行推理来更好地满足它的使用需求那么Model Server本身它也应该提供一套分类机制或者一条benchmark机制这样代替用户去人工做选择它可以在用户的目标机器上目标机群上先进行一些benchmark的采集从而定位和确认这一类用户的应用场景适用于哪一类模型那么它推荐相应的模型给用户使用然后在流水线当中来进行实际的模型推理的运算来判断大概是这样一个逻辑谢谢我有一个问题就是目前机密计算其实挺流行的嘛然后我就想问一下就是开普勒社区对于机密计算的这种能耗的有没有什么方向或者是计划去怎么来去测量在一个机密的环境下它是一个什么样的结果以及它的准确性会是什么样的这也是一个很好的问题就是我回到你这个问题的话就是现在从目前开普勒社区的现状来说它目前机密计算相关在一个可信执行环境下的能耗的采集和测量还是一个规划中的功能这里面难点就在于我们可信执行环境下的原始的数据很难采集可以说甚至在不同的实现第一的实现方案上可能有的实现方案就从原理上就是采集不到原始数据那么怎么把机器学习的方式和机密计算的环境下结合起来这个是现在目前社区正在规划中的一些调研项目社区也成立了一些讨论组在讨论这些问题所以每一个对这方面感兴趣的小伙伴我们都欢迎他加入进来加入我们的讨论加入这个开普勒的这个research项目我们一起共同努力能够找出一些方法论或者一些可信的方法来推进这方面的工作我再补充总结一句吧就是说现在为什么我们这个项目它是怎么应运而升的一个很重要的背景就是我们在目前的这个特别是现在AI和大鱼模型逐渐盛行的这样一个时代我们在这个AI推理和AI训练的过程中会产生大量的耗能这个耗能实际上是对于我们这个节能减排包括我们这个持续发展环境保护这方面是带来的挑战是巨大的因此除了一些传统的硬件方式的这些节能减排的这个solution比如像夜冷等等这些方式之外如果我们能在软件层面特别在圆圆生的这样的应用场景下能够探索出一些软件的检测能耗的这样一个方式并且进一步地用于更上游的一些节能的措施比如说通过调度的方式智能调度的方式比如说通过灵活深缩的方式来进一步最终达到节能的效果那么软件和硬件的这个结合最终我们能够实现一个比较好的愿景这也是开湖的社区的一个很大的愿景所以我们也希望有知识时刻自从大河的小统白和我们一起共同努力把这个工具做得逐渐更加地完善能够满足更多的应用场景能够更好的服务全人类吧好 谢谢大家那下还有什么问题的话也欢迎和我们交流我们给出了这个社区的地址大家可以去访问一下对 包括这次CoopyHunt期间我们社区在信息庭也有展示如果还没有到场的小伙伴的话可以关注一下这里面的微信公众号这个二维码里面有很多关于开普罗社区的一些介绍的情况包括开普罗的一些基本原理等等以及在一些必占上我们录好的一些教学视频也欢迎大家去访问好 谢谢