ML in a Box: Analyzing Containerization Practices in Open Source ML Projects
本文呈现了对 1,993 个开源机器学习 Dockerfile 的首次大规模实证研究，揭示了尽管容器在机器学习工作流中承担着不同的角色，但由于频繁由实验触发的重新构建，这些容器往往体积庞大且效率低下，从而促使本文识别出七种特定的重构模式，以提高构建效率并减小占用空间。
原始论文根据 CC0 1.0（http://creativecommons.org/publicdomain/zero/1.0/）发布到公有领域。 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。 阅读完整免责声明
想象一下你是一位经营着一家大型高科技厨房的厨师。在机器学习（ML）的世界里，你的“食谱”是代码，你的“食材”是数据和模型，而你的“厨房”就是一个容器（Container）。容器就像一个自给自足、可移动的厨房箱，里面装满了制作特定菜肴所需的一切，确保无论是在纽约、东京，还是在太空船上烹饪，味道都始终如一。
长期以来，人们都知道这些厨房箱很有用。但没人真正知道它们有多大，打包需要多久，或者厨师们仅仅因为换了一个调料瓶，就不得不把整个箱子扔掉重新开始的频率有多高。
一组研究人员决定窥探 1,993 个这样的机器学习厨房箱，涵盖了 392 个不同项目，以看看究竟发生了什么。以下是他们发现的情况，附带一份现实的佐料。
“厨房箱”的大小：这事儿非同小可
首先，他们称量了这些箱子的重量。你可能认为容器是轻便快捷的，但这些机器学习箱其实是巨兽。
- 平均而言，一个容器重达 10.27 GB。这就像为了做个三明治，就在背包里背了一整套百科全书。
- “训练”（Training）箱（AI 进行学习的地方）最重，平均为 17.25 GB。其中一些怪物甚至达到了 125 GB！
- “推理”（Inference）箱（AI 仅执行工作的地方）较小，约为 1.72 GB，但也不算得上是口袋大小。
而打包这些箱子呢？这很耗时。平均“冷构建”（从零开始打包一个箱子）需要 8.84 分钟。对于那些大型训练箱，可能需要超过 14 分钟。为了看一眼你的代码是否有效，等待这么久可不是件好事。
“哎呀”时刻：为什么我们要扔掉箱子
在正常的厨房里，如果你修改了食谱，你只需要调整指令即可。但在机器学习的世界里，厨房遵循严格的“层（Layer）”系统。想象一下在搭积木塔：如果你改变了第三层积木的颜色，你就必须拆掉第三层、第四层、第五层，一直到最顶端，即使顶部的积木根本没变。
研究人员发现，开发者对项目所做的所有更改中，有 44.4% 会触发整个容器的重新构建。这意味着近一半的时间里，他们都在丢弃辛苦完成的工作并从头开始。
是什么导致了这种“丢弃”？
通常并不是因为食谱本身（Dockerfile）发生了变化。而是因为食材！
- 96.4% 的重新构建是因为有人更改了被复制到箱子内部的文件（比如数据集或代码文件）。
- 只有 1.1% 的重新构建是因为有人更改了构建箱子的实际指令。
浪费：70% 的工作都是徒劳
这是故事中最令人难过的一部分。当“层塔”断裂时，厨房会尝试复用已经构建好的积木。但研究人员发现，71% 的工作被浪费了。
- 可以这样理解：你花了 10 分钟搭了一个积木塔。你撞倒了第三层积木。你试图复用前两层，但随后你必须重建剩下的部分。最终，你只复用了大约 30% 的精力，另外 70% 只是在重复已经做过的工作。
为什么会发生这种情况？
这取决于你在更改什么。
- 如果你是在调整实验（改变 AI 的大脑或数据），你最有可能破坏这个塔。对于训练箱，这种情况发生的概率为 46%。
- 如果你是在更新基础设施（比如厨房的水管或电路），你几乎总是会破坏这个塔，并且会损失几乎所有的进度。
好消息：聪明的厨师找到了捷径
尽管情况混乱，但研究人员发现一些聪明的厨师已经在解决这些问题。他们观察了那些“最佳”厨房（即浪费时间最少的厨房），并发现了 7 个具体的技巧，这些技巧能阻止浪费。这些不仅仅是猜测，而是开发者进行的、确实有效的实际改动。
以下是这 7 个技巧：
- 不要打包杂货： 不要将巨大的数据集直接复制进箱子，而是告诉箱子在开始烹饪时去哪里寻找它们。
- 不要打包模型： 对 AI 模型也一样。不要把它“烘焙”进箱子里；在需要时从外部加载。
- 把重活移开： 如果你必须下载一个大模型，请在食谱的早期阶段进行。这样，如果你稍后更改了一个小文件，那个大的下载过程仍会被缓存（保存）下来。
- 拆分厨房： 如果你需要一个同时支持 CPU 和 GPU 的箱子，不要做一个包含所有东西的巨大箱子。而是制作两个较小的、专业化的箱子。
- 选择正确的工具： 如果你只需要“CPU 版本”的工具，就不要安装“GPU 版本”。这能节省大量的空间。
- 移动易变的部分： 如果你经常更改配置文件，请将它们放在食谱中大型安装步骤之后，这样它们就不会破坏沉重的层。
- 不要下载整个历史记录： 在从互联网获取代码时，不要下载整个项目的历史记录。只需抓取最新的快照即可。
总结
这篇论文并不是说这些问题已经“解决了”。它指出的是，目前机器学习容器是庞大、缓慢且脆弱的。由于开发者把太多东西塞进箱子里，并且过早地破坏了缓存，他们正在浪费大量的时间（大约 70% 的重建精力）。
但好消息是，我们知道如何修复它。通过使用这 7 个技巧，团队可以让他们的容器更小、构建速度更快。这不是魔法，这只是更好的组织方式。研究人员通过实际构建这些箱子并计算分钟数来衡量这一切，所以我们知道这些数字是真实的。下次当你看到一个机器学习项目时，请记住：它不仅仅关乎代码，更关乎你如何打包你的厨房。
您所在领域的论文太多了？
获取与您研究关键词匹配的最新论文每日摘要——附技术摘要，使用您的语言。