加速大模型推理服务启动：你需要了解的关键要点
内容提要
大模型推理服务启动需加载权重、初始化GPU、编译内核并捕获计算图，耗时显著。vLLM和SGLang通过权重守护进程、持久缓存、休眠唤醒及快照复用已初始化状态来优化；平台层如Snapshot、Dynamo、llm-d构建预热实例与快照工作流；Kubernetes、CRI和OCI推进Pod级检查点、恢复接口及制品打包，但GPU状态、跨节点恢复和兼容性仍受限。
延伸解读
启动耗时为何难以消除
文章指出，推理服务启动不只是加载权重，还包括初始化GPU、编译内核、自动调优和捕获CUDA Graph等步骤。这些工作虽拖慢启动，却直接提升稳态推理性能，因此不能简单跳过。当模型文件已本地缓存、权重可在GPU内存复用时，导入、调优和图捕获反而成为剩余延迟的主要来源。读者应把启动优化理解为“保留哪些已初始化状态”的问题，而非单纯加快文件读取。
不同复用机制边界各异
文章按可复用对象区分了多种路径：预暂存模型文件、持久化编译与调优缓存、权重守护进程、休眠唤醒、以及引擎或容器快照。它们保留的状态不同，集成条件也不同。例如vLLM零拷贝预加载依赖同节点CUDA IPC，休眠模式与零拷贝组合存在限制；快照方案则需在捕获前释放权重和KV缓存。理解每种机制保留什么、仍依赖什么，比比较单一启动数字更有意义。
平台工作流不等于统一标准
Snapshot、Dynamo、llm-d等平台把底层机制组织成预热实例和快照工作流，但实现路径并不一致：有的基于CRIU，有的依赖gVisor沙箱检查点，有的通过唤醒休眠实例或从种子副本传输权重。文章还提醒，Dynamo某版本的GMS加Snapshot被明确标为禁用且不支持生产，vLLM示例也仅验证特定版本。读者需按版本和具体集成阅读，不能把高层流程相似当作检查点格式或API兼容。
Kubernetes与OCI仍在推进中
平台层进展并不均衡。容器检查点已随KEP-2008进入beta，Pod级检查点KEP-5823标记为可实现并设v1.38 alpha目标，但初始范围排除设备状态和跨节点恢复；GPU支持另有暂定提案且PR未合并。CRI的CheckpointPod和RestorePod接口已合并，但Kubernetes、containerd和CRI-O实现PR仍未完成。OCI可承载检查点制品，却未定义执行状态语义，通用检查点镜像提案也仍开放。
Q&A
为什么大模型推理服务启动这么慢？主要耗时在哪些环节？
启动通常包括：启动进程并导入库；读取模型文件、构建张量并做权重转换；初始化执行运行时和worker间通信、分配内存；以及为提升后续推理性能而做的编译内核、自动调优和CUDA Graph捕获。模型文件本地缓存后，引擎初始化会更突出；权重可复用后，导入、调优和图捕获可能占剩余延迟的更大比例。
vLLM和SGLang分别用什么方式复用权重、减少重复启动开销？
vLLM的Fast Start围绕持久权重守护进程：加载并处理权重，将张量保留在GPU内存，通过CUDA IPC暴露给兼容引擎；零拷贝模式下引擎映射守护进程已有分配，并有回退普通加载的路径。SGLang已合并权重缓存守护进程，通过CUDA IPC与新引擎实例共享已处理权重，并规划扩展模型/量化覆盖、内存传输和守护进程生命周期。
vLLM和SGLang的初始化引擎快照目前支持哪些场景，有什么限制？
vLLM已合并实验性初始化引擎快照，用CRIU捕获/恢复Linux进程状态，CUDA checkpoint处理GPU状态；文档范围要求同一机器、兼容环境、单NVIDIA GPU且张量并行度为1，捕获前释放权重和KV状态、恢复时重新加载，并校验生成结果。SGLang的RFC/PR提议在初始化后、HTTP服务绑定前捕获，初始范围同样是单NVIDIA GPU、张量并行度1、同主机同软件环境，模型权重仍外部保存并在恢复后重载。
平台层（Snapshot、Dynamo、llm-d）如何把快照和预热实例变成启动工作流？
Snapshot项目提供Kubernetes上GPU工作负载的检查点/恢复原语，由operator和节点代理协调CRIU与CUDA checkpoint，资源如PodSnapshot、SnapshotJob，存储当前用PVC。Dynamo把原语集成进服务流程，其v1.4.0文档明确GMS+Snapshot被禁用、不支持生产。llm-d的Pod Snapshots指南覆盖单GPU vLLM/SGLang，使用GKE Pod Snapshots、基于gVisor的GKE Sandbox和云存储；另有Fast Model Actuation唤醒休眠实例或经已加载模块的launcher启动，以及ModelExpress用NIXL/RDMA从种子副本传权重。
Kubernetes、CRI和OCI在Pod级检查点与恢复上进展到哪一步？
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为草案。OCI方面，镜像规范支持通用制品、分发规范提供注册表传输和referrers，可承载检查点载荷但不定义执行状态语义；检查点专用OCI镜像提案issue #962仍开放。
使用快照或权重复用方案时，有哪些兼容性和恢复风险需要注意？
恢复受硬件、驱动、运行时和工作负载兼容性约束；CUDA IPC句柄仅限本节点，多节点需各节点本地提供相关分片；守护进程在使用其内存期间必须存活。vLLM零拷贝模式与sleep模式的权重卸载存在组合限制。示例集成有版本边界，如vLLM指南在v0.27.1验证且明确不适用于v0.28。仅注册表存储不能保证跨运行时或GPU环境的恢复兼容。快照生命周期还缺少统一协议，应用如何报告可安全捕获、如何得知恢复完成仍在提案中。
