SGLang亚秒级引擎恢复：权重缓存守护进程

SGLang亚秒级引擎恢复：权重缓存守护进程 | 前端进阶之旅

Full translation

完整中文译文

核心思想：通过 CUDA IPC 实现持久化权重缓存

零拷贝加载（Meta Device）

配置校验：安全优先

三种模式：daemon、client 和 off

安全与健壮性

超越重启：生产场景

多实例权重共享

主备故障切换

权重加载：磁盘 vs IPC 零拷贝

启动 Weight Cache Daemon — 单节点

启动 Engine 并启用 Weight Cache

启动 Weight Cache Daemon — 多节点

快速 Engine 恢复框架：路线图

如今，最先进（SOTA）模型越来越大，重载模型服务（ crash 后）的代价非常高。因此，我们推出了 Weight Cache Daemon——一个持久的 GPU 进程，将量化后的模型权重保存在 GPU 内存中，并通过 CUDA IPC 零拷贝映射为新的 SGLang engine 实例提供服务。这将权重加载时间从分钟级缩短到秒级。

Weight Cache Daemon 是快速 Engine 恢复框架的第一阶段，目标是为生产环境 LLM 服务实现冷启动 < 10 秒、热备切换 < 1 秒。

权重加载：约 495 秒 → 约 0.63 秒——基于 Ling-2.6-1T FP8 模型，加速约 785 倍。

总启动时间：8.8 分钟 → 0.528 分钟——端到端引擎启动时间减少 93.9%。

多实例权重共享——同一 GPU 上的多个 engine 实例映射到相同的 IPC 句柄，消除冗余磁盘 I/O 和后量化变换。

主备故障切换 < 1 秒——备机引擎通过零拷贝共享权重，实现近零停机故障切换，无需为闲置副本预留完整 GPU。

多节点实例权重共享——支持大模型的多节点模式

随着 LLM 模型越来越大——Qwen3-235B、Ling-2.6-1T 以及新发布的 2.8T Kimi K3——服务引擎的冷启动时间已成为生产效率的关键瓶颈。在 8×H20-3e GPU 上，一个 Ling-2.6-1T FP8 实例仅就绪就需要约 8.52 分钟，权重存储在 3.5T NVME SSD 中。在生产环境中，这意味着：

重启期间 P99 尾延迟飙升——所有进行中的请求失败或无限排队。

可用性降低——数分钟的恢复窗口违反 SLA 目标。

运维摩擦——滚动更新、配置变更和故障恢复都受制于重启周期。

GPU 资源浪费——传统的主动-备机部署需要为闲置副本预留完整 GPU，翻倍了硬件成本用于故障切换。

时间都花在哪了？我们对 Ling-2.6-1T FP8 的完整 SGLang 引擎启动过程做了性能分析：

瓶颈很清晰：从磁盘加载权重占总启动时间的 93.2%。对于 Ling-2.6-1T FP8 模型，每个 TP rank 需要从磁盘读取约 120GB 的 safetensors、反序列化、应用 TP 分片、运行后量化变换（FP8 量化、权重重打包）。每次重启都会重复完全相同的工作，尽管得到的 GPU tensor 是确定性的，且往往已经存在于 GPU 内存中。

能否避免每次都从磁盘重新加载？答案是肯定的——通过在引擎重启之间保持 GPU 内存中的权重。

核心思想：通过 CUDA IPC 实现持久化权重缓存

Weight Cache Daemon 是一个持久的 GPU 进程，将量化后、TP 分片后的权重保存在 GPU 内存中。引擎重启时，新引擎进程通过 CUDA IPC 零拷贝映射权重——无磁盘 I/O、无反序列化、无量化。

每个 GPU 运行一个 daemon 进程处理其 TP rank。daemon 的职责：

从磁盘加载模型权重（完整流水线：磁盘 → TP 分片 → 量化 → 重打包）。

将 model.state_dict() 中的每个参数和缓冲区导出为 CUDA IPC 句柄。

记录 CacheConfig 指纹（模型路径、TP/DP 大小、量化配置哈希、dtype）。

通过 Unix socket 向请求的引擎进程提供 IPC 句柄。

引擎连接到 daemon、校验配置兼容性，然后将权重直接映射到自己的地址空间——引擎和 daemon 通过 CUDA IPC 共享同一块物理 GPU 内存。

