Faster LLM inference startup: What you need to know
Baofa Fan, DaoCloud / CNCF · 2026-11-06

启动一个容器不等于增加了可服务容量。模型权重加载之后，推理实例还可能需要初始化通信、编译 kernel、自动调优和捕获 CUDA Graph。CNCF / DaoCloud 的这篇技术综述按“保住哪一层状态”梳理快速启动，最有用的地方是把相似名称背后的恢复边界讲清楚。

不同缓存消除的是不同启动步骤

本地模型文件缓存避免重复下载，却仍要读取权重、构造 tensor、进行量化格式转换。编译和 autotune 缓存复用已有产物，但通常不能替代进程初始化或图捕获。预加载权重进一步保存处理后的 GPU tensor；热实例保留活着的引擎；快照尝试保存已初始化的执行状态。

这些路径可以组合，但不能互相代指。若存储已经足够快，优化加载可能只把剩余瓶颈移到 Python 导入、通信初始化或 graph capture。评估启动收益必须看恢复后何时真的能生成，而不是仅看进程出现或模型文件可见。

权重 daemon 与 sleep/wake 的生命周期不同

vLLM 的 Fast Start 用持久权重 daemon 加载、处理并持有 GPU 权重，通过 CUDA IPC 交给兼容的新引擎。zero-copy 模式映射原有分配，daemon 因而必须比使用它的引擎活得更久；配置不匹配时可回退普通加载。CUDA IPC 是节点本地能力，多节点需要各节点保有相应分片，不能把一个句柄当成集群远程缓存。

SGLang 也已合入权重缓存 daemon，Fast Engine Recovery 的其他模型覆盖、内存传输和生命周期工作仍在路线图中。共同点是将权重所有权从一次引擎启动中分离，却没有自动保存其余初始化过程。

sleep/wake 则保持服务器进程存活，释放再恢复部分 GPU 资源。文章提醒 vLLM preload 的 zero-copy 路径与 sleep 权重卸载存在组合限制。它们都追求快速恢复，但资源由谁拥有、释放是否允许，决定了能否同时使用。

快照保存初始化，也带来严格兼容条件

vLLM 已合入的实验性初始化快照采用 CRIU 和 CUDA checkpoint，文中支持范围是同机器、兼容环境、单 NVIDIA GPU、TP=1。捕获前释放权重和 KV，恢复时重新加载，因此快照不包含所有服务依赖，模型文件仍要可用；恢复还会核对一段生成结果。

SGLang 的初始化快照在该文中仍是 RFC 和开放 PR，不能写成已发布的同等能力。外部 checkpoint orchestrator 提案则尝试划清职责：节点组件负责捕获和存储，推理引擎负责确认请求、缓存和通信状态何时安全。

独立的 Snapshot 项目由 operator 和 node agent 协调 Kubernetes GPU 工作负载的捕获恢复；Dynamo 将其集成进服务流程。文章所述存储路径是共享 PVC，对象存储仍属未来方向。Dynamo v1.4.0 的文档还明确把 GMS 与 Snapshot 的组合标为禁用且不支持生产，不能从两个功能各自存在推导出组合已成熟。

平台工作流与标准化进度要分开看

llm-d 的 GKE Pod Snapshots 使用 gVisor 和云存储，与 CRIU 路径并非相同快照格式。Fast Model Actuation 可以唤醒匹配的睡眠实例，或通过预导入 Python 的 launcher 缩短启动；ModelExpress 则经 NIXL/RDMA 从种子副本分发权重，接收端仍要完成其他初始化。

Kubernetes 的 Pod 级 checkpoint/restore、GPU 状态提案、容器运行时实现与 OCI 制品封装也处在不同阶段。原文区分了已合入的 CRI 接口、仍开放的实现和目标版本。能把快照上传 registry，并不意味着跨运行时、跨驱动或跨 GPU 可以恢复。

这篇文章提供的是机制与状态清单，没有统一工作负载上的恢复时间对照。它适合作为故障恢复设计的入口：先确定需要跨越的是引擎重启、资源释放还是 Pod 重建，再检查对应机制保留的状态、仍需加载的依赖以及当前版本的兼容范围。