LLM 推理启动加速：vLLM 权重复用、SGLang 快照与 Kubernetes 检查点

原文信息：本文译自 CNCF 博客《Faster LLM inference startup: What you need to know》，作者 Baofa Fan（DaoCloud），发布于 2026 年 11 月 6 日。原文链接：https://www.cncf.io/blog/2026/11/06/faster-llm-inference-startup-what-you-need-to-know/ 。原文采用 CC BY 4.0 许可。本文为翻译，译者在文末补充了译者注；原文配图请见原文链接。

译者导语：大模型推理服务扩容时，多一个副本不等于马上多一份算力——新实例要先加载权重、初始化 GPU、编译内核、预热引擎，才能开始接请求。这篇文章把 vLLM、SGLang、llm-d 和 Kubernetes 各自在做的启动加速办法摊开讲清楚：每种办法到底保留了什么、还剩哪些工作、适用边界在哪。如果你之前读过本站 11 月 2 日那篇 vLLM 休眠省显存的文章，这篇是同一条链路的另一端：那篇讲“怎么让活着的引擎少占显存”，这篇讲“怎么让新的引擎更快活过来”。

推理服务器启动为什么花时间

一次典型的启动要做好几类工作。服务器先启动进程、导入库，然后读模型文件、构建张量、做必要的权重转换，再初始化执行运行时和各工作进程之间的通信，分配内存，让引擎做好服务准备。

其中一部分工作专门是为了让之后的推理跑得更快。编译会产出可执行的内核；自动调优（autotuning）会给当前配置挑一种实现；CUDA Graph 捕获会把 GPU 操作记录下来，后面重放时启动开销更低。vLLM 的优化文档里讲过启动工作和稳态执行性能之间的这种取舍。

具体哪部分占大头，取决于模型、软件、硬件和存储。模型文件已经缓存在本地之后，引擎初始化可能变得更显眼；权重已经能在 GPU 显存里复用之后，导入、调优和图捕获可能占去剩下的大部分延迟。

哪些东西可以复用，不必重建

启动优化可以按“保留了什么工作”来分组：

这些办法可以出现在同一个系统里，具体怎么组合取决于各自的实现条件。比如一个引擎可以一边复用编译产物，一边用专门的加载器加载权重；一个快照流程可以在捕获前丢掉空的键值（KV）缓存，恢复后再重建——这个缓存保存的是处理 token 时算出来的注意力状态。

高效加载本身还是一个独立方向。SGLang 的文档里介绍了预分片状态、fastsafetensors 和流式加载器等加载器；llm-d 的文档里在其他启动路径之外也介绍了模型文件缓存。这些机制决定权重怎么到达引擎；它们保留的状态，和一个已初始化进程的快照保留的状态并不相同。

vLLM 和 SGLang 在做什么

vLLM

vLLM 的 Fast Start（快速启动）工作围绕一个常驻的权重守护进程展开。它加载并处理权重，把得到的张量保存在 GPU 显存里，再通过 CUDA 进程间通信（IPC）提供给兼容的引擎使用。权重守护进程的实现和 vllm preload 命令已经合并。当前的 preload 文档里还介绍了在引擎启动前准备好 FlashInfer 自动调优结果的做法。

这样一来，缓存权重的生命周期就和引擎重启分开了。在零拷贝模式下，引擎直接映射守护进程里已有的显存分配。配置检查会判断复用是否合适，文档里也写了可以回退到普通加载。守护进程在引擎使用它的显存期间必须一直活着；CUDA IPC 句柄只在单个节点内有效，多节点部署的文档里要求每个节点本地提供相应的分片。

vLLM 也有休眠/唤醒支持：服务器保持在线，同时释放大部分 GPU 显存。这和“拿缓存权重启动一个新引擎”是不同的生命周期。preload 文档里指出了零拷贝模式和通过休眠做权重卸载不能组合使用的限制。

另外还有一个已合并的实验性功能：已初始化引擎的快照。vllm snapshot 工作流用 CRIU 捕获和恢复 Linux 进程状态，GPU 状态由 CUDA 检查点支持处理。它的文档范围要求同一台机器、兼容的环境、一块 NVIDIA GPU、张量并行度为 1。捕获前会释放权重和 KV 状态，恢复时再重新加载，仍然依赖模型文件。恢复时还会校验一条记录下来的生成结果。

SGLang

SGLang 已经合并了一个权重缓存守护进程：它保存处理过的权重，再通过 CUDA IPC 分享给新的引擎实例。它的 Fast Engine Recovery（快速引擎恢复）路线图讨论了在这个基础上继续扩展，包括更广的模型和量化覆盖、内存传输、守护进程生命周期，以及权重加载之外的初始化成本。路线图讲的是方向，不只是已经合并的初始实现。

SGLang 还提供内存释放/恢复和生成暂停/继续操作，供外部快照集成使用。释放之后权重还在不在，取决于配置的内存策略，包括有没有 CPU 备份。这些操作让集成方可以把引擎准备到可捕获的状态，事后再恢复它；但整个流程的协调工作还是得由外部系统来做。

已初始化引擎的快照是另一个方向。公开的 RFC 和实现 PR 提议在初始化完成、HTTP 服务绑定之前捕获 SGLang。初始范围是一块 NVIDIA GPU、张量并行度为 1、同一台主机和软件环境；模型权重仍然放在外面，恢复后再重新加载。

两个框架也都有公开提案，讲怎么和外部的检查点编排器配合：引擎自己准备好状态、恢复后继续服务，外部系统负责捕获、存储和恢复进程。这些提案针对的是一个实际的边界问题：节点代理可以操作检查点工具，但只有推理引擎自己知道它的请求、缓存和通信资源在什么时候可以安全捕获。

平台怎么把机制变成启动流程

Snapshot 和 Dynamo

ai-dynamo 组织里的独立 Snapshot 项目为 Kubernetes 上的 GPU 工作负载提供检查点和恢复原语。它的 Operator 和节点代理协调 CRIU 和 CUDA 检查点操作，涉及 PodSnapshot 和 SnapshotJob 这类资源。Dynamo 把这些原语集成进自己的服务流程。

Snapshot 的文档存储路径用的是节点代理都能访问的共享持久卷，由代理侧的组件管理产物的移动和恢复访问。目前的存储文档支持通过 Kubernetes PersistentVolumeClaim（PVC）做存储，对象存储后端留待以后。硬件、驱动、运行时和工作负载的兼容性仍然会限制恢复。

框架的示例也展示了应用层要做的工作。SGLang 的示例挂载了一个入口点：先预热引擎，再暂停生成、释放内存，然后发出“可以安全捕获”的信号；恢复后重新恢复内存和生成，校验一次生成结果，再启动 API。vLLM 的指南在 v0.27.1 上验证了自己的入口点，并明确说那个示例在 v0.28 上不可用。这正好说明了这类集成的兼容性边界。

Dynamo 还在开发 GPU Memory Service（GPU 内存服务），把 GPU 显存的所有权移到引擎进程之外。它的集成和快照支持要按版本来看：Dynamo v1.4.0 的 Snapshot 文档明确写着 GMS 加 Snapshot 处于禁用状态，不支持生产使用。

llm-d

llm-d 的文档里介绍了几种启动办法。它的 Pod Snapshots 指南目前覆盖使用 GKE Pod Snapshots、基于 gVisor 的 GKE Sandbox 和 Google Cloud Storage 的单 GPU vLLM 和 SGLang 部署：第一个实例加载并预热模型、准备好显存，然后触发快照；之后兼容的 Pod 恢复这个状态，继续跑框架。指南里说平台无关的 CRIU 后端还在开发中。

这个后端和 Snapshot 的 CRIU 路径并不相同。gVisor 通过自己的检查点机制保存沙箱状态；GKE 的文档里介绍了通过 NVIDIA 检查点支持捕获 GPU 状态。表面上相似的工作流，并不意味着检查点格式或 API 相同。

Fast Model Actuation（快速模型激活，FMA）是另一条路。它用控制器和请求方/启动器 Pod 的组合来管理 vLLM 实例。根据已有的状态和放置情况，它可以唤醒一个休眠的实例，或者通过一个已经加载好 Python 模块的启动器来启动实例。它的热路径取决于把保留下来的实例匹配到指定的 GPU 上。

llm-d 还介绍了 ModelExpress：用 NIXL 和远程直接内存访问（RDMA），通过兼容的网络把权重从一个种子副本传给其他副本。这改变了权重的分发方式，但接收实例的其他引擎启动工作还得自己做。这三条路正好说明：一个平台的启动工作没法用单个检查点功能来概括。

Kubernetes 检查点和恢复做到哪一步了

Kubernetes Checkpoint Restore Working Group（检查点恢复工作组）提供了一个协调用例、API 提案以及和 SIG、运行时集成的地方。它的章程也把检查点归档效率列为值得重新审视的领域。这个工作组的范围是平台编排；推理框架内部的启动机制则由各框架自己继续发展。

Kubernetes 本身已经有了容器检查点能力，相关的 Kubernetes 增强提案 KEP-2008 在 v1.30 进入 Beta。KEP-5823 处理 Pod 级检查点和恢复，已标记为可实施，目标是 v1.38 进入 Alpha——这是一个交付目标。它的初始边界排除了设备状态和跨节点恢复。GPU 支持有另外的临时提案 KEP-6274，相关的增强 PR 仍然开放，讨论设备分配和兼容性。

