[Bugfix] Fix sleep-mode tensor ownership and recovery - #53344
Closed
Ronald1995 wants to merge 9 commits into
Closed
Ronald1995 wants to merge 9 commits into
Ronald1995 wants to merge 9 commits into
Conversation
Signed-off-by: Ronald1995 <ronaldautomobile@163.com>
Signed-off-by: Ronald1995 <ronaldautomobile@163.com>
Signed-off-by: Ronald1995 <ronaldautomobile@163.com>
Ronald1995
requested review from
22quinn,
AndreasKaratzas,
WoosukKwon,
mgoin,
njhill,
patrickvonplaten,
pavanimajety,
robertgshaw2-redhat,
tlrmchlsmth,
yewentao256 and
zyongye
as code owners
August 22, 2026 03:47
Signed-off-by: Ronald1995 <ronaldautomobile@163.com>
Contributor
|
Documentation preview: https://vllm--53344.org.readthedocs.build/en/53344/ |
Signed-off-by: Ronald1995 <ronaldautomobile@163.com>
Signed-off-by: Ronald1995 <ronaldautomobile@163.com>
Signed-off-by: Ronald1995 <ronaldautomobile@163.com>
Signed-off-by: Ronald1995 <ronaldautomobile@163.com>
Signed-off-by: Ronald1995 <ronaldautomobile@163.com>
Contributor
Author
|
test result for gemma3n before: > raise original_exception
E AssertionError: cycle 1: Gemma3n runtime tensors changed after sleep/wake; before=[{'embed_scale': (140380362670080, 8.0), 'embed_scale_per_layer': (140380362682880, 4.0), 'per_layer_input_scale': (140380362690560, 0.70703125), 'per_layer_projection_scale': (140380362690048, 8.0)}], after=[{'embed_scale': (140380362670080, 0.0), 'embed_scale_per_layer': (140380362682880, 0.0), 'per_layer_input_scale': (140380362690560, 0.0), 'per_layer_projection_scale': (140380362690048, 0.0)}]
E assert [{'embed_scal...690048, 0.0)}] == [{'embed_scal...690048, 8.0)}]
E
E At index 0 diff: {'embed_scale': (140380362670080, 0.0), 'embed_scale_per_layer': (140380362682880, 0.0), 'per_layer_input_scale': (140380362690560, 0.0), 'per_layer_projection_scale': (140380362690048, 0.0)} != {'
E
E ...Full output truncated (34 lines hidden), use '-vv' to showafter PASSED
=============================================================================================== warnings summary ================================================================================================
.venv/lib/python3.12/site-packages/torch/jit/_script.py:365: 14 warnings
/home/liurong/vllm/.venv/lib/python3.12/site-packages/torch/jit/_script.py:365: DeprecationWarning: `torch.jit.script_method` is deprecated. Please switch to `torch.compile` or `torch.export`.
warnings.warn(
test2.py::test_gemma3n_level2_sleep_wake_preserves_generation
/home/liurong/vllm/tests/utils.py:1759: DeprecationWarning: This process (pid=2078323) is multi-threaded, use of fork() may lead to deadlocks in the child.
pid = os.fork()
-- Docs: https://docs.pytest.org/en/stable/how-to/capture-warnings.html
================================================================================== 1 passed, 15 warnings in 118.44s (0:01:58) =================================================================================== |
aoshen02
reviewed
Aug 24, 2026
| with kv_cache_allocation_context or nullcontext(): | ||
| kv_caches = allocate_kv_cache( | ||
| kv_cache_config, | ||
| self.device, |
Collaborator
There was a problem hiding this comment.
No need to fix mrv1, let's focus on mrv2 first.
Contributor
Author
There was a problem hiding this comment.
ok, i'll focus on mrv2.
aoshen02
reviewed
Aug 24, 2026
| with self._maybe_get_memory_pool_context(tag="kv_cache"): | ||
| self.model_runner.initialize_kv_cache(kv_cache_config) | ||
| self.model_runner.initialize_kv_cache( | ||
| kv_cache_config, |
Collaborator
There was a problem hiding this comment.
let's just split this huge pr into several pieces for example
- sleep scope: only kvcache
- register buffer
- ...
Contributor
Author
There was a problem hiding this comment.
ok,i will split it into several prs
This was referenced Aug 24, 2026
Contributor
Author
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Purpose
Addresses the ownership and recovery design in #53343.
CuMem allocator tags describe the allocation site, but sleep mode treats them as lifecycle policy. A persistent runtime tensor allocated while the
kv_cacheorweightspool is active can therefore be discarded and remapped without its semantic value, while its virtual address remains stable. This can produce silent wrong results, including through an already captured CUDA graph.This PR:
kv_cachepool in MRV1 and MRV2 to the backing KV-cache allocation only;Related and duplicate work
Searched all vLLM issues and PRs for
sleep mode tensor ownershipandsleep mode kv cache tensor tagbefore submission.mainand adds recovery coverage.No open PR implementing this combined scope and recovery design was found.
Root-cause categories and potentially affected models
The affected surface is determined by both model architecture and the selected runtime backend. In particular, the MoE fixes below are not Gemma3n-specific: Gemma3n exercises model-owned static scaling tensors, while the MoE changes cover quantization backends shared by many sparse models.
Backend-dependent MoE exposure
A model name alone is insufficient to determine exposure. The same Qwen3-MoE or DeepSeek checkpoint can use Triton, CUTLASS, FlashInfer TRT-LLM, B12x, or Humming depending on its quantization format, GPU architecture, expert-parallel configuration, installed kernels, and --moe-backend.
The concrete backend classes audited by this PR include:
These are conditional examples, not claims that every checkpoint in each family is affected. Dense variants, deployments without sleep mode, and MoE models selecting an unaffected backend do not exercise the corresponding MoE recovery path.
Sleep-level distinction
Test Plan
pytest -q tests/v1/worker/test_kv_cache_allocation_scope.py pytest -q tests/model_executor/test_sleep_mode_tensor_ownership.py pytest -q tests/basic_correctness/test_mem.py -k "tagged_ordinary_tensor or level2_discards or cudagraph_replays" pytest -q tests/kernels/core/test_minimax_reduce_rms.py -k lamport_workspace_resetTest Result
uvx ruff checkpassed for all changed Python files.python -m compileallpassed for all changed vLLM Python files.uvloop.e2e case for gemma3n
AI assistance: OpenAI Codex was used to investigate, implement, and test this change. The submitter reviewed the design, code, tests, and commits and takes responsibility for the contribution.