利用GPU快照减少gVisor冷启动时间

在GPU加速的AI推理场景中，容器冷启动是一个显著的瓶颈。初始化过程通常包括导入Python模块、加载PyTorch、组装模型权重并复制到GPU、运行框架预热路径（如torch.compile、CUDA图捕获、KV缓存初始化）等步骤。每一个阶段都是确定性的：相同的输入每次产生相同的输出。然而，每次扩容时，系统都在重复计算已知的结果。

Cerebrium提出的解决方案是GPU内存快照（checkpointing）。其核心思想很简单：执行一次昂贵的启动工作，将结果冻结，然后在需要时按需恢复。具体操作包括：暂停所有应用进程和GPU工作，将CPU和GPU内存状态序列化到文件，并将文件上传到快速持久化存储。恢复则是逆向过程：下载检查点文件，重新填充CPU和GPU内存，修复无法在迁移中存活的状态，然后解冻工作负载。恢复后的应用进程与之前冻结的运行时完全相同：PyTorch已导入、模型权重已在GPU上、内核已编译，准备直接处理流量。

为了实现这一功能，Cerebrium在容器运行时和运行工作负载的沙箱之间进行了扩展。他们添加了两个组件：一个运行在每个主机上的小型检查点服务，负责下载、上传、缓存和驱逐检查点；一个修改后的gVisor containerd shim，它拦截容器创建过程，检查是否可以恢复检查点，并选择正常启动或恢复路径。

关键的技术挑战在于时序。containerd启动沙箱的固定序列是：Sandbox Create → Sandbox Start → Container Create → Container Start。自然的选择是在Sandbox Start时决定是否恢复，但此时还无法获得容器镜像信息。Cerebrium重新排序了启动序列：在Sandbox Start时延迟实际启动，直到Container Create阶段获取镜像信息后，再决定是正常启动还是恢复检查点。这个小的调整使得检查点功能对用户透明。

在开发和测试中，团队遇到了许多边缘情况。包括：检查点期间TCP网络栈的竞态条件导致网络中断；如果检查点耗时超过几秒，containerd内的gVisor会崩溃；需要支持NVIDIA GPU的容器设备接口注入；以及检查点分发依赖存储层性能。

存储和网络路径是整个系统最重要的设计决策。对于一个9 GiB的检查点，在g5.12xlarge实例上，完整的vLLM冷启动约需50秒，而恢复检查点只需2.25秒（从S3）或9秒（本地NVMe）。S3作为默认恢复路径，因为速度足够且跨云和区域可移植。

实际工作负载并非总能完美适应快照。网络状态是一个明显的例子：恢复后TCP连接已终止，容器可能分配了不同的外部IP，这会破坏依赖外部IP进行通信的框架（如vLLM）。解决方法是使用VLLM_HOST_IP=127.0.0.1将内部通信绑定到回环地址。

多进程是另一个问题：Python框架使用fork创建GPU工作进程时，会继承父进程的NVIDIA驱动文件描述符，导致检查点系统难以判断哪些进程真正拥有GPU状态。解决方案是使用spawn方式创建进程（VLLM_WORKER_MULTIPROC_METHOD=spawn）。

本地运行时文件（Unix套接字、临时文件、锁文件）如果未在检查点中保留，恢复后进程可能因找不到文件而失败。vLLM通过VLLM_RPC_BASE_PATH=/run/cuda-ckpt将关键RPC状态保存在一个保留路径中。

检查点的时机也很重要：需要在CUDA工作完成、应用处于已知空闲状态时进行。vLLM的睡眠模式可以在检查点前丢弃KV缓存等瞬时状态，减小快照大小并提高恢复性能。用户可选择是否保留这些状态。

最后，GPU内存检查点与创建时的环境紧密绑定：GPU类型、CPU架构、机器类型、驱动/运行时兼容性、gVisor版本都必须匹配。因此，检查点按兼容性键控，而非仅按应用键控。

总之，GPU内存检查点不仅仅是“转储内存并重新加载”，而是需要仔细分离可冻结的状态与必须重新创建、重新连接或迁移的状态。Cerebrium的实践表明，通过精心设计，这项技术能够显著减少GPU容器的冷启动时间，为AI推理带来更快的弹性伸缩能力。