大模型服务最怕什么？不是推理慢，不是显存溢出，而是——重启。你掐着秒表等模型重新加载，五分钟过去，服务还在“Initializing”。用户早跑了。SGLang 团队这次拿出的 Weight Cache Daemon，把模型权重加载从大约 495 秒压到 0.63 秒，785 倍加速，端到端启动时间缩减 93.9%。这不是挤牙膏式的优化，是直接换了一条路。
重启一次要等八分钟？这不是段子
495 秒的折磨
做过大模型线上服务的人都有这种记忆：更新一个配置，滚动重启所有副本，每个副本都在那里吭哧吭哧读权重。一个 70B 的模型，磁盘读出来要几十秒，反量化再花几十秒，分片到多卡又是一轮通信。七七八八加起来，五分钟是常事。495 秒，差不多八分钟，足够让运维同事喝掉两杯咖啡，也足够让 SLA 变成一张废纸。
根子在哪：反量化与分片
问题不在磁盘速度，而在重复劳动。每次启动，引擎都要把原始权重从磁盘读进内存，再做反量化，再做张量分片。这些操作明明在第一次启动时已经做过一遍，偏偏每次重启都要重来。更蠢的是，同一台机器上多个实例各自加载同一份权重，每个人的内存里都放着一份一模一样的拷贝。算力在重复，IO 在重复，等待也在重复。
Weight Cache Daemon 的解法：CUDA IPC 零拷贝
从磁盘到 GPU 显存，数据不再搬家
Weight Cache Daemon 的思路听起来简单：既然权重已经加载过，那就别扔，让它在 GPU 显存里住着。新来的引擎进程不用再去磁盘翻文件，直接通过 CUDA IPC 零拷贝映射，把已有显存地址映射进自己的地址空间。数据不动，指针动。这一下，反量化不用做了，分片不用做了，连 memcpy 都省了。
785 倍加速是怎么算出来的
0.63 秒对 495 秒，不是渐进优化，是量级变化。0.63 秒里大部分时间还是在建立 IPC 映射和同步元数据。真正读权重的时间趋近于零。端到端启动时间减少 93.9%，意味着你的服务滚动更新从此不用再排维护窗口。早上十点发版？可以。双十一峰值前扩容？也可以。只要显存放得下，拉起一个新副本就是眨眼的功夫。
不只是快：多实例共享与亚秒级主备切换
显存里的权重，多个引擎共用
一个常驻的守护进程持有权重，所有工作进程都能共享同一份显存数据。这不光省了加载时间，还省了显存。同一台机器上跑两个推理引擎实例，第一个把权重加载好，第二个直接映射。显存占用从双份变一份，多租户场景下的部署密度立刻上去了。对于需要多副本负载均衡的生产环境，这个特性的价值甚至超过加载速度本身。
故障切换从分钟级到秒级
主备切换是另一个被低估的收益。以前主节点挂了，备用节点要从磁盘冷启动，没有几分钟缓不过来。现在备用节点的权重已经在显存里热着，通过 Weight Cache Daemon 一映射就能接客。亚秒级切换，意味着故障自动恢复不再是“尽量缩短宕机时间”，而是真的可以做到用户无感知。对于追求高可用的大模型 API 服务，这是从“勉强可以用”到“敢签 SLA”的分水岭。
Fast Engine Recovery Framework 的第一阶段，下一步呢？
为什么叫第一阶段的深意
官方说这是 Fast Engine Recovery Framework 的第一阶段，措辞很克制。第一阶段解决权重加载，已经砍掉 93.9% 的启动时间。那剩下的 6.1% 是什么？是 KVCache 重建，是 CUDA context 初始化，是引擎内部状态恢复。这些还没被优化。如果后续阶段把这些也啃掉，启动时间可能真要进入毫秒级。到那时，“重启代价”这个概念在物理上就接近消失了。
对生产环境的实际影响
别小看这个守护进程的工程意义。它把业务服务的生命周期管理从“分钟级预算”拽进了“秒级预算”。这意味着弹性伸缩可以做得更激进，流量高峰来了现开实例也来得及；意味着新版本发布可以更频繁，灰度失败回滚也就是一瞬间的事。SGLang 这一刀切在了大模型部署最疼的地方。那些还在用预加载权重、镜像缓存、自定义快照绕圈子的团队，该重新算算这笔账了。