零拷贝加载（Meta Device）

实现亚秒级加载的关键是零拷贝：引擎的 param.data 指针直接指向 IPC 映射的 GPU tensor，不发生任何数据拷贝。

实现方式：引擎先在 meta device 上初始化模型（不分配 GPU/CPU 内存），然后将每个参数的数据指针替换为 IPC 映射的 tensor。

process_weights_after_loading() 产生的后量化参数（如 FP8 量化的 weight_scale）也由 daemon 缓存并直接映射——无需重新量化。

配置校验：安全优先

引擎配置与 daemon 缓存配置之间的任何不匹配都会触发完整的磁盘重新加载，确保正确性：

最后两个字段组成环境戳：daemon 和 client 若运行了不同的后处理分支（不同的 compute capability 或 torch/kernel 版本），可能产生通过 IPC 映射但实际是垃圾数据的权重——将环境信息打入 CacheConfig 可以将这种情况转为干净的不匹配。

这对生产安全至关重要：若运维人员更改了模型或量化配置，引擎会检测到不匹配并回退到磁盘加载，而非映射不兼容的权重。

在配置校验之上，量化方法还受 IPC 白名单控制。CUDA IPC 零拷贝仅导出原始 tensor 数据，因此只有当 process_weights_after_loading() 的全部效果都被该数据捕获时才是正确的。某些方法在 Python 侧记录元数据或对权重进行重打包/转置（per-tensor FP8、Marlin、AWQ/GPTQ），若使用这些方法会静默产生错误的数值——它们会抛出硬错误而非静默出错。目前已验证支持：无量化以及 block-wise FP8（设置了 weight_block_size）；更多方法将在端到端验证完成后陆续加入。

三种模式：daemon、client 和 off

daemon 模式下，引擎在启动期间派生 daemon 进程并等待它们从磁盘加载权重。首次启动仍然较慢（daemon 必须从磁盘加载），但后续重启是瞬时的。

client 模式下，引擎连接到已运行的 daemon。这是快速重启路径——daemon 之前已启动并在 GPU 内存中持有权重。

安全与健壮性

Weight Cache Daemon 的设计是非侵入性和安全的：

最小侵入性：该功能独立在 python/sglang/srt/weight_cache/ 中，对核心引擎的改动极小（仅 load_model() 分发和一个 CLI flag）。

崩溃安全：若 daemon 崩溃，现有引擎实例继续运行——它们已通过 CUDA 引用计数持有 IPC 映射 tensor 的引用。只有当 daemon 和引擎同时退出时，GPU 内存才会被释放。

Daemon 恢复：若 daemon 重启，它会从磁盘重新加载权重并重新导出 IPC 句柄。新的引擎实例随后可以连接到重启后的 daemon。

不匹配时回退：配置不匹配自动回退到磁盘加载（client 模式下）或抛出错误（daemon 模式下，因为回退会导致两个进程共享同一 GPU 而 OOM）。

超越重启：生产场景

Weight Cache Daemon 解锁了传统基于磁盘加载无法实现的生产模式：

多实例权重共享

每个 GPU 的单一 daemon 将权重保存在内存中；多个引擎实例（如独立服务）通过零拷贝映射到相同的 IPC 句柄。无论多少实例消费这些权重，每个 GPU 只需从磁盘加载和量化一次。

在同一 GPU 上运行高优先级在线服务和低优先级批处理任务，二者共用同一个 weight cache daemon。低优先级实例可以被驱逐并在亚秒级时间内重新生成，无需从磁盘重新加载权重——实现了灵活的 GPU 时间共享，而无需承担通常的启动代价。

主备故障切换

在primary旁部署一台 standby 引擎，二者共用同一个 weight cache daemon。Standby 通过零拷贝映射权重并保持热备。当 primary 故障时，standby 在 < 1 秒内接管——无需权重加载、无磁盘 I/O。

这实现了近零停机故障切换，无需为闲置副本预留完整 GPU，避免了传统热备部署中昂贵的 GPU 资源浪费。

权重加载：磁盘 vs IPC 零拷贝

启动 Weight Cache Daemon — 单节点

一条命令启动所有 TP rank 的 daemon：

