BentoML：如何使用 JuiceFS 加速大模型加载？( 二 ) _大模型

3为什么使用 JuiceFS ？
接下来将详细探模型部署这一关键阶段的具体工作。下图展示了我们最初采用的架构，即将所有模型文件，包括 Python/ target=_blank class=infotextkey>Python 代码、Python 依赖和扩展，都打包成一个 Container Image，然后在 Kubernetes 上运行。然而，这一流程面临着以下挑战：

文章插图
【BentoML：如何使用 JuiceFS 加速大模型加载？】（BentoML：最初模型部署流程图）

首先，一个 Container Image 由一系列 Layer 组成，因此 Container Image 最小的下载和缓存单位是 Layer，虽然在下载 Container Image 时，Container Image 的 Layer 是并行下载的，但 Layer 在解压的时候是串行的。当解压到模型所在的 Layer 时速度会减慢，同时占用大量的 CPU 时间。
另一个挑战是当不同的 Bento 使用相同的模型时。这种架构会浪费多份相同的空间，并且被打包到不同的 Image 中，作为不同 Layer 存在，导致了多次下载和解压，这是极大的资源浪费。因此，这种架构无法共享模型。

在解决这个问题时，我们首选了 JuiceFS，主要因为它具有以下三个优势。

首先，它采用 POSIX 协议，无需再加一层抽象就使我们能够以连贯的方式读取数据。
其次，它可以达到很高的吞吐，可以接近整个 S3 或 GCS 的带宽。
第三，它能够实现良好的共享模型。当我们将模型存储在 JuiceFS 中时，不同实例可以共享同一个大型语言模型。

下图是我们集成 JuiceFS 后的架构。在构建 Container Image 时，我们将模型单独提取并存储到 JuiceFS 中。Container Image 中仅包含用户的 Python 业务代码和 Python 运行所需的依赖和基础环境，这样的设计带来的好处是可以同时下载模型和运行，无需在本地解压模型。整体解压过程变得非常迅速，下载的数据量也大大减少，从而显著提升了下载性能。

文章插图
（BentoML：使用 JuiceFS 后的模型部署流程图）
此外，我们进一步优化了下载和缓存的颗粒度，不仅每个模型都有自己的缓存颗粒度，而且 JuiceFS 对大文件分割成了一系列 chunk ，以 chunk 为单位进行下载和缓存，利用这个特性可以实现类似于大模型的 Stream Loading 的效果。
我们还充分利用了 GKE 的 Image Streaming 技术。通过 Model Streaming 和 Image Streaming 同时进行数据拉取，我们成功降低了启动时间，提升了整体性能。
4集成 JuiceFS 时遇到的挑战

挑战 1：无缝集成

在引入 JuiceFS 这一新组件时，必须处理如何与已有组件实现无缝集成的问题。这种情况是在任何较为成熟的平台引入新组件时都会遇到的普遍挑战。为了更好地继承 JuiceFS，我们采用了 AWS MemoryDB，以代替自己运维的 redis，从而降低架构的复杂度。

挑战 2: 引入新组件对业务逻辑的影响

引入 JuiceFS 可能导致业务逻辑的变化。之前，Bento 的容器镜像包含了完整的模型，而现在的 Bento 容器镜像则不再携带模型。在 yatai-serverless 平台的部署中，我们必须在代码层面确保这两种不同的镜像在业务逻辑上实现相互兼容。为此，我们使用不同的 label 来区分不同版本的 bento ，然后在代码逻辑里做向前兼容。

挑战 3: JuiceFS 下载速度问题

在测试 JuiceFS 时发现，使用 JuiceFS 下载模型的速度非常慢，甚至比直接从镜像中下载还要慢。通过 JuiceFS 团队的协助，我们发现我们的 Boot Disk 是网络磁盘，所以我们一直使用网络磁盘作为 JuiceFS 的缓存盘，这就会导致一个奇怪的现象：不命中缓存时速度更快，一旦命中缓存就变慢。为了解决这个问题，我们为我们的 GKE 环境都添加了 Local NVME SSD，并将 Local NVMe SSD 作为 JuiceFS 的缓存盘，从而完美地解决了这一问题。
5展望
在未来，我们将深入进行更多的可观测性工作，以确保整个架构保持良好的运行状态，并获得足够的指标以便更好地优化配置，尽量避免再次出现类似的问题。
希望可以高效利用 JuiceFS 自带的缓存能力。例如，将模型提前种植到 JuiceFS 后，这意味着在业务集群中，可以提前在节点中预热模型的缓存，从而进一步提升缓存和冷启动时间的性能。