不要把 vLLM sleep 模式的唤醒理解成恢复旧的 KV 内容。vLLM 论坛的一则答复和 GitHub 上的 RFC 讨论显示，sleep 会释放大部分 GPU 显存；唤醒 kv_cache 实际是重新分配一块预留给 KV 块的显存，旧缓存不应期待被恢复，后续请求要重新填充缓存。这则论坛答复同时称，vLLM 在单个 LLM 进程内只支持同一模型的休眠与唤醒，切换不同模型仍需重新加载权重。前缀缓存跨 sleep 是否保留、唤醒后首次请求的 TTFT 回升多少，现有资料没有直接说明。下面分别说明唤醒时的显存分配、单进程多模型的边界，以及 sleep level 2 丢弃 buffer 的证据范围。
唤醒 kv_cache 分配的是新显存，不是旧内容
vLLM 用 PagedAttention 管理 attention 的 key/value 内存，并支持 continuous batching、chunked prefill 和 prefix caching。sleep 模式把模型占用的显存释放出来，让同一张 GPU 能腾给训练或其他任务；唤醒时再把这些内存拿回来。问题在于，“唤醒”这个词容易让人以为之前填充的 KV 块还在。
一位贡献者在 RFC 讨论中描述：唤醒 kv_cache 会尝试分配一个约占 GPU 显存 85% 的张量；如果其他对象占用超过 15%，就会 OOM。这里的 85%/15% 是特定 gpu_memory_utilization 配置下的示例，不能推广成所有部署的固定阈值；但它说明唤醒 kv_cache 是一次大块显存分配，而不是把旧 KV 内容从某处读回来。旧缓存既然在 sleep 时已被丢弃，唤醒后就不能指望它仍然可用。
更紧的场景出现在 RLHF 训练中：唤醒 vLLM 引擎准备更新权重时，旧权重、已丢弃的 KV cache 和新权重副本会同时占用同一块 GPU，导致 OOM。RFC 因此提议把唤醒拆成 tags 为 weights 和 kv_cache 的两次调用，先只重新分配权重内存，再分配 KV cache 内存，以降低唤醒时的峰值显存。这个提议仍是进行中的工作，不是已经落地的稳定行为。
单进程多模型分时复用不是 sleep 的目标场景
vLLM 论坛的一则答复称，sleep 模式可释放大部分 GPU 显存并支持快速唤醒，显著缩短同一模型的二次加载时间。但该答复同时指出，官方文档没有明确支持在单个 LLM 进程中切换多个不同模型，只支持同一模型的休眠与唤醒；模型切换仍需重新加载权重，仍有延迟。
这意味着 sleep 模式更多是优化同一模型在占用 GPU 的任务之间切换，不是多模型的分时复用。如果你在一个进程里依次服务多个模型，不能靠 sleep/wake 避免重新加载权重。这则论坛答复属于二手解释，不是官方规范原文；它描述的边界可以作为判断依据，但不能当作所有版本的行为保证。
level 2 会丢弃 buffer，不能只看权重
sleep 模式分级别，不同级别释放的内容不同。一位维护者在同一 RFC 讨论中指出，sleep level 2 尚未真正就绪，因为它还会丢弃类似 RoPE 嵌入的 buffer，这可能引发问题；讨论中出现了 mangled text 的输出异常描述。
这里的证据只到“level 2 会丢弃 buffer，并且可能引发问题”。资料没有说明这些 RoPE buffer 在唤醒后是否会被恢复，也没有确认 mangled text 是否会在所有版本、所有配置下出现。因此不能把 level 2 当成无风险换出：它丢弃的不只是权重，具体影响要看实现和版本。不要从这段讨论推断“唤醒后 RoPE buffer 一定影响输出质量”，那一步现有资料没有确认。
仍未证实的部分
现有资料没有直接说明 prefix caching 在 sleep/wake 后是否保留、何时失效；也没有给出唤醒后首次请求 TTFT 回升的具体数值或可观测指标。sleep level 2 的 buffer 丢弃行为也有版本和实现条件。
因此，判断旧缓存能否复用，不能只看“唤醒成功”这个结果。至少不能把旧 KV 内容当作唤醒后仍然可用；prefix caching 是否跨 sleep 保留，需要另看具体版本和实际行为。资料没有给出可直接套用的预热时间或验收指标，不能从现有信息推出统一数值。