# Standalone daemon launch (one command for all TP ranks):
python -m sglang.srt.weight_cache.daemon \
    --model-path /path/to/model --tp-size 4 \
    --load-format auto --dtype auto --quantization fp8

等待 daemon 就绪（每个 rank 会写入一个 .ready 文件）：

# Check readiness:
ls /tmp/sglang_weight_cache_rank*.ready

启动 Engine 并启用 Weight Cache

# Engine Client — connect to pre-running daemons (restart)
python -m sglang.launch_server \
    --model-path /path/to/model --tp-size 4 \
    --weight-cache-mode client

启动 Weight Cache Daemon — 多节点

在多节点部署中，每个节点为自己的本地 TP rank 运行 daemon。所有 daemon 加入同一个分布式组，因此 --nnodes、--node-rank 和 --dist-init-method 必须在节点间保持一致，$MASTER_ADDR 指向节点 0：

# Daemon on node 0:
python -m sglang.srt.weight_cache.daemon \
    --model-path /path/to/model --tp-size 2 \
    --load-format auto --dtype auto --quantization fp8 \
    --nnodes 2 --node-rank 0 \
    --dist-init-method tcp://$MASTER_ADDR:29500

# Daemon on node 1:
python -m sglang.srt.weight_cache.daemon \
    --model-path /path/to/model --tp-size 2 \
    --load-format auto --dtype auto --quantization fp8 \
    --nnodes 2 --node-rank 1 \
    --dist-init-method tcp://$MASTER_ADDR:29500

每个节点报告其 daemon 就绪后，启动引擎 client。它们使用独立于 daemon（29500）的 rendezvous 端口（29600）：

# Engine client on node 0:
python -m sglang.launch_server \
    --model-path /path/to/model --tp-size 2 \
    --weight-cache-mode client \
    --nnodes 2 --node-rank 0 \
    --dist-init-addr $MASTER_ADDR:29600 --port 34000

# Engine client on node 1:
python -m sglang.launch_server \
    --model-path /path/to/model --tp-size 2 \
    --weight-cache-mode client \
    --nnodes 2 --node-rank 1 \
    --dist-init-addr $MASTER_ADDR:29600

快速 Engine 恢复框架：路线图

Weight Cache Daemon 是更广泛快速恢复框架的第一阶段，目标实现冷启动 < 10 秒、热备切换 < 1 秒：

更多模型支持也在路上。

Weight Cache Daemon 只是第一步——还有很多需要建设，我们对未来的路线感到兴奋。第一阶段目前覆盖 TP + PP、单节点和多节点启动、每 GPU 零拷贝 CUDA IPC 以及无量化和 block-wise FP8。在此之外，许多高影响力的方向仍待探索：

更多模型和量化：将 IPC 白名单扩展到 block-wise FP8 之外（per-tensor FP8、INT8、MXFP8、NVFP4、AWQ/GPTQ 等），并覆盖更多架构，包括多模态和 LoRA 基础权重。

DP/EP 与多节点：DP/EP 分片键控和跨节点 daemon 协调、生命周期管理及故障切换。

无需重载的权重更新：原地权重刷新用于 RL/在线更新，以 daemon 作为传输媒介。

跨 GPU 和集群共享：peer-copy 和 fleet-fill，使集群冷启动每个分片组只需约一次磁盘读取。

KV 缓存恢复：在重启/故障切换之间保留和重映射 KV 缓存（KV 复用、交接给备机），使进行中的上下文在恢复后存活而非从头重新计算。

启动路径其余部分：CUDA graph 序列化、内核预热持久化、更快的 server/分布式初始化，以达到 < 10 秒冷启动目标。

其他硬件后端：将此功能扩展到其他提供类似功能的加速器（AMD 和 Intel 都有可比的 IPC 机制）。

运维与可靠性：指标、状态工具、安全加固和 CI 覆盖。

这非常需要社区共同参与。完整计划在 sgl-project/sglang#33522 公开追踪——非常欢迎贡献和反馈，有很多有影响力的工作等待认领。

Ant Ling Infra Team, Ant Group: Michael Qiu qiudayu.qdy@antgroup.com

Alibaba: Siyu Liu liusy58@smail.nju.edu.cn

SGLang Team: Alex Nails