Skip to content

[Docs] Record the measured cost of the colocate CPU backup and link the upstream report - #444

Closed
0z5a wants to merge 1 commit into
vllm-project:0z5a-branchfrom
0z5a:docs/tms-cpu-backup-cost
Closed

0z5a wants to merge 1 commit into
vllm-project:0z5a-branchfrom
0z5a:docs/tms-cpu-backup-cost

Conversation

@0z5a

@0z5a 0z5a commented Sep 19, 2026 •

Copy link
Copy Markdown

Incremental review: Files changed.

Base: 0z5a-branch at 791f101e20db377b28e15f12a00863baaea2605f.

Document the CPU-backup choice at ActorGroup's memory-saver configuration and link the measured dependency cost to torch_memory_saver#111.

Qwen3-0.6B colocate measurement Result
State parked per step Approximately 18.7 GiB
TMS pause / resume copy rate 2.41 / 5.32 GiB/s
Plain pinned copy, same device and volume 24.43 / 23.54 GiB/s
Disk backup on ext4 Approximately 30× slower

CPU backup preserves state; disabling backup cannot restore it. The measured copy cost belongs to the dependency. This PR changes one comment and has no runtime speedup. Offload attribution is in #443, and the existing resident configuration is explained by #445.

@gemini-code-assist gemini-code-assist Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request adds a detailed comment in vime/ray/actor_group.py explaining the performance characteristics and rationale for enabling CPU backup in torch_memory_saver. There are no review comments, so no additional feedback is provided.

@read-the-docs-community

read-the-docs-community Bot commented Sep 19, 2026 •

Copy link
Copy Markdown

@0z5a
0z5a force-pushed the docs/tms-cpu-backup-cost branch from 736e22e to be5306b Compare September 24, 2026 05:53
`Actor.sleep()` / `Actor.wake_up()` are the largest single block of a colocate
step, and the time is almost entirely `torch_memory_saver`'s CPU-backup copy:
measured on 1 GPU colocate with Qwen3-0.6B it moves ~18.7 GiB per step, and the
copy path runs at ~2.4 GiB/s while a plain pinned torch copy on the same device
does ~24 GiB/s.

Note at the point where the mode is chosen that CPU backup is the fastest of the
three modes here (disk backup measured ~30x slower on ext4, no backup cannot
restore the state), and link the upstream report so the next person to look at
this number does not have to re-measure it.

No behaviour change; comment only.

Signed-off-by: 0z5a <0z5a@users.noreply.github.com>
Signed-off-by: 0z5a <dezhen.lu@student.uni-tuebingen.de>
@0z5a

0z5a commented Oct 6, 2026

Copy link
Copy Markdown
Author

Superseded by #460, now merged into 0z5a-branch. The consolidated implementation and validation are retained there; closing this duplicate PR.

@0z5a 0z5a closed this Oct 6, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant