为什么开发者喜欢开源 KitOps——来自机器学习前线的经验分享

在人工智能/机器学习领域，充斥着大量吹捧最新技术创新的文章。大多数情况下，这些创新并未被应用到少数科学家之外的人群中。与此不同，我们撰写本文旨在分享一家真实公司中的真实用户如何使用 KitOps，并以简洁明了的方式解释为什么 KitOps 是唯一能够满足他们需求的解决方案。

TAR 和 S3 的愚蠢之处

首先，我们来谈谈大家心知肚明却又避而不谈的问题：TAR 文件。没错，它们的确很方便，能把你的文件打包成简洁易用的压缩包。但蜜月期也就到此为止了。一位名叫 Niklas 的用户，同时也是一家德国联邦科技公司的工程师，用只有亲身经历才能体会到的那种直言不讳，向我们揭示了 TAR 的弊端：“ S3 和 GitLFS 就像狂野西部——什么都可以做，而这恰恰是问题所在，因为它们都存在缺陷。 ”
并非防篡改：如果没有不可篡改的特性，就无法保证你的文件没有被篡改过。祝你好运，看看该如何向你的合规官解释这一点。

缺乏可听性：当需要追溯决策源头时，技术授权报告 (TAR) 和 S3 几乎帮不上什么忙。正如 Niklas 指出的，新的人工智能法规“要求确保发布文件的完整性和真实性”。如果你的文件散落在各处，未经核实且缺乏约束，又该如何做到这一点呢？

轻松标记：冠军模型与挑战者模型、语义版本控制——如果没有合适的工具，想实现这些目标几乎是不可能的。TAR 做不到，S3 也做不到。

元数据处理不当：没错，你的工件可能有个名称，但这能完整地描述它吗？那些对下游流程至关重要的额外元数据呢？
供应链不一致： “所有东西都在 Artifactory 里，”Niklas 指出，“那么为什么不把机器学习工件也存储在那里呢？”关键在于一致性，而 TAR 或 S3 都无法做到这一点。

KitOps 的力量

相比之下， KitOps不仅仅存储您的工件，还会将它们放入您现有的 OCI 镜像仓库（DockerHub、Quay.io、Artifactory、GitHub Container Registry），这些仓库已经过安全审核，并采用企业级身份验证和授权机制。现在，它们受到严密保护，而KitOps ModelKit格式确保每个字节都被记录在案，每个版本都被标记和跟踪，每个工件都像珠穆朗玛峰一样不可更改。这不仅仅是为了满足合规性要求，更是为了确保您的 AI 模型从一开始就值得信赖、可靠且安全。

为什么选择 KitOps？

防篡改：使用 KitOps，您的工件将被锁定、哈希处理并以不可更改的方式存储。您再也不用担心半夜惊醒，担心某些东西被偷偷篡改了。

可审计性：每个工件都带有完整的历史记录，确保当审计人员上门时，您不会手忙脚乱地寻找答案。

标签和版本控制： KitOps 内置了对冠军模型与挑战者模型、语义版本控制等功能的支持，使管理复杂的机器学习工作流程变得轻松。

优雅的打包： KitOps 不仅存储您的工件，还会将它们与您需要的所有元数据打包在一起，从而确保每次部署都具有一致性和可靠性。

供应链的一致性： KitOps 将所有内容存储在 Artifactory 中，确保您的 AI/ML 工作流程与 DevOps 流程的其他部分一样无缝衔接。

扩大规模

当然，如果 KitOps 无法扩展，这一切就毫无意义。但正如 Niklas 所解释的，这并非问题。他的团队目前规模虽小——只有 10 到 15 位数据科学家、工程师和 SRE，负责五个预测性机器学习模型——但他们正在不断壮大。随着团队的扩张，KitOps 也将随之扩展，确保他们的工作流程始终流畅、安全且一致，无论部署多少模型。正因如此，它才被全球一些最大的政府机构、科研实验室和科技公司所采用。

预测性机器学习，而非层级线性模型

值得注意的是，Niklas 的团队目前还没有深入研究机器学习（LLM），他们专注于预测性机器学习。但无论您是部署机器学习、微调机器学习，还是仅仅管理少量预测模型，KitOps 都能满足您的需求。当然，如果您正在开发机器学习，KitOps 就显得更加重要，因为项目工件的数量和规模只会不断增长。

底线

如果你对人工智能/机器学习认真投入，并且厌倦了那些承诺美好却实际表现糟糕的工具，那么是时候了解一下 KitOps 了。它不仅仅是存储你的工件——更重要的是确保它们的安全性、可审计性，以及随时可以部署。因为在这个领域，任何低于此标准的风险都是你无法承受的。

如果您对将 KitOps 集成到您的团队有任何疑问，请加入Discord上的讨论，并立即开始使用 KitOps！