在容器运行时接口（CRI）这一层有了具体进展：加入 CheckpointPod 和 RestorePod 的 PR 已于 2026 年 7 月 22 日合并。现在的接口描述了一致的捕获、检查点之后的恢复，以及恢复失败时的清理。恢复会在容器开始执行之前先做好准备。Kubernetes 编排层和 containerd 的实现 PR 仍然开放；CRI-O 的实现 PR 还是草稿。

CRI 把检查点文件和它们的布局留给运行时。OCI 处理的是另一个问题：打包和分发。它的镜像规范支持通用产物，发行规范提供注册表传输和引用机制。这些设施可以搬运检查点载荷，但不定义它们的执行状态语义。

针对检查点的 OCI 镜像提案（issue #962）仍然开放。Podman 可以创建检查点镜像，checkpointctl 可以从检查点归档构建 OCI 兼容的镜像，containerd 也有自己的检查点媒体类型。这些都是已有的打包做法，而一个通用的定义提案还没有定论。只用注册表存起来，并不等于跨运行时、跨 GPU 环境都能恢复。

正在探索的方向

路线图里还覆盖了剩下的几项成本。vLLM 的 Fast Start 工作包括权重缓存校验、调优、进程启动、性能分析和图捕获等问题。SGLang 的 Fast Engine Recovery 路线图包括更广的模型覆盖、内存传输、守护进程生命周期，以及权重加载之外的初始化。它们的任务清单讲的是方向；每个具体实现的进度和支持配置要看各自的文档。

快照的生命周期提案也在探索应用怎么报告“可以安全捕获”，以及怎么知道“恢复已经完成”。Snapshot 项目的应用钩子设计讨论了文件、HTTP 和 Unix 信号这几种过渡方式。框架的提案从引擎一侧处理同一个边界。它们的存在，并不等于一个共享协议已经被各方采用。

在平台和运行时层面，正在推进的工作涉及 Pod 和 GPU 的约定、检查点产物和兼容性。对关注这个领域的人来说，有用的问题还是很具体的：保留了哪些工作、哪个组件负责、恢复还要求什么、实现支持哪些环境。

延伸阅读

• vLLM Fast Start 路线图：权重加载之外的方向，包括调优、初始化和校验
• SGLang Fast Engine Recovery 路线图：权重缓存演进和正在讨论的其他启动成本
• vLLM 已初始化引擎快照设计：捕获边界、兼容性检查和恢复校验
• 外部检查点编排 RFC：推理引擎和外部编排器各自的职责划分
• OCI 检查点镜像定义提案：产物布局、元数据和互操作问题
• Kubernetes Checkpoint Restore Working Group：社区范围、会议记录和参与入口

译者注

1. 和 11 月 2 日那篇的区别：那篇讲的是 vLLM 休眠模式怎么省显存——让活着的引擎把显存交出来、需要时再唤醒；这篇讲的是新引擎怎么更快启动——复用权重、缓存调优结果、拍快照恢复。休眠省的是“在线但闲着”的成本，启动加速省的是“扩容和重启时”的等待，两件事合起来才是推理服务的弹性全貌。相关阅读里放了那篇的链接。
2. 落地前先核对版本和边界：快照类功能目前大多还处在实验或受限阶段，常见限制是单 GPU、张量并行度为 1、同一台机器和软件环境；vLLM 的指南明确写着在 v0.27.1 上验证过、在 v0.28 上不可用，Dynamo v1.4.0 的文档也明确说 GMS 加 Snapshot 不支持生产。照着做之前，先按你自己的版本核对一遍文档，别直接照搬。
3. 和华为云的结合点：在华为云 CCE 上扩容推理副本，或者用 ModelArts 跑推理服务时，冷启动时间直接决定了扩容能不能跟上流量尖峰。权重预热、常驻权重守护进程、快照恢复这些思路，对应到平台侧就是模型缓存、热实例池和检查点恢复能力，值得按这个方向继续跟踪。

相关阅读（同方向旧文，纯文本链接）： - vLLM 休眠模式的显存税怎么省：PhOSv1 共享 GPU 上下文，休眠 23 个模型显存降 98.1%：https://bbs.huaweicloud.com/blogs/f9cdf2ddf484453b81398875a93a9a44 - 角色伪造攻击怎么防？Jellyfish v2 用分层记忆保持一致性：https://bbs.huaweicloud.com/blogs/5d6093310de44238b51ad216cc06751f

原文：Faster LLM inference startup: What you need to know，Baofa Fan（DaoCloud），CNCF 博客，2026-11-06，CC BY 4.0 许可。原文链接：https://www.cncf.io/blog/2026/11/06/faster-llm-inference-startup-what-you-need-to-know/