KitOps：AI 模型与 DevOps 的集成方案

昨天，Jozu CEO、KitOps 维护者 Brad Micklea 做客了由 Sean Falconer 主持的 Partially Redacted 播客。在这场长达 45 分钟的对谈中，他们讨论了许多话题。具体来说，他们聊到了 KitOps 项目的现状、项目未来的发展方向，以及我们关于如何将基于 KitOps 构建的 Jozu 产品化并发布的一些早期构想。

在本文中，我想更深入地探讨其中几个话题。

我们之所以构建 KitOps，是因为将 AI/ML 模型部署到生产环境是一项复杂且极具挑战的工作，需要针对 AI 运维的特定需求，使用不同的工具和基础设施。不过，这里需要找到一个平衡点。企业并不希望为了开发、部署和维护 AI/ML 模型，再单独搭建一套完全独立、与现有体系并行的工具链。它们已经在现有 DevOps 工具中建立并完善了安全与合规护栏。遗憾的是，这些工具在设计之初，并没有考虑如何处理 AI 项目中的超大文件，也没有考虑 AI 项目动态变化且会随时间衰减的特性。

几年前，这还不是什么问题。但随着 AI 和 machine learning 不断发展、应用范围持续扩大，我们越来越需要一类工具，将数据科学与实验所在的 AI 世界，同软件工程与 DevOps 所在的生产世界连接起来。KitOps 的 ModelKits 和 CLI 正是为满足这些需求而设计的，它们提供了一种高效、可扩展且易于使用的方式，用来打包、共享和部署 AI 模型。这是朝正确方向迈出的一步，但也仅仅是一步，我们还有很长的路要走。

AI/ML 的工具与基础设施挑战

部署 AI/ML 模型，并不只是编写和测试模型代码那么简单。它需要一套能够支持模型完整生命周期的技术栈，包括训练、打包、验证、部署、运行和重新训练。模型在这套流程中流转时，会多次在不同团队之间来回交接。ModelKits 和 Kit CLI 可以生成兼容 OCI 的软件包，让它直接与现有工具配合使用，同时不再需要将模型重复打包成多种供应商专属格式，从而简化整个过程。

这样做的好处显而易见。ModelKits 将数据、配置和依赖项等所有必要组件打包在一起，可以确保不同环境中的部署保持一致且可复现，也让围绕模型展开协作变得更加容易。此外，模型从代码到数据集的每一个组成部分都受到版本控制。ModelKit 一旦创建，便不可变且能够防止篡改，从而确保任何未经授权的修改都不会影响部署。

Jozu 是什么？它在这一切中扮演什么角色？

有一件事我们一直没有真正详细谈过，那就是 Jozu。一直密切关注我们经历的人应该知道，Kit 这一概念源于我们创建一家名为 Jozu（V1）的初创公司时，亲自尝试部署模型所积累的经验。这是一个很长的故事，但最终，Jozu（V1）进行了业务转型，将重心转向 Kit 的发布与产品化。从这里开始，我们所说的 Jozu 都是 Jozu V2。

如今，正是 Jozu 这家公司，让我们得以每天专注于构建 Kit。

展望未来，我们对 Jozu 有着宏大的规划。自 KitOps 发布以来，我们从设计合作伙伴那里收到了非常宝贵的反馈。其中许多反馈已经进入 KitOps 的 roadmap，还有一部分则属于企业级使用场景。Jozu 最终将专注于构建企业所需的基础设施，帮助它们大规模采用 KitOps，并将 KitOps 与那些经过长期打磨、已经十分成熟的流程结合起来。

Jozu 接下来的一个重要里程碑，是推出一个用于共享和获取 ModelKits 的公共 Hub。用户可以免费使用这个 Hub，并在其中存储自己的 ModelKits。它将促进社区协作，让开发者和企业能够共享各自的解决方案与改进成果，从而推动整个行业的创新，而不必担心你或对方正在使用什么工具。

针对企业用户，我们计划提供私有仓库，让企业能够存储专有的 ModelKits，并支持自定义安装，使企业可以在自己的防火墙之后安装和运行 Jozu 的基础设施，从而确保数据隐私与安全始终保持在最高水平。

除此之外，我们还在探索其他方式，希望围绕来源追溯、安全、监控和平台集成，为企业创造更多价值。随着这些能力逐渐成形，我们会及时向大家同步进展。

目前，我们很高兴看到 KitOps 持续得到大家的支持，也非常感谢每一位愿意花时间向我们提供产品反馈的人。信不信由你，我们会讨论并记录与 KitOps 用户的每一次交流，而这些交流也会带来大量新的 ticket。如果你有兴趣继续关注我们的旅程，欢迎加入我们的 Discord server，并参与 KitOps 项目。