LLM 推理服务启动慢，社区从权重复用与预热实例等多层面优化

增加一个推理副本，只有在新实例能够处理请求之后才会真正形成容量。从启动进程到生成响应之间，LLM 服务器可能需要加载权重、初始化 GPU 资源、编译 kernel、捕获执行图，以及预热引擎。重启、切换模型和横向扩容都会重复这些工作。

社区正在多个层面解决这些开销。vLLM 和 SGLang 正在开发复用权重和已初始化状态的方法。服务平台上在围绕热实例和快照构建工作流。Kubernetes、容器运行时和 Open Container Initiative（OCI）正在研究相关接口和制品问题。

这些工作的边界各不相同，也在各自独立推进。理解每种方法保留了哪些状态，有助于解释它的收益和当前适用范围。

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

一次典型的启动包含几类工作。服务器启动进程并导入库。它读取模型文件、构造张量，并执行所需的权重变换。它初始化执行运行时和 worker 之间的通信，分配内存，并准备好引擎以提供服务。

有些工作是为了提升后续推理性能而专门进行的。编译会生成可执行的 kernel；自动调优会为某个配置选择实现。CUDA Graph 捕获会记录 GPU 操作，以便之后以更低的启动开销重放。vLLM 的优化文档描述了启动工作与稳态执行性能之间的权衡。

这种平衡取决于模型、软件、硬件和存储。一旦模型文件在本地缓存，引擎初始化就可能变得更加显眼。一旦权重可以在 GPU 内存中复用，导入、调优和图捕获就可能占据剩余延迟中更大的部分。

哪些可以复用而不是重建

启动优化可以按它们保留的工作来分组：

这些方法可以在一个系统中同时出现，集成条件因具体实现而异。例如，引擎可以在通过专用加载器加载权重的同时复用编译产物。快照工作流可能会在捕获前丢弃空的 key/value（KV）缓存，并在恢复后重新创建它。该缓存保存处理 token 时计算出的 attention 状态。

高效加载仍然是一个独立的工作领域。SGLang 文档介绍了 pre-sharded state、fastsafetensors 和流式加载器等加载器。llm-d 文档介绍了模型文件缓存以及其他启动路径。这些机制影响权重如何到达引擎；它们保留的状态不同于已初始化进程快照所保留的状态。参见 SGLang 模型加载、llm-d 启动概览。

vLLM 和 SGLang 在做什么

vLLM

vLLM 的 Fast Start 工作以持久化权重守护进程为核心。它加载并处理权重，将生成的张量保存在 GPU 内存中，并通过 CUDA 进程间通信将它们暴露给兼容的引擎。权重守护进程实现和 vllm preload 命令已经合并。当前的 preload 文档还描述了在引擎启动前准备 FlashInfer 自动调优结果。参见 Fast Start 实现、preload 文档。

这将缓存权重的生命周期与引擎重启分离开来。在零拷贝模式下，引擎会映射守护进程已有的分配。配置检查决定复用是否合适，文档所述的路径可以回退到普通加载。在引擎使用其内存期间，守护进程必须保持存活。CUDA IPC 句柄是节点本地的；文档所述的多节点部署会在每个节点本地提供相关分片。

vLLM 还支持睡眠/唤醒，它保留一个运行中的服务器，同时释放其大部分 GPU 内存。这提供了一种不同于针对缓存权重启动新引擎的生命周期。preload 文档指出了其零拷贝模式与通过睡眠模式进行权重卸载相结合时的限制。参见睡眠模式。

另一个已合并的实现增加了实验性的已初始化引擎快照。vllm snapshot 工作流使用 CRIU 来捕获和恢复 Linux 进程状态，并通过 CUDA checkpoint 支持处理 GPU 状态。其文档所述范围要求同一台机器和兼容环境，使用一块 NVIDIA GPU 且张量并行度为 1。它在捕获前释放权重和 KV 状态，并在恢复期间重新加载它们，从而保留对模型文件的依赖。恢复时还会检查记录的生成结果。参见已初始化引擎快照。

SGLang

SGLang 已合并一个权重缓存守护进程，它保存已处理的权重，并通过 CUDA IPC 与新的引擎实例共享它们。其 Fast Engine Recovery 路线图讨论了扩展这一基础，包括更广泛的模型和量化覆盖、内存传输、守护进程生命周期以及剩余的初始化开销。该路线图描述了已合并初始实现之外的方向。参见权重缓存实现、Fast Engine Recovery 路线图。

（原文较长，此处译出前 6000 字，完整内容请点「打开原文」。）