我今天要开始了开始了可以那我先开始吧好吧刚才大家听了那个调度也很多下面给大家换个口语专Fly给大家做一个专Fly的介绍以及专Fly的一些最新的一些大版本的一些更新还有呢跟快手公司的刘泽棍同学一起讲一下专Fly在快手对吧AI模型分发这一部分是如何做的一个落地级违法案嘛我这边先自我介绍一下我叫齐文博来自蚂蚁集团同时也是专Fly的Mantainer后面呢是刘泽棍来自快手公司首先给大家介绍一下专Fly是什么专Fly是一个基于P2P的镜像加速以及文件分发系统首先呢在2017年的时候呢专Fly正式开源当时其实已经被很多的大型的互联公司所使用在2018年的时候呢专Fly由阿里巴巴捐赠给了Sensef作为一个Sandbox项目在2020年的时候呢专Fly呢成为了Sensef的一个Incubation项目在2023年的时候也就是上个月我们也提了一个Graduation的一个Proposal大家可以关注的可以关注一下PR在Sensef的当然呢大家可以看到在Sensef的Landscape里面主要有两个项目一个是Graduation的一个是Incubation的Graduation是Hobbo就是说做一个镜像存储的一个降仓库的一个解决方案当然现在呢它更多是做一个质品的一个存储第二部分呢就是专Fly当然呢专Fly之前是局限于镜像加速其实现在呢更多是也是会做一些文件分发以及AI场景下的一些数据分发的工作当然呢我们也得到一些公勇云的知识这些公勇云的公司呢也会把专Fly作为他们公勇云的产品的一部分去做一个使用第二部分呢给大家介绍一下专Fly的一个子项目叫NedusNedus这个项目呢主要做一个镜像的驱虫压缩并且呢在镜像启动工人当中呢运行工人当中呢去做一个安需夹载当然呢Nedus它可以把端到端的一个启动时间呢从分钟级别降低到秒级同时呢Nedus也是由阿里云蚂蚁以及字节跳动三家公司共同去研发的一款专Fly的可能P2P的一个补充方案吧讲了这么多专Fly也介绍Nedus也介绍大家可能还不知道专Fly跟Nedus到底解决了什么样的一个问题给大家讲一下专Fly跟Nedus到底解决一个什么样的问题就说其实最简单的理解就是说专Fly跟Nedus它解决的就是你原站的一个带宽平静的问题假设你在一个1000个节点或者一个万1万个节点的一个K8S集群当中你每个节点都需要去加载一个镜像或者说下载一个文件或者说你下载一个AI的模型对吧这时候你就需要有1000次的并发下载文件或者说1万次的这时候不论怎样你的原站的存储其实它都很容易达到一个带宽的上限导致你整个下载流程了一个变慢或者说你容器启动时间变慢这种情况其实有三种解决方案第一种就是说我们把原站的带宽限制提高当然这种解决方案其实不论在成本还是硬件上面其实它都有限度的它都有平静的这种情况其实在之前很多年都已经印证过了对吧就是说你一个中心化的存储方案它是解决不了这种大规模的场景的第二种解决方案就是说我们用P2P的方式我们用节点的一个限制带宽从而去缓解你原站的一个带宽平静当然这有John Fly所做的事情可能社区当中有一些同学会本地起这么一个节点两个节点用John Fly去做个P2P可能它的效果还没有你直接回源快这是为什么就是说你的原站带宽远远没有打满的情况下其实P2P它并没有一个加速的效果当你的规模够大情况下才是一个很好的解决方案第三种方式就是说我们尽量少的加载字眼就是说我们在构建镜像或者说构建文件的时候构建模型的时候我们把镜像或文件去做一个去重去做一个压缩并且在加载的过程当中我们去做一个安区加载我们尽量加载它只需要使用的部分就可以了这样就可以达到一个尽量少的加载文件的场景这样其实就是Nedas所做的一件事情比如说ZhuanFly加Nedas其实用了第二种加第三种解决方案去解决一个你的原站带宽平静的一个问题下面给大家讲一下ZhuanFly最近的一些大版本的一些更新首先第一点就是说我们最近半年做的就是说我们把整个控制台就是说一些可实化控制台做了一个大版本的一个更新重写了其中我们把整个P2P集群的部署操作还有说一些多集群的方案定义的更加清晰让用户的体验更好一些在做部署过程当中第二部分就是说我们基于一个智能化的一个调度方案智能化调度方案我们主要基于两个数据第一个数据就是节点之间去做一个探测构建一个虚拟的网络拓布节奏第二部分数据就是说我们基于一些节点之间的一些历史加载数据通过GN和MLP算法去构建一个构建两个模型去做一个Predict去相对来讲去选择它最优的一组复节点进行一个调度当然这是我们整个的一个架构就是说我们会把数据收集在Scattered内然后呢会在用Redis去同步一些状态同时呢我们新增了一个服务Trainer去做模型的一个训练同时呢我们推理也使用了Triton Server去做一个推理这部分呢就是说其实我们这次分享其实最重要的一点就是说在AI场景下我们是如何去做一个数据加速的我们把AI场景的数据分为四类第一类呢就是数据级第二类呢就是模型比如说你们推理功能当中所需要的模型第三类呢就是框架比如说你的Titan Flow你的PetTouch你的Triton Server你的Touch Server你的Titan Flow Serving比如说Triton Server你可能你在解压情况下可能它的镜像能有10个级怎么的这也是需要加速的最后一部分呢就是外围数据可能我们做推理和训练功能当中所需要依赖的一些外围的一些周边数据这四份数据呢我们主要提供几种方案去做一个加速第一个呢就是在训练阶段在训练阶段呢我们主要提供的方案是佛罗伊德再加Juice FS再加Juan Fly的一个整体方案佛罗伊德呢大家也知道之前今天可能也有很多分享关于佛罗伊德的就是说他会做一个数据点牌同时呢他的RanTime是基于一个分布式文件系统有Juice FS大家可能对Juice比较了解的同学呢可能知道Juice他真正在对方存储所夹仔的是每一个创可当然呢Juice这种情况呢其实小规模是可以的当你大规模的情况下他就会相对来讲把你的存储很容易就会打满而且你的QPS会很高因为他会分为一个个小的创可这部分呢我们会跟Juice社区做一个集成比如说把Juan Fly放到Juice当中让Juice的创可的一个流量走一个P2P的分阀这样呢就会有效的缓解你的原站的一个贷款好吧就是我们一个训练的工人当中的一个数据加速的一个解决方案这部分在社区当中后面我们也会提供一些文档第二部分就是腿里是我认为Juan Fly就是在AI场景下用处最大的一个场景可能大家在对于AI推理或者说训练工人当中听到了很多方案分布是文件系统方案又是有其他一些方案但是我认为在AI推理工人当中P2P是最好的一个解决方案为什么呢首先AI有两个前提第一个前提呢就是AI推理工人当中就有并发行的就我不需要只起一个推理服务我可以起一钱我必须要起一千个或者两千个我去做一个线上的serving第二部分呢就是说我AI的模型足够大AI的模型可能从几百兆到几个G再到几百个G都有可能对吧这种情况呢其实用P2P的方案是最好的方案比如说我可以因为你同时一千个推理节点同时去加载大文件情况下你的原站的带宽不管怎样都是要被打满的这种情况你自然而然你下载时间会很长的我们内部比如说一些大模型场景对吧一开始在没有P2P的方案的时候他们可能加载整体启动一千个服务的时候他可能需要两个小时三个小时对吧他用P2P之后可能十分钟就可以所有的容器都启动起来为什么呢因为ZoneFlight能做到最好的情况我让整个机群当中只有一个节点进行回源这样我就会让原站加载回源加载尽量快这时候它加载功用当中它的piece也可以在整个P2P机群当中进行内网的一个夹载这时候就会大大提高它的整体启动速度当然这是AI推理阶段我们推荐的第一个方案就是说直接用P2P的方式而且ZoneFlight跟社区的推理服务框架也有很好的集成方式并且是一些无清无清的集成所以说可以直接去用ZoneFlight去做一个P2P的一个模型分发第二种方案就是我们提供的一个文件系统的一个方案模型文件系统方案也就是说用Nedus去把你的模型文件构建成Nedus的一个RAFS格式的一个文件系统这个过程当中就去除跟压缩的能力同时在夹载的过程当中我们会安须的去夹载对应Nedus的一个创可这时候会经过ZoneFlight去做一个分发一个P2P分发当然这种方案它的缺点就在于说它可能相量集成比较麻烦一些第三种方案就是模型镜像的一个方案也是后面快手公司落地的一个方案这种方案其实跟模型文件系统方案其实是一样的也有说用Nedus去转换成Nedus一个格式的镜像只不过它的载体是OCIV1格式的一个镜像格式我们主要是把模型跟推理服务框架打在同一个镜像当中转换成Nedus一个格式的镜像在夹载工作当中通过Nedus去分创可做一个安须夹载这种情况其实在我们内部使用其实也很多大部分其实都是用作就是说部门之间交接比较简单一些因为大家知道训练的部门可能跟推理的部门是两个部门完全两个部门对吧这时候我用一个镜像版本的方式进行一个交付的话其实是做到沟通成本是最低的嘛对吧所以说我们内部也有一部分是通过模型镜像的方案当然的DrawFlight跟Nedus本身就是SenseApp的一个incubating项目也是开源项目我们最重要的是跟AI的推理社区去做一个结合比如说线阶段推理服务框架用了最多的第一个Tyson Flow Serving第二个Trend Server第三个Touch Server当然还有现在比如说大家可能知道比较多Hugging Face Hub它可能它也有SDK去Hugging Face去做一个夹载我们认为Hugging Face Hub就是未来的容器镜像的一个Dock Hub比如说我们把Hugging Face Hub的SDK做一个集成之后其实未来DrawFlight在AI推理工程当中其实就有它自己的一个位置了当然三个推理服务框架其实DrawFlight都做了一种集成我拿Touch Server做举一个例子我们在DrawFlight OS在Google里面会开源一个项目是DrawFlight and Point这个就是Touch Server的一个Plug In它提供一个Plug In它会把所有的模型夹载的流量转发到DrawFlight的一个P2P网络当中去做一个加速这就是我们的一个Touch Server的一个方案吧最后一部分就是框架以及外围数据这两部分其实就是可以用标准的一个DrawFlight加Nedus的一个进向加速的一个解决方案因为它都打在进向内的就可以了我这边基本上分享结束后面有刘泽坤同学讲一下DrawFlight具体在快手公司是如何进行一个落地的在模型分发这里谢谢好的 大家好我是来自快手容器云的刘泽坤刚刚清文博和大家介绍了一下DrawFlight相关的项目以及DrawFlight在AI文件分发的一个一些新的特性接下来由我和大家分享一下DrawFlight在快手的一个落地特别是在AI模型分发上的一个时间的分享首先我和大家简要地介绍一下快手AI平台快手的AI平台作为公司内部一个统一的一个机器学习的平台它的底座是以K8S为底座会支撑公司多种AI业务类型的一些场景包括模型的一些训练 模型的上线模型市场 以及在一些推理等方面的一些工作整个平台的系统的职责的话向上它会接受各个业务场景下的一些AI训练任务比如说流水来自流水线上的任务数据处理 以及模型训练等向的话去会屏蔽底层的一些资源信息特别是存储 网络 酸力等对这一些AI任务的生命周期做一个统一的管理整个这个系统里边比较关键的就是模型相关 模型的市场以及模型的管理是我们这一部分要和大家介绍的一个重点然后另外一个部分的话也和大家要地介绍一下整个快手的进项分发的一个系统那快手的进项仓库它作为公司内部一个统一的进项管理平台支撑着公司所有容器进项的一个存储和管理底层的话是基于Hobber去做的一个实现那像在快手的这样的一个大的业务场景下国内和海外对应的一些举点分别都建设有对应的一个NUS Catch去加速对应区域的一个进项拉取那对于整个快手公司而言公司整体的一个平均进项大小的话其实有3.5G其中AR内的这种进项平均已经有30多个G以上40多G以上的大进项其实也是非常常见的那在这样子的一个背景之下我们要落实AR模型进项的一个分发其实会面临的一个非常关键的一些痛点最为关键的有一下几个方面第一个的话就是咱们公司AR的一个进项体积大小其实可以说是非常庞大的有30多个G以上这导致的一个后果就是咱们业务的一个实力启动在进项拉取阶段就会非常的耗时10分钟甚至二三十分钟都是非常有可能的第二个方面的话是咱们的训练任务一旦几种启动的时候有些时候是100兵发甚至更高的一个兵发的时候我们的进项仓库的出口流量带宽就会打满导致的后果其实这方面就已经非常严重了一旦哈绊出口流量带宽打满然后整个公司其他的业务服务的发布特别是在线业务的发布其实就没法正常进行了导致的后果直接就是一个固状级的一个大型的固状第三个方面的话就是这种哎呀模型大进向的拉取的时候它会产生这种单级的损失或者说持续的高IO带来的影响就是单级上面正在运行的业务的稳定性可能就会带来一个影响和干扰特别是我们核心电路上面的组件也可能会受到影响有点心的大家可能会遇到到IO的时候我们的couplet可能会由于PLG Not Ready这种驱逐单级上面的一个实力这个也是比较常见的针对这一些难点或者说我们遇到的一些痛点我们在AR模型进向分发上面也经历了几个关键的一些历程比如说进向解压缩算法方面的一些优化然后也引入了PDPJohn Fly去做进向分发的一个PDP的实现也包括John Fly下的一个紫相摩纳迪斯去做我们模型进向分发的一个难加载整体是去对齐我们业界的一些领先的进向分发的一些领先手段我们在对相关技术的选型的时候其实也是做了非常多充分的调研然后综合评比下来我们最终是拥抱了John Fly以及纳迪斯主要是几个下面的一个原因第一个方面的话就是John Fly它的生态是火月的我们评估下来是它是一个非常开放也是良好的一个良好的一个开源社区而且生态是非常健康的有非常多的厂商在参与期中也有非常多的一些高校的学生们也在参与所以我们认为它的生态非常良好第二个方面的话整个项目在我们内部落地下来的话是安全稳定的我们引入这样的一个项目到容器云平台之后它不会对我们现有的系统去产生侵入式的一些干扰部署上去整个运行是非常稳定然后也不会再用特别多额外的一些资源第三个方面的话整个项目维护起来非常地简单它本身就是云原生能够支持容器化的一些部署维护成本是非常低的我们一次性把这个事情做好之后后续的维护可以以极低的成本去维护第四个方面的话就是整套项目它确确实实能解决我们的核心的问题特别是我们AR模型进向分发引入进来之后这一些痛点能够得到彻底的一个编制关于快手AR模型进向分发我们为什么选择了模型进向这种方式呢主要有以下几个方面的一个考虑第一个方面的话就是它的投入成本是非常低的我们选用GiornoFlight这套项目它无需投入额外的人力去负责模型管理系统的一个开发与维护也无需投入额外的资源因为容器云我们本身已经有非常好的进向管理分发能力了然后引入这个方式的话可以非常低成本的就完成我们内部AR模型市场以及模型分发等管理上面的一些需求然后第二个方面的话就是交付便利因为进商仓库对于我们来说是公司级的一个服务通过这种进向模型产品的方式去做发布非常适合我们公司内部去做跨团队的交付以及模型的一个工厢特别是对于快手而言大部分业务其实都已经完成了容器化第三个方面的话就是数据方面的一个工厢得益于容器进商层的这些附用以及进向数据的创改及力度的一些去从压缩等这些机制我们可以节省模型加载流量以及后段数据的一个存储压力所以综合这些方面我们最终是选取了模型进向分发作为我们AR文件的模型的一个分发基础上面介绍了这么多最后和大家也分享一下装Flight具体咱们在快手落地的时候会面临着哪些问题对于我们来说最为关键最为核心的其实就是稳定性方面第一个方面的话就是涉及到管控的一个稳定性因为快手的容器云也是进有几十万的这种大规模的主机整个平台上面每时每刻可以说都有非常多的一些重要的业务在做发布比如说我们的电商的大醋星巴等这样子的一些大醋直播活动包括一些重要的一些大明星的见面会等等都有快速扩锁的这种需求咱们的经向接入DragonFlight之后可以说整个公司的这种业务发布就完全压榜在DragonFlight之上了对于管控面的稳定性的要求其实就是极为重要的对此我们采取的部署架构方式的话采取这种多AZ部署的架构AZ之间它是可以互为栽备的一旦管控面上面某个举步除了对应的问题我们马上可以自动地去调度自动地占留包括能够快速地止损去应对对于单级上的稳定性其实也是要求非常高的在我们单级维度的一个时间中我们也会结合自己公司内部AZ的一个部署的规范然后我们的工程师也做了充分的一些评估认为PDP这种进行拉绝其实它自身也是一个中CPU中内存资源消耗的一个服务对于单级上正在运行的这些业务即可能带来一些稳定性的一些干扰我们的一个建议的话就是像这些Deaf DemoDeaf Guide这些AZ的集群中部署是通过Democent就是容器化去部署的做好对应这些AZ的CPU以及内存资源的隔离和限制并且对我们的业务带来一些影响同时我们的容器引擎在做进行拉取的策略的时候也补充了对应的一个降级的策略因为容器化部署的这些AZ它只有可能在单级上也是会有实力的驱逐或者OM会受到一些影响我们在这方面的话即便这些AZ出问题我们也要在管控在这些组建一场工作的时候我们的进行拉取能够回源到我们的HUB这个是做我们我们后面的最后一道保障关于进行构建以及在业务的具体的使用方面来说因为刚刚也提到咱们快手容器铭的规模其实是非常龐大的特别是引入Nardis这种进行方案的时候我们必须去考虑这种平滑的切换能够平稳地去过度因此我们面临的几个问题一个就是我们没法直接一下子权量就推进这种单级上Nardis组建的一个部署另外我们的服务实在非常多没法要求我们的业务全部都直接改用Nardis这种进行格式因此我们必须找到一些应对策略一个方面的话是在流水线的这种进行构建方式上面我们是多版本去构建的也就是说同一个多个Fail我们会发布两个不同格式的进行版本一个是普通传统的OCR进行第二个的话就是Nardis进行的版本然后Push到我们的进行仓库之中然后到了单级上的话我们的实力调度到了单级然后在Kubernetes与容器引擎之间我们会对对应的实力创建请求做一个劫持会根据对应的一个判断第一个方面就是我们的业务开启了Nardis进行这种格式第二个方面的话就是我们的仓库中有对应的产品Nardis版本的产品第三个的话就是我们在单级上对应的组建是已经支持Nardis这种进行格式的时候在这个条件上面我们会去Nardis进行的版本做对应实力的一个创建如果说三个条件任何条件满足不了我们只能回到最开始的这种方式就是传统的OCR经向就拿去对应的经向版本做实力的一个创建以达到这种能够平稳的过渡能够平滑的让公司的业务切换到这种非常好的先进的这种方案上面来最后是和大家分享一下Dragonfly在快手落地之后能够取得的一些效果第一个方面的话就是我们的仓库出口网络贷款凭据压力基本上是已经节省到了70%凭据峰值的这种压力是节省了80%左右曾经我们Hub仓库这里经常出故障经常出问题这一个问题已经通过这一套方案已经得到了一个彻底的根治没有再出现过了另外的话就是我们的经向拉取耗时已经节省了90%然后我们的破的实力起动耗时也是节省了50%最后我的分享结束了大家如果说对Dragonfly以及Nardis感兴趣的话可以关注屏幕上面的一些二维码然后和社区的同事们一起做更深度的交流谢谢大家大家可以看看还有什么疑问或者问题可以已经提出了我来回答吧你好我想问一下Dragonfly PDP这个机制的话首先我想就是说它是不是至于IPFS来来实现不是的自己做一套自研那一套对那这套方式的话一个就是说它能不能指定节点就是它这个不一定比如说都在一个内网当中或者不在一个机构里面如果它是跨机构甚至跨云的我能不能指定这几个节点在这个节点当中做加速可以的因为Dragonfly本身它就有一套多级群方案有时候我可以只指定我一个小范围的P2P然后只调度在小范围当中是有的是可以的如果这个小范围当中它的网速是不均衡的有的连接很通这个当中它会自动调度对它都会考虑到每个节点它的贷款它的负载都会去做一个最优的调度那需要一个中心的控制面吗还是说对它的控制面是个中心的是个中心的对因为P2P大家应该知道BT协议BT协议它相当于最早的方案是基于Tracker的一个中心化的调度方案但是BT协议它是面向公网的所以说它的节点是不可控的它可能是海量的就是说调度器的话其实它扛不住的所以说它基于一个DHT和DHT的方案一个分布式的哈基表的方案去做一个群职的但是呢John Fly因为他做的是一个内网的P2P也就是说我们的节点数量是可控的所以说我们可以基于一个中心化的一个调度方案这样是可能对还有最后一个问题如果是真谅数据的话就它会只传播真谅吗这个没有的P2P的话就是说你的数据不能改变因为你在节点当中是你不知道它传到哪里的以镜像为单位的对 是的谢谢啊 客气您好我想请问一下就是Ladas里面夸基象驱虫的能力现在在社区里面好像看到P2然后应该有一年多左右了还没合进去不知道现在的进度怎么样Nadas驱虫其实已经有了是有的但是驱虫的话能力的话就是很一般或者就是跨镜像一个镜像里面有重物的OK 可以去掉我知道但是跨镜像我知道你意思跨镜像的一个驱虫方案对 就是社区里面CS这部分应该还需要做一下因为单镜像比较好做如果跨镜像你就需要一个中心化的一个服务了对 跨镜像或者中心化的服务或者在本地节点里面有一个本地节点撬个寻指对就是上面的CS对 其实我们内部是有这一套的但是但是就是没完社区里面可以对 是的之后我回去可以推一下他们但是有没有road map或者说什么时候会推进去或者说是有没有这个可以在Nadas的那个群里问一下可以问一下他们因为Nadas的话他们是另一个团队我是装Flight里面我只要去做P2P的那我想请问一下快手公司就是你们在处理的时候是不是也遇到这个问题是你们用的社区版本还是说是用到蚂蚁直接给你们提供的他们本地的版本我们目前是用到社区的版本那你们现在是不是也会有这个问题就是说跨镜像区重的问题是的 也会有这样子的问题的然后我们也是和他们做深度的一些合作想把这些事情做到结合实际公司的一些业务成绩那个版合做得更好这样子这个我们回去我回去推想让他们尽快做这件事情因为这件事情其实提了很多很长时间了就一个相当于一个中心化的一个去重的一个方案中心化的去重的一个方案或者说是直接在节点上面本地节点的话会有一个抽个表然后直接查这个表有重复的就不再下就OK了对 是的这个我回去可以推一下了好吧好 谢谢这个问题我带回去好 谢谢我想问一下就是刚刚这个P2P技术它可能会涉及到一些比如说NAT内网穿透一些技术在里面这个应该没有的因为内网的话我们认为都是都是透明的就是IP之间都可以访问的OK我们是没有这个问题所以说我们是假设就是它整张大网就是网络能互相通然后给我一个分发对 是的因为我以前有去研究过一些P2P技术比如说刚刚这位他提到IPFS他底层可能会用到LIB P2P这个库然后他可能就会涉及到这种内网穿透对是一种类似于VPN一样的技术对咱们这边其实上就假设他底层网路已经是通了了对 是的好好明白这种一般是面向公网他会去搞一些内网穿透这种OK好 那我明白谢谢这样就有一个问题就是如果说我们一个节点可能会拉很多进行他会把我的整个这个主机就是闹着节点的带款打满如果说我这样的话会影响业务如果说我不想影响业务我想限制它的P2P拉取速度现在支持吗或者有什么结局方案吗限制它的P2P拉取速度我们都提供的我们科物端它提供了上传的一个限速提供了一个下载的限速都有的都支持的就官方文档配置应该有的只不过可能没强调一下是吧对就单接点的上传下载速度有一个限速而且我们单任务的限速都已经有了就是说你可能可能同时上传或者下载多个任务我们把整体有个限速然后单任务也有限速的对都支持的还有什么问题吗没有问题的话咱们可以线下交流也可以的对我们装给了装Fly社区的话其实也希望更多的公司来参与进来做这件事情对因为我认为AI场景下其实确实P2P是一个很好的一个解决方案你不论说你如何去做文件系统的一些优化或者说你做文件系统相关一些东西都没有一个P2P我感觉解决的就可能它解决的是1%的问题但P2P可能就解决到90%的问题对吧行那我就这次分享结束了好谢谢大家