用Dragonfly加速大规模模型分发

现代基础设施在计算资源调配方面已经非常成熟，但制品交付仍是常见瓶颈。当数百甚至数千个节点需要同时获取同一个镜像、模型或文件时，源站系统往往会不堪重负，使扩容从计算问题变成流量问题。

Dragonfly 是一个 CNCF 毕业项目，正是为解决这一问题而构建。它利用 P2P 技术提供高效、稳定且安全的数据分发能力，支持大规模交付文件、容器镜像、OCI 制品、AI 模型、缓存、日志和依赖项。

Dragonfly 架构：Manager、Scheduler、Seed Peer 和 Peer 角色

Dragonfly 解决的基础设施问题

在以 Kubernetes 为中心的系统中，突发部署可能会触发大量针对同一制品的并发请求。源站可能是 registry、对象存储、内部制品服务器或公共模型中心，但故障模式都很相似：太多节点在同一时间直接从同一个位置拉取相同的数据。

这个问题在 AI 环境中会变得严重得多。Dragonfly 维护者指出，现代模型权重已从数百 MB 增长到数百 GB，甚至 TB 级别，这使模型分发成为基础设施的核心问题。

CNCF Dragonfly 给出的一个示例表明：如果使用普通下载方式将一个 130 GB 的模型分发到 200 个 GPU 节点，将产生 26 TB 的源站流量；而 Dragonfly 在首次获取后利用 P2P 分发，可以将其减少到约 130 GB。

归根结底：计算能力的扩展速度已经超过制品交付能力，而这一差距会影响每一个运行大规模 Kubernetes 或 AI 工作负载的团队。

Dragonfly 将其系统划分为四种角色：

集群中的首次下载

• Client 通过 HTTP/HTTPS proxy 或 gRPC 请求制品

• Peer 向 Scheduler 注册任务

• Scheduler 触发 Seed Peer，从源站获取一次数据

• 任务被拆分成多个分片；分片从 Seed Peer → Peer 进行流式传输

• 分片元数据会上报给 Scheduler，供后续调度使用

• 如果本地已有分片 → 立即组装并返回（不联系 Scheduler）

• 否则 → Scheduler 分配已经拥有这些分片的其他 Peer

• Peer 并行从多个父节点下载分片，然后组装文件

基于分片的 P2P 分发流程

为什么 Dragonfly 此刻如此重要

Dragonfly 出现的时机很关键。CNCF 表示，该项目：

• 在生产环境中支持每天数千万次容器启动
• 最多可节省 90% 的存储带宽
• 在大规模环境中，可将启动时间从数分钟缩短至数秒

仅凭这些能力，它对平台工程就已经十分重要，而 AI 维度又让它在今天变得更加切题。

AI 工作负载让制品分发变得更加困难，原因包括：

• 模型体积庞大（数百 GB 至 TB 级别）
• 启动延迟会直接影响推理吞吐量和成本
• 同一批文件经常需要反复分发到大量节点
• 外部模型中心（Hugging Face、ModelScope）存在速率限制和出口流量成本

Dragonfly 如今已经明确面向 AI 训练和推理中的分发工作流提供加速能力，其中包括 Hugging Face 和 ModelScope 的原生集成路径。

值得关注的特性

Dragonfly 的核心能力不只是追求极致速度，也关乎生产环境的可靠性：

近期改进（v2.4.0）

在最新的项目演讲中，维护者介绍了 Vortex 传输协议（基于 TLV），并公布了以下结果：

• 与 gRPC 相比，大文件下载时间缩短约 50%（TCP Vortex）
• 与 gRPC 相比，下载时间缩短约 40%（QUIC Vortex）
• 更智能的预热，以及基于 hash 的任务识别机制，可避免跨 repository 重复下载。

Dragonfly 在云原生 AI 技术栈中的位置

Dragonfly 发展历程中最有意思的转变之一，是它不再只与镜像加速有关。它正在成为一个实用的**模型交付层、基于 registry 的模型管理基于 registry 的模型管理，以及 Kubernetes 原生推理工作流以及 Kubernetes 原生推理工作流。项目资料描述了这样的工作流：对模型制品进行版本管理、存储、预热，并将其挂载到推理容器中，而不是把它们当作一次性下载来处理。这一方向非常契合平台团队管理 AI 基础设施的方式：平台团队管理 AI 基础设施的方式：可复现、高效，并采用与软件制品相同的运维规范。

为什么我认为平台团队应该关注它

从维护者的角度来看，Dragonfly 所讲述的故事远不止“更快的下载”。它反映了云原生架构中的一种转变，即**面向容器、制品、制品和 AI 模型的一等优化层。对于平台工程师而言，这意味着：平台工程师而言，这意味着：

• 更快的 AI 和 AI 工作负载
• 更低的源站负载和和出口流量成本
• 降低突发多节点部*对于 KubeCon 的听众来说，最有力的信息很简单：*计算能力的扩展速度已经超过制品交付能力，而 Dragonfly 通过一个**为 Kubernetes 时代基础设施构建的系统弥合了这一差距。这正是该项目如今重新显得重要的原因，而不只是具有历史意义。

Dragonfly 文档：d7y.io/docs/next

CNCF 项目页面：cncf.io/projects/dragonfly

CNCF 毕业公告：cncf.io announcement

Hugging Face 集成指南：d7y.io/docs/.../hugging-face/

P2P AI 模型分发博客：cncf.io blog

v2.4.0 项目演讲：YouTube

GitHub：keda-gpu-scaler | gpu-mcp-server

Pavan Madduri 是 W.W. Grainger 的高级云平台工程师、CNCF Golden Kubestronaut，以及 CNCF TAG Workloads Foundation Tech Lead。他负责维护 keda-gpu-scaler 和 gpu-mcp-server，并为包括 KEDA、Volcano 和 Dragonfly 在内的 CNCF 项目做出贡献。你可以在 GitHub 上找到他。

如需采取进一步措施，你可以考虑屏蔽此人和/或举报滥用行为。