Dragonfly 介绍、更新和快手中的 AI 模型分发实践

第一阶段：DragonFly 基本介绍

介绍了 DragonFly 的历史背景

子项目 Nydus 介绍

Nydus 主要职责是镜像的去重、压缩，并且在镜像启动、运行过程当中进行按需加载，可以将端到端的启动速度从分钟级提升到秒级，同时 Nydus 也是由阿里云、蚂蚁、字节跳动三家公司研发的，DragonFly P2P 的解决方案。

为什么使用 DragonFly，解决了什么问题？

一句话概括：源站的带宽瓶颈问题

假设在上千、上万个节点，都需要加载一个镜像、文件或者是 AI 模型，这时候，就需要上千、上万次的并发下载文件。这个过程很容易达到带宽上限，导致整个加载流程的变慢，或者容器启动变慢。

解决方案：

1. 提高带宽上限

   问题：硬件成本过高，且有瓶颈 -- 中心化的存储方案解决不了大规模场景

2. 利用 P2P 方式，利用节点的闲置带宽来缓解带宽瓶颈

   问题：着力于大规模场景，小规模场景并不受很大影响

3. 尽量少的加载资源

   问题：在构建镜像、文件、AI 模型时进行去重、压缩，并且在加载时做到按需加载

那么 DragonFly 就是结合第二和第三种方式来解决 源站带宽瓶颈问题的

近期大规模更新

1. 重写可视化控制台，将 P2P 集群的部署操作、多集群方案定义的更加清晰，让用户的体验更好

2. 智能化调度方案，两个数据： ①基于节点之间进行探测，构建一个虚拟的网络结构； ②基于节点之间的历史加载数据，通过 GNN 和 MLP 算法构建两个模型进行 predict ，选择最优的父节点进行调度。

第二阶段：AI 场景下如何进行加速

如何进行加速？

把 AI 场景数据分为四类

1. 数据集

2. 模型

3. 框架

4. 外围数据

一：训练阶段

要点

1. Fluid：进行数据编排，同时它的 runtime 是基于分布式文件系统如 JuiceFS；

2. JuiceFS：加载是按每一个 chunk，适用于小规模，大规模情况下会打满存储；

3. 解决方案：与 Juice 社区进行沟通，将 Dragonfly 集成到 Juice 中，让 chunk 流量走 P2P 分发，由此有效缓解源站带宽；

二：重点：Drangonfly 在 AI 场景下用处最大的一个场景

对于 AI 推理、训练过程中，听到过很多方案，如分布式文件系统方案等。

但是戚老师认为，在 AI 推理过程当中，P2P 是最好的解决方案

为什么？

首先 AI 有两个前提：

1. AI 推理服务过程当中具有并发性，需要启动一两千个服务进行线上 serving

2. AI 模型足够大，从上百 MB 到上百 G 都有可能，一千个推理节点同时加载大文件的情况下，源站带宽不管怎么样都会被打满的。内部一些大模型场景，在没有用 P2P 之前，加载整体一千个服务的时候，可能需要几个小时，使用 P2P 之后只需要几分钟。因为 Dragonfly 能做到最好的情况，让整个集群当中只有 1 个节点进行回源。这样就会让回源加载尽量快，此时加载过程中它的 piece 也能在 P2P 集群当中进行内网加载，由此大大提升速度。

这是第一种方案：直接使用 Dragonfly 做 P2P 模型分发

第二种方案：是模型文件系统方案

用 Nydus 将文件构建为 rafs 格式的文件，这个过程能够做到去重和压缩，同时在加载时会按需加载 chunk，经过 Dragonfly 进行分发。此方案的问题在于集成比较麻烦。

第三种方案：模型镜像方案，是快手公司落地的方案

相似于模型系统文件方案，用 Nydus 转换为 ocive 格式，将模型和推理服务框架打在同一个镜像当中，转换为 Nydus 格式的镜像。加载过程当中，通过 Nydus 去分 chunk 和按需加载。

优势：部门交接简单，如训练部门和推理部门沟通，通过镜像版本的方式进行交付可以做到沟通成本最低化。

三：Dragonfly 和各 AI 推理社区进行结合

提到了 Hugging face hub，预测会成为未来容器镜像的 Dockerhub

Dragonfly 与其进行集成之后，Dragonfly 未来在 AI 推理种就会拥有自己的位置

举例：Dragonfly + TorchServe

TorchServe 会提供一个 plugin，将所有模型加载的流量转发到 Dragonfly P2P 网络当中进行加速。

四：框架及外围数据

第三阶段：快手 AI 模型分发实践分享

快手 AI 平台简介

介绍了快手 AI 平台的业务背景

快手 AI 模型镜像分发痛点

1. 耗时严重

2. 高并发情况下，出口流量带宽打满，其它在线业务无法发布，达到故障级

1. 单机瞬时高IO/持续高IO，对其它业务稳定性带来影响

快手 AI 模型镜像分发优化历程

快手 AI 模型镜像分发技术选型

为什么选择 Dragonfly？

为什么选择模型镜像方案？

Dragonfly AI 模型镜像分发实践

遇到的问题：

1. 快速扩缩容需求频繁：整个公司的业务发布放在 Dragonfly 之上，管控面的稳定性极为重要，对此必须采取多 AZ 部署架构，AZ 之间互为灾备，管控面具有自动调度和自动摘流机制，异常时能够快速止损。

1. 单机稳定性：将 dfdaemon 和 dfget 在 k8s 集群中通过 daemonset 容器化部署，做好 CPU/内存资源隔离与限制。同时针对容器引擎镜像拉取策略，补充降级策略，确保在管控或单机 Agent 组件异常时，镜像拉取迅速回源。

2. 镜像构建与业务使用：在流水线镜像构建方面采取多版本构建，例如对同一个 Dockerfile，会发布两个不同版本，一个是传统 ocr 镜像，一个 Nydus 镜像，然后 push 到镜像仓库中。

效果总结

效果显著

第四阶段：提问

跨云、跨机构场景，能否指定节点进行加速？

答：可以，Dragonfly 本身支持指定小范围 P2P。

追问：小范围当中如果网络不均衡，是否会自动调度？

答：可以。

追问：需要中心控制面吗？

答：是的，Dragonfly 基于内网 P2P ，节点数量可控，所以可以做到中心化的调度方案。

追问：增量数据的话，会只传播增量吗？

答：不支持，P2P 数据不能改变，以镜像为单位，不知道数据传递到哪里。

跨镜像场景去重方案

答：需要往这方面努力，内部有这套方案，但是还没有推到社区当中。

P2P 技术是否涉及 NAT 内网穿透技术？

答：内网之间 IP 能够互相访问，默认为透明的，所以不涉及。

是否提供限速？

答：是的，提供上传与下载的限速，细化到单任务的限速。