通过 GPU 快照减少 GVisor 冷启动

通过内存快照减少 GPU 冷启动：在几秒钟内恢复 CUDA 工作负载如果您在生产中运行 AI 模型，那么无论您是否想要冷启动，您都与冷启动有关。三分钟的启动时间会改变您的扩展方式。您可以对本来可以释放的 GPU 进行保温。您进行过度配置以避免让用户等待。你延长了冷却时间，因为缩减得太快会在下一个峰值时产生疼痛。应用程序开始围绕一个问题积累复杂性：让模型准备好足够快地服务流量。在 Cerebrium，我们从第一天起就一直致力于解决冷启动问题。这种痴迷促使我们重新思考基础设施的几乎每一层： 用于更快节点扩展的自定义虚拟机映像 用于亚秒级容器映像冷启动的自定义映像运行时 用于跨区域和云路由工作负载的高可用、低延迟协调器 用于在几秒钟内恢复完全预热的容器的 CPU 和 GPU 内存快照 随着越来越多的公司将大型自定义 AI 模型投入生产，他们遇到了同样的问题。我们的客户运行大型语言模型、实时化身、转录模型、扩散模型和其他 GPU 密集型工作负载，其中启动时间可能从几秒到五分钟以上不等。大部分时间都花在让容器准备好服务请求的工作上：导入库、加载模型权重、初始化 CUDA、编译内核以及预热运行时。这就是检查点解决的核心问题。我们不是每次新容器启动时都从头开始重建相同的运行时，而是对完全初始化的容器（包括 CPU 内存、GPU 内存、进程状态、模型权重和编译内核）进行快照，并在很短的时间内将其直接恢复到新容器中。对于某些工作负载，这可以将冷启动时间减少 80% 以上！这篇文章解释了我们如何在 Cerebrium 中构建 CPU 和 GPU 内存检查点、它如何在我们高度定制的基于 gVisor 的运行时中工作，以及如何使 vLLM 等真正的 CUDA 工作负载可靠且快速地恢复。分钟实际上去了哪里？人们很容易将冷启动视为简单的“拉取映像”：将应用程序映像下载到将运行容器的计算机上。但对于人工智能工作负载来说，这只是让模型准备好服务流量的第一步，它不再是瓶颈。我们已经解决了容器下载问题。 CPU 或 GPU 容器的实际成本是图像位于计算机上并且应用程序开始初始化之后发生的所有事情。该初始化路径包括导入 Python 模块、加载 PyTorch、组装模型权重、将它们复制到 GPU 上以及运行框架的预热路径 - torch.compile、CUDA 图形捕获、KV 缓存初始化以及服务堆栈在获取流量之前所需的任何其他内容。这些阶段中的每一个阶段都是确定性的。每次导入 PyTorch 都会生成相同的加载模块。构建模型并将权重复制到 GPU 上每次都会在 GPU 内存中产生相同的字节。 torch.compile 和 CUDA 图形捕获每次都会生成相同的内核。然而，在每次扩大规模时，我们都会付费重新计算已知的结果。这就是检查点所改变的。这个想法很简单：执行一次昂贵的启动工作，冻结结果，并根据需要恢复它。具体来说，采取检查点意味着： 暂停执行：暂停所有应用程序进程、线程，最重要的是暂停 GPU 工作。转储内存：将内存中的状态从 CPU 和 GPU 序列化到文件。上传：将这些文件推送到快速、持久的存储中。恢复以相反的方式运行相同的过程。我们将检查点文件拉下来，补充 CPU 和 GPU 内存，修复无法在移动中幸存的状态片段，并取消暂停工作负载。恢复的应用程序进程与我们之前冻结的预热运行时相同：PyTorch 已导入，模型权重已驻留在 GPU 上，内核已编译，并且应用程序已准备好提供流量。心智模型很简单。使其能够可靠地处理真实的 GPU 工作负载则不然。高层架构 在高层，检查点需要位于一个可以控制容器整个生命周期的位置：在容器运行时和运行工作负载的沙箱之间。 Cerebrium 在 gVisor 沙箱内运行用户工作负载以进行隔离。为了支持检查点，我们扩展了该运行时路径，以便当容器启动时，我们可以在正常启动序列完成之前做出决定：该容器应该从头开始，还是应该从检查点恢复？如果不存在检查点，容器将遵循正常路径。映像启动、应用程序启动、模型加载、GPU 内存填充、工作负载准备就绪。一旦容器完全变暖，用户就可以触发检查点。此时，我们暂停工作负载，捕获其 CPU 并