0.63秒。780倍。8.8分钟变成0.53分钟。这三个数字放在一起，指向一个长期被忽视的痛点：大模型推理服务的启动。SGLang推出Weight Cache Daemon，让权重加载不再是磁盘带宽的奴隶。它用缓存复用，硬生生把分钟级的等待压成了眨眼之间。这背后，是对推理服务重启逻辑的重新思考。
八分钟的空转，GPU在等什么？
重启一次，GPU要发呆多久
想象一台承载 Ling-2.6-1T FP8 权重的 GPU 节点。这个模型的权重规模已经超过 TB 级，即使从 NVMe 固态盘顺序读取，理论带宽也只有六七 GB/s。刨开文件系统、系统调用和内存映射的开销，实际速度要再打一个折扣。于是，一次冷启动里，权重加载吃掉了绝大部分时间，GPU 的计算核心全程沉默，显存被逐渐填满，但没有任何 token 流进出。你盯着监控里的 GPU 利用率，看着一条直线停留在零点几，这种等待，真的很磨人。
磁盘加载的物理天花板
磁盘加载慢，本质上是被几层天花板同时压住。NVMe 的顺序带宽再高，也扛不住大量进程同时读同一个大目录。权重文件通常按张量切分，上百个分片一起读，随机读性能立刻恶化。内核的 page cache 只对重复读取友好，可每次新引擎都是新进程，第一遍读盘必须实打实从介质上搬数据。更要命的是，当一台节点上有多块 GPU，每块 GPU 都要独立加载一份权重时，磁盘 IO 会在瞬间饱和。负载一高，启动时间不是线性增加，而是直接翻倍。
八分钟对运维意味着什么
八分钟，足够一个微服务触发几十次健康检查，足够 K8s 重新调度一批副本，也足够用户点开另一个替代产品。对推理服务而言，这八分钟带来的后果是：扩容时必须提前预留足够的时间窗，缩容时不敢把实例全收回去，故障后要容忍一段漫长的空窗期。很多团队因此选择保留冗余常驻实例，哪怕 GPU 利用率不到 10%，也不敢真正按负载动态起停。启动时间，成为弹性调度最硬的瓶颈。
Weight Cache Daemon：换一种思路
绕过磁盘，直接命中缓存
Weight Cache Daemon 的做法，是让一个常驻进程提前把权重文件读入共享内存，然后所有新启动的推理引擎都从这个共享内存里拷贝权重，而不是重新打开文件读取。整个过程可以类比 Docker 的分层存储：底层镜像只是第一次拉取时付出网络和磁盘代价，之后每个容器都只是加一层薄薄的读写层。SGLang 把这个思路搬到了权重加载上。守护进程成了权重的中转站，磁盘只在首次填充时扮演供应商，此后便退出每次启动的关键路径。
从8分钟到0.53分钟的路径
官方在 Ling-2.6-1T FP8 上给出的数据很直观：权重加载时间从大约 8.2 分钟降到 0.63 秒，快约 780 倍；引擎总启动时间从 8.8 分钟压到 0.53 分钟。780 倍的差距从哪里来？内存带宽数十 GB/s 的起步速度，加上连续地址上的内存拷贝几乎没有任何额外开销，而磁盘加载每次都要经历地址转换、IO 调度和等待队列。当数据已经躺进内存，剩下的就是一道 memcpy。对 TB 级权重来说，这等于把一次长途运输变成了仓库内平移。
常驻进程的代价与边界
天下没有免费的缓存。Weight Cache Daemon 要常驻在节点上，占用的内存大约和模型权重一样大。拿 Ling-2.6-1T FP8 来说，主机内存要预留出妥妥的 1TB 以上。这意味着内存密度较高的节点才有条件真正享受这个红利。另外，缓存不是永动机：如果权重版本更新，缓存必须失效重建；如果守护进程本身崩溃或重启，后续所有引擎的启动都要重新经历一次漫长的磁盘加载。运维必须把这个进程当作节点上的一等公民，纳入监控和守护体系。
从分钟级到秒级，然后呢
哪些场景真正受益
最明显的受益者是容器环境里那些经常被抢占、被回收的 Pod。尤其在公有云上，spot 实例随时可能被中断，新实例通常要从镜像里拉起权重，没有缓存的话就是又一次八分钟。现在只要节点内存充足，新 Pod 可以直接挂载共享内存里的权重，启动时间缩短到秒级。另一个受益场景是多副本推理服务：同一台物理机上起第二个实例，第一次已经把权重拉进缓存，第二次启动几乎就是 fork 一个进程的体验。
局限：冷启动和显存压力
但别把缓存命中当成了免费午餐。所谓 0.63 秒，命中缓存之后的速度；冷启动时，磁盘加载的 8 分钟仍然一分不少。如果系统在节点重启后立刻拉起服务，权重需要先从磁盘读一遍，缓存热起来之前，启动时间还是老样子。此外，权重缓存放在主机内存，虽然不直接挤占显存，但主机内存本身也是稀缺资源。当一个节点要管理多个模型版本，或者模型权重超过单机内存容量，这个方案的性价比就要重新计算。
与现有推理栈的契合度
Weight Cache Daemon 是 SGLang 生态的一部分，和自家引擎配合得最顺。它的设计思路却具有通用性：只要推理引擎支持从共享内存映射权重，其他框架也能借用这个机制。但通用的另一面是不够直接。比如和 vLLM 或 TensorRT-LLM 混部时，你需要自己确认映射接口是否兼容，或者是否需要额外做一层适配。对一个小团队来说，这可能是延迟落地的理由；对追求极致弹性的平台团队来说，这正是一笔值得投的账。
当重启成为一种低成本的奢侈
弹性伸缩可以更野
过去扩容一个推理副本，要提前几分多钟预判流量。因为启动时间太长，扩容动作必须“提前量”足够大，否则流量上来时服务还没就绪。现在，权重加载已经不再是瓶颈，扩缩容的决策可以更激进：流量掉下去，缩容到零都不怕；流量一涨，秒级拉起新副本。当然，0.53分钟不是零，如果业务要求毫秒级响应，还是需要常驻实例。但至少，弹性策略的粒度可以从“小时级预估”变成“分钟级响应”。
故障恢复：从喝茶到喝咖啡
节点故障后，GPU 新实例加入集群是运维最紧张的时刻。传统的恢复流程，先是等待节点健康检查，然后拉起推理引擎，接着载入权重，最终才能对外提供推理能力。每一步都可能因为磁盘 IO 竞争而拖长。有了 Weight Cache Daemon，权重直接命中内存，故障恢复时间被压缩到一个能接受的区间。你甚至有心情去泡一杯咖啡，而不是盯着滚动日志发呆。
对推理引擎设计的一点启示
权重加载这个冷门环节，被缓存思想剖开，暴露出一个更大的可能性：推理系统里还有多少东西可以常驻、可复用？tokenizer 映射、模型配置、图优化结果，甚至每个请求的 KV cache，都可以从“每次重建”变成“常驻服务”。如果有一天，GPU 节点上真的提供一个通用的内存管家，统一管理权重、上下文和运行时资源，那么启动一个新的推理服务，可能真的就像 fork 一个进程那样轻巧。这条路还很长，但 Weight Cache Daemon 已经给出了第一段跑道。
