通过内存快照减少GPU冷启动：在几秒钟内恢复CUDA工作负载 如果您在生产中运行AI模型，无论您愿不愿意，您都与冷启动有着某种关系。三分钟的启动时间改变了您的扩展方式。您保持温暖的GPU可能已经释放。您过度配置以避免用户等待。您延长冷却周期，因为过快地缩减会在下一个峰值时造成痛苦。应用程序开始围绕一个问题积累复杂性：快速准备好为流量服务的模型。在Cerebrium，我们从第一天起就对冷启动问题感到痴迷。这个痴迷驱使我们重新思考基础设施的几乎每个层面： 自定义VM镜像以实现更快速的节点扩展 自定义镜像运行时以实现亚秒级的容器镜像冷启动 高可用、低延迟的调度器，用于跨区域和云路由工作负载 CPU和GPU内存快照，用于在几秒内恢复完全预热的容器 随着越来越多的公司将大型自定义AI模型投入生产，他们碰到了同样的墙。我们的客户运行大型语言模型、实时化身、转录模型、扩散模型以及其他GPU密集型工作负载，启动时间可能从几秒钟到五分钟以上。大部分时间都花在使容器准备好服务请求的工作上：导入库、加载模型权重、初始化CUDA、编译内核和预热运行时。这是检查点解决的核心问题。与其每次新容器启动时从头构建相同的运行时，不如将完全初始化的容器快照（包括CPU内存、GPU内存、进程状态、模型权重和编译的内核），并在短时间内直接恢复到新容器中。对于某些工作负载，这减少了超过80%的冷启动时间！ 这篇文章解释了我们在Cerebrium如何构建CPU和GPU内存检查点，它在我们高度定制的基于gVisor的运行时内如何工作，以及使真实的CUDA工作负载（如vLLM）可靠且快速恢复所需的条件。分钟到底用在哪里？ 很容易认为冷启动仅仅是“拉取镜像”：将应用程序镜像下载到将运行容器的机器上。但对于AI工作负载而言，这只是让模型准备好服务流量的第一部分，并不再是瓶颈。我们已经解决了容器下载问题。 在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和