KubeDL 0.4.0 - Kubernetes AI 模型版本管理与追踪

前言

KubeDL 是阿里开源的基于 Kubernetes 的 AI 工作负载管理框架，取自"Kubernetes-Deep-Learning"的缩写，希望能够依托阿里巴巴的场景，将大规模机器学习作业调度与管理的经验反哺社区。目前 KubeDL 已经进入 CNCF Sandbox 项目孵化，我们会不断探索云原生 AI 场景中的最佳实践，助力算法科学家们简单高效地实现创新落地。

在最新的 KubeDL Release 0.4.0 版本中，我们带来了模型版本管理（ModelVersion）的能力，AI 科学家们可以像管理镜像一样轻松地对模型版本进行追踪，打标及存储。更重要的是，在经典的机器学习流水线中，“训练”与“推理”两个阶段相对独立，算法科学家视角中的“训练->模型->推理”流水线缺乏断层，而“模型”作为两者的中间产物正好能够充当那个“承前启后”的角色。

Github：https://github.com/kubedl-io/kubedl

网站：https://kubedl.io/model/intro/

模型管理现状

模型文件是分布式训练的产物，是经过充分迭代与搜索后保留的算法精华，在工业界算法模型已经成为了宝贵的数字资产。通常不同的分布式框架会输出不同格式的模型文件，如 Tensorflow 训练作业通常输出 CheckPoint(*.ckpt)、GraphDef(*.pb)、SavedModel 等格式，而 PyTorch 则通常以 .pth 后缀，不同的框架会在加载模型时解析其中承载的运行时的数据流图、运行参数及其权重等信息，对于文件系统来说，它们都是一个（或一组）特殊格式的文件，就像 JPEG 和 PNG 格式的图像文件一样。

因此典型的管理方式就是把它们当作文件，托管在统一的对象存储中（如阿里云 OSS 和AWS S3），每个租户/团队分配一个目录，各自成员再把模型文件存储在自己对应的子目录中，由 SRE 来统一进行读写权限的管控：

这种管理方式的优缺点都很明显：

• 好处是保留了用户的 API 使用习惯，在训练代码中将自己的目录指定为输出路径，之后将云存储的对应目录 mount 到推理服务的容器内加载模型即可；
• 但这对 SRE 提出了较高的要求，不合理的读写权限授权及误操作，可能造成文件权限泄露，甚至大面积的误删除；同时基于文件的管理方式不易实现模型的版本管理，通常要求用户自身根据文件名来标记，或是上层平台自己承担版本管理的复杂度；此外，模型文件与算法代码/训练参数的对应关系也无法直接映射，甚至同个文件在多次训练中会被多次覆写，难以追溯历史；

基于以上现状，KubeDL 充分结合了 Docker 镜像管理的优势，引入了一套 Image-Based 的镜像管理 API，让分布式训练和推理服务结合得更紧密自然，同时也极大简化了模型管理的复杂度。

从镜像出发

镜像（Image）是 Docker 的灵魂，也是容器时代的核心基础设施。镜像本身即分层的不可变文件系统，模型文件天然地可以作为其中的一个独立镜像层，两者结合的还会迸发出其他火花：

• 用户不用再面向文件管理模型，而是