好 时间差不多了就是首先感谢大家过来今天听我们这边的一个分享我是李鹏 来自阿里云这是我今天的partner 温文哲老师他来自数合科技我们今天给大家带来的分享是数合使用Kynadu加速AI模型服务部署我们会从如下三个方面分别去进行介绍首先由我来介绍Kynadu相关的一些技术第二部分由温文哲老师给大家介绍一下就是数合基于Kynadu的一个最佳实践最后一部分是我们会介绍一下在Kynadu里面部署当前一个比较活热的AI Gears的应用Stable Diffusion首先首先我来介绍一下Kynadu众所周知K8s自从2014年开源以来受到众多云厂商和开发者的一个青睐最后一款开源容器避免系统使用K8s可以降低温文负载 提升温文效率并且提供标准化的API在某种意义上说是避免了云厂商的绑定进而形成了以K8s为核心的一个原生生态根据2021年量CNC-F的调查报告全球有96%的用户再使用或者计划使用K8s而随着原生技术的眼睛按需使用的SolarLight技术逐渐成为主流根据Garden的预测2025年全球将近有50%以上的企业将会部署SolarLight应用我们知道AWI是Lambdaway代表的Fast技术把SolarLight技术带火了用户只要写一段代码就可以跑自己的业务而不需要关注底层的一些技术设施但Fast 使用Fast也会面临一些问题首先是它的开发模式的倾注性比较强另外就是韩硕的运行实际上有些限制此外就是跨平台跨云场上的这种真实而以K8s为代表的容器技术恰好能解决这些问题我们知道SolarLight的核心里面是聚焦业务逻辑而减少对底层技术师的关注那么如何面向开发者提供基于K8s开放标准的SolarLight的容器技术呢答案其实是KineticKinetic是2008年谷歌在Club of Nets大会上开演了一款SolarLight应用编排系统它基于K8s它的目标是制定跨云标准的跨云原生的这种跨平台的SolarLight应用编排标准帮助我们部署和管理现在发展业务工作负载打造企业界的SolarLight平台我们阿里云这边也在比较早的2019年就已经提供了Kinetic的产品化的一个能力随着去年也就是2022年Kinetic正式成为CNCF的伏发项目当前也越来越多的开发者去拥抱它那么Kinetic主要包括哪些功能呢主要两个毛块一是用于部署工作负载的serving另外就是事业驱动放假移民厅Kinetic上面提供了比较简洁高效的一个服务部署能力通过基于请求的一个重弹性我们可以按需使用资源不用的时候它可以自动送容到零另外它也提供了一个继续流量的汇动发布能力而Eventing它基于标准的Cloud的Uno协议可以接受不同的设计员而事件之间的流转可以通过broke和trigger这种事件的流转机制非常方便地去处理是一种事件的流转那么我们说一下它的应用模型也就是connected to service其实主要包括两部分一是用于部署工作负载的configuration另外一部分是用于设置路由策略的router也就是说我们工作发展如果变更音的倾向或者环境辨量我们可以修改configuration的一些配置每一次修改就会产生一个新的版本那么我们可以基于不同版址之间如果做挥度发布的话我们可以很方便调整它的一个流量比例例如我新创建一个新的版本22然后将30%的流的量打到这个新的版本上然后原来的是70%正常流量就会按照7比3的比例分别转发到一个新就版本上去而这个时候如果发现新的版本有异常我们可以随时调整它的流量比例做一些回滚存在天代动物里面还提供了一个对每个版本我们可以试一个tag这个可以怎么理解的我们可以理解的它是一个精确验证的一个能力我们对某个版本上做一个tag我们就可以对这个版本单独地进行验证而不需要现身的流量去直接打上去其实这就是一个就比较简单的一个精确验证的一个能力接下来我们说一下就是Connected with它一个比较有特点的一个弹性能力也是它主打的叫做基于请求的自动弹性KPA我们知道KPA-S里面提供了原生的就是HPA它是基于CPU memory去做自动弹性的但是基于这种基于CPU memory有时候闭门直接反映它的一个优务负载情况而基于请求硕或者并发射这样的更能发现它的真实的一个业务负载那么KNAV就提供了基于请求的一个自动弹性能力那它们怎么来做的呢我们可以看一下这个官方的这张图首先其实我们需要观众一点一是指标怎么踩它是怎么踩的KNAV里面通过一个对每个业务上做一个这种塞德卡叫做Queo Proposy这样的容器去采集它的一个数据它的一个指标以并发射为例它可以拿到这个当前的这个转发过来的并发朔然后Autroscelia组建拿到这个并发朔之后会计算出我当前的所需要的POD朔那么计算方式是什么呢我这边也列出来了它是我们可以看看它可以基于当前总的并发朔然后处于它的一个每个POD所能承载的一个最大并发朔然后再呈一个目标使用率就可以计算到它的POD朔那这个目标使用率什么概念呢我稍后会在重点介绍一下这个点这就是它是基于请求一个自动彩星能力从来Kenneth都有提另外一个特点的一个功能是速容到零其实相当于我们是平时使用资源的时候如果没有齐群的话我们希望它能够速容到零而Kenneth都提供这种能力它是怎么来做到呢其实就提供过两种模式的一个切换一个是Proposy模式另外就是色耳模式Proposy模式只是顾名思念就是个代理也就是当当请求然后过来的时候这时候如果是没有没有POD朔它会先转到一个IGTV的上去IGTV的收集到这个指标之后它会做两个事情第一个把当前的请求给缓存起来放到一个请求队列另外就是它会发送一个指标给Auto SurglareAuto Surglare收集到这个指标之后会计算到POD它知道我十多信号有新的请求过来了我要去谈那么就会谈出新的POD一旦这个新的PODReady达到Ready的状态那么IGTV的会将队列中的这些请求转发到这个POD上去这就是0到1的一个流程而一旦这个流量没有我们不知道也没有请求没有反复不反问了这时候Auto Surglare也会从QoProsy拿到这些指标说哎 我们没有请求了那这时候怎么呢它会它会做一个调整去调整它的模式切换我切换到Auto Surglare的模式这时候它就会自动搜索到0了我们知道实际我们实际我们生产中就是请求或者业务流量它是个不确定性的但是真的这不确定往往遇到会有一些突发的流量对于这突发流量Connect5其实也提供了一些方式去做举而言两个一是遇到有突发流量进来了我首先就要快速谈自愿出来另外就是对于这些突发的流量我如何避免当前的这些正在提供服务的正常步骤被流量打爆如何是快速谈呢它其实也是通过两种模式进行处理一是稳定模式另外就是恐慌模式稳定模式是怎么这里面我稍微说一下稳定模式是基于稳定窗口模式是60秒也就是它会计算60秒内的我收到一个以并发售为厉害它会计算60秒内的一个并发售的一个基于60秒内的并发售计算当前的一个破的请求数破的谈出的自愿数另外就是恐慌模式恐慌模式它有一个恐慌窗口机这个恐慌窗口机是通过就是稳定窗口机乘以它的一个参数叫pandicwindow%这样的参数默认是参数0.1它可以计算中默认情况的一个恐慌窗口机就是60秒也就是它可以计算恐慌窗口机也就是60秒也会拿到60秒的一个时间我计算在60秒内的一个应该谈入多少破的数那么最终是应该是使用哪一个模式下计算的破的声向呢它会这里面会有一个恐慌预值的概念恐慌预值也就是说当它模式是2也就是说如果是恐慌模式下计算的破的数大于当前我正在reddit的运行中的破的数乘以我的恐慌预值也就是大于它的两倍我发现它已经这个是个突发的流量那我赶紧用恐慌模式这时候就用恐慌模式下计算的破的数进行生效另外一个就是如何避免被破的打爆呢它提供了一个就是突发流量突发请求容量的一个概念也就是说刚正常请求的时候我通过Gateway直接打到破的上然后如果是遇到突发流量它超过了我设置的突发流量的那个请求的容量预值那么它会做个切换它会切换到一个也就是Gateway的组件上去Gateway的这时候就会把那些突发的流量做一个缓冲缓损起来然后等破得真正需要的破的创建reddit之后然后我再去转发上去这个过程中其实我间接地可以避免了破的被突发过来的流量打爆另外其实能启动这个我们也知道其实对于正常的破得启动过程中它涉及到拉近一下然后容积启动业务容积启动这些过程是存在一些弹性之后能启动的一个问题connector里面也提供了一些减少能启动的一些技巧第一个就是延迟缩容它提供就是首先对于那些破的平凡扩缩容或者是破的启动车门比较大的这些场景我可以通过延迟让它缩下去然后避免它平凡地去扩缩你就可以做到一个相当于间接做到一个减少能启动的效果另外我刚才也上面也提到过就是目标使用率目标使用率是在我们计算需要谈多少破的的时候计算得出来的也就是说我们可以调低目标使用率实验资源预热假如我现在设置的并发售最大单个破的并发最大并发售是10我设置的它的目标使用率是0.7也就是达到70%的时候它就会去扩容这种间接的形式实现了一个资源的预热接下来我说一下肯尼德有一个弹性策略的配置它那个比较多这些配置参数也确实比较多也间接地说明了它提供的弹性能力是非常丰富的我就简单说一下就是破的Out of Slayer Class这个就是弹性插接类型这个我们可以通过如果我们有自己自然的弹性能力例如我们阿里云这边自然的要HPA MPA就是弹晕色这个像MPA是进入的弹性这个都是扩展了弹性能力然后这时候我可以通过设置它这个破的Out of Slayer Class指定不同的弹性插接类型我们知道看源的看源的这项目我们不能直接拿来用肯南的我也是社区的原生的也存在一些问题首先就是它的组件比较多运维比较复杂另外就是网关能力我们希望提供真正生产可用的就是云产品网维能力的支撑此外就是它虽然做了一些减少冷气中的一些一些Scape吧但是我们还是它不能没有去完全解冷气中这个问题那么针对这些问题我们阿里云中区服务肯南的我在完全建筑市区肯南都市市上做了一些功能上的一些增强例如我们支持就是AITL的框架K425在弹性方面可以提供保留自愿池和精准弹性然后也支持弹性预测的一个能力在网关增强上我们支持了云云产品的网关像MSIeARB然后像ASM就是服务网格能力世界驱动上我们也做了一个升级与阿里云自身的世界驱动产品银云的BREER做了一个深度的继承之外我们还支持阿里云生态其他产品做了一些融合接下来我说一下就是保留自愿池这个保留自愿池什么场景来用呢一般是两个场景一是ECS和ECI混用的ECI是弹性容器实力也就是说在常态流略上下就是我们可以备用一个池子就是正常的如果有常态的业水位我们备用一些ECI S的资源或者是包年包园的因为成本更低一些这样的我们面对突发流量又希望它快速弹起来我们可以用ECI S的资源那么这种情况下我如何去实现这种突发流量去用ECI呢我们可以通过肯南头里面保留自愿池去配置另外就是自愿与热这个我们也可以再通过保留自愿池来做到也就是说当它没有流量的时候我们会将它缩容到一个低规格的实力上去低规格的一个实力上去然后一旦有请求进来之后我们首先用低规的实力给它返回当前的一个请求同时我们会扩容正常实力出来一旦正常实力出来之后我们会把低规的实力缩容下去对于0到1的这种情况我们其实做到了避免冷气洞接下来说一下就是肯南头另外一个特性就是我们做了一个扩展就是精准弹性为什么要做这个事情呢因为POD本身它其实有些场景下一个POD的处理请求的并发出有限的但是我们又要精准地控制这一个POD只能处理多少也就是有的甚至一个POD我只处理一个请求或者只处理两个请求这就要求我对这个请求做精准的一个转发精准的一个弹性处理这是我们和我们的云产品就是MSE原生网关做了一个结合提供了就是一个弹性能力的扩展就做MPA接下来就是说一下弹晕色弹晕色这一块其实是我们本身就是我们阿里云也有一款这样的一个产品能力叫做AHPAAHPA然后它是可以继续历史的一个历史的一个指标比如CPMEME或者是QPS并发出也支持SDN的指标基于这些历史的指标它通过机器学习的一些算法去分析然后识别它的周期然后提前预测下一个周期我们会提我们也可以做到就是提前未来24小时每一分钟的POD都可以做一个分析出来然后做个预测通过那种方式我们相当于可以提前准不自愿像这边像传统的AHPA它是等请求来了之后我在谈但是AHPA我们可以做到就是在它请求来之前我预测它要来请求了那我就提前去谈可以做到一个避免冷启动可待的我有一句这个AHPA做了一个深度的结合让它支持谈预测能力这个就是KPA上面是一个谈预就是谈预测的效果上面是KPA就是原生的那种方式我们等了请求它是等请求来了之后我再去扩容那对于其实有些场景它是经向比较大其实尤其对于现在的这种AI的应用来说它的模型加载或者是拉镜像这块是非常耗时的会存在一些谈应之后而通过我们HPX就可以等到它来之前这下面的是它的请求来之前我就给它扩出来提前准备资源避免它的冷启动另外就是我说一下就是世界驱动这一块就是Kenneth里面其实它本身也提供了就是Kenneth上面的原生的能力Kenneth有问题但是这种原生的能力我们直接来用的话也面临问题就是世界源比较多我们要接受不同的世界源我们要自己写世界源的实现配置这是比较繁琐的另外就是我们如何保证它世界流转中不丢我们其实是结合云产品的能力也就是提供了直接面向Kenneth的设定去操作一个世界驱动能力而它真正去承载的是Union的Bridge通过这种方式我们就可以完全地实现了云产品就生产级别的一个世界驱动能力我们知道就是Kenneth我可能是在实际业务结合过程中会如何来Kenneth我们有我们的实际业务相继合应该怎么来做然后通过Kenneth我能给企业带来哪些收益呢接下来就是有请汪文哲老师跟我们分享数合级于Kenneth的对家事件感谢李鹏老师的分享大家好我是来自数合科技的技术家库团队的卫文哲下面我来给大家介绍一下数合是怎样基于Kenneth5的一个模型部署的一个最佳实践首先介绍一下我们的数合科技数合科技成立于2015年8月数合科技是一家以大数据和技术为驱动的为金融机构提供高效解决方案的一家技术公司我们的业务涵盖消费信贷小微企业贷款场景分期等多个领域并且提供营销货客风险防控运营管理等服务数合科技旗下的环卑APP是一款为个人提供消费信贷服务并且为小微企业提供资金贷款支持的一款APP目前有1.31的一个注册用户并且为1700万用户提供了一个消费信贷服务下面简单介绍一下我们的BatterCDS平台BatterCDS是数合的一战士Dial Ops平台我们的Kinity5模型也是基于BatterCDS打造的可以看到我们BatterCDS有很多模块下面简单介绍一下虚线框中的这些是我们的一个模型持续交付的一些相关的一些模块首先是我们的流水线我们流水线的主要功能就是编排我们的一些自动化的流程同时我们也支持了应用模板的一个能力支持了多种的应用类型其中Kinity5模型就是我们其中的一个应用类型我们流水线中包括了一些步骤比如说经向构建经向扫描经向部署还有我们的自动化测试那么中间的这个是我们的一个置品仓库的一个模块那么我们的置品仓库主要就是管理我们的交付物然后同时我们的置品其实是一个抽象的一个感念我们可以包括我们的炸包袜包还有我们的模型文件经向文件等等通过我们的置品也可以关联到这个一个经向的安全报告质量报告等等那么我们Kinity5模型也是基于跟我们的置品进行关联来管理我们的模型的一个版本然后通过置品去发布我们的模型版本那么右边的这个就是我们的发布管理的一个模块那么发布管理的话就是我们的发布平台管理我们的发布计划还有我们的发布的策略还有我们的挥度的策略等等那么我们的模型的持续交付就是基于以上几个模块来共同完成的那么在我们过去的模型发布也存在了一些问题和痛点那么首先就是我们那个模型的一个版本的生命周期不是只不于上线完成还包括它的资源的回收和模型版本的下线那么在模型上线的阶段首先我们要去申请资源那么申请资源的话我们通常因为我们在业务出击很难去预估一个模型的一个真正的资源使用量我们往往都会去预留8份那么预留8份呢可能作为资源使用方为了保证这个资源的一个服务的稳定性那么我们都会超过我们实际使用的规格去申请比如说我们通常如果使用两盒那可能就申请四盒申请八盒甚至这样子那么这样就会那么即使我们申请了这部分资源可能也不是全时段用满比如说我们经常会看到线上的一些应用尤其是一些离线照布类的一些应用它的整体的资源使用率在大部分情况下都是很低的那只有在某些时光才会涨上去有比较明显的一个周期性那么这个就是因为我们一个资源使用缺乏弹性导致我们的一个资源浪费比较多那么第二点就是一个资源难回收的问题就是我们线上目前一个模型的版本可能一个模型有多个版本那么我们通过不同的版本去观察模型的一个实际的使用效果如果某个版本评估的效果不佳那么我们会在决策流程中将这个版本下线掉那么下线以后它就不再提供服务了如果这个时候我们不能够将资源及时回收那么就会造成一个资源的浪费那么最后一点就是我们的人工操作比较多可以看到我们在模型的上线和下线的过程中有比较多的人工介入尤其是在模型下线的阶段因为下线资源大家都比较谨慎可能要再三确认所以这个会导致我们的一个和发布效率的一个降低那么下面介绍一下我们的一个BetaCDS模型持续交付的一个技术架构可以看到最上面是我们的模型平台那么我们的模型就是在我们的集群的云庄面中进行训练和开发的那么在这里会产生我们的模型文件以及模型的一些中间的训练数据那么我们通过将模型文件登记到BetaCDS然后会产生一个与模型文件对应的一个支品那么这时候可以看一下我们的一个Konitivo的配置模块那么我们通过Konitivo配置模块可以配置我们的Konitivo的一个全局的弹簧配置和一个版本的弹簧配置那么中间的这个部分是我们的一个CI的流水线那么CI的流水线主要功能就是构建出通过我们Docalfile然后拉取模型文件构建出我们的一个模型镜像镜像构建完成之后就进入到一个部属的流程部属就是通过我们的部属流水线来完成的那么可以看到我们部属就是通过更新Konitivo Service然后设置我们的镜像版本和一个我们弹簧配置然后这时候就产生了一个对应的Revision版本那么下面是我们的一个然后下面是我们的这个Konitivo集群我们流水线更新Konitivo Service之后会产生一个对应版本的Revision这个Revision会包含我们的一个Deployment对象然后Deployment对象产生了Republic Set和POD那么流水线就去Watch这个Deployment那么当所有POD都Ready的时候我们就认为这个版本是部属成功的那么最后我们流水线会为这个Revision版本打上一个Tag创建一个版本的路由下面介绍一下我们一个多版本发布的能力可以看到上面这个是我们的一个Beta CDS的制品这个制品是有多个版本的那么右边的这个是我们的一个RevisionKonitivo的Revision版本这个Revision版本跟我们的制品版本就是一一对应的那么我们制品实际上就是包含我们的模型镜像然后我们去设置更新我们Konitivo Service就产生了对应的Revision版本那么第二点就是我们线上模型的一个多版本共存的能力可以看到我们这个为每一个Revision都创建了一个版本路由那么我们这样就可以在我们的决策的流程中模型的这个业务决策流程中通过不同的版本路由去调用不同的模型服务版本来观察这个模型的一个实际效果那么因为我们支持了多版本路由这样的话我们也可以实现一个灵活的一个流量的策略那么最后就是我们支持也支持了一个Latest的版本那么Latest的版本是实际上可以指向任何一个Revision版本那么这样我们就可以做到在不改变我们业务决策流程的情况下将Latest的版本迁换到任何一个任意一个Revision版本这样就完成了一个线上流量的无缝迁换那么下面介绍一下我们一个基于请求的谈过能力那么这个图是我们的一个Revision版本的流量从百分之百到零的一个工作过程那么可以看到先简单介绍一下为什么我们会使用一个基于流量的弹扩策略因为我们大部分模型都属于一个计算密集性的一个服务那么也就意味着我们的模型服务的CPU使用率给我们的请求数是正相关的而且说当请求数越高的时候我们CPU使用率就会越高那么如果遇到一些突发流量的场景那么很容易就将我们的模型服务打爆导致一个服务不可用最终导致一个系统的血泵那么这时候我们就希望基于请求的流量进行弹扩那么其实类似的还有我们的比如说HPE的指标弹扩那么我们指标弹扩也存在几点问题比如说第一点就是我们指标弹扩的HPE弹扩整体的链路比较长首先HPE首先要服务去暴露指标然后普罗米修斯按周期去抓取一个指标然后HPE在根据普罗米修斯的指标去控制我们Diplomint去弹扩我们可以看到整体的链路是比较长的那么第二点的就是我们的一个HPE弹扩这个指标本身可能不准确不能够真实地反映服务的一个状态比如说有一些我们扎外应用可能会存在GC的这种情况会导致我们指标的一个周期性的变化那么第三点就是指标我们HPE弹扩存在一定的延后性也就是说当指标上升的时候这个服务响应的延迟就已经很高了那这时候如果再等到我们HPE去启动弹扩过程然后等到Paul Ready to这整个过程都是延后的所以我们需要将弹扩时间提前采用一个急于请求数的一个弹扩策略那么最后就是我们的一个Paul就是针对之前我们模型下线的一个痛点我们可以将某个Revision版本的最小Paul的数缩到调整为0那么这样的话在没有请求的情况下这个RevisionPaul就会自动被回收那么也就不再占用资源了这时候如果再结合我们的ECI的弹性节点那么就可以实现我们模型的一个真正的Serverless能力下面介绍一下我们发布流水线和一个模型弹扩配置左边这是我们的发布流水线的一个界面我们可以看到这个首先就是出发一个Connective Service的部署然后部署完成之后新增一个版本路由然后更新Latest的版本是作为一个流水线参数来决定是否要在部署成功的时候去更新我们Latest的路由将它切换成最新版本那么最后一个步骤就是向系统同步部署的结果那么右边的是我们的模型弹扩的配置那么最上面的是我们的一个模型全局的一个弹扩配置它会作为一个版本的一个默认配置那么中间的是一个版本的自定义的一个弹扩配置可以自定义某个版本的一个弹扩配置那么下面这个下面部分最下面这部分是我们的一个弹扩的事件在这里可以看到我们的一些Cabinitis的一些炮的伸缩事件那么下面看一下我们集群的一个伸缩弹扩的一个架构我们可以看到我们的容器应用是运行在我们的ACK和我们的许你节点上来的那么ACK的话维护着我们固定节点的那个资源池那么固定节点是根据我们的一个集群的一个长柱的炮的数和一个常规的业务用量来进行规划的然后这样的话就是包年包月的节点然后成本更低然后右边的是我们的虚拟节点那么虚拟节点的话上面就是运行着我们的ECI的势力我们类比应用如果它无需关心我们的炮的话我们就要成为serverless那么如果我们的炮无需关心我们的节点的话那么就成为notelace那么notelace节点的话提供我们一个弹性的能力能够轻松地运动对一些突发流量和一些周期性的任务那么虚拟节点的还有第二个优势就是我们成本更低就是一些比如说线上的一些实施性要求不高的一些任务或者是一些离线照博这些任务它有明显的周期性所以它不会一直占用资源那么使用虚拟节点就是我们按量付费的虚拟节点可以节省我们的成本那么第三点虚拟节点的一个免运为的优势就是因为无需关心节点可以节省我们的运为成本那么通过虚拟节点也满足了我们弹性的一个需求同时也会也能够降低我们使用的成本那么通过ACK与虚拟节点的混合应用兼顾我们资源的成本和弹过的需求提高我们资源的一个使用率实现我们一个低成本的高弹性那么下面介绍一下我们的一个请求与集群节点的一个示意图那么在我们金融封控的一些业务场景下面存在一些跟决策相关的一些批量调用还有一些营销活动都会使我们的模型服务面临一些流量激增的一些情况因为我们采用的是一个基于请求的一个弹阔策略所以当流量激增的时候我们能够快速地弹起我们的泡的来响应请求同时我们也加入了这个按量付费的弹性节点那么当请求数过大的时候我们会弹起这个弹性节点那么因为是弹性节点能够保证我们一个足够大的一个资源使用量那么当请求减小的时候我们这个节点就会被回收那么降低我们的使用成本那么下面这个就是我们一个资源使用的一个和我们集群节点的一个曲线我们看到我们的ECS常铸节点是保证我们一个常规的业务一个资源使用那么ECI的弹性节点来应对我们突发流量和一些照顾的场景那么通过ECS和ECI的混合使用能够最大化地提升我们资源的使用业那么下面这个是我们一个上线的一个实际效果可以看到这里这张图里面有两条线下面这个黄色的这个曲线是我们一个集群的请求流量的一个曲线可以看到我们集群的请求流量这个波动范围是比较大的有波峰有波谷有很明显的一个周期性那么上面的这个绿色的这个线是我们集群的一个炮的树那么集群炮的树可以看到它是整体是非常贴合我们这个请求的这个曲线的当请求流量上升的时候我们炮的树也是上升的请求流量下降的时候我们炮的树也会回收然后炮的树也是下降的那么这个这条线是我们的一个峰值炮的树可以看到我们的峰值炮接近是2000个那么如果按照这个这个使用规格去预留资源的话这个会造成一个资源的一个很大的浪费我们整体这个资源的使用率还是比较可观的那么下面这个是我们的一个成本的收益那么我们的成本比例呢在使用Konitiv模型之后呢大约结成了60%那么右边是我们的一个部署效率的提升那么结合Konitiv的这个多版本部署的一个能力我们的这个部署的效率从小时期降低为分钟几那么整体的部署效率提升了80%那么最后我们这个Konitiv模型的实践也获得了这个权威的认证那么树合的Konitiv AR模型获得了新通院云原生产业联盟的一个云原生优秀案例的一个权威认证那么以上就是我们国关于树合的Konitiv模型实践的一些分享那么下面接着有李鹏老师我们介绍下一部分的内容我就看说说一下就是我们最后这一部分其实是基于Konitiv不属于一个就是Stiffle Diffusion当前比较火的这种AIGC的这样一个应用为什么要坐在Konitiv里面去部署呢就是实际在K8S里面如果直接使用Stiffle Diffusion这样直接部署的话其实还面临一些问题就是它请求的时候我们这个所创新的Port de Rive它需要精准地去处理这些请求数如果超过这些请求的话然后这些超过这些它的最大处理请求数它这个请求会挂掉也就服务不可用生成不了图片也就是另外就是我们知道GPU这些资源非常珍贵我们希望就是用用的时候就谈出来不用那么去说希望基于请求来自动化的一些扩缩我们就是在提供了Konitiv部署这种Stiffle Diffusion这种方式我们可以做到就是按需使用另外就一对一的请求转发没有请求的时候就让它送到零我可以衍伸一下它有一个有一个效果简单看一下这是我们部署的一个服务然后我是每一个Port de Rive这个好像没拖出来对吧这个怎么拖出来拖不出来好像是吧轻换了屏幕拖转一下这个是我们的视力就是这个视力的话这里并发出的是5然后每个Port的可以处理一个请求然后其实它可以像那个创建会创建5个Port的每去处理这当前的生成图片的一个任务然后我们发送20个然后我现在点一下然后开始压这个可能你看可以看到之前它是没有Port的这个就是Port的硕之前是没有的没有请求流量的现在它收到了这个请求然后就会创建5个Port去做的IGC做绘图一会儿就会出来因为它这个加速的模型时间比较耗时所以我可以给大家直接看效果我们可以看到稍后会出现一个这样的效果此外就是我们也提供肯带6个整体的可观测量大盘能力包括上面的那个它的一个请求就是吞吐量然后成功率成功率处理成功率然后它的Port扩散容趋势下面的一些RT响员迟可以非常方便通过这种大盘的形式直观地看它那个服务质量的一个情况这就是我们今天的一个分享感谢大家下面这个是我们阿里云肯带6的建立这个叮叮交流圈就是大家有兴趣的可以加一下或许我们有什么问题就是不管是不是社区的肯带都或者是我们都可以在里面去交流大家有什么问题吗有那个话筒对非常感谢李老师的分享关于将在Knetwork里面去部署模型服务作为reversion就是我有个问题就是如果说在你刚刚的视力里面就是您强调了并发数是1它作为硬线字去作为比如说concurrency的参数去进行产业扩散容那实际上在我们用模型服务去做预测的时候就我们会发现其实它除了concurrency之外我们可能还会需要比如说继续显存的扩散容那其实我们就是有这种KPA跟HPA相结合的这种场景我想知道我想知道阿里云有没有这方面的实践我们是有一个这样的就是其实像你提到的是多指标嘛对多指标这种情况下我们就是站在咱们的英雄的角度是希望它哪一个负载上来了我就以哪个为主那生小对吗对的对所以我们其实这边提供的就是刚才我提到一个AHPA我们可以支持多指标预测并且其实它预测是其中一个就是它的一个特性能力它里面支持和就是我除了这种预测我最近对那些正常的扩散容我也可以多指标的一些一个配置配置完之后然后与connected within结合之后我就可以针对不同的指标GPU的我们也支持并发售CPU memory多种指标组合是这样的我们是提供这么的能力的OK我想问一下这个这个AHPA您刚刚提到的是有开源的产品吗开源的目前没有开源的目前没有是我们因为这个是我们和打磨院那边合作的可能目前还没有开源OK好的谢谢老师可能这边时间到了我们会一下交流一下吧好吧就是确实刚才有点时间上延迟不好意思